Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Динамические туннели на основе следующего перехода

Примере: Настройка динамических туннелей MPLS перехода через UDP

В данном примере показано, как настроить динамический туннель MPLS-UDP с составным следующим переходом. Функция MPLS UDP обеспечивает преимущество масштабирования числа IP-туннелей, поддерживаемых устройством.

Начиная Junos OS 18.3R1, туннели MPLS Свыше UDP поддерживаются на серия PTX и серия QFX коммутаторах. Для каждого динамического туннеля, настроенного на маршрутизаторе PTX или коммутаторе QFX, создаются составный туннельный следующий переход, следующий непрямый переход и следующий переход переадправления для разрешения маршрута назначения туннеля. Управление политикой можно также использовать для разрешения динамического туннеля по выбору префиксов, включив в нее утверждение конфигурации forwarding-rib на [edit routing-options dynamic-tunnels] уровне иерархии.

Требования

В данном примере используются следующие аппаратные и программные компоненты:

  • Пять серия MX с MCS и MCS.

  • Junos OS версии 16.2 или более поздней на маршрутизаторах edge поставщика (PE).

Перед началом работы:

  1. Настройте интерфейсы устройств, включая интерфейс обратной связи.

  2. Настройте ID маршрутизатора и автоматический номер системы для устройства.

  3. Установить внутренний BGP (IBGP) с удаленным устройством PE.

  4. Установить OSPF пиринга между устройствами.

Обзор

Начиная с Junos OS 16.2 динамический туннель UDP поддерживает создание туннельного составного следующего перехода для каждого настроенного туннеля UDP. Эти динамические туннели UDP на основе следующего перехода называются MPLS-UDP-туннелями. Составный следующий переход по умолчанию включен для туннелей MPLS-UDP.

MPLS туннели свыше UDP могут быть двухнаправленные или однонаправленные по своей сути.

  • Двухнаправленный . Когда устройства PE подключены по туннелям MPLS-UDP в обоих направлениях, это называется двухнаправленным MPLS-по-UDP-туннелю.

  • Однонаправленное — два устройства PE соединены по туннелю MPLS UDP в одном направлении и через MPLS/IGP в другом направлении, это называется однонаправленным туннелем MPLS-через UDP-туннель.

    Однонаправленные туннели MPLS UDP используются в сценариях миграции или в случаях, когда два устройства PE обеспечивают связь друг с другом по двум разнонаправленным сетям. Поскольку туннель обратного направления не существует для однонаправленных туннелей MPLS UDP, необходимо настроить декапсуляцию на основе фильтра MPLS-over-UDP на удаленном устройстве PE для пересылки трафика.

Начиная с Junos OS release 18.2R1, на маршрутизаторах серии PTX и QFX10000 с однонаправленными MPLS-UDP-туннелями, необходимо настроить удаленное устройство PE с входным фильтром для MPLS-over-UDP-пакетов, а также действия по декапсулированию IP- и UDP-задатков для перенаправления пакетов в обратном туннельном направлении.

Например, на удаленном устройстве PE, Device PE2, для однонаправленных туннелей с MPLS UDP требуется следующая конфигурация:

PE2

В вышеприочисленной конфигурации Decap_Filter имя фильтра брандмауэра, используемого для MPLS-uDP-декапсуляции. Термин "udp_decap" является входным фильтром для примите пакетов UDP на интерфейсе интерфейса основного интерфейса устройства PE2, а затем декапсулирует MPLS-over-UDP-пакетов для MPLS-ip-пакетов для переадранизации.

Можно использовать существующие команды брандмауэра в режиме эксплуатации, например, для просмотра декапсуляции на MPLS UDP на основе show firewall filter фильтров.

Например:

Прим.:

Для однонаправленных туннелей MPLS UDP:

  • В качестве внешнего загона поддерживается только адрес IPv4. Декапсуляция MPLS UDP на основе фильтра не поддерживает адрес IPv6 во внешнем загоде.

  • После декапсуляции поддерживается только экземпляр маршрутизации по умолчанию.

Начиная Junos OS 17.1, на серия MX с MMPC и MCS, увеличивается предел масштабирования MPLS туннелей, которые могут быть больше UDP.

Начиная с Junos выпуска 19.2R1, на серия MX маршрутизаторах с MCS и MCS, архитектуру несущей поддержки (CSC) можно развертывать с помощью MPLS-UDP туннелей, несущих MPLS по динамическим туннелям IPv4 UDP, установленным между устройствами PE несущей. С помощью этого усовершенствования преимущество масштабирования, предоставляемых туннелем MPLS over UDP, еще больше возрастает. Поддержка CSC с туннелем MPLS UDP не поддерживается для туннеля IPv6 UDP.

Существующая функция динамического туннеля требует полной статической настройки. В настоящее время информация о туннеле, полученная от одноранговых устройств на объявленных маршрутах, игнорируется. Начиная с Junos OS выпусков 17.4R1, на серия MX маршрутизаторах сигнализируются динамические MPLS на основе UDP следующего перехода с использованием расширенных BGP инкапсуляции. BGP экспорта используется для указания типов туннелей, объявления сведений о туннеле на стороне отправитель, а также для их разчета и передачи данных туннеля на стороне приемника. Туннель создается в соответствии с полученным типом туннельного сообщества.

Несколько инкапсуляций туннеля поддерживаются BGP. При получении нескольких возможностей динамический туннель следующего перехода создается на основе настроенной политики BGP и предпочтения туннеля. Для настройки туннеля на обоих концах туннеля должно быть установлено предпочтение туннеля. По умолчанию туннель MPLS-over-UDP предпочтительнее, чем туннель GRE. Если динамическая конфигурация туннеля существует, то она имеет приоритет перед полученным туннельным сообществом.

При конфигурировании динамического MPLS следующего перехода по UDP-туннелю необходимо учитывать следующие факторы:

  • Между устройствами PE должен быть настроен сеанс IBGP.

  • Переключение между динамическими инкапсуляциями туннеля на основе следующего перехода (UDP и GRE) допускается, что может повлиять на производительность сети с точки зрения поддерживаемых значений масштабирования IP-туннелей в каждом режиме.

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

  • Для однонаправленных туннелей MPLS UDP необходимо явно настроить декапсуляцию на основе фильтра MPLS-uDP на удаленном устройстве PE для пересылаемых пакетов.

  • При модуль маршрутизации-UDP MPLS переключение (GRES), а также флаги типа MPLS-туннеля uDP, совместимые с ISSU и NSR.

  • MPLS туннели свыше UDP поддерживаются на виртуальных MX (vMX) в режиме Lite.

  • MPLS туннели с поддержкой динамического создания туннелей GRE на основе новых переходов IPv4-mapped-IPv6.

  • MPLS туннели свыше UDP поддерживаются в области межсерийной связи с contrail, где от contrail vRouter к шлюзу MX создаются туннели MPLS over UDP. Для этого в маршруте от маршрутизатора серия MX маршрутизатора contrail vRouter требуется объявление следующего сообщества:

    В данный момент времени в contrail vRouter поддерживается только один тип туннеля — динамические туннели GRE на основе следующего перехода, MPLS туннели over UDP или VXLAN.

  • Следующие функции не поддерживаются в конфигурации динамического MPLS перехода через UDP:

    • Автоматическая сетвая сетка RSVP

    • Простая конфигурация туннелей IPV6 GRE и UDP

    • Логические системы

