Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

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

Обзор PCEP

Элемент вычисления пути (PCE) – это объект (компонент, приложение или сетевой узел), который способен вычислять сетевой путь или маршрут на основе схемы сети и применить ограничения вычислений. Клиент path Computation Client (PCC) – это любое клиентский приложение, запрашивающий вычисление пути, которое будет выполняться PCE. Протокол элемента вычисления пути (PCEP) обеспечивает взаимодействие между PCC и PCE или между двумя PCEs (определен в RFC 5440).

PCEP – это протокол на основе TCP, определенный рабочей группой IETF PCE, и определяет набор сообщений и объектов, используемых для управления сеансами PCEP, а также для запроса и отправки путей для мультидоменного трафика, разработанного LSP (управление трафиком LSP). Она обеспечивает механизм для PCE для выполнения вычисления пути для внешних LSP PCC. Взаимодействия PCEP включают отчеты о состоянии LSP, отправленные PCC на PCE, и обновления PCE для внешних LSP.

Рис. 1 иллюстрирует роль PCEP в реализации архитектуры PCE на стороне клиента в MPLS сети с поддержкой RSVP-управление трафиком.

Рис. 1: Сеанс PCEPСеанс PCEP

Сеанс PCEP на основе TCP соединяет PCC с внешней PCE. PCC инициирует сеанс PCEP и остается подключенным к PCE во время сеанса PCEP. Во время сеанса PCEP PCC запрашивает параметры LSP у PCE с состоянием. При получении одного или более параметров LSP от PCE PCC повторно передает сигнал управление трафиком LSP. Когда сеанс PCEP заканчивается, необходимое TCP-соединение сразу закрывается, и PCC пытается повторно установить сеанс PCEP.

Таким образом, функции PCEP включают:

  • Синхронизация состояния туннеля LSP между PCC и PCE с синхронизацией состояния — при обнаружении активного с синхронизацией состояния PCE PCE PCC пытается делегировать все LSP этому PCE в процедуре, называемой синхронизацией состояния LSP. PCEP включает синхронизацию состояния LSP PCC с PCE.

  • Истока управления туннелями LSP на PCE с контролем состояния — активный PCE с контролем состояния контролирует один или несколько атрибутов LSP для расчетных путей, таких как полоса пропускания, путь (МCE) и приоритет (настройка и удержание). PCEP позволяет использовать такие возможности LPS для вычисления пути.

  • Контроле PCE с синхронизацией и последовательностью расчетов пути внутри сеансов PCEP и через них — активный pCE с синхронизацией состояния изменяет один или несколько атрибутов LSP, таких как полоса пропускания, путь (IES) и приоритет (настройка и удержание). PCEP передает эти новые атрибуты LSP от PCE к PCC, после чего PCC повторно передает сигнал LSP по указанному пути.

Поддержка протокола path Computation Element Protocol для обзора RSVP-управление трафиком

Понимание MPLS RSVP-управление трафиком

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

Для управление трафиком в больших плотных сетях MPLS возможности, поскольку они потенциально обеспечивают большую часть функций, доступных в модели наложения, интегрированной и при меньших затратах по сравнению с конкурирующей в настоящее время альтернативой. Основная причина реализации этих управление MPLS-трафиком – контроль путей, по которым трафик проходит через сеть. Основное преимущество реализации управление MPLS-трафиком заключается в том, что она обеспечивает сочетание управление трафиком возможностей ATM и дифференциации класса обслуживания (CoS) IP.

В MPLS сети данные плоскость данных с помощью коммутаторов меток. Пакет, поступающий на грань поставщика (PE) от маршрутизатора клиентское граничное устройство (CE) имеет метки, примененные к маршрутизатору, и затем он переадресуется на маршрутизатор egress PE. Метки удаляются на маршрутизатор исходящего трафика и в качестве IP-пакета перенаправлены в нужное место назначения. Маршрутизаторы с коммутациями по метки (LSRs) в домене MPLS используют протоколы распределения меток для обозначения значения меток, используемых для переназначения трафика между и через LSRs. Протокол RSVP-управление трафиком – это один из таких протоколов распределения меток, который позволяет LSR равноправным узлам узнать о сопоставлениях меток других одноранговых сторон.

Если на MPLS и RSVP включены обе команды, MPLS становится клиентом RSVP. Основная цель программного обеспечения Junos OS RSVP – поддержка динамической сигнализации на путях с коммутаавлвлждем меток (LPS). RSVP резервировать ресурсы, такие как для однонастных и многоафретных IP-потоков, и запрашивает параметры качества обслуживания (QoS) для приложений. Протокол расширен в управление MPLS-трафиком, чтобы позволить RSVP устанавливать LSP, которые могут использоваться управление трафиком в MPLS сетях.

При MPLS и RSVP метки связаны с потоками RSVP. После того, как LSP установлен, трафик, который проходит по пути, определяется меткой, применяемой на впадаемом узле LSP. Сопоставление меток для трафика выполняется с использованием различных критериев. Набор пакетов, которые определенному узлу присвоены одно и то же значение метки, принадлежит одному и тем же классу эквивалентности переадности (FEC) и эффективно определяет поток RSVP. Когда трафик сопривязывался с LSP таким образом, LSP называется туннелем LSP.

Туннели LSP – это способ установить однонаправленные маршруты с коммутацией по метке. Протокол RSVP-управление трафиком создается на основе протокола Ядра RSVP путем определения новых объектов и изменения существующих объектов, используемых в объектах PATH и RESV для установления LSP. Новые объекты — объект LABEL-REQUEST (LRO), объект RECORD-ROUTE (RRO), объект LABEL и объект EXPLICIT-ROUTE (МВК) — являются необязательными в отношении протокола RSVP, за исключением объектов LRO и LABEL, которые являются обязательными для создания туннелей LSP.

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

  • Возможность установить путь с переключение на метку с использованием полного или частично точного маршрута (RFC 3209).

  • Установление LSP на основе ограничений по каналам, которые выполняют такие требования, как полоса пропускания и свойства канала.

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

  • Управление связью, которое управляет ресурсами связи для маршрутов, имеющих привязку к ресурсам, управление трафиком LPS и программы MPLS меток.

  • MPLS быстрая перемаршрутизация (FRR), которая управляет LPS, которым нужна защита, и назначает этим LSP информацию о резервном туннеле.

Текущие MPLS RSVP-управление трафиком

Хотя расширения протокола RSVP для управление трафиком более эффективного использования сети и отвечают требованиям к классам трафика MPLS, современный набор протоколов RSVP-управление трафиком имеет ряд проблем, свойственно распределенным сетям. Это вызывает ряд проблем в процессе прения за пропускную способность bisection, особенно в пределах класса приоритета LSP, где подмножество LSP совместно используется для общих значений настройки и удержания приоритетов. Ограничения RSVP-управление трафиком:

  • Недостаточенность отдельных уровней на LSP, требования к пропускной способности каждого устройства— въехатели в MPLS RSVP-управление трафиком сети устанавливают LSP без глобального представления о требовании пропускной способности сети. Информация об использовании сетевых ресурсов доступна только в качестве общей зарезервированной емкости класса трафика по интерфейсам. Отдельное состояние LSP локально доступно на каждой граничный маршрутизатор (LER) только для своих собственных LSP. В результате возникает ряд проблем, связанных со схемой запроса, особенно в рамках общей настройки и приоритета удержания.

  • Асинхронная и независимая природа сигнализации RSVP — в RSVP-управление трафиком- управление трафиком, ограничения при установлении пути контролируются администратором. Поэтому полоса пропускания, зарезервированная для туннеля LSP, устанавливается администратором и не предполагает никаких ограничений трафика, отосланного по туннелю. Таким образом, пропускная способность, доступная на управление трафиком канале, является пропускной способностью, настроенной для канала, за исключением суммы всех резервирований, сделанных на канале. Таким образом, невыполнение требований туннеля LSP приводит к ухудшению обслуживания LSP, требующего превышения пропускной способности, а также других LSP, которые соответствуют требованиям к пропускной способности канала управление трафиком.

  • LPS, установленные на основе динамических параметров явный путь в порядке предпочтения — в порядке поступления маршрутизаторы в MPLS RSVP-управление трафиком устанавливают LSP для требований на основе порядка прибытия. Поскольку у маршрутизаторов в направлении трафика нет глобального представления о требованиях к пропускной способности сети, использование порядка предпочтений для создания LSP может привести к отброшению трафика или не создавать LSP вообще при избыточном требовании к пропускной способности.

В качестве примера можно настроить MPLS RSVP-управление трафиком, в которой A и G являются гранными маршрутизаторами Рис. 2 меток (LERs). Эти входить маршрутизаторы устанавливают LSP независимо на основании порядка требований и не имеют информации или контроля над LSP друг друга. Маршрутизаторы B, C и D являются промежуточными или транзитными маршрутизаторами, которые соединяются с маршрутизаторами E и F на выходящем направлении.

Рис. 2: Пример MPLS управления трафиком Пример MPLS управления трафиком

Входимые маршрутизаторы устанавливают LPS на основе порядка поступления требований. Если маршрутизатор G получает два требования пропускной способности по 5 каждый для G-F, то G сигнализирует два LSP1 и LSP2 — через G-B-D-F. Аналогичным образом, когда маршрутизатор А получает третий запрос емкости 10 для A-E, то он передает сигнал LSP, LSP3, через A-B-C-E. Однако, если спрос на LSP A-E увеличивается с 10 до 15, маршрутизатор A не может сигнализировать LSP3 с помощью того же пути (A-B-C-E), поскольку связь B-C обладает более низкой производительностью.

Маршрутизатор A должен был про сигнализировать о повышенном спросе на LSP3 с помощью пути A-B-D-C-E. Поскольку LSP1 и LSP2 использовали B-D-соединение в порядке получения требований, LSP3 не передается сигнал.

Таким образом, несмотря на то, что для всех LSP доступна дополная пропускная способность максимального потока, LSP3 может стать объектом возможного ухудшения качества обслуживания. Это связано с отсутствием наглядности глобального запроса маршрутизатора А и системной координацией по требованию со стороны впадателей A и G.

Использование объекта для вычисления внешних путей

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

В настояще MPLS е время в сети RSVP-управление трафиком предоставляется только интерактивное вычисление пути маршрутизации с ограничением в режиме реального времени. Каждый маршрутизатор выполняет вычисления маршрутов на основе ограничений независимо от других маршрутизаторов в сети. Эти вычисления основаны на доступных на данный момент сведениях топологии — информация, которая обычно является последней, но не полностью точной. Размещения LSP локально оптимизированы в зависимости от текущего состояния сети. Туннель MPLS RSVP-управление трафиком настроен с помощью интерфейс командной строки. Оператор настраивает управление трафиком LSP, который затем сигнализируется в маршрутизатором в направлении веского маршрутизатора.

В дополнение к существующим управление трафиком, MPLS RSVP-управление трафиком расширенный включает объект вычисления внешнего пути, называемый Path Computation Element (PCE). PCE вычисляет путь для управление трафиком LPS влиятельных маршрутизаторов, настроенных на внешнее управление. Вционный маршрутизатор, подключа который подключается к PCE, называется Клиентом вычисления пути (PCC). PCC настраивается с помощью клиентского протокола вычисления пути (PCEP), чтобы облегчить вычисление внешнего пути PCE.

Дополнительные сведения Компоненты вычисления внешних путей см. в .

Чтобы включить вычисление внешнего пути для LSP управление трафиком PCC, включим утверждение на lsp-external-controller pccd[edit mpls] уровнях иерархии и на [edit mpls lsp lsp-name] иерархии.

Компоненты вычисления внешних путей

Компоненты, составляющие внешнюю систему вычисления путей:

Элемент вычисления пути

Элемент path Computation Element (PCE) может быть любым объектом (компонентом, приложением или сетевым узлом), которое может вычислять сетевой путь или маршрут на основе графа сети и применить ограничения вычислений. Однако PCE может вычислять путь только для тех управление трафиком LSPs PCC, настроенных для внешнего управления.

PCE может быть как с состоянием, так и без состояния.

  • Stateful PCE . PCE с синхронизацией между PCE и состояниями сети (с точки зрения топологии и информации о ресурсах), а также набором расчетных путей и зарезервированных ресурсов, которые используются в сети. Другими словами, PCE с состоянием использует информацию из управление трафиком базы данных, а также информацию о существующих путях (например, управление трафиком LSP) в сети при обработке новых запросов от PCC.

    PCE с состоянием имеет два типа:

    • Passive stateful PCE поддерживает синхронизацию с PCC и узнает состояния LSP PCC для оптимизации расчетов пути, но не имеет над ними управления.

    • Active stateful PCE — активно изменяет LSP PCC помимо изучения состояния PCC LSP.

      Прим.:

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

    PCE с состоянием обеспечивает следующие функции:

    • Предложения для вычисления пути LSP в автономном режиме.

    • Активирует перена маршрутизатор LSP, когда требуется повторно оптимизировать сеть.

    • Изменение пропускной способности LSP при увеличении требования к полосе пропускания со стороны приложения.

    • Изменяет другие атрибуты LSP на маршрутизаторе, такие как IES, приоритет установки и приоритет удержания.

    PCE имеет глобальное представление о требовании пропускной способности сети и ведет базу данных, спроектированную трафиком для выполнения вычислений пути. Он выполняет сбор статистики со всех маршрутизаторов в домене MPLS с помощью SNMP и NETCONF. Это обеспечивает механизм автономного управления LSP управление трафиком PCC. Несмотря на то, что в сетевой контроллер можно встраить систему вычисления пути LSP в автономном режиме, PCE действует как полностью посконченный сетевой контроллер, который предоставляет управление LSP управление трафиком PCC, помимо расчетных путей.

    Хотя PCE с синхронизацией с сохранением состояния на оптимальном пути и успешной вычислением пути, требует надежных механизмов синхронизации с потенциально значительной плоскость управления затратами и обслуживания большого объема данных с точки зрения состояния, как в случае полной сетки управление трафиком LPS.

  • PCE без с состоянием состояния — PCE не запоминает расчетный путь, и каждый набор запросов обрабатывается независимо друг от друга (RFC 5440).

Клиент вычисления пути

Клиент path Computation Client (PCC) – это любое клиентский приложение, запрашивающий вычисление пути, которое будет выполняться PCE.

PCC может одновременно подключаться не более чем к 10 PCEs. Соединение PCC с PCE может быть настроенным статическим маршрутом или TCP-соединением, которое устанавливает доступность. PCC назначает каждому подключенного PCE номер приоритета. Он посылает сообщение всем подключенным PCEs с информацией о своих текущих LSP в процессе, называемом синхронизацией состояния LSP. Для управление трафиком LPS с включенным внешним управлением, PCC подгогружает эти LSP к основному PCE. PCC избирает, в качестве основного PCE, PCE с наименьшим номером приоритета, или PCE, к который он подключается, при отсутствии приоритетного номера.

PCC повторно передает сигнал LSP на основе расчетного пути, получаемого от PCE. Когда завершается сеанс PCEP с основным PCE, PCC избирает новую основную PCE, и все переданные LSP до этого главному PCE делегируют на новый доступный основной PCE.

Path Computation Element Protocol

Протокол элемента вычисления пути (PCEP) используется для связи между PCC и PCE (а также между двумя PCEs) (RFC 5440). PCEP – это протокол на основе TCP, определенный рабочей группой IETF PCE, и определяет набор сообщений и объектов, используемых для управления сеансами PCEP, а также для запроса и отправки путей для многодомена управление трафиком LPS. Взаимодействия PCEP включают сообщения PCC, а также уведомления о конкретных состояниях, связанных с использованием PCE в контексте MPLS RSVP-управление трафиком. Когда PCEP используется для связи между PCE и PCE, запрашивающий PCE берет на себя функции PCC.

Таким образом, функции PCEP включают:

  • Синхронизация состояния туннеля LSP между PCC и PCE с синхронизацией состояния.

  • Неумеха управления туннелями LSP к PCE с контролем состояния.

Взаимодействие между PCE и PCC с использованием PCEP

Рис. 3 иллюстрирует взаимосвязь между PCE, PCC и ролью PCEP в контексте MPLS RSVP-управление трафиком.

Рис. 3: PCC и RSVP-управление трафиком PCC и RSVP-управление трафиком

Связь PCE с PCC включена pcEP на основе TCP. PCC инициирует сеанс PCEP и остается подключенным к PCE во время сеанса PCEP.

Прим.:

Начиная Junos OS 16.1, можно защитить сеанс PCEP, используя аутентификацию TCP-MD5 в RFC 5440. Чтобы включить механизм безопасности MD5 для сеанса PCEP, рекомендуется определить и связать ключ аутентификации MD5 на уровне иерархии для [edit protocols pcep pce pce-id] сеанса PCEP. Однако для защиты сеанса PCEP можно также использовать предопределенный ключchain уровня [edit security authentication-key-chains key-chain] иерархии. В этом случае необходимо связать предопределенный ключ в сеанс PCEP на [edit protocols pcep pce pce-id] уровне иерархии.

PCE и PCC используют один ключ для проверки подлинности каждого сегмента, отсылаемого на TCP-соединении сеанса PCEP, тем самым обеспечивая безопасность связи PCEP между устройствами, которые могут стать объектом атак и могут нарушить работу сетевых служб.

Дополнительные сведения о защите сеансов PCEP с использованием аутентификации MD5 см. в Аутентификация TCP-MD5 для сеансов PCEP .

