Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
На этой странице
 

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

Минимальная конфигурация LDP

Чтобы включить LDP с минимальной конфигурацией:

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

  2. (Необязательно) Настройте соответствующие интерфейсы на [edit protocol mpls] уровне иерархии.

  3. Включите LDP на одном интерфейсе, включите ldp утверждение и укажите интерфейс, используя interface утверждение.

Это минимальная конфигурация LDP. Все другие настройки LDP являются необязательными.

Чтобы включить LDP на всех интерфейсах, укажите all для interface-name .

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

Включение и отключение LDP

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

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

Чтобы включить LDP на всех интерфейсах, укажите all для interface-name .

Если вы настроили свойства интерфейса на группе интерфейсов и хотите отключить LDP на одном из интерфейсов, включите в interface параметр disable утверждение:

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

Настройка LDP-времени для сообщений hello

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

Существует два типа приветствуя сообщений LDP:

  • Link hello messages - отправляется через интерфейс LDP в качестве пакетов UDP, адресованных на порт обнаружения LDP. Получение приветственного сообщения LDP-соединения на интерфейсе указывает на соединение с равноправным маршрутизатором LDP.

  • Целевые hello-сообщения — отправляются в качестве пакетов UDP, адресованных на порт обнаружения LDP с определенным адресом. Целевые hello-сообщения используются для поддержки сеансов LDP между не подключенными напрямую маршрутизаторами. Целевой маршрутизатор определяет, отвечать или игнорировать целевое привет сообщение. Целевой маршрутизатор, который выбирает ответ, делает это путем периодической отправки целевых приветствующих сообщений обратно на инициаляющий маршрутизатор.

По умолчанию LDP отправляет сообщения приветния каждые 5 секунд для сообщений hello по соединению и каждые 15 секунд для целевых сообщений hello. Можно настроить LDP-timer для изменения периоди между сообщениями hello обоих типов. Однако нельзя настроить время для LDP-времени, которое больше времени удержания LDP. Дополнительные сведения см. в "Настройка задержки перед тем, как соседи LDP будут считаться неавтируемыми".

Настройка LDP-времени для сообщений hello по ссылке

Чтобы изменить время отправки LDP сообщений hello по ссылке, укажите новый интервал приветствуя сообщения для LDP-времени с помощью hello-interval утверждения:

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

Настройка целевого hello-сообщения для LDP-времени

Чтобы изменить время отправки целевых сообщений приветинга LDP, укажите новый интервал целевого hello-сообщения для этого LDP-времени, сконфигурив утверждение в качестве параметра для hello-intervaltargeted-hello утверждения:

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

Настройка задержки до того, как соседи LDP будут считаться неавтируемыми

Время удержания определяет, как долго узлу LDP следует подождать сообщения hello, прежде чем объявлять соседний узел неавным. Данное значение отправляется как часть сообщения hello, так что каждый узел LDP сообщает своим соседям, сколько времени ждать. Значения, отосланные каждым соседом, не должны совпадать.

Время удержания обычно должно быть как минимум в три раза больше hello-интервала. Значение по умолчанию — 15 секунд для сообщений hello по соединению и 45 секунд для целевых сообщений приветния. Тем не менее, можно настроить время удержания LDP, близкое к значению для интервала hello.

Прим.:

За счет настройки времени удержания LDP близко к интервалу приветния (менее чем в три раза больше интервала приветния), ошибки соседей LDP могут обнаруживаться более быстро. Однако это также увеличивает вероятность того, что маршрутизатор может объявить о сбое соседа LDP, который продолжает работать в нормальном режиме. Дополнительные сведения см. в "Настройка LDP-времени для сообщений hello".

Время удержания LDP также автоматически согласуется между однорангами LDP. Когда два одноранговых узла LDP объявляют разное время удержания LDP друг с другом, используется меньшее значение. Если одноранговой маршрутизатор LDP объявляет меньшее время удержания, чем настроено, используется объявленный промежуток удержания. Такое согласование также может повлиять на интервал keepalive LDP.

Если локальное время удержания LDP не сокращается во время согласования равноправного узла LDP, настраиваемый пользователем интервал keepalive остается неизменным. Однако, если локальное время удержания уменьшается во время согласования равноправных рангов, интервал keepalive пересчитываются. Если время удержания LDP было уменьшено во время одноранговых согласований, интервал keepalive уменьшается до одной трети нового значения времени удержания. Например, если новое значение времени удержания составляет 45 секунд, то интервал keepalive установлен в 15 секунд.

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

При повторной настройки интервала времени удержания изменения не вступает в силу до тех пор, пока сеанс не будет перезагружен. Время удержания согласуется, когда инициируется одноранговая сессия LDP и не может быть повторно согласовано, пока сеанс будет в состоянии up (требуемая RFC 5036, спецификация LDP). Чтобы вручную принудительно перезагрузить сеанс LDP, вдай clear ldp session команду.

Настройка времени удержания LDP для сообщений hello соединения

Чтобы изменить время ожидания узлом LDP сообщения hello перед объявлением о сбое соседнего узла, укажите новое время в секундах с помощью hold-time утверждения:

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

Настройка времени удержания LDP для целевых сообщений приветния

Чтобы изменить время ожидания узлом LDP целевого сообщения hello перед объявлением о сбое соседа, укажите новое время в секундах, используя утверждение в качестве параметра для hold-timetargeted-hello утверждения:

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

Включение строго целевых приветствующих сообщений для LDP

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

  • Конечные точки туннелей RSVP, для которых настроено туннеление LDP

  • Соседние цепи уровня 2

Если ненастроенный сосед отправляет сообщение hello, одноранговая точка LDP игнорирует это сообщение и занося в журнал сообщение об ошибке (с флагом трассировки), error указывающее источник. Например, если одноранговой узла LDP был получен целевой привет от Интернет-адреса 10.0.0.1, и сосед с этим адресом не настраивается, в файл журнала LDP будет печататься следующее сообщение:

Чтобы включить строго целевые сообщения приветствуя, включайте в себя strict-targeted-hellos утверждение:

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

Настройка интервала для сообщений keepalive LDP

Интервал keepalive определяет, как часто сообщение отправляется через сеанс, чтобы убедиться, что время не превышено. Если в течение этого времени через сеанс не отправляется никакой другой трафик LDP, отправляется сообщение keepalive. Значение по умолчанию — 10 секунд. Минимальное значение - 1 секунда.

Значение, настроенное для интервала keepalive, может быть изменено во время согласования сеанса LDP, если значение, настроенное для времени удержания LDP на одноранговом маршрутизаторе, меньше, чем локально настроенное значение. Дополнительные сведения см. в "Настройка задержки перед тем, как соседи LDP будут считаться неавтируемыми".

Для изменения интервала keepalive включим keepalive-interval утверждение:

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

Настройка времени сбоя keepalive LDP

После установленного сеанса LDP необходимо периодически обмениваться сообщениями, чтобы убедиться, что он все еще работает. Время ожидания keepalive определяет время, которое соседний узел LDP ждет перед тем, как решить, что сеанс неуспешен. Это значение обычно устанавливается как минимум в три раза больше интервала keepalive. Значение по умолчанию — 30 секунд.

Для изменения интервала keepalive включим keepalive-timeout утверждение:

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

Значение, настроенном для утверждения, отображается как keepalive-timeout время удержания при выдаче show ldp session detail команды.

Настройка самого длинного совпадения для LDP

Чтобы позволить LDP узнать маршруты, агрегированные или суммированные по OSPF областям или уровням ISIS в между доменах, Junos OS позволяет настраивать самое длинное совпадение для LDP на основе RFC5283.

Прежде чем настраивать самое длинное совпадение для LDP, необходимо сделать следующее:

  1. Настройте интерфейсы устройств.

  2. Настройте MPLS протокол.

  3. Настройте OSPF протокол.

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

  1. Настройте самое длинное совпадение для протокола LDP.
  2. Настройте протокол LDP на интерфейсе.

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

Примере: Настройка самого длинного совпадения для LDP

В данном примере показано, как настраивать самое длинное совпадение для LDP на основе RFC5283. Это позволяет LDP узнать маршруты, агрегированные или суммированные по OSPF областям или уровням ISIS в между доменах.. Политика совпадения с самой длинной длиной обеспечивает детализацию префикса.

Требования

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

  • Шесть серия MX с OSPF протоколом и включенным LDP на подключенных интерфейсах.

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

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

  • Настройте интерфейсы устройств.

  • Настройте OSPF.

Обзор

LDP часто используется для создания маршрутов MPLS с коммутаными метоками (LSP) в полном сетевом домене с помощью IGP, например OSPF или IS-IS. В такой сети все соединения в домене имеют IGP, а также связи LDP. LDP устанавливает LSP на самом коротком пути к месту назначения в зависимости от ip-переадправления. В Junos OS реализация LDP делает точное сопоставление на IP-адресе FEC в RIB или IGP маршрутов для сопоставления меток. Для точного сопоставления MPLS все IP-адреса конечной точки LDP, которые будут настроены во всех ЛЯП. В этом случае цель иерархической IP-конструкции или маршрутов по умолчанию в устройствах доступа не существует. Настройка помогает избежать этого путем устранения точного поведения совпадения и настройки LSP на основе самого длинного совпадающих маршрутов на уровне каждого longest-match префикса.

Топологии

В топологии показывается, что самое длинное совпадение Рис. 1 для LDP настроено на устройстве R0.

Рис. 1: Пример наиболее длинного совпадения для LDPПример наиболее длинного совпадения для LDP

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

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

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

R0

R1

R2

R3

R4

R5

Настройка устройства R0

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

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

Для настройки устройства R0:

  1. Настройте интерфейсы.

  2. Назначьте устройству адреса обратной связи.

  3. Настройте ID маршрутизатора.

  4. Настройте протокол MPLS на интерфейсе.

  5. Настройте протокол OSPF на интерфейсе.

  6. Настройте самое длинное совпадение для протокола LDP.

  7. Настройте протокол LDP на интерфейсе.

Результаты

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

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

Проверки

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

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

Цель

Убедитесь, что ожидаемые маршруты выучатся.

Действий

На устройстве R0 в рабочем режиме запустите команду для отображения маршрутов в show route таблице маршрутов.

Смысл

Выходные данные показывают все маршруты в таблице маршрутов устройства R0.

Проверка информации о обзоре LDP

Цель

Отображение сведений о обзоре LDP.

Действий

На устройстве R0 в рабочем режиме запустите команду, show ldp overview чтобы отобразить обзор LDP.

Смысл

В выходных данных отображается информация о обзоре LDP устройства R0

Проверка записей LDP во внутренней таблице топологии

Цель

Отображение записей маршрутов во внутренней таблице топологии протокола распределения меток (LDP).

Действий

На устройстве R0 в рабочем режиме запустите команду, чтобы отобразить внутреннюю таблицу show ldp route топологии LDP.

Смысл

Выходные данные отображают записи маршрутов в таблице внутренней топологии протокола распределения меток (LDP) устройства R0.

Проверка только информации FEC о маршруте LDP

Цель

Отображение только данных FEC маршрута LDP.

Действий

На устройстве R0 в рабочем режиме запустите команду для отображения маршрутов в show ldp route fec-only таблице маршрутов.

Смысл

Выходные данные показывают только FEC-маршруты протокола LDP, доступные для устройства R0.

Проверка FEC и теневых маршрутов LDP

Цель

Отобразить FEC и теневые маршруты в таблице маршрутов.

Действий

На устройстве R0 в рабочем режиме запустите команду, чтобы отобразить FEC-маршруты и теневые маршруты в show ldp route fec-and-route таблице маршрутов.

Смысл

Выходные данные показывают FEC и теневые маршруты устройства R0

Настройка предпочтений маршрута LDP

Когда несколько протоколов вычисляют маршруты к одному месту назначения, для выбора маршрута, установленного в таблица переадресации. Выбирается маршрут с наименьшим значением предпочтения. Значением предпочтения может быть число в диапазоне от 0 до 255. По умолчанию для маршрутов LDP имеется значение предпочтения 9.

Для изменения предпочтений маршрутов включим в себя preference утверждение:

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

Хламный перезапуск LDP

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

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

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

Можно настроить пустую перезагрузку LDP как в случае с master экземпляром протокола LDP, так и для конкретного экземпляра маршрутов. Можно отключить изящную перезагрузку на глобальном уровне для всех протоколов, только на уровне протокола для LDP и на отдельном экземпляре маршрутки. По умолчанию пустая перезагрузка LDP отключена, так как на глобальном уровне по умолчанию режим graceful restart отключен. Однако вспомогательный режим (возможность помочь соседнему маршрутизатору, который пытается перезапуститься) включен по умолчанию.

Ниже следующую поведение, связанное с корректным перезапуском LDP:

  • Исходяющие метки не поддерживаются при перезапусках. Выделяются новые исходяющие метки.

  • При перезапуске маршрутизатора соседним маршрутизаторам не отправляются сообщения карты меток, поддерживаюющие измеримый перезапуск, пока не стабилизируется перезапуск маршрутизатора (сообщения карты меток немедленно отправляются соседям, которые не поддерживают корректный перезапуск). Однако все остальные сообщения (keepalive, address-message, notification и release) отправляются в обычном режиме. Распространение этих других сообщений предотвращает распространение неполной информации маршрутизатором.

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

Настройка правильного перезапуска LDP

При изменениях конфигурации постепенного перезапуска на уровне иерархии любой работающий сеанс LDP автоматически перезагружается для применения [edit routing-options graceful-restart][edit protocols ldp graceful-restart] конфигурации постепенного перезапуска. Такое поведение зеркально отражает поведение BGP настройке его при изящном перезапуске.

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

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

Включение изящного перезапуска

Для того, чтобы включить нелегкий перезапуск LDP, необходимо также включить нелегкий перезапуск маршрутизатора. Для того, чтобы включить экономный перезапуск, включите graceful-restart утверждение:

Это утверждение можно включить на следующих уровнях иерархии:

  • [edit routing-options]

  • [edit logical-systems logical-system-name routing-options]

Прим.:

серия ACX не поддерживают edit logical-systems logical-system-name routing-options [] уровень иерархии.

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

По умолчанию, при включенном изящном перезапуске LDP-перезапуска на уровне протокола LDP и во всех экземплярах маршрутов включается хламный перезапуск. Тем не менее, можно отключить как режимы graceful restart lDP, так и режим помощника при легком перезапуске LDP.

Отключение изящной перезагрузки LDP или режима помощника

Для отключения корректного перезапуска и восстановления LDP включите disable утверждение:

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

Можно отключить режим помощника только на уровне протоколов LDP. Отключение режима справки для отдельного экземпляра маршрутов невозможно. Чтобы отключить режим помощника LDP, включим в себя helper-disable утверждение:

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

Возможны следующие конфигурации изящного перезапуска LDP:

  • При этом lDP перезагружаются и режим помощника.

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

  • При этом lDP-перезапуск и режим помощника отключены. Маршрутизатор не использует ровный перезапуск LDP или тип и длину перезапуска (TLV), отосланные в сообщении инициализации. Маршрутизатор работает как маршрутизатор, который не поддерживает нелегкий перезапуск LDP.

Ошибка конфигурации выдана при попытке включить пустую перезагрузку и отключить режим помощника.

Настройка времени повторного соединения

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

Предположим, что маршрутизатор А и маршрутизатор B являются соседями LDP. Маршрутизатор A перезагружается. Время повторного соединения – это время, когда маршрутизатор А сообщает маршрутизатору B подождать, когда маршрутизатор B обнаружит, что маршрутизатор A перезагружен.

Чтобы настроить время повторного соединения, включим в себя reconnect-time утверждение:

Можно установить время повторного соединения на значение в диапазоне от 30 до 300 секунд. По умолчанию это значение составляет 60 секунд.

Список уровней иерархии, на которых можно настроить эти утверждения, см. в разделах сводка утверждения для этих утверждениях.

Настройка времени восстановления и максимального времени восстановления

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

Чтобы предотвратить отрицательное воздействие на соседний маршрутизатор, если он получает ложное значение времени восстановления от перезапуска маршрутизатора, можно настроить максимальное время восстановления на соседнем маршрутизаторе. Соседний маршрутизатор сохраняет свое состояние короче двух раз. Например, маршрутизатор А выполняет нелегкий перезапуск LDP. Он отправил соседнему маршрутизатору B время восстановления 900 секунд. Однако для маршрутизатора B максимальное время восстановления настроено в 400 секунд. Маршрутизатор B будет ждать только 400 секунд, прежде чем он очистит свои LDP-данные от маршрутизатора A.

Чтобы настроить время восстановления, включим recovery-time в себя утверждение и maximum-neighbor-recovery-time утверждение:

Список уровней иерархии, на которых можно настроить эти утверждения, см. в разделах сводка утверждения для этих утверждениях.

Фильтрация связывания входящие метки LDP

Можно фильтровать полученные привязки меток LDP, применяя политики для следования или запрета связывания, объявленных соседними маршрутизаторами. Для настройки фильтрации полученных меток включим в себя import утверждение:

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

Именоваемая политика (настроена на уровне иерархии) применяется к всем привязкам меток, полученным [edit policy-options] от всех соседей LDP. Все фильтрация делается с помощью операторов. Перечисляются только операторы, применимые к фильтрации по полученной fromТабл. 1from меткой LDP.

Табл. 1: от операторов, применимых к фильтрации полученных меток LDP

from Оператор

Описание

interface

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

neighbor

Совпадения по привязкам, полученным от указанного LDP-ID маршрутизатора

next-hop

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

route-filter

Соответствует привязкам с указанным префиксом

Если привязка отфильтрована, она по-прежнему отображается в базе данных LDP, но не рассматривается для установки как часть пути с коммутаансной меткой (LSP).

Обычно политики в LDP можно использовать только для блокирований создания LSP, а не для контроля их маршрутов. Это обусловлено тем, что путь, по пути, который следует за LSP, определяется одноавстной маршрутией, а не LDP. Однако при использовании нескольких маршрутов с равной стоимостью к месту назначения через различных соседей можно использовать фильтрацию LDP, чтобы исключить возможные последующие переходы из рассмотрения. (В противном случае LDP выбирает один из возможных следующих переходов на выбор.)

Сеансы LDP не привязаны к интерфейсам или адресам интерфейсов. LDP объявляет только метки для каждого маршрутизатора (не для каждого интерфейса); таким образом, если между двумя маршрутизаторами существует несколько параллельных связей, устанавливается только один сеанс LDP, и он не привязан к одному интерфейсу. Если несколько соседей маршрутизатора имеют несколько соседей к одному и тому же соседу, необходимо убедиться, что фильтр делает ожидаемое. (Как правило, в next-hop данном случае используется и не interface подходит.)

Если метка была отфильтрована (означая, что она отклонена политикой и не используется для создания LSP), метка помечется как отфильтровываемая в базе данных:

Дополнительные сведения о настройке политик для LDP см. в руководстве по политикам маршрутов, фильтрам межсетевых экранов и руководству по политикам управления трафиком.

Примеры: Фильтрация связывания входящие метки LDP

Примите от всех соседей только префиксы /32:

Примите 131.108/16 или дольше из ID маршрутизатора и 10.10.255.2 примите все префиксы от всех остальных соседей:

Фильтрация связывания исходящие метки LDP

Можно настроить экспортную политику для фильтрации исходящие метки LDP. Можно отфильтровать привязки исходящие метки, применив политики маршрутов, чтобы блокировать объявление связывания соседним маршрутизаторам. Чтобы настроить фильтрацию исходящие метки, включим в себя export утверждение:

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

Именоваемая экспортная политика (настроена на уровне иерархии) применяется к всем привязкам меток, переданным всем [edit policy-options] соседям LDP. Единственный оператор, применяющий фильтрацию исходящие метки LDP – это, который соответствует привязкам с указанным fromroute-filter префиксом. toОператоры, применимые к фильтрации исходящие метки, - это операторы Табл. 2 in.

Табл. 2: операторам для фильтрации исходящие метки LDP

оператору

Описание

interface

Совпадения по привязкам, отосланным соседу, который является смежным по указанному интерфейсу

neighbor

Совпадения по привязкам, отправленным на указанный LDP-маршрутизатор ID

next-hop

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

Если привязка фильтруется, связывание не объявляется соседнему маршрутизатору, но может быть установлено как часть LSP на локальном маршрутизаторе. В LDP можно применить политики, блокируют установление LPS, но не контролируют их маршруты. Путь, по пути, который следует на LSP, определяется одноавстной маршрутией, а не LDP.

Сеансы LDP не привязаны к интерфейсам или адресам интерфейсов. LDP объявляет только для каждого маршрутизатора (не для каждого интерфейса) метки. Если между двумя маршрутизаторами существует несколько параллельных связей, устанавливается только один сеанс LDP, и он не привязан к одному интерфейсу.

Не используйте операторы и маршрутизаторы, если у маршрутизатора есть несколько соседей next-hopinterface с одинаковым соседом.

В базе данных помечаются отфильтрованные метки:

Дополнительные сведения о настройке политик для LDP см. в руководстве по политикам маршрутов, фильтрам межсетевых экранов и руководству по политикам управления трафиком.

Примеры: Фильтрация связывания исходящие метки LDP

Блокировать передачу маршрута 10.10.255.6/32 соседним маршрутизаторам:

Отправьте только 131.108/16 или дольше на ID маршрутизатора и отправьте все 10.10.255.2 префиксы всем другим маршрутизаторам:

Указание транспортного адреса, используемго LDP

Прежде чем устанавливать сеанс LDP, маршрутизаторы должны установить сеанс TCP друг с другом. Сеанс TCP позволяет маршрутизаторам обмениваться объявлениями меток, необходимыми для сеанса LDP. Для установления сеанса TCP каждый маршрутизатор должен получить транспортный адрес другого маршрутизатора. Транспортный адрес – это IP-адрес, используемый для идентификации сеанса TCP, в течение которого будет работать сеанс LDP.

Для настройки транспортного адреса LDP включаем утверждение транспортного адреса:

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

При указании параметра адрес идентификатора маршрутизатора будет использоваться в качестве транспортного адреса (если иное не настроено, идентификатор маршрутизатора обычно будет тем же, что и адрес обратной router-id связи). Если указан параметр, адрес интерфейса будет использоваться в качестве транспортного адреса для любых сеансов LDP с соседями, с которые interface можно получить обращение через этот интерфейс. Обратите внимание, что идентификатор маршрутизатора по умолчанию используется в качестве транспортного адреса.

Нельзя указать этот параметр при нескольких параллельных соединениях с одним и тем же соседом LDP, поскольку спецификация LDP требует, чтобы один и тот же транспортный адрес был объявлен всем интерфейсам одному и тому interface же соседу. Если LDP обнаруживает несколько параллельных связей с одним и тем же соседом, он отключает интерфейсы к соседнему соседу один за одним до тех пор, пока условие не будет смыкаться, отсоединив соседа на интерфейсе или указав router-id параметр.

Контроль транспортного адреса, используемого для целевого сеанса LDP

Чтобы установить сеанс TCP между двумя устройствами, каждое устройство должно получить транспортный адрес другого устройства. Транспортный адрес – это IP-адрес, используемый для идентификации сеанса TCP, в котором работает сеанс LDP. Раньше этот транспортный адрес мог быть только адресом router-ID или адресом интерфейса. С помощью функции переноса-адреса LDP можно явно настроить любой IP-адрес в качестве транспортного адреса для целевых соседей LDP для соседей уровня 2, MPLS и соседей VPLS. Это позволяет управлять целевыми сеансами LDP с помощью конфигурации транспортного адреса.

Преимущества управления транспортным адресом, используемым для целевого сеанса LDP

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

  • Flexible interface configurations- Обеспечивает гибкость настройки нескольких IP-адресов для одного интерфейса обратной связи без прерывания создания сеанса LDP между целевыми соседями по LDP.

  • Ease of operation— Транспортный адрес, настроенный на уровне интерфейса, позволяет использовать несколько протоколов в IGP магистрали для LDP. Это обеспечивает ровную и легкую работу.

Обзор целевого транспортного адреса LDP

До Junos OS выпуска 19.1R1 LDP предоставлял поддержку только для ID маршрутизатора или адреса интерфейса в качестве транспортного адреса на любом интерфейсе LDP. Сформированные на этом интерфейсе юные стороны использовали один из IP-адресов, присвоенных интерфейсу или маршрутизатору-ID. В случае целевой сдежности интерфейс является интерфейсом обратной связи. Когда на устройстве было настроено несколько адресов обратной связи, транспортный адрес для интерфейса не может быть получен, и в результате сеанс LDP не может быть установлен.

Начиная с Junos OS release 19.1R1, помимо IP-адресов по умолчанию, используемых для переноса целевых LDP-сеансов, можно настроить любой другой IP-адрес в качестве транспортного адреса в соответствии с и sessionsession-groupinterface настройками. Конфигурация транспортного адреса применима только для настроенных соседей, включая цепи уровня 2, MPLS и соседства VPLS. Эта конфигурация не применяется к обнаруженным смежам (целевым или нет).

Предпочтение транспортного адреса

Можно настроить транспортный адрес для целевых LDP-сеансов на уровне сеанса, группы сеансов и уровня интерфейса.

После настройки транспортного адреса устанавливается сеанс targeted-LDP на основе предпочтения транспортного адреса LDP.

Порядок предпочтения транспортного адреса для целевого соседа (настроен через цепь уровня 2, MPLS, VPLS и конфигурацию LDP) следующим образом:

  1. В [edit protocols ldp session] иерархии.

  2. В [edit protocols ldp session-group] иерархии.

  3. В [edit protocols ldp interfcae lo0] иерархии.

  4. В [edit protocols ldp] иерархии.

  5. Адрес по умолчанию.

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

  1. В [edit protocols ldp interfcae] иерархии.

  2. В [edit protocols ldp] иерархии.

  3. Адрес по умолчанию.

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

  1. В [edit protocols ldp interfcae lo0] иерархии.

  2. В [edit protocols ldp] иерархии.

  3. Адрес по умолчанию.

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

Для устранения неполадок сеансов targeted-LDP можно использовать следующие выходные данные команды show:

  • show ldp session

  • show ldp neighbor

    Уровень выходных данных команды показывает транспортный адрес, отправленный в приветствуемом сообщении detailshow ldp neighbor целевому соседу. Если этот адрес не может быть достижим от соседа, сеанс LDP не будет иным.

  • show configuration protocols ldp

Можно также включить трассировки LDP для дальнейшего устранения неполадок.

  • Если изменить конфигурацию с использования недопустимого (не догонимого) транспортного адреса на допустимый транспортный адрес, можно отследить следующие трассировки:

  • Если изменить конфигурацию с использованием действительного транспортного адреса на недопустимый (недоступный) транспортный адрес, можно отследить следующие трассировки:

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

  • Проверьте. address family Транспортный адрес, настроенный под утверждением, должен принадлежать к одному семейку session адресов, что и соседний или сеанс.

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

Настройка префиксов, объявленных LDP из таблицы маршрутов

Можно управлять набором префиксов, которые объявляются в LDP, и привести к тому, что маршрутизатор маршрутизатор исходящего трафика для этих префиксов. По умолчанию LDP объявляется только адрес обратной связи. Чтобы настроить набор префиксов из таблицы маршрутов, которые будут объявлены в LDP, включим в себя egress-policy утверждение:

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

Прим.:

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

Именоваемая политика (настроена на уровне иерархии) применяется ко всем маршрутам в [edit policy-options][edit logical-systems logical-system-name policy-options] таблице маршрутов. Маршруты, которые соответствуют политике, объявляются в LDP. Можно управлять набором соседей, которые объявляются префиксами с помощью export утверждения. Рассматриваются from только операторы; можно использовать любого действительного from оператора. Дополнительные сведения см. в Junos OS протоколов маршрутов для устройств маршрутов.

Прим.:

серия ACX не поддерживают edit logical-systems [] уровень иерархии.

Примере: Настройка префиксов, объявленных в LDP

Объявление всех подключенных маршрутов в LDP:

Настройка deaggregation FEC

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

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

При отсеии feC каждый префикс привязывается к отдельной метке и становится отдельным LSP.

Для настройки дезгрегированных FEC включим в себя deaggregate утверждение:

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

Для всех сеансов LDP можно настроить deaggregated FEC только глобально.

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

Чтобы агрегировать FEC, включим в себя no-deaggregate утверждение:

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

Для всех сеансов LDP можно настраивать агрегированные FEC только глобально.

Настройка policers для LDP FEC

Можно настроить Junos OS отслеживание и отслеживание трафика для LDP FEC. Для этого можно использовать следующие действия:

  • Отслеживание или отслеживание впускного трафика для LDP FEC.

  • Отслеживание или отслеживание транзитного трафика для LDP FEC.

  • Отслеживает или пропадет трафик LDP FEC, исходя из отдельного класса переад пути.

  • Отслеживает или отслеживает трафик LDP FEC, исходя из специального виртуального сайта маршрутов и переададреции (VRF).

  • Отбросьте ложный трафик, связанный с определенным LDP FEC.

Для управления трафиком для LDP FEC сначала необходимо настроить фильтр. В частности, необходимо настроить утверждение или утверждение interfaceinterface-set на уровне [edit firewall family protocol-family filter filter-name term term-name from] иерархии. Утверждение interface позволяет со соответствием фильтра одному интерфейсу. Утверждение interface-set позволяет со соответствием фильтра нескольким интерфейсам.

Дополнительные сведения о настройке утверждения, утверждения и политик для LDP FEC см. в руководстве по политикам маршрутов, фильтрам брандмауэра и правилам управления interfaceinterface-setтрафиком.

После настройки фильтров необходимо включить их в конфигурацию утверждения policing для LDP. Для настройки policers для LDP FEC включаем policing утверждение:

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

Утверждение policing включает в себя следующие параметры:

  • fec- Укажите адрес FEC для LDP FEC, который необходимо проавизировать.

  • ingress-filter-Укажите имя фильтра влияемого трафика.

  • transit-traffic-Укажите имя фильтра транзитного трафика.

Настройка фильтрации LDP IPv4 FEC

По умолчанию, когда установлен целевой сеанс LDP, Junos OS всегда обменивается как классами эквивалентности переадружения IPv4 (FEC), так и каналами FEC 2-го уровня через целевой сеанс LDP. Для сеанса LDP с косвенно подключенным соседом, возможно, будет необходимо экспортировать цепи FEC уровня 2 соседу, только если сеанс был специально настроен для поддержки каналов уровня 2 или VPLS.

В смешанной сети поставщика, где все префиксы, не BGP, объявляются в LDP, база данных LDP может стать большой. Для этого типа окружения может быть полезно предотвратить объявление плат FEC IPv4 по сеансам LDP, сформированных вследствие конфигурации VPLS цепи уровня 2 или LDP. Аналогичным образом может быть полезно отфильтровать все feC IPv4, полученные в подобной среде.

Если все соседи LDP, связанные с сеансом LDP, являются только уровня 2, можно настроить Junos OS для объявления только каналов FEC уровня 2 путем настройки l2-smart-policy утверждения. Эта функция также автоматически фильтрует feC IPv4, полученные в этом сеансе. Настройка явно определенной политики экспорта или импорта, которая активирована для отключения этой l2-smart-policy функции в соответствующем направлении.

