Введение

Virtual Connect – это дополнительная надстройка для подключения к облаку для выделенного экземпляра Webex Calling (выделенный экземпляр). Virtual Connect позволяет клиентам безопасно расширять свои частные сети через Интернет с помощью VPN-туннелей "точка-точка". Этот вариант подключения обеспечивает быстрое установление частного сетевого соединения с использованием существующего оборудования для помещений клиента (Customer Premise Equipment, CPE) и подключения к Интернету.

Компания Cisco обеспечивает, управляет и обеспечивает избыточные туннели IP VPN и необходимый доступ в Интернет в регионе центра обработки данных Выделенного экземпляра Cisco, где это необходимо. Аналогично, администратор отвечает за соответствующие cpe-услуги и службы Интернета, которые необходимы для установления виртуального соединения.

Каждый заказ на виртуальное подключение в определенном регионе выделенного экземпляра должен включать в себя два общих туннеля инкапсуляции маршрутизации (GRE), защищенных шифрованием IPSec (GRE по IPSec), по одному для каждого центра обработки данных Cisco в выбранном регионе.

Виртуальное соединение имеет ограничение пропускной способности в 250 Мбит/с для туннеля и рекомендуется для небольших развертывания. Поскольку два VPN-туннеля "точка-точка" используются в облаке, весь трафик в облако должен проходить через клиентский головной процессор CPE, что может быть непригодным при большой площади удаленных объектов. Для других альтернативных параметров пиринга обратитесь к параметру Подключение к облаку.

Прежде чем отправлять запрос на пиринг для Virtual Connect, убедитесь, что в соответствующем регионе активирована услуга выделенного экземпляра.

Предварительные условия

Предварительные условия для создания виртуального соединения:

  • Клиент предоставляет

    • Подключение к Интернету с достаточной доступной полосой пропускания для поддержки развертывания

    • Публичные IP-адреса для двух туннелей IPSec

    • Транспортные IP-адреса GRE для двух туннелей GRE на стороне клиента

  • Партнер и клиент

    • Совместное использование для оценки требований к полосе пропускания

    • Обеспечение поддержки сетевых устройств на протокол пограничного шлюза (BGP) и проектирование туннеля GRE по IPSec

  • Партнер или клиент предоставляет

    • Сетовая группа с знанием технологий туннеля между узлами

    • Сетовая группа со знанием BGP, eBGP и общих принципов маршрутов

  • Cisco

    • Cisco назначена частная автономная система номеров (ASNS) и временный IP-адрес для интерфейсов туннеля GRE

    • Компании Cisco назначена доступная, но не доступная в Интернет сеть класса C (/24) для адресов в облаке выделенных экземпляров

Если у клиента имеется только 1 устройство CPE, то 2 туннеля к центрам обработки данных Cisco (DC1 и DC2) в каждом регионе будут от этого устройства CPE. Клиент также имеет возможность на 2 устройства CPE, поэтому каждое устройство CPE должно подключаться к 1 туннелю только к центрам обработки данных Cisco (DC1 и DC2) в каждом регионе. Можно добиться дополнительной избыточности, орвав каждый туннель в отдельном физическом объекте или местоположении в инфраструктуре клиента.

Технические сведения

Модель развертывания

Virtual Connect использует архитектуру головной системы двойного уровня, в которой плоскости маршрутов и управления GRE предоставлены одним устройством, а плоскость управления IPSec – другим.

По завершении подключения к виртуальному соединению между корпоративной сетью клиента и выделенными экземплярами центра обработки данных Cisco будут созданы два туннеля GRE по IPSec. Один на каждый избыточный центр обработки данных в соответствующем регионе. Дополнительные сетевые элементы, необходимые для пиринга, обмениваются партнером или клиентом на Cisco с помощью формы активации Virtual Connect Control Hub.

На рисунке ниже показан пример модели развертывания виртуального соединения для варианта с 2 концентраторами на стороне клиента.

Виртуальное соединение– VPN – это проект концентратора, в котором веб-сайты концентраторов клиента подключены к DC1 и DC2 центров обработки данных выделенных экземпляров в определенном регионе.

Для улучшения избыточности рекомендуется использовать два узла Концентратора, однако поддерживаются также веб-сайты с одним концентратором с двумя туннелями.