После того, как сеанс PCEP установлен, PCC выполняет следующие задачи:

  1. Синхронизация состояния LSP — PCC отправляет информацию обо всех LSP (локальных и внешних) на все подключенные PCEs. Для внешних LSP PCC отправляет на PCE информацию обо всех изменениях конфигурации, изменении RRO, изменении состояния и так далее.

    Для LSP, инициированных PCE, конфигурация LSP на PCC не существует. PCE, инициировал LSP, посылает параметры LSP на PCC, который указал на возможность поддержки LSP, инициированных PCE.

    Прим.:

    Поддержка LPS, инициированных PCE, предоставляется в Junos OS 13.3 и более поздних выпусках.

  2. Некорронизированный LSP . После синхронизации информации о состоянии LSP PCC перезагружает внешние LSP на один PCE, который является основным активным PCE с синхронизацией состояния. Только основной PCE может устанавливать параметры для внешнего LSP. Параметры, которые изменяет основной PCE, включают полосу пропускания, путь (IES), а также приоритет (настройка и удержание). Параметры, заданные в локальной конфигурации, переопределяются параметрами, заданными главным PCE.

    Прим.:

    Когда завершается сеанс PCEP с основным PCE, PCC избирает новую основную PCE, и все переданные LSP до этого главному PCE делегируют на новый доступный основной PCE.

    В случае LSP, инициированных PCE, PCC создает LSP с использованием параметров, полученных от PCE. PCC назначает PCE-инициировал LSP уникальный LSP-ID и автоматически присваивает PCE значение LSP. PCC не может отоимти невод для LSP, инициированных PCE, для активного сеанса PCEP.

    После прерывания сеанса PCEP PCC запускает два часа без немедленного удаления LSPs, инициированных PCE, и во избежание сбоев delegation cleanup timeoutlsp cleanup timer в обслуживании. За это время активный PCE с контролем состояния может получить управление LSP, которые были предусмотрены сбойной PCE, отправив запрос на создание для LSP.

    Контроль за PCE-инициализными LSP возвращается к PCC по истечении срока delegation cleanup timeout действия. По истечении срока действия, и ни один другой PCE не получил контроля над LSP от сбойного PCE, PCC берет на локальный контроль не делегированную delegation cleanup timeout PCE-инициированную LSP. Позже, когда исходный или новый активный PCE с контролем состояния хочет получить управление локально управляемыми PCE-Инициализными LSP, PCC посведет эти LSPs к PCE, и время lsp cleanup timer остановлено.

    PCE может вернуть PCE-инициировал LSP на PCC, чтобы разрешить передачу LSP между PCEs. Это инициирует lsp cleanup timer запуск LSP, инициированного PCE. PCC ждет истечения срока времени очистки LSP перед удалением не делегирования LSP, инициированных PCE, из сбойного PCE.

    Когда истекает срок действия, и ни один другой PCE не получает управления LPS от сбойного PCE, PCC удаляет все LSP, задамые сбойным lsp cleanup timer PCE.

    Прим.:

    В соответствии с проектом-ietf-pce-stateful-pce-09,отмена стандартов LSP, инициированных PCE, происходит в за несколько минут до того, как LSP будут обновлены на альтернативном PCE. Начиная Junos OS релизе 18.1R1, PCC должен быть больше или равен затме, чтобы PCC оторавлил лицензию lsp-cleanup-timerdelegation-cleanup-timeout LSP. Если нет, то интервал времени окончания действия для PCC может быть установлен на бесконечность, когда LSP не заменяется до тех пор, пока PCC не будет предприняты конкретные действия для изменения параметров, заданных PCE.

  3. Сигнализация LSP — при получении одного или более параметров LSP от основного активного PCE с состоянием состояния, PCC повторно передает сигнал управление трафиком LSP на основе предоставленного PCE пути. Если PCC не может настроить LSP, он извессирует PCE об ошибке установки и ждет, пока основной PCE предоставит новые параметры для этого LSP, а затем перенаправит его.

    Когда PCE указывает путь, который является неполным или имеет свободные переходы, в которых указаны только конечные точки пути, PCC не выполняет маршруты на основе локальных ограничений, чтобы узнать полный набор переходов. Вместо этого PCC обеспечивает RSVP с предоставленным PCE путем, как это делается, для сигнализации, и путь устанавливается с помощью IGP маршрутов по переходу за переходом.

Если рассматривать топологию, которая используется в сети, иллюстрирует частичное внедрение PCE на стороне клиента MPLS в сети с управление трафиком Рис. 2Рис. 4 RSVP-управление трафиком. Впадаемые маршрутизаторы A и G – это PCC, настроенные для подключения к внешнему PCE с состоянием соединения TCP.

PCE имеет глобальное представление о требовании пропускной способности сети и выполняет вычисления внешних путей после просмотра управление трафиком базы данных. Активный PCE с состоянием, изменяет один или несколько атрибутов LSP и отправляет на PCC обновление. PCC использует параметры, получаемые от PCE для повторной сигнализации LSP.

Рис. 4: Пример PCE для MPLS RSVP-управление трафиком Пример PCE для MPLS RSVP-управление трафиком

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

Поведение LSP с внешними вычислениями

Типы LSP

В реализации PCE на стороне клиента существует три типа управление трафиком LPS:

  • интерфейс командной строки LPS— LPS, на которые не настроена утверждение, называются интерфейс командной строки lsp-external-controller pccd LPS, управляемым. Хотя эти LSP контролируются локально, PCC обновляет подключенные PCEs, сообщая интерфейс командной строки LSP, управляемые во время начального процесса синхронизации LSP. После начальной синхронизации LSP PCC информирует PCE о любых новых и удаленных LSP.

  • PCE-управляемые LPS — LPS, которые имеют настроенную утверждение, lsp-external-controller pccd называются PCE-управляемыми LPS. PCC нецессировал LPS, инициированные PCC, с главным PCE для вычисления внешнего пути.

    PCC информирует PCE о настроенных параметрах LSP, управляемых PCE, таких как пропускная способность, IES и приоритеты. Он также информирует PCE о действительных значениях, используемых для этих параметров для того, чтобы настроить LSP, включая RRO, когда они доступны.

    PCC посылает такие отчеты состояния LSP на PCE только когда произошла перенастройка или когда произошло изменение в МВТ, RRO или состоянии LSP, управляемых PCE, под внешним управлением.

    Существует два типа параметров, которые пришли из интерфейс командной строки LSP для PCE:

    • Параметры, которые не переопределяются PCE и которые применяются немедленно.

    • Параметры, которые переопределяются PCE. Эти параметры включают пропускную способность, путь и приоритет (значения настройки и удержания). Когда режим управления переключается с внешнего на локальный, интерфейс командной строки значения, настроенные для этих параметров, применяются при следующей возможности для повторного сигнала LSP. Значения не применяются немедленно.

  • Внешние LPS (или LPS, инициируемые PCE) — LPS, которые имеют настроенную утверждение, называются lsp-provisioning PCE-инициируемыми LSP. LSP, инициированный PCE, динамически создается внешним PCE; в результате на PCC не будет присутствовать конфигурация LSP. PCC создает LSP, инициированный PCE, используя параметры, предоставленные PCE, и автоматически использует LSP в PCE.

    Прим.:

    Поддержка LPS, инициированных PCE, предоставляется в Junos OS 13.3 и более поздних выпусках.

LPS, интерфейс командной строки, управляемые PCE, и LPS, инициированные PCE, могут сосуществовать на PCC.

LPS интерфейс командной строки и LPS, управляемые PCE, могут сосуществовать на PCC.

Режим управления LSP

В реализации PCE на стороне клиента существует два типа режимов управления LSP, управляемых PCC:

  • External . По умолчанию все LPS, управляемые PCE, находятся под внешним управлением. Когда LSP находится под внешним управлением, PCC использует параметры, предоставленные PCE, для того, чтобы настроить LSP.

  • Local — LSP, управляемый PCE, может перенаправляемый локально. Когда LSP переключается с внешнего управления на локальное управление, вычисление пути происходит с помощью интерфейс командной строки параметров и маршрутизации на основе ограничений. Такое переключение происходит, только когда есть триггер для повторного сигнала LSP. До этого момента PCC использует параметры, предоставленные PCE, для сигнализации LSP, контролируемого PCE, хотя LSP остается под локальным управлением.

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

Дополнительные сведения о интерфейс командной строки LPS и LPS под управлением PCE Типы LSP см. в .

Утверждения конфигурации, поддерживаемые для внешних вычислений

Табл. 1 перечисляет MPLS и существующие настройки конфигурации LSP, применимые к LSP, контролируемым PCE.

Табл. 1: Применимость MPLS и существующих конфигураций LSP к LSP, контролируемым PCE

Поддержка LSP под управлением PCE

Применимые утверждения конфигурации LSP

Применимые MPLS конфигурации

Эти настройки можно настроить вместе с конфигурацией PCE. Однако они вступает в силу только при использовании локальной конфигурации. Во время управления PCE эти утверждения конфигурации остаются неактивными.

  • admin-group

  • автоматическая пропускная способность

  • предел переходов

  • наименее заполнение

  • наибольшее заполнение

  • Случайных

  • admin-group

  • группы администраторов

  • расширенный администратор

  • предел переходов

  • no-cspf

  • smart-optimize-timer

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

Прим.:

Изменения локальной конфигурации интерфейс командной строки время, когда LSP находится под управлением PCE с контролем состояния, не влияют на LSP. Эти изменения вступает в силу только при применении локальной конфигурации.

  • Пропускной способности

  • основная

  • Приоритет

  • Приоритет

Эти утверждения конфигурации не могут быть настроены вместе с конфигурацией PCE.

  • p2mp

  • Шаблон

  • p2mp-lsp-next-hop

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

Защита LSP под управлением PCE

Пути защиты, включая быстрая перемаршрутизация и обход LPS, локально вычисляются PCC с помощью маршрутов на основе ограничений. PCE с состоянием указывает только основной путь (ESS). PCE также может инициирует нестандартный вторичный путь, даже если локализованная конфигурация не имеет нестандартного вторичного пути для защиты LSP.

контрольный PCE LSP ТБВ

Для LSP, управляемых PCE (LPS, делегированные PCC и PCE-иниированные LSP), только полнодубный объект явного маршрута (ATED) должен быть отправлен от PCE на PCC; в противном случае PCC отклоняет сообщение PCUpdate или PCCreate для этого сеанса PCEP.

Начиная Junos OS 17.2, для LPS под управлением PCE вводятся два новых типа вычисления external cspf пути: local cspf и no cspf .

  • local cspf- PCC использует тип вычисления, только когда PCE отправляет TLV Juniper поставщика local cspf (номер предприятия: 0x0a4c) типа 5.

  • no cspf— Ни PCE, ни PCC не выполняют вычисление ограниченного пути. Конечные точки и ограничения даются модулею RSVP для настройки LSP с IGP пути.

    В следующих случаях PCC использует no cspf тип вычисления:

    • Когда PCE отправляет TLV и когда Junos OS или шаблон совпадения для этого LSP, включенный в local cspfno-cspf PCC-делегированную LSP.

    • Когда PCE отправляет TLV и когда Junos OS конфигурации для этого LSP, включенный в LSP, инициированный local cspfno-cspf PCE.

    • Когда PCE не отправляет TLV с пустым local cspf ЖИЖ или свободной МБАЙТ (при слишком свободном бите, замещаемом в объекте МБАЙТ).

С помощью этих новых типов вычислений PCC может принять объект МВК как свободного МВК или как пустой МБАЙТ. Объект для вычисления внешнего пути, который не может вычислить маршрут, может изменять параметры, такие как полоса пропускания и цвет, на основе анализа. В таких случаях используется пустой объект МБАЙТ или свободный МБАЙТ, и PCC решает, как следует использовать путь.

LPS, управляемые PCE для многоточки RSVP-управление трафиком

После того, как сеанс PCEP установлен между PCE и PCC, PCC сообщает все LSP в системе PCE для синхронизации состояния LSP. Это включает LPS, управляемые PCC, делегирование PCE и LPS, инициированные PCE. Начиная Junos OS 15.1F6 и 16.1R1, эта возможность распространяется и на LSP "точка-многоточки". Для PCE многоканальный LSP аналогичен LSP точки-многоточки RSVP, где LSP точки-многоточки рассматривается как набор точек-точек LSP, сгруппченных под идентификатором "точка-многоточки".

По умолчанию PCE не поддерживает многоканальный LSP. Чтобы добавить эту возможность, добавьте утверждение p2mp-lsp-report-capability на уровне [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] иерархии или на иерархии. После настройки возможности отчетов "точка-многоточки" на PCC, PCC объявляет эту возможность PCE. Если PCE в ответ объявляет те же возможности отчетов "точка-многоточки", то PCC сообщает PCE полное дерево LSP "точка-многоточки" для синхронизации состояния LSP.

PCC с возможностью "точка-многоканальный" управление трафиком LSP поддерживает отчет о LSP "точка-многоканальный" управление трафиком LSP для точек pcEs с поддержкой точек и базы данных LSP, поддерживающей имя LSP точки-многоточки как ключевое. Однако для версий Junos OS 16.1 и 16.1 15.1F6 следующие функции и функции не поддерживаются:

  • Статические многоканальных LPS

  • LPS, делегированная PCE и инициированная точкой-многоточки

  • Автоматическая пропускная способность

  • управление трафиком++

  • Запрос PCE и ответное сообщение

  • Создание точек-многоканальных LPS с использованием шаблонов

  • Настройка записи переад доступа на LPS, инициируемых PCE между точками

  • Настройка записи forward на маршрутизаторе, указывающего на настроенный LSP.

LPS, инициированные PCE

Начиная с Junos OS 16.1, функциональность PCEP расширена, позволяя PCE с состоянием запускать и управление трафиком LSP через PCC. Ранее LSP были настроены на PCC, и PCC делегировал контроль над внешними LSP PCE. Владельцем состояния LSP является PCC. С появлением LSP, инициируемых PCE, PCE может инициировать и настраивать LSP из точки управление трафиком динамически, без необходимости локально настроенного LSP на PCC. При получении сообщения PCCreate от PCE, PCC создает LSP, инициированный PCE, и автоматически копирует LSP на PCE.

По умолчанию PCC отклоняет запрос на предоставление PCE-инициализных точеных LSP от PCE. Чтобы включить поддержку PCE-и поддерживаемых PCE LSP на PCC, включите утверждение lsp-provisioning на [edit protocols pcep pce pce-id] уровнях [edit protocols pcep pce-group group-id] иерархии или lsp-provisioning.

PCC указывает на возможность поддержки PCE-инициализации точестных LSP при установлении сеанса Path Computation Element Protocol (PCEP) с PCE. PCE выбирает PCC, который может инициировать LSP. PCE обеспечивает PCC параметрами LSP, инициированными PCE. При получении параметров LSP, инициированных PCE, PCC устанавливает LSP, назначает ID LSP и автоматически присваивает PCE новый LSP.

Когда PCE, инициировал LSP, не предоставляет параметры LSP, инициированные PCE-точкой, PCC использует параметры по умолчанию. Можно также настроить дополнительный шаблон LSP для указания значений для LSP, инициируемых точкой PCE, если параметры LSP не предоставлены PCE. Чтобы настроить шаблон LSP для PCE-инициируемых точеческих LSP на label-switched-path-template PCC, необходимо включить утверждение шаблона маршрут-метка на уровне [edit protocols mpls lsp-external-controller lsp-external-controller] иерархии.

После прерывания сеанса PCEP PCC запускает два часа без немедленного удаления PCE-инициализацииLSP и во избежание сбоев delegation cleanup timeoutlsp cleanup timer в обслуживании. В это время активный PCE с контролем состояния может получить управление LSP, которые были предусмотрены сбойным PCE.

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

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

Начиная с Junos OS выпуска 21.1R1, мы поддерживаем бесконечную активную маршрутную (NSR) для точек-точек RSVP, инициированных PCE. Только первичный модуль маршрутизации поддерживает сеанс PCEP с контроллером. Он синхронизирует все LPS RSVP, инициированные PCEs, включая спецификации многоафрового потока для любого PCE-инициирующего P2MP LPS, с резервным модуль маршрутизации. Во время переключения сеанс PCEP выключается и вновь включается, когда резервный модуль маршрутизации становится основным модуль маршрутизации. Это уменьшает потерю трафика, передается по RSVP LSP, инициированным PCE, модуль маршрутизации переключения. Эта функция включена при настройке NSR.

Обход LSP, инициированный PCE

Понимание PCE-инициированных обходных LPS

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

Junos OS выпуски 19.2R1 и более поздние выпуски предоставляют частичную поддержку проекту Интернет-проект-cbrt-pce-stateful-local-protection-01 (истекает декабря 2018 г.), расширения PCEP для RSVP-управление трафиком Local-Protection с PCE-Stateful,где функциональность PCEP расширена, чтобы разрешить PCE с состоянием инициировать, и обходить LSP для защищенного интерфейса. PCE может инициировать несколько обходных LSP с резервированием полосы пропускания для защиты канала или узла. Ожидается, что полоса пропускания обходного LSP будет меньше общей пропускной способности первичных LSP, которые он может защитить.

Существующий механизм выбора обхода, предпочитая вручную обходные LPS (если они доступны) по большей выбору, чем динамические обходные LSP, расширен, чтобы предпочитать PCE-иные обходные LPS (если они доступны), а не динамические обходные LSP. PCE-provisioned bypass LSPs имеют более высокий предпочтение по чем динамические обходные LSP, но меньше предпочтительнее, чем LPS обхода вручную.

Набор операций, которые используются для выполнения на любых рабочих обходных LSP, например, может также выполняться на clear rsvp session PCE-инициации обходных LPS. Можно использовать команды, например, и для просмотра статистики LSP, инициированной show path-computation-client status extensiveshow path-computation-client lsp PCE.

При поддержке PCE-инициировал обход LSP, вы можете:

  • Создайте RSVP-обход LSP через PCEP с внешнего контроллера, где обход LSP:

    • может быть для защиты соединения или узла.

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

    • должен иметь определенный строгий МНИОН.

  • Обновите полосу пропускания и МВТ для существующего PCE-созданного обходного LSP.

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

Преимущества PCE-инициировал обход LSP

PCE-инициировал обходные LPS предоставляют следующие преимущества:

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

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

  • Убедитесь, что во время событий сбоя соединения не перегружены.

Поведение PCE-инициировал обход LPS во время сбоя сеанса PCEP

В момент сбоя сеанса PCEP инициированные PCE обходные LPS становятся потерянными до истечения времени ожидания состояния. PCE-инициировал обходные LPS очищаются по истечении времени ожидания состояния. Чтобы получить управление PCE-инициировал обход LSP (после сбой сеанса PCEP), PCE (первичный PCE или любой дополнительный PCE) посылает сообщение PCInitiate перед истечением времени ожидания состояния.

LPS, инициированные PCE для многоточки

Благодаря внедрению точек-многоточки PCE-Инициальных LSP PCE, PCE может инициировать и динамически инициировать многоканальный LSP без необходимости локальной конфигурации LSP на PCC. Это позволяет PCE управлять синхронизацией и последовательностью расчетов маршрутов между точками в сеансах Path Computation Element Protocol (PCEP) и через него, создавая таким образом динамическую сеть, которая централизованно контролируется и развертывается.

Дополнительные сведения см. в статье Основные сведения о протоколе path Computation Element Protocol для MPLS RSVP-управление трафикомс поддержкой LPS "точка-многоточки", инициированная PCE.

LSP с автоматической пропускной способностью и PCE

Начиная Junos OS выпуске 14.2R4, поддержка автоматической пропускной способности предоставляется для LPS, управляемых PCE. В более ранних выпусках опция автополосы пропускания не применялась к LPS, управляемым PCE, хотя LPS, управляемые auto-bandwdith и базой ограничений, могут сосуществовать с PCE-LSP. Сбор статистики для автоматической полосы пропускания действует, только когда режим управления PCE-контролируемого LSP меняется с внешнего на локальный. Это происходило в таких случаях, как отсутствие подключения к PCE или когда PCE возвращает обратное время LSP к PCC.

