Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
НА ЭТОЙ СТРАНИЦЕ
 

MPLS логические интерфейсы абонента Псевдопровода

Обзор логических интерфейсов подписчика Псевдопровода

Управление абонентом поддерживает создание абонентского интерфейса по точе MPLS псевдо-проводам. Возможность псевдонаправленного абонентского интерфейса позволяет поставщикам услуг расширить домен MPLS от сети агрегирования доступа до границы службы, где выполняется управление абонентом. Поставщики услуг могут воспользоваться преимуществами MPLS, таких как перенаправка, перенаправка и предоставление единой MPLS меток, при использовании одного псевдопровода для обслуживания большого количества абонентов DHCP и PPPoE в сети обслуживания.

Примечание:

Логические интерфейсы абонента Псевдопровода поддерживаются только на модульных концентраторах портов (MCS) с модульными интерфейсными картами Ethernet.

Псевдопровод – это туннель, который может быть MPLS VPN уровня 2 или 2-го уровня. Псевдопроводный туннель передает инкапсулированный трафик Ethernet с узла доступа (например, DSLAM или другого устройства агрегации) на маршрутизатор серия MX, на котором размещены службы управления абонентами. Завершение псевдо-туннельного канала на серия MX аналогично физическому завершении Ethernet и является точкой, на которой выполняются функции управления абонентом. Поставщик услуг может настроить несколько псевдо-каналов на основе DSLAM, а затем обеспечение поддержки большого количества абонентов на определенном псевдо-канале.

На рис. 1 показана MPLS, которая поддерживает управление абонентом.

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

Рис. 1. MPLS доступа к сети с помощью поддержки управления абонентами MPLS Access Network with Subscriber Management Support

На рис. 2 показан стек протоколов для логического интерфейса абонента псевдо-провода. Псевдопроводка – это виртуальное устройство, которое стек над логической точкой якоря туннеля на физическом интерфейсе (IFD) и поддерживает протокол цепи на уровне 2 (канал VPN 2-го уровня или канал 2-го уровня). Протокол 2-го уровня обеспечивает логические интерфейсы транспортных и сервисных служб и поддерживает семейство протоколов (IPv4, IPv6 или PPPoE).

Начиная с Junos OS выпусков 18.3R1, на серия MX с интерфейсами MPC и MIC поддержка абонентского интерфейса псевдопроводки через избыточные логические туннели введена в VPN уровня 3 и в многоадретных VPN проект-дейтаграмм. Ранее VPN 3-го уровня предоставляли поддержку услуг абонента псевдопровода только через логические туннельные интерфейсы, а эти интерфейсы использовали протоколы одноадревой маршрутной маршрутки. например OSPF или BGP. С помощью этой поддержки можно задать протокол мультиавтоматной маршрутки Protocol Independent Multicast (PIM) на псевдо-интерфейсах абонента, который завершается экземпляром виртуальной маршрутной и переадресной (VRF) маршрутов. Кроме того, увеличивается число масштабируемых устройств псевдопроводного логического интерфейса, что обеспечивает дополнительную поддержку отказоустойчивости для интерфейсов абонентов псевдопроводки на избыточных логических туннельных интерфейсах.

Примечание:

Если интерфейс службы абонента псевдопровода закреплен на избыточном логическом туннеле, член которого (или FPC) не существует, туннельный интерфейс отсоединим. В таких случаях псевдопроводные интерфейсы (физические и логические) также должны быть недоступны, но, однако, состояние логического интерфейса абонента псевдо-связи остается в состоянии up, хотя службы цепи уровня 2, такие как ping для клиентское граничное устройство (CE) устройства со стороны службы псевдоподдержки абонента, недоступны.

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

Рис. 2. Стек протоколов интерфейса абонента Псевдопровода Pseudowire Subscriber Interface Protocol Stack

Конфигурация псевдопроводки прозрачна для приложений управления абонентами и не влияет на пакетную нагрузку, которая используется для управления абонентом. Такие абонентские приложения, как DHCP и PPPoE, могут быть сложены на уровне 2 аналогично тому, как они находятся в стеке через физический интерфейс.

Начиная Junos OS версии 16.1R1 и поддерживаемых на стороне служб одного MPLS, а также не абонентского family inet family inet6 логического интерфейса.

Начиная Junos OS версии 16.1R1, Inline IPFIX поддерживается на стороне служб логического интерфейса MPLS абонента псевдопроводки.

Начиная с Junos OS выпусков 15.1R3 и 16.1R1 и более поздних, инкапсуляция CCC поддерживается на транспортной стороне MPLS логическим интерфейсом абонента псевдопроводки.

До Junos OS выпуска 19.1R1 только поддерживаемый тип инкапсуляции на абонентские интерфейсы псевдопроводки включают:

  • Транспортные логические интерфейсы — инкапсуляция перекрестного соединения (CCC).

  • Service logical interfaces:

    • Инкапсуляция Ethernet VPLS

    • Инкапсуляция моста VLAN

    • Инкапсуляция VLAN VPLS

Начиная Junos OS выпуске 19.1R1, дополнительные инкапсуляции добавляются в перенос псевдо-абонента и логические интерфейсы служб. Транспортный логический интерфейс поддерживает инкапсуляцию Ethernet VPLS и условия для завершения интерфейса на l2backhaul-vpn экземпляре маршрутизации. Логический интерфейс службы поддерживает перекрестную инкапсуляцию (CCC) и условия для завершения интерфейса в локально коммутацией каналов уровня 2.

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