Полоса пропускания одного туннеля ограничена до 250 Мбит/с. Для обеспечения эффективного отказоустойчивого режима суммарный трафик по обоим туннелям не должен превышать 250 Мбит/с, поскольку в случае сбоя весь трафик будет направляться через один туннель.

Удаленные объекты клиента в том же регионе, необходимо будет подключиться обратно к концентратору через WAN клиента, и компания Cisco не несет ответственности за это подключение.

Ожидается, что партнеры будут тесно сотрудничать с клиентами, обеспечивая выбор наиболее оптимального пути для региона обслуживания Virtual Connect.

На рисунке ниже показаны пиринговые регионы подключения выделенного экземпляра облака.

Виртуальные области соединения

Маршрутизация

Маршрутка для виртуальной надстройки Connect реализована с использованием внешнего BGP (eBGP) между выделенным экземпляром и оборудованием в помещении клиента (CUSTOMER Premise Equipment, CPE). Компания Cisco объявит о своей сети для каждого избыточного ЦОДа в регионе для клиентского оборудования, и CPE является обязательной для объявления маршрутов по умолчанию в Cisco.

  • Cisco поддерживает и назначает

    • IP-адресвание интерфейса туннеля (временный канал для маршрутики) назначается Cisco из назначенного общего адресного пространства (не для публичной маршрутики)

    • Адрес делегации транспортного туннеля (на стороне Cisco)

    • Номера частной автономной системы (ASNS) для конфигурации маршрутов BGP клиента

      • Cisco назначает из назначенного частного диапазона использования: с 64512 по 65534

  • EBGP используется для обмена маршрутами между выделенным экземпляром и CPE

    • Cisco разделит назначенную сеть /24 на 2/25 один для каждого постоянного тока в соответствующем регионе

    • В виртуальном подключении каждая /25 сеть объявляется клиентом cisco через соответствующие VPN-туннели «точка-точка» (временные соединения)

    • Для CPE должны быть настроены соответствующие соседние ели EBGP. При использовании одного CPE будут использоваться два eBGP-соседя, которые указывают на каждый удаленный туннель. При использовании двух CPE каждый CPE будет иметь единый соседний eBGP-канал для одного удаленного туннеля для CPE.

    • Сбоку каждого туннеля GRE (IP-интерфейса туннеля) Cisco настраивается как соседний BGP на CPE

    • CPE требуется для объявления маршрута по умолчанию по каждому из туннелей

    • CPE может при необходимости перераспределить перераспределяемые маршруты в пределах корпоративной сети осязаемого предприятия.

  • В случае отказа канала без отказа один CPE будет иметь два активных и активных туннеля. Для двух узлов CPE каждый CPE будет иметь один активный туннель, и оба узла CPE должны быть активными и проходить трафик. В сценарии, не относясь к отказу, трафик должен разделяться на два туннеля, которые будут проходить к правильному пункту назначения /25. Если один из туннелей выходит из строя, оставшийся туннель может проходить трафик для обоих туннелей. В таком сценарии отказа при отбое сети /25 сеть /24 используется в качестве резервного маршрута. Cisco отправит трафик клиентов через свою внутреннюю WAN в ЦОД, в связи с которым соединение разослаться не будет.

Виртуальный поток трафика соединения

Транспортный поток, когда оба туннеля подняты

Выделенный экземпляр — виртуальное подключение

На этом изображении показана архитектура сети Virtual Connect, на которой подробно показан поток трафика, когда работают как первичный, так и вторичный туннели.

Она представляет собой активную модель подключения, позволяющую клиенту получать доступ к UC-приложениям, размещенным в центрах обработки данных Cisco, используя двойную GRE/IPSEC туннели через Интернет с BGP для обмена маршрутами.