Если один из соседей сеанса LDP сформирован из-за обнаруженной соседства или если соседи сформированы вследствие конфигурации туннелирований LDP на одном или более LSVP LSP, feC IPv4 объявляется и получается с использованием поведения по умолчанию.

Чтобы предотвратить экспорт LDP IPv4 FEC через сеансы LDP только с соседями уровня 2 и отфильтровать IPv4 FEC, полученные через такие сеансы, включаем l2-smart-policy утверждение:

Список уровней иерархии, на которых можно настроить это утверждение, см. в сводке утверждения для этого утверждения.

Настройка BFD для LDP LSP

Для LSP LDP можно настроить обнаружение байтовой переадправления (BFD). Протокол BFD – это простой механизм приветствуя, который выявляет сбои в сети. Пакеты приветствуются с заданным, регулярным интервалом. Ошибка соседа обнаруживается, когда маршрутизатор прекращает получать ответ через заданный интервал. BFD работает с множеством сетевых сред и топологий. У измерителей обнаружения сбоев для BFD есть более короткие пределы времени, чем у механизмов обнаружения сбоев статических маршрутов, что обеспечивает более быстрое обнаружение.

Ошибка регистрируется всякий раз при сбойе сеанса BFD для пути. Ниже показано, как может появиться BFD для сообщений журнала LSP LSP LSP:

Можно также настроить BFD для LSP RSVP, как описано в описании конфигурации BFD для LSVP-сигнальных LPS.

По времени обнаружения неисправностей BFD имеются адаптивные и более или менее агрессивные. Например, можно адаптироваться к большему значению при сбойе соседства или сосед может согласовать для этого значения большее, чем настроено значение. При перенастраи сеанса BFD они адаптируются к большему значению за период 15 секунд более чем в три раза. Алгоритм back-off увеличивает интервал получения (Rx) на два, если локальный экземпляр BFD является причиной переключеки сеанса. Интервал передачи (Tx) увеличивается на два, если экземпляр удаленного BFD является причиной перепутья сеанса. Эту команду можно использовать для возврата заданные значения интервалов clear bfd adaptation BFD. Команда не работает, т.е. она не влияет на поток трафика на clear bfd adaptation устройстве маршрутов.

Чтобы включить BFD для LDP LSP, включим oam в себя bfd-liveness-detection следующие утверждения:

BFD можно включить для LDP LSP, связанных с определенным классом эквивалентности переадности (FEC), путем настройки адреса FEC с помощью параметра на fec[edit protocols ldp] уровне иерархии. Кроме того, можно настроить политику управления операциями и управления (OAM) для встрашения BFD в диапазон FEC-адресов. Дополнительные сведения см. в "Настройка политик впуска OAM для LDP".

Нельзя включить LSP BFD LDP, если их эквивалентные адреса FEC явно настроены или OAM включен на FEC с помощью политики входа OAM. Если BFD не включен для адресов FEC, сеанс BFD не будет включен.

Можно настроить утверждение oam на следующих уровнях иерархии:

  • [edit protocols ldp]

  • [edit logical-systems logical-system-name protocols ldp]

Прим.:

серия ACX не поддерживают edit logical-systems [] уровень иерархии.

Утверждение oam включает в себя следующие параметры:

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

  • lsp-ping-interval-Укажите продолжительность интервала ping LSP в секундах. Чтобы сделать ping на LDP-сигнальном LSP, используйте ping mpls ldp эту команду. Дополнительные сведения см. в интерфейс командной строки Explorer.

Утверждение bfd-liveness-detection включает в себя следующие параметры:

  • ecmp- Причиной того, что LDP установит сеансЫ BFD для всех путей ECMP, настроенных для указанного FEC. При настройке ecmp параметра необходимо также настроить утверждение для periodic-traceroute указанного FEC. Если это не сделать, операция сфиксации будет неудачной. Можно настроить утверждение на уровне глобальной иерархии () и настроить только параметр для periodic-traceroute[edit protocols ldp oam]ecmp конкретного FEC ( [edit protocols ldp oam fec address bfd-liveness-detection] ).

  • holddown-interval— указание продолжительности сеанса BFD до добавления маршрута или следующего перехода. Указание времени 0 секунд приводит к добавлению маршрута или следующего перехода сразу после того, как сеанс BFD снова зайдет.

  • minimum-interval-Укажите минимальный интервал передачи и получения. При настройке этого параметра нет необходимости настраивать minimum-intervalminimum-receive-interval этот minimum-transmit-interval параметр.

  • minimum-receive-interval-Укажите минимальный интервал получения. Диапазон — от 1 до 255 000 миллисекунд.

  • minimum-transmit-interval-Укажите минимальный интервал передачи. Диапазон — от 1 до 255 000 миллисекунд.

  • multiplier-Укажите коэффициент времени обнаружения. Диапазон — от 1 до 255.

  • version —указывается версия BFD. Возможные варианты: BFD версии 0 или BFD версии 1. По умолчанию Junos OS программного обеспечения пытается автоматически определить версию BFD.

Настройка ecMP-aware BFD для LDP LSP

При настройке BFD для FEC сеанс BFD устанавливается только для одного активного локального следующего перехода для маршрутизатора. Однако можно настроить несколько сеансов BFD, по одному для каждого FEC, связанного с конкретным многопутевым маршрутом равной стоимости (ECMP). Для правильной работы необходимо также настроить периодическую трассировку трассировки LSP LDP. (См. Настройка LDP LSP Traceroute.) Трассировка LSP LSP используется для обнаружения путей ECMP. Для каждого обнаруженного пути ECMP инициировался сеанс BFD. При неудачном сеансе BFD для одного из путей ECMP регистрируется ошибка.

Трассировка LSP LSP периодически запускается для проверки целостности путей ECMP. При обнаружении проблемы может возникнуть следующее:

  • Если последняя версия LDP LSP traceroute для FEC отличается от предыдущей трассировки маршрута, сессии BFD, связанные с этим FEC (сеансы BFD для диапазонов адресов, измененных по сравнению с предыдущими версиями), отлажаются и новые сеансы BFD инициируются для адресов назначения в измененных диапазонах.

  • Если трассировка LSP LSP возвращает ошибку (например, время простоя), все сеансы BFD, связанные с этим FEC, разрываются.

Чтобы настроить LDP на установление сеансов BFD для всех путей ECMP, настроенных для указанного FEC, включите ecmp утверждение.

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

Наряду с утверждением необходимо также включить утверждение в глобальную конфигурацию LDP OAM (на уровне иерархии или на иерархии) или в конфигурацию для указанного FEC (на уровне иерархии или на уровне ecmpperiodic-traceroute[edit protocols ldp oam][edit logical-systems logical-system-name protocols ldp oam][edit protocols ldp oam fec address][edit logical-systems logical-system-name protocols ldp oam fec address] иерархии). В противном случае операция сфиксации будет неуспешной.

Прим.:

серия ACX не поддерживают edit logical-systems [] уровень иерархии.

Настройка сбоя для сеанса BFD на LSP LDP

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

Можно настроить один из следующих вариантов действий при сбое для утверждения в случае сбоя failure-action сеанса BFD на LSP LDP:

  • remove-nexthop-Удаление маршрута, соответствующего следующему переходу маршрута LSP на впадаемом узле при обнаружении события сбоя сеанса BFD.

  • remove-route-Удаление маршрута, соответствующего LSP, из соответствующих таблиц маршрутов при обнаружении события сбоя сеанса BFD. Если LSP настроен с ECMP и сеанс BFD, соответствующий любому пути, отстает, маршрут удаляется.

Чтобы настроить действие по сбою в случае сбоя сеанса BFD на LSP LDP, включите либо параметр, либо параметр для remove-nexthopremove-routefailure-action утверждения:

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

Настройка интервала удержания для сеанса BFD

Можно указать длительность сеанса BFD перед добавлением маршрута или следующего перехода, настроив утверждение на уровне иерархии или на holddown-interval[edit protocols ldp oam bfd-livenesss-detection] уровне [edit protocols ldp oam fec address bfd-livenesss-detection] иерархии. Указание времени 0 секунд приводит к добавлению маршрута или следующего перехода сразу после того, как сеанс BFD снова зайдет.

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

Понимание быстрой перенастройки только для многоастройной вещания

Многоадварная рассылка только быстрая перемаршрутизация (MoFRR) минимизирует потерю пакетов для трафика в дереве многоавтоматной рассылки при сбое каналов, расширяя протоколы многоарендной маршрутизации, такие как Protocol Independent Multicast (PIM) и многоточкиальный протокол распределения меток (многоточки LDP) на устройствах, поддерживаюющих эти функции.

Прим.:

На коммутаторах MoFRR с MPLS меткой и многоточки LDP не поддерживается.

Для серия MX маршрутизаторов MoFRR поддерживается только на серия MX с картами линии MPC. В качестве предварительного условия необходимо настроить маршрутизатор в режиме, а все карты линии в маршрутизаторе network-services enhanced-ip должны быть картами MPC.

При включаемом MoFRR устройства посылают сообщения join на основной и резервный путь к многоадстройному источнику. Устройства получают пакеты данных как с основного, так и с резервного пути, и отбрасывают избыточные пакеты на основе приоритета (весов, которые назначены для основных и резервных путей). Обнаружив сбой на основном пути, устройство немедленно начинает принимать пакеты от вторичного интерфейса (резервного пути). Быстрое переключение значительно улучшает время сходимости при сбоях основного пути.

Одно приложение для MoFRR – потоковое IPTV. Потоки IPTV являются многоандными в качестве потоков UDP, поэтому любые потерянные пакеты не ретранслированы повторно, что приводит к менее приемлемому опыту работы пользователей. MoFRR может улучшить ситуацию.

Обзор MoFRR

При быстрая перемаршрутизация однонаправных потоках устройство маршрутной передачи в верхнем потоке передо всеми путями MPLS метки коммутаторами (LSPs) или precomputes альтернативного альтернативного (LFA) IP-петли (LFA) быстрая перемаршрутизация резервного пути для обработки сбоев сегмента в ингинговом пути.

В многоафровом маршруте приемная сторона обычно создает графики распределения трафика. В этом отличие от одноастерной маршрутки, обычно устанавливаемой путь от источника к приемнику. PIM (для IP), многоточки LDP (для MPLS) и RSVP-управление трафиком (для MPLS) — это протоколы, способные создавать графики многоандной рассылки. Из них приемники PIM и многоточки LDP инициируют настройку схемы распределения, чтобы MoFRR мог работать с этими двумя многоадранными протоколами там, где они поддерживаются.

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

При включенном MoFRR для каждой (S,G) записи устройство использует два доступных входных интерфейса для отправки сообщения join и получения многоададного трафика. Протокол пытается выбрать два разных пути, если есть два таких пути. Если несоотвествуют пути, протокол выбирает два несоединеных пути. Если недоступны два несоединеных пути, то выбирается только основной путь без резервной копии. MoFRR приоритизует несоединяемое резервное копирование в пользу балансировки нагрузки доступных путей.

MoFRR поддерживается для семейок протоколов IPv4 и IPv6.