Топологии

Рис. 1 иллюстрирует сценарий vpn уровня 3 по динамическим туннелям MPLS-UDP. Устройства клиентское граничное устройство (CE) CE1 и CE2 подключаются к устройствам поставщиков edge (PE) PE1 и PE2 соответственно. Устройства PE подключены к устройству поставщика (Устройству P1), и внутренний сеанс BGP (IBGP) соединяет два устройства PE. Между устройствами PE настраивается динамический двухнаправленный туннель MPL-over-UDP на основе динамического перехода.

Рис. 1: Динамические MPLS туннели свыше UDPДинамические MPLS туннели свыше UDP

Туннель MPLS по UDP обрабатывается следующим образом:

  1. После настройки MPLS-UDP создается маршрут маски назначения туннеля со следующим переходом, составным для туннеля в таблице маршрутов inet.3. Этот маршрут IP-туннеля удаляется только при удалении конфигурации динамического туннеля.

    Атрибуты туннельного составного следующего перехода включают в себя следующие:

    • Если составный следующий переход VPN уровня 3 отключен — исходный и адрес назначения, строка инкапсуляции и метка VPN.

    • Когда включены составные следующий переход VPN уровня 3 и назначение меток для каждого префикса VPN — адрес источника, адрес назначения и строка инкапсуляции.

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

  2. Устройства PE связаны при помощи сеанса IBGP. Следующий переход IBGP к удаленному BGP является протоколом next hop, который разрешен с помощью маршрута маски туннеля со следующим туннельным переходом.

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

  4. Туннельный составный следующий переход используется для перенапряжия следующих переходов по косвенным следующим переходам.

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

интерфейс командной строки быстрой конфигурации

Чтобы быстро настроить этот пример, скопируйте следующие команды, введите их в текстовый файл, удалите все разрывы строки, измените все данные, необходимые для настройки сети, скопируйте и введите команды в интерфейс командной строки на иерархии, а затем войдите из режима [edit]commit конфигурации.

CE1

CE2

PE1

P1

PE2

Процедуры

Пошаговая процедура

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

Настройка устройства PE1:

  1. Настройте интерфейсы устройств, включая интерфейс обратной связи устройства.

  2. Настройте статический маршрут для маршрутов устройства PE1 с устройством P1 в качестве места назначения следующего перехода.

  3. Настройте ID-маршрутизатор и номер автономной системы для устройства PE1.

  4. (только серия PTX) Настройте управление политиками для разрешения динамического MPLS туннельного маршрута по выбранным префиксам MPLS-over-UDP.

  5. (только серия PTX) Настройте политику inet-import для изменения динамических маршрутов назначения туннеля.

  6. Настройте равноправную связь IBGP между PE-устройствами.

  7. Настройте OSPF на всех интерфейсах Устройства PE1, за исключением интерфейса управления.

  8. В настройках динамического туннеля GRE на устройстве PE1 в следующем переходе.

    Прим.:

    Этот шаг необходим только для иллюстрации различий в реализации между динамическими туннелями GRE на MPLS на основе следующих переходов и туннелем с более-UDP.

  9. Настройте параметры MPLS-uDP с Device PE1 на Device PE2.

  10. Настройте экземпляр маршрутки VRF на устройстве PE1 и другие параметры экземпляра маршрутов.

  11. В BGP экземпляра маршрутки для пиринга с устройством CE1 в включается настройка.

Результаты

В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show routing-options и show protocolsshow routing-instances команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.

После настройки устройства войдите в commit режим конфигурации.

Проверки

Подтвердим, что конфигурация работает правильно.

Проверка соединения между pe-устройствами

Цель

Проверьте состояние BGP одноранговых устройств между Device PE1 и Device PE2, а также маршруты BGP, полученные от устройства PE2.

Действий

В рабочем режиме запустите show bgp summary команды show route receive-protocol bgp ip-address table bgp.l3vpn.0 и команды.

Смысл
  • В первых выходных данных состояние BGP сеансе – это означает, что сеанс в состоянии "up" и устройства Establ PE равноправы.

  • Во втором выводе устройство PE1 изучило два BGP от Устройства PE2.

Проверка динамических туннельных маршрутов на устройстве PE1

Цель

Проверьте маршруты в таблице маршрутов inet.3 и сведения о динамической базе данных туннеля на устройстве PE1.

Действий

В рабочем режиме show route table inet.3 запустите show dynamic-tunnels database terse команды , show dynamic-tunnels databaseshow dynamic-tunnels database summary и.

Смысл
  • В первом выводе, поскольку устройство PE1 настроено с помощью туннельного MPLS UDP, туннельный составный маршрут создается для записи маршрутной таблицы маршрутов inet.3.

  • В остальных выходных данных туннель MPLS-uDP с типом инкапсуляции туннеля, параметрами туннеля следующего перехода и состоянием туннеля.

Проверка динамических туннельных маршрутов на устройстве PE2

Цель

Проверьте маршруты в таблице маршрутов inet.3 и сведения о динамической базе данных туннеля на устройстве PE2.

Действий

В рабочем режиме запустите show route table inet.3 команды и show dynamic-tunnels database terse команды.

Смысл

Выходные данные показывают MPLS туннельное создание по UDP и ID следующего перехода назначен в качестве интерфейса следующего перехода, подобно устройству PE1.

Проверка того, что у маршрутов есть ожидаемый флаг Indirect-Next-Hop

Цель

Убедитесь, что устройства PE1 и Device PE2 настроены для сохранения косвенного следующего перехода в состоянии перенастройки следующего перехода на модуль передачи пакетов таблица переадресации.

Действий

В рабочем режиме запустите show krt indirect-next-hop команду на устройствах PE1 и Device PE2.

Смысл