Определения:

  • Помещение клиента:
    • Это представляет собой локальную сеть заказчика, в которой находятся пользователи и их устройства (например, IP-телефоны, компьютеры, на которых работают клиенты UC).
    • Трафик, исходящий отсюда, должен достигать приложений UC, размещенных в центрах обработки данных Cisco.
  • Центры обработки данных выделенного экземпляра Cisco Webex Calling (выделенный экземпляр) (WxC-DI DC-A и WxC-DI DC-B):
    • Это центры обработки данных Cisco, в которых размещаются UC-приложения.
    • DC-A и DC-B географически разделены, что обеспечивает избыточность.
    • Каждый центр обработки данных имеет собственную подсеть для приложений UC:
      • DC-A subnet:X.X.X.0/25
      • DC-B subnet:X.X.X.128/25
  • GRE/IPsec Туннели (Туннель 1 и Туннель 2):
    • Это безопасные, зашифрованные соединения между помещением клиента и центром обработки данных Cisco через общедоступный Интернет.
    • GRE (общая инкапсуляция маршрутизации): Этот протокол используется для инкапсуляции различных протоколов сетевого уровня внутри виртуальных соединений «точка-точка». Он позволяет протоколам маршрутизации, таким как BGP, работать через туннель.
    • IPsec (безопасность интернет-протокола): Этот набор протоколов обеспечивает криптографические службы безопасности (аутентификацию, целостность, конфиденциальность) для IP-коммуникаций. Он шифрует инкапсулированный GRE трафик, обеспечивая безопасную передачу данных через Интернет.
  • Протокол пограничного шлюза (BGP):
    • BGP — это протокол маршрутизации, используемый для обмена маршрутной информацией между помещением клиента и центрами обработки данных Cisco.

Как показано на схеме выше, устройства, развернутые на территории клиента, должны устанавливать два GRE/IPSEC туннели.

Соглашения об именовании, используемые ниже с XX / YY, DC-A DC-B являются общими для всех регионов, где предлагается выделенный экземпляр. Эти значения будут уникальными для каждого региона и фактическими значениями для каждого региона. Конкретные значения предоставляются во время активации виртуального соединения.

Со стороны Cisco туннели IPSec и GRE будут терминироваться на разных устройствах. Поэтому клиент должен соответствующим образом настроить IP-адреса назначения IPSec и GRE на устройствах. Клиенты могут использовать один и тот же IP-адрес для GRE и IPSEC, если он поддерживается на их устройствах. См. диаграмму выше. Значения, связанные с IP-адресом, предоставляются во время активации виртуального соединения на портале.

  • Туннель 1: Подключает помещение клиента к «Выделенному экземпляру DC-A» (центру обработки данных A) через Интернет. Этот туннель использует BGP AS:64XX1 на стороне клиента и BGP AS:64XX2 на стороне выделенного экземпляра DC-A. Конфигурации источников туннелей IPSEC и GRE делятся на данные, предоставленные заказчиком, и данные, предоставленные Cisco.
  • Туннель 2: Подключает помещение клиента к «Выделенному экземпляру DC-B» (центру обработки данных B) через Интернет. Этот туннель использует BGP AS:64YY1 на стороне клиента и BGP AS:64YY2 на стороне выделенного экземпляра DC-B. Как и в случае с туннелем 1, конфигурации источников туннелей IPSEC и GRE являются общими для клиента и Cisco.

В БГП AS:64XX и БГП AS:64YY, XX и YY характерны для определенного региона.

Как только GRE/IPSEC туннели устанавливаются с центрами обработки данных выделенных экземпляров Webex Calling (A и B), клиент должен получить следующие маршруты, объявленные Cisco через соответствующие сеансы BGP.

  • Для DC-A: Маршруты, объявленные Cisco, будут X.X.X.0/25 и X.X.x.0/24. При необходимости, если IaaS запрошен и настроен для клиентских маршрутов Y.Y.Y.0/25 и Y.Y.Y.0/24 будет рекламироваться компанией Cisco.
  • Для DC-B: Маршруты, объявленные Cisco, будут X.X.X.128/25 и X.X.x.0/24. При необходимости, если IaaS запрошен и настроен для клиентских маршрутов Y.Y.Y.128/25 и Y.Y.Y.0/24 будет рекламироваться компанией Cisco.
  • Клиенту необходимо рекламировать 0.0.0./0 маршрут к Cisco через оба соединения (туннели)
  • Клиент должен использовать самый длинный префикс (/25) маршруты для отправки трафика в Cisco через соответствующие туннели, когда оба туннеля активны.
  • Cisco будет возвращать трафик через те же туннели, чтобы сохранить симметричность трафика.