Рис. 12 отображает два пути от многоаресного приемного устройства маршрутов (также именуемого устройством поставщика на выпадающее (PE) пути к устройству маршрутов многоаресного источника (также именуемого устройством pe-вния).

Рис. 12: Пример топологии MoFRRПример топологии MoFRR

При включенном MoFRR устройство маршрутизации (сторона приемного устройства) устанавливает два многоадресных дерева, основной и резервный путь, к многоадресным источникам для каждого (S,G). Другими словами, устройство маршрутной маршрутки на выходящего потока передает одинаковые (S,G) сообщения join к двум различным соседним устройствам в направлении к вышестояному потоку, создавая таким образом два дерева многоадретной распространения.

Одно из многоавестных деревьев проходит через плоскость 1, а другая - через плоскость 2, как показано Рис. 12 в. Для каждого (S,G) устройство маршрутной маршрутации для выпадающего трафика, полученного на основном маршруте, отбрасняет трафик, полученный на резервном пути.

MoFRR поддерживается как на путях с равной стоимостью (ECMP), так и на неэкранных путях. Устройству необходимо включить альтернативные маршруты без петель одноаксочной (LFA) для поддержки MoFRR на путях, не в зависимости от ECMP. Маршруты LFA включается с помощью утверждения в конфигурации протокола внутренних IGP link-protection шлюзов. Когда включается защита соединения на интерфейсе OSPF или IS-IS, устройство создает резервный путь LFA к основному следующему переходу для всех маршрутов назначения, которые проходят через защищенный интерфейс.

Junos OS реализует MoFRR в IP-сети для IP MoFRR и на MPLS на границе метки маршрутизации (LER) для многоточки LDP MoFRR.

Многоточкиальный LDP MoFRR используется на устройстве-выпуске сети MPLS, где пакеты переадресуются в IP-сеть. С помощью многоточки LDP MoFRR устройство устанавливает два пути к устройству маршрутизации pe входящего потока для получения двух потоков MPLS пакетов на LER. Устройство принимает один из потоков (первичный), а другой (резервный) отброшен на LER. Если основной путь сбой, устройство принимает резервный поток. Поддержка сигнализации вполосном ряду является предварительным условием для MoFRR с многоточкильным LDP (см. "Понимание многоточки LDP inband signaling для LSPточек-точек").

Функциональные возможности PIM

Junos OS поддержка MoFRR для дерева кратчайших путей (SPT) присоединяется к многоарендной (SSM) и многоарендной (ASM) для любого источника. MoFRR поддерживается как для SSM, так и для диапазонов ASM. Чтобы включить joins MoFRR (*,G), включив в иерархию утверждение mofrr-asm-starg[edit routing-options multicast stream-protection] конфигурации. Для каждой группы G MoFRR будет работать либо (S,G), либо (*,G), но не обе. (S,G) всегда имеет приоритет над (*,G).

При включаемом MoFRR устройство маршрутизации PIM распространяет сообщения join на двух upstream reverse-path forwarding (RPF) интерфейсах для получения многоададного трафика на обоих соединениях для одного и того же запроса соединения. MoFRR отдается предпочтение двум путям, которые не сходятся с одинаковым устройством немедленной маршрутизации в направлении к источнику. PIM устанавливает соответствующие многоадстройные маршруты с следующими переходами RPF в направлении к источнику с двумя интерфейсами (для основного и резервного путей).

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

Можно включить MoFRR с помощью балансировки нагрузки присоединиться к PIM join-load-balance automatic (см. утверждение). Однако в этом случае распределение сообщений join между каналами может быть не более чем 1. При добавлении нового соединения ECMP сообщения о соединении на основном пути перераспределяются и балансирует нагрузку. Сообщения join на резервном пути могут все еще следовать тем же путем и не могут быть перераспределяться поровна.

MoFRR включается с помощью stream-protection утверждения конфигурации в [edit routing-options multicast] иерархии. MoFRR управляется набором политик фильтрации.

Когда устройство маршрутизации PIM получает сообщение о присоединиться или отчет IGMP, оно проверяет конфигурацию MoFRR и продолжает работу следующим образом:

  • Если конфигурация MoFRR не имеется, PIM отправляет сообщение о подсоединении к одному соседу входящего потока (например, плоскости 2 Рис. 12 in).

  • Если конфигурация MoFRR присутствует, устройство проверяет конфигурацию политики.

  • Если политика не существует, устройство проверяет основные и резервные пути (upstream interfaces) и продолжает работу следующим образом:

    • Если первичные и резервные пути недоступны — PIM отправляет сообщение о подсоединении к одному соседу в направлении (например, плоскость 2 Рис. 12 in).

    • При наличии основных и резервных путей PIM отправляет сообщение join upstream двум доступным соседям в направлении к нему. Junos OS настраивает основной и вторичный многоабъестные пути для получения многоабъюстного трафика (например, плоскость 1 Рис. 12 in).

  • Если имеется политика, устройство проверяет, разрешает ли данной политикой MoFRR (S,G) и продолжает действовать следующим образом:

    • Если эта проверка политики не удалась — PIM отправляет сообщение о подсоединении одному соседу в направлении к вышестояку (например, плоскость 2 Рис. 12 in).

    • Если эта проверка политики проходит — устройство проверяет основные и резервные пути (upstream interfaces).

      • Если первичные и резервные пути недоступны, PIM отправляет сообщение о подсоединении к одному соседу в направлении к нему (например, плоскость 2 Рис. 12 in).

      • Если доступны первичный и резервный пути, PIM отправляет сообщение join upstream к двум доступным соседним соседним системам. Устройство устанавливает основные и вторичные многоастерные пути для получения многоабъюстного трафика (например, плоскость 1 Рис. 12 in).

Многоточкиальная функциональность LDP

Во избежание MPLS трафика многоточки LDP обычно выбирает только один путь входящего потока. (См. раздел 2.4.1.1. Определение «upstream LSR» в RFC 6388, расширения протокола распределения меток для многоточки и многоточки с коммутациями по метке.)

Для многоточки LDP с MoFRR многоточки LDP-устройство выбирает два отдельных одноранговых узла входящего потока и отправляет две отдельные метки, по одной на каждый конечный одноранговой. Устройство использует тот же алгоритм, что и в RFC 6388, чтобы выбрать основной путь к источнику. Устройство использует тот же алгоритм для выбора резервного пути отходящего потока, но исключает первичный LSR кандидатом. Два разных одноранговых узла входящего потока посылают два MPLS трафика на устройство маршрутной передачи для выходящего трафика. Устройство выбирает только один из путей соседа вышестояного потока в качестве основного пути, с которого MPLS трафик. Другой путь становится резервным, и устройство сбрасывает этот трафик. При сбой основного пути к верхнему потоку устройство начинает принимать трафик с резервного пути. Многоканальный LDP-устройство выбирает два пути от входа в систему на основе протокола внутреннего шлюза (IGP) следующего перехода.

Класс эквивалентности для переадности (FEC) является группой IP-пакетов, которые переадминуются одинаковым образом по одному и тем же пути и с одинаковой обработкой переад. Обычно метка, присвоенная конкретному пакету, представляет FEC, которому назначен этот пакет. В MoFRR два маршрута помещаются в таблицу mpls.0 для каждого FEC— один маршрут для основной метки, а другой маршрут для резервной метки.

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

Узел "нестабильный" LSR является выходящий LSR, но с одним или более непосредственно связанными 9-градиными LSRs. Для заявного узла трафик от основного пути к вышестоякому маршруту перена него LSR. Если основной путь к основному потоку сбой, MPLS трафик с резервного пути от него передается на начальную LSR. Это означает, что LSR следующий переход добавляется как к MPLS, так и к следующему переходу для выходящего.

Как и в PIM, MoFRR с многоточкильным LDP включается с помощью утверждения конфигурации в иерархии, и управлять им можно с помощью набора stream-protection[edit routing-options multicast] политик фильтрации.

Если для MoFRR включен многоточки LDP-многоточки FEC из двух точек, устройство учитывает следующие факторы при выборе пути входящего потока:

  • Целевые сеансы LDP пропускаются, если имеется нетаргетный сеанс LDP. При едином целевом сеансе LDP выбирается целевой сеанс LDP, но соответствующий сеанс "точка-многоканальный FEC" теряет возможность MoFRR из-за того, что с целевым сеансом LDP не связан интерфейс.

  • Все интерфейсы, принадлежащие одному и одному LSR, считаются основными.

  • Для всех обновлений маршрутов корневого узла путь к узлу маршрута меняется на основе последних следующих переходов от IGP. Если доступен лучший путь, многоточкиальный LDP пытается переключиться на лучший путь.

Переадваровка пакетов

Для PIM или многоточки LDP устройство выполняет многоадресный выбор потока источника на впускном интерфейсе. Это сохраняет полосу пропускания инфраструктуры и максимизирует производительность переадрегируемой связи, благодаря этому:

  • Предотвращение рассылки дублирующихся потоков через структуру

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

Для PIM каждый многоадресная передача по протоколу IP содержит один и тот же адрес назначения. Независимо от интерфейса, на который приходят пакеты, у пакетов один и тот же маршрут. Устройство проверяет интерфейс, на который приходит каждый пакет, и переадековывая только те, которые находятся с основного интерфейса. Если интерфейс соответствует интерфейсу резервного потока, устройство сбрасывает пакеты. Если интерфейс не совпадает ни с первичным, ни с резервным интерфейсом потока, устройство обрабатывает пакеты в качестве исключений из плоскость управления.

Рис. 13 показывает этот процесс с примерами первичных и резервных интерфейсов для маршрутизаторов с PIM. Рис. 14 показывает это аналогично для коммутаторов с PIM.

Рис. 13: В окнах модуль передачи пакетов маршрутов IP MoFRRВ окнах модуль передачи пакетов маршрутов IP MoFRR
Рис. 14: Обработка IP-маршрута MoFRR на модуль передачи пакетов коммутаторахОбработка IP-маршрута MoFRR на модуль передачи пакетов коммутаторах

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

Рис. 15 показывает этот процесс для маршрутизаторов с многоточки lDP.

Рис. 15: В MPLS маршрутизации МоФRR модуль передачи пакетовВ MPLS маршрутизации МоФRR модуль передачи пакетов

Ограничения и ограничения

Ограничения и ограничения MoFRR в коммутаторах и устройствах маршрутизации

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

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

  • MoFRR поддерживает быстрая перемаршрутизация двух выбранных размежных путей к источнику. Два выбранных соседа по потоку не могут быть на одном интерфейсе — другими словами, два соседних соседа в направлении от сегмента LAN. То же самое происходит в том случае, если интерфейсом вышестояного канала является интерфейс многоастных туннелей.

  • Обнаружение максимальных конечных маршрутов размеженого потока не поддерживается. Приемник на стороне (на стороне получения) устройства маршрутации только позволяет убедиться в том, что существует несоединяющееся устройство отбоя (непосредственный предыдущий переход). PIM и многоточки LDP не поддерживают эквивалент явных объектов маршрутов (EROs). Таким образом, обнаружение несоотвеченного пути входящего потока ограничено контролем непосредственного устройства предыдущего перехода. В связи с этим ограничением, можно использовать общий путь к устройству входящего потока предыдущего перехода, выбранного в качестве основного и резервного.

  • Некоторые потери трафика можно увидеть в следующих сценариях:

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

    • MoFRR включен или отключен на устройстве для выпадания при активном потоке трафика.

  • Балансировка нагрузки присоединиться PIM для сообщений join для резервных путей не поддерживается.

  • Для многоадрентной группы G сообщения MoFRR (S,G) и (*,G) не допускаются. (S,G) сообщения о присоединиться имеют приоритет над (*,G).

  • MoFRR не поддерживается для многоадритных потоков трафика, которые используют две разные группы многоафров. Каждая комбинация (S,G) рассматривается как уникальный многоадронный поток трафика.

  • В MoFRR не поддерживается многонаправленный диапазон PIM.

  • Плотный режим PIM не поддерживается MoFRR.

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

  • Мониторинг скорости не поддерживается.

Ограничения MoFRR на коммутаторных устройствах с PIM

MoFRR с PIM имеет следующие ограничения на коммутаторных устройствах:

  • MoFRR не поддерживается, если вышестояющий интерфейс является интегрированным интерфейсом маршрутизации и запарачивания (IRB), который влияет на другие функции многоарендной вещания, такие как управление интернет-протоколом версии 3 (IGMPv3) функции Snooping.

  • Репликация пакетов и многоадреционный просмотр во время пересылания многоададного трафика могут вызвать повторяемую пересыла В результате отображаемые в этой команде значения для многоастных пакетов могут показать большее число, чем ожидалось в выходных полях, таких как show pfe statistics trafficInput packets и Output packets . Такое поведение можно чаще заметить в сценариях MoFRR, так как дублирование основного и резервного потоков в целом увеличивает поток трафика.

Ограничения и ограничения MoFRR на устройствах маршрутизации с многоточкильным LDP

У MoFRR есть следующие ограничения и ограничения на маршрутизаторах при их использования с многоточкильным LDP:

  • MoFRR не применяется к многоточкильму трафику LDP, полученному по туннелю RSVP, поскольку туннель RSVP не связан ни с любым интерфейсом.

  • Смешанный upstream MoFRR не поддерживается. Это относится к многоточки LDP-сигнализации PIM, когда один путь входящего потока проходит через многоточки LDP, а второй путь входящего потока – через PIM.

  • Многоточки lDP-метки как внутренние метки не поддерживаются.

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

  • Целевые сеансы LDP входящего потока не выбираются в качестве устройства отбоя для MoFRR.

  • Защита многоканальных соединений LDP на резервном пути не поддерживается, так как внутренние метки MoFRR не поддерживаются.

Настройка быстрой перенастройки только для многоастройной вещания

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

Когда быстрая перемаршрутизация к однонаказанным потокам, вышестоячий маршрутизатор предварительно MPLS метки-коммутаторными путями (LSPs) или precomputes IP loop-free alternate (LFA) быстрая перемаршрутизация резервного пути для обработки сбоев сегмента в 9-ом пути.

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

  • В сериях QFX MoFRR поддерживается в доменах PIM.

  • На серия MX и серия SRX, MoFRR поддерживается в доменах PIM и многоточки LDP.

Действия по настройке одинаковы для включения MoFRR для PIM на всех устройствах, поддерживаюющих эту функцию, если не указано иное. Также указаны действия по настройке, которые не применимы к многоточки LDP MoFRR.

(Только серия MX маршрутизаторами) MoFRR поддерживается на серия MX с картами линии MPC. В качестве предварительного условия все карты линии в маршрутизаторе должны быть MPC.

Настройка MoFRR на маршрутизаторах и коммутаторах:

  1. (Только серия MX серия SRX маршрутизаторов) Установите для маршрутизатора расширенный IP-режим.
  2. В включить MoFRR.
  3. (Необязательно) Настройте политику маршрутизации, которая фильтрует ограниченный набор многоадритных потоков, на который влияет конфигурация MoFRR.

    Можно применять фильтры, основанные на адресах источника или групп.

    Например:

  4. (Необязательно) Если была настроена политика маршрутизации для фильтрации набора групп многоарентной передачи, на которые влияет конфигурация MoFRR, примените политику защиты потока MoFRR.

    Например:

  5. (Необязательно) В домене PIM с MoFRR разрешайте применять MoFRR к многоадвартным (ASM) любого источника (*,G) присоединяется.

    Это не поддерживается для многоточки LDP MoFRR.

  6. (Необязательно) В домене PIM с MoFRR разрешайте выбор только размеженого RPF (RPF на отдельной плоскости) в качестве резервного пути RPF.

    Это не поддерживается для многоточки LDP MoFRR. В многоточки домене LDP MoFRR общая метка разделяется между параллельными соединениями с тем же соседом в направлении к верхнему потоку. Это не случай в домене PIM, где каждый соединение формирует соседа. Утверждение mofrr-disjoint-upstream-only не позволяет выбрать резервный путь RPF, если путь переходит к этому же соседу в направлении к источнику, что и основной путь RPF. Это гарантирует, что MoFRR запускается только в топологии с несколькими верхними соседями RPF.

  7. (Необязательно) В домене PIM с MoFRR предотвращает отправку сообщений join на резервном пути, но сохраняет все функции MoFRR.

    Это не поддерживается для многоточки LDP MoFRR.

  8. (Необязательно) В домене PIM с MoFRR разрешайте выбор нового основного пути на основе выбора одноадростного шлюза для одноадростного маршрута к источнику и изменения при изменении в выборе одноастерной вещания, вместо того, чтобы резервный путь был назначен основным. Это гарантирует, что основной переход RPF всегда находится на наилучшем пути.

    Если вы включаете утверждение, путь резервного копирования не гарантируется, что он будет назначен новым основным путем, когда основной mofrr-primary-selection-by-routing путь отключится.

    Это не поддерживается для многоточки LDP MoFRR.

Примере: Настройка быстрой перенастройки в многоканальных LDP-доменах

В этом примере показано, как настраивать передачу только для многоа быстрая перемаршрутизация (MoFRR) для минимизации потерь пакетов в сети в случае сбоя в соединении.

Многоточкиальный LDP MoFRR используется на выпускном узле MPLS сети, где пакеты переадресуются в IP-сеть. В случае многоточки LDP MoFRR два пути к оконечным (PE) маршрутизаторам вышестоястого поставщика (PE) устанавливаются для получения двух потоков MPLS пакетов на метке граничный маршрутизатор (LER). Один поток (основной) принимается, а другой (резервный) отброшен на LER. Резервный поток принимается при сбойе основного пути.

Требования

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

В многоточкином домене LDP для работы MoFRR необходимо, чтобы MoFRR был включен только для маршрутизатора pe на выпуске. Другим маршрутизаторам не требуется поддержка MoFRR.

MoFRR поддерживается на серия MX с картами линии MPC. В качестве предварительного условия необходимо настроить маршрутизатор в режиме, а все линк-карты платформы network-services enhanced-ip должны быть MPC.

Для этого примера требуется Junos OS версии 14.1 или более поздней на выходе PE-маршрутизатора.

Обзор

В данном примере устройство R3 является выпадающее граничный маршрутизатор. MoFRR включен только на этом устройстве.

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

Для целей тестирования маршрутизаторы используются для имитации источника и приемника. Устройство R4 и устройство R8 настроены на статическое присоединиться к нужной группе с помощью set protocols igmp interface interface-name static group group команды. Эта статическая конфигурация IGMP полезна в случае, когда реальный хост-приемник многоарной трансляции не доступен, как в этом примере. В этом примере приемники прослушивают адрес многоарной set protocols sap listen group группы.

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

Топологии

Рис. 16 отображает пример сети.

Рис. 16: MoFRR в многоточкином домене LDPMoFRR в многоточкином домене LDP

интерфейс командной строки быстрой конфигурации отображает конфигурацию всех устройств Рис. 16 в.

В разделе Конфигурации описаны действия устройства R3.

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

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

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

Устройство src1

Устройство src2

Устройство R1

Устройство R2

Устройство R3

Устройство R4

Устройство R5

Устройство R6

Устройство R7

Устройство R8

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

Процедуры

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

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

Для настройки устройства R3:

  1. В режиме улучшенного IP-адреса.

  2. Настройте интерфейсы устройств.

  3. Настройте номер автономной системы (AS).

  4. Настройте политики маршрутов.

  5. Настройте PIM.

  6. Настройте LDP.

  7. Настройте IGP или статические маршруты.

  8. Настройте внутреннюю BGP.

  9. Настройте MPLS и, дополнительно, RSVP.

  10. В включить MoFRR.

Результаты

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

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

Проверки

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

Проверка классов эквивалентности точек переадности между точками LDP

Цель

Убедитесь, что moFRR включен, и определите используемые метки.

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

Выходные данные показывают, что moFRR включен, и он показывает, что метки 301568 и 301600 используются для двух многоточки LDP точек LDP для многоточки LDP-точек LPS.

Анализ информации метки

Цель

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

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

Выходные данные показывают основные пути от линии к линии и резервные пути от линии к линии. Он также отображает следующие переходы RPF.

Проверка многоастерстных маршрутов

Цель

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

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

Выходные данные показывают первичные и резервные сеансы, а также следующие переходы RPF.

Проверка статистики трафика между точками LDP

Цель

Убедитесь, что указаны первичные и резервные статистические данные.

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

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

Примере: Настройка ходящего потока LDP по требованию

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

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

Требования

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

  • M Series маршрутизатор

  • Junos OS 12.2

Обзор

Для сеанса LDP можно включить объявление LDP 9stream-метки по требованию, включив в нее утверждение "downstream on-demand" на [edit protocols ldp session] уровне иерархии. Если маршрутизатор, находящийся в потоке по требованию, Juniper Networks о запросе по требованию 9-го потока своим равноправным маршрутизаторам. Чтобы 9-ой сеанс по требованию был установлен между двумя маршрутизаторами, оба должны объявлять ходящий режим по требованию во время установления сеанса LDP. Если один маршрутизатор объявляет 9-ой незатвершенный режим, а другой — 9-й по требованию, то в 9-ом режиме используется незатвершенный режим.

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

Настройка ходящего потока LDP по требованию

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

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

  1. Настройте 9-ую политику по требованию (в этом примере – DOD-Request-Loopbacks).

    Эта политика заставляет маршрутизатор переадрикировать сообщения запроса метки только на FEC, которые совпадают с политикой DOD-Request-Loopbacks.

  2. Укажите политику DOD-Request-Loopbacks с помощью утверждения dod-request-policy на [edit protocols ldp] уровне иерархии.

    Политика, заданная с помощью этого утверждения, используется для идентификации префиксов для dod-request-policy отправки сообщений запроса метки. Эта политика схожа с политикой на выпадение или импортной политикой. При обработке маршрутов из таблицы маршрутов inet.0 программа Junos OS проверяет маршруты, совпадающие с политикой DOD-Request-Loopbacks (в этом примере). Если маршрут соответствует политике, и сеанс LDP согласовываться с режимом объявления DOD, сообщения запроса метки отправляются на соответствующий 9-ой сеанс LDP.

  3. downstream-on-demandВключит утверждение в конфигурацию для сеанса LDP, чтобы включить 9-ой режим распределения по требованию.

Распределение ходящего потока LDP на маршрутах по требованию на помеченные BGP

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

Для распределения ходящего потока LDP по маршрутам по требованию в BGP метку используйте BGP экспорта.

  1. Настройте политику маршрутов LDP redistribute_ldp (в этом примере).

  2. Включив политику маршрутов LDP в конфигурацию BGP (в качестве части redistribute_ldp BGP группы в этом ebgp-to-abr примере).

    BGP маршруты LDP на основе политики на redistribute_ldp удаленный маршрутизатор PE

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

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

  1. Настройте политику dod-routes на прием маршрутов из LDP.

  2. Настройте политику do-not-propagate-du-sessions так, чтобы маршруты не перенастилались 1.1.1.1 соседним 2.2.2.2 маршрутизаторам, и 3.3.3.3 .

  3. Настройте политику так, чтобы маршруты, проверяемые политикой, не были перенаадланы соседним маршрутизаторам, filter-dod-on-du-sessionsdod-routes определенным в do-not-propagate-du-sessions политике.

  4. Укажите filter-dod-routes-on-du-sesssion политику в качестве экспортной политики для BGP ИБП. ebgp-to-abr

Результаты

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

Проверки

Проверка режима объявления метки

Цель

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

Используйте эту show ldp session команду для проверки состояния режима объявления метки для сеанса LDP.

Действий

В show ldp session командах show ldp session detail и командах:

  • Следующий вывод команды показывает, что (режим объявления show ldp session меток) Adv. ModeDOD (т.е. 9-ой сеанс LDP по требованию является рабочим):

  • Следующий результат команды показывает, что значение по умолчанию (означая, что входящий по требованию не настроен show ldp session detailLocal Label Advertisement mode на Downstream unsolicited локальном сеансе). И наоборот, оба указывают на то, что Remote Label Advertisement modeNegotiated Label Advertisement modeDownstream on demand настроены на удаленном сеансе

Настройка поддержки LDP Native IPv6

LDP поддерживается в сети только iPv6 и в сети с двумя стеками IPv6 или IPv4, как описано в RFC 7552. Настройте семейство адресов как inet для IPv4 или inet6 для IPv6 IPv4 или обоих, а также в качестве транспортного предпочтения. IPv6 Утверждение позволяет Junos OS LDP установить TCP-соединение через IPv4 с соседями IPv4 и через IPv6 с соседями IPv6 в качестве одиночного dual-transport LSR. ID и ID — это два LSR, которые должны быть настроены для установления LDP-сеанса через транспортировку inet-lsr-idinet6-lsr-id IPv4 и IPv6 TCP. Эти два ID должны быть ненулевыми и должны быть настроены с различными значениями.

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

Чтобы настроить поддержку LDP native IPv6, необходимо сделать следующее:

  1. Чтобы использовать различные метки для различных семейство адресов, необходимо включить дезогрегрирование класса equivalence (FEC).
  2. Настройте семейства адресов LDP.
  3. Настройте утверждение для выбора предпочтительного транспорта для transport-preference TCP-соединения, если включены IPv4 и IPv6. По умолчанию IPv6 используется в качестве транспорта TCP для установления LDP-соединения.
  4. (Необязательно) Настройте двойные транспортные режимы, чтобы разрешить LDP устанавливать отдельный сеанс IPv4 с соседом IPv4 и сеанс IPv6 с соседом IPv6. Настройте в качестве LSR ID для IPv4 и в LSR inet-lsr-idinet6-lsr-id IPv6.

    Например, настройте inet-lsr-id как 10.255.0.1, а inet6-lsr-id как 1.1.1.1.

Примере: Настройка поддержки LDP Native IPv6

В этом примере показано, как разрешить протоколу распределения Junos OS меток (LDP) установить TCP-соединение через соседей IPv4 и через IPv6 с соседями IPv6 в одном стеке LSR. Это помогает избежать туннелировать IPv6 через IPv4 MPLS с помощью IPv4-сигнальных MPLS-коммутаторов (LSP).

Требования

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

  • Два серия MX маршрутизатора

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

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

Обзор

LDP поддерживается только в сети IPv6 и в сети с двойным стеком IPv6 или IPv4, как описано в RFC 7552. Настройте семейство адресов как inet для IPv4, inet6 так и для IPv6. По умолчанию IPv6 используется в качестве транспорта TCP для сеанса LDP со своими однорангами, когда IPv4 и IPv6 включены. Двух-транспортный режим позволяет LDP Junos TCP-соединение через IPv4 с соседями IPv4 и через IPv6 с соседями IPv6 в качестве одностекного LSR. И есть два LSR, которые должны быть настроены для установления LDP-сеанса через inet-lsr-idinet6-lsr-id транспортировку IPv4 и IPv6 TCP. Эти два ID должны быть ненулевыми и должны быть настроены с различными значениями.

Топологии

Рис. 17 отображает LDP IPv6, настроенный как двойной стек на устройстве R1 и устройстве R2.

Рис. 17: Пример поддержки LDP Native IPv6Пример поддержки LDP Native IPv6

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

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

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

R1

R2

Настройка R1

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

В следующем примере иерархия конфигурации требует перемещения по разным уровням. Для получения информации о навигации по интерфейс командной строки см. « « В руководстве Junos OS интерфейс командной строки Using the CLI Editor in Configuration Modeпользователя).

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

  1. Настройте интерфейсы.

  2. Назначьте устройству адрес обратной связи.

  3. Настройте IS-IS интерфейсов.

  4. Настройте MPLS использовать LDP-интерфейсы на устройстве.

  5. Чтобы использовать различные метки для различных семейство адресов, необходимо включить дезогрегрирование класса equivalence (FEC).

  6. Настройте семейства адресов LDP.