Начиная Junos OS выпусков 15.1R3 и 16.1R1 и более поздних, распределенная защита отказ в обслуживании (DDoS) поддерживается на стороне служб на стороне MPLS абонента псевдопровода логического интерфейса.

Начиная Junos OS начиная 15.1R3 и 16.1R1 и более поздних выпусках, Policer and Filter поддерживаются на стороне служб со стороны MPLS псевдо-интерфейса абонента.

Начиная с Junos OS выпусков 15.1R3 и 16.1R1 и более поздних, точная статистика передачи на логическом интерфейсе поддерживается на стороне служб MPLS псевдо-интерфейсом абонента.

Начиная с Junos OS выпуска 17.3R1 и более поздних версий, поддержка избыточности тока якоря с контролем состояния обеспечивается для логического интерфейса абонента псевдо-wire с помощью избыточного логического интерфейса (rlt) в режиме активного резервного копирования. Это избыточность защищает доступ и опорный соединение от сбоев Якорного PFE (модуль передачи пакетов).

Обзор логических интерфейсов абонента Псевдоwire при якорной избыточности

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

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

Начиная Junos OS выпуска 17.3 и вовне, логические интерфейсы абонента псевдопроводки могут быть мгновенно настроены через начальный резервный логический интерфейс (rlt) в режиме active-backup. Кроме того, псевдо-провода устанавливаются через один логический туннельный интерфейс. Наиболее заметным преимуществом реализации логического интерфейса псевдо-провода абонента по сравнению с избыточными логическими туннельными интерфейсами является обеспечение избыточности основному пути переадресовки.

До Junos OS версии 18.3R1, можно указать не более 2048 устройств резервного логического туннельного интерфейса абонента псевдопровода для серия MX маршрутизатора. Начиная с Junos OS выпуска 18.3R1, на серия MX с интерфейсами MPC и MIC число устройств псевдо-резервного логического интерфейса увеличено до 7000 устройств для дополнительной поддержки отказоустойчивости.

Junos OS версии 17.3 также поддерживает улучшенную агрегированную инфраструктуру для модуль передачи пакетов обеспечения избыточности якорных тоок. Расширенная агрегированная инфраструктура требует как минимум одного контрольного логического интерфейса, который необходимо создать на избыточном логическом туннельном интерфейсе. Логические интерфейсы транспортных и сервисов, созданные для логического интерфейса абонента псевдо-связи, сложены на логическом интерфейсе управления на основе избыточного логического туннеля. Эта модель стека используется как для избыточных, так и для неотвеченных псевдопроводных абонентов логических интерфейсов.

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

  • Аппаратные сбои на модульном концентраторе PIC (MPC) или модульной карте интерфейсов (MIC).

  • Сбой MPC из-за отказа микроярса.

  • Административно отключение MPC или MIC.

  • Сбой питания на MPC или MIC.

На рис. 3 приводится подробная информация о стеке логического интерфейса абонента псевдо-wire через избыточный логический туннельный интерфейс.

Рис. 3. Логический интерфейс абонента Псевдопровода стек по избыточному интерфейсу логического туннеля Pseudowire Subscriber Logical Interface Stacking over Redundant Logical Tunnel Interface
Примечание:

Статический service ifl не стек по транспортному ifl при используется RLT.

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

Чтобы избежать потерь трафика и сеансов, можно с помощью конфигурирования конфигурации настроить защиту неотвекивтельных соединений для интерфейсов избыточных set interfaces rltX logical-tunnel-options link-protection non-revertive туннелей. С данной конфигурацией, при повторном соединении активного соединения трафик не возвращается на активный и по-прежнему перенанокается по резервному соединению. Таким образом, потери трафика или сеанса абонента нет. Также можно вручную переключить трафик из резервного соединения на активный с помощью request interface (revert | switchover) interface-name команды.

ОСТОРОЖНОСТЬЮ:

Ручная коммутаторная коммутаторная обработка трафика повеет потерю трафика.

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

  • Избыточный логический туннельный интерфейс позволяет 32-участнику логических физических туннельных интерфейсов. Однако логический интерфейс абонента псевдо-связи, который имеется на избыточном логическом интерфейсе туннеля, ограничивает число логических физических интерфейсов туннеля двумя.

Примечание:

Нельзя отключить основному избыточному логическому туннелю (rlt) интерфейсу или основному логическому (lt) интерфейсу, если псевдопровод закреплен на этом интерфейсе. Чтобы отключить интерфейс, который является его частью, сначала деактивировать псевдо-провод.

Начиная с Junos OS выпуска 18.4R1, поддержка линейного распределения однонаправленных сеансов обнаружения однонаправленной переадресации (BFD) распространяется на абонента псевдопровода через избыточные логические туннельные интерфейсы. Для абонента псевдо-провода по логическим туннельным интерфейсам интерфейсы закреплены на одном гибком концентраторе PIC (FPC), в результате чего по умолчанию поддерживается линейное распределение сеансов BFD на одном переходе. При псевдопроводных избыточных логических интерфейсах член логических туннельных интерфейсов может быть разбит на разных линеек. Поскольку адрес распределения не доступен для избыточных логических интерфейсов, распределение одно переходов BFD сеансов выполнялось в централизованном режиме перед Junos OS выпуском 18.4R1.

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

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

  1. После добавлении нового сеанса BFD он может быть закреплен либо на активном, либо на резервном FPC.

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

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

  3. При сбой активного FPC все сеансы BFD закрепляются на резервном FPC. Аналогично, если резервный FPC работает, все сеансы BFD закрепляются на активном FPC.

  4. Повторное закрепление сеанса BFD не запускается, когда активный FPC снова находится в сети.

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