Транспортный поток:

  • Трафик, предназначенный для «DC-A UC Apps» (X.X.X.0/25) из помещения заказчика потоки проходят через туннель 1.
  • Трафик, предназначенный для «DC-B UC Apps» (X.X.X.128/25) из помещения клиента потоки проходят через туннель 2.

Сценарий отказа : транспортный поток, когда один из туннелей выходит из строя

Выделенный экземпляр — виртуальное подключение

Как показано на схеме выше, когда туннель к DC-A отключается, bgp, установленный через туннель к DC-A, отключается.

Влияние на BGP: При выходе из строя туннеля 1 сеанс BGP по этому туннелю также будет прерван. Следовательно, DC-A больше не сможет рекламировать свои маршруты (в частности, X.X.X.0/25) к клиенту по этому пути. Следовательно, маршрутизатор клиента определит путь как недоступный.

Теперь, поскольку Туннель 1 не работает, маршрутизатор клиента на территории клиента автоматически удалит маршруты, полученные через Туннель 1, из своей таблицы маршрутизации или отметит их как недоступные.

  • Трафик, предназначенный для сети приложений UC (X.X.X.0/24) или подсеть DC-A (X.X.X.0/25) затем будет перенаправлен через рабочий туннель к DC-B, который продолжает рекламировать X.X.X.0/24 который включает в себя X.X.X.0/25 сеть.
  • Аналогичное поведение будет наблюдаться, если туннель к DC-B не работает, а туннель к DC-A все еще работает.

Процесс подключения

Ниже описано, как установить соединение с виртуальным Connect для выделенного экземпляра.
1

Размещение заказа в Cisco CCW

2

Активация виртуального соединения из Control Hub

3

Cisco выполняет настройку сети

4

Клиент выполняет настройку сети

Этап 1. Заказ CCW

Virtual Connect – это надстройка для выделенного экземпляра в CCW.

1

Перейдите на веб-сайт для заказа CCW и щелкните Login (Вход), чтобы войти на веб-сайт:

https://apps.cisco.com/Commerce/guest.
2

Выберите Create Estimate (Создать предложение с расценками).

3

Добавьте SKU "A-FLEX-3".

4

Выберите Редактировать параметры.

5

На отобра похожей вкладке подписки выберите Параметры и Надстройки.

6

В области Дополнительные надстройки выберите поле "Виртуальное соединение для выделенного экземпляра". SKU – это A-FLEX-DI-VC.

7

Введите количество и количество регионов, в которых требуется virtual Connect.

Количество виртуальных подключений не должно превышать общее количество регионов, приобретенных для выделенного экземпляра. Кроме того, в одном регионе допускается только один порядок виртуальных подключений.
8

Если вы удовлетворены выбором, щелкните Проверить и сохранить в правой верхней части страницы.

9

Щелкните Save (Сохранить), а затем Continue (Продолжить), чтобы оформить заказ. После завершения этого заказа приложение будет в сетке заказов.

Этап 2. Активация виртуального соединения в Control Hub

1

Во войти в Control Hub https://admin.webex.com/login.

2

В разделе Службы перейдите к разделу Вызовы > службу instacnce > облаке.

3

На карточке Virtual Connect указано приобретенное количество Virtual Connect. Теперь администратор может щелкнуть Активировать , чтобы инициировать активацию виртуального соединения.

Активация может быть инициирована только администраторами с ролью "Администратор с полными клиентами". При этом администратор с ролью "Администратор только для чтения клиента" может только просматривать состояние.
4

При нажатии кнопки "Активировать" администратор может предоставить администратору технические сведения, необходимые для пиринговых конфигураций на стороне Cisco.