Выходные данные показывают, что между устройствами PE создается динамический туннель MPLS-over-UDP.

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

Для устранения неполадок динамических туннелей на основе следующих переходов см.:

Команды для устранения неполадок

Проблема

Конфигурация динамических туннелей MPLS-uDP на основе следующего перехода не действует.

Решение

Для устранения неполадок при настройке туннеля MPLS-over-UDP используйте следующие команды в traceroute[edit routing-options dynamic-tunnels] иерархии еагитации:

  • traceoptions file file-name

  • traceoptions file size file-size

  • traceoptions flag all

Например:

Обзор защиты от спуфинга для динамических туннелей на основе следующего перехода

В связи с тем, что масштабные IP-туннели в центрах обработки данных развертываются, необходимо принять дополнительные меры безопасности, которые позволяют пользователям ограничивать вредоносный трафик от взлома виртуальных компьютеров (VM). Одной из возможных атак является влияние трафика в произвольный клиентский VPN с скомпрометированного сервера через маршрутизатор шлюза. В таких случаях проверки с спуфингом в IP-туннелях гарантируют, что только легитимные источники вводят трафик в центры обработки данных из назначенных IP-туннелей.

Динамические IP-туннели на основе следующего перехода создают туннельный составный следующий переход для каждого динамического туннеля, созданного на устройстве. Поскольку динамические туннели на основе следующего перехода удаляют зависимость от физических интерфейсов для каждого настроенного нового динамического туннеля, настройка динамических туннелей на основе следующего перехода предоставляет преимущество масштабирования по сравнению с числом динамических туннелей, которые можно создать на устройстве. Начиная с Junos OS 17.1, возможности борьбы с спуфингом для динамических IP-туннелей на основе следующего перехода обеспечиваются для динамических туннелей на основе следующих переходов. Это усовершенствование позволяет предотвратить внедрение трафика в произвольный клиентский VPN с скомпрометированного сервера через маршрутизатор шлюза.

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

Рис. 2 иллюстрирует пример топологии с требованиями к защите от спуфинга.

Рис. 2: Защита от спуфинга для динамических туннелей на основе следующего переходаЗащита от спуфинга для динамических туннелей на основе следующего перехода

В данном примере маршрутизатор шлюза – это маршрутизатор G. Маршрутизатор G имеет две СЕТИ VPN — зеленый и синий. Два сервера, сервер А и сервер B, могут достичь зеленых и синих VPN на маршрутизаторе G через динамические туннели T1 и T2 на следующем переходе, соответственно. Несколько хостов и виртуальных компьютеров (P, Q, R, S и T), подключенных к серверам, могут достигать VPN через маршрутизатор шлюза, маршрутизатор G. Маршрутизатор G имеет виртуальные таблицы маршрутов и переадранки (VRF) для зеленых и синих VPN, каждая из которых заполнена информацией о доступности виртуальных машин в этих VPN.

Например, в vpn Green маршрутизатор G использует туннель T1 для достижения хоста P, туннель T2 для доступа к хостам R и S, а балансировка нагрузки между туннелями T1 и T2 проводится для достижения многоканального хоста Q. В vpn Blue маршрутизатор G использует туннель T1 для достижения хостов P и R, а туннель T2 – для доступа к хостам Q и T.

Проверка проходит для обратной переадментки пути, когда:

  • Пакет поступает от законного источника в назначенном туннеле.

    Хост P в VPN Green отправляет пакет хосту X с помощью туннеля T1. Поскольку маршрутизатор G может достичь хоста P через туннель T1, он позволяет пакету проходить и переадреть пакет на хост X.

  • Пакет поступает из многоканального источника в назначенных туннелях.

    Хост Q в vpn Green многоканален на серверах А и В, и может достичь маршрутизатора G через туннели T1 и T2. Хост Q отправляет пакет хосту Y по туннелю T1, а пакет – хосту X, использующего туннель T2. Поскольку маршрутизатор G может достичь хоста Q через туннели T1 и T2, он разрешает пропускать пакеты и переадреав их хостам Y и X, соответственно.

VPN уровня 3 по умолчанию не имеют включенной защиты от спуфинга. Чтобы включить анти спуфинг для динамических туннелей на основе следующего перехода, включим утверждение ip-tunnel-rpf-check на [edit routing-instances routing-instance-name routing-options forwarding-table] уровне иерархии. Проверка переадранки обратного пути применяется только к экземпляру маршрутов VRF. По умолчанию установлен режим, в котором пакет, который приходит от источника в ненастроещенном туннеле, strict не проходит проверку. Режим может быть установлен как , где не удается проверить обратную переадментационную маршрутизию, когда пакет поступает от ip-tunnel-rpf-checkloose несущестующего источника. Дополнительный фильтр брандмауэра можно настроить в соответствии с утверждением для подсчета и регистрации пакетов, которые не удалось проверить пересылку по ip-tunnel-rpf-check обратному пути.

В следующем примере выходных данных показана конфигурация по борьбе с спуфингом:

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

  • Защита от спуфинга может быть включена только для туннелей IPv4 и трафика данных IPv4. Возможности защиты от спуфинга не поддерживаются в туннелях IPv6 и трафике данных IPv6.

  • Анти-спуфинг для динамических туннелей на основе следующих переходов может обнаружить и предотвратить взлом виртуальной машины (проверку переад через внутренний исходный обратный путь), но не скомпрометированного сервера, который является подменой меток.

  • IP-туннели на основе следующего перехода могут исходить и заканчиваться в таблице маршрутов inet.0.

  • Защита от спуфинга эффективна, когда экземпляр маршрутов VRF имеет интерфейсы с коммутационными метами (LSIS) (с использованием) или интерфейсы виртуального туннеля vrf-table-label (VT). При per-next-hop метке экземпляра маршрутов VRF защита от спуфинга не поддерживается.

  • Применимо rpf fail-filter только к внутреннему пакету IP.

  • Включение проверок спуфинга не влияет на ограничение масштабирования динамических туннелей на устройстве на основе следующего перехода.

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

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

  • При модуль маршрутизации переключения (GRES) и обновления программного обеспечения на сервисе (ISSU) поддерживается защита от спуфинга.

Примере: Настройка защиты от спуфинга для динамических туннелей на основе следующего перехода

В данном примере показано, как настраивать проверки переадности обратного пути для экземпляра виртуальной маршрутной и переадранной (VRF) маршрутов, чтобы обеспечить защиту от спуфинга для динамических туннелей на основе следующего перехода. Проверки проверяют, что легитимные источники вводят трафик через назначенные им IP-туннели.

Требования