Аутентификация TCP-MD5 для сеансов PCEP

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

Учитывая важность связи PCEP между PCE и PCC при эффективном выполнении функций PCE, Junos OS выпуск 16.1 вводит возможность обеспечения безопасности сеанса PCEP с использованием аутентификации TCP-MD5 в соответствии с RFC 5440. Данная функция защищает связь между PCE и PCC через сеанс PCEP, который может стать объектом атаки, и может нарушить работу сетевых служб.

Чтобы включить механизм безопасности MD5 для сеанса PCEP, рекомендуется определить и связать ключ аутентификации MD5 на уровне иерархии для [edit protocols pcep pce pce-id] сеанса PCEP. Однако для защиты сеанса PCEP можно также использовать предопределенный ключchain уровня [edit security authentication-key-chains key-chain] иерархии. В этом случае необходимо связать предопределенный ключ в сеанс PCEP на [edit protocols pcep pce pce-id] уровне иерархии.

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

  • Использование ключа аутентификации MD5:

  • Использование предварительно задатки ключа аутентификации:

Чтобы безопасные сеансы PCEP были успешно установлены, необходимо настроить аутентификацию MD5 с предварительно общим ключом аутентификации на сервере PCE и PCC. PCE и PCC используют один ключ для проверки подлинности каждого сегмента, отосланного по TCP-соединению сеанса PCEP.

Прим.:
  • Junos OS 16.1 поддерживает только аутентификацию TCP-MD5 для сеансов PCEP без расширенной поддержки TLS и TCP-AO, такой как защита от подслушивания, фальсификации и фальсификации сообщений.

  • Первоначальное применение механизма безопасности к сеансу PCEP приводит к сбросу сеанса.

  • Если MD5 неправильно настроен или не настроен на одной стороне сеанса PCEP, сеанс не устанавливается. Убедитесь, что конфигурации PCC и PCE совпадают.

  • Данная функция не поддерживает механизм аутентификации сеансов.

  • Чтобы просмотреть ключ аутентификации, используемый сеансом PCEP, используйте выходные show path-computation-client statusshow protocols pcep данные команд и команды.

  • Используйте эту команду для просмотра количества пакетов, отброшенных TCP из-за show system statistics tcp | match auth ошибок аутентификации.

  • Функционирование команды keychain можно проверить с помощью show security keychain detail выходных данных команды.

Влияние реализации PCE на стороне клиента на производительность сети

Поддержка базы данных с сохранением состояния может быть нелинейной. В единой централизованной среде PCE pCE с состоянием просто должен запомнить все управление трафиком LPS, которые PCE вычислил, управление трафиком LSPs, которые были на самом деле настроены (если это известно), и когда управление трафиком LSP были разорваны. Однако эти требования вызывают значительную накладные расходы по протоколу управления с точки зрения состояния, использования и обработки сети, а также оптимизации линий связи по всей сети. Таким образом, проблемы реализации PCE с соблюдением состояния:

  • Любой надежный механизм синхронизации приводит к значительной плоскость управления накладных расходов. PcE могут синхронизировать состояние при помощи связи друг с другом, но когда управление трафиком LPS настроены с помощью распределенной вычисления, выполняемой между несколькими PCE, проблемы синхронизации и предотвращения условий гонки данных становятся все более и более сложными.

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

  • Расчеты путей, включающие общее состояние сети, крайне сложны, даже если PCE обладает подробной информацией по всем путям, приоритетам и уровням.

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

Примере: Настройка протокола path Computation Element Protocol для MPLS RSVP-управление трафиком

В данном примере показано, как включить вычисление внешнего пути с помощью элемента вычисления пути (PCE) для путей с меткой коммутации (управление трафиком LSP) на клиенте вычисления пути (PCC). Здесь также показано, как настроить протокол Path Computation Element Protocol (PCEP) на PCC для обеспечения связи PCE с PCC.

Требования

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

  • Три маршрутизатора, которые могут быть комбинацией серия ACX: M Series Multiservice Edge Routers, серия MX универсальных маршрутных платформ 5G, серия T основных маршрутизаторов или серия PTX транспортных маршрутизаторов, один из которых настроен как PCC.

  • TCP-соединение с внешним PCE с состоянием состояния от PCC.

  • Junos OS версии 12.3 или более поздней версии на PCC вместе с пакетом добавления JSDN.

Прим.:

Необходимо установить пакет добавления JSDN вместе с программой установки Junos OS ядра.

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

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

  2. Настройте MPLS и RSVP-управление трафиком.

  3. Настройте IS-IS или любой другой IGP протокол.

Обзор

Начиная Junos OS 12.3, функция MPLS RSVP-управление трафиком расширена для частичной реализации архитектуры PCE с соблюдением состояния (проект-ietf-pce-stateful-pce) на PCC.

Прим.:

Частичная реализация архитектуры PCE с учетом состояния клиента основана на версии 2 Интернет-проекта draft-ietf-pce-stateful-pce-pce. Начиная с Junos OS 16.1, эта реализация обновляется до поддержки версии 7, как определено в проекте проекта Интернет-ietf-pce-stateful-pce-07. Выпуски до 16.1 поддерживают старую версию проекта PCE, что вызывает проблемы взаимодействия между PCC, работающим в предыдущем выпуске, и сервером PCE с поддержкой состояния, который соответствует проекту проектируемого Интернет-проект-ietf-pce-stateful-pce-07.

Чтобы включить вычисление внешнего пути с помощью PCE, включив в нее утверждение lsp-external-controller PCC на [edit mpls] уровнях иерархии и на уровне [edit mpls lsp lsp-name] иерархии.

LSP, настроенный с утверждением, по умолчанию называется PCE-контролируемым LSP и по умолчанию находится под внешним lsp-external-controller управлением PCE. Активный PCE с контролем состояния может переопределять параметры, установленные с интерфейс командной строки, такие как полоса пропускания, путь (МКС) и приоритет, для таких LSP PCC, управляемых PCE.

Чтобы включить PCE для связи с PCC, настройте PCEP на PCC на [edit protocols] уровне иерархии.

При настройке PCEP на PCC необходимо учитывать следующие факторы:

  • Необходимо установить пакет добавления JSDN вместе с программой установки Junos OS ядра.

  • Junos OS версии 12.3 поддерживают только ПК с поддержкой с поддержкой состояния.

  • PCC может подключаться не более чем к 10 PCEs с состоянием. В любой момент времени может быть только один основной PCE (PCE с наименьшим значением приоритета, или PCE, который подключается к PCC сначала при отсутствии приоритета PCE), к которому были добавлены LSP-соединения PCC для вычисления пути.

  • В Junos OS 12.3 PCC всегда инициирует сеансы PCEP. Сеансы PCEP, инициированные удаленными PCEs, не принимаются PCC.

  • Существующие функции LSP, такие как защита LSP и передавка, работают для LSP, управляемых PCE.

  • Параметр auto-bandwidth отключен для LSP, управляемых PCE, хотя LPS под управлением автодиабайта и маршрутов с ограничением может сосуществовать с PCE-LSP.

  • На LSP, управляемые PCE, могут ссылться другие конфигурации интерфейс командной строки, такие как lsp-nexthop к маршрутам, перенаправляемые сопутства, соединения CCC и логические туннели.

  • LPS, управляемые PCE, не поддерживают GRES.

  • LSP, управляемые PCE, в логических системах не поддерживаются.

  • LPS, управляемые PCE, не могут быть многоточкиными LSP.

  • Многонаправленные LPS не поддерживаются.

  • LPS, управляемые PCE, не могут иметь вторичные пути без основного пути.

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

  • Время настройки и время сходимости (перенаправляемый, MBB) для exisiting LSP тот же, что и в предыдущих выпусках, при отсутствии LSP, управляемых PCE. Однако небольшое воздействие можно оказать на присутствие LPS, управляемых PCE.

  • Ожидается, что время вычисления МВТ будет значительно больше, чем локально-CSPF.

Топологии

Рис. 5: Настройка PCEP для MPLS RSVP-управление трафикомНастройка PCEP для MPLS RSVP-управление трафиком

В данном примере PCC – это маршрутизатор в направлении в направлении маршрутизатора, который подключается к внешнему активному PCE с состоянием.

Внешние LSP маршрутизатора PCC вычисляются следующим образом:

  1. Маршрутизатор PCC получает конфигурацию туннеля LSP, настроенную с помощью интерфейс командной строки. При условии, что полученная конфигурация включена с помощью внешних вычислений пути, PCC маршрутизатора станет известно, что некоторые из атрибутов LSP ( полоса пропускания, путь и приоритет) находятся под управлением PCE с контролем состояния и копрутют LSP на PCE.

    В данном примере называется внешний LSP, который настроен PCC-to-R2 от маршрутизатора PCC к маршрутизатору R2. Устройством интерфейс командной строки МБАЙТ, настроенным как PCC-to-R2 PCC-R0-R1-R2, является PCC-R0-R2. Полоса пропускания PCC-to-R2 для нее составляет 10 м. Значения приоритета установки и удержания имеют значение 4.

  2. Маршрутизатор PCC пытается извлечь атрибуты LSP, управляемые PCE. Для этого маршрутизатор PCC посылает PRpt-сообщение на PCE с состоянием, заявляя, что LSP конфигурирован. Сообщение PCRpt сообщает состояние LSP и содержит параметры локальной конфигурации LSP.

  3. PCE с состоянием изменяет один или несколько атрибутов делегирования LSP и отправляет новые параметры LSP маршрутизатору PCC через сообщение PCUpd.

  4. Получив новые параметры LSP, маршрутизатор PCC настраивает новый LSP и повторно сигнализирует о нем с помощью пути, предоставленного PCE.

    В данном примере PCE-provided МБАЙТ для PCC-to-R2 – PCC-R3-R2. Полоса пропускания PCC-to-R2 для нее составляет 8 м. Значения приоритета установки и удержания имеют значение 3.

  5. Маршрутизатор PCC отправляет PCRpt с новым RRO на PCE с состоянием.

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

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

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

Pcc

R0

R1

R2

R3

Процедуры

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

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

Настройка PCC маршрутизатора:

Прим.:

Повторите эту процедуру для всех Juniper Networks влияющих маршрутизаторов в домене MPLS после изменения соответствующих имен интерфейсов, адресов и любых других параметров для каждого маршрутизатора.

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

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

  2. Включить RSVP на всех интерфейсах PCC маршрутизатора, за исключением интерфейса управления.

  3. Настройте путь с коммутансировкой по метке (LSP) от маршрутизатора PCC к маршрутизатору R2 и включите внешнее управление LSP PCE.

  4. Настройте LSP от маршрутизатора PCC к маршрутизатору М2, который имеет локальное управление и переопределяется параметрами LSP, предоставленными PCE.

  5. Актив MPLS всех интерфейсов маршрутизатора PCC, за исключением интерфейса управления.

  6. Настройте IS-IS на всех интерфейсах PCC маршрутизатора, за исключением интерфейса управления.

  7. Определите PCE, к который подключается PCC маршрутизатора, и настройте IP-адрес PCE.

  8. Настройте порт назначения для PCC маршрутизатора, который подключается к PCE, используя PCEP на основе TCP.

  9. Настройка типа PCE.

Результаты

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

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

Проверки

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

Проверка состояния сеанса PCEP

Цель

Проверьте состояние сеанса PCEP между PCE и PCC маршрутизатора, когда состояние PCE в состоянии up.

Действий

В рабочем режиме запустите show path-computation-client active-pce команду.

Смысл

Выходные данные показывают информацию о текущем активном состоянии PCE, к который подключен PCC маршрутизатора. Поле PCE status выходных данных показывает текущее состояние сеанса PCEP между PCE и PCC маршрутизатора.

Для , состояние сеанса PCEP – это означает, что сеанс PCEP был установлен между однорангами pce1PCE_STATE_UP PCEP.

Статистика показывает количество сообщений, отправленных маршрутизатором PCC на PCE для отчета о текущем PCRpts состоянии LSP. Статистика PCUpdates показывает количество сообщений, полученных PCC маршрутизатора от PCE. Сообщения PCUpdates содержат измененные параметры PCE для LPS, управляемых PCE.

Проверка состояния LSP, контролируемого PCE, когда управление LSP является внешним

Цель

Проверьте состояние LSP, контролируемого PCE, от маршрутизатора PCC к маршрутизатору R2, когда LSP находится под внешним управлением.

Действий

В рабочем режиме запустите show mpls lsp name PCC-to-R2 extensive команду.

Смысл

Поля выходных данных LSPtype и LSP Control Status выходных данных показывают, что LSP находится под внешним управлением. Выходные данные также показывают журнал сообщений PCEP, отправленных между PCC маршрутизатора и PCE.

Сеанс PCEP между PCE и PCC маршрутизатора в том же направлении, и маршрутизатор PCC получает следующие параметры LSP, управляемые PCE:

  • МВТ (путь) — 20.31.4.2 и 20.31.5.2

  • Bandwidth—8Mbps

  • Приоритеты — 3 3 (значения настройки и удержания)

Проверка состояния LSP, контролируемого PCE, когда управление LSP является локальным

Цель

Проверьте состояние LSP, контролируемого PCE, от маршрутизатора PCC к маршрутизатору R2, когда управление LSP становится локальным.

Действий

В рабочем режиме запустите show mpls lsp name PCC-to-R2 extensive команду.

Смысл

В выходных данных поле LSP Control Status выходных данных показывает, что LSP находится под локальным управлением. Хотя LSP, управляемый PCE, находится под локальным управлением, маршрутизатор PCC продолжает использовать параметры, предоставленные PCE, до следующей возможности для повторного сигнала LSP.

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

  • Пропускная способность — 10 Мбит/с (фактическая полоса пропускания: 8 Мбит/с)

  • Приоритеты — 4 4 (Фактическиеприоры 3 3)

На триггере повторной сигнализации LSP, маршрутизатор PCC использует параметры локальной конфигурации для создания LSP, контролируемого PCE.

Это Computed ERO 20.31.1.2, 20.31.2.2 и 20.31.8.2. LSP, управляемый PCE, устанавливается с использованием локальных параметров конфигурации.

Примере: Настройка протокола path Computation Element Protocol для MPLS RSVP-управление трафиком с поддержкой LPS, инициированных PCE

В этом примере показано, как настроить клиент вычисления пути (PCC) с возможностью поддержки Path Computation Element (PCE) инициируемых трафиком маршрутов с поддержкой маршрутизации между точками с коммутацией по метке (LPS).

Требования

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

  • Три маршрутизатора, которые могут быть комбинацией серия ACX, M Series, серия MX или серия T маршрутизаторов.

  • TCP-соединение с двумя внешними pces с управлением состоянием от веского маршрутизатора (PCC).

  • Junos OS версии 16.1 или более поздней версии на PCC.

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

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

  • Настройка MPLS и RSVP-управление трафиком (RSVP-traffic engineering).

  • Настройте OSPF или любой другой IGP протокол.

Обзор

Начиная с Junos OS 16.1, функциональность PCEP расширена, позволяя PCE с состоянием запускать и управление трафиком LSP через PCC. Ранее LSP были настроены на PCC, и PCC делегировал контроль над внешними LSP PCE. Владельцем состояния LSP является PCC. С появлением LSP, инициируемых PCE, PCE может инициировать и настраивать LSP из точки управление трафиком динамически, без необходимости локально настроенного LSP на PCC. При получении сообщения PCCreate от PCE, PCC создает LSP, инициированный PCE, и автоматически копирует LSP на PCE.

При настройке поддержки LPS, инициированных PCE для PCC, необходимо учитывать следующие моменты:

  • Junos OS версии 13.3 поддерживают только PCEs с поддержкой с поддержкой состояния.

  • Для Junos OS версии 13.3 PCC всегда инициирует сеансы PCEP. Сеансы PCEP, инициированные удаленными PCEs, не принимаются PCC.

  • Существующие функции LSP, такие как защита LSP и передавка, работают для LSP, инициированных PCE.

  • LPS, инициированные PCE, не поддерживают модуль маршрутизации переключения (GRES).

  • LPS, инициированные PCE, в логических системах не поддерживаются.

  • LPS, инициированные PCE, не могут быть многоканальных LSP.

  • Многонаправленные LPS не поддерживаются.

  • RSVP-управление трафиком для ненумберных линий связи не поддерживается. LPS, инициированные PCE, поддерживают только про номера.

  • PCE, инициировал сегментную маршрутизационную LSP, может использовать метки связующего сегмента ID (SID), связанные с нецветными сегментными маршрутами LSP для предоставления путей LSP, инициированных PCE.

    Начиная с Junos OS выпуска 18.2R1, статически настроенные не-цветные сегменты маршруты LSP на впадающее устройство сообщаются PCE через сеанс PCEP. LSPs маршрутов нецветных сегментов могут иметь связывание с меткой SID, связанной с ними. При использовании этой функции PCE может использовать эту связываемую метку SID в стеке меток для предоставления путей LSP, инициированных PCE.

Топологии

Рис. 6: Пример PCE-initated Point-to-Point LSP для MPLS RSVP-управление трафикомПример PCE-initated Point-to-Point LSP для MPLS RSVP-управление трафиком

В данном примере PCC – это маршрутизатор в направлении в направлении маршрутизатора, который подключается к двум внешним PCEs с управлением состоянием: PCE1 и PCE2.

При новом требовании активный PCE с динамическим состоянием инициирует LSP в соответствии с этим требованием. Поскольку PCC настроен с возможностью поддержки PCE-инициируемых LSP, вычисление пути на PCC выполняется следующим образом:

  1. PCE отправляет PCC сообщение PCCreate для инициирования и предоставления LSP. PCC устанавливает LSP, инициированный PCE, используя параметры, полученные от PCE, и автоматически настраивает LSP, инициированный PCE, на Инициировал его.

    В данном примере PCE1 – это активный PCE с состоянием, который инициирует инициирует LSP на PCC, инициировал PCE. При получении параметров LSP, инициированных PCE, PCC настраивает LSP и автоматически настраивает LSP, инициированный PCE, в PCE1.

  2. Когда завершается сеанс PCEP между PCC и PCE1, PCC запускает два часа для LSP, инициированных PCE1: и время простоя очистки delgation и LSP. За это время PCE1 или PCE2 могут получить управление PCE-инициировал LSP.

  3. Если PCE2 получает контроль над PCE-инициализным LSP до истечения срока действия времени очистки LSP, то PCC копает LSP, инициированный PCE, в PCE2, а также время ожидания очистки, инициированное PCE, и время ожидания очистки lSP, и время ожидания очистки, инициализации очистки lSP, останавливаются.

  4. Если истекает время очистки расчищаемой мультсериалов, и ни PCE1, ни PCE2 не получили контроля над LSP, инициализ которого PCE, PCC берет на себя локальный контроль не делегирования LSP, инициированного PCE, до истечения срока времени очистки LSP.

  5. По истечении срока действия времени очистки LSP PCC удаляет LSP, инициированный PCE, инициированный PCE1.

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

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

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