Кроме того, в форме статическая информация на стороне компании Cisco основывается на выбранном регионе. Эта информация будет полезна администраторам клиентов для настройки клиентской сети для установления соединения.

  1. IP-адрес туннельного транспорта GRE: Клиенту необходимо предоставить IP-адреса для бокового туннеля, и компания Cisco динамически выделит IP-адреса по завершению активации. IPSec ACL для трафика с интересным трафиком должен позволять локальному транспортному туннелю IP/32 к удаленному транспортному транспортному туннелю IP/32. В ACL также должен указываться только протокол GRE IP.

    IP-адрес, предоставленный клиентом, может быть частным или общедоступным.

  2. Одноранговые узлы IPSec: Клиент должен предоставить IP-адреса источника туннеля IPSec, а компания Cisco выделяет IP-адрес назначения IPSec. При необходимости также поддерживается трансляция NAT внутреннего туннеля IPSEC на публичный адрес.

    IP-адрес, предоставленный клиентом, должен быть общедоступным.

    Вся другая статическая информация, представленная на экране активации, является частью безопасности и стандартов шифрования Cisco, с которыми следует следовать. Статическая конфигурация не подстроима и не подгоняться. Для дальнейшей помощи в отношении статических конфигураций на стороне Cisco клиенту необходимо будет связаться с TAC.
5

После заполнения всех обязательных полей щелкните кнопку Активировать.

6

После завершения активации формы активации виртуального соединения для региона, который является частью, клиент может экспортировать форму активации из Control Hub, на вкладке Вызовы > Выделенная служба > Cloud Connectivity" и щелкнуть Параметры экспорта.

По соображениям безопасности аутентификация и пароль BGP не будут доступны в экспортированном документе, но администратор может просмотреть их в Control Hub, нажав Просмотреть настройки в Control Hub, Вызов > Выделенный экземпляр > Вкладка «Подключение к облаку».

Этап 3. Cisco выполняет настройку сети

1

По завершению формы активации виртуального соединения состояние будет обновлено до состояния "Активация, которая уже идет в вызове> выделенном экземпляре > карточке "Виртуальное соединение с подключением к облаку".

2

Cisco выполнит необходимые настройки на оборудовании Cisco в течение 5 рабочих дней. После успешного завершения состояние будет обновлено до "Активировано" для этого региона в Control Hub.

Шаг 4. Клиент выполняет настройку сети

Состояние изменено на "Активировано", чтобы известить администратора клиента о том, что конфигурации сети IP VPN компании Cisco выполнены на основе входных данных, предоставленных клиентом. Однако ожидается, что администратор клиента завершит настройку конфигураций клиентского оборудования и протестирует маршруты подключения для туннеля виртуального соединения в режиме онлайн. В случае любых проблем, с которыми столкнулись при настройке или подое связи, клиент может за помощью связаться с Cisco TAC.

Устранение неполадок

Устранение неполадок и проверка первой фазы IPsec (согласование IKEv2)

Согласование туннеля IPsec включает две фазы: фазу IKEv2 и фазу IPsec. Если согласование фазы IKEv2 не завершено, то вторая фаза IPsec не инициируется. Сначала выполните команду «show crypto ikev2 sa» (на оборудовании Cisco) или аналогичную команду на оборудовании стороннего производителя, чтобы проверить активность сеанса IKEv2. Если сеанс IKEv2 неактивен, возможными причинами могут быть:

  • Интересный трафик не активирует туннель IPsec.

  • Список доступа к туннелю IPsec настроен неправильно.

  • Отсутствует связь между клиентом и IP-адресом конечной точки туннеля IPsec выделенного экземпляра.

  • Параметры сеанса IKEv2 на стороне выделенного экземпляра и на стороне клиента не совпадают.

  • Брандмауэр блокирует пакеты IKEv2 UDP.

Сначала проверьте журналы IPsec на наличие сообщений, показывающих ход согласования туннеля IKEv2. Журналы могут указывать на проблему с согласованием IKEv2. Отсутствие сообщений журнала также может указывать на то, что сеанс IKEv2 не активирован.

Некоторые распространенные ошибки при согласовании IKEv2:

  • Настройки IKEv2 на стороне CPE не соответствуют настройкам Cisco, перепроверьте указанные настройки:

    • Убедитесь, что версия IKE — 2.

    • Убедитесь, что параметры шифрования и аутентификации соответствуют ожидаемому шифрованию на стороне выделенного экземпляра.

      При использовании шифра «GCM» протокол GCM обрабатывает аутентификацию и устанавливает параметр аутентификации в значение NULL.

    • Проверьте настройки срока службы.

    • Проверьте группу модулей Диффи-Хеллмана.

    • Проверьте настройки псевдослучайной функции.

  • Список доступа для криптокарты не установлен на:

    • Разрешить GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (или эквивалентную команду)

      Список доступа должен быть предназначен специально для протокола «GRE», протокол «IP» работать не будет.