В данном примере используются следующие аппаратные и программные компоненты:

  • Три серия MX с MCS, каждый из которых подключен к хост-устройству.

  • Junos OS версии 17.1 или более поздней версии, запущенной на одном или всех маршрутизаторах.

Перед началом работы:

  • В включается настройка служб туннеля на гибком концентраторе PIC.

  • Настройте интерфейсы маршрутизатора.

  • Настройте ИД маршрутизатора и назначьте номер автономной системы для маршрутизатора.

  • Установить внутренний BGP (IBGP) с конечными точками туннеля.

  • Настройте RSVP на всех маршрутизаторах.

  • Настройте OSPF или любой другой протокол внутреннего шлюза на всех маршрутизаторах.

  • Настройте два динамических IP-туннеля на основе следующего перехода между двумя маршрутизаторами.

  • Настройте экземпляр маршрутки VRF для каждого подключения маршрутизатора к хосту.

Обзор

Начиная с Junos OS 17.1, возможности защиты от спуфинга добавляются в динамические IP-туннели на основе следующего перехода, где выполняются проверки трафика, передающегося через туннель к экземпляру маршрутов с использованием обратного пути переадребовки в модуль передачи пакетов.

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

В экземплярах маршрутов VRF поддерживается анти спуфинг. Чтобы включить анти спуфинг для динамических туннелей, включим утверждение ip-tunnel-rpf-check на [edit routing-instances routing-instance-name routing-options forwarding-table] иерархическому уровне.

Топологии

Рис. 3 иллюстрирует пример топологии сети с включенной защитой от спуфинга. Маршрутизаторы R0, R1 и R2 подключены к хостам Host0, Host1 и Host2 соответственно. Два общих инкапсуляции маршрутизации (GRE) динамические туннели на основе следующего перехода ( Tunnel 1 и Tunnel 2) соединяют маршрутизатор R0 с маршрутизаторами R1 и R2 соответственно. Экземпляр маршрутки VRF работает между каждым маршрутизатором и подключенными к его хостам устройствами.

Рис. 3: Защита от спуфинга для динамических туннелей на основе следующего переходаЗащита от спуфинга для динамических туннелей на основе следующего перехода

В качестве примера три пакета (пакеты A, B и C) принимаются на маршрутизаторе 0 от маршрутизатора 2 через динамический туннель GRE (Туннель 2) на основе следующего перехода. IP-адрес источника этих пакетов: 172.17.0.2 (Пакет A), 172.18.0.2 (Пакет B) и 172.20.0.2 (Пакет C).

IP-адрес источника пакетов A и B принадлежит хостам 2 и Хосту 1 соответственно. Пакет C является несущестным туннелем-источником. В данном примере назначенным туннелем является Туннель 2, а неназначенным туннелем является Туннель 1. Поэтому пакеты обрабатываются следующим образом:

  • Packet A-Поскольку источник приходит из назначенного туннеля (туннель 2), пакет A проходит проверку переадментменты обратного пути и обрабатывается для переададментки через туннель 2.

  • Packet B- Поскольку источник идет из туннеля 1, который является неудаваемым туннелем, по умолчанию пакет B не может быть перенаправл по обратному пути при проверке в режиме strict. Если включен свободный режим, пакет B разрешен для переададации.

  • Packet C— Поскольку источник является несущестным источником туннеля, пакет C не может быть перенаправлен по обратному пути, и пакет не передается.

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

интерфейс командной строки быстрой конфигурации

Чтобы быстро настроить этот пример, скопируйте следующие команды, введите их в текстовый файл, удалите все разрывы строки, измените все данные, необходимые для настройки сети, скопируйте и введите команды в интерфейс командной строки на иерархии, а затем войдите из режима [edit]commit конфигурации.

Маршрутизатор М0

Маршрутизатор М1

R2

Процедуры

Пошаговая процедура

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

Для настройки маршрутизатора 0:

  1. Настройте интерфейсы маршрутизатора 0, включая интерфейс обратной связи.

  2. Назначьте маршрутизатору ID и номер автономной системы для маршрутизатора М0.

  3. Настройте пиринг IBGP между маршрутизаторами.

  4. Настройте OSPF на всех интерфейсах маршрутизатора М0, за исключением интерфейса управления.

  5. Настройте RSVP на всех интерфейсах маршрутизатора М0, за исключением интерфейса управления.

  6. В настройках динамического туннеля GRE на маршрутизаторе М0 в следующем переходе.

  7. Настройте параметры динамического туннеля GRE от маршрутизатора М0 к маршрутизатору М1.

  8. Настройте параметры динамического туннеля GRE от маршрутизатора М0 к маршрутизатору М2.

  9. Настройте экземпляр виртуальной маршрутной и forwarding (VRF) на маршрутизаторе М0 и назначьте интерфейс, соединяющий хост 1 с экземпляром VRF.

  10. Настройте внешний сеанс BGP host 1 для экземпляра маршрутов VRF.

  11. Настройте защиту от спуфинга для экземпляра маршрутов VRF на маршрутизаторе М0. Таким образом, включается проверка переадречений по обратному пути для динамических туннелей на основе следующего перехода (T1 и T2) на маршрутизаторе 0.

Результаты

В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show routing-options и show protocolsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.

Проверки

Подтвердим, что конфигурация работает правильно.

Проверка базовой конфигурации

Цель

Проверьте состояние OSPF равноправных BGP между маршрутизаторами R0 и маршрутизаторами R1 и R2.

Действий

В рабочем режиме запустите show ospf neighbor команды show bgp summary и команды.

Смысл

Сеансы OSPF BGP запущены между маршрутизаторами R0, R1 и R2.

Проверка конфигурации динамического туннеля

Цель

Проверьте состояние динамических туннелей GRE на основе следующего перехода между маршрутизаторами R0 и маршрутизаторами R1 и R2.

Действий

В рабочем режиме запустите show route table inet.3 команды и show dynamic-tunnels database terse команды.

Смысл

Два динамических туннеля GRE на следующем переходе (Туннель 1 и туннель 2) находятся в активном диапазоне.

Проверка конфигурации защиты от спуфинга

Цель

Убедитесь, что на экземпляре маршрутки VRF на маршрутизаторе М0 включена проверка переадранки обратного пути.

Действий

В рабочем режиме запустите show krt table VPN1.inet.0 detail .

Смысл

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

Обзор динамической локализации туннеля на основе следующего перехода