Результаты

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

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

интерфейс командной строки быстрой конфигурации
Пошаговая процедура

Можно настроить утверждение для выбора предпочтительного транспорта для transport-preference TCP-соединения, если включены IPv4 и IPv6. По умолчанию IPv6 используется в качестве транспорта TCP для установления LDP-соединения.

  • (Необязательно) Настройте транспортное предпочтение для LDP-соединения.

Пошаговая процедура
Результаты

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

Настройка двойного переноса для установления отдельных сеансов для IPv4 с соседом IPv4 и IPv6 с соседом IPv6

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

Можно настроить утверждение, чтобы разрешить LDP устанавливать отдельный сеанс IPv4 с соседом dual-transport IPv4 и сеанс IPv6 с соседом IPv6. Для этого требуется настройка в качестве LSR ID для IPv4 и В качестве LSR inet-lsr-idinet6-lsr-id IPv6.

  • (Необязательно) Настройте двойное транспортное соединение, чтобы разрешить LDP установить TCP-соединение через IPv4 с соседями IPv4 и через IPv6, при этом соседи IPv6 будут в одном стеке LSR.

Результаты

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

Проверки

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

Проверка записей маршрутов в таблице mpls.0
Цель

Отображение данных таблицы маршрутов mpls.0.

Действий

На устройстве М1 в рабочем режиме запустите команду для отображения show route table mpls.0 сведений таблицы маршрутов mpls.0.

Смысл

Выходные данные показывают данные таблицы маршрутов mpls.0.

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

Отображение данных таблицы маршрутов inet.3.

Действий

На устройстве М1 в рабочем режиме запустите команду, show route table inet.3 чтобы отобразить информацию таблицы маршрутов inet.3.

Смысл

Выходные данные показывают информацию таблицы маршрутов inet.3.

Проверка записей маршрутов в таблице inet6.3
Цель

Отображение данных таблицы маршрутов inet6.3.

Действий

На устройстве М1 в рабочем режиме запустите команду для отображения show route table inet6.3 сведений таблицы маршрутов inet6.3.

Смысл

Выходные данные показывают информацию таблицы маршрутов inet6.3.

Проверка базы данных LDP
Цель

Отображение сведений из базы данных LDP.

Действий

На устройстве М1 в рабочем режиме запустите команду для show ldp database отображения сведений из базы данных LDP.

Смысл

Выходные данные показывают записи в базе данных LDP.

Проверка информации о соседе LDP
Цель

Отобразить сведения о соседях LDP.

Действий

На устройстве М1 в рабочем режиме запустите команды и для show ldp neighborshow ldp neighbor extensive отображения информации о соседе LDP.

Смысл

Выходные данные показывают сведения о соседях LDP для адресов IPv4 и IPv6.

Проверка информации о сеансе LDP
Цель

Отображение данных сеанса LDP.

Действий

На устройстве М1 в рабочем режиме запустите команды show ldp session и show ldp session extensive отобразите информацию о сеансе LDP.

Смысл

В выходных данных отображается информация о сеансе LDP, использующем IPv6 в качестве транспорта TCP.

Проверки

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

Проверка информации о соседе LDP
Цель

Отобразить сведения о соседях LDP.

Действий

На устройстве М1 в рабочем режиме запустите команду, show ldp neighbor extensive чтобы отобразить информацию о соседе LDP.

Смысл

Выходные данные показывают сведения о соседях LDP для адресов IPv4 и IPv6.

Проверка информации о сеансе LDP
Цель

Отображение данных сеанса LDP.

Действий

На устройстве М1 в рабочем режиме запустите команду для show ldp session extensive отображения информации о сеансе LDP.

Смысл

В выходных данных отображается информация о сеансе LDP, использующем IPv6 в качестве транспорта TCP.

Проверки

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

Проверка информации о соседе LDP
Цель

Отобразить сведения о соседях LDP.

Действий

На устройстве М1 в рабочем режиме запустите команду, show ldp neighbor extensive чтобы отобразить информацию о соседе LDP.

Смысл

Выходные данные показывают сведения о соседях LDP для адресов IPv4 и IPv6.

Проверка информации о сеансе LDP
Цель

Отображение данных сеанса LDP.

Действий

На устройстве М1 в рабочем режиме запустите команду, show ldp session extensive чтобы отобразить информацию о соседе LDP.

Примере: Настройка многоточки LDP-сигнализации в диапазоне для LSP точек-точек

Понимание многоточки LDP-сигнализации для многоканальных LDP-LSP

Многоточкиальный протокол распределения меток (M-LDP) для маршрутов маршрутов с переключениями точек на многоточки (LSP) с сигнализацией в диапазоне полезен при развертывании с существующей магистрали IP/MPLS, в которую нужно переносить многонастоной трафик, например, для IPTV.

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

Однако в существующей СЕТИ IP/MPLS не стоит использовать PIM в первую очередь. Некоторые поставщики услуг заинтересованы в замене IP-туннелизации MPLS меткой. Мотивация перехода к коммутации MPLS меток – использовать управление MPLS-трафиком функции защиты и уменьшить объем ключевых для провайдера затрат на контрольный трафик.

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

Как работает M-LDP

Привязки меток в сигнализации M-LDP

Многоточкивой расширение LDP использует элементы класса equivalence (FEC) между точками и многоточки в многоточки (RFC 5036, спецификация LDP)наряду с объявлениями о возможностях, сопоставлением меток и процедурами сигнализации. Элементы FEC включают идею корневого узла LSP, который является IP-адресом, и "непрозрачной" величины, которая является селектором, который групп предусматривает группу leaf-узлов с одним и тем же opaque значением. Значение opaque прозрачно для промежуточных узлов, но имеет значение для корня LSP. Каждый узел LDP объявляет локовую входящие метки, связывание с вышестоячим LDP-узлом на самом коротком пути к корневому IP-адресу, найденного в FEC. Узел входящего потока, получаюющий привязки меток, создает собственную локскую метку и исходящие интерфейсы. Этот процесс распределения меток может привести к репликации пакетов, если имеется несколько исходяющих ветвей. Как показано в примере, узел LDP объединяет привязки меток для одного и того же непрозрающего значения, если 9-узлы находятся на одном и том же Рис. 18 вышестояком узле. Это обеспечивает эффективное построение точек-многоканальных LPS и сохранение меток.

Рис. 18: Привязки меток в сигнализации M-LDPПривязки меток в сигнализации M-LDP
M-LDP в Ядре без PIM MPLS

Рис. 19 демонстрирует сценарий масштабирования развертывания. Два отдельных домена PIM связаны между собой без PIM-узла ядра. Пограничные маршрутизаторы этого основного узла поддерживают PIM на граничных интерфейсах. Далее, эти пограничные маршрутизаторы собирают и распределяют сведения о маршруте из смежных узлов в основную сеть. На окнях маршрутизаторов узла C BGP для обнаружения корневого узла. Маршруты внутреннего IGP шлюза не могут использоваться для обнаружения впадающего маршрута, поскольку в большинстве случаев следующий переход переадресовки, предоставляемый маршрутизатором IGP не будет предоставлять информацию об входе к источнику. Межполосная сигнализация M-LDP имеет 1-1 сопоставление между точкой-многоточки LSP и (S,G) потоком. При вносимой сигнализации сообщения PIM напрямую преобразуются в привязки FEC M-LDP. По контрасту, вне диапазона сигнализация основана на настройке вручную. Одним из приложений для сигнализации на полосном канале M-LDP является перенос многоканального трафика IPTV по MPLS магистрали.

Рис. 19: Пример топологии M-LDP в Ядре без PIM MPLSПример топологии M-LDP в Ядре без PIM MPLS
Конфигурации

Утверждение конфигурации mldp-inband-signalling на метке-граничный маршрутизатор (LER) позволяет PIM использовать в диапазоне сигнализацию M-LDP для соседей по более верхнему потоку, когда LER не обнаруживает соседа PIM по потоку. Статическая конфигурация корневого MPLS LSP включается в конфигурацию PIM с использованием политики. Это необходимо, если IBGP отсутствует на основной площадке или переопределит обнаружение корневого процессора LSP на основе IBGP.