Если сообщения журнала не показывают никакой активности согласования для фазы IKEv2, то может потребоваться захват пакетов.

Сторона выделенного экземпляра не всегда может инициировать обмен IKEv2 и иногда может ожидать, что инициатором станет сторона CPE клиента.

Проверьте конфигурацию стороны CPE на наличие следующих предварительных условий для инициирования сеанса IKEv2:

  • Проверьте список криптографического доступа IPsec для трафика GRE (протокол 50) от транспортного IP-адреса туннеля CPE до транспортного IP-адреса туннеля выделенного экземпляра.

  • Убедитесь, что интерфейс туннеля GRE включен для сообщений Keepalive GRE. Если оборудование не поддерживает сообщения Keepalive GRE, то Cisco получает уведомление, поскольку сообщения Keepalive GRE будут включены на стороне выделенного экземпляра по умолчанию.

  • Убедитесь, что протокол BGP включен и настроен с использованием адреса соседа IP-адреса туннеля выделенного экземпляра.

При правильной настройке начинается создание туннеля IPsec и согласование первой фазы IKEv2:

  • Сообщения GRE keepalive от интерфейса туннеля GRE на стороне CPE к интерфейсу туннеля GRE на стороне выделенного экземпляра.

  • Сеанс TCP соседа BGP от соседа BGP на стороне CPE к соседу BGP на стороне выделенного экземпляра.

  • Отправьте пинг с IP-адреса туннеля стороны CPE на IP-адрес туннеля стороны выделенного экземпляра.

    Пинг не может быть туннельным транспортным IP-адресом к туннельному транспортному IP-адресу, он должен быть туннельным IP-адресом к туннельному IP-адресу.

Если требуется трассировка пакетов для трафика IKEv2, установите фильтр для UDP и либо порт 500 (когда между конечными точками IPsec нет устройства NAT), либо порт 4500 (когда между конечными точками IPsec вставлено устройство NAT).

Убедитесь, что пакеты IKEv2 UDP с портом 500 или 4500 отправляются и принимаются на IP-адрес DI IPsec.

Центр обработки данных выделенного экземпляра не всегда может начинать первый пакет IKEv2. Требование состоит в том, чтобы устройство CPE было способно инициировать первый пакет IKEv2 в сторону выделенного экземпляра.

Если локальный брандмауэр это позволяет, попробуйте также выполнить команду ping на удаленный адрес IPsec. Если пинг с локального на удаленный адрес IPsec не удался, выполните трассировку маршрута, чтобы определить, где пакет был потерян.

Некоторые брандмауэры и интернет-оборудование могут не допускать трассировку маршрута.

Устранение неполадок и проверка второй фазы IPsec (согласование IPsec)

Перед устранением неполадок на втором этапе IPsec убедитесь, что первая фаза IPsec (то есть сопоставление безопасности IKEv2) активна. Выполните команду «show crypto ikev2 sa» или эквивалентную ей для проверки сеанса IKEv2. В выходных данных убедитесь, что сеанс IKEv2 активен уже более нескольких секунд и не прерывается. Продолжительность сеанса отображается в выходных данных как «Активное время» сеанса или эквивалент.

После проверки сеанса IKEv2 на работоспособность и активность проверьте сеанс IPsec. Как и в случае с сеансом IKEv2, выполните команду «show crypto ipsec sa» или эквивалентную ей для проверки сеанса IPsec. Перед установлением туннеля GRE должны быть активны как сеанс IKEv2, так и сеанс IPsec. Если сеанс IPsec не отображается как активный, проверьте журналы IPsec на наличие сообщений об ошибках или ошибок согласования.

Некоторые из наиболее распространенных проблем, которые могут возникнуть во время переговоров IPsec:

Настройки на стороне CPE не соответствуют настройкам выделенного экземпляра, перепроверьте настройки:

  • Убедитесь, что параметры шифрования и аутентификации соответствуют настройкам на стороне выделенного экземпляра.

  • Проверьте настройки Perfect Forward Secrecy и убедитесь, что они соответствуют настройкам на стороне выделенного экземпляра.

  • Проверьте настройки срока службы.

  • Убедитесь, что IPsec настроен в туннельном режиме.

  • Проверьте IPsec-адреса источника и назначения.

Устранение неполадок и проверка туннельного интерфейса

Когда сеансы IPsec и IKEv2 проверены на работоспособность и активность, пакеты поддержки активности туннеля GRE могут передаваться между выделенным экземпляром и конечными точками туннеля CPE. Если интерфейс туннеля не отображает свой статус, вот некоторые распространенные проблемы:

  • Транспортный VRF туннельного интерфейса не соответствует VRF интерфейса обратной связи (если на туннельном интерфейсе используется конфигурация VRF).

    Если на туннельном интерфейсе не используется конфигурация VRF, эту проверку можно проигнорировать.

  • Сообщения Keepalive не включены на интерфейсе туннеля со стороны CPE.

    Если на оборудовании CPE не поддерживаются пакеты keepalive, необходимо уведомить об этом компанию Cisco, чтобы пакеты keepalive по умолчанию на стороне выделенного экземпляра также были отключены.

    Если сообщения keepalive поддерживаются, проверьте, включены ли они.

  • Маска или IP-адрес туннельного интерфейса неверны и не соответствуют ожидаемым значениям выделенного экземпляра.

  • Исходный или целевой транспортный адрес туннеля неверен и не соответствует ожидаемым значениям выделенного экземпляра.

  • Межсетевой экран блокирует отправку пакетов GRE в туннель IPsec или получение из туннеля IPsec (туннель GRE передается по туннелю IPsec).

Тест ping должен подтвердить работоспособность локального туннельного интерфейса и наличие соединения с удаленным туннельным интерфейсом. Выполните проверку ping с IP-адреса туннеля (не транспортного IP-адреса) на IP-адрес удаленного туннеля.

Список криптографического доступа для туннеля IPsec, по которому передается трафик туннеля GRE, разрешает пересечение только пакетов GRE. В результате пинги не будут работать с IP-адреса туннельного транспорта на удаленный IP-адрес туннельного транспорта.

Результатом проверки ping является пакет GRE, который генерируется из исходного туннельного транспортного IP-адреса в целевой туннельный транспортный IP-адрес, в то время как полезной нагрузкой пакета GRE (внутренний IP-адрес) будет исходный и целевой туннельный IP-адрес.

Если тест ping не увенчался успехом и предыдущие пункты проверены, то может потребоваться захват пакета, чтобы убедиться, что icmp-пинг приводит к формированию пакета GRE, который затем инкапсулируется в пакет IPsec и отправляется с исходного адреса IPsec на целевой адрес IPsec. Счетчики на интерфейсе туннеля GRE и счетчики сеансов IPsec также могут помочь показать, увеличиваются ли отправленные и полученные пакеты.

Помимо пингового трафика, захват также должен показывать пакеты GRE keepalive даже во время простоя трафика. Наконец, если настроен BGP, пакеты BGP keepalive также должны отправляться как пакеты GRE, инкапсулированные в пакеты IPSEC, а также через VPN.

Устранение неполадок и проверка BGP

Сеансы BGP

BGP требуется в качестве протокола маршрутизации через туннель VPN IPsec. Локальный сосед BGP должен установить сеанс eBGP с соседом выделенного экземпляра BGP. IP-адреса соседей eBGP совпадают с IP-адресами локального и удаленного туннелей. Сначала убедитесь, что сеанс BGP активен, а затем проверьте, что от выделенного экземпляра поступают правильные маршруты и на выделенный экземпляр отправляется правильный маршрут по умолчанию.

Если туннель GRE установлен, проверьте успешность ping-запроса между локальным и удаленным IP-адресами туннеля GRE. Если ping прошел успешно, но сеанс BGP не устанавливается, проверьте журнал BGP на наличие ошибок установления BGP.