Примечание:

Учитывайте следующее при поддержке линейного распределения сеансов BFD с одним переходом на абоненте псевдо-провода по логическим туннельным интерфейсам:

  • На FPC тип MPC 7e, при активации экземпляра маршрутов 7000, сеансы 7000 BGP должны быть установлены на интерфейсах абонентов псевдопровода, закрепленных на резервных логических туннельных интерфейсах.

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

Начиная с Junos OS выпуска 21.4R1 мы ввели CoS BNG на абонентском интерфейсе на псевдопроводе через активный резервный логический туннель (RLT) для абонентских приложений, таких как DHCP и PPPoE. Это CoS достигается путем предоставления узлов планирования для логических туннельных каналов. Для динамических интерфейсов, наборов интерфейсов, статических основных интерфейсов и динамических интерфейсов на основном канале RLT CoS распределяет узлы планирования для каждого канала в RLT, у которого есть несколько логических туннельных каналов в активном режиме. В случае целевых интерфейсов и целевых наборов интерфейсов, которые имеют первичные и резервные соединения, CoS распределяет узлы планирования на первичных и резервных соединениях для оптимизации использования узлов планирования. Трафик для абонентских интерфейсов, нацеленных на абонента, будет распределяться по всем основным соединениям LT, если CoS применяется на уровне абонента. Кроме того, трафик от любого абонента всегда обрабатывается одной модуль передачи пакетов.

На рис. 4 приводится подробная информация о родительских и родительских интерфейсах, используемых для четырехуровневой иерархии планировщика для доступа абонента. Динамические PPPoE IFL и динамические наборы IFL – это узлы-дети. Динамический ifL-set и динамический или статический узел uifl являются родительскими узлами.

Рис. 4. Четырехуровневая иерархия планировщика для доступа абонентов Four-level Scheduler Hierarchy for Subscriber Access

Для правильного функционирования целевых узлов в узле необходимо включить функцию целевого обеспечения для всех CoS узлов. Чтобы активировать "последние" узлы, настройте динамический профиль в ок. [edit interfaces ps1 auto-configure stacked-vlan-ranges dynamic-profile] Создайте динамический профиль с помощью настройки динамических целевых интерфейсов и наборов интерфейсов в [edit dynamic-profiles].

Вот пример конфигурации динамического профиля:

Также необходимо настроить сетевые службы на уровне иерархии, так как эта функция работает enhanced-ip [edit chassis] только в расширенном IP-режиме.

Режим активного-активного множественных соединений с использованием целевых алгоритмов для интерфейса RLT используется для распределения клиентов между различными членами RLT (первичными/вторичными парами ветвей). Адресная адресовка может применяться для динамических абонентов и наборов динамических интерфейсов. Алгоритм целей проходит через список псевдо-ifLs, связанных с парой соединений-участников, и выбирает первый псевдо IFL, который обладает достаточной емкостью на основе rebalance-subscriber-granularity настроенного.

Когда включена цель, абоненту назначен вес целевого значения по умолчанию в зависимости от типа клиента. Алгоритм целей использует вес распределения в псевдо-процессе выбора IFL и его дебитный вес – это вес, подсчитывающийся по отношению к назначенной псевдо IFL. Для всех объектов, кроме IFLset, распределение и дебитный вес одинаковы, и можно изменить это через профиль клиента. В случае ifLset, только атрибут распределения веса может быть изменен через профиль клиента, и debit weight для IFLset фиксированное на значении 0.

Таблица 1. Весовые значения по умолчанию для различных типов клиентов

Тип клиента

Вес распределения

Вес debit

Dvlan

1

1

IpDemux

1

1

PPP

1

1

IFLset

32

0

Настройка логического интерфейса абонента Псевдопровода

Логический интерфейс псевдонаправленного абонента прерывает псевдо-туннель MPLS серия MX от узла доступа к маршрутизатору, на котором выполняется управление абонентом, и позволяет выполнять на интерфейсе службы управления абонентами.