Pcc

R1

R2

Процедуры

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

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

Настройка маршрутизатора PCC:

Прим.:

Повторите эту процедуру для всех Juniper Networks влияющих маршрутизаторов в домене MPLS после изменения соответствующих имен интерфейсов, адресов и любых других параметров для каждого маршрутизатора.

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

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

  2. Включить RSVP на всех интерфейсах PCC, за исключением интерфейса управления.

  3. Включить внешнее управление LSP с помощью PCEs.

  4. Актив MPLS на всех интерфейсах PCC, за исключением интерфейса управления.

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

  6. Определение группы PCE и поддержка LPS, инициированных PCE, для группы PCE.

  7. Определите PCEs, которые подключаются к PCC.

Результаты

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

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

Проверки

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

Проверка состояния PCC

Цель

Проверьте состояние сеанса PCEP и краткое описание LSP между PCC и подключенными PCEs.

Действий

В рабочем режиме запустите show path-computation-client status команду.

Смысл

Выходные данные показывают состояние сеанса PCEP между активными PCEs с состоянием и PCC. Здесь же отображаются сведения о различных типах LSP на PCC, а также о количестве LSP, которые были предусмотрены подключенными PCEs и делегированы им.

PCE1 является основным активным PCE и имеет один LSP, инициированный PCE, который был автоматически делегирован ему PCC.

Проверка состояния PCE1

Цель

Проверьте состояние основного активного PCE с состоянием.

Действий

В рабочем режиме запустите show path-computation-client active-pce detail команду.

Смысл

Выходные данные показывают информацию о текущем активном состоянии PCE, к которому подключен PCC. Поле PCE status выходных данных указывает на текущий статус сеанса PCEP между PCE и PCC.

Для PCE1 состояние сеанса PCEP – это означает, что сеанс PCE_STATE_UP PCEP был установлен с PCC.

Проверка состояния LSP, инициированного PCE, когда LSP инициировался внешне

Цель

Проверьте состояние LSP, инициированного PCE.

Действий

В рабочем режиме запустите show mpls lsp externally-provisioned detail команду.

Смысл

В выходных данных поле LSPtype выходных данных показывает, что LSP имеет внешнее обеспечение.

Сеанс PCEP между PCC и PCE1 состоится, и PCC получает следующие параметры LSP, инициированные PCE:

  • МВТ (путь) — 10.0.102.10 и 10.0.101.9

  • Пропускная способность — 8 Мбит/с

  • Приоритет — 7 0 (значения настройки и удержания)

Настройка протокола path Computation Element Protocol для MPLS RSVP-управление трафиком с поддержкой LPS, инициированных PCE

Можно настроить клиент path Computation Client (PCC) с возможностью поддержки динамически созданных маршрутов с коммутацией меток (LSPs) от централизованного внешнего объекта вычисления пути. Для выполнения вычисления внешнего пути и генерации динамических LSP при росте спроса можно использовать динамический элемент Вычисления пути (PCE).

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

LSP, интерфейс командной строки LSP, контролируемый PCE, и LSP, инициированный PCE, могут сосуществовать друг с другом на PCC.

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

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

  • Настройте MPLS и RSVP-управление трафиком.

  • Настройте OSPF или любой другой IGP протокол.

Чтобы настроить PCC на поддержку LSP, инициированных PCE-точками, выполните следующие задачи:

  1. В режиме конфигурации перейдите на следующий уровень иерархии:
  2. Укажите максимальное количество сообщений в минуту, которое может получать PCC.
  3. Укажите число внешних маршрутов коммутаторов с меткой (LSP) на всех подключенных ПК, которые может принимать PCC по максимуму.
  4. Укажите уникальный пользовательский определенный ID для подключенного PCE, чтобы настроить параметры PCE.
  5. Укажите время (в секундах), которое PCC должен подождать перед возвращением контроля LSP к процессу протокола маршрутизации после отключения сеанса PCEP.
  6. Укажите адрес IPv4 PCE для подключения с.
  7. Укажите номер порта TCP, который использует PCE.

    Значение может колебаться от 1 до 65535, а значение по умолчанию — 4189.

  8. Укажите время (в секундах), которое PCC должен подождать перед удалением любых не делегированных PCE-инициаторов LPS из сбойного PCE после окончания сеанса PCEP.
  9. Настройте PCC на прием SP, внешних, с помощью подключенных PCE. По умолчанию PCC отклоняет LPS, инициированные PCE.
  10. Укажите количество неизвестных сообщений в минуту, которое может получить PCC по максимуму после закрытия сеанса PCEP.

    Значение может колебаться от 1 до 16384, а по умолчанию – 0 (отключен или не ограничивается).

  11. Укажите число неизвестных запросов в минуту, которое может получать PCC по максимуму после окончания сеанса PCEP.

    Значение может колебаться от 0 до 16384, а значение по умолчанию - 5. Значение 0 отключает эту утверждение.

  12. Настройка типа PCE.
  13. Укажите время (в секундах), которое PCC должен дождаться ответа перед повторной темой запроса.

    Это значение может колебаться от 0 до 65535 секунд.

  14. Проверьте и сфиксировать конфигурацию.

Пример выходных данных

Примере: Настройка протокола path Computation Element Protocol для MPLS RSVP-управление трафиком с поддержкой LPS с поддержкой точек-точек в PCE

В этом примере показано, как настроить клиент вычисления пути (PCC) с возможностью представления отчетов о маршрутизации-многоточки трафика, спроектированного как метка коммутируемых путей (управление трафиком LPS) на элемент вычисления пути (PCE).

Требования

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

  • Три маршрутизатора, которые могут быть комбинацией серия ACX, M Series, серия MX или серия T маршрутизаторов.

  • Один виртуальный компьютер, настроенный с функцией virtual Route Reflector (VRR).

  • TCP-подключение к внешнему PCE с состоянием состояния от VRR.

  • Junos OS версии 16.1 или более поздней версии на PCC.

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

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

  • Настройте MPLS и RSVP-управление трафиком.

  • Настройте OSPF или любой другой IGP протокол.

Обзор

После того, как сеанс PCEP установлен между PCE и PCC, PCC сообщает все LSP в системе PCE для синхронизации состояния LSP. Это включает LPS, управляемые PCC, делегирование PCE и LPS, инициированные PCE. Начиная Junos OS 15.1F6 и 16.1R1, эта возможность распространяется и на LSP "точка-многоточки".

По умолчанию PCE не поддерживает многоканальный LSP. Чтобы добавить эту возможность, добавьте утверждение p2mp-lsp-report-capability на уровне [edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] иерархии или на иерархии.

Топологии

Рис. 7: Пример LPS, управляемых PCE между точкамиПример LPS, управляемых PCE между точками

В данном примере PCC является входящим маршрутизатором, маршрутизатор R1 является транзитным маршрутизатором, а маршрутизатор R2 – маршрутизатор исходящего трафика. PCC подключен к виртуальному отражателем маршрутов (VRR), который подключен к PCE. Между PCC, Маршрутизатором М1 и маршрутизатором М2 существует много точек интерфейса «точка-точка».

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

  1. Если PCC маршрутизатора сконфигурирован с точками-точками и многоканальных LSP без поддержки возможности представления отчетов между точками, подключенным PCE сообщаются только LSP "point-to-point". По умолчанию PCC не поддерживает возможность отчетов LSP с разных точек.

  2. Когда PCC маршрутизатора настроен с возможностями отчетов LSP "точка-многоточки", PCC сначала объявляет эту возможность PCE через сообщение отчета.

  3. По умолчанию PCE поддерживает возможность LSP между точками. Получив объявление PCC о возможности LSP "точка-многоточки", PCE в ответ объявляет PCC о своей возможности.

  4. Получив объявление PCE о функции "точка-многоточки", PCC отсылает все ветви LSP "точка-многоточки" PCE с помощью сообщения обновления.

  5. Как только все LSP сообщаются PCE, состояние LSP синхронизируется между PCE и PCC.

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

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

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

Pcc

R1

R2

R3

Процедуры

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

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

Настройка маршрутизатора PCC:

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

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

  3. Включить RSVP на всех интерфейсах PCC маршрутизатора, за исключением интерфейса управления.

  4. Актив MPLS всех интерфейсов PCC маршрутизатора, за исключением интерфейса управления.

  5. Настройте динамический LSP и отключите для LSP автоматическое вычисление пути.

  6. Настройте многоточки LSP и определите для LSP внешний объект вычисления пути.

  7. Включить вычисление внешнего пути для MPLS LPS и назначить шаблон для внешних LSP.

  8. Настройте LSP, которые имеют локальное управление и переопределяются параметрами LSP, предоставленными PCE.

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

  10. Назначьте настроенные административные групповые политики интерфейсам PCC маршрутизатора.

  11. Настройте политику управление трафиком (TED).

  12. Настройте внутреннюю BGP группу.

  13. Настройте управление трафиком для BGP и назначьте экспортную политику.

  14. Настройте OSPF области 0 на всех интерфейсах точки-многоточки маршрутизатора PCC.

  15. Настройте OSPF области 0 на интерфейсе "точка-точка" PCC маршрутизатора.

  16. В управление трафиком в OSPF в OSPF.

  17. Определите PCE, к который подключается PCC маршрутизатора, и настройте параметры PCE.

  18. Настройте PCC маршрутизатора для обеспечения возможности LSP "точка-многоточки" для вычисления внешнего пути.

  19. Настройте политику управление трафиком настройке.

Результаты

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

Проверки

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

Проверка конфигурации LSP на PCC

Цель

Проверьте тип и состояние работы LSP точки-многоточки.

Действий

В рабочем режиме запустите show mpls lsp extensive команду.

Смысл

Выходные данные отображают LSP lsp2-pcc LSP как LSP, управляемый PCE.

Проверка конфигурации PCE на PCC

Цель

Проверьте конфигурацию параметров PCE и состояние PCE.

Действий

В рабочем режиме запустите show path-computation-client active-pce команду.

Смысл

Выходные данные показывают активный PCE, к который подключен PCC маршрутизатора, а также параметры и состояние PCE pce1.

Понимание протокола path Computation Element Protocol для MPLS RSVP-управление трафиком с поддержкой LPS "точка-многоточки", инициированных PCE

Благодаря внедрению точек-многоточки PCE-Инициальных LSP PCE, PCE может инициировать и динамически инициировать многоканальный LSP без необходимости локальной конфигурации LSP на PCC. Это позволяет PCE управлять синхронизацией и последовательностью расчетов маршрутов между точками в сеансах Path Computation Element Protocol (PCEP) и через него, создавая таким образом динамическую сеть, которая централизованно контролируется и развертывается.

Преимущества многоканальных LPS, инициированных PCE

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

Сигнализация LPS point-multipoint, инициированных PCE

Сигнализация точек-точек LPS, инициированных PCE, передается следующим образом:

  • When a new branch is added (Grafting)- Сигнализируется только новый филиальный суб-LSP, который не приводит к повторной сигнализации всего дерева "точка-многоточки".

    Если какие-либо изменения топологии произошли до истощения нового под-LSP, то сервер вычисления пути (PCS) перерасчитает все дерево точек в многоточки и обновляет LSP "точка-многоточки" с помощью сообщения об обновлении ПК.

  • When a branch is deleted (Pruning)— удаленный филиальный суб-LSP размыкается и не приводит к повторной сигнализации всего дерева "точка-многоточки".

  • When a branch sub-LSP parameter is changed— Изменение параметров суб-LSP, таких как Explicit Route Object (МВК), полоса пропускания или приоритет, может произойти как в результате оптимизации, так и по запросу пользователя. При запросе повторной сигнализации для суб-LSP происходит повторная сигнализация всего дерева "точка-многоточки", после чего происходит переключение на новый экземпляр при включении новых экземпляров всех филиалов.

  • When a branch sub-LSP path fails- В PCS сообщается об ошибке филиальной под-LSP. При получении нового МВП от PCS происходит переподключение дерева point-multipoint наряду с сбоем под-LSP филиала, и переход на новый экземпляр происходит в модеме make-before break (MBB).

Поведение LSP, инициированных PCE и многоканальными LPS после сбоя сеанса PCEP

При неудачном сеансе PCEP LSP, инициализ которых инициировал PCE, не будут обанкречены до истечения state timeout времени. По state timeout истечении времени LPS, инициированные PCE, очищаются.

Чтобы получить управление PCE-инициировал точкой-многоточки LSP после сбоя сеанса PCEP, основной или вторичный PCE отправляет сообщение до истечения PCInitiatestate timeout времени.

Настройка возможности LSP "точка-многоточки" инициируемых PCE

По умолчанию создание и и предоставление PCE точек-многоканальных LSP на PCC не поддерживается. Чтобы включить эту возможность, включим p2mp-lsp-init-capability в себя а также утверждения на уровне p2mp-lsp-update-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] иерархии или на иерархии.

Утверждение p2mp-lsp-init-capability обеспечивает возможность предоставления PCE точек-многоточки RSVP-управление трафиком LPS. Утверждение обеспечивает возможность обновления параметров p2mp-lsp-update-capability LSP для точек-многоточки RSVP-управление трафиком PCE.

Поддерживаемые и неподдерживаемые функции для LPS, инициированных PCE-точками

Следующие функции поддерживаются с PCE-инициализными точками LPS:

  • Частичное соответствие проекту проекту Интернет-проекту ietf-pce-pce-stateful-pce-p2mp (истекает октября 2018 г.), Расширения протокола Path Computation Element (PCE) для использования PCE с соблюдением состояния для коммутационных путей point-to-Multipoint Traffic Engineering Paths.

  • Начиная с Junos OS 21.1R1, мы поддерживаем бесконечную активную маршрутную (NSR) для LSP, инициированных PCE,RSVP-точками. Только первичный модуль маршрутизации поддерживает сеанс PCEP с контроллером. Он синхронизирует все LPS RSVP, инициированные PCEs, включая спецификации многоафрового потока для любого PCE-инициирующего P2MP LPS, с резервным модуль маршрутизации. Во время переключения сеанс PCEP выключается и вновь включается, когда резервный модуль маршрутизации становится основным модуль маршрутизации. Это уменьшает потерю трафика, передается по RSVP LSP, инициированным PCE, модуль маршрутизации переключения. Эта функция включена при настройке NSR.

Следующие функции не поддерживаются LPS, инициированными PCE:.

  • Истока LSP с локальной управляемой точкой.

  • Контрольный контроль LSP.

  • Расширение протокола внутреннего шлюза (IGP) для обнаружения PCE внутри домена IGP маршрутов.

  • Передача сообщений запроса/ответа.

  • Прямое перемещение филиального под-LSP из одного дерева в многоточки в другую.

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

  • IPv6 не поддерживается.

  • Сигнализация на основе S ПРОСТОР не поддерживается.

  • Функция Пустой МВТ не поддерживается.

  • Защита соединения не поддерживается.

Сопоставление PCE-инициальных LPS между точками и MVPN

Можно связать один или диапазон многоадретных потоков MVPN (S,G) с динамически созданным путем переключения на многоточки (LSP) точками PCE. Данная функция может работать только с выборочными типами потоков. Это включает в себя:

  • Отличительный отличитель маршрута (RD), привязавающийся к экземпляру маршрутов MVPN.

  • (S,G) который является источником многоадретного пакета и адреса группы многоадретной вещания назначения. Используется для фильтрации входящих данных трафика для его сопоставления с туннелем.

  • Многоканальный LSP, используемый для отправки трафика, который соответствует вышеприведенийным спецификациям потока.

Дополнительные сведения см. в проекте проекта Интернет-проект ietf-pce-pcep-flowspec-05 (истекает 16 февраля 2020 г.) Расширение PCEPдля спецификации потока.

В текущей реализации этой функции не реализованы следующие разделы проекта:

  • Раздел 3.1.2. Объявления capabilties PCE в IGP

  • Раздел 3.2. Сообщение PCReq и PCRep

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

Чтобы включить сопоставление LPS между точками-точками PCE и MVPN:

  • Включит утверждение на иерархической уровне, чтобы указать поддержку PCC возможностей спецификации потока (также называемого управлением pce_traffic_steering[edit protocols pcep pce pce-id] трафиком).

  • external-controllerВключит утверждение на [edit routing-instances routing-instance-name provider-tunnel] уровне иерархии.

    Наличие в конфигурации поставщика-туннеля для MVPN указывает, что external-controller точка-многоточки LSP и (S,G) для этого экземпляра MVPN могут быть предоставлены внешним контроллером. Это позволяет внешнему контроллеру динамически настраивать (S,G) и многоканальный LSP для MVPN.

Примите во внимание следующее при сопоставлении PCE-инициальных точек LPS с MVPN:

  • Если не включить утверждение для конкретного экземпляра MVPN, процесс PCCD не будет динамически настраивать external-controller pccd (S,G).

  • Если отключить конфигурацию из интерфейс командной строки, то динамически выученные многоадронные потоки (S,G) для этого экземпляра MVPN удаляются и сообщаются внешнему external-controller pccd контроллеру.

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

  • Если какой-либо определенный (S,G) удаляется с внешнего контроллера динамически, и затем тот же (S,G) для того же экземпляра MVPN настраивается, то динамически заученный (S,G) удаляется и передается внешнему контроллеру через PCC.

  • Если процесс протокола маршрутизации перезагружается, процесс PCCD снова перенастроит все (S,G).

  • Если процесс PCCD перезагружается, MVPN сообщает все PCCD, настроенные (S,G) внешнему контроллеру.

  • Если пользователь включает для конкретного экземпляра external-controller pccd MVPN, то MVPN запрашивает процесс PCCD для настройки (S,G), если таковым является.

  • Если в конкретном экземпляре MPVN происходят серьезные изменения конфигурации, то MVPN запрашивает процесс PCCD для изменения конфигурации всего (S,G) для этого конкретного экземпляра MVPN.

  • Все спецификации потока, связанные с любым PCE-инициированным точкой-многоточки LSP, должны иметь одинаковый RD. Во время инициалирования ПК, если все спецификации потока не имеют разных RD, сообщение о инициировании ПК с ошибкой отброшено.

  • LSP точки-многоточки можно связать только с выборочным типом спецификаций потока, в противном случае сообщение инициирования ПК отброшено с ошибкой.

  • Во время обновления ПК, если все спецификации потока не имеют одинаковых RD либо из-за добавления новой спецификации потока, либо из-за существующего обновления спецификации потока, то PCC отбрасняет сообщение об обновлении.

  • Обновление ПК, если все технические требования потока не соответствуют выборочным условиям либо из-за добавления новой спецификации потока, либо из-за существующих спецификаций потока, то PCC отбрасняет сообщение об обновлении.

  • Поведение для сопоставления PCE-инициируемых точек-многоканальных LSP с экземпляром маршрутирования MVPN и сопоставления статического (локально настроенного) LSP между точками с экземпляром MVPN на одном и том же уровне пользователя.

  • ID спецификации потока может быть связан только с одной точкой-многоточки LSP. Чтобы связать один и тот же RD и (S,G) с многоканальных LPS, можно добавить несколько спецификаций потока с различными ID и тем же RD и (S,G).

  • Для динамической карты PCEP (S,G) пороговое значение всегда является значением по умолчанию, 0.

  • Число спецификаций потока, относя их к одному ИНИЦиалуалу PCE-многоточки LSP, не ограничивается.

  • Текущая реализация данной функции не поддерживается:

    • Отчетность о состояниях переад назначения, связанных с LSP "точка-многоточки".

    • Динамическая конфигурация туннеля поставщика включительно

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

    • Программируемый процесс протокола маршрутизации (prpd)

    • Отчет о интерфейс командной строки LSP, настроенных как точка-многоканальный LSP, который сопописан многоадретным потокам MVPN (S,G).