Динамические туннели на основе следующего перехода включают общие туннели инкапсуляции маршрутизации (GRE) и туннели MPLS-через UDP. Эти туннели предоставляют преимущество масштабирования по сравнению с туннелями на основе интерфейса. Однако, в отличие от туннелей на основе интерфейса, динамические туннели на основе следующего перехода не имеют привязки по своей сути, когда информация о переадностике туннелей распределяется на пакеты механизмов перенавания (PFEs) на каждую линеевую карту устройства. Это ограничивает максимальное число туннелей, поддерживаемых устройством, до пропускной способности туннеля одной лиевой карты. С помощью поддержки локализации можно настроить динамическую локализацию туннеля на основе следующего перехода для создания сведений о переадментации только на PFE линеестойной карты, назначенной якорным PFE. PFEs на других картах линии на устройстве имеют информацию о состоянии перенаправки, чтобы направить пакеты на якорный PFE. Это обеспечивает преимущество масштабирования за счет увеличения максимального количества туннелей, поддерживаемых устройством.

Преимущества динамической локализации туннеля на основе следующего перехода

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

Случаи использования динамической локализации туннеля на основе следующего перехода

  • Шлюзы IPsec, на хосте нескольких ms-MPC, используются для оканки туннелей IPSec и требуются для поддержки средней нагрузки. Эта поддержка зависит от использования динамических туннелей на основе следующего перехода, когда достигается предел масштабирования устройства. В связи с локализацией динамических туннелей на основе следующих переходов максимальное число поддерживаемых туннелей увеличивается, что позволяет устройству размещать больше туннелей за счет дополнительных переходов в структуре.

  • Шлюзам Интернет или VPN, таким как виртуальные общедоступные облако обработки данных, необходимо, чтобы шлюзы связывались с большим количеством серверов. Серверы центров обработки данных можно достичь через динамические туннели на основе следующих переходов. Свойство динамических туннелей, не закрепленное в якорях, ограничивает общее число масштабирования устройства. На шлюзах есть несколько многоадрастных многопровайных мобильных систем (MPC) с увеличенными требованиями к трафику. При локализации динамических туннелей на основе следующих переходов туннели могут распространяться по каналам MPC, что способствует увеличению числа масштабирования туннелей.

Обработка трафика с локализацией динамических туннелей на основе следующих переходов

С помощью поддержки локализации динамическое состояние туннеля на основе следующего перехода локализовано в якорной модуль передачи пакетов, а у другого модуль передачи пакетов состояние туннеля для управления трафиком до якоря туннеля.

Рис. 4 иллюстрирует путь переад через динамические туннели на основе следующего перехода без локализации.

Рис. 4: Путь переад частью динамических туннелей в следующем переходе без локализацииПуть переад частью динамических туннелей в следующем переходе без локализации

Рис. 5 иллюстрирует путь переададации динамических туннелей на основе следующего перехода с локализацией.

Рис. 5: Путь переад пути динамических туннелей следующего перехода с локализациейПуть переад пути динамических туннелей следующего перехода с локализацией

Настройка локализации динамических туннелей на основе следующего перехода

Поддержку локализации можно настроить для вновь созданных динамических туннелей на основе следующего перехода или для существующих не локальных динамических туннелей.

Настройка локализации для динамических туннелей на основе нового перехода

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

  1. Создание динамических профилей туннеля.

    Динамический профиль туннеля определяет тип туннеля и тип модуль передачи пакетов якоря. Для локализации динамических туннелей можно создать несколько динамических профилей туннеля. Значения динамического типа туннеля могут быть GRE, UDP или BGP SIGNAL.

    Хотя BGP-SIGNAL не является допустимым типом туннеля, при назначении BGP SIGNAL в качестве типа туннеля, туннели, созданные из BGP-сигнальных атрибутов, локализованы. При использовании BGP SIGNAL тип туннеля принимается на основе типа, объявленного BGP TLV. BGP-SIGNAL всегда являются туннелями на основе следующих переходов. Туннели GRE, созданные динамически BGP-SIGNAL, всегда имеют следующий переход, даже если пользователь вручную настраивает туннели, созданные GRE для использования IFLs.

    Якорное модуль передачи пакетов является ликерной картой якорного модуль передачи пакетов, например, pfe-x/y/0. Эти сведения можно просмотреть из show interfaces terse pfe* выходных данных команды.

    Sample Configuration:

  2. Связывание динамического профиля туннеля со списком префиксов.

    Настройка политики с помощью действия связывает динамический туннель со списком dynamic-tunnel-attributes префиксов. Действие политики позволяет создавать туннель с указанными атрибутами для любых условий совпадения, таких как диапазон префиксов, сообщество или исходный адрес BGP маршрутов и так from далее.

    Sample configuration:

  3. Включая политику туннеля в рамках таблица переадресации экспорта.

    После настройки политики она включается в таблица переадресации экспорта для парсинга политики.

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

    Sample configuration:

Настройка локализации существующих динамических туннелей на основе следующих переходов

ОСТОРОЖНО:

Изменение динамических атрибутов туннеля может привести к сбою FPC из-за высокой загруженности памяти. Поэтому перед настройкой локализации рекомендуется деактивировать конфигурацию динамических туннелей.

Чтобы обновить атрибуты туннеля для существующих динамических туннелей на основе следующих переходов, необходимо выполнить следующее:

  1. Деактивировать dynamic-tunnels конфигурацию на [edit routing-options] уровне иерархии.

    Sample configuration:

  2. При необходимости измените атрибуты туннеля.

  3. Активируйте dynamic-tunnels конфигурацию на [edit routing-options] уровне иерархии.

    Sample configuration:

Для настройки локализации существующих не локальных динамических туннелей на основе следующего перехода:

ОСТОРОЖНО:

Внесение изменений в конфигурацию локализации для существующих не локальных динамических туннелей на основе следующего перехода может привести к сбою FPC из-за высокой загруженности памяти. Поэтому перед настройкой локализации рекомендуется деактивировать конфигурацию динамических туннелей.

  1. Деактивировать dynamic-tunnels конфигурацию на [edit routing-options] уровне иерархии.

  2. Создайте профиль атрибутов туннеля и добавьте политику для локализации динамических туннелей подобно новым динамическим туннелям на основе следующих переходов.

  3. Активируйте dynamic-tunnels конфигурацию.

Устранение неполадок локальных динамических туннелей на основе следующего перехода