Для создания логического интерфейса абонента псевдо-связи:

  1. Укажите число псевдопроводных логических интерфейсов, которое может поддерживать маршрутизатор.
  2. Настройте псевдо-подключаемую абонентскую логическую интерфейсную устройство.
  3. Настройте транспортный логический интерфейс.
  4. Настройте сигнализацию для интерфейса абонента псевдо-провода. Можно использовать либо сигнализацию цепи уровня 2, либо сигнализацию VPN уровня 2. Два типа сигнализации для данного псевдо-провода являются взаимоисключающими.
    • Для настройки сигнализации цепи уровня 2 см. "Настройка сигнализации на уровне 2 для логических интерфейсов абонента Псевдопровода".

    • Для настройки сигнализации VPN на уровне 2 см. "Настройка сигнализации VPN уровня 2 для логических интерфейсов абонента Псевдопровода".

  5. Настройте логический интерфейс службы.
  6. Настройте устройство на основном интерфейсе.
  7. Настройте CoS параметры и классификацию BA.

    См. CoS обзор конфигурации для MPLS абонентские интерфейсы Псевдопроводки.

  8. (Необязательно) Связывать динамический профиль с логическим интерфейсом абонента псевдо-провода.

    Динамические профили DHCP, PPPoE, IP demux и VLAN можно связать с логическими интерфейсами псевдопроводного абонента. Поддержка аналогична обычной поддержке интерфейса Ethernet.

    Примечание:

    При использовании динамического профиля PPPoE для создания логического интерфейса абонента псевдо-связи через устройство demux-интерфейса динамический профиль должен явно указать правильное псевдо-устройство интерфейса, на котором создан интерфейс. Динамический профиль не создает интерфейс автоматически через интерфейсное устройство demux0, как в случае с интерфейсом VLAN demux.

  9. (Необязательно) Настройте поддержку набора интерфейсов для логических интерфейсов псевдо-провода абонента.
  10. (Необязательно) Логические интерфейсы стека PPPoE через псевдопроводное логическое устройство.
  11. (Необязательно) Поддержка балансировки нагрузки для абонентского трафика на интерфейсе псевдо-проводной связи (PS). См. "Настройка поддержки балансировки нагрузки для абонентского трафика".

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

Необходимо установить максимальное число устройств псевдопроводного логического интерфейса (псевдопроводных туннелей), которое маршрутизатор может использовать для логических интерфейсов абонента. Установка максимального количества также определяет имена интерфейсов псевдо-проводов. При последующей настройке интерфейсов необходимо указать имена интерфейсов в диапазоне от ps0 до ps (device-count - 1) .

Например, если установить максимальное количество устройств в значение 5, то можно настроить только интерфейсы ps0, ps1, ps2, ps3 и ps4.

До Junos OS версии 17.2R1, можно указать не более 2048 псевдопроводных логических интерфейсов устройств для серия MX маршрутизатора. Начиная с Junos OS выпуска 17.2R1, на серия MX с интерфейсами MPC и MIC, число масштабируемых устройств псевдопроводного логического интерфейса увеличено до 7000 устройств для обеспечения дополнительной поддержки отказоустойчивости.

Аналогичным образом, до Junos OS выпуска 18.3R1, можно было указать не более 2048 устройств псевдо-пути абонента с избыточным логическим туннелем (rlt) интерфейсом для серия MX маршрутизатора. Начиная с Junos OS выпуска 18.3R1, на серия MX с интерфейсами MPC и MIC количество устройств псевдо-резервного логического интерфейса увеличено до 7000 устройств для дополнительной поддержки отказоустойчивости.

Начиная с Junos OS выпуска 20.4R1, на MX2010 и MX2020 маршрутизаторах с линковой картой MX2K-MPC9E или MX2K-MPC11E можно определить до 18000 псевдо-логических интерфейсов.

PFE с максимально допустимым логическим интерфейсом, где размещено максимальное число устройств псевдо-связи, обеспечивает гибкость конфигурации, необходимую для особых случаев, которые могут возникнуть в сценариях на границе бизнеса. Однако можно превысить доступные ресурсы PFE, настроив дополнительные службы на портах устройств с псевдопроводным логическим интерфейсом. Чтобы поддерживать масштабную конфигурацию, убедитесь, что вы заполнили необходимое количество PPF для шасси и распределили псевдопроводные логические интерфейсы устройств через PPFE таким образом, чтобы убедиться, что ни один PFE не перегружен предполагаемой пиковой нагрузкой. В рамках планирования сети для конкретного развертывания, необходимо учитывать точную смесь распределения устройств псевдопроводного логического интерфейса и служб, связанных с устройствами.

Лучшие практики:

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

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

  1. Укажите, что нужно настроить псевдо-службу.
  2. Установите максимальное число устройств псевдопроводного логического интерфейса.

Настройка устройства логического интерфейса абонента Псевдопровода

Для настройки псевдопроводного логического интерфейса, которое маршрутизатор использует для логических интерфейсов абонентов, необходимо указать логический туннель, который обрабатывает прерывание псевдо-связи. Для обеспечения избыточности для членского логического туннеля можно также использовать резервные логические туннели. Можно настроить дополнительные параметры для интерфейсного устройства, такие как метод маркировки VLAN, MTU и неоконфигурированная поддержка ARP.

Примечание:

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