Включить сегментную маршрутацию для протокола path Computation Element Protocol

SUMMARY Для управления трафиком можно включить сегментную маршрутацию или маршрутацию пакетов источника в сети (SPRING) управление трафиком (SR-управление трафиком) с помощью протокола расчета пути (PCEP) для управления трафиком. С помощью этой поддержки преимущества сегментной маршрутизации расширены на пути с коммутацией по метке (LSP), которые внешне управляются элементом вычисления пути (PCE).

Обзор протокола "Segment Routing for the Path Computation Element Protocol"

Преимущества сегментной маршрутации для PCEP

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

    Преимущества сегментной маршрутизации расширены до LPS, инициированных внешним контроллером, также известным как элемент вычисления пути (PCE), что увеличивает преимущества вычисления внешнего пути в MPLS сети.

  • Клиент вычисления пути (PCC, который является маршрутизатором в направлении серия MX), который может вернуть контроль за делегированием сегментной маршрутизации LSP от PCE при отступе сеанса PCEP; иначе LSP будут удалены из PCC. Таким образом, можно обеспечить защиту данных LSP, предотвратив ситуацию, когда пакеты тихо отбрасываются или отбрасываются (также известно как "нулевое состояние маршрута").

Сегментная маршрутация для управления трафиком

Сегментная маршрутация может работать через IPv4 или IPv6 плоскость данных и поддерживает многоканальный маршрут с равной стоимостью (ECMP). Благодаря встроенным IGP расширениям сегментная маршрутизация интегрируется с многофункционными возможностями мультисервисного обслуживания MPLS, включая VPN 3-го уровня, виртуальный частный кабельный сервис (VPWS), виртуальный частный lan-сервис (VPLS) и Ethernet VPN (EVPN).