Некоторые из наиболее распространенных проблем согласования BGP:

  • Номер удаленной AS не совпадает с номером AS, настроенным на стороне выделенного экземпляра. Перепроверьте конфигурацию соседней AS.

  • Локальный номер AS не соответствует ожидаемому значению выделенного экземпляра. Проверьте, соответствует ли локальный номер AS ожидаемым параметрам выделенного экземпляра.

  • Межсетевой экран блокирует отправку пакетов BGP TCP, инкапсулированных в пакеты GRE, в туннель IPsec или получение из туннеля IPSEC.

  • IP-адрес удаленного соседа BGP не совпадает с IP-адресом удаленного туннеля GRE.

Обмен маршрутами BGP

После проверки сеанса BGP для обоих туннелей убедитесь, что со стороны выделенного экземпляра отправляются и принимаются правильные маршруты.

Решение VPN с выделенным экземпляром предполагает установку двух туннелей из customer/partner сторона. Первый туннель указывает на выделенный центр обработки данных экземпляра A, а второй туннель указывает на выделенный центр обработки данных экземпляра B. Оба туннеля должны быть в активном состоянии, и для решения требуется active/active развертывание. Каждый выделенный центр обработки данных экземпляра будет рекламировать свой локальный /25 маршрут, а также /24 запасной маршрут. При проверке входящих маршрутов BGP от выделенного экземпляра убедитесь, что сеанс BGP, связанный с туннелем, указывающим на центр обработки данных выделенного экземпляра A, получает центр обработки данных выделенного экземпляра A. /25 местный маршрут, а также /24 запасной маршрут. Кроме того, убедитесь, что туннель, указывающий на выделенный экземпляр центра обработки данных B, получает выделенный экземпляр центра обработки данных B. /25 местный маршрут, а также /24 запасной маршрут. Обратите внимание, что /24 Резервный маршрут будет тем же маршрутом, который объявлен из центра обработки данных выделенного экземпляра A и центра обработки данных выделенного экземпляра B.

Резервирование обеспечивается для выделенного экземпляра центра обработки данных в случае выхода из строя туннельного интерфейса к этому центру обработки данных. Если подключение к центру обработки данных выделенного экземпляра A потеряно, то трафик будет перенаправлен из центра обработки данных выделенного экземпляра B в центр обработки данных A. В этом сценарии туннель к центру обработки данных B будет использовать центр обработки данных B. /25 маршрут для отправки трафика в центр обработки данных B и туннель к центру обработки данных B будут использовать резервный /24 маршрут для отправки трафика в центр обработки данных A через центр обработки данных B.

Важно, чтобы при активности обоих туннелей туннель центра обработки данных A не использовался для отправки трафика в центр обработки данных B и наоборот. В этом сценарии, если трафик отправляется в центр обработки данных A с пунктом назначения в центре обработки данных B, центр обработки данных A перешлет трафик в центр обработки данных B, а затем центр обработки данных B попытается отправить трафик обратно к источнику через туннель центра обработки данных B. Это приведет к неоптимальной маршрутизации и может также нарушить прохождение трафика через межсетевые экраны. Поэтому важно, чтобы оба туннеля находились в одном месте. active/active конфигурации во время нормальной работы.

The 0.0.0.0/0 Маршрут должен быть объявлен от стороны клиента до стороны центра обработки данных выделенного экземпляра. Более конкретные маршруты не будут приняты выделенной стороной экземпляра. Убедитесь, что 0.0.0.0/0 Маршрут объявляется как из туннеля центра обработки данных выделенного экземпляра A, так и из туннеля центра обработки данных выделенного экземпляра B.

Конфигурация MTU

На стороне выделенного экземпляра включены две функции для динамической настройки MTU для больших размеров пакетов. Туннель GRE добавляет дополнительные заголовки к IP-пакетам, проходящим через сеанс VPN. Туннель IPsec добавляет дополнительные заголовки поверх заголовков GRE, что еще больше снижает максимальный допустимый размер MTU для туннеля.

Туннель GRE регулирует функцию MSS, а путь туннеля GRE в функции обнаружения MTU включается на стороне выделенного экземпляра. Настройте «ip tcp adjust-mss 1350» или эквивалентную команду, а также «tunnel path\u0002mtu-discovery" или эквивалентная команда на стороне клиента, помогающая в динамической настройке MTU трафика через VPN-туннель.