Для настройки интерфейса абонента псевдо-связи:

  1. Укажите, что нужно настроить псевдо-подписчика логического интерфейса.
    Примечание:

    Имена доступных интерфейсов определяются с помощью [edit chassis pseudowire-service device-count] утверждения. Имена, которые необходимо указать, должны быть в диапазоне от ps0 до (device-count - 1) ps. Если указать имя интерфейса вне этого диапазона, то псевдо-интерфейс не будет создан.

  2. Укажите логический туннельный интерфейс, который является якорной точкой для устройства псевдопроводного логического интерфейса. Якорной точкой должно быть lt устройство в формате lt-fpc/pic/port .
    ОСТОРОЖНОСТЬЮ:

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

    Примечание:

    Службы туннеля должны быть включены на интерфейсе, который является якорной точкой или членом lt соединения в резервном логическом туннеле. Чтобы включить службы туннеля, set chassis fpc slot-number pic pic-number tunnel-services bandwidth bandwidth используйте эту команду.

    Примечание:

    Нельзя отключить интерфейс логического (lt) логического (lt) логического или избыточного логического (rlt) интерфейса, если псевдо-канал закреплен на этом интерфейсе. Чтобы отключить интерфейс, который является его частью, сначала деактивировать псевдо-провод.

  3. (Необязательно) Укажите MAC-адрес для устройства псевдопроводного логического интерфейса.
    Примечание:

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

  4. (Необязательно) Укажите метод маркировки VLAN, используемый для устройства псевдопроводного логического интерфейса. Можно указать одиночное, двойное (стековое) маркировку, смешанную (гибкую) маркировку или без маркировки.

    Дополнительные сведения о маркировке VLAN см. в включение маркировки VLAN.

  5. (Необязательно) Укажите тип инкапсуляции для устройства псевдопроводного логического интерфейса.

    Начиная с Junos OS выпуска 19.1R1, можно настроить дополнительные инкапсуляции — Ethernet VPLS и инкапсуляцию на основе перекрестных подключений — для устройств логического интерфейса абонента переноса и обслуживания псевдо-подключений.

  6. (Необязательно) Укажите MTU для устройства псевдопроводного логического интерфейса. Если конфигурация маршрутизатора не MTU явно, то маршрутизатор использует значение по умолчанию, 1500.

    Дополнительные сведения см. MTU настройка протокола.

  7. (Необязательно) Укажите, что псевдопроводное логическое устройство интерфейса не отвечает на несповечные запросы ARP.
  8. (Необязательно) Укажите, что проверки переадресовки обратного пути выполняются для трафика на устройстве псевдопроводного логического интерфейса.

    Дополнительные сведения см. в "Сведениях об одноастерной RPF (маршрутизаторах)".

  9. Настройте дополнительные необязательные параметры для устройства псевдопроводного логического интерфейса, такие как description ,apply-groups, apply-groups-exceptи traceoptions.

Изменение якорной точки для устройства логического интерфейса абонента Псевдопровода

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

Для перемещения якорной точки между интерфейсами логических туннелей:

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

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

  1. Деактивировать стек псевдо-проводов и сфиксировать их. Для этого может потребоваться отсоединие абонентов, использующих псевдо-провода.

  2. Добавьте новый резервный интерфейс логического туннеля и сфиксировать.

    1. Создайте туннель и установите максимально допустимый номер устройств.

    2. Связывая каждый член логического туннеля с избыточным логическим туннелем.

      Примечание:

      Избыточные логические туннели требуют, чтобы члены группы были в режиме активного резервного копирования. Резервный логический туннель должен быть на другом FPC, чем активный логический туннель. Например, если активный туннель находится на FPC 3, резервный туннель должен быть на другом FPC, например FPC 4.

    3. Сфиксировать изменения.

  3. Измените якорь на деактивированном псевдопроводе на новый резервный логический туннельный интерфейс и сфиксировать.

  4. Повторно активировать стек псевдо-проводов и сфиксировать их.

Чтобы переместить точку якоря из избыточного логического туннельного интерфейса в логический туннельный интерфейс, который является членом резервного логического туннеля:

  1. Деактивировать стек псевдо-проводов; может потребоваться отсоединие всех абонентов, использующих псевдо-провода. Удалите резервный интерфейс логического туннеля и сфиксировать изменения.

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

  3. Повторно активировать стек псевдо-проводов и сфиксировать их.

Настройка логического интерфейса транспортного интерфейса для логического интерфейса абонента Псевдопроводки

В данной теме описывается настройка псевдо-интерфейса транспортного логического интерфейса. Псевдопроводное устройство может иметь только один транспортный логический интерфейс.

Псевдопроводное логическое устройство и связанные с ним псевдопроводные логические интерфейсы зависят от состояния логического устройства логического транспортного интерфейса, которое является каналом VPN 2-го уровня или каналом 2-го уровня.

Примечание:

Рекомендуется использовать для представления логического интерфейса транспортного unit 0 устройства для псевдопроводного устройства. Ненулевые номера единиц представляют логические интерфейсы служб, используемые для интерфейсов абонентов псевдо-каналов.

Для настройки псевдо-интерфейса транспортного логического интерфейса:

  1. Укажите, что нужно настроить псевдо-подписчика логического интерфейса.
  2. Укажите, что нужно настроить блок 0, который представляет транспортный логический интерфейс.
  3. (Необязательно) Укажите метод инкапсуляции для логического транспортного интерфейса.

    Начиная с Junos OS выпуска 19.1R1, можно настроить инкапсуляцию Ethernet VPLS в дополнение к инкапсуляции на основе перекрестных подключений для логических интерфейсов переноса псевдо-подключенного абонента.

  4. (Необязательно) Настройте завершение транспортного логического интерфейса на l2backhaul-vpn экземпляре маршрутов. Эта поддержка включена из Junos OS release 19.1R1.

Настройка сигнализации цепи уровня 2 для логических интерфейсов абонента Псевдо-провода

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