При локализации динамических туннелей на основе следующих прыжков составные следующие переходы туннеля связаны с модуль передачи пакетов ID. Следующие утверждения конфигурации traceroute на иерархическом уровне помогают при устранении неполадок [edit routing-options] локальных динамических туннелей:

  • dynamic-tunnels traceoptions flag all— Отслеживание создания и удаления туннеля в DTM.

  • resolution traceoptions flag tunnel— Отслеживание операций разреша мне BGP маршруту.

  • forwarding-table traceoptions flag all— отслеживают туннели, отправленные в ядро;

  • traceoptions flag all- Отслеживание процесса обучения маршрутов.

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

  1. show route prefix extensive-Чтобы получить косвенный следующий переход.

    Например:

  2. show krt indirect-next-hop index indirect-next-hop detail-Чтобы проверить, нет ли модуль передачи пакетов якоря в подробном выводе непрямого следующего перехода.

    Например:

Неподтверченные функции локализации динамических туннелей на основе следующего перехода

Junos OS не поддерживает локализацию для динамических туннелей на основе следующего перехода:

  • Цепные составные следующие переходы на [edit routing-options forwarding-table chained-composite-next-hop ingress l3vpn] уровне иерархии.

  • Якорная модуль передачи пакетов отказоустойчивость.

    При локализации динамические туннели на основе следующего перехода не поддерживают отказоустойчивость. После локализации динамических туннелей на основе следующих переходов якорный механизм переададации пакетов становится единым объектом для обработки любого туннеля на устройстве. Хотя отказоустойчивость якорного пакета forwarding Engine не поддерживается, для шлюзов избыточность на шлюзе гарантирует, что при переходе на резервный шлюз должен быть передан трафик, на который делегирован туннельный составный следующий переход. Процесс протокола маршрутизации отслеживает состояние ядер packer Forwarding Engine и BGP всех маршрутов, указывая на составный туннель следующих переходов, закрепленных на этом механизме переадментации Packer.

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

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

  • IPv6 не поддерживается при локализации динамических туннелей на основе следующих переходов.

  • При локализации эта команда не отображает точную сводку туннелей, если состояние якорной линии модуль передачи пакетов show dynamic-tunnels database summary не работает. В качестве обходного решения можно использовать выходные show dynamic-tunnels database данные команд show dynamic-tunnels database terse и команды.

Обзор динамического туннеления на основе следующих переходов с использованием инкапсуляции IP-over-IP

SUMMARY 

Преимущества

Туннеля IP-over-IP предоставляет следующие преимущества:

  • Alternative to MPLS over UDP- Можно использовать в качестве альтернативы туннелю MPLS по UDP-туннелю, чтобы обеспечить IP-службу, в которой есть выделенное устройство для обслуживания.

  • Ability to steer specific traffic- Обеспечивает ровную миграцию при совместном MPLS и IP-сетях, поскольку маршруты можно отфильтровать для управления конкретным трафиком через IP-туннели в противоположность MPLS туннелям.

  • Ability to support tunnels at increasing scale— Динамическое создание туннеля с BGP плоскость управления может содействовать созданию туннеля в крупных масштабах.

Что такое динамическое туннеление на основе IP-over-IP на основе следующего перехода?

IP-сеть состоит из edge-устройств и ядер. Чтобы добиться более масштабирования и надежности среди этих устройств, необходимо логически изолировать сеть ядра от внешней сети, с которую граничные устройства взаимодействуют, используя инкапсуляцию наложения.

Начиная Junos OS выпуске 20.3R1, мы поддерживаем инкапсуляцию IP-over-IP, чтобы облегчить конструкцию НАложения IP через IP-сеть. Ip over IP основывается на следующей инфраструктуре на основе переходов, которая поддерживает более высокий масштаб. Эта функция поддерживает инкапсуляцию IPv4 полезной нагрузки IPv6 и IPv4. Среди других поддерживаемых инкапсуляций наложения IP-over-IP инкапсуляция является единственным типом, который позволяет:

  • транзитные устройства для анализе внутренней полезной нагрузки и использования внутренних полей пакета для вычисления hash

  • клиентское граничное устройство устройствам по маршруту трафика в туннель и из него без каких-либо сокращений пропускной способности

На серия MX маршрутизаторах, daemon протокола маршрутизации (RPD) отправляет задаток инкапсуляции со составным следующим сообщением туннеля, а модуль передачи пакетов (PFE) находит адрес назначения туннеля и пересылает пакет. На серия PTX и QFX10000 маршрутизаторах RPD отправляет на туннель на модуль передачи пакетов полностью разрешенный следующий туннель на модуль передачи пакетов. BGP используется для распределения маршрутов и динамических туннелей сигнала.

На следующем рисунке изображена маршрутка трафика IPv4 или IPv6 с R-1 на R-5 через IP-туннель, установленный между R-2 и R-4:

Сшивание туннеля IP-over-IP

В Junos OS выпуска 21.3R1 мы вводим зашивание туннеля IP-over IP на MX240, MX480, MX960, PTX1000, PTX10008, PTX10016 и QFX10002. Эту функцию можно использовать для того, чтобы завершить туннель IP-over-IP на устройстве и инициировать другой туннель на этом же устройстве. Когда устройство получает пакет IP-over-IP, оно декапсулирует заглавную часть внешнего пакета, а также происходит просмотр внутреннего пакета. Заглавная часть внутреннего IP-пакета указывает на другой туннель того же устройства, где это же устройство снова инкапсулирует пакет другим загонком IP-over-IP.

Примере: Настройка динамических туннелей IP-over-IP на основе следующих переходов

SUMMARY Узнайте, как настроить следующие туннели на основе перехода с помощью инкапсуляции IP-over-IP.

Требования

В данном примере используются следующие аппаратные и программные компоненты:

  • 4 серия MX маршрутизаторы и 1 серия PTX маршрутизатор.

  • Junos OS версии 20.3R1 версии.

Обзор

Начиная Junos OS выпуске 20.3R1, мы поддерживаем инкапсуляцию IP-over-IP, чтобы облегчить конструкцию НАложения IP через IP-сеть. В данном примере показано установление однонастных туннелей IP-over-IP между устройствами со следующим переходом (PNH) протокола со статической конфигурацией и BGP протоколом.

Чтобы объяснить разницу в поведении между MX и PTX1000/PTX10000/QFX10000 устройствами, для этого был включен серия PTX (R2) маршрутизатор (R2). IBGP также настроен между R2 и R4, которые соединены по IP core, для обмена маршрутами и динамическими туннелями сигнала.

Топологии

На рис. 1 иллюстрируется сценарий использования IP-over-IP с 5 устройствами. В этой топологии R1 подключен к R2, а R5 подключен к R4. R2 является серия PTX устройством. R2 и R4 подключены к устройству R3 в центре.