Например:

M-LDP в Ядре с поддержкой PIM MPLS

Начиная с Junos OS.14.1, для переноса существующих сервисов IPTV с исходного многоадресная передача по протоколу IP на MPLS многоаддровую передачу необходимо плавно переходить от PIM к многоканальных LSP M-LDP с минимальным сбоем. Рис. 20 показывает сходную топологию M-LDP, Рис. 19 но с другим сценарием. Ядро включено с помощью PIM, при этом один источник передает все каналы IPTV. Телевизионные каналы отправляются в качестве asM-потоков, каждый канал которых определен по своему групповому адресу. Ранее эти каналы были потоками по ядру в качестве IP-потоков и сигнализировали с помощью PIM.

Рис. 20: Пример топологии M-LDP в Ядре с поддержкой PIM MPLSПример топологии M-LDP в Ядре с поддержкой PIM MPLS

Настройка этого сценария инициализирует сигнализацию M-LDP только когда нет соседа mldp-inband-signaling PIM по направлению к источнику. Однако, поскольку PIM всегда находится соседом PIM по направлению к источнику, если PIM не деактивирован на интерфейсах отходящего потока PE, PIM имеет преимущество над M-LDP, а M-LDP не действует.

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

Для последовательной миграции канала по каналу в ядро M-LDP MPLS с использованием нескольких потоков, использующих передачу от M-LDP и других потоков с использованием существующего выше PIM, включите утверждение конфигурации наряду с фильтрами на основе групп в фильтре политики для многополосной сигнализации selected-mldp-egress M-LDP.

Прим.:

Фильтр политики политики сигнализации для inband M-LDP может включать либо source-address-filter утверждение, либо утверждение, либо route-filter комбинацию обоих политик.

Например:

Прим.:

Некоторые ограничения вышеуказанной конфигурации:

  • Утверждение selected-mldp-egress должно быть настроено только на LER. Настройка утверждения selected-mldp-egress на невыпадающих маршрутизаторах PIM может привести к ошибкам установки пути.

  • Когда внесены изменения политики для коммутации трафика от PIM отходящего к вышестоячему трафику M-LDP и наоборот, потери пакетов можно ожидать, так как механизм break-and-make выполняется на плоскость управления.

Терминологии

Следующие термины важны для понимания многоандной сигнализации M-LDP в диапазоне.

LSP "точка-точка"

LSP с одним маршрутизатором с коммута указаной меткой (LSR) и одним маршрутизатором на LSR.

Многоточки LSP

LSP между точками или многоканальный LSP.

многоканальный LSP

LSP, который имеет один LSR и один или несколько выпаденых LSRs.

многоканальный LSP

LSP, который имеет один или несколько влиятелей LSRs и один уникальный LSR.

многоканальный LSP

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

Ветвь LSR

Маршрут в LSR LSP – это маршрут, LSR, который может отправлять пакеты данных по LSP. Многоточкиовые LSP могут иметь несколько ветвных LSRs. Многоканальный LSP имеет только один LPS, и этот узел часто называют корневым узлом.

Выпадение LSR

Выходная LSR определенного LSP – это LSR, который может удалить пакет данных из этого LSP для дальнейшей обработки. LPS "точка-точка" и "многоточки", имеют только один узел для выплытия. LPS "точка-многоточки" и многоканальный LPS могут иметь несколько выпаденых узлов.

Транзитные LSR

Точка LSR, которая имеет возможность достичь корня многоточки LSP через напрямую подключенный к LSR и один или несколько непосредственно подключенных 9-х LSRs.

Bud LSR

Одно LSR является выходящий, но с одним или более непосредственно подключенными 9-ми LSRs.

Leaf-узел

В контексте многоканального LSP LSR как "выход". В контексте многоканального LSP с многоточки зрения LSR как в рамках веского, так и для одного и того же многоточки LSP и может также явную LSR.

Обработка вгрузного и псевдо-интерфейса

При впуске LER LDP извещение PIM о (S,G) сообщениях, полученных во время сигнализации в диапазоне. PIM связывает каждое (S,G) сообщение с псевдо-интерфейсом. Затем к источнику инициировался сообщение блоки кратчайших путей (SPT). PIM рассматривает это как новый тип локального приемника. Когда LSP размыкается, PIM удаляет этот локальный приемник на основе уведомления от LDP.

Нарезка на врезе

LDP предоставляет PIM следующий переход, который будет связан с каждой записью (S,G). PIM устанавливает многоадварный маршрут PIM (S,G) со следующим переходом LDP и другими приемниками PIM. Следующий переход является составным следующим переходом локальных приемников + список нижестояких соседей PIM + следующий субуровневый переход для туннеля LDP.

Реверсивная переадваровка пути

Расчет обратного пути переадресовки (RPF) PIM выполняется на узле для выпадающего (egress) узла.

PIM выполняет в диапазоне сигнализацию M-LDP при выполнении всех следующих условий:

  • Нет соседей PIM к источнику.

  • Настраивается утверждение сигнализации M-LDP в диапазоне.

  • Следующий переход определяется через BGP или присутствует в статическом сопоставлении (указано в политике сигнализации в диапазоне M-LDP).

В противном случае, если обнаружение корневого LSP не удается, PIM сохраняет запись (S,G) с неурегулированным состоянием RPF.

PIM RPF регистрирует этот исходный адрес каждый раз при изменениях информации одноастрной маршрутки. Таким образом, если маршрут к источнику изменяется, пересчет RPF повторяется. BGP следующие переходы протокола к источнику также отслеживаются на основе изменений в корне LSP. Такие изменения могут привести к нарушению трафика на короткий период времени.

Обнаружение корневого LSP

Если операция RPF обнаруживает необходимость Входящего сигнального сигнала M-LDP входящего потока, то обнаруживается корневой (входящий) LSP. Этот корневой является параметром для сигнализации LDP LSP.

Корневой узел обнаруживается следующим образом:

  1. Если в существующей статической конфигурации указан адрес источника, то корневой адрес определяется как указано в конфигурации.

  2. В таблице одноастной маршрутки выполняется просмотр. Если адрес источника найден, протокол следующего перехода к источнику используется в качестве корневого LSP.

    До Junos OS выпуска 16.1 многоканальный LSP M-LDP сигнализируется от выходного сигнала к впуску с использованием корневого адреса впускного LSR. Этот корневой адрес достижим только IGP, что ограничивает точку M-LDP многоточки LSP отдельной автономной системой. Если корневой адрес не достигается через IGP, но достижим через BGP, и если этот BGP MPLS маршрут рекурсивно рекурсивным LSP, то LSP "точка-многоточки" не будет сигнализироваться дальше от этой точки к корневому LSR-адреса.

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

    • Inter-AS MVPN с не сегментными LSP «точка-многоканальный».

    • Межсетевая сигнализация M-LDP между клиентской сетью, подключенной MPLS основной сетью.

    • Межрегиональная сигнализация MVPN или M-LDP с не сегментными LSP между точками (seamless MPLS многоарендными).

    Начиная с Junos OS 16.1, M-LDP может сигнализировать многоканальный LSP на ASBR или транзите или выходе, когда корневой адрес является BGP, который далее рекурсивно рекурсивным MPLS LSP.

Обработка join translation и псевдо-интерфейса на выгрузку

На egress LER PIM извещение LDP сообщения (S,G) о сигнализации наряду с корневым LSP. PIM создает псевдо-интерфейс в качестве интерфейса входящего потока для этого сообщения (S,G). Когда получено (S,G) сообщение об отсеижении, это ассоциация удаляется.

Размыкание на отрезоке

На выходящего узле ядра сети, где с 9-го узла получается сообщение join (S,G), это сообщение join транслется в параметры сигнализации M-LDP в диапазоне, и LDP извещен. Более того, разрыв LSP происходит при утере (S,G) записи, при смене корневого LSP или когда запись (S,G) достигается через соседа PIM.

Поддерживаемые функциональные возможности

Для многодиандной сигнализации M-LDP Junos OS поддерживают следующие функции:

  • Размыкание на части следующего перехода PIM с маршрутом LDP

  • Впускная соединая часть маршрута PIM со следующим переходом LDP

  • Трансляция сообщений join PIM в параметры настройки LSP о точках LSP о точках LDP

  • Трансляция параметров LSP M-LDP в диапазоне для того, чтобы настроить сообщения join PIM

  • Обнаружение корневого LSP на BGP на основе следующего перехода в режиме статической настройки и протокола

  • Состояния PIM (S,G) в диапазонах PIM, специфических для многоадретных вещания (SSM) и anysource multicsast (ASM)

  • Утверждения конфигурации на впадаемом и выпадаемом ЛЕР, чтобы позволить им действовать в качестве граненых маршрутизаторов

  • Сообщения о присоединиться к IGMP на ЛЕР

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

  • Статическая конфигурация для карты IPv6 (S,G) на корневой адрес IPv4

Неподтвердимые функции

Для многодиандной сигнализации M-LDP Junos OS не поддерживает следующие функции:

  • Полная поддержка PIM ASM

  • Команда mpls lsp point-to-multipoint ping с параметром (S,G)

  • Неполная активная маршрутная (NSR)

  • Передрыв (MBB) для PIM

  • Корневые адреса IPv6 LSP (LDP не поддерживает LSP IPv6.)

  • Отношения соседей между динамиками PIM, которые не соединены напрямую

  • Хламный перезапуск

  • Плотный режим

  • Многонаправленный режим PIM

Функциональные возможности LDP

Информация PIM (S,G) передается как кодиры типа длины M-LDP (TLV). Элемент FEC между точками состоит из адреса корневого узла. В случае многоадрастных VPN нового поколения (NGEN MVPNs), LSP точки-многоточки опознается по адресу корневого узла и LSP ID.

Функциональные возможности выпадаемого LER

На выпадаемом LER PIM инициирует LDP со следующей информацией, чтобы создать LSP между точками:

  • Корневой узел

  • (S,G)

  • Следующий переход

PIM находит корневой узел на основе источника многоададного дерева. Если для данной записи (S,G) настроен корневой адрес, он будет использоваться как корневой LSP "точка-многоточки". В противном случае таблица маршрутов используется для того, чтобы найти маршрут к источнику. Если маршрут к источнику многоадстерного дерева является BGP, PIM извлекает BGP адреса следующего перехода и использует его в качестве корневого узла для LSP точки-многоточки.

LDP находит вышестоячий узел на основе корневого узла, выделяет метку и отправляет сопоставление меток на вышестоячий узел. LDP не использует предпоследнее выталкивение (PHP) для сигнализации M-LDP в диапазоне.

Если корневые адреса источника многоадстерного дерева меняются, PIM удаляет многоканальный LSP с разных точек и запускает LDP для создания нового многоканального LSP. Когда это происходит, список выходных интерфейсов становится NULL, PIM запускает LDP для удаления LSP точки-многоточки, и LDP отправляет сообщение метки в вышестоячий узел.

Функции транзитного LSR

Транзитный LSR передает метку вышестоячему LSR источнику точки-многоканального FEC и устанавливает необходимое состояние переадстройки для переадстройки пакетов. Транзитным LSR может быть любой M-LDP-маршрутизатор.

Функциональные возможности впадаемого LER

На впуске LER LDP предоставляет PIM следующую информацию при получении сопоставления меток:

  • (S,G)

  • Затоплите следующий переход

После этого PIM устанавливает состояние forwarding. Если новые ветви добавляются или удаляются, то поток следующего перехода обновляется соответствующим образом. Если все ветви удалены из-за удаления метки, LDP передает PIM обновленную информацию. Если имеется несколько связей между соседними точками вышестояного и 9-го уровня, то LSP между точками точки не сбалансирован по нагрузке.

Примере: Настройка многоточки LDP-сигнализации в диапазоне для LSP точек-точек

В этом примере показано, как настраивать многоточки LDP (M-LDP) в качестве сигнализации для многоадлинного трафика в качестве расширения протокола независимой многоарендной передачи (PIM) протокола или в качестве замены PIM.

Требования

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

  • Junos OS версии 13.2 или более поздней

  • серия MX универсальных платформ маршрутов 5G или M Series мультисервисных ежежных маршрутизаторов для маршрутизаторов edge поставщика (PE)

  • серия PTX в качестве транзитных коммутаторов с меткой

  • серия T маршрутизаторы ядра для основных маршрутизаторов

Прим.:

Маршрутизаторы PE также могут быть серия T основными, но это не типично. В зависимости от требований к масштабирования, основные маршрутизаторы могут быть также серия MX универсальными серия MX маршрутизируемыми платформами 5G или M Series маршрутизаторами Multiservice Edge. Устройства Customer Edge (CE) могут быть другими маршрутизаторами или коммутаторами от Juniper Networks или другого поставщика.

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

Обзор

интерфейс командной строки быстрой конфигурации отображает конфигурацию всех устройств Рис. 21 в. В этом #d158e60__d158e615 разделе описаны действия по устройству EgressPE.

Рис. 21: Пример топологии многоканальных LSPs для многоканальных сигналов M-LDP в диапазонеПример топологии многоканальных LSPs для многоканальных сигналов M-LDP в диапазоне

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

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

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

Устройство src1

Device IngressPE

Устройство EgressPE

Устройство p6

Устройство pr3

Устройство pr4

Устройство pr5

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

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

Для настройки Device EgressPE:

  1. Настройте интерфейсы.

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

  2. Настройте IGMP на интерфейсах для выпадаемых интерфейсов.

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

  3. Настройте MPLS интерфейсах с основными интерфейсами.

  4. Настройте BGP.

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

    Например, может потребоваться экспорт статических маршрутов в BGP.

  5. (Необязательно) Настройте одноранговую связь MSDP с устройством pr5, чтобы связывать разрознние доменов PIM, тем самым предоставляя избыточные РС.

  6. Настройте OSPF.

  7. Настройте LDP на интерфейсах с основными интерфейсами и на интерфейсе обратной связи.

  8. В enable point-to-multipoint MPLS LPS.

  9. Настройте PIM на 9-х интерфейсах.

  10. Настройте параметры RP, так как это устройство служит точкой встречи PIM (RP).

  11. В включить в диапазоне сигнализацию M-LDP и настроить связанную политику.

  12. Настройте политику маршрутов, которая определяет корневой адрес для LSP точки-многоточки и связанных адресов источника.

  13. Настройте ID автономной системы (AS).

Результаты

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

Устройство EgressPE

Аналогичным образом настройте другие выпадаемые устройства.

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

Проверки

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

Проверка состояния присоединиться PIM
Цель

Отображение сведений о состояниях присоединиться PIM для проверки сведений о M-LDP входящего и ходящего потоках. На входящего устройства отображается show pim join extensive команда Pseudo-MLDP для 9-го интерфейса. На отступе команда show pim join extensive отображается для Pseudo-MLDP вышестояходящего интерфейса.

Действий

В рабочем режиме введите show pim join extensive команду.

Проверка источников PIM
Цель

Убедитесь, что у источников PIM ожидаемые данные о M-LDP входящего и ходящего потока.

Действий

В рабочем режиме введите show pim source команду.

Проверка базы данных LDP
Цель

Убедитесь, что эта команда отображает ожидаемые привязки корневого к show ldp database (S,G) связывания.

Действий
Поиск информации о маршруте для MPLS метки
Цель

Отобразить сведения о FEC с разных точек.

Действий
Проверка статистики трафика LDP
Цель

Отслеживайте статистику трафика данных для многоканальных LSP.

Действий

Обзор сервера сопоставления LDP для возможности сегментной маршрутации с LDP

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

Функция сервера сопоставления LDP реализуется с помощью OSPF или ISIS.

Использование возможности сегментной маршрутной маршрутации с LDP OSPF