Настройка сигнализации на уровне 2 для псевдо-интерфейсов:

  1. Укажите, что необходимо настроить параметры цепи уровня 2 на уровне иерархии протоколов.
  2. Укажите IP-адрес соседа, чтобы идентифицировать маршрутизатор PE, используемый для цепи уровня 2.
  3. Укажите интерфейс, используемый трафиком цепи уровня 2.
  4. Настройте идентификатор виртуального цепи, который идентифицирует схему уровня 2 для псевдо-провода.

Дополнительные сведения о схемах уровня 2 см. в "Настройка интерфейсов для каналов уровня 2".

Настройка сигнализации VPN на уровне 2 для логических интерфейсов абонента Псевдо-провода

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

Настройка сигнализации VPN на уровне 2 для псевдо-интерфейсов:

  1. Укажите имя экземпляра маршрутов, который необходимо настроить.
  2. Настройте тип экземпляра маршрутов VPN уровня 2.
  3. Связывать псевдопроводный логический интерфейс для VPN уровня 2.
  4. Настройте уникальный идентификатор для маршрутов, принадлежащих VPN уровня 2.
  5. Настройте целевые показатели маршрутной маршрутки и переадранки (VRF) для экземпляра маршрутов VPN.
  6. Укажите, что необходимо настроить протокол VPN уровня 2 для экземпляра маршрутов.
  7. Настройте тип инкапсуляции для экземпляра маршрутизации.
  8. Укажите имя узла и идентификатор узла для СЕТИ VPN уровня 2.
  9. Укажите интерфейс, который подключается к сайту, и удаленный интерфейс, к которому должен быть подключен указанный интерфейс.
  10. Настройте параметры отслеживания трафика, использующего VPN уровня 2.

Настройка логического интерфейса службы для логического интерфейса псевдонастройки абонента

В данной теме описывается настройка логического интерфейса псевдопроводной службы. Логические интерфейсы служб представляют цепи, вложенные в псевдопроводные логические интерфейсы.

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

Примечание:

Ненулевые номера единиц представляют логические интерфейсы служб, используемые для интерфейсов абонентов псевдо-каналов. Используется unit 0 для представления логического интерфейса транспортного устройства для псевдопроводного устройства.

Для настройки логического интерфейса псевдо-службы:

  1. Укажите, что нужно настроить псевдо-подписчика логического интерфейса.
  2. Настройте блок для логического интерфейса службы. Используйте ненулевой номер единицы.
  3. (Необязательно) Укажите тип инкапсуляции логического интерфейса службы.

    Начиная с Junos OS выпуска 19.1R1, можно настроить инкапсуляцию перекрестного соединения на основе инкапсуляции, в дополнение к Ethernet VPLS, мосту VLAN и VLAN VPLS инкапсуляции VLAN для логических интерфейсов службы подписчика псевдопроводки.

    Логические интерфейсы службы псевдоназначений абонента поддерживают одномеченый трафик, трафик с двойной маркировкой и список VLANs на едином логическом интерфейсе.

  4. (Необязательно) Настройте фильтры и функции регулирования в инкапсуляции с перекрестным подключением семейства.
  5. Настройте ID тегов VLAN.
  6. Настройте интерфейс для ответа на запросы ARP, когда устройство имеет активный маршрут к целевому адресу запроса ARP.
  7. Укажите, что необходимо настроить сведения семейства протоколов. Логические интерфейсы псевдопроводной связи поддерживают семейства протоколов IPv4 (inet), IPv6 (inet6) и PPPoE (pppoe).

    Например, для настройки семейства IPv4:

    1. Укажите, что необходимо настроить IPv4.

    2. Настройте параметры для семейства.

  8. (Необязательно) Настройте завершение логического интерфейса службы на локально коммутируемых схемах уровня 2. Эта поддержка включена из Junos OS release 19.1R1.

Настройка PWHT с поддержкой типа VC 11

СВОДКА Можно настроить интерфейс псевдо-подключаемого головного конфигурера (PWHT) на маршрутизаторе службы PE, а также настроить инкапсуляцию на транспортном логическом интерфейсе ethernet-tcc псевдо-связи абонента (PS).

При использовании этой функции маршрутизатор service PE не должен поддерживать трафик TDM/SONET/SDH-инкапсулированный трафик, исходя из клиентов на стороне доступа. Ip-основанный на точке псевдопровод , то есть LDP-сигнальный FEC 128 (виртуальный канал (VC) типа 11) — соединяет маршрутизатор службы PE с устройством доступа, подключенным к CE маршрутизатору. Псевдо-провод настраивается для доступа к экземпляру VPN уровня 3 или глобальной таблице IP.

Эта функция поддерживает полезное погружные сообщения IPv4 и IPv6, а также одно- и многоавеальный трафик.

Маршрутизатор службы PE использует неверную схему ARP для разрешения адресов уровня 2, когда на обоих концах цепи используются разные протоколы разрешения. Для маршрутизатора службы PE маршрутизатор доступа CE как локально подключенный. Данное решение ARP обеспечивается прокси-ARP на адресах IPv4 и протоколом обнаружения соседей (NDP) на адресах IPv6. Маршрутизатор service PE создает локнюю запись ARP, соответствующую IPv4-адресу CE доступа маршрутизатора, или добавляет адрес CE маршрутизатора IPv6 в таблицу соседей.

Перед настройкой интерфейсов и протокола pwHT с l2circuit поддержкой типа VC 11:

Примечание:

При в enable и на интерфейсе PS обратите внимание на следующие ограничения family tcc encapsulation ethernet-tcc конфигурации:

  • Поддержка только одного псевдопровода IP для каждого физического интерфейса PS
  • Нет поддержки контрольного слова; для BFD через интерфейс PS; или для активного standby, горячего или все-активного конфигурации на IP pseudowire

Настройка PWHT на маршрутизаторе службы PE с завершением на экземпляр VPN уровня 3:

  1. Настройте резервный логический туннель (RLT) с помощью данной команды:
  2. Настройка интерфейсов. Настройте группу резервирования и интерфейсы членов на интерфейсе rlt; настройте якорную точку на интерфейсе rlt; а также настройте логические интерфейсы транспортных и сервисных псий. Настройте family tcc и инкапсуляцию-тип ethernet-tcc на транспортном логическом интерфейсе. См. пример конфигурации интерфейсов сразу после примеча.
    Примечание:
    • Настройте только один логический интерфейс службы PS.
    • ARP может быть сгенерирован на маршрутизаторе службы PE для всех IP-адресов в подсети, настроенной на логическом интерфейсе службы PS. Чтобы предотвратить генерацию многих APP, рекомендуется использовать подсеть /30 или/31 на логическом интерфейсе службы PS.
  3. Настройте протокол и включите в него утверждение для сигнализации о том, что l2circuit send-ip-addr-list-tlv отправляется IP TLV. Настройте тип инкапсуляции на логическом интерфейсе транспортного интерфейса как internetworking . Вот пример конфигурации протокола:

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

    • Используйте эту show route table l2circuit.0 команду, чтобы увидеть, что тип VC 11 включен.
    • Используйте эту show l2circuit connections extensive команду, чтобы увидеть, что инкапсуляция настроена на работу с сетью.
    • Используйте эту команду, чтобы увидеть, что были добавлены маршрут метки и маршрут tcc для переадресовки трафика через псевдопровод IP и show route table mpls.0 protocol l2circuit в псевдопровод IP.

Настройка поддержки балансировки нагрузки для трафика абонента

Настройте RLT с LT-соединениями маршрутизатора в активном активном режиме. RLT-приложения можно расширить, включив в агрегированное свойство LT-соединения для детей-членов.

Начиная с Junos OS версии 21.4R1, мы одновременно обеспечиваем поддержку балансировки нагрузки для сеансов абонента на интерфейсе PS через несколько каналов LT- детей-членов RLT. Свойство балансировки нагрузки интерфейса RLT позволяет дисперсии абонентского трафика на интерфейсе PS и распределению нагрузки между различными РС и картами линии.

Для интерфейса RLT поддерживает избыточность тока якоря PS для улучшения режима LAG. Используйте этот параметр или параметр на уровне enhanced-ip enhanced-ethernet иерархии [edit chassis network-services] при настройке PS IFD, закрепленного на RLT.

Расчетный hash используется при выборе пути ECMP и балансировки нагрузки. Можно настроить балансировку нагрузки для трафика IPv4 через псевдо-провода Ethernet уровня 2. Можно также настроить балансировку нагрузки для псевдо-проводов Ethernet на основе информации IP.

Ограничения

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

  • Изменить якорную точку PS нельзя, если не отключить физический интерфейс PS.

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

  • Статистика в членом LT недоступна для каждого члена LT. Однако совокупная статистика PS IFL или IFD доступна для обоих направлений.

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

Ниже не поддерживаются текущие функции балансировки нагрузки на PS over RLT по нескольким активным соединениям LT для детей

  • Поддержка интерфейса PS over RLT на MX240, MX480 и MX960 картах.

  • CoS поддержки иерархического интерфейса policer для активных активных линий связи-участника режима

  • CoS агрегированной поддержки Ethernet для абонентского трафика на интерфейсе псевдопроводной службы (PS)

  • L2 Поддержка IFL службы и границы бизнеса (L3) для соединения активного активного участника режима

  • Поддержка интерфейса PS на не избыточных

  • Иерархическая поддержка CoS для избыточности якорных точечных псевдо-абонентов логических интерфейсов

Настройка поддержки балансировки нагрузки для абонентского трафика:

  1. Настройте дополнительные параметры локального сервера DHCP на маршрутизаторе. См. "Настройка маршрутизатора в качестве расширенного локального сервера DHCP".
  2. Настройте два логических туннеля на двух разных картах линии для создания резервного логического туннеля (RLT).
  3. Настройте интерфейс RLT и включите логический туннельный интерфейс в группу резервирования путем настройки имени интерфейса участника-интерфейса. Настройка интерфейса RLT, см. Настройка устройства логического интерфейса абонента Псевдо-провода
  4. Настройте динамические профили для управления абонентами, см. "Динамические профили для управления абонентами".
  5. Настройка l2circuit с резервным соседом с одинаковым виртуальным кодом цепи см. пример: Настройка самого длинного совпадения для LDP.
  6. Проверку использования пропускной способности туннеля можно проверить с помощью статистики по выпаданиям интерфейса LT. Просмотр конфигурации для PS по RLT в активном режиме.