Некоторые из высокотехнологичных компонентов сегментной маршрутации — управление трафиком (SR–управление трафиком) включают:

  • Использование ссылки IGP для объявления характеристик соединения. Эта функциональность аналогична RSVP-управление трафиком.

  • Сначала используйте ограниченный кратчайший путь (CSPF) на впадающее устройство или PCE.

  • Использование ссылки IGP меток для ссылок.

    Функции SR-управление трафиком:

    1. Въехающее устройство строит LSP с помощью стеков меток связей, которые он хочет пройти.

    2. Объявление комбинируются с IGP меток для создания маршрутизательных LSP на входящем устройстве, поэтому транзитные устройства не осведомлены о конечных LSP.

    3. LSP создаются между гранными узлами, не устанавливая каких-либо требований к памяти для каждого LSP на транзитных устройствах. (Создание таких LSP включено, так как в SR-управление трафиком нет сигнализации по LSP.

    4. Метки для соседей стеков, что приводит к управлению большим количеством меток, что приводит к плоскость управления масштабирования.

Junos OS сегментной маршрутации для PCEP

Junos OS сегментную маршрутику для PCEP для двух типов LSP — LSP, инициированных PCE, и LPS, делегированную PCE.

LPS, инициированные PCE, сегментная маршрутиация

LSPS, инициированные PCE- это LPS, которые создаются PCE для сегментов сопутства и узла

PCE выполняет следующие функции:

  1. Вычисляет путь LSP сегментной маршрутации.

  2. Обеспечение LSP на клиенте вычисления пути (PCC) с использованием расширения маршрутизации сегмента PCEP.

  3. Проансирует расширения сегментной маршрутки PCEP.

  4. Создает туннельный маршрут на PCC с собственным значением предпочтения и доступна в таблице маршрутов inet.3 для разрешения IP-трафика и услуг, как и любой другой туннельный маршрут.

PCC выполняет следующие функции:

  1. Выбор выходного интерфейса на основе первого идентификатора сетевого доступа (NAI) в источнике Explicit Route Object (S-МБАЙТ).

    Junos OS поддерживают S-EROs, содержащие первый переход в качестве строгого перехода; Junos OS не поддерживает выбор исходя из интерфейса на PCC на основе сегмента узла свободного перехода (SID). Однако оставшиеся переходы могут быть свободной. Для S-EROs, которые находятся за пределами первого перехода, не делается специальной обработки, кроме использования метки для создания следующего перехода.

  2. Отклонение S-МВК, если:

    • В S-МВК нет меток.

    • S-МВК содержит более шести переходов.

    PCC создает маршрут с равной стоимостью многопутевой (ECMP) при нескольких LSP к одному месту назначения с той же метрикой.

  3. Ждет обработку PCE любого события, которое приводит к изменению LSP маршрутизации сегмента после его инсументации, например, если метка изменена или снята, или если один из интерфейсов, которые проходят через LSP, отстает.

Когда сеанс PCEP отстает, LSP, инициированный PCE сегментной маршрутисти:

  1. Остается в течение 300 секунд.

  2. Удален из PCC через 300 секунд.

Дополнительные сведения см. в проекте Интернет-проектов draft-ietf-pce-lce-lsp-setup-type-03.txt (истекает 25 декабря 2015 г.), документ "Конвейер типа настройки пути в сообщениях PCEP" и draft-ietf-pce-segment-routing-06.txt (истекает 10 февраля 2016 г.), расширения PCEPдля сегментной маршрутации.

LPS, делегированная PCE-сегментная маршрутация

LSPS, делегируемые PCE-сегментом, – это LPS, которые PCC настраивает локально, а затем настраивают к контроллеру PCE.

Прим.:

Junos OS поддерживают 20.1R1:

  • Возможность инскрипации PCE только для неприрезементных сегментных маршрутов LPS с пунктами назначения IPv4.

  • Отчеты и отчеты только о первом сегменте списка сегментов внешнему контроллеру. Несколько сегментов не поддерживаются для затюмки PCE.

PCC может делегировать LSP сегментной маршрутации внешнему контроллеру (PCE) следующим образом:

  • Initial delegation- Локальные LSP еще не настроены на PCC, и отсрочка LSP происходит в момент настройки LSP.

  • Delegation of existing LSP- Локальные LSP настраиваются на PCC, и переописка LSP происходит после настройки пути маршрутирования источника. То есть возможность зависимости от сегмента маршрутов на LSP включена.

После делегирования LSP сегментной маршрутизации PCE управляет переданным LSP и может изменять атрибуты LSP для вычисления пути. Управление LSP возвращается к PCC, когда сеанс PCEP между PCC и PCE отстает. LPS, делегированная PCE, имеет преимущество перед LPS, инициированными PCE, в случае, если сеанс PCEP не проходит. В случае LPS, инициированных PCE, когда сеанс PCEP неавт, LSPs удаляются из PCC. Однако в случае, когда PCE-делегированная LPS, когда сеанс PCEP отстает, PCC возвращает управление делегированным LSP от PCE. В результате при условии, что LPS, делегированная PCE, предотвратит отбрасывание пакетов (также известное как null route condition) во время сеанса.

LSP сегментной маршрутации следующих типов поддерживают функцию PCE-деления:

  • Static LSPs— Статически настроенные пути маршрутов-источников, в которые статически настроен весь стек меток.

  • Auto-translated LSPs— Статически настроенные пути маршрутов-источников, которые автоматически преобразуются.

  • Computed LSPs- Статически настроенные пути маршрутов-источников, которые вычисляются с помощью распределенного ограниченного кратчайших пути (CSPF).

  • Dynamic LSPs— Туннели, созданные динамически, запускаются с помощью модуля динамического туннеля с разрешением ALLY на последнем переходе.

В зависимости от источника сегментной маршрутации LSP, можно настроить возможность отсрочки на PCC. Чтобы включить иерархию сегментных маршрутов LPS, включив в иерархию утверждение на lsp-external-controller pccd соответствующем [edit protocols source-packet-routing] уровне.

Табл. 2 отображает сопоставление источника LSP с соответствующим уровнем иерархии конфигурации, на котором включена возможность отображения отображения.

Прим.:

Следует включить утверждение на уровне иерархии и на уровне иерархии, прежде чем настраивать возможность ненастройки lsp-external-controller pccd[edit protocols source-packet-routing] в [edit protocols mpls] PCC.

Табл. 2: Сопоставление источника LSP сегментной маршрутки с иерархией конфигурации

Источник LSP сегментной маршрутации

Иерархия конфигураций

  • Автоматически переведенные LPS

  • Статические LPS

Список первичного сегмента: [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

Расчетные LSP (распределенный CSPF)

Первичный список сегментов пути маршрутов-источников:

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

Динамические LPS

Первичный список сегментов шаблона пути маршрутов-источников:

  • [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]

  • [edit protocols source-packet-routing source-routing-path-template template-name]

Статус управления SR-управление трафиком LPS можно просмотреть в выходных данных команды show spring-traffic-engineering.

Табл. 3 Отображает взаимодействие PCEP, когда утверждение lsp-external-controller настроено для пути маршрутов источника.

Табл. 3: Неумеха взаимодействия PCEP LSP

Иерархия конфигурации lsp-external-controller

Состояние "исходный маршрут-путь"

Взаимодействие PCEP между PCC и PCE

Список первичного сегмента пути маршрутов-источников

Начальный начальный проект

  1. Сообщение PCReport отправляется на PCE для затребовки. В PCReport содержатся только ограничения и данные о пути (например, МРОТ).

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

  3. Локальный LSP не программирует маршрут до тех пор, пока контроллер не вычислит IES и не выведет результат на PCC через PCUpdate.

Такое же поведение происходит, когда процесс протокола маршрутизации (rpd) возобновляется или происходит модуль маршрутизации переключение.

Список первичного сегмента пути маршрутов-источников

Неумеха существующего пути

  1. PcReport отправляется на PCE для затребовки. В PCReport содержатся только ограничения и данные о пути (например, МРОТ).

  2. Соответствующий основной сегмент делегирован PCE.

  3. PCE вычисляет путь для LSP.

  4. Основной сегмент продолжает внести свой вклад в маршрут в соответствии с локальной конфигурацией или вычислением до тех пор, пока PCUpdate не будет получен от PCE.

    • Если seamless BFD (S-BFD) не настроен для основного сегмента, дальнейшего обновления маршрута нет, и состояние LSP также не отслеживается и не сообщается PCE. Состояние LSP в этой точке сообщается как в состоянии up или down в зависимости от того, успешно ли в тот момент было успешно вычислено состояние пути.

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

  5. Если от PCE получено сообщение PCUpdate, SR-управление трафиком использует полученный параметр для того, чтобы настроить путь, по которому было послано сообщение PCReport. Затем программный путь включает в себя только список сегментов, полученный от PCE, а все остальные запрограммированные до этого списки сегментов удаляются. Такое перепрограммное перепрограмм

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

Не настроен и не удален.

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

Список сегментов пути маршрутов-источников

После настройки LSP включена возможность отсюмы.

Для списка первичного сегмента в пути маршрутной маршрутации источника запускается функция уеханий.

Список сегментов пути маршрутов-источников

Не настроен и не удален.

Функции фрагментации удаляются из списка первичных сегментов в соответствии с маршрутиали-источником.

Список первичных сегментов шаблона пути маршрутизации источника

После настройки LSP включена возможность отсюмы.

  • В шаблоне пути маршрутов-источников — в этом шаблоне функциональность Неавтирования активна для всего пути маршрутов источника.

    Конфигурации шаблона могут применяться только к динамическим туннельным модулям.

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

Список первичных сегментов шаблона пути маршрутизации источника

Не настроен и не удален.

Функции уединия удаляются со всех исходных маршрутов и основных путей, которые соответствуют конфигурации шаблонов.

Сегментная маршрутная маршрутка для ограничений PCEP и неподтвержденых функций

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

  • SR-управление трафиком LSP не защищен локально на PCC. Когда LSP более чем на шесть переходов, на LSP не предоставляется обслуживание, кроме как для переноса простого IP-трафика.

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

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

  • IPv6 не поддерживается.

  • LPS, делегированная PCE, не поддерживает следующее:

    • Цветные SR-управление трафиком LPS

    • LSP IPv6

    • Список вторичных сегментов пути маршрутов-источников. Можно делегировать только один путь в списке сегментов.

    • Стандарт мультиэрегации. Только первый сегмент списка сегментов делегирован и передан контроллеру.

Примере: Настройка сегментной маршрутизации для протокола Path Computation Element Protocol

В данном примере показано, как настроить сегментную маршрутацию или маршрутизации пакета источника в сети (SPRING) управления трафиком (SR-управление трафиком) для протокола path Computation Element Protocol (PCEP). В конфигурации мы используем преимущества сегментной маршрутации с преимуществами вычисления внешнего пути для эффективного управление трафиком.

Требования

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

  • Четыре серия MX универсальные платформы маршрутизации 5G, где маршрутизатор в направлении серия MX является клиентом вычисления пути (PCC).

  • TCP-соединение между PCC и внешним элементом вычисления пути с управлением состоянием (PCE).

  • Junos OS версии 17.2 или более поздней на PCC для реализации LPS, инициированных PCE.

    Для функций PCE-нее необходимо запустить версию Junos OS или более 20.1R1 или более поздней версии.

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

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

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

  • Настройте IS-IS.

Обзор

В Junos OS сегментной маршрутации для PCEP входят LPS, инициированные PCE, и SR-управление трафиком PCE.

  • Внедрение LPS, инициированных PCE, внедряется в Junos OS 17.2R1, где возможности сегментной маршрутации трафика поддерживаются в сеансах PCEP для LSP, инициированных PCE. PCE создает LSP для сегментов сдежности и узла. Туннельные маршруты создаются в таблице маршрутов inet.3 PCC в соответствии с LPS, инициированными PCE управление трафиком SR.

  • Применение LSP, делегируемых PCE, внедряется в Junos OS выпуска 20.1R1, где локально настроенные LSP маршрутирования нестандартного сегмента IPv4 на PCC могут делегироваться контроллеру PCE. После этого PCE управляет LSP и может изменять атрибуты LSP для вычисления пути.

LPS, делегированная PCE, имеет преимущество перед LPS, инициированными PCE, в момент, когда сеанс PCEP не проходит. В случае LPS, инициированных PCE, когда сеанс PCEP неавт, LSPs удаляются из PCC. Однако в случае, когда PCE-делегированная LPS, когда сеанс PCEP отстает, PCC возвращает управление делегированным LSP от PCE. В результате при условии, что LPS, делегированная PCE, предотвратит отбрасывание пакетов (также известное как null route condition) во время сеанса PCEP.

Чтобы включить сегментную маршрутику для PCEP:

Для LPS, инициализющих PCE сегментов маршрутов:

  1. Включив вычисление внешнего пути MPLS, включив утверждение lsp-external-controller на [edit protocols mpls] уровне иерархии.

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

  2. Включив вычисление внешнего пути для управление трафиком SR-управление трафиком включив утверждение lsp-external-controller pccd на [edit protocols spring-traffic-engineering] уровне иерархии.

  3. Включив сегментную маршрутику для PCE, включив в нее утверждение spring-capability на [edit protocols pcep pce pce-name] уровне иерархии.

  4. При желании настройте максимальную глубину SID для PCE, включив утверждение max-sid-depth number на [edit protocols pcep pce pce-name] уровне иерархии.

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

  5. При желании настройте значение предпочтения для сегментной маршрутки, включив на preference preference-value[edit protocol spring-te] иерархический уровень.

    Значение предпочтения указывает порядок выбора пути в качестве активного пути среди кандидатов в пути, где более высокое значение является более высоким. Если параметр не настроен, по умолчанию задается значение предпочтения 8.

  6. При желании настройте регистрацию сегментной маршрутки для устранения неполадок, включив в нее утверждение уровня traceoptions[edit protocols spring-te] иерархии.

Для PCE-рефекции LSP сегментной маршрутации в дополнение к дополнительным шагам необходимо сделать следующее:

  1. Определите список сегментов с параметрами метки. Это создает LSP сегментной маршрутки локально на PCC.

  2. Включить возможность отсрочки локально настроенного LSP на PCC, включив утверждение в любой из следующих иерархий, в зависимости от источника lsp-external-controller pccd LSP сегментной маршрутации:

    • Для статически настроенных исходных маршрутных путей, которые вычисляются с помощью распределенного CSPF и [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name][edit protocols source-packet-routing source-routing-path lsp-name primary path-name] уровней иерархии.

    • Для статически настроенных путей маршрутов-источников, в которые статически настроен весь стек меток, а маршруты источника автоматически преобразуются— иерархический [edit protocols source-packet-routing source-routing-path lsp-name primary path-name] уровень.

    • Для динамически созданных туннелей, запускаемых через динамический туннельный модуль с разрешением ALLY последнего перехода, [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name][edit protocols source-packet-routing source-routing-path-template template-name] и уровнями иерархии.

Топологии

Рис. 8 иллюстрирует пример топологии сети с сеансом PCEP, запущенным между PCE и PCC (маршрутизатором в серия MX-маршрутизатором). Маршрутизаторы R1, R2 и R3 являются другими серия MX в сети. В данном примере настроена сегментная маршрутка для PCEP на PCC. Также настроим статический маршрут на PCC к маршрутизатору 3 для проверки использования маршрутов туннеля SR-управление трафиком при маршрутке трафика для статического маршрута.

Рис. 8: Сегментная маршрутация для PCEPСегментная маршрутация для PCEP

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

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

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

Хотя в данном разделе представлена конфигурация всех устройств (PCC и трех маршрутизаторов), пошаговая процедура документировать только конфигурацию PCC.

Pcc

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

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

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

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

В данном примере настраивается только PCC.

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

Настройка PCC:

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

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

  3. Настройте статический маршрут от PCC к маршрутизатору R3.

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

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

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

  6. Включить возможность вычисления внешнего пути для MPLS.

  7. Настройте IS-IS 2-м уровне на всех интерфейсах PCC, за исключением интерфейсов управления и обратной связи.

  8. Настройте атрибуты сегментной маршрутной глобальной блокировки (SRGB) для сегментной маршрутации.

  9. Вние возможности вычисления внешнего пути для SR-управление трафиком.

  10. Настройте параметры PCE и в настройте инсинг LSP PCE и возможность сегментной маршрутации.

  11. В возможности инсурсации LSP сегментной маршрутки PCE.

  12. В включается возможность сегментной маршрутации для PCE.

  13. Определите параметры списка static_seg_list_1 статических сегментов.

  14. Настройте статическую сегментную маршрутку LSP от PCC к маршрутизатору 3 для отсрочки PCE.

  15. Включить возможность зависимости от источника static_srte_lsp_1 маршрутов.

    Выполив шаги 13, 14 и 15, PCC сможет делегировать LSP сегментной маршрутации PCE.

  16. Сфиксировать конфигурацию.

Результаты

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

Если настройка устройства (PCC) уже была сделана, commit войдите в режим конфигурации.

Проверки

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

Проверка IS-IS и меток
Цель

Проверьте IS-IS на PCC. Обратите внимание на диапазон меток SRGB, значения сегмента узла и значения сегмента узла, а также поля выходных данных функции SPRING.

Действий

В рабочем режиме запустите show isis adjacency extensiveshow isis database extensive команды и show isis overview команды.

Смысл

Отношения IS-IS между PCC и PCE, а также между PCC и маршрутизатором R1, находятся в рабочем состоянии. В выходных данных также отображаются назначения меток для смежных сегментов и узлов.

Проверка базы данных управления трафиком
Цель

Проверьте записи управление трафиком базы данных на PCC.

Действий

В рабочем режиме запустите show ted database extensive команду.

Смысл

База управление трафиком содержит записи, объявленные маршрутизаторами М1, R2 и R3, которые PCE использует для вычисления внешнего пути для PCC.

Проверка SR-управление трафиком LPS
Цель

Проверьте создание SR-управление трафиком LSP на PCC.

Действий

В рабочем режиме запустите show path-computation-client lspshow spring-traffic-engineering lsp detail команды и show route protocol spring-te команды.

Смысл

Выходные данные показывают, что два SR-управление трафиком LSP и были созданы PCE для сегментов сдежности и узлов adj_sid_lspnode_sid_lsp соответственно.

Сегментная маршрутная маршрутка LSP static_srte_lsp_1 включена с возможностью отсрочки маршрутов. Поле показывает состояние управления и маршрутов для PCE-делегированных LPS. Указывает, что PCE имеет контроль над Delegation info LSP. Указывает, что PCE обеспечил IES для пути маршрутов Externally controlledExternally routed источника.

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

Проверьте туннельные маршруты, созданные для SR-управление трафиком LPS, включенных в таблицу маршрутов inet.3 на PCC.

Действий

В режиме работы запустите show route table inet.3 extensive команду.

Смысл

Туннельные маршруты были созданы для LSP-назначения, контролируемого PCE, управление трафиком меткой протокола SR-управление трафиком.

Проверка записей таблицы переад нет
Цель

Убедитесь, что SR-управление трафиком LSP-назначения маршрутизатору R3 установлен в таблица переадресации PCC.

Действий

В режиме работы запустите show route forwarding-table destination ip-address extensive команду.

Смысл

IP-адрес назначения SR-управление трафиком LSP маршрутизатору 3 установлен в качестве записи переадправления.

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

Убедитесь, что статический маршрут берет туннельный маршрут, созданный для LSP SR-управление трафиком.

Действий

В рабочем режиме запустите show route ip-address команды show route forwarding-table destination ip-address и команды.

Смысл

Выходные данные показывают, что статический маршрут к маршрутизатору 3 использует туннельный маршрут, созданный для LSP управление трафиком SR.

Путь коммутации меток статического сегмента

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

Понимание статической сегментной маршрутки LSP в MPLS сетях

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

Введение в LPS сегментной маршрутации

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

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

Dynamic segment routing LSPs-Когда LSP сегментной маршрутизации создается внешним контроллером и загружается на вющее устройство через расширения протокола вычисления пути (PCEP) или из политики маршрутизации сегмента BGP через расширения BGP сегмента маршрутизации, LSP динамически предусматривается. Список сегментов динамической сегментной маршрутации LSP содержится в объекте точного маршрута PCEP (МВК), или BGP маршрутной политики сегмента LSP.

Static segment routing LSPs-Когда LSP сегментной маршрутации создается на в агрессивном устройстве с помощью локальной конфигурации, LSP статически и составляется.

LSP статической сегментной маршрутки можно далее классифицировать как цветные и нецветные LSP в зависимости от конфигурации утверждения на color[edit protocols source-packet-routing source-routing-path lsp-name] уровне иерархии.

Например:

[edit protocols]
    source-packet-routing {
    source-routing-path lsp_name {
        to destination_address;
        color color_value;
        binding-sid binding-label;
        primary segment_list_1_name weight weight;
        ...
        primary segment_list_n_name weight weight;
        secondary segment_list_n_name;
        sr-preference sr_preference_value;
    }
}

В данном случае каждое первичное и вторичное утверждения относятся к списку сегментов.

[edit protocols]
source-packet-routing {
    segment-list segment_list_name {
        hop_1_name label sid_label;
        ...
        hop_n_name label sid_label;
    }
}

Преимущества использования LPS сегментной маршрутации

  • Статическая сегментная маршрутка не зависит от состояния пересылки LSP на транзитных маршрутизаторах. Таким образом, снятие необходимости и подготовка и обслуживание для каждого состояния пересылания LSP в ядре.

  • Обеспечивает более высокую масштабируемость MPLS сетей.

Цветная статическая маршрутка для сегмента LSP

LSP статической сегментной маршрутки, настроенный с color утверждением, называется цветным LSP.

Понимание статических статических сегментов маршрутов LPS

Как и BGP сегментной политики маршрутов, вющий маршрут цветного LSP устанавливается в таблицах маршрутов или в качестве ключа для сопоставления inetcolor.0inet6color.0destincation-ip-address, color IP-трафика.

LSP статической цветной сегментной маршрутки может иметь привязку SID, для которого маршрут установлен в mpls.0 таблице маршрутов. Эта метка привязки SID используется для привязки помеченного трафика к LSP сегментной маршрутки. Шлюзы маршрута получены из конфигураций списка сегментов по основному и вторичному пути.

Список сегментов цветных сегментных маршрутов LPS

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

Нецветная статическая маршрутка сегмента LSP

LSP статической сегментной маршрутки, настроенный без утверждения, color является нецветным LSP. Как и в туннелях сегментной маршрутки PCEP, маршрут в направлении в направлении компьютера заносится в inet.3 таблицы или inet6.3 таблицы маршрутов.

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

Понимание LSP маршрутов нецветных сегментов

Нецветный сегмент маршрутов LSP имеет уникальное имя и IP-адрес назначения. В таблице маршрутов inet.3 задается веский маршрут к месту назначения с предпочтением по умолчанию 8 и метрикой 1. Этот маршрут позволяет соедиировать нецветные службы на LSP сегментной маршрутации, относящийся к месту назначения. Если нефресные сегменты маршрутов LSP не требуют веского маршрута, то вющий маршрут может быть отключен. Нецветная сегментная маршрутная маршрутка LSP использует привязку метки SID для обеспечения зашивание LSP сегментной маршрутизационной маршрутизационных технологий. Эта метка, которую можно использовать для модели сегментной маршрутации LSP как сегмент, который можно использовать для создания LSP других сегментов маршрутов иерархической структурой. Транзитный параметр привязки sid метки по умолчанию имеет значение 8 и метрику 1.

Начиная с Junos OS выпуска 18.2R1, LPS маршрутизации статически настроенных не-цветных сегментов на в выходном устройстве сообщаются элементу вычисления пути (PCE) через сеанс Path Computation Element Protocol (PCEP). Эти LSPS маршрутов нецветных сегментов могут иметь связанные с ними метки привязки идентификатора службы (SID). При использовании этой функции PCE может использовать эту связываемую метку SID в стеке меток для предоставления путей LSP, инициированных PCE.

LSP нецветной сегментной маршрутации может иметь не более 8 основных путей. Если существует несколько рабочих основных путей, то механизм переадружания пакетов (PFE) распределяет трафик по путям на основе таких факторов распределения нагрузки, как вес, задаемый по пути. Это равной стоимости нескольких путей (ECMP), если ни один из путей не имеет веса, настроенного на них или взвешеного ECMP, если хотя бы один из путей имеет ненулевой вес, настроенный на этих путях. В обоих случаях, когда один или несколько путей сбой, PFE перебалансирует трафик по оставшимся путям, что автоматически приводит к обеспечению защиты пути. LSP нецветной сегментной маршрутки может иметь вторичный путь для защиты выделенного пути. При сбое основного пути PFE перебалансирование трафика на оставшиеся функциональные основные пути. В противном случае PFE переключает трафик на резервный путь, таким образом достигая защиты пути. Нефресная сегментная маршрутная маршрутная система LSP может задать метрику для своих маршрутов в направлении впадающего и [edit protocols source-packet-routing source-routing-path lsp-name] связывания-SID. Несколько нецветных сегментов маршрутов LPS имеют один и тот же адрес назначения, который вносит свой вклад в следующий переход на впадаемом маршруте.

Несколько нецветных сегментов маршрутов LPS имеют один и тот же адрес назначения, который вносит свой вклад в следующий переход на впадаемом маршруте. Каждый путь (первичный или вторичный) каждого сегментного LSP маршрутизации считается кандидатом в шлюзы, если путь функционирует, а LSP сегментной маршрутации имеет наилучшее предпочтение от всех LSP, маршрутизющих сегмент. Однако максимальное количество шлюзов, которое может удерживать следующий переход, не может превышать RPD предела многоканального пути, то есть 128 по умолчанию. Дополнительные пути отсоединены, сначала вторичные, а затем первичные. Эти LPS, маршрутизющие сегменты, могут несколько раз называть данный список сегментов основными или вторичными путями. В данном случае существует несколько шлюзов, каждый из которых имеет уникальный ID туннеля LSP сегментной маршрутки. Эти шлюзы отличаются друг от друга, хотя у них одинаковый стек исходяющих меток и интерфейс. Нецветные сегменты маршрутов LSP и цветные сегментные маршруты LSP также могут иметь один и тот же адрес назначения. Однако они соответствуют разным адресам назначения для впадающих маршрутов, так как цветной сегмент маршруты адреса назначения LSP сконструированы как с адресом назначения, так и с цветом.

Прим.:

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

Список сегментов нецветных сегментов маршрутов LPS

Список сегментов состоит из списка переходов. Эти переходы основаны на метки SID или IP-адресе. Число меток SID в списке сегментов не должно превышать максимального предела списка сегментов. Максимальный размер привязки сегмент-списка к туннелю LSP увеличивается с 8 до 128 с максимальным числом туннелей 1000 на систему. Не более 128 основных путей поддерживаются для каждого статического сегмента маршрутизации LSP. Можно настроить максимальный предел списка сегментов на [edit protocols source-packet-routing] уровне иерархии.

До Junos OS релиза 19.1R1, что для неприметной статической маршрутации LSP сегмента, первый переход в списке сегментов должен быть IP-адресом выходного интерфейса, а второй – n-th-переходами с sid-меткой. Начиная Junos OS выпуске 19.1R1, данное требование не применяется, так как первый переход нецветных статических LSP теперь поддерживает метки SID помимо IP-адресов. С помощью поддержки метки первого перехода MPLS быстрая перемаршрутизация (FRR) и взвешенный многопутевой многопутевой маршрут для статического нецветного сегмента маршрутов LSP, подобно цветным статическим LSP.

Для того чтобы вступает в силу режим метки первого перехода, необходимо включить утверждение глобально или отдельно для списка сегментов, а первый переход в списке сегментов должен включать и IP-адрес, inherit-label-nexthops и метку. Если в первом переходе содержится только IP-адрес, inherit-label-nexthops утверждение не влияет.

Можно настроить в inherit-label-nexthops любой из следующих иерархий. Утверждение inherit-label-nexthops вступает в силу, только если список сегментов первого перехода включает и IP-адрес, и метку.

  • Segment list level—На уровне [edit protocols source-packet-routing segment-list segment-list-name] иерархии.

  • Globally—На уровне [edit protocols source-packet-routing] иерархии.

Когда утверждение настроено на глобальном уровне, он имеет приоритет над конфигурацией уровня списка сегментов, и конфигурация применяется во всех inherit-label-nexthopsinherit-label-nexthops списках сегментов. Если утверждение не настроено глобально, только списки сегментов с меткой и IP-адресом присутствуют при первом переходе и настроенные с помощью утверждения решаются с помощью inherit-label-nexthopsinherit-label-nexthops меток SID.

Для динамических не-статических статических LPS, то есть LSP сегментов маршрутов, управляемых PCEP, утверждение должно быть включено глобально, так как конфигурация уровня сегмента inherit-label-nexthops не применяется.

Табл. 4 описывает режим разрешения LSP сегментной маршрутки на основе спецификации первого перехода.

Табл. 4: Нецветное статическое разрешение LSP на основе спецификации первого перехода

Спецификация первого перехода

Режим разрешения LSP

только IP-адрес

Например:

segment-list path-1 {
    hop-1 ip-address 172.0.12.2;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Список сегментов разрешен с использованием IP-адреса.

только SID

Например:

segment-list path-2 {
    hop-1 label 1000011;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Список сегментов разрешен с помощью меток SID.

IP-адрес и SID (без inherit-label-nexthops конфигурации)

Например:

segment-list path-3 {
    hop1 {
        label 801006;
        ip-address 172.24.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

По умолчанию список сегментов разрешен с использованием IP-адреса.

IP-адрес и SID (с inherit-label-nexthops конфигурацией)

Например:

segment-list path-3 {
    inherit-label-nexthops;
    hop1 {
        label 801006;
        ip-address 172.24.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

Список сегментов разрешен с помощью меток SID.

Эту команду можно использовать для просмотра нецветных сегментов маршрутов LPS, спроектированных трафиком, с несколькими списками сегментов, установленными в таблице маршрутов show route ip-address protocol spring-te active-path table inet.3 inet.3.

Например:

Прим.:

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

  • Различные списки сегментов туннеля имеют различные типы разрешения первого перехода. Это применимо как к цветным, так и к нецветным статическим сегментам маршрутов LPS. Однако это не относится к LPS, управляемым PCEP; сообщение системного журнала генерируется из-за несоответствия в типе разрешения первого перехода во время вычисления пути.

    Например:

    Сбой сфиксации туннеля lsp1, поскольку путь-1 имеет IP-адресный модем, а путь-2 - режим метки.

  • Привязка SID включена для статического нефрашиваемого LSP, тип списка сегментов которого — SID label.

    Например:

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

И обеспечение LSP статической сегментной маршрутиации

Сегментная икание выполняется на уровне каждого маршрутизатора. Для данного сегмента маршрутизатора выделяется уникальная метка идентификатора службы (SID) из пула меток, который может быть из пула динамической метки для метки идентификатора смежности или из глобального блока маршрутов сегмента (SRGB) для идентификатора префикса или узла SID. Метка SID смежности может быть динамически распределена (стандартное поведение) или выделена из локального статического пула меток (SRLB). Затем в таблице mpls.0 устанавливается маршрут для метки SID.

Junos OS позволяет LSP маршрутов статического сегмента путем настройки утверждения segment на [edit protocols mpls static-label-switched-path static-label-switched-path] уровне иерархии. Статический сегмент LSP идентифицирован уникальной меткой SID, подпадаемой под Junos OS статического пула меток. Можно настроить пул статических Junos OS меток, настроив утверждение static-label-range static-label-range на [edit protocols mpls label-range] уровне иерархии.

Ограничения LSP статической сегментной маршрутации

  • Junos OS имеет ограничение, что следующий переход не может быть создан для того, чтобы выталкить больше, чем максимальное число меток глубины списка сегментов. Таким образом, список сегментов с более чем максимальными sid-метами (за исключением метки SID первого перехода, который используется для разрешения переадментации следующего перехода) не используется для цветных или нефрашиваемых сегментов маршрутов LPS. Кроме того, фактическое число, разрешенное для данного сегментного маршрутного LSP, может быть даже меньше максимального предела, если услуга MPLS на LSP сегмента маршрутов, или LSP сегментной маршрутки на пути защиты соединения или узла. Во всех случаях общее количество меток служб, меток SID и меток защиты соединений или узлов не должно превышать максимальную глубину списка сегментов. Можно настроить максимальный предел списка сегментов на [edit protocols source-packet-routing] уровне иерархии. Несколько нецветных сегментов маршрутов LSP с меньшим или равным максимальному метке SID могут быть сшежны для построения LSP более длинных сегментных маршрутов. Это называется "сшивание LSP сегментной маршрутии". Это можно сделать с помощью метки binding-SID.

  • Сшивание LSP сегментной маршрутки фактически выполняется на уровне пути. Если в LSP маршрутов нецветных сегментов содержится несколько путей с множественными списками сегментов, каждый путь может быть независимо сшивается в другой нецветный сегментный маршрутинг LSP в точке сшивание. Нефресная сегментная маршрутная маршрутация LSP, предназначенная для сшивание, может отключить установку веского маршрута с помощью настройки на no-ingress[edit protocols source-packet-routing source-routing-path lsp-name] уровне иерархии.

  • Не более 12 8 основных путей и 1 вторичный путь поддерживаются для нецветных статических сегментов маршрутов LSP. При нарушении конфигурации проверка с ошибкой не удается проверить.

  • Максимальный размер привязки сегмент-списка к туннелю LSP увеличивается с 8 до 128 с максимальным числом туннелей 1000 на систему. Не более 128 основных путей поддерживаются для каждого статического сегмента маршрутизации LSP. В качестве ограничения максимальный предел поддерживаемой датчиком пути LSP составляет только 32000.

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

Динамическое создание LPS сегментной маршрутации

В сетях сегментной маршрутации, в которых каждое устройство-поставщик edge (PE) подключено к каждому другому устройству PE, для настройки маршрутов сегментной маршрутной маршруты с коммутаными метоками (LSP) требуется большой объем конфигурации, хотя можно использовать только несколько путей сегментной маршрутной маршрутки, спроектированных (SR-управление трафиком) путей. Можно включить BGP динамическое создание этих LSP в несколько раз, чтобы уменьшить количество конфигураций в таких развертываниях.

Настройка шаблона LSP динамической сегментной маршрутки

Чтобы настроить шаблон для включения динамического создания LSP маршрутов сегмента, необходимо включить в иерархию утверждение spring-te.[edit routing-options dynamic-tunnels]

  • Ниже приводится пример конфигурации для шаблона LSP маршрутов динамического цветового сегмента:

  • Ниже приводится пример конфигурации для шаблона LSP не цветной динамической сегментной маршрутации:

Разрешение проблем динамической сегментной маршрутации LPS
Разрешение проблемы цветной динамической сегментной маршрутации LSP

Когда префиксы BGP с сообществом цветов, они изначально решаются через политику catch-all route for-that (политика конкретного цвета) и, в свою очередь, SR-управление трафиком, в котором BGP префикс, на который должен быть разрешен префикс BGP. Sid назначения затем выводится из BGP префикса полезной нагрузки в следующем переходе. Например, если следующим переходом префикса полезной нагрузки BGP IP-адреса устройства A, то принято решение node-SID устройства A, и соответствующая метка подготовлена и загружена вниз стека. Префикс полезной нагрузки BGP разрешен в режиме только цветной маркировки, где узел-SID устройства A находится внизу стека конечных меток, а метки путей SR-управление трафиком находятся вверху.

Окончательные имя шаблона LSP – это комбинация префикса, цвета и имени туннеля; например, <prefix>:<color>:dt-srte-<tunnel-name> Цвет имени LSP отображается в hexademal формате, а формат имени туннеля аналогичен именам LSP, инициированным RSVP.

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

Разрешение проблем бесхрометных динамических сегментов маршрутов LPS

В таблицу маршрутов inet.3 добавляются маршруты catch-all для нецветных LPS. Нецветный туннельный пункт назначения должен быть настроен в другой конфигурации и иметь только одно имя шаблона spring-te в списке сопоставления. Это имя шаблона используется для всех туннельных маршрутов, совпадающих с любой из сетей назначения, настроенных в одной spring-te конфигурации. Эти туннели по функциональности схожи с туннелями RSVP.

Окончательные имя шаблона LSP – это комбинация префикса и имени туннеля; например, <prefix>:dt-srte-<tunnel-name>

Пример конфигурации LSP динамической сегментной маршрутации

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

Цветные динамические сегменты маршрутов LPS

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

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

  1. inetcolor.0 tunnel route: 22.33.44.0-0/24 -> RT_NH_TUNNEL

  2. inetcolor6.0 tunnel route: ffff:22.33.44.0-0/120 -> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1 (префикс) - > 22.33.44.55-101 (PNH) Имя туннеля LSP = 22.33.44.55:65:dt-srte-tunnel1

    R1 (префикс) - > ffff:22.33.44.55-101 (PNH) Имя туннеля LSP = 22.33.44.55:65:dt-srte-tunnel1

    R1 (префикс) - > ffff:22.33.44.55-124 (PNH) Имя туннеля LSP = 22.33.44.55:7c:dt-srte-tunnel1

  4. inetcolor.0 tunnel route:

    22.33.44.55-101/64 - ><next-hop>

    22.33.44.55-124/64 -><next-hop>

  5. inetcolor6.0 tunnel route:

    ffff:22.33.44.55-101/160 -><next-hop>

    ffff:22.33.44.55-124/160 -><next-hop>

Бесцветные динамические сегменты маршрутов LPS

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

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

  1. inet.3 tunnel route: 22.33.44.0/24 -> RT_NH_TUNNEL

  2. inet6.3 tunnel route: ffff:22.33.44.0/120 -> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1 (префикс) -> 22.33.44.55 (PNH) Имя шаблона LSP = LSP1 --- 22.33.44.55:dt-srte-tunnel2

    R1 (префикс) -> ffff:22.33.44.55 (PNH) Имя шаблона LSP = LSP1 --- 22.33.44.55:dt-srte-tunnel2

  4. inet.3 tunnel route: 22.33.44.55/32 ><next-hop>

  5. inet6.3 tunnel route: ffff:22.33.44.55/128 -><next-hop>

Unresolved Dynamic Segment Routing LSP

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

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

  1. inetcolor.0 tunnel route: 22.33.44.0 - 0/24 - > RT_NH_TUNNEL 1.1.1.0 - 0/24 - > RT_NH_TUNNEL

  2. inetcolor6.0 tunnel route: ffff:22.33.44.0 - 0/120 - > RT_NH_TUNNEL ffff:1.1.1.0 - 0/24 -> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: Туннель R1 (префикс) -> 22.33.44.55-124 (PNH) Туннель не создается. (Шаблон для этого цвета не найден).

Соображения по настройке динамического создания LSP сегментной маршрутки

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

  • Шаблон может быть назначен цветным объектом. Когда динамическая конфигурация туннеля включает в себя шаблон с цветным объектом, необходимо также настроить все другие шаблоны spring-te с цветными предметами. Предполагается, что в данная конфигурация все пункты назначения имеют цветной цвет.

  • Шаблон может иметь список цветов, определенных на нем, или может быть настроен с помощью color-any параметра. Оба этих варианта могут сосуществовать в одной spring-te конфигурации. В таких случаях шаблоны, присвоенные определенными цветами, имеют более высокое предпочтение.

  • В spring-te конфигурации только один шаблон может быть определен с помощью color-any параметра.

  • Сопоставление «цвет-шаблон» создается индивидуально. Один цвет не может быть привяжным к нескольким шаблонам.

  • Имя шаблона должно быть сконфигурировано в иерархии с spring-te[edit protocols] включенной primary опцией.

  • Цветные и нецветные пункты назначения не могут сосуществовать в одной spring-te конфигурации.

  • Нельзя настроить одинаковые сети назначения, с цветом или без них, в соответствии с различными spring-te настройками.

  • В нецветной конфигурации можно настроить только один шаблон spring-te без цветного объекта.

Службы, поддерживаемые динамическими сегментами маршрутов LPS

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

  • VPN уровня 3

  • BGP EVPN

  • Службы политики экспорта

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

  • VPN уровня 3

  • VPN на уровне 2

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

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

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

Ограничения LSP динамической сегментной маршрутации

Динамические SR-управление трафиком LPS не поддерживают следующие функции и функции:

  • Туннели сегментной маршрутки IPv6.

  • Статические туннели.

  • 6PE не поддерживается.

  • Распределенная CSPF.

  • Туннелирование sBFD и LDP не поддерживается для динамических SR-управление трафиком LPS и в шаблоне.

  • Установите и B-SID маршруты в шаблоне.

Цветовая сопоставление служб VPN

Можно указать цвет в качестве ограничения следующего перехода протокола (в дополнение к адресу IPv4 или IPv6) для разрешения транспортных туннелей со статическими цветными и BGP сегментными маршрутами трафика, спроектированными (SRTE) LPS. Это называется цветно-IP-протоколом разрешения следующего перехода, где необходимо настроить карту разрешения и применить к службам VPN. С помощью этой функции можно включить управление цветом трафика служб VPN 2-го и 3-го уровней.

Junos OS поддерживают цветовые SRTE LSP, связанные с одним цветом. Цветовая карта служб VPN поддерживается на статических цветных LSP и BGP SRTE.

Цветовая цветовая раскраска для службы VPN

В общем, службе VPN может быть назначен цвет на том маршрутизатор исходящего трафика, где объявляется VPN NLRI, или на в агрессивном маршрутизаторе, на котором получается и обрабатывается VPN NLRI.

Службе VPN можно назначить цвет на разных уровнях:

  • Для каждого экземпляра маршрутов.

  • Для BGP группы.

  • Соседний BGP.

  • Для каждого префикса.

После назначения цвет присваивается службе VPN в форме BGP цветом расширенного сообщества.

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

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

  • BGP экспортную политику на устройстве-выпадающее устройство.

  • BGP импорт на впадающее устройство.

  • Политика импорта VRF на в агрессивном устройстве.

Два режима цветовой цветовой разности службы VPN:

Назначение цветного перепада

В этом режиме устройство для выпадания (например, рекламодатель VPN NLRI) отвечает за цветную цветную цветовую цветовую погрешности службы VPN. Чтобы включить этот режим, можно определить политику маршрутов и применить ее к экземпляру маршрутов службы VPN, экспорту группы или соседу группы на уровне vrf-export[edit protocols bgp] иерархии. VPN NLRI объявляется BGP с указанным цветом расширенным сообществом.

Например:

Или

Прим.:

При применении политики маршрутов в качестве политики экспорта группы BGP или BGP соседа, необходимо включить утверждение на BGP, BGP группы или BGP соседа, чтобы политика влияла на vpn-apply-export VPN NLRI.

Политики маршрутов применяются к NLRis NLRX 3-го уровня VPN, NRLIS VPN уровня 2 и EVPN NLRIs. Сообщество расширенного цвета наследуется всеми маршрутами VPN, импортируемыми и установленными в целевых VRF на одном или нескольких впаданных устройствах.

Назначение цветового назначения впаданий

В этом режиме въехающее устройство (то есть приемник VPN NLRI) отвечает за цветную цветовую цветовую поддержку VPN-службы. Чтобы включить этот режим, можно определить политику маршрутов и применить ее к экземпляру маршрутов службы VPN, импорту группы или соседу группы на уровне vrf-import[edit protocols bgp] иерархии. Все маршруты VPN, совпадающие с политикой маршрутов, присоединены к указанному цвету расширенного сообщества.

Например:

Или

Указание режима сопоставления службы VPN

Чтобы указать гибкие режимы отображения служб VPN, необходимо определить политику с помощью утверждения и обратиться к политике в экземпляре маршрутов службы VPN, импорте группы или импорте соседа группы на уровне resolution-mapvrf-import[edit protocols bgp] иерархии. Все маршруты VPN, совпадающие с политикой маршрутов, подключены к указанной карте разрешения.

Например:

Можно применить политику импорта к экземпляру маршрутов службы VPN.

Можно также применить политику импорта к группе BGP или BGP соседу.

Прим.:

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

Разрешение следующего перехода в протоколе Color-IP Protocol

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

Необходимо настроить политику для поддержки многопутевого разрешения цветных VPN 2-го уровня, VPN уровня 3 или EVPN с помощью цветных LSP. Затем следует применить политику с соответствующей таблицей RIB в качестве политики импорта разреша вопросы.

Например:

Переход на следующий переход протокола IP

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

Это простой процесс от цветных SRTE LSP к LSPs LDP, с помощью RIB-группа LDP для установки маршрутов в таблицы маршрутизации inet{6}сети.0. Совпадение с самым длинным префиксом для цветного IP-протокола следующего перехода гарантирует, что если цветной маршрут SRTE LSP не существует, должен быть возвращен маршрут LDP с совпадающий IP-адрес.

BGP одноандной цветовой маркировки на основе меток в SR-управление трафиком

Начиная с Junos OS выпуска 20.2R1, BGP однонастная трансляция (BGP-LU) может разрешить маршруты IPv4 или IPv6 через сегментную маршруту – управление трафиком (SR-управление трафиком) для семейства адресов IPv4 и IPv6. BGP LU поддерживает сопоставление BGP сообщества и определение resolution map SR-управление трафиком. Построить цветной протокол следующего перехода, и он будет разрешен в цветном SR-управление трафиком туннеле в inetcolor.0 или inet6color.0 таблице. BGP для сопоставления на основе цветов и inet.3inet6.3 таблиц. Это позволяет объявлять префиксы IPv6 BGP LU IPv6 и IPv4 с адресом следующего перехода IPv6 в сетях только IPv6, в которых маршрутизаторы не имеют настроенных адресов IPv4. С помощью этой функции в настоящее время BGP lu IPv6 по SR-управление трафиком с IS-IS подуровной.

В Рис. 9 , контроллер настраивает 4 цветных туннеля в сети ядра IPv6, настроенной с SR-управление трафиком. Каждый цветной туннель проходит различные пути к маршрутизатору назначения D в зависимости от определенной карты разрешения. Контроллер настраивает цветной туннель SR-управление трафиком на abcd:3701:2d05 interface в маршрутизаторе D. BGP импорта политик для назначения карты цвета и разрешения полученному префиксу abcd::3700:6/128. В зависимости от назначенного цвета сообщества, BGP-BGP LU устраняет цвет цветной следующий переход для префикса LU IPv6 в соответствии с назначенной политикой карты разрешения.

Рис. 9: BGP LU IPv6 по цветной IPv6 SR-управление трафикомBGP LU IPv6 по цветной IPv6 SR-управление трафиком

BGP-LU поддерживает следующие сценарии:

  • BGP IPv4 LU на BGP IPv4 SR-управление трафиком, с расширениями ISIS/OSPF IPv4 SR.

  • BGP lu IPv4 по статическому и нефическому IPv4 SR-управление трафиком, с расширениями ISIS/OSPF IPv4 SR.

  • BGP LU IPv6 с BGP IPv6 SR-управление трафиком с расширениями ISIS IPv6 SR.

  • BGP lu IPv6 по статическому и нефическому IPv6 SR-управление трафиком, с расширениями ISIS IPv6 SR.

  • Службы VPN IPv6 уровня 3 с локальным адресом IPv6 и адресом соседа IPv6.

  • Vpn-сервисы IPv6 уровня 3 по BGP IPv6 SR-управление трафиком с расширениями ISIS IPv6 SR.

  • Услуги VPN IPv6 уровня 3 по статическому и нефическому IPv6 SR-управление трафиком с расширениями ISIS IPv6 SR.

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

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

  • BGP VPN 2-го уровня (VPN 2-го уровня, Kompella)

  • BGP EVPN

  • Разрешение-карта с одним IP-цветом.

  • Разрешение следующего перехода для цветного протокола IPv4 и IPv6.

  • База сведений о маршруте (также известная как таблица маршрутов) группа, базирующаяся на перепаде LSP LDP в таблице маршрутов inetголевеку.0.

  • Цветной SRTE LSP.

  • Виртуальные платформы.

  • 64-битная Junos OS.

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

  • BGP одноавтосеку.

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

  • Цветные MPLS LSP, такие как RSVP, LDP, BGP-LU, статические.

  • канал уровня 2

  • FEC-129 BGP автооткрытки и LDP-сигналы VPN уровня 2.

  • Vpls

  • MVPN

  • IPv4 и IPv6 используют карту разрешения.

Шаблоны туннеля для LPS, инициированных PCE-сегментом маршрутов

Можно настроить шаблон туннеля для LSP, инициируемых PCE сегментной маршрутирой, чтобы передать два дополнительных параметра для этих LSP — двунаправленное обнаружение перенаправления (BFD) и туннелировать LDP.

Когда LSP, инициируемый PCE-сегментом, создается LSP, LSP проверяется по политикам (если таковых имеется), и при совпадении политика применяет настроенный шаблон для этого LSP. Конфигурация шаблона наследуется, только если она не предоставлена источником LSP (PCEP); например, метрика.

Для настройки шаблона:

  1. Включит в него утверждение source-routing-path-template на [edit protocols source-packet-routing] уровне иерархии. Здесь можно настроить дополнительные параметры туннелирований BFD и LDP.

  2. Включите на уровне иерархии утверждение source-routing-path-template-map для списка политик, в отношении которых следует проверить LSP, инициированный [edit protocols source-packet-routing] PCE.

  3. Определите политику для списка LPS, к которым должен применяться шаблон.

    Утверждение может включать либо имя LSP, либо регулярное выражение from LSP с использованием lsp условий lsp-regex совпадения и совпадения. Эти параметры являются взаимоисключающими, поэтому в заданный момент времени можно указать только один параметр.

    Утверждение then должно включать параметр с sr-te-template действием принятия. Этот шаблон применяется к LSP, инициировал PCE.

При настройке шаблона для LSP, инициированных PCE, учитывайте следующее:

  • Конфигурация шаблона не применяется к LSP статической, настроенной сегментной маршрутизаации, или LSP любой другой клиентской сегментной маршрутки.

  • Конфигурация, предоставленная PCEP, имеет приоритет по сравнению с конфигурацией шаблона.

  • LSP PCEP не наследует конфигурацию сегмента-списка шаблонов.

Примере: Настройка коммутируемых меток маршрутов статического сегмента маршрутов

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

Требования

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

  • Семь серия MX универсальных платформ маршрутов 5G

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

Перед началом работы убедитесь, что интерфейсы устройств настроены.

Обзор

Junos OS набор явных маршрутных путей сегмента настраивается на в агрессивном маршрутизаторе не-статического туннеля статического сегмента с помощью настройки утверждения на уровне segment-list [edit protocols source-packet-routing] иерархии. Можно настроить туннель сегментной маршрутации, настроив утверждение source-routing-path на [edit protocols source-packet-routing] уровне иерархии. Туннель сегментной маршрутации имеет адрес назначения, один или несколько основных путей, а также дополнительные пути, которые относятся к списку сегментов. Каждый список сегментов состоит из последовательности переходов. Для нецветного статического туннеля маршрутов первый переход в списке сегментов определяет IP-адрес следующего перехода, а второй – метки SID, соответствующие каналу или узлу, через который проходит путь. Маршрут к месту назначения туннеля сегментной маршрутации установлен в таблице inet.3.

Топологии

В данном примере настройте VPN уровня 3 на маршрутизаторах edge поставщика услуг PE1 и PE5. Настройте MPLS на всех маршрутизаторах. Туннель сегментной маршрутации настраивается от маршрутизатора PE1 к маршрутизатору PE5 с первичным путем, настроенным на маршрутизаторе PE1 и маршрутизаторе PE5. Маршрутизатор PE1 также настроен со вторичным путем для защиты пути. Транзитные маршрутизаторы PE2 к PE4 сконфигурированы с метами SID со схождения с меткой pop и выходным интерфейсом.

Рис. 10: Путь коммутации меток статического сегментаПуть коммутации меток статического сегмента

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

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

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Настройка устройства PE1
Пошаговая процедура

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

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

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

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

  3. Настройте интерфейсы с помощью MPLS и настройте диапазон MPLS меток.

  4. Настройте тип группы равноправных узла, локальный адрес, семейство протоколов для NLRIs в обновлениях и IP-адрес соседа для группы равноправных групп.

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

  6. Настройте адрес IPv4 и метки основных и вторичных путей для политик маршрутной маршрутки-управление трафиком (управление трафиком) политик маршрутов пакетов источника протокола (SPRING).

  7. Настройте адрес назначения IPv4, связывание метки SID, основного и дополнительного источника маршрутов для протокола SPRING.

  8. Настройте параметры политики.

  9. Настройте BGP сообщества.

  10. Настройте экземпляр маршрутки VRF1 с типом экземпляра, интерфейсом, отличительным устройством маршрутизатора, импортом VRF, экспортом и меткой таблицы. Настройте экспортную политику и интерфейс области для протокольных OSPF.

Результаты

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

Настройка устройства PE2
Пошаговая процедура

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

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

  2. Настройте статический LSP для протокола MPLS.

  3. Настройте интерфейсы и диапазон статических меток для протоколов MPLS.

  4. Настройте интерфейсы для протоколов OSPF.

Результаты

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

Проверки

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

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

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

Действий

В рабочем режиме введите show route table inet.3 команду.

Смысл

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

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

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

Действий

В рабочем режиме введите show route table mpls.0 команду.

Смысл

В выходных данных отображаются SID-метки туннелей маршрутов сегмента.

Проверка трафика SPRING, спроектированного LSP маршрутизатора PE1
Цель

Проверьте трафик SPRING, спроектированный LSP на впадаемом маршрутизаторе.

Действий

В рабочем режиме введите show spring-traffic-engineering overview команду.

Смысл

Выходные данные показывают обзор spring-трафика, спроектированных LPS на впадаемом маршрутизаторе.

Проверка трафика SPRING, сконструженного на впадаемом маршрутизаторе PE1
Цель

Проверьте трафик SPRING, спроектированный LSP на впадаемом маршрутизаторе.

Действий

В рабочем режиме введите show spring-traffic-engineering lsp detail команду.

Смысл

Выходные данные отображают подробную информацию о spring-трафике, спроектированных LPS на впадаемом маршрутизаторе

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

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

Действий

В рабочем режиме введите show route table mpls.0 команду.

Проверка состояния статических MPLS LSP маршрутизатора PE2
Цель

Проверьте состояние MPLS LSP сегментов маршрутизатора PE2.

Действий

В рабочем режиме введите show mpls static-lsp команду.

Смысл

Выходные данные показывают состояние статических MPLS LSP маршрутизатора PE2.

Включение распределенного CSPF для LSP сегментной маршрутации

До Junos OS выпуска 19.2R1S1 для управление трафиком путей сегментной маршрутации можно было либо явно настроить статические пути, либо использовать расчетные пути от внешнего контроллера. С помощью распределенного первого ограниченного пути (CSPF) для функции LSP маршрутизации сегмента, можно вычислить LSP сегмента локально на влиятельном устройстве в соответствии с настроенными ограничениями. С помощью этой функции LPS оптимизированы на основе настроенных ограничений и типа метрики (проектирование трафика или IGP). LSP вычисляются для использования доступных путей ECMP к месту назначения с включенным или отключенным сжатием меток сегментной маршрутации.

Распределенные ограничения вычислений CSPF

Пути LSP сегментной маршрутки вычисляются при совме-лени всех сконфигурируемых ограничений.

Функция распределенной вычисления CSPF поддерживает следующее подмножество ограничений, заданных в проекте Интернет, проект ietf-spring-сегмент-маршрутизация-политика-03.txt, политика сегментной маршрутизации для управления трафиком:

  • Включение и исключение административных групп.

  • Включение IP-адресов свободного или строгого перехода.

    Прим.:

    Можно указать только ID маршрутизаторов в ограничениях свободного или строгого перехода. В версии Junos OS-S1 метки и другие IP-адреса не могут быть заданы как ограничения свободного Junos OS перехода 19.2R1-S1.

  • Максимальное число сегментных ID (SID) в списке сегментов.

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

Функция распределенной вычисления CSPF для LPS сегментной маршрутизации не поддерживает следующие типы ограничений и сценарии развертывания:

  • Адреса IPV6.

  • Маршруты между сегментами доменов управление трафиком (SRTE) LPS.

  • Ненумберные интерфейсы.

  • Одновременно включены несколько протоколов маршрутов, OSPF, ISIS и BGP-LS.

  • Вычисление с префиксами или любыми адресами в качестве адреса назначения.

  • Включая и за исключением IP-адресов интерфейса в качестве ограничений.

Распределенный алгоритм вычисления CSPF

Функция распределенной вычисления CSPF для LSPs сегментной маршрутизации использует алгоритм сжатия стека меток с CSPF.

Сжатие стека меток включено

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

Отключено сжатие стека меток

Многоканальная вычисление CSPF с отключенным сжатием стека меток обнаруживает до списков сегментов N к месту назначения, где:

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

  • Каждый список сегментов включает в себя siD для работы с сотнями.

  • Значение N – это максимальное число списков сегментов, разрешенных для пути кандидатов в конфигурации.

  • Два списка сегментов не идентичны.

  • Каждый список сегментов удовлетворяет всем настроенным ограничениям.

Распределенная база данных вычислений CSPF

База данных, используемая для вычисления SRTE, содержит все ссылки, узлы, префиксы и их характеристики независимо от того, включено ли в этих рекламных узлах технологии трафика. Другими словами, это объединение базы данных управления трафиком (TED) и базы данных о состоянии IGP соединений всех доменов, которые были научились вычислительным узлом.

Настройка ограничений распределенных вычислений CSPF

Для логической группировки ограничений вычислений можно использовать вычислительный профиль. Эти вычислительные профили ссылаются на пути сегментной маршрутации для расчета первичных и вторичных сегментов маршрутов LSP.

Чтобы настроить профиль вычислений, включим в себя утверждение compute-profile на [edit protocols source-packet-routing] уровне иерархии.

Конфигурация для поддерживаемых ограничений вычислений:

  • Administrative groups

    Можно настроить группы администраторов на уровне [edit protocols mpls] иерархии. Junos OS применяет конфигурацию административной группы к интерфейсам сегментной маршрутной маршрутации (SRTE) интерфейсам.

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

    • include-any-Указывает, что любая связь, хотя бы одна из настроенных административных групп в списке, является приемлемой для прохождения пути.

    • include-all-Указывает, что любая связь со всеми настроенными административными группами в списке является приемлемой для прохождения пути.

    • exclude-Указывает, что любой ссылки, в списке которых нет настроенных административных групп, является допустимым для прохождения пути.

  • Explicit path

    Можно указать серию ID маршрутизаторов в профиле вычислений как ограничение для вычисления путей-кандидатов SRTE. Каждый переход должен быть адресом IPv4 и может быть строгого или свободного типа. Если тип перехода не настроен, используется strict. Необходимо включить этот compute параметр в утверждение "segment-list" при указании явный путь ограничения.

  • Maximum number of segment lists (ECMP paths)

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

    Этот атрибут можно настроить с помощью параметра maximum-computed-segment-lists maximum-computed-segment-lists под утверждением конфигурации compute-profile. Эта конфигурация определяет максимальное число таких списков сегментов, вычисляется для данного основного и вторичного LSP.

  • Maximum segment list depth

    Параметр максимального вычисления глубины списка сегментов гарантирует, что среди путей ECMP, удовлетворяющих всем другим ограничениям, например административной группе, используются только пути, у которых списки сегментов меньше или равны максимальной глубине списка сегментов. Если этот параметр сконфигурирован как ограничение для вычислительного профиля, он переопределит конфигурацию на уровне maximum-segment-list-depth[edit protocols source-packet-routing] иерархии, если она имеется.

    Этот атрибут можно настроить с помощью параметра maximum-segment-list-depth maximum-segment-list-depth под утверждением конфигурации compute-profile.

  • Protected or unprotected adjacency SIDs

    Можно настроить защищенный или незащищенный SID для своего четного соединения как ограничение для профиля вычисления, чтобы избежать ссылок с указанным типом SID. compute-profile

  • Metric type

    Можно указать тип метрики на соединении, который будет использоваться для вычисления. По умолчанию SR-управление трафиком LPS используют для вычисления трафик-технические метрики линий связи. Метрика управления трафиком для линий связи объявляется расширениями протокола IGP трафика. Однако можно также использовать метрику IGP для вычисления, используя конфигурацию типа метрики в профиле вычислений.

    Этот атрибут можно настроить с помощью параметра metric-type (igp | te) под утверждением конфигурации compute-profile.

Распределенная вычисление CSPF

Пути кандидатов на SRTE вычисляются локально, чтобы удовлетворить настроенные ограничения. Если сжатие стека меток отключено, то результатом многоканального вычисления CSPF является набор стеков SID для удлинения. Если включено сжатие стека меток, то результатом является набор стеков сжатой метки (составленный из смежных SID и SID узла).

Когда вычисляются вторичные пути, соединения, узлы и SRLG, которые принимаются по основным путям, не избегаются вычисления. Дополнительные сведения о первичных и вторичных путях см. в настройках первичных и вторичных LSP.

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

Взаимодействие между распределенной вычислением CSPF и функциями SRTE

Вес, связанный с путями политики SRTE

Весовые веса можно настраивать по расчетным и статическим путям SRTE, что внося свой вклад в последующие переходы маршрута. Однако один путь с включенным вычислением может привести к списку сегментов. Эти расчетные списки сегментов сами по себе рассматриваются как ECMP. Можно назначить иерархическую весовую часть ECMP этим сегментам с учетом весов, присвоенных каждому из настроенных сегментов.

Обнаружение BFD в прямом эфире

Можно настроить обнаружение BFD прямого эфира для расчетных основных или вторичных маршрутов. Каждый вычисляемый основной или вторичный путь может привести к образованию нескольких списков сегментов. В результате параметры BFD, настроенные по этим спискам, применяются во всех расчетных списках сегментов. Если все активные первичные пути от становятся неабитыми, то заранее запрограммированный вторичный путь (при условии) становится активным.

inherit-label-nexthops

Не требуется явно включить конфигурацию в иерархии для расчетных первичных или вторичных путей, так как это поведение inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name] по умолчанию.

Функция автоматического перевода

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

Примеры распределенных вычислений CSPF

Пример 1

В примере 1

  • Несчисленный основной путь ссылается на настроенный список сегментов. В данном примере выполняется ссылка на настроенный список static_sl1 сегментов, который также служит именем для этого основного пути.

  • В расчетном первичном устройстве должно быть настроено имя, которое не должно ссылаться ни на какой настроенный список сегментов. В данном примере compute_segment1 сегментов не настроен.

  • Вычислительный compute_profile_red-профиль применяется к основному пути с именем compute_segment1.

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

Весовые веса для расчетного пути следующих и статических следующих переходов – 2 и 3 соответственно. Предполагая, что для расчетных путей comp_nh1,comp_nh2и comp_nh3,а следующий переход для статического пути – static_nh,вес применяется следующим образом:

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

Масса

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Пример 2

В примере 2 первичный и вторичный пути могут иметь расчетный тип и иметь собственные расчетные профили.

Пример 3

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

Примере: Настройка переад CoS маршрутов на основе политик и маршрутов на основе политик для LSP управление трафиком SR-управление трафиком.

SUMMARY CoS маршруты (CBF) и маршруты на основе политик (PBR, также известные как перенаправляющие потоки на основе фильтра) могут быть включены для нецветных сегментных маршрутиз-трафика, спроектированных (SR-управление трафиком) LPS для управления выборочным трафиком через явный путь SR-управление трафиком, предоставляя вам преимущество обслуживания трафика на основе класса обслуживания или политики.

CoS LPS на основе переадреатики и маршрутов на основе политик для SR-управление трафиком LPS

Преимущества маршрутов CoS(CBF) и маршрутов на основе политик (PBR) для LPS управление трафиком SR

С помощью CBF и PBR можно:

  • Используйте комбинации путей сегментной маршрутной управление трафиком (SR-управление трафиком) для управления сервисным трафиком в ядре.

  • Выберите службы поддержки для разрешения проблемы по выбранным путям SR-управление трафиком.

Источники пути сегментной маршрутации, поддерживающие CBF и PBR

Следующие источники пути сегментной маршрутации поддерживают CoS маршруты на основе CoS и маршрутов на основе политик:

  • Static SR–TE paths— Статически настроенные пути маршрутов-источников, в которые статически настроен весь стек меток.

  • PCEP— Динамическая истечении исходных маршрутных путей, созданных на контроллере и загружаемых на вющий маршрутизатор в ALLY либо через расширения сегмента PCEP, либо в BGP сегментной политике маршрутации через расширения маршрутов сегмента BGP сегментов.

  • Dynamic LSPs— Туннели, созданные динамически, запускаются с помощью модуля динамического туннеля с разрешением ALLY на последнем переходе.

  • Auto-translated paths— Статически настроенные пути маршрутов-источников, которые автоматически преобразуются.

Соображения по настройке CBF и PBR для SR-управление трафиком LPS

Помните:

  • CBF и PBR включены только на нефрашиваемых SR-управление трафиком LPS, настроенных статически или динамически.

  • Конфигурации CBF и PBR для SR-управление трафиком LSP могут сосуществовать на устройстве; порядок конфигурации определяет тип переадрешаемой маршрутов.

  • Для PBR, если первым переходом SR-управление трафиком LSP является метка, следует включить утверждение на resolution preserve-nexthop-hiearchy[edit routing-options] уровне иерархии.

  • Переадребовка маршрутов на основе классов для CBF видна только в таблица переадресации а не на маршрутах.

  • Перенаводка маршрутов для PBR на основе политик происходит на маршрутах и видна в show route выходных данных команды.

Настройка переад CoS маршрутов на основе политик для LSP на управление трафиком SR

SUMMARY CoS маршруты (CBF) и маршруты на основе политик (PBR, также известные как фильтровая переадреация FBF) могут использоваться для управления выборочным трафиком с использованием явного сегментного трафика, разработанного (SR-управление трафиком) пути с маркировкой (LSP). Только нецветные сегменты маршрутизируемые LPS, которые имеют следующий переход настроен как метка первого перехода или IP-адрес поддерживают CBF и PBR.

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

  • Необходимо использовать Junos OS версии 20.1 и более поздних версий, чтобы включить CBF и PBR для нецветных SR-управление трафиком LPS.

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

  • Определите списки сегментов и настройте SR-управление трафиком LPS и связанные с ними параметры.

Чтобы настроить SR-управление трафиком LSP, сделайте следующее:

  1. Определите список сегментов с параметрами метки.

    Например:

  2. Настройте маршрутизируемый путь источника для SR-управление трафиком LPS и укажите для пути значение предпочтения и основной сегмент.

    Например:

Теперь можно настроить CBF и PBR для настроенных SR-управление трафиком LPS.

Чтобы настроить CBF, сделайте следующее:

  1. Определите классификаторы кодов дифференцированного обслуживания (DSCP) для обработки входящих пакетов IPv4, классов переадречения и значений опций.

    Например:

  2. Определите классы переадстройки (FCs) для группивки пакетов для передачи и призначьте пакеты выходным очередям.

    Например:

  3. Назначьте настроенные классификаторы интерфейсам устройств.

    Например:

  4. Определите CoS на основе политик переадрежки, при этом LSP следующий переход будет управление трафиком LSP.

    Например:

  5. Отбрасывание трафика, не отвечающего классу переад откуда-либо в следующей карте перехода.

    Например:

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

    Например:

  7. Примените политику к маршрутам, экспортным из таблицы маршрутов, в таблица переадресации. Это включает CBF для SR-управление трафиком LPS.

    Например:

  8. Сфиксировать конфигурацию.

Verify CBF Configuration

Конфигурацию CBF можно проверить с помощью show route forwarding-table destination ip-address vpn vpn-name extensive этой команды.

В CBF маршруты, основанные на классах, видны только в таблица переадресации, в отличие от PBR, где фильтруются маршруты в show route выходных данных команды.

Для настройки PBR необходимо сделать следующее:

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

    Например:

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

    Прим.:

    Утверждение является обязательным для работы PBR, когда первый переход resolution preserve-nexthop-hierarchy SR-управление трафиком LSP является меткой.

  3. Примените политику к маршрутам, экспортным из таблицы маршрутов, в таблица переадресации. Это включает PBR для SR-управление трафиком LPS.

    Например:

  4. Сфиксировать конфигурацию.

Verify PBR Configuration

Можно проверить конфигурацию PBR с помощью show route destination-prefix этой команды.

Выходные данные отображают все следующие переходы для префикса назначения, 4.0.0.1. Параметры expanded-nh extensive отображают отфильтрованные следующие переходы в поле Krt_inh вывода.

Для PBR выходные show route данные команды делает фильтрацию маршрутов на основе политик.

Таблица истории выпусков
Версия
Описание
21.R1
Начиная с Junos OS 21.1R1, Junos OS поддерживают бесконечную активную маршрутную (NSR) для точек-точек на основе RSVP, инициированных PCE.
21.R1
Начиная с Junos OS 21.1R1, Junos OS поддерживает бесконечную активную маршрутную (NSR) для LSP с поддержкой RSVP на основе точек PCE.
20.2R1
Начиная с Junos OS выпуска 20.2R1, BGP однонастная трансляция (BGP-LU) может разрешить маршруты IPv4 или IPv6 через сегментную маршруту – управление трафиком (SR-управление трафиком) для семейства адресов IPv4 и IPv6.
19.4R1
Можно связать один или диапазон многоадретных потоков MVPN (S,G) с динамически созданным путем переключения на многоточки (LSP) точками PCE.
19.4R1
Можно настроить шаблон туннеля для LSP, инициируемых PCE сегментной маршрутирой, чтобы передать два дополнительных параметра для этих LSP — двунаправленное обнаружение перенаправления (BFD) и туннелировать LDP.
19.1R1
Начиная Junos OS выпуске 19.1R1, вводится функция проверки сфикси, гарантирующий, что все списки сегментов, способствующие цветным маршрутам, имеют минимальную метку для всех переходов.
19.1R1
Начиная Junos OS выпуске 19.1R1, данное требование не применяется, так как первый переход нецветных статических LSP теперь поддерживает метки SID помимо IP-адресов. С помощью поддержки метки первого перехода MPLS быстрая перемаршрутизация (FRR) и взвешенный многопутевой многопутевой маршрут для статического нецветного сегмента маршрутов LSP, подобно цветным статическим LSP.
18.2R1
Начиная с Junos OS выпуска 18.2R1, LPS маршрутизации статически настроенных не-цветных сегментов на в выходном устройстве сообщаются элементу вычисления пути (PCE) через сеанс Path Computation Element Protocol (PCEP).
17.2R1
Начиная Junos OS 17.2, для LPS под управлением PCE вводятся два новых типа вычисления external cspf пути: local cspf и no cspf .
16.1
Начиная Junos OS 16.1, можно защитить сеанс PCEP, используя аутентификацию TCP-MD5 в RFC 5440.
16.1
Junos OS версии 16.1 вводится функция обеспечения безопасности сеанса PCEP с использованием аутентификации TCP-MD5 в RFC 5440.
14.2R4
Начиная Junos OS выпуске 14.2R4, поддержка автоматической пропускной способности предоставляется для LPS, управляемых PCE.