В данном примере мы попытаемся обмениваться маршрутами от R1 к R5 и наоборот через динамические туннели IP-over-IP, установленные между устройствами R2 и R4. Маршруты, генерируемые из R1, экспортируются в R2, а маршруты из R5 экспортируются в R4 с помощью IS-IS политики экспорта. Можно настроить однонастный ТУННЕЛЬ IPIP-01 от R2 к R4 и другой туннельный туннель-02 от R4 к R2. Префиксы маршрутов, сгенерируемые в маске сетей назначения одноранговых устройств, используются для создания туннеля и потоков трафика в противоположном направлении маршрутов в туннеле.

Настройка динамических туннелей IP-over-IP со следующим переходом протокола

интерфейс командной строки быстрой конфигурации

Чтобы быстро настроить этот пример, скопируйте следующие команды, введите их в текстовый файл, удалите все разрывы строки, измените все данные, необходимые для настройки сети, скопируйте и введите команды в интерфейс командной строки на иерархии, а затем введите commit из режима [edit] конфигурации.

R1

R2

R3

R4

R5

Настройка динамических IP-туннелей со следующим переходом протокола

Пошаговая процедура
  1. Войдите в режим настройки устройств R1 и R5.

  2. Настройте основные требования к устройствам, таким как VLAN, family iso, интерфейсы устройств и адреса обратной связи. Маршруты создаются на адресах обратной связи.

  3. Настройте ID маршрутизатора и номер автономной системы (AS) для назначения IP-адресов маршрутизаторам и для BGP.

  4. Настройте IS-IS протоколов для обеспечения IGP. Маршруты экспортируются из R1 в R2 и R5 устройствам R4 с помощью IS-IS протоколом.

  5. Войдите в режим настройки на устройства R1 и commit R5.

  6. Перейдите в режим конфигурирований на R2 и R4, чтобы настроить их.

  7. Настройте основные требования к устройствам, таким как VLAN, family iso, MPLS, router interfaces и loopback addresses на R2 и R4.

  8. Настройте IBGP между R2 и R4.

  9. Настройте экспортную политику IS-IS на R2 и R4 с BGP экспорта на экспорт маршрутов от R1 к R2 и R5 к R4.

  10. Для доступности OSPF протокол между R2 и R4.

  11. Настройте однонастный динамический туннель IP-01 от R2 к R4 и Туннель-02 от R4 к R2.

  12. Настройте BGP и IS-IS политик на R2 и утверждение политики для перенастройки маршрутов от BGP и RIB inet.0 до полностью разрешенного следующего перехода (на устройстве R2-PTX).

  13. Войдите commit из режима настройки устройств R2 и R4.

  14. Настройте интерфейсы устройств VLAN, адреса обратной связи, family mpls, router-ID и номера автономной системы (AS).

  15. Для доступности OSPF протоколов на устройствах R3 и R2 и R4.

  16. Войдите commit из режима настройки на устройстве R3.

Результаты

Проверьте конфигурацию, проверив конфигурации ниже с устройств следующим образом:

Вот как можно проверить конфигурации устройства R2:

user@R2# show interfaces

user@R2# show routing-options

user@R2# show protocols

user@R2# show policy-options

Проверки

Проверка динамической туннельной базы данных
Цель

Для проверки информации динамической базы данных туннеля используйте show dynamic-tunnels database команду operational mode.

Действий
Смысл

Выходные данные показывают, что туннель IPoIP создан с инкапсуляцией туннеля между R2 (источник) и R4 (местом назначения) на устройстве R2, а другой туннель IPoIP установлен в туннельную инкапсуляцию между 192.168.0.21192.168.0.41 R4 (источник) и 192.168.0.41 R2 (местом 192.168.0.21 назначения) на устройстве R4.

Проверка таблицы маршрутов inet.3
Цель

Для проверки маршрутов, генерируемых по таблице inet.3, используйте show route table inet.3 команду operational mode.

Действий
Смысл

Выходные данные показывают, что R2 получил маршрут 192.168.0.41/32 от R4 через туннель IPIP.

Проверка BGP маршрутов, полученных и объявленных по туннелю
Цель

Для проверки BGP префиксов маршрутов, полученных и объявленных на R2 192.168.0.41 узел BGP, используйте show route receive-protocol bgp peer команды operational show route advertising-protocol bgp peer mode.

Действий
Смысл

Выходные данные показывают, что R2 получает маршруты от R5 с помощью BGP, а R2 рекламит или отправляет маршруты от R1.

Примере: Настройка туннеля IPoIP в среде MPLS с туннелем LDP, разрешенным через inet configuration.0 с использованием статической конфигурации

По умолчанию MPLS выше, чем IP. Например, если MPLS и LDP настроены среди R2, R3 и R4, где R2 достижим с R4 через LDP, маршруты от R2 будут разрешены через LDP, вместо IP-over-IP, из-за более высокого предпочтения.

Если вы хотите использовать определенный маршрут для разрешения за IP-over-IP вместо LDP, можно сделать это, создав таблицу inet проема, в которой IP-over-IP имеет более высокое предпочтение и настраивает BGP маршрут для устранения этого маршрута через таблицу inet200 вместо таблицы inet3. В следующем примере показано, как это сделать с помощью статической конфигурации.

интерфейс командной строки быстрой конфигурации

R2

R3

R4

Процедуры

Пошаговая процедура
  1. Настройте MPLS протоколов и протоколов LDP между R2 и R3 и R3 и R4.

  2. Настройте BGP протоколов для BGP импорта цветного туннеля IPIP и расширенного следующего перехода.

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

  4. Настройте параметр preference для назначения значения предпочтения.

  5. Настройте параметры политики, чтобы назначить цвет красного цвета и IPIP выбранному фильтру маршрута. Именно через параметры политики можно установить фильтры маршрутизатора для выбора маршрутов, которые необходимо разрешить через IP-over-IP, добавить к ней цвет и ipip.

  6. Настройте параметры политики сообщества для назначения инкапсуляции и добавления ipip community атрибутов к community red .

  7. Настройте параметры маршрутов и параметры политики для настройки динамического туннеля от R2 к R4 и R4 к R2 с конечными точками туннеля 192.168.0.41192.168.0.21 и.

  8. В commit режиме настройки войдите в R2, R3 и R4.

Результаты

Проверьте конфигурации, установленные для сценария 2 из режима конфигурации. Вот как можно проверить конфигурации на R2:

user@R2 # show protocols

user@R2 #show routing-options dynamic-tunnels Tunnel-01

user@R2 #show policy-options policy-statement ipip-tunnel-color

user@R2 # show policy-options policy-statement set-dynamic-tunnel-ep

user@R2 # show policy-options community ipip