Для реализации возможности сегментной маршрутации с LDP с использованием OSPF создается расширенное префиксное объявление состояния соединения (LSA) с типом диапазона, длиной и значением (TLV) для всех префиксов LDP, а маршруты сопоставления, соответствующие префиксу, устанавливаются в таблицы маршрутов inet.3 и mpls.0.

Рис. 22 – простая топология сети LDP, используемая для иллюстрации возможности сегментной маршрутации с устройствами LDP с OSPF. Топология имеет шесть устройств (Устройства R1, R2, R3, R4, R5 и R6) с переносом маршрутов из LDP в сегмент.

Рис. 22: Пример топологии LDP с использованием возможности сегментной маршрутации с LDP OSPFПример топологии LDP с использованием возможности сегментной маршрутации с LDP OSPF

В вышеуказанной топологии устройства R1, R2 и R3 поддерживают только сегментную маршрутику, устройства R5 и R6 поддерживают только LDP, а устройство R4 поддерживает как LDP, так и сегментную маршрутику. В этом состоянии устройство R1 не может работать с устройством R6 из-за проблем с возможности использования.

Чтобы обеспечить возможность взаимодействия между устройствами, способными LDP, и устройствами сегментной маршрутации, любой один интерфейс устройства в сегменте маршрутной сети в сегменте сети настраивается в качестве сервера сопоставления LDP. В настоящее время сервер сопоставления настраивает префиксы на [edit routing-options source-packet-routing] уровне иерархии. С помощью этой функции конфигурация сервера сопоставления LDP, если применяется к уровню иерархии, где новый расширенный префикс LSA с диапазоном TLV для всех префиксов LDP объявляется [edit protocols ospf] OSPF. Устройство, которое работает в сегментной маршрутизаации, анализирует TLV расширенный диапазон префиксов, и маршруты сопоставления, соответствующие префиксу, устанавливаются в таблицы маршрутов inet.3 и mpls.0.

Например, если устройство R2 (в сети сегментной маршрутации) является сервером сопоставления LDP, будет включена Рис. 22 следующая конфигурация:

Прим.:

В качестве ip-адреса используется адрес обратной связи устройства в сети LDP (в данном примере устройство start-prefix R5).

Когда конфигурация сервера сопоставления LDP зафиксирована на устройстве R2, TLV расширенного префикса распространяется по всей OSPF области. Устройства, способные сегментную маршрутацию (устройства R1, R2 и R3), устанавливают OSPF сегментных маршрутов маршрутов для указанного адреса обратной связи с индексом ID (SID) сегмента. Индекс SID также обновляется в таблице маршрутов mpls.0 устройствами сегментной маршрутации.

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

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using OSPF

  • Конфликты префиксов обнаруживаются только в конфигурации источника. При конфликте диапазона префиксов преобладает SID префикса из более низкого ID маршрутизатора. В таких случаях генерируется сообщение об ошибке RPD_OSPF_PFX_SID_RANGE_CONFLICT системного журнала.

  • Префиксы IPv6 не поддерживаются.

  • Затопление OSPF префикса Opaque LSA, созданных сервером сопоставления сегментов для автономных систем (ASS) не поддерживается.

  • Функции сервера сопоставления LDP между зонами не поддерживаются.

  • Функции ABR расширенного префикса Opaque LSA не поддерживаются.

  • Функции ASBR расширенного префикса Opaque LSA не поддерживаются.

  • Сервер TLV для отображения сегментов маршрутов не поддерживается.

Возможности сегментной маршрутации с LDP при помощи ISIS

Для реализации возможности сегментной маршрутации с LDP с использованием ISIS требуется конфигурация server-client для протоколов ISIS и LDP, а маршруты из таблиц inet.3 или inet.0 используются для сшивание сегментной маршрутизации LSP с LSP LDP и наоборот.

Рис. 23 – простая топология сети LDP, используемая для иллюстрации возможности межсетевой маршрутной связи сегментных устройств с устройствами LDP с использованием функции сопоставления сервера-клиента LDP. Топология имеет четыре устройства edge поставщика (PE) (Устройства PE1, PE2, PE3 и PE4) и четыре устройства поставщика (P) (Устройства P5, P6, P7 и P8).

Рис. 23: Пример топологии LDP с возможности сегментной маршрутации с LDP с использованием ISISПример топологии LDP с возможности сегментной маршрутации с LDP с использованием ISIS

Устройства PE3, PE4, P6, P7 и P8 являются устройствами, способными на решение LDP. Устройства PE1, PE2, P5 и P6 способны к сегментной маршрутиации с глобальным блоком сегментной маршрутации (SRGB) значениями 100 и 200, а также значениями ID сегментов узлов (SID) 101, 102,105 и 106 соответственно.

Чтобы поток обслуживания был туннелироваться с устройства PE3 и устройства PE1 с использованием непрерывного MPLS туннеля, необходимо использовать острова устройств, поддерживающих сегментную маршрутику и LDP.

LDP Mapping Client Functionality (LDP to Segment Routing)

Функциональность клиента LDP – это сопоставление маршрутов между LDP и сегментами, которое является справа налево потоком Рис. 23 трафика. На устройстве P6 настроена политика отката LDP для объявления всех узлов SID и префиксов SID из сети сегментной маршрутации слева. В результате на устройстве P6 LDP объявляет устройства PE1, PE2 и P5 в качестве связи с меткой FEC для устройства P7.

Устройство PE3 узнало маршрут службы с Устройством PE1 как протокол следующего перехода. Устройство PE3 имеет привязку меток LDP с следующего перехода P8 для PE1 FEC. В результате устройство PE3 отправляет пакет обслуживания устройству P8 в классическом поведение LDP. Устройство P8 имеет привязку метки LDP со своего следующего перехода P7 для PE1 FEC, поэтому устройство P8 пересылает устройство P7 в классическом поведение LDP.

Устройство P7 имеет привязку метки LDP со своего следующего перехода P6 к PE1 FEC, в результате, устройство P7 пересылает устройство P6 в классическом поведение LDP.

Устройство P6that действует как отрезок LDP для PE1 FEC, сширует и заменит входящий сигнал LDP метки для PE1 FEC с эквивалентным узлом сегмента маршрутации SID (101 в этом примере) для переадресации трафика устройству P5.

Устройство P5 всплывет на 101 SID при условии, что устройство PE1 объявляет свой сегмент узла 101 с установленным предпоследним флагом и затем передает трафик устройству PE1. Устройство PE1 обрабатывает туннельный пакет и обрабатывает метку службы.

В результате между устройством PE3 MPLS LSP LSP LDP от устройства PE3 к устройству P6 и связанного сегмента узла от устройства P6 к Device PE1.

LDP Mapping Server Functionality (Segment Routing to LDP)

Функциональность сервера LDP – это сопоставление сегментной маршрутации с LDP, который является слева направо потоком трафика Рис. 23 в. На устройстве P6 конфигурация префиксов сервера сопоставления включена на [edit routing-options source-packet-routing] уровне иерархии. Когда конфигурация применяется в определенном IGP, тип привязки метки, длина и значение (TLV) для всех LDP FEC-меток из сети LDP объявляются как маршруты inet.3 LDP.

В данном примере устройство P6 действует как сервер сопоставления сегментов маршрутов (SRMS) и объявляет следующие сопоставления (P7, 107), (P8, 108), (PE3, 103), (PE4, 104) и (P7, 107). Если бы сегментная маршрутка поддерживалась на устройстве PE3, узел SID 103 был бы настроен на устройстве PE3. Так как устройство PE3 не поддерживает сегментную маршрутику, политика настраивается в SRMS на устройстве P6, а устройство P6 отвечает за объявления сопоставлений.

Данные объявления сервера сопоставления понятны только устройствам сегментной маршрутации. Устройства сегментной маршрутации устанавливают связанные с узлами SID в MPLS плоскость данных точно так, как сегменты узла были объявлены самими узлами. Например, устройство PE1 устанавливает узел SID 103 со следующим переходом P5 точно так, как если бы Устройство PE3 объявлял SID 103.

Устройство PE1 имеет маршрут обслуживания с PE3 в качестве следующего перехода протокола. Устройство PE1 имеет сегмент узла для этого IGP – 103 с P5 следующим переходом. В результате устройство PE1 посылает свой пакет обслуживания устройству P5 с двумя метами — нижней меткой, которая является меткой службы, и верхней меткой, которая является SID 103. Устройство P5 заменяется 103 на 103 и передается устройству P6. Следующим переходом для устройства P6 является маршрут IGP PE3, который не способен на сегментную маршрутику. (Устройство P7 не объявляет возможность сегментной маршрутации). Однако устройство P6 имеет привязку меток LDP с следующего перехода для того же FEC (например, метка LDP 1037). В результате, на устройстве P6 IGP 103 на 1037 и переадваровывается устройству P7.

Устройство P7 заменяет эту метку меткой LDP, полученной от устройства P8, и затем передает ее устройству P8. Метка LDP выталкивется устройством P8 и перенанощается на устройство PE3.

Устройство PE3 получает туннельный пакет и обрабатывает метку службы. Туннель между MPLS создан из узла сегментной маршрутации от устройств PE1 к P6 и LSP LSP от устройств P6 к PE3.

Segment Routing to LDP Stitching

Если следующий переход IP сегмента IGP LSP не поддерживает сегментную маршрутизализку, IGP смотрит на таблицу маршрутов inet.3, чтобы увидеть, есть ли LSP на том же префиксе. Если LSP LDP имеется, IGP сегмент, который перешивает LSP на LDP LSP, программируя MPLS транзитный маршрут, который заменяет метку сегмента маршрутов меткой LDP для коммутации трафика из домена сегментной маршрутации в домен LDP.

Рис. 24 иллюстрирует сшивание сегментной маршрутации и LDP LDP LSP для обеспечения возможности использования.

Рис. 24: Сшивание сегментной маршрутации и LDP LDP LSPСшивание сегментной маршрутации и LDP LDP LSP

В топологии устройство PE3 поддерживает LDP и не поддерживает сегментную маршрутизию. Сервер привязки в домене сегментной маршрутации может объявлять привязку меток TLV для устройств P7, P8 и PE4. В таком сценарии устройство PE1 может иметь как префикс SID, так и удаленный связывание меток TLV и SID для достижения устройства PE4. Однако устройство PE1 предпочитает SID префикса, чем удаленное связывание меток TLV, при этом запрограммировать маршрутов в рамках веского сегмента для устройства PE4. В результате устройство PE1 использует сегментную маршрутную LSP для передачи трафика на Device PE4 и использует зашифровку сегмента маршрутов к LDP при отправке трафика устройству PE3.

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS

  • Поведение выталкиваний предпоследней перемеха для TLV привязки меток не поддерживается.

  • Объявления диапазона префиксов в TLV связывания с меткой не поддерживаются.

  • Разрешение конфликтов сегментной маршрутизаации не поддерживается.

  • Статистика трафика LDP не работает.

  • Неполная активная маршрутная (NSR) и модуль маршрутизации переключение (GRES) не поддерживаются.

  • Межуровневая поддержка ISIS не поддерживается.

  • Атрибуты префикса IS-IS RFC 7794, для расширенного IPv4 не поддерживаются.

  • Перераспределение маршрута LDP в качестве префикса-sid на узле сшивание не поддерживается.

Настройка разных свойств LDP

В следующих разделах описана настройка нескольких свойств LDP,

Настройка LDP для использования метрики IGP маршрута

Используйте утверждение, если необходимо использовать метрику маршрута протокола внутреннего шлюза (IGP) для маршрутов LDP вместо метрики маршрута LDP по умолчанию (метрика маршрута LDP по умолчанию – track-igp-metric 1).

Чтобы использовать метрику IGP, включим в себя track-igp-metric утверждение:

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

Предотвращение добавления впадающих маршрутов в таблицу маршрутов inet.0

Настройка этого утверждения позволяет предотвратить добавление в таблицу маршрутов inet.0 маршрутов в таблице маршрутов inet.3, даже если было включено утверждение на уровне иерархии или на no-forwardingtraffic-engineering bgp-igp[edit protocols mpls][edit logical-systems logical-system-name protocols mpls] иерархии. По умолчанию no-forwarding утверждение отключено.

Прим.:

серия ACX не поддерживают edit logical-systems [] уровень иерархии.

Чтобы не включать впадающие маршруты из таблицы маршрутов inet.0, включаем no-forwarding утверждение:

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

VPN LDP с несколькими экземплярами и сети VPN операторов связи

Настроив несколько экземпляров маршрутов LDP, можно использовать LDP для объявления меток в СЕТИ VPN операторов связи от маршрутизатора поставщика услуг на границе сети поставщика услуг (PE) маршрутизатору заказчика клиентское граничное устройство (CE) маршрутизатору. Это особенно полезно, когда клиент оператора является основным поставщиком Интернет-услуг (Интернет-провайдер) и хочет ограничить полный доступ в Интернет маршрутизаторами PE. Используя LDP вместо BGP, клиент-носитель защищает другие внутренние маршрутизаторы от Интернета. LDP с несколькими экземплярами также полезен, когда клиент-носитель хочет предоставить своим клиентам услуги VPN 2-го или 3-го уровня.

Пример настройки нескольких экземпляров маршрутов LDP для VPN операторов связи см. в руководстве пользователя «Несколько экземпляров протокола распределения меток».

Настройка MPLS и LDP для всплывания метки на маршрутизаторе с конечным переходом

Объявленная по умолчанию метка – label 3 (Неявная метка Null). Если метка 3 объявлена, предпоследний маршрутизатор удаляет метку и отправляет пакет маршрутизатор исходящего трафика. Если включена выталкивка в конечном переходе, объявляется метка 0 (IPv4 Explicit Null label). При отсеии конечного перехода все пакеты, которые проходят через MPLS сети, содержат метку.

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

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

Прим.:

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

Дополнительные сведения о меток см. в MPLS меток и MPLS меток.

Включение LDP через установленные RSVP LPS

Можно запускать LDP через LSP, установленные на основе RSVP, эффективно туннеля LDP-установленный LSP через установленный RSVP. Для этого включим LDP на интерфейсе lo0.0 (см. Включение и отключение LDP). Также необходимо настроить LPS, над которыми будет работать LDP, включив в нее утверждение ldp-tunneling[edit protocols mpls label-switched-path lsp-name] на иерархическому уровне:

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

Включение LDP через установленные RSVP LPS в гетерогеных сетях

Некоторые другие поставщики используют OSPF 1 для адреса обратной связи. Juniper Networks маршрутизаторы используют OSPF 0 для адреса обратной связи. Для этого может потребоваться ручная настройка метрики RSVP при развертывании туннелирований LDP через LSVP LSP в гетерог сетях.

Если Juniper Networks маршрутизатор подключен к маршрутизатору другого поставщика через туннель RSVP и также включено туннеление LDP, то по умолчанию Juniper Networks маршрутизатор не может использовать RSVP-туннель для маршрутов трафика к пунктам назначения LDP вниз по направлению к маршрутизатор исходящего трафика другого поставщика, если маршрут RSVP имеет метрику 1 больше, чем физический OSPF путь.

Чтобы убедиться в правильности функций туннелирований LDP в гетерогевидных сетях, можно настроить OSPF игнорировать метрику LSP RSVP, включив в себя ignore-lsp-metrics утверждение:

Это утверждение можно настроить на следующих уровнях иерархии:

  • [edit protocols ospf traffic-engineering shortcuts]

  • [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

Прим.:

серия ACX не поддерживают edit logical-systems [] уровень иерархии.

Чтобы включить LDP по RSVP LSP, необходимо также выполнить процедуру, процедуру в Включение LDP через установленные RSVP LPS разделе.

Настройка подписи TCP MD5 для сеансов LDP

Можно настроить подпись MD5 для TCP-соединения LDP, чтобы защитить от внедрения поддельных сегментов TCP в потоки подключения сеанса LDP.

Маршрутизатор с параметром подписи MD5 настраивается с паролем для каждого одноранговых узла, для которого требуется аутентификация. Пароль хранится в зашифрованном виде.

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

Начиная с Junos OS 16.1R1, поддержка кода аутентификации хэширования сообщений (HMAC) и аутентификации MD5 для сеансов LDP расширена из конфигурации каждого сеанса в конфигурацию подсети-match (то есть, самое длинное префикс-совпадение).

Поддержка аутентификации, совпадающих с подсетью, обеспечивает гибкость при настройке аутентификации для автоматически целевых сеансов LDP (TLDP), что делает развертывание удаленных альтернативных обходных петель (LFA) и FEC 129 псевдопроводов простым.

Чтобы настроить подпись MD5 для соединения LDP TCP, включим в себя session-group утверждение и authentication-key утверждение:

Используйте утверждение для настройки адреса удаленного конца session-group сеанса LDP.

md5-authentication-key(пароль) может быть до 69 символов. Символы могут включать любые строки ASCII. При вложении пробелов все символы будут заключены в кавычках.

Можно также настроить механизм обновления ключа аутентификации для протокола маршрутизации LDP. Этот механизм позволяет обновлять ключи аутентификации без прерывания связанных протоколов маршрутизации и сигнализации, таких как Open Shortest Path First(OSPF)и протокол настройки резервирования ресурсов(RSVP).

Чтобы настроить механизм обновления ключа аутентификации, включите утверждение на уровне иерархии и укажите возможность создания ключа, состоящего из key-chain[edit security authentication-key-chains] нескольких key ключей аутентификации.

Чтобы настроить механизм обновления ключа аутентификации для протокола маршрутизации LDP, включив в него утверждение уровня иерархии, чтобы связать протокол с authentication-key-chain[edit protocols ldp][edit security authentication-key-chains] ключами аутентификации. Также необходимо настроить алгоритм аутентификации, включив в нее утверждение authentication-algorithm algorithm[edit protocols ldp] уровня иерархии.

Дополнительные сведения о функции обновления ключа аутентификации см. в "Настройка механизма обновления ключа аутентификации для BGP протоколов маршрутизации LDP".

Настройка защиты сеанса LDP

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

Можно настроить Junos OS оставить сеанс LDP между двумя маршрутизаторами up, даже если нет приветствующих отношений на соединениях, соединяющих два маршрутизатора, путем настройки session-protection утверждения. С помощью параметра можно указать время в timeout секундах. Сеанс остается открытым в течение указанного периода, пока маршрутизаторы поддерживают IP-подключение к сети.

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

Отключение ловушек SNMP для LDP

Когда LDP LSP совершает переход от up к down или down к up, маршрутизатор отправляет trap-сообщение SNMP. Однако можно отключить ловушки LDP SNMP на маршрутизаторе, логической системе или экземпляре маршрутов.

Для получения информации о ловушках SNMP LDP и фирменом MIB LDP см. SNMP-MIB Explorer..

Чтобы отключить ловушки SNMP для LDP, укажите trap disable параметр для log-updown утверждения:

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

Настройка синхронизации LDP с IGP LDP-соединениями

LDP – это протокол распространения меток в приложениях, не спроектированных для трафика. Метки распределяются по наилучшему пути, который определяется IGP. Если синхронизация между LDP и IGP не поддерживается, LSP отстает. Если LDP не является полностью рабочим на заданном соединении (сеанс не установлен и метки не обмениваются), IGP объявляет связь с метрикой максимальной стоимости. Связь не является предпочтительной, но остается в топологии сети.

Синхронизация LDP поддерживается только на активных интерфейсах "точка-точка" и интерфейсах LAN, настроенных под IGP. Синхронизация LDP не поддерживается во время простого перезапуска.

Для объявления метрики максимальной стоимости до тех пор, пока LDP не будет работоустойки для синхронизации, включим ldp-synchronization утверждение:

Чтобы отключить синхронизацию, включите disable утверждение. Чтобы настроить период времени для объявления метрики максимальной стоимости для не полностью активного соединения, включите hold-time утверждение.

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

Настройка синхронизации LDP с IGP маршрутизатора

Можно настроить время ожидания LDP перед информированием IGP о том, что сосед LDP и сеанс для интерфейса рабочие. Для больших сетей с многочисленными FEC может потребоваться настройка более длительного значения, чтобы обеспечить достаточное время для обмена базами данных меток LDP.

Чтобы задать время ожидания LDP перед информированием IGP о том, что сосед и сеанс LDP являются рабочими, включите утверждение и укажите время в секундах для igp-synchronizationholddown-interval параметра:

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

Настройка времени вывода меток

Время вывода метки задерживает отправку сообщения отмены метки для FEC соседнему с соседом. При с IGP соединении к соседнему маршрутизатору метка, связанная с FEC, должна быть отозвана со всех вышестояных маршрутизаторов, если сосед является следующим переходом для FEC. После IGP конвергенции и следования метки с нового следующего перехода, метка будет перенастройка на все вышестоячие маршрутизаторы. Это типичное поведение сети. За счет задержки снятия меток на некоторое время (например, до тех пор, пока IGP не будет схождения IGP и маршрутизатор не получит новую метку ДЛЯ FEC со следующего перехода в следующую следующую метку), вскоре можно избежать снятия меток и отправки сопоставления меток. Утверждение позволяет настроить это время label-withdrawal-delay задержки. По умолчанию задержка составляет 60 секунд.

Если маршрутизатор получает новую метку до того, как иссякнуть время, время вывода меток отменяется. Однако если время работает, метка для FEC будет снята со всех вышестояных маршрутизаторов.

По умолчанию LDP ждет в течение 60 секунд, прежде чем повторно заверять метки, чтобы избежать повторного отзыва LPS во время IGP перенаверждения. Чтобы настроить время задержки вывода меток в секундах, включите label-withdrawal-delay утверждение:

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

Игнорирование проверки подсети LDP

В Junos OS 8.4 и более поздних версиях во время процедуры установления соседа выполняется проверка адреса источника LDP в подсети. Адрес источника в пакете приветствуемой связи LDP совпадает с адресом интерфейса. Это вызывает проблему с возможностью использования оборудования других производителей.

Чтобы отключить проверку подсети, включим в нее allow-subnet-mismatch утверждение:

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

  • [edit protocols ldp interface interface-name]

  • [edit logical-systems logical-system-name protocols ldp interface interface-name]

Прим.:

серия ACX не поддерживают edit logical-systems [] уровень иерархии.

Настройка трассировки LSP LSP

За маршрутом, за которым следует LDP-сигнал, можно проследить LSP. Трассировка маршрутов LDP LSP основана на RFC 4379, обнаружение сбоев плоскости данных с многопротоколной коммутализаемой (MPLS) меткой. Эта функция позволяет периодически отслеживать все пути в FEC. Сведения о топологии FEC хранятся в базе данных, доступной из интерфейс командной строки.

Изменение топологии не запускает автоматически отслеживание LDP LSP. Однако можно вручную инициировать трассировка. Если запрос traceroute для FEC, который в данный момент находится в базе данных, содержимое базы данных обновляется с помощью результатов.

Функция периодической трассировки трассировки применяется ко всем FEC, заданным в утверждениях, oam настроенных на [edit protocols ldp] уровне иерархии. Для настройки периодического LDP LSP traceroute включаем periodic-traceroute утверждение:

Это утверждение можно настроить на следующих уровнях иерархии:

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

Можно настроить утверждение самостоятельно или periodic-traceroute с помощью любого из следующих параметров:

  • exp-Укажите класс обслуживания, который будет использовать при отправке зондов.

  • fanout-Укажите максимальное число следующих переходов для поиска на узле.

  • frequency-Укажите интервал между попытками traceroute.

  • paths-Укажите максимальное число путей для поиска.

  • retries-Укажите количество попыток отправки зонда конкретному узлу перед тем, как сдать запрос.

  • source-Укажите адрес источника IPv4, который будет использовать при отправке зондов.

  • ttl-Укажите максимальное время в прямом эфире. Узлы, которые находятся за пределами этого значения, не трассировка не трассировка.

  • wait-Укажите интервал ожидания перед повторной повторной проверкой пакета.

Сбор статистики LDP

Статистика трафика LDP показывает объем трафика, который прошел через определенный FEC на маршрутизаторе.

При настройке утверждения на уровне иерархии статистика трафика LDP периодически собирается и traffic-statistics[edit protocols ldp] записана в файл. С помощью этого параметра можно сконфигурировать, как часто собираются статистические данные (в interval секундах). Стандартный интервал сбора составляет 5 минут. Необходимо настроить файл статистики LDP; в противном случае статистика трафика LDP не будет собрана. Если LSP отстает, статистика LDP сбрасывается.

Чтобы собрать статистику трафика LDP, включим в себя traffic-statistics утверждение:

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

В данном разделе содержатся следующие темы:

Выходные данные статистики LDP

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

Файл статистики LDP содержит следующие столбцы данных:

  • FEC- FEC, для которого собираются статистические данные трафика LDP.

  • Type- Тип трафика, исходяющего от маршрутизатора (исходя из этого Ingress маршрутизатора) или Transit (перена который через этот маршрутизатор).

  • Packets— Число пакетов, переданных FEC с момента своего взламывания LSP.

  • Bytes- Число bytes данных, переданных FEC с момента его LSP.

  • Shared— Значение указывает на то, что несколько префиксов привязаны к одной мете (например, когда несколько префиксов объявляются с помощью политики Yes для отката). Статистика трафика LDP в этом случае применяется ко всем префиксам и должна рассматриваться как таковая.

  • read- Это число (которое отображается рядом с датой и временем) может отличаться от фактического числа отображаемой статистики. Некоторые статистические данные суммируют перед их отображением.

Отключение статистики LDP на предпоследней-переходной маршрутизаторе

Сбор статистики трафика LDP на предпоследней трассе-переходе маршрутизатор может потреблять избыточные системные ресурсы, в частности, на маршрутах следующего перехода. Эта проблема осложняется, если вы настроили утверждение deaggregate в дополнение к этому traffic-statistics сообщению. Для маршрутизаторов, достигающих предела использования маршрута следующего перехода, рекомендуется настроить параметр no-penultimate-hop для traffic-statistics утверждения:

Список уровней иерархии, на которых можно настроить утверждение, см. в разделе Сводка утверждения traffic-statistics для этого утверждения.

Прим.:

При настройке параметра для FEC, которые являются предпоследним переходом для этого маршрутизатора, статистика no-penultimate-hop недоступна.

При включите или удалите этот параметр из конфигурации, сеансы LDP снимались и затем перезапускались.

Следующий пример выходных данных – это файл статистики LDP, показывающий маршрутизаторы, на которых no-penultimate-hop настроен параметр:

Ограничения статистики LDP

Следующие вопросы связаны со сбором статистики LDP при конфигурировании traffic-statistics утверждения:

  • Невозможно очистить статистику LDP.

  • Если сокращается заданный интервал, то будет выдан новый запрос статистики LDP, только если время статистики истечет позже, чем новый интервал.

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

При отбое LSP происходит сброс статистики LDP.

Отслеживание трафика протокола LDP

В следующих разделах описана настройка параметров трассировки для проверки трафика протокола LDP:

Отслеживание трафика протокола LDP на уровнях экземпляров протокола и маршрутов

Для трассировки трафика протокола LDP можно указать параметры в глобальном сообщении на уровне иерархии, а также указать параметры, специфические traceoptions[edit routing-options] для LDP, включив в себя traceoptions утверждение:

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

Используйте утверждение, чтобы указать имя файла, который получает выходные данные операции file отслеживания. Все файлы помещаются в каталог /var/log. Рекомендуется разместить в файле выходные данные отслеживания ldp-log LDP.

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

  • address- Трассировка работы сообщений об отмене адреса и адреса.

  • binding— Отследить операции привязки меток.

  • error-Трассировка условий ошибки.

  • event— события протокола трассировки.

  • initialization— Трассировка работы сообщений инициализации.

  • label- Отслеживание операций запроса меток, карты меток, вывода меток и сообщений о выпуске меток.

  • notification— Трассировка работы уведомлений.

  • packets-Трассировка работы адреса, удаление адреса, инициализация, запрос метки, карта меток, удаление меток, выпуск меток, уведомление и периодические сообщения. Этот модификатор эквивалентен установке модификаторов address , , , и initializationlabelnotificationperiodic модификаторов.

    Можно также настроить модификатор флага с filter под match-on address опцией packets флага. Это позволяет отследить источник и адреса назначения пакетов.

  • path- Отслеживание операций по маршруту с коммутаемой по метке.

  • path- Отслеживание операций по маршруту с коммутаемой по метке.

  • periodic— Трассировка работы сообщений hello и keepalive.

  • route— трассировка работы сообщений маршрутов.

  • state- Переходы состояния протокола трассировки.

Отслеживание трафика протокола LDP внутри FEC

LDP связывает класс эквивалентности переадности (FEC) с каждым LSP, который он создает. FEC, связанный с LSP, определяет пакеты, связанные с этим LSP. LSP расширяются через сеть, так как каждый маршрутизатор выбирает метку, объявляемую следующим переходом для FEC, и соедиирует ее на метку, которая объявляется всем другим маршрутизаторам.

Можно отследить трафик протокола LDP в пределах определенного FEC и фильтровать LDP-трассировки на основе FEC. Это полезно для отслеживания или устранения неполадок трафика протокола LDP, связанного с FEC. Для этой цели доступны следующие флаги трассировки: route, path и binding .

В следующем примере показано, как можно настроить утверждение LDP для фильтрации сообщений трассировки traceoptions LDP на основе FEC:

Данная функция имеет следующие ограничения:

  • Возможность фильтрации доступна только для FEC, состоящих из префиксов IP версии 4 (IPv4).

  • FeC цепи уровня 2 не могут фильтроваться.

  • При настройке трассирения и фильтрации MPLS маршруты не отображаются (фильтр блокирует их).

  • Фильтрация определяется политикой и настроенным значением match-on параметра. При настройке политики необходимо убедиться, что поведение по умолчанию reject всегда.

  • Единственным match-on вариантом является fec . Следовательно, единственным типом политики, которая должна включаться, является политика фильтрации маршрутов.

Примеры: Отслеживание трафика протокола LDP

Подробное отслеживание сообщений пути LDP:

Трассировка всех исходяющих сообщений LDP:

Трассировка всех условий ошибки LDP:

Трассировка всех входящих сообщений LDP и всех операций привязки меток:

Трассировка трафика протокола LDP для FEC, связанного с LSP:

Таблица истории выпусков
Версия
Описание
19.1
Начиная Junos OS выпуске 19.1R1, пограничный маршрутизатор сегментной маршрутации-LDP может сшивать трафик сегментной маршрутки на следующий переход LDP и наоборот.
16.1R1
Начиная с Junos OS 16.1R1, поддержка кода аутентификации хэширования сообщений (HMAC) и аутентификации MD5 для сеансов LDP расширена из конфигурации каждого сеанса в конфигурацию подсети-match (то есть, самое длинное префикс-совпадение).
16.1
Начиная с Junos OS 16.1, M-LDP может сигнализировать многоканальный LSP на ASBR или транзите или выходе, когда корневой адрес является BGP, который далее рекурсивно рекурсивным MPLS LSP.
14.1
Начиная с Junos OS.14.1, для переноса существующих сервисов IPTV с исходного многоадресная передача по протоколу IP на MPLS многоаддровую передачу необходимо плавно переходить от PIM к многоканальных LSP M-LDP с минимальным сбоем.