Таблица истории релизов
Выпуска
Описание
21.4R1
Начиная с Junos OS выпуска 21.4R1 мы ввели CoS BNG на абонентском интерфейсе на псевдопроводе (PS) через активный резервный логический туннель (RLT) интерфейса абонентов, таких как DHCP и PPPoE.
21.4R1
Начиная с Junos OS версии 21.4R1, мы одновременно обеспечиваем поддержку балансировки нагрузки для сеансов абонента на интерфейсе PS по нескольким ссылкам LT child member RLT. Свойство балансировки нагрузки интерфейса RLT позволяет дисперсии абонентского трафика на интерфейсе PS и распределению нагрузки между различными РС и картами линии.
21.2R1
Начиная с Junos OS 21.2R1, можно настроить интерфейс PWHT на маршрутизаторе службы PE с инкапсуляцией ethernet-tcc на интерфейсе. Псевдопроводка – VC типа 11.
20.4R1
Начиная с Junos OS выпуска 20.4R1, на MX2010 и MX2020 с линеевыми маршрутизаторами MX2K-MPC9E или MX2K-MPC11E можно определить до 18000 псевдопроводных логических интерфейсов.
19.1R1
Начиная Junos OS выпуске 19.1R1, дополнительные инкапсуляции добавляются в перенос псевдо-абонента и логические интерфейсы служб. Транспортный логический интерфейс поддерживает инкапсуляцию Ethernet VPLS и условия для завершения интерфейса экземпляра маршрутизации l2backhaul-vpn. Логический интерфейс службы поддерживает перекрестную инкапсуляцию (CCC) и условия для завершения интерфейса в локально коммутацией каналов уровня 2.
19.1R1
Начиная с Junos OS выпуска 19.1R1, можно настроить дополнительные инкапсуляции — Ethernet VPLS и инкапсуляцию на основе перекрестных подключений — для устройств логического интерфейса абонента переноса и обслуживания псевдо-подключений.
19.1R1
Начиная с Junos OS 19.1R1, можно настроить инкапсуляцию Ethernet VPLS в дополнение к инкапсуляции на основе перекрестных подключений для логических интерфейсов переноса псевдо-подключенного абонента.
19.1R1
Начиная с Junos OS выпуска 19.1R1, можно настроить инкапсуляцию перекрестного соединения на основе инкапсуляции, в дополнение к Ethernet VPLS, мосту VLAN и VLAN VPLS инкапсуляции VLAN для логических интерфейсов службы подписчика псевдопроводки.
18.4R1
Начиная с Junos OS 18.4R1, поддержка линейного распределения однонаправленных сеансов обнаружения однонаправленной переадресации (BFD) распространяется на абонента псевдопровода через избыточные логические туннельные интерфейсы.
18.3R1
Начиная с Junos OS выпуска 18.3R1, на серия MX с интерфейсами MPC и MIC поддержка абонентского интерфейса псевдопроводки по избыточным логическим туннелям введена в VPN 3-го уровня и в многоадретных VPN проектно-внедренных многоадретных VPN.
18.3R1
Начиная с Junos OS выпуска 18.3R1, на серия MX с интерфейсами MPC и MIC число устройств псевдо-резервного логического интерфейса увеличено до 7000 устройств для дополнительной поддержки отказоустойчивости.
18.3R1
Начиная с Junos OS выпуска 18.3R1, на серия MX с интерфейсами MPC и MIC количество устройств псевдо-резервного логического интерфейса увеличено до 7000 устройств для дополнительной поддержки отказоустойчивости.
17.3R1
Начиная с Junos OS выпуска 17.3R1 и более поздних версий, поддержка избыточности тока якоря с контролем состояния обеспечивается для логического интерфейса абонента псевдопроводки с помощью резервного резервного туннельного интерфейса (rlt) в режиме активного резервного копирования. Это избыточность защищает доступ и опорный соединение от сбоев Якорного PFE (модуль передачи пакетов).
17.2R1
Начиная с Junos OS выпуска 17.2R1, на серия MX с интерфейсами MPC и MIC, число масштабируемых устройств псевдопроводного логического интерфейса увеличено до 7000 устройств для обеспечения дополнительной поддержки отказоустойчивости.
16.1R1
Начиная Junos OS выпуске 16.1R1, family inet и family inet6 поддерживаются на стороне сервисов одного MPLS псевдоядерного абонента, а также не абонентского логического интерфейса.
16.1R1
Начиная Junos OS версии 16.1R1, Inline IPFIX поддерживается на стороне сервисов логического интерфейса MPLS абонента псевдо-провода.
15.1R3
Начиная с Junos OS выпуска 15.1R3 и 16.1R1 и более поздних, инкапсуляция CCC поддерживается на транспортной стороне логического интерфейса MPLS абонента псевдо-связи.
15.1R3
Начиная с Junos OS выпусков 15.1R3 и 16.1R1 и более поздних, распределенная защита отказ в обслуживании (DDoS) поддерживается на стороне сервисов логического интерфейса MPLS абонента псевдопроводки.
15.1R3
Начиная Junos OS начиная 15.1R3 и 16.1R1 и более поздних выпусках, Policer and Filter поддерживаются на стороне служб со стороны MPLS псевдо-интерфейса абонента.
15.1R3
Начиная с Junos OS выпусков 15.1R3 и 16.1R1 и более поздних, точная статистика передачи на логическом интерфейсе поддерживается на стороне служб логического MPLS абонента псевдо-провода.