user@R2 # show policy-options community red

Проверки

Проверка разрешения маршрута
Цель

Для проверки разрешения маршрутов в таблицах inet.3 и inet verify.0 используйте show route table inet.3show route table inetcolor.0 команды "operational mode".

Действий
Смысл

Выходные данные R2 показывают, что в таблице inet.3 маршрут получает разрешенный LDP из-за более высокого предпочтения, чем 192.168.0.41 IP-over-IP. С другой стороны, в только что созданной таблице inet аттестюет.0 маршрут решается через 192.168.0.41 туннель IP-over-IP с <c> присоединенным.

Выходные данные R4 показывают, что в таблице inet.3 маршрут решается LDP из-за более высокого предпочтения, но в таблице inetresolved.0 маршрут решается через 192.168.0.21192.168.0.21 туннель IP-over-IP с <c> присоединенным.

Проверка динамической туннельной базы данных
Цель

Для проверки динамического туннеля IP-over-IP, созданного маршрутами в таблице inet verify.0, используйте show dynamic-tunnels database terse команду operational mode.

Действий
Смысл

Выходные данные R2 показывают, что маршрут создал динамический туннель на 192.168.0.41 основе следующего перехода.

Выходные данные R4 показывают, что маршрут создал динамический туннель на 192.168.0.21 основе следующего перехода.

Проверка маршрутов следующих переходов
Цель

Для проверки всех следующих переходов маршрута, настроенного на разрешение с помощью IP-over-IP, необходимо получить команду e the show route 192.168.0.51/32 extensive expanded-nh operational mode.

Действий
Смысл

Выходные данные R2 указывают на расширенный следующий переход 192.168.0.51/32 маршрута. Поскольку R2 является маршрутизатором серия PTX, он отправляет протокол со следующим переходом и составный следующий переход с полностью разрешенным туннелем.

Выходные данные R4 указывают на расширенный следующий переход 192.168.0.11/32 маршрута. Поскольку R4 является серия MX маршрутизатором, он отправляет протоколу следующий переход и следующий переход через посредника.

Примере: Настройка туннеля IPoIP с туннелем LDP в облаке MPLS, разрешенного через inetтетехенд.0 с помощью BGP сигнализации

В среде MPLS с включенным LDP маршруты BGP маршруты проходят через LDP в таблице inet.3, поскольку MPLS обладает более высоким предпочтением, чем IP.

Если вы по-прежнему предпочитают, чтобы маршруты разрешались через IP-over-IP в MPLS среде, можно сделать это, создав таблицу inetго разметки.0, которая назначает более высокое предпочтение IP-over-IP и решению выбранных маршрутов через IP-over-IP. Чтобы включить эту функцию с помощью BGP, разрешение маршрута выполняется на удаленном конечном устройстве туннеля и с экспортной политикой, настроенной на удаленном устройстве, маршруты получают и объявляются с помощью BGP сигнализации. В этом примере показано, как настроить это с помощью BGP протокола.

Прим.:

Если после настройки туннеля IP-over-IP с использованием статической конфигурации LDP следует сохранить конфигурации MPLS и LDP на устройствах R2, R3 и R4 и удалить остальные статические конфигурации.

Если после настройки динамических туннелей IP-over-IP со следующим переходом для протокола следует настроить конфигурации MPLS и LDP на устройствах R2, R3 и R4, прежде чем настраивать следующие утверждения. Не забудьте применить export-tunnel-route политику, прежде чем применять export-isis ее с первого примера.

интерфейс командной строки быстрой конфигурации

R2

R4

Процедуры

Пошаговая процедура
  1. Войдите в режим настройки устройств R2 и R4.

  2. Настройте BGP протоколов на R2 и R4, чтобы включить туннель nexthop и экспорт маршрутов с удаленного о конце устройства.

  3. Настройте параметры маршрутов на М2 для создания туннеля между R2 и R4 и R4 для создания туннеля между R4 и R2 с цветовым значением и предпочтением, настроенным на 100.

  4. Настройте утверждение политики для экспорта маршрутов на R2 и R4 с помощью фильтра экспорта и добавьте атрибуты туннеля.

  5. Настройте параметры политики для добавления цвета туннеля, типа туннеля и удаленной точки на R2 и R4.

  6. Войдите commit из режима конфигурации.

Результаты

Проверить конфигурацию можно при помощи следующих команд show в режиме конфигурации. Вот как можно проверить конфигурации устройства R2:

user@R2# show routing-options

user@R2# show policy-options policy-statement export-tunnel-route

user@R2# show policy-options tunnel-attribute tunnle-attr-02

user@R2# show protocols bgp group iBGP

Проверки

Проверка BGP маршрутов

Цель

Проверьте маршруты, отправленные с помощью BGP протокол.

Действий

R2

R4

Смысл

В выходных данных показаны маршруты BGP.

Проверка полученных маршрутов

Цель

Проверьте маршруты, полученные через BGP с помощью следующих команд операционного режима.

Действий

R2

R4

Смысл

Выходные данные R2 и R4 указывают маршруты, полученные устройствами.

Проверка объявленных маршрутов

Цель

Проверьте маршруты, объявленные BGP посредством следующих команд режима эксплуатации.

Действий

R2

R4

Смысл

Выходные данные R2 и R4 указывают объявленные маршруты.

Таблица истории выпусков
Версия
Описание
19.2R1
Начиная с Junos выпуска 19.2R1, на серия MX маршрутизаторах с MCS и MCS, архитектуру несущей поддержки (CSC) можно развертывать с помощью MPLS-UDP туннелей, несущих MPLS по динамическим туннелям IPv4 UDP, установленным между устройствами PE несущей.
18.3R1
Начиная Junos OS 18.3R1, туннели MPLS Свыше UDP поддерживаются на серия PTX и серия QFX коммутаторах.
18.2R1
Начиная с Junos OS release 18.2R1, на маршрутизаторах серии PTX и QFX10000 с однонаправленными MPLS-UDP-туннелями, необходимо настроить удаленное устройство PE с входным фильтром для MPLS-over-UDP-пакетов, а также действия по декапсулированию IP- и UDP-задатков для перенаправления пакетов в обратном туннельном направлении.
17.4R1
Начиная с Junos OS выпусков 17.4R1, на серия MX маршрутизаторах сигнализируются динамические MPLS на основе UDP следующего перехода с использованием расширенных BGP инкапсуляции.
17.1R1
Начиная Junos OS 17.1, на серия MX с MMPC и MCS, увеличивается предел масштабирования MPLS туннелей, которые могут быть больше UDP.