Multicast

Введение

Цифровая Подстанция это тренд в энергетике. Если Вы близки к теме, то наверняка слышали, что большой объем данных передается в виде multicast-потоков. Но знаете ли Вы, как этими multicast-потоками управлять? Какие инструменты управления потоками применяются? Что советует нормативная документация?

Всем, кому интересно разобраться в этой теме, welcome под кат!

Как данные передаются в сети и зачем управлять multicast-потоками?

Прежде чем переходить непосредственно к Цифровой Подстанции и нюансам построения ЛВС, предлагаю краткий ликбез по типам передачи данных и протоколам передачи данных для работы с multicast-потоками. Ликбез мы спрятали под спойлер.


Что такое Цифровая Подстанция и зачем там нужен multicast?

Прежде, чем заговорить про ЛВС Цифровой Подстанции, нужно разобраться, что такое Цифровая Подстанция. Потом ответить на вопросы:

• Кто участвует в передаче данных?
• Какие данные передаются в ЛВС?
• Какая типовая архитектура ЛВС?

И уже после этого обсуждать multicast

Что такое Цифровая Подстанция?

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

Соответственно, в цифровом виде здесь передаются все данные:

• Измерения.
• Диагностическая информация.
• Команды управления.

Этот тренд получил очень большое развитие в российской энергетике и сейчас повсеместно внедряется. В 2019 и 2020 году появилось очень много нормативных документов, регулирующих создание Цифровой Подстанции на всех этапах разработки. Например, СТО 34.01-21-004-2019 ПАО Россети определяет следующее определение и критерии ЦПС:

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

Критерии:

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

Кто участвует в передаче данных?

В составе Цифровой Подстанции есть следующие системы:

• Системы релейной защиты. Релейная защита это практически сердце Цифровой Подстанции. Терминалы релейной защиты из систем измерения берут значения тока и напряжения. На основе этих данных терминалы отрабатывают внутреннюю логику защит. Терминалы общаются между собой, чтобы передавать информацию о сработанных защитах, о положениях коммутационных аппаратов и т.д. Также терминалы отправляют информацию о произошедших событиях на сервер АСУ ТП. Итого, можно выделить несколько типов связи:
  Горизонтальная связь общение терминалов между собой.
  Вертикальная связь общение с сервером АСУ ТП.
  Измерения общение с измерительными устройствами.

• Системы коммерческого учета электроэнергии.Системы коммерческого учета общаются только с измерительными устройствами.

• Системы диспетчерского управления.С сервера АСУ ТП и с сервера коммерческого учета данные частично должны отправляться в диспетчерский пункт.

Это очень упрощенный перечень систем, которые обмениваются данными в составе Цифровой Подстанции. Если Вам интересно углубиться в эту тему глубже пишите в комментарии. Расскажем про это отдельно ;-)

Какие данные передаются в ЛВС?

Чтобы объединить описанные системы между собой и организовать горизонтальную и вертикальную связь, а также передачу измерений организуются шины. Пока давайте договоримся, что каждая шина это просто отдельная ЛВС на промышленных Ethernet-коммутаторах.


Структурная схема электроэнергетического объекта в соответствии с МЭК 61850

На структурной схеме изображены шины:

• Мониторинг/Управления.
• Передача сигналов РЗА.
• Передача мгновенных значений напряжений и токов.

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

Через шину Передача сигналов РЗА терминалы передают информацию между собой. Т.е. здесь реализована горизонтальная связь.

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

Также к шине Передача мгновенных значений напряжений и токов подключается сервер АСКУЭ, который также забирает к себе измерения для учета.

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

С сервера АСУ ТП данные отправляются в диспетчерский пункт.

Какая типовая архитектура ЛВС?

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

На схеме ниже изображена достаточно стандартная архитектура ЛВС для Цифровой Подстанции.

Архитектура Цифровой Подстанции

На подстанциях 6 кВ или 35 кВ сеть будет попроще, но если мы говорим про подстанции 110 кВ, 220 кВ и выше, а также про ЛВС электрических станций, то архитектура будет соответствовать изображенной.

Архитектура разбита на три уровня:

• Уровень станции/подстанции.
• Уровень присоединения.
• Уровень процесса.

Уровень станции/подстанции включает в себя АРМы и сервера.

Уровень присоединения включает в себя все технологическое оборудование.

Уровень процесса включает в себя измерительное оборудование.

Также есть две шины для объединения уровней:

• Шина станции/подстанции.
• Шина процесса.

Шина станции/подстанции объединяет в себе функции шины Мониторинг/Управление и шины Передача сигналов РЗА. А шина процесса выполняет функции шины Передача мгновенных значений напряжения и тока.

Особенности передачи Multicast в Цифровой Подстанции

Какие данные передаются с помощью multicast?
Горизонтальная связь и передача измерений в рамках Цифровой Подстанции выполняется с помощью архитектуры Издатель-Подписчик. Т.е. терминалы релейной защиты используют multicast-потоки для обмена сообщениями между собой, а также измерения передаются с помощью multicast.

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

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

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

Поэтому данные должны были передаваться:

• Надежно.
• Гарантированно.
• Быстро.

Теперь вместо связи точка-точка используется шина станции/подстанции, т.е. ЛВС. А данные передаются с помощью протокола GOOSE, который описан стандартом МЭК 61850 (в МЭК 61850-8-1, если быть точнее).

GOOSE расшифровывается как General Object Oriented Substation Event, но эта расшифровка уже не очень актуальна и смысловой нагрузки не несет.

В рамках этого протокола, терминалы релейной защиты обмениваются GOOSE-сообщениями между собой.

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

Измерения, как мы уже обсудили, также передаются с помощью multicast-потоков. В терминологии ЦПС эти потоки называются SV-потоками (Sampled Value).

SV-потоки это сообщения, содержащие определенный набор данных и передаваемые непрерывно с определенным периодом. Каждое сообщение содержит измерение в определенный момент времени. Измерения берутся с определенной частотой частотой дискретизации.

Частота дискретизации частота взятия отсчетов непрерывного по времени сигнала при его дискретизации.


Частота дискретизации 80 выборок в секунду

Состав SV-потоков описан в МЭК61850-9-2 LE.

SV-потоки передаются через шину процесса.

Шина процесса коммуникационная сеть, обеспечивающая обмен данными между измерительными устройствами и устройствами уровня присоединения. Правила обмена данными (мгновенными значениями тока и напряжения) описаны в стандарте МЭК 61850-9-2 (на данный момент используется профиль МЭК 61850-9-2 LE).

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

Зачем необходим multicast?
Как упоминалось выше, для закрытия требований по передаче данных для горизонтальной связи, GOOSE передаются несколько непривычно.

Во-первых, они передаются на канальном уровне и имеют свой Ethertype 0x88b8. Это обеспечивает высокую скорость передачи данных.

Теперь необходимо закрыть требования гарантированности и надежности.

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

Поэтому для передачи GOOSE используется архитектура Издатель-Подписчик.

Архитектура Издатель Подписчик

Устройство отправляет GOOSE-сообщение на шину, и подписчики получают это сообщение. Причем сообщение отправляется с постоянным временем T0. Если случается какое-то событие, то генерируется новое сообщение, в независимости от того, закончился предыдущий период Т0 или нет. Следующее сообщение с новыми данными генерируется через очень короткий промежуток времени, потом через чуть больший и так далее. В итоге время увеличивается до Т0.

Принцип передачи GOOSE-сообщений

Подписчик знает, от кого он получает сообщения, и если от кого-то не получил сообщение через время T0, то он генерирует сообщение об ошибке.

SV-потоки также передаются на канальном уровне, имеют свой Ethertype 0x88BA и передаются по модели Издатель Подписчик.

Нюансы multicast-передачи в Цифровой подстанции
Но в энергетическом multicastе есть свои нюансы.

Нюанс 1. Для GOOSE и SV определены свои multicast-группы
Для энергетического multicast используются свои группы для рассылки.

В телекоме для multicast-рассылки используется диапазон 224.0.0.0/4 (за редкими исключениями есть зарезервированные адреса). Но сам стандарт МЭК 61850 и корпоративный профиль МЭК 61850 от ПАО ФСК определяет собственные диапазоны multicast-рассылки.

Для SV-потоков: от 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.

Для GOOSE-сообщений: от 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.

Нюанс 2. Терминалы не используют протоколы multicast
Второй нюанс гораздо значительнее терминалы релейной защиты не поддерживают IGMP или PIM. Тогда как они работаю с multicast? Они просто ждут, когда на порт будет прислана нужная информация. Т.е. если они знают, что подписаны на определенный MAC-адрес, то принимают все приходящие фреймы, но обрабатывают только необходимые. Остальные просто отбрасывают.

Другими словами вся надежда возлагается на коммутаторы. Но как будет работать IGMP или PIM, если терминалы не будут посылать Join-сообщения? Ответ простой никак.

А SV-потоки это достаточно тяжелые данные. Один поток весит около 5 Мбит/с. И если все оставить как есть, то получится, что каждый поток будет передаваться широковещательно. Другими словами, мы потянем всего 20 потоков на одну 100 Мбит/с ЛВС. А количество SV-потоков на крупной подстанции измеряется сотнями.

Какой тогда выход?

Простой использовать старые проверенные VLAN.

Более того, IGMP в ЛВС Цифровой Подстанции может сыграть злую шутку, и наоборот ничего не будет работать. Ведь коммутаторы без запроса не начнут передавать потоки.

Поэтому можно выделить простое правило пусконаладки Сеть не работает? Disable IGMP!

Нормативная база

Но может быть все-таки можно как-то организовать ЛВС Цифровой Подстанции на основе multicast? Давайте попробуем обратиться теперь к нормативной документации по ЛВС. В частности я буду приводить выдержки из следующих СТО:

• СТО 34.01-21-004-2019 ЦИФРОВОЙ ПИТАЮЩИЙ ЦЕНТР. ТРЕБОВАНИЯ К ТЕХНОЛОГИЧЕСКОМУ ПРОЕКТИРОВАНИЮ ЦИФРОВХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 110-220 кВ И УЗЛОВХ ЦИФРОВХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 35 кВ.
• СТО 34.01-6-005-2019 КОММУТАТОР ЭНЕРГООБЪЕКТОВ. Общие технические требования.
• СТО 56947007-29.240.10.302-2020 Типовые технические требования к организации и производительности технологических ЛВС в АСУ ТП ПС ЕНЭС.

Давайте сначала посмотрим, что можно найти в этих СТО про multicast? Упоминание есть только в свежем СТО от ПАО ФСК ЕЭС. СТО просит при приемо-сдаточных испытаниях ЛВС проверить, корректно ли настроены VLAN, и проверить отсутствие multicast-трафика в непрописанных в рабочей документации портах коммутаторов.

Ну и еще СТО прописывает, что обслуживающий персонал должен знать, что такое multicast.

На этом все про multicast

Теперь давайте посмотрим, что можно найти в этих СТО про VLAN.

Здесь уже все три СТО сходятся в том, что коммутаторы должны поддерживать VLAN на основе IEEE 802.1Q.

СТО 34.01-21-004-2019 говорит о том, что VLANы должны использоваться для управления потоками, и при помощи VLAN трафик должен разделяться на РЗА, АСУТП, АИИС КУЭ, видеонаблюдение, связь и др.

СТО 56947007-29.240.10.302-2020, помимо этого, еще требует при проектирование подготовить карту распределения по VLAN. При этом СТО предлагает свои диапазоны IP-адресов и VLAN для оборудования ЦПС.

Также СТО приводит таблицу рекомендуемых приоритетов для разных VLAN.

Таблица рекомендуемых приоритетов VLAN из СТО 56947007-29.240.10.302-2020



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

А сейчас давайте подведем итог по управлению потоками в ЛВС Цифровой Подстанции.

Заключение

В Цифровой Подстанции, несмотря на тот факт, что передается очень много multicast-потоков, по факту не применяются стандартные механизмы управления multicast-трафиком (IGMP, PIM). Это обусловлено тем, что конечные устройства не поддерживают какие-либо multicast-протоколы.

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

Полезные ссылки:
Обучающий курс Цифровая подстанция от Phoenix Contact.
Решения для ЦПС от Phoenix Contact.

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

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

Прим. Автор подразумевает, что читатель хорошо знаком со следующими технологиями: OSPF, BGP, PIM, MPLS.

Заинтересовавшимся добро пожаловать под кат.

Основной задачей является туннелирование мультикаст-пакетов между РЕ маршрутизаторами (от Ingress PE к одному или более Egress PE). Для этого необходимо построить наложенную (overlay) сеть поверх опорной (underlay) инфраструктуры.

Если мы обратимся к RFC6513, то найдем там одно довольно пространственное пояснение по поводу, как необходимо передавать трафик между РЕ-маршрутизаторами: P-tunnels must be used a P-tunnel is a transport mechanism inside the network of the Service Provider that instantiates a Provider Multicast Service Interface (PMSI). A PMSI is a conceptual overlay on the P-network with the following property: a PE in a given MVPN can give a packet to the PMSI, and the packet will be delivered to some or all of the other PEs in the MVPN, such that any PE receiving the packet will be able to determine the MVPN to which the packet belongs.

Т.е. если просто следовать сказанному, то вся multicast VPN инфраструктура будет выглядеть приблизительно вот так:

Осталась самая малость разобраться с тем, как строить этот PMSI и как РЕ устройствам узнавать друг о друге.

На текущий момент мне известно четыре способа создания Р-туннелей:

• Protocol Independent Multicast (PIM, P-PIM, Provider-PIM; PIM работающий внутри опорной сети в рамках глобальной таблицы маршрутизации GRT)
• Multipoint Label Distribution Protocol (mLDP)
• Resource Reservation Protocol Traffic Engineering (RSVP-TE)
• Ingress Replication (IR)

Прим. В статьях основное внимание будет уделено созданию PMSI с помощью PIM и mLDP.

После поднятия Р-туннелей, РЕ должны произвести сигнализацию о наличии Источников и/или Получателей трафика в сети. Делается это одним из двух вариантов:

• PIM (C-PIM, Customer-PIM; PIM работающий внутри наложенной сети в рамках клиентской таблицы маршрутизации (VRF))
• BGP.

Ключевыми блоками mVPN являются следующие компоненты:

• тип корневого дерева. Корневое дерево определяет как будет передаваться пользовательский многоадресный трафик (C-Multicast) поверх опорной сети.
• протокол построения корневого дерева
• протокол сигнализации клиентского трафика

Мультикастные деревья

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

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

• точка-точка (Point-to-Point)
  
  • это классическое дерево (должно быть знакомо всем тем, кто работал с MPLS сетями), которое представляет собой LSP для передачи одноадресного (unicast) трафика.
• точка-многоточка (Point-to-Multipoint)
  
  • это дерево в котором только одно устройство (корень дерева, root) может передавать пакеты в сеть. По своей природе дерево является однонаправленным (unidirectional).
• многоточка-многоточка (Multipoint-to-Multipoint)
  
  • это двунаправленное дерево (bidirectional), в котором трафик передается либо по направлению к корневому маршрутизатору, либо от него. Любой РЕ может передавать пакеты в сеть, равно как и принимать их.
• точка-точка-многоточка (Point-to-Point-to-Multipoint)
  
  • дерево представляет собой микс P2P и P2MP деревьев. Любой РЕ коммутатор может передавать пакеты внутрь P2P LSP в сторону корневого РЕ, который в свою очередь передает пакеты дальше посредством P2MP до всех остальных РЕ.
    Необходимость в таком дереве будет рассмотрена в главе, посвященной тематике Partitioned MDT.

Функционально деревья делятся на три категории:

• Multi-Directional Inclusive PMSI (MI-PMSI, aka Default MDT)
• Selective PMSI (aka Data MDT)
• Multi-Directional Selective PMSI (aka Partitioned MDT)

О каждом из этих деревьев мы подробно поговорим в следующих разделах (в следующих выпусках). Сейчас же остановимся на дереве, которое является обязательным аттрибутом любой имплементации mVPN и носит название Default MDT.

Default MDT

Default MDT представляет собой древовидную структуру для соединения всех PE-маршрутизаторов в рамках одного VPN (VRF) с включенной многоадресной рассылкой. Преимущество наличия Default MDT заключается в том, что оно облегчает передачу сигнализации PIM в наложенной сети.

Default MDT всегда включено и из-за этого все маршрутизаторы PE становятся PIM соседями в рамках VRF, что позволяет передавать PIM сигнализацию (Join/Prune, RPT Switchover) поверх Default MDT также, как если бы все РЕ маршрутизаторы находились в одном LAN сегменте.

mVPN Profile 0

Одним из наиболее простых способов реализации mVPN является вариант настройки который известен под кодовым именем Profile 0, именуемый в народе как Draft Rosen.

Основные компоненты реализации профиля:

• использование Default MDT
• использование PIM для сигнализации внутри наложенной сети
• использование PIM внутри опорной сети
• инкапсуляция C-multicast трафика внутрь GRE (mGRE если быть точным)

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

• BGP (в частности, адресное семейство VPNv4), с помощью которого будут передаваться unicast клиентские адреса для прохождения RPF проверок многоадресного трафика.
• OSPF или IS-IS (по вкусу) для обеспечения IP-связности между интерфейсами Loopback0 всех устройств, поверх которых будут строиться BGP сессии
• PIM ASM внутри опорной сети (в рамках Global Routing Table, GRT)
  
  • В качестве метода распространения информации о точке рандеву выберем протокол Bootstrap Router (BSR)
• LDP внутри опорной сети для распространения меток от/до РЕ.

Шаблон для настройки базовых ингридиентов:

router ospf 1 router-id X.X.X.X!ip mutlicast-routing!ip pim register-source Lo0!interface Loopback0 ip address X.X.X.X 255.255.255.255 ip ospf 1 area 0 ip pim sparse-mode!interface Gi2.Y encapsulation dot1q Y ip address 10.X.Y.Z 255.255.255.0 ip ospf 1 area 0 ip pim sparse-mode!router bgp 65001 bgp router-id X.X.X.X no bgp default ipv4 unicast neighbor Y.Y.Y.Y remote-as 65001 neighbor Y.Y.Y.Y update-source Loopback0 ! address-family vpnv4  neighbor Y.Y.Y.Y activate  neighbor Y.Y.Y.Y send-community-both!####################################################### ТОЛЬКО НА ТОЧКЕ РАНДЕВУ #######################################################!ip pim rp-candidate Lo0ip pim bsr-candidate Lo0

После проведение указанных настроек, Вы можете увидеть, что на каждом из устройств появился как минимум один туннель (а на Provider RP (P-RP) целых два). При этом эти туннели не видны в конфигурации, но присутствуют в выводе show ip int brief. В чем же их назначение? Ответ: Tunnel необходим для передачи (encap) сообщений PIM-Register в сторону P-RP. На стороне P-RP дополнительный Tunnel необходим для обработки (decap) всех прибывающих Register сообщений.

Прим. Номера туннельных интерфейсов у меня и у Вас в лаборатории могут отличаться

PE1#show int tu2 | i Descr|destination|Tunnel2Tunnel2 is up, line protocol is up   Description: **Pim Register Tunnel (Encap)** for RP 8.8.8.8  Tunnel source 1.1.1.1 (Loopback0), destination 8.8.8.8

>RR#show int tu0 | i Descr|destination|Tunnel0Tunnel0 is up, line protocol is up   Description: **Pim Register Tunnel (Encap)** for RP 8.8.8.8  Tunnel source 8.8.8.8 (Loopback0), destination 8.8.8.8         Tunnel0 source tracking subblock associated with Loopback0RR#show int tu1 | i Descr|destination|Tunnel1Tunnel1 is up, line protocol is up   Description: Pim Register Tunnel (**Decap**) for RP 8.8.8.8  Tunnel source 8.8.8.8 (Loopback0), destination 8.8.8.8         Tunnel1 source tracking subblock associated with Loopback0

В Profile 0 подразумевается передача C-multicast трафика с помощью mGRE инкапсуляции. В новом (внешнем) IP заголовке выставляется адрес многоадресной рассылки. Данный адрес должен быть маршрутизируем в рамках опорной сети (внутри GRT). Именно для этого нам необходим PIM внутри GRT. Задается данная группа с помощью следующей конструкции:

ip vrf C-ONE mdt default 239.1.1.1

Таким образом, если ingress PE получает мультикаст-пакет в рамках клиентского VRF, то этот ingress РЕ инкапсулирует его внутрь mGRE, в качестве destination IP выставляет адрес 239.1.1.1 и пакет отправляется в опорную сеть.

Очевидно, что все egress PE должны быть подписаны на ту же самую многоадресную группу. В противном случае трафик до них не дойдет. Дополнительной настройки для подписки на группу не требуется.

PE2#show ip igmp membership Flags: A  - aggregate, T - tracked       L  - Local, S - static, V - virtual, R - Reported through v3        I - v3lite, U - Urd, M - SSM (S,G) channel        1,2,3 - The version of IGMP, the group is inChannel/Group-Flags:        / - Filtering entry (Exclude mode (S,G), Include mode (G))Reporter:       <mac-or-ip-address> - last reporter if group is not explicitly tracked       <n>/<m>      - <n> reporter in include mode, <m> reporter in exclude Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface  *,239.1.1.1                    2.2.2.2         1d20h    stop  2VA    Lo0

Из вывода видно, что РЕ2 подписался на группу (*, 239.1.1.1) со своего интерфейса Loopback0. Это, в свою очередь, ведет к генерации PIM Join в сторону RP и формированию многоадресного дерева в опорной сети.

В выводе ниже видно, что на Р2 появляется запись в mRIB. Наличие двух маршрутов обусловлено работой PIM ASM (shared tree и source-based tree):

P2#show ip mroute 239.1.1.1IP Multicast Routing Table(*, 239.1.1.1), 2d00h/00:03:09, RP 8.8.8.8, flags: S  Incoming interface: GigabitEthernet2.68, RPF nbr 10.6.8.8  Outgoing interface list:    GigabitEthernet2.67, Forward/Sparse, 2d00h/00:03:09    GigabitEthernet2.26, Forward/Sparse, 2d00h/00:03:05 (2.2.2.2, 239.1.1.1), 05:22:26/00:01:55, flags: T  Incoming interface: GigabitEthernet2.26, RPF nbr 10.2.6.2  Outgoing interface list:    GigabitEthernet2.56, Forward/Sparse, 05:22:26/00:02:46    GigabitEthernet2.67, Forward/Sparse, 05:22:26/00:03:09

После того, как настройка MDT для vrf C-ONE растиражирована на все РЕ, на Р устройствах появляются соответствующие маршруты:

P2#show ip mroute 239.1.1.1IP Multicast Routing Table(*, 239.1.1.1), 2d00h/00:03:09, RP 8.8.8.8, flags: S  Incoming interface: GigabitEthernet2.68, RPF nbr 10.6.8.8  Outgoing interface list:    GigabitEthernet2.67, Forward/Sparse, 2d00h/00:03:09    GigabitEthernet2.26, Forward/Sparse, 2d00h/00:03:05(4.4.4.4, 239.1.1.1), 05:21:57/00:02:16, flags: T  Incoming interface: GigabitEthernet2.56, RPF nbr 10.5.6.5  Outgoing interface list:    GigabitEthernet2.26, Forward/Sparse, 05:21:57/00:03:15(3.3.3.3, 239.1.1.1), 05:22:22/00:01:46, flags: T  Incoming interface: GigabitEthernet2.67, RPF nbr 10.6.7.7  Outgoing interface list:    GigabitEthernet2.26, Forward/Sparse, 05:22:22/00:03:05(2.2.2.2, 239.1.1.1), 05:22:26/00:01:55, flags: T  Incoming interface: GigabitEthernet2.26, RPF nbr 10.2.6.2  Outgoing interface list:    GigabitEthernet2.56, Forward/Sparse, 05:22:26/00:02:46    GigabitEthernet2.67, Forward/Sparse, 05:22:26/00:03:09(1.1.1.1, 239.1.1.1), 2d00h/00:03:15, flags: T  Incoming interface: GigabitEthernet2.56, RPF nbr 10.5.6.5  Outgoing interface list:    GigabitEthernet2.26, Forward/Sparse, 2d00h/00:03:05

На данном этапе опорная сеть готова к передаче многоадресного трафика в рамках GRT. Но зачем нам это? ведь пользовательский трафик живет внутри C-VRF! Постараемся ответить на данный вопрос ниже.

Следующим шагом необходимо поднять интерфейс PMSI. На Cisco IOS (в рамках Profile 0) за это отвечает адресное семейство MDT процесса BGP. Как только на РЕ появляется сконфигурированный MDT сосед, операционная система автоматически создает PMSI интерфейс.

Все MDT сессии будем строить также через Route Reflector (R8).

PE1#sh run | s bgprouter bgp 65001 ! address-family ipv4 mdt  neighbor 8.8.8.8 activate exit-address-family

На РЕ сразу же появляется дополнительный интерфейс Tunnel:

*Nov 12 11:27:45.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

PE1#show int Tu0 | i transport|source|Tunnel0Tunnel0 is up, line protocol is up   Tunnel source 1.1.1.1 (Loopback0)         Tunnel0 source tracking subblock associated with Loopback0          Set of tunnels with source Loopback0, 2 members (includes iterators), on interface <OK>  Tunnel protocol/transport multi-GRE/IP  Tunnel transport MTU 1476 bytes

Интерфейс Tunnel0 ничто иное, как PMSI относящийся к C-VRF.

PE1#show ip pim vrf C-ONE interface Address          Interface                Ver/   Nbr    Query  DR         DR                                          Mode   Count  Intvl  Prior172.1.11.1       GigabitEthernet2.111     v2/S   1      30     1          172.1.11.11172.1.15.1       GigabitEthernet2.115     v2/S   1      30     1          172.1.15.151.1.1.1          Tunnel0                  v2/S   3      30     1          4.4.4.4

Через данный интерфейс РЕ начинает рассылку сообщений PIM Hello (на адрес 224.0.0.13) и устанавливает отношения соседства со всеми другими РЕ, на которых настроена VRF с таким же адресом для Default MDT.

PE1#show ip pim vrf C-ONE interface Address          Interface                Ver/   Nbr    Query  DR         DR                                          Mode   Count  Intvl  Prior172.1.11.1       GigabitEthernet2.111     v2/S   1      30     1          172.1.11.11172.1.15.1       GigabitEthernet2.115     v2/S   1      30     1          172.1.15.151.1.1.1          Tunnel0                  v2/S   3      30     1          4.4.4.4

PE1#show ip pim vrf C-ONE neighbor           PIM Neighbor TableMode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,      L - DR Load-balancing CapableNeighbor          Interface                Uptime/Expires    Ver   DRAddress                                                            Prio/Mode172.1.11.11       GigabitEthernet2.111     4d20h/00:01:25    v2    1 / DR S P G172.1.15.15       GigabitEthernet2.115     4d21h/00:01:25    v2    1 / DR S P G3.3.3.3           Tunnel0                  00:07:25/00:01:41 v2    1 / S P G2.2.2.2           Tunnel0                  00:07:25/00:01:41 v2    1 / S P G4.4.4.4           Tunnel0                  00:08:24/00:01:41 v2    1 / DR S P G

На рисунке ниже представлен дамп одного из PIM Hello, отправленного со стороны РЕ1. Как видно, доставка клиентского (в рамках VRF) пакета до всех заинтересованных РЕ достигается за счет инкапсуляции внутрь многоадресного IP-пакета, который может маршрутизироваться в рамках опорной сети.

Из всего вышесказанного следует, что дерево Default MDT имеет тип Multipoint-to-Multipoint т.к. любой РЕ имеет право передавать данные в рамках дерева (напр. сообщения PIM Hello) и пакеты будут доставлены до любого другого РЕ, являющегося частью указанного дерева.

Внимательный читатель мог справедливо задаться вопросом: а в чем тайный смысл адресного семейства MDT? Ведь маршрутизация осуществляется благодарю наличию PIM ASM в опорной сети.

Все дело в том, что реализация Cisco IOS подразумевает, что PMSI поднимется только после настройки хотя бы одного BGP соседа в рамках указанного адресного семейства. Технически, соседство может быть даже не установлено (Tunnel0 переходит в состояние UP как только Вы введете команду neighbor activate).

Соседство в рамках MDT строго требуется, если внутри опорной сети работает PIM SSM. Дело в том, что если в сети отсутствует RP, то РЕ маршрутизаторам как-то необходимо узнать друг о друге. В рамках MDT они обмениваются маршрутами следующего вида:

PE1#show bgp ipv4 mdt all      Network          Next Hop            Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *>   1.1.1.1/32       0.0.0.0                                0 ?Route Distinguisher: 2.2.2.2:1 *>i  2.2.2.2/32       2.2.2.2                  0    100      0 ?Route Distinguisher: 3.3.3.3:1 *>i  3.3.3.3/32       3.3.3.3                  0    100      0 ?Route Distinguisher: 4.4.4.4:1 *>i  4.4.4.4/32       4.4.4.4                  0    100      0 ?

PE1#show bgp ipv4 mdt all 2.2.2.2/32BGP routing table entry for 2.2.2.2:1:2.2.2.2/32         version 3Paths: (1 available, best #1, table IPv4-MDT-BGP-Table)  Not advertised to any peer  Refresh Epoch 1  Local    2.2.2.2 from 8.8.8.8 (8.8.8.8)      Origin incomplete, metric 0, localpref 100, valid, internal, best      Originator: 2.2.2.2, Cluster list: 8.8.8.8,      MDT group address: 239.1.1.1      rx pathid: 0, tx pathid: 0x0

Из указанных апдейтов РЕ выбирает поля Originator и MDT group address, что позволяет просигнализировать (S,G) дерево.

Прим. Согласно документации от вендора: The Address Family (AF) IPv4 Multicast Distribution Tree (MDT) must be used for all types of PIM signaling in the core (not only for PIM Source Specific Multicast (SSM)).
Т.е. без sAFI MDT всё будет работать, но официально такая конструкция не поддерживается.

Осталось проверить прохождение клиентского трафика.

Для этого, на CE3 и CE4 пропишем конструкцию:

interface Loopback0 ip igmp join-group 230.0.0.1

Убедимся, что на РЕ3 и РЕ4 появились маршруты:

PE3#show ip mroute vrf C-ONE       (*, 230.0.0.1), 05:58:36/00:03:19, RP 15.15.15.15, flags: S  Incoming interface: Tunnel1, RPF nbr 1.1.1.1  Outgoing interface list:    GigabitEthernet2.313, Forward/Sparse, 00:00:10/00:03:19

PE4#show ip mroute vrf C-ONE(*, 230.0.0.1), 00:00:29/00:03:00, RP 15.15.15.15, flags: S  Incoming interface: Tunnel0, RPF nbr 1.1.1.1  Outgoing interface list:    GigabitEthernet2.414, Forward/Sparse, 00:00:29/00:03:00

На РЕ2 OIL пустой (поскольку нет активных получателей). Однако, IIL состоит из интерфейса Tunnel (default MDT). Т.е. РЕ2 будет получать пакеты на группу 230.0.0.1 и отбрасывать их.

PE2#show ip mroute 239.1.1.1(*, 239.1.1.1), 05:06:26/stopped, RP 8.8.8.8, flags: SJCFZ  Incoming interface: GigabitEthernet2.26, RPF nbr 10.2.6.6  Outgoing interface list:    MVRF C-ONE, Forward/Sparse, 05:06:26/stopped

PE2#show ip mroute vrf C-ONE(*, 230.0.0.1), 05:59:17/00:01:08, RP 15.15.15.15, flags: SP  Incoming interface: Tunnel1, RPF nbr 1.1.1.1  Outgoing interface list: Null

И запустим трафик:

CE1#ping 230.0.0.1 source 11.11.11.11Type escape sequence to abort.Sending 1, 100-byte ICMP Echos to 230.0.0.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11 Reply to request 0 from 14.14.14.14, 11 msReply to request 0 from 13.13.13.13, 13 ms

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

Таким образом: даже при наличии MPLS внутри опорной сети, метки для передачи многоадресного трафика (в рамках Profile 0) не используются.

При этом ответный трафик (ICMP reply) подчиняется законам одноадресной маршрутизации и его передача осуществляется по классическим правилам MPLS L3 VPN:

К сожалению, Default MDT не всегда эффективно. Все дело в том, что оно доставляет весь многоадресный трафик на все PE-маршрутизаторы, независимо от того, есть ли C-Receiver или же нет. Это означает, что ядро сети может передавать многоадресный трафик к тем маршрутизаторам PE, которые затем отбрасывают трафик. Это видно из дампа трафика (обратите внимание на поле VLAN ID = 26, которое символизирует линк между R2 (PE2) и R6 (P2)).

Чтобы обойти ограничения Default MDT вводится понятие Data MDT, которое позволяет переключить пользовательский трафик C-(S,G) из Default MDT в Data MDT, в котором участвуют только те РЕ, где есть активные источники или получатели трафика. Об этом мы поговорим с Вами в следующем выпуске.

Продолжение следует...

В прошлой статье мы познакомились с Вами с исторически первым способом организации построения multicast VPN с помощью технологий PIM и mGRE (Часть 1, Profile 0).

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

• LDP пиры находят друг друга посредством рассылки Hello сообщений на адрес 224.0.0.2. В рамках Hello передается параметр transport address (который, по-умолчанию в Cisco IOS совпадает с IP адресом LDP router-id)
• Маршрутизаторы устанавливают ТСР сессию и в рамках неё обмениваются метками для FEC (читай IP префиксов из таблицы маршрутизации)
• Результат обмена однонаправленный LSP типа Point-to-Point.

• Помимо этого, пиры в рамках ТСР сессии обмениваются сообщениями типа Initialization, внутри которых передается информация о поддерживаемых возможностях (Capabilities). За обмен информацией отвечают Capabilities TLV.
  
  • Т.е. обмениваться можно не только информацией об P2P LSP, но и ещё чем-то ...

Вся соль mLDP в том, что для этого протокола FEC представляет собой не какой-то один конкретный префикс, а скорее некую комбинацию из четырёх элементов:

• Тип дерева
• Адресное семейство (IPv4/IPv6)
• IP адрес корневого устройства
• Корневое устройство заранее определенный коммутатор, в котором начинается mLDP LSP
• Некое дополнительно значение, в оригиналье именуемое Opaque Value.
  
  • Используется для обозначения конкретного дерева (читай C-VRF) внутри MPLS инфраструктуры.

Всего для mLDP определено три различных FEC:

• P2MP FEC (тип дерева = 0x06)
• MP2MP Upstream FEC (тип дерева = 0x07)
• MP2MP Downstream FEC (тип дерева = 0x08)

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

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

Теперь попробуем разобраться с тем, как именно строится MP2MP LSP в mLDP (P2MP нам будет интересен в следующих статьях цикла).

Построение MP2MP LSP

Точно также как в обычном unicast LSP, направление сигнализации (распространение меток) противоположно направлению следованию трафика.

Весь процесс сигнализации можно разделить на два этапа (очень похожих на процесс построения многоадресного дерева в PIM ASM через точку рандеву):

• Downstream сигнализация
  
  • РЕ распространяют метки в сторону корневого маршрутизатора
  • Согласно распространённым меткам, корневой маршрутизатор передаёт трафик в сторону РЕ
• Upstream сигнализация
  
  • Корневой маршрутизатор распространяет метки в сторону РЕ
  • Согласно распространённым меткам, РЕ передаёт трафик в сторону корневого маршрутизатора

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

Рассмотрим вариант замены ранее рассмотренного метода построения Default MDT через BGP ipv4 MDT на mLDP на следующей топологии:

В качестве корневого маршрутизатора будем использовать R8.

Проведем базовую преднастройку (подразумевается, что сделаны все настройки из 1-ой части статьи):

• Отключим на всех маршрутизаторах протокол PIM:
  

  interface Gi2.Xno ip pim sparse-mode
  

• адресное семейство BGP MDT (на РЕ):
  

  router bgp 65001no address-family ipv4 mdt
  

• и адрес рассылки MDT
  

  ip vrf C-ONEno mdt default 239.1.1.1
  

Для полной настройки FEC нам остается ввести IP адрес корневого маршрутизатора и Opaque Value. Начнём с РЕ1:

PE1(config)#mpls mldp logging notificationsPE1(config)#!PE1(config)#ip vrf C-ONEPE1(config-vrf)# vpn id 65001:1PE1(config-vrf)# mdt default mpls mldp 8.8.8.8PE1(config-vrf)#*Nov 21 22:41:03.703: %MLDP-5-ADD_BRANCH: [mdt 65001:1 0] Root: 8.8.8.8, Add MP2MP branch MDT(Lspvif0) remote label , local label no_label*Nov 21 22:41:03.742: MLDP: Reevaluating peers for nhop: 10.1.5.5PE1(config-vrf)#*Nov 21 22:41:04.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to upPE1(config-vrf)#*Nov 21 22:41:05.840: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0PE1(config-vrf)#

PE1 создаёт новый интерфейс Lspvif0 (LSP virtual interface, ничто иное как новый PMSI) для MDT с Opaque Value = [65001:1 0] и запускает на нём PIM в рамках C-VRF.

Прим. Opaque Value состоит из двух частей: vpn id и некоторого дополнительного индекса. Если индекс равен нулю, то это указание на использование Default MDT.

Проверим некоторые параметры вновь созданного интерфейса:

PE1#show ip interface Lspvif0Lspvif0 is up, line protocol is up  Interface is unnumbered. Using address of Loopback0 (1.1.1.1)  Multicast reserved groups joined: 224.0.0.1 224.0.0.2 224.0.0.22 224.0.0.13  VPN Routing/Forwarding "C-ONE"

PE1#show ip pim vrf C-ONE interface Address          Interface                Ver/   Nbr    Query  DR         DR                                          Mode   Count  Intvl  Prior172.1.11.1       GigabitEthernet2.111     v2/S   1      30     1          172.1.11.11172.1.15.1       GigabitEthernet2.115     v2/S   1      30     1          172.1.15.151.1.1.1          Lspvif0                  v2/S   0      30     1          1.1.1.1

Посмотрим базу данных по меткам:

PE1#show mpls mldp neighbors  MLDP peer ID    : 5.5.5.5:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 1  Upstream count : 1  Branch count   : 0  Path count     : 1  Path(s)        : 10.1.5.5          LDP GigabitEthernet2.15  Nhop count     : 1  Nhop list      : 10.1.5.5 

PE1#show mpls mldp database   * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 5 (RNR LSM ID: 6)   Type: MP2MP   Uptime : 00:07:53  FEC Root           : 8.8.8.8   Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  RNR active LSP     : (this entry)  Upstream client(s) :    5.5.5.5:0    [Active]      Expires        : Never         Path Set ID  : 6      Out Label (U)  : 1013          Interface    : GigabitEthernet2.15*      Local Label (D): 10017         Next Hop     : 10.1.5.5  Replication client(s): >   MDT  (VRF C-ONE)      Uptime         : 00:07:53      Path Set ID  : 7      Interface      : Lspvif0       RPF-ID       : *

На РЕ1 присутствует Upstream сосед, которому была передана метка 10017. Трафик, который будет передавать от РЕ1 в сторону R8 получит метку 1013 от Р1.

На Р1 соседей гораздо больше (согласно топологии шестеро):

P1#show mpls mldp neighbors  MLDP peer ID    : 4.4.4.4:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 1  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.4.5.4          LDP GigabitEthernet2.45  Nhop count     : 0 MLDP peer ID    : 1.1.1.1:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 2  Upstream count : 0  Branch count   : 1  Path count     : 1  Path(s)        : 10.1.5.1          LDP GigabitEthernet2.15  Nhop count     : 0 MLDP peer ID    : 8.8.8.8:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 3  Upstream count : 1  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.8.8          LDP GigabitEthernet2.58  Nhop count     : 1  Nhop list      : 10.5.8.8  MLDP peer ID    : 6.6.6.6:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 4  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.6.6          LDP GigabitEthernet2.56  Nhop count     : 0 MLDP peer ID    : 7.7.7.7:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 5  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.7.7          LDP GigabitEthernet2.57  Nhop count     : 0 MLDP peer ID    : 9.9.9.9:0, uptime 1w5d Up,   Target Adj     : No  Session hndl   : 6  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.9.9          LDP GigabitEthernet2.59  Nhop count     : 0

P1#show mpls mldp database   * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 3   Type: MP2MP   Uptime : 00:13:23  FEC Root           : 8.8.8.8   Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  Upstream client(s) :    8.8.8.8:0    [Active]      Expires        : Never         Path Set ID  : 9      Out Label (U)  : 8017          Interface    : GigabitEthernet2.58*      Local Label (D): 1014          Next Hop     : 10.5.8.8  Replication client(s):     1.1.1.1:0       Uptime         : 00:13:23      Path Set ID  : A      Out label (D)  : 10017         Interface    : GigabitEthernet2.15*      Local label (U): 1013          Next Hop     : 10.1.5.1

Обратите внимание на тот факт, что на Р1 C-VRF не настроен, однако маршрутизатор понимает MP2MP дерево согласно по-умолчанию включённому функционалу recursive fec.

На Р1 есть один Upstream сосед (тот, через которого можно добраться на корня дерева) и один Downstream сосед. Для передачи данных в сторону РЕ1, как и ожидалось, используется метка 10017. При получении mLDP метки 10017, Р1 генерирует метку 1014 и отправляет её в сторону Upstream соседа.

Здесь можно сформулировать правило: каждый раз, когда маршрутизатор получает Downstream MP2MP метку, он реагирует созданием Upstream MP2MP метки и отправлением её в сторону Upstream соседа.

Таким образом на текущий момент организуется дерево от РЕ до ROOT.

В ответ на получение метки 1014, ROOT генерирует метку 8017 которая для Р1 будет являться Upstream меткой. В ответ на получение 8017, Р1 генерирует Downstream метку 1013 и отправляет её в сторону PE1.

Добавим настройку на РЕ4:

PE4(config-subif)#ip vrf C-ONEPE4(config-vrf)# vpn id 65001:1PE4(config-vrf)# mdt default mpls mldp 8.8.8.8

*Nov 21 23:25:03.638: %PIM-5-NBRCHG: VRF C-ONE: neighbor 1.1.1.1 UP on interface Lspvif0

Обратите внимание, что mLDP метки на R8 (ROOT) никоим образом не меняются при появлении нового устройства. Это происходит из-за того, что Р1 не создаёт новую метку при получении сигнализации от РЕ4 в силу того, что сообщаемая метка от РЕ4 принадлежит тому же FEC, что полученная ранее от PE1.

Однако на Р1 появляются новые метки (и это ожидаемо, т.к. РЕ4 произвёл дополнительную сигнализацию):

P1#show mpls mldp database               * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 3   Type: MP2MP   Uptime : 00:46:10  FEC Root           : 8.8.8.8   Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  Upstream client(s) :    8.8.8.8:0    [Active]      Expires        : Never         Path Set ID  : 9      Out Label (U)  : 8017          Interface    : GigabitEthernet2.58*      Local Label (D): 1014          Next Hop     : 10.5.8.8  Replication client(s):     1.1.1.1:0       Uptime         : 00:46:10      Path Set ID  : A      Out label (D)  : 10017         Interface    : GigabitEthernet2.15*      Local label (U): 1013          Next Hop     : 10.1.5.1    4.4.4.4:0       Uptime         : 00:02:11      Path Set ID  : B      Out label (D)  : 40017         Interface    : GigabitEthernet2.45*      Local label (U): 1012          Next Hop     : 10.4.5.4

Стоит создать дополнительный VRF C-TWO на РЕ4, как сигнализируется дополнительное дерево с новыми метками.

PE4(config)#ip vrf C-TWOPE4(config-vrf)# rd 4.4.4.4:2PE4(config-vrf)# vpn id 65001:2PE4(config-vrf)# mdt default mpls mldp 8.8.8.8PE4(config-vrf)# route-target export 65001:2PE4(config-vrf)# route-target import 65001:2

RR#show mpls mldp database   * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 1   Type: MP2MP   Uptime : 00:54:07  FEC Root           : 8.8.8.8 (we are the root)  Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  Upstream client(s) :    None      Expires        : N/A           Path Set ID  : 1  Replication client(s):     5.5.5.5:0       Uptime         : 00:54:06      Path Set ID  : 2      Out label (D)  : 1014          Interface    : GigabitEthernet2.58*      Local label (U): 8017          Next Hop     : 10.5.8.5LSM ID : 2   Type: MP2MP   Uptime : 00:00:48  FEC Root           : 8.8.8.8 (we are the root)  Opaque decoded     : [mdt 65001:2 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000200000000  Upstream client(s) :    None      Expires        : N/A           Path Set ID  : 3  Replication client(s):     5.5.5.5:0       Uptime         : 00:00:48      Path Set ID  : 4      Out label (D)  : 1019          Interface    : GigabitEthernet2.58*      Local label (U): 8018          Next Hop     : 10.5.8.5

Проверим связность между сайтами, находящимися за РЕ1 и РЕ4.

CE1#ping 230.0.0.1 source Lo0Type escape sequence to abort.Sending 1, 100-byte ICMP Echos to 230.0.0.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11 Reply to request 0 from 14.14.14.14, 15 ms

Связность есть, что хорошо. Однако, давайте задумаемся над одним вопросом по каком пути ходит трафик? Доходит ли он до корневого маршрутизатора и потом возвращается обратно (так называемый U-turn) или же P1 может передавать пакеты напрямую в сторону РЕ4?

Чтобы ответить на этот вопрос, проанализируем таблицу меток на Р1 и ROOT и дополнительное воспользуемся Wireshark.

Мы уже знаем, что для передачи многоадресного трафика РЕ1 будет использовать метку 1013 (см пояснения выше) (для интерфейса 802.1Q vlan id = 15). Это подтверждается дампом трафика.

Что делает Р1 при получении данной метки?

P1#show mpls forwarding-table labels 1013Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    Label      Label      or Tunnel Id     Switched      interface              1013       8017       [mdt 65001:1 0]  198024        Gi2.58     10.5.8.8               40017      [mdt 65001:1 0]  184856        Gi2.45     10.4.5.4 

На что здесь необходимо обратить пристальное внимание. P1 знает об этой метке, т.к он сам её сгенерировал (смотри вывод show mpls mldp database ранее). Ранее мы с Вами говорили о том, что РЕ передаёт пакет в сторону ROOT, а уже ROOT должен вернуть пакет обратно на заинтересованные РЕ. Однако в данном примере видно, что при получении пакета на Р1, он раздваивается и отправляется в сторону РЕ4 и ROOT. Т.е U-turn не происходит из-за того, что Р1 видит

• Downstream сигнализацию от РЕ4
• Upstream передачу данных от РЕ1

В результате Р1 коммутирует MPLS пакеты напрямую, отправляя на ROOT копию трафика.

На ROOT на текущий момент пакет должен быть уничтожен:

RR#show mpls forwarding-table | i 80178017       No Label   [mdt 65001:1 0]  0

Активируем VRF на всех остальных РЕ. В результате можем ожидать создания интерфейсов типа Lspvif на каждом РЕ устройстве и установление PIM соседства между ними.

PE1#show ip pim vrf C-ONE neighbor | i Lsp3.3.3.3           Lspvif0                  00:01:02/00:01:41 v2    1 / S P G2.2.2.2           Lspvif0                  00:01:09/00:01:40 v2    1 / S P G4.4.4.4           Lspvif0                  10:49:57/00:01:40 v2    1 / DR S P G

Дополнительно, проверим таблицу коммутации на ROOT и убедимся, что теперь для метки 8017 (которая была получена от Р1) есть собственная локальная метка.

RR#show mpls forwarding-table | i 80178017       2013       [mdt 65001:1 0]  982           Gi2.68     10.6.8.6 

Рассмотренный выше вариант реализации multicast VPN известен под кодовым именем Profile 1. Его основные характеристики:

• Нет необходимости в P-PIM для опорной сети
• В качестве PMSTI используется интерфейс Lspvif
• Нет необходимости в специализированном адресном семействе BGP
• Для передачи трафика используется Default MDT
• Построение Default MDT осуществляется с помощью протокола mLDP.
  
  • Проблема с тем, что многоадресный трафик коммутируется в сторону всех РЕ (в рамках VPN) также присутствует, как и в Profile 0.
• В качестве протокола многоадресной маршрутизации внутри C-VRF на опорной сети используется протокол PIM (автоматически активируется на интерфейсе Lspvif)

Продолжение следует...

В прошлых выпусках мы с Вами познакомились с понятиями Default MDT, типами корневых деревьев и разобрали два варианта реализации mVPN на основе mGRE и mLDP:
Profile 0
Profile 1

На сегодняшний день адресное семейство BGP MDT (которое уже рассматривали) является устаревшим. Ему на замену пришло новое SAFI = multicast VPN (mVPN). Что нового приносит данное адресное семейство? Какие случаи использования могут быть? Попробуем разобраться.

Заинтересованным добро пожаловать под кат.

Авторы идеи предложили разделить сообщение BGP update на две составляющие:

• Непосредственно mvpn NLRI. Внутри передаётся следующая информация:
  
  • Типа маршрута (значение от 1 до 7). У каждого маршрута своя функция.
• Аттрибуты туннеля PMSI (PMSI Tunnel Attribute, PTA). Отвечают за передачу информации о типе корневого дерева.

Типы BGP mVPN маршрутов

PTA

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

0 информация не представлена
1 RSVP-TE P2MP LSP
2 mLDP P2MP LSP
3 PIM-SSM
4 PIM-SM
5 BIDIR-PIM
6 Ingress Replication
7 mLDP MP2MP LSP

Дополнительные community

В зависимости от того, используется ли BGP для сигнализации многоадресного трафика в рамках VRF, у маршрутов могут появляться дополнительные коммьюнити.

VRF Route Import (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение:
Импортирование многоадресных маршрутов (подобную функцию в vpnv4 выполняет аттрибут Route-Target)

Route Target Constraint (RTC)
Предназначение:
В случае наличия RTC, Route-Reflector (или любой другой РЕ) отправляет только желаемый vpnv4/vpnv6 префикс к РЕ. Желаемый обозначает, что на принимаемом РЕ есть один или более VRF, в который указанный префикс может быть импортирован.

Прим. Более подробно про RTC написано в RFC4684

Source-AS Extended Community (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение:
Передача AS информации для организации Inter-AS mVPN сценариев

PE Distinguisher Label
Предназначение:
Построение PPMP дерева для участия в Partitioned MDT (на текущий момент я не планирую рассматривать данное дерево в рамках цикла статей).

Поскольку с появлением SAFI mVPN функционал BGP очень расширился, то и применять данное SAFI можно для разных сценариев, в частности:

• проведение Auto-Discovery
• замена PIM сигнализации на BGP

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

Сначала рассмотрим случай когда в наложенной сети сохраняется PIM, но поиск заинтересованных РЕ происходит посредством BGP. Передача данных между РЕ осуществляется посредством GRE. Данная реализация известна под кодовым именем Profile 3.

Как и раньше, будем использовать следующую лабораторную топологию:

Начальные условия:

• В рамках опорной сети:
  
  • настроен OSPF
  • настроен P-PIM в режиме SSM
    

    access-list 99 permit 239.1.1.0 0.0.0.255ip pim ssm range 99
    

• В рамках VRF:
  
  • настроен C-PIM
  • нет активных источников или получателей трафика
• VRF приведена к виду
  

  ip vrf C-ONErd 1.1.1.1:1route-target export 65001:1route-target import 65001:1
  

В первую очередь рассмотрим ситуацию, когда в рамках vrf C-ONE работает C-PIM SSM.

На всех РЕ:

ip vrf C-ONEmdt auto-discovery pimmdt default 239.1.1.1

На РЕ устройствах поднимается новый PMSTI:

*Nov 24 20:44:40.941: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2

PE1#show int tu2Tunnel2 is up, line protocol is upInterface is unnumbered. Using address of Loopback0 (1.1.1.1)Tunnel source 1.1.1.1 (Loopback0)Tunnel protocol/transport multi-GRE/IP

Пока что нет PIM соседства (т.к. РЕ не знают друг о друге):

*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2

Активируем адресное семейство ipv4 mvpn:

router bgp 65001!address-family ipv4 mvpnneighbor MPLS_PE send-community extendedneighbor MPLS_PE route-reflector-clientneighbor 1.1.1.1 activateneighbor 2.2.2.2 activateneighbor 3.3.3.3 activateneighbor 4.4.4.4 activateexit-address-family

На РЕ моментально появляются соседи в рамках C-VRF:

PE1#show ip pim vrf C-ONE neighbor172.1.11.11    GigabitEthernet2.111   2w3d/00:01:19   v2  1 / DR S P G172.1.15.15    GigabitEthernet2.115   2w3d/00:01:35   v2  1 / DR S P G4.4.4.4      Tunnel2         00:00:17/00:01:27 v2  1 / DR S P G3.3.3.3      Tunnel2         00:00:17/00:01:27 v2  1 / S P G2.2.2.2      Tunnel2         00:00:47/00:01:27 v2  1 / S P G

И соответствующие (S, G) деревья:

PE1#show ip mroute 239.1.1.1(1.1.1.1, 239.1.1.1), 00:00:45/00:02:44, flags: sTIncoming interface: Loopback0, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.15, Forward/Sparse, 00:00:45/00:02:44(4.4.4.4, 239.1.1.1), 00:00:49/00:02:10, flags: sTIZIncoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5Outgoing interface list:MVRF C-ONE, Forward/Sparse, 00:00:49/00:02:10(3.3.3.3, 239.1.1.1), 00:00:53/00:02:06, flags: sTIZIncoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5Outgoing interface list:MVRF C-ONE, Forward/Sparse, 00:00:53/00:02:06(2.2.2.2, 239.1.1.1), 00:01:19/00:01:40, flags: sTIZIncoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5Outgoing interface list:MVRF C-ONE, Forward/Sparse, 00:01:19/00:01:40

Как РЕ смогли увидеть друг друга? Ответ на этот вопрос нам даст анализ BGP таблицы:

PE1#show bgp ipv4 mvpn allBGP table version is 258, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i  internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i  IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Как видим, каждый РЕ маршрутизатор создал BGP IPv4 mvpn маршрут первого типа, в котором описал себя

PE1#show bgp ipv4 mvpn all route-type 1 4.4.4.4BGP routing table entry for [1][1.1.1.1:1][4.4.4.4]/12, version 262Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Not advertised to any peerRefresh Epoch 1Local, imported path from [1][4.4.4.4:1][4.4.4.4]/12 (global)4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestCommunity: no-exportExtended Community: RT:65001:1Originator: 4.4.4.4, Cluster list: 8.8.8.8PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101rx pathid: 0, tx pathid: 0x0BGP routing table entry for [1][4.4.4.4:1][4.4.4.4]/12, version 265Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Not advertised to any peerRefresh Epoch 1Local4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestCommunity: no-exportExtended Community: RT:65001:1Originator: 4.4.4.4, Cluster list: 8.8.8.8PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101rx pathid: 0, tx pathid: 0x0

Обратите внимание на PTA:

• Tunnel type: 3 говорит нам о том, что в рамках vrf использует SSM PIM
• tunnel parameters сообщает нам об адресе РЕ и группе многоадресной рассылки (EF01 0101 = 239.1.1.1)

Подключим клиента:

CE4(config-if)#ip igmp join-group 230.1.1.1 source 11.11.11.11

На РЕ этого сайта появляется многоадресный маршрут:

PE4#show ip mroute vrf C-ONE(11.11.11.11, 230.1.1.1), 00:00:11/00:03:18, flags: sTIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:11/00:03:18

В качестве RPF nbr указан адрес 1.1.1.1 как PE4 вычисляет его? На самом деле очень просто. Это адрес BGP next-hop для источника = 11.11.11.11

PE4#show ip route vrf C-ONE 11.11.11.11Routing Table: C-ONERouting entry for 11.11.11.11/32  Known via "bgp 65001", distance 200, metric 0  Tag 65011, type internal  Last update from 1.1.1.1 01:02:10 ago  Routing Descriptor Blocks:  * 1.1.1.1 (default), from 8.8.8.8, 01:02:10 ago      Route metric is 0, traffic share count is 1      AS Hops 1      Route tag 65011      MPLS label: 10018      MPLS Flags: MPLS Required

Соответственно, РЕ4 генерирует PIM Join и отправляет его в рамках Default MDT:

Данный PIM Join будет получен всеми РЕ, но обработан только на РЕ1 (т.к. только на нём Join пройдет RPF проверку)

PE1#show ip mroute vrf C-ONE | b \((11.11.11.11, 230.1.1.1), 00:01:16/00:03:11, flags: sTIncoming interface: GigabitEthernet2.111, RPF nbr 172.1.11.11Outgoing interface list:Tunnel2, Forward/Sparse, 00:01:16/00:03:11

PE2#show ip mroute vrf C-ONE | b \(PE2#

Проверим работоспособность сервиса:

CE1#pingTarget IP address: 230.1.1.1Repeat count [1]: 5Extended commands [n]: yInterface [All]: GigabitEthernet2.111Source address or interface: 11.11.11.11Sending 5, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11Reply to request 0 from 14.14.14.14, 7 msReply to request 1 from 14.14.14.14, 7 msReply to request 2 from 14.14.14.14, 8 msReply to request 3 from 14.14.14.14, 8 msReply to request 4 from 14.14.14.14, 7 ms

Как видно, многоадресные пакеты корректно передаются через опорную сеть. При этом стоит отметить, что способ передачи пакетов ничем не отличается от того, что мы с Вами наблюдали в рамках Profile0. Т.е. пакеты долетают до всех РЕ в рамках Default MDT и уже там отбрасываются в случае отсутствия активных подписчиков.

В этом можно убедиться, сняв дамп трафика на сети как это показано на рисунке ниже (vlan id = 37 характеризует интерфейс между R3 и R7):

Выше мы рассмотрели случай использования PIM SSM внутри C-VRF. Изменится ли что-либо, если будет работать PIM ASM?

CE4(config-if)#interface Lo0CE4(config-if)#ip igmp version 2CE4(config-if)#no ip igmp join-group 230.1.1.1 source 11.11.11.11CE4(config-if)#ip igmp join-group 231.1.1.1!CE15(config)#no ip pim bsr-candidate Loopback0 0CE15(config)#no ip pim rp-candidate Loopback0!CE15(config)#access-list 1 permit 231.1.1.0 0.0.0.255CE15(config)#ip pim bsr-candidate Lo0CE15(config)#ip pim rp-candidate Lo0 group-list 1

На РЕ сайта появляется дополнительный туннельный интерфейс для PIM encap:

PE1#*Nov 24 21:39:32.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

Все маршрутизаторы внутри C-VRF корректно узнают о появившихся RP и BSR устройствах в сети:

CE1#show ip pim bsr-routerPIMv2 Bootstrap informationBSR address: 15.15.15.15 (?)Uptime:   00:01:54, BSR Priority: 0, Hash mask length: 0Expires:   00:01:16

До тех пор, пока нет активного источника трафика, внутри C-VRF будут наблюдаться только (*, G) маршруты согласно обычной логике работы PIM ASM:

PE4#show ip mroute vrf C-ONETimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 231.1.1.2), 00:00:46/00:02:43, RP 15.15.15.15, flags: SIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:46/00:02:43

При этом внутри BGP домена не появляется никаких дополнительных mvpn префиксов:

PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>i [1][1.1.1.1:1][1.1.1.1]/121.1.1.1         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1 (default for vrf C-ONE)*>i [1][4.4.4.4:1][1.1.1.1]/121.1.1.1         0  100   0 ?*>i [1][4.4.4.4:1][2.2.2.2]/12Network     Next Hop      Metric LocPrf Weight Path2.2.2.2         0  100   0 ?*>i [1][4.4.4.4:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>  [1][4.4.4.4:1][4.4.4.4]/12

Почему? спросите Вы? Потому что для сигнализации многоадресного трафика C-VRF используется протокол PIM.

О возможной замене сигнализации на BGP поговорим в следующий раз.

В предыдущих выпусках:

Profile 0
Profile 1
Profile 3

В этой части статьи мы рассмотрим с Вами вариант замены сигнализации в рамках наложенной сети с протокола PIM на BGP.

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



Зачем натягивать сову на глобус? можете спросить Вы, ведь всё прекрасно работает и с PIM. И, в общем-то, будете правы. Основной причиной эдакого ходя конём является масштабируемость. PIM, являясь по сути своей Soft Driven протоколом, требует для своей работы постоянной рассылки служебных сообщений, что при определённом размере внедрения (если количество узлов начинает переваливать за пару сотен или тысяч) привносит ограничения в связи с неизбежной загрузкой CPU. BGP же является Hard Driven протоколом т.е. если что-то было сказано однажды, то не повторяется; любые BGP обновления вызваны исключительно изменениями в сети.

Сегодня мы с Вами рассмотрим два сценария: использование PIM SSM и PIM ASM в рамках C-VRF.

C-PIM SSM

Для более простого понимания BGP сигнализации для построения многоадресных деревьев, начнём наш разговор с более простого PIM SSM.

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

CE4(config)#interface Loopback0CE4(config-if)#no ip igmp join-group 231.1.1.2CE4(config-if)#CE15(config)#no ip pim bsr-candidate Loopback0 0CE15(config)#no ip pim rp-candidate Loopback0 group-list 1

На всех РЕ укажем, что для сигнализации вместо PIM будет работать BGP. Это делается следующей командой:

ip vrf C-ONEmdt overlay use-bgp

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

PE1#show bgp ipv4 mvpn allBGP table version is 406, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Подключим получателя:

CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11

На ближайшем РЕ создаётся BGP маршрут 7-го типа это эквивалент сообщения PIM (S, G) Join:

PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>  [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/220.0.0.0              32768 ?

По логике вещей, данный маршрут должен присутствовать только на РЕ4 и на РЕ1 (т.к именно через них должен проходить трафик) и отсутствовать на РЕ2 и РЕ3. Проверим:

PE1#show bgp ipv4 mvpn all | b \[7\]*>i [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/224.4.4.4         0  100   0 ?PE2#show bgp ipv4 mvpn all | b \[7\]PE2#PE3#show bgp ipv4 mvpn all | b \[7\]PE3#

Как так получается, что маршрут, изначальной порождённый на РЕ4, импортируется только на РЕ1?

Посмотрим на запись в BGP-таблице чуть детальнее:

PE4#show bgp ipv4 mvpn all route-type 7 1.1.1.1:1 65001 11.11.11.11 230.1.1.1BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:7Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

В записи префикса присутствует расширенное коммьюнити Route-target = 1.1.1.1:1, которое было добавлено в vpnv4 префикс маршрутизатором, который с точки РЕ4 является RPF соседом:

PE1#show bgp vpnv4 unicast rd 1.1.1.1:1 11.11.11.11/32BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1     17Refresh Epoch 465011172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)Origin IGP, metric 0, localpref 100, valid, external, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1mpls labels in/out 10018/nolabelrx pathid: 0, tx pathid: 0x0PE1#PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 15265011, imported path from 1.1.1.1:1:11.11.11.11/32 (global)1.1.1.1 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10018rx pathid: 0, tx pathid: 0x0

Проверим связность:

CE1#ping 230.1.1.1 so 11.11.11.11 rep 3Type escape sequence to abort.Sending 3, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11Reply to request 0 from 14.14.14.14, 7 msReply to request 0 from 14.14.14.14, 8 msReply to request 1 from 14.14.14.14, 7 msReply to request 1 from 14.14.14.14, 9 msReply to request 2 from 14.14.14.14, 7 msReply to request 2 from 14.14.14.14, 7 ms

C-PIM ASM

В случае работы C-PIM в режиме SSM всё довольно просто. Для корректной работы mVPN достаточно создания двух дополнительных (типов) BGP маршрутов.

А как обстоят дела, если внутри C-VRF используется более комплексный ASM PIM?

Прежде всего мы видим, что на всех СЕ известна информация о точке рандеву:

CE2#show ip pim rp mappCE2#show ip pim rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 231.1.1.0/24RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 1d04h, expires: 00:02:09CE2#

Как? Если мы посмотрим BGP таблицу, то не найдём там никакого намёка на эту точку:

PE1#show bgp ipv4 mvpn allBGP table version is 682, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Не надо забывать о том, что у нас есть PMSTI, на котором активирован PIM:

PE1#show ip pim vrf C-ONE interfaceAddress     Interface        Ver/  Nbr  Query DR     DRMode  Count Intvl Prior172.1.11.1    GigabitEthernet2.111   v2/S  1   30   1     172.1.11.11172.1.15.1    GigabitEthernet2.115   v2/S  1   30   1     172.1.15.151.1.1.1     Tunnel2         v2/S  0   30   1     1.1.1.1

Отсюда можно сделать важный вывод некоторые сообщения PIM (даже при BGP сигнализации) передаются поверх опорной сети в рамках Default MDT.


Представим, что в сети появился источник (за маршрутизатором СЕ2). Поскольку на СЕ2 на данный момент нет записей в mRIB, то PIM Designated Router (в нашем случае это сам СЕ2) отправляет сообщение Register на точку рандеву, тем самым сигнализируя о наличии активного источника в сети.


На точке рандеву создаётся дерево (12.12.12.12, 231.1.1.1):

CE5#show ip mroute | b \((*, 231.1.1.1), 00:00:19/stopped, RP 15.15.15.15, flags: SPIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list: Null(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: PIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing interface list: Null

И, поскольку, в сети нет активных получателей трафика (отсутствует дерево (*, 231.1.1.1)), то со стороны CE5 создаётся сообщение Register-Stop



В ответ на получение Register-Stop, CE2 приостанавливает передачу данных (нет интерфейсов в OIL):

CE2#show ip mroute 231.1.1.1(12.12.12.12, 231.1.1.1), 00:00:07/00:02:54, flags: PFTIncoming interface: Loopback0, RPF nbr 0.0.0.0Outgoing interface list: Null

Теперь представим, что в сети появился получатель, заинтересованный в трафике для группы 231.1.1.1. На РЕ4 появляется маршрут внутри C-VRF:

PE4#show ip mroute vrf C-ONE 231.1.1.1 | b \((*, 231.1.1.1), 00:00:44/00:02:45, RP 15.15.15.15, flags: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:44/00:02:45

И создаётся BGP маршрут 6-го типа, который является эквивалентом PIM Join (*, 231.1.1.1):

PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>  [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/220.0.0.0              32768 ?PE4#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

В приведённом выше выводе необходимо обратить внимание на расширенное коммьюнити Route-target = 1.1.1.1:1. Что это и откуда взялось?

Проверим наличие данного префикса на других РЕ:

PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1% Network not in tablePE3#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1% Network not in tablePE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698Paths: (1 available, best #1, table MVPNv4-BGP-Table)Not advertised to any peerRefresh Epoch 2Local4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:1.1.1.1:1Originator: 4.4.4.4, Cluster list: 8.8.8.8rx pathid: 0, tx pathid: 0x0

Т.е. префикс существует только на РЕ1. Что интересно, так это тот факт, что точка рандеву (15.15.15.15) находится именно на сайте за РЕ1.

Зная назначение Route-target (импорт маршрутов внутрь определённой VRF) напрашивается вывод RT = 1.1.1.1:1 известен РЕ1 и неизвестен РЕ2/PE3. Т.е очевиден факт, что РЕ4 сгенерировал BGP маршрут, описывающий PIM Shared Tree Join таким образом, чтобы он был обработан только на том РЕ, за которым в действительности находится точка рандеву (по факту, это аналог передачи PIM Join через RPF интерфейс). Но каким образом РЕ1 и РЕ4 согласуют между собой значения Route-target?

PE4 проводит RPF для адреса точки рандеву:

PE4#show ip rpf vrf C-ONE 15.15.15.15RPF information for ? (15.15.15.15)RPF interface: Tunnel0RPF neighbor: ? (1.1.1.1)RPF route/mask: 15.15.15.15/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 1.1.1.1RPF topology: ipv4 multicast base, originated from ipv4 unicast base

В качестве RPF соседа виден РЕ1. Значит, РЕ4 должен поместить внутрь маршрута 6-го типа такой Route-target, который будет импортирован только РЕ1. Чтобы ответить на вопрос откуда РЕ4 его знает? посмотрим, для начала, на vpn маршрут:

PE4#show bgp vpnv4 unicast vrf C-ONE 15.15.15.15/32BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 165015, imported path from 1.1.1.1:1:15.15.15.15/32 (global)1.1.1.1 (metric 3) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10013rx pathid: 0, tx pathid: 0x0

Обратите внимание на дополнительное коммьюнити MVPN VRF:1.1.1.1:1. Это ничто иное, как коммьюнити Route Import, сгенерированное РЕ1. Именно это значение копируется как Route-target внутрь многоадресного маршрута, что позволяет РЕ1 импортировать полученный апдейт от РЕ4.

Результатом обработки BGP маршрут 6-го типа на РЕ4 является создание записи в многоадресной таблице маршрутизации:

PE4#show ip mroute vrf C-ONE(*, 231.1.1.1), 00:23:31/00:02:33, RP 15.15.15.15, flags: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:23:31/00:02:33

Прим обратите внимание, что входным интерфейсом указан Tunnel0 (PMSTI).

На точке рандеву завершается создание общего дерева:

CE5#show ip mroute | b \((*, 231.1.1.1), 00:25:42/00:03:22, RP 15.15.15.15, flags: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.115, Forward/Sparse, 00:25:42/00:03:22

Теперь, если в сети опять появится активный источник трафика, точка рандеву будет знать как совместить (*, 231.1.1.1) и (12.12.12.12, 231.1.1.1) деревья.

CE5#show ip mroute | b \((*, 231.1.1.1), 00:47:12/stopped, RP 15.15.15.15, flags: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.115, Forward/Sparse, 00:47:12/00:02:31(12.12.12.12, 231.1.1.1), 00:00:23/00:02:43, flags: PTIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing interface list: Null

Точка рандеву создаёт PIM Join (12.12.12.12, 231.1.1.1), отправляя его в сторону CE2. PE1 получает указанный PIM Join и создаёт BGP маршрут 7-го типа:

PE1#show bgp ipv4 mvpn allRoute Distinguisher: 2.2.2.2:1*>  [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/220.0.0.0              32768 ?PE1#show bgp ipv4 mvpn all route-type 7 2.2.2.2:1 65001 12.12.12.12 231.1.1.1BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (1.1.1.1)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:2.2.2.2:1rx pathid: 1, tx pathid: 0x0

Обратите внимание, что в качестве Remote VPN RD выставляется значение 2.2.2.2:1, т.к. именно через РЕ2 завершается RPF проверка маршрута:

PE1#show ip rpf vrf C-ONE 12.12.12.12RPF information for ? (12.12.12.12)RPF interface: Tunnel2RPF neighbor: ? (2.2.2.2)RPF route/mask: 12.12.12.12/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 2.2.2.2RPF topology: ipv4 multicast base, originated from ipv4 unicast base

И RT 2.2.2.2:1 был добавлен в VPNv4 префикс со стороны РЕ2:

PE1#show bgp vpnv4 unicast vrf C-ONE 12.12.12.12BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 265012, imported path from 2.2.2.2:1:12.12.12.12/32 (global)2.2.2.2 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1Originator: 2.2.2.2, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 2.2.2.2:1:2.2.2.2mpls labels in/out nolabel/31rx pathid: 0, tx pathid: 0x0

На этом шаге, по сути, завершается построение дерева (12.12.12.12, 231.1.1.1) на участке между источником и точкой рандеву:


После получения маршрута 7-го типа, РЕ2 генерирует маршрут 5-го типа, сигнализируя о наличии активного источника трафика в сети. Маршрут импортируется всеми РЕ устройствами.

PE2#show bgp ipv4 mvpn allRoute Distinguisher: 2.2.2.2:1 (default for vrf C-ONE)*>  [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/180.0.0.0              32768 ?PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (2.2.2.2)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestCommunity: no-exportExtended Community: RT:65001:1rx pathid: 0, tx pathid: 0x0

При получении маршрута 5-го типа, на РЕ4 (где находится получатель) завершается создание многоадресного дерева:

PE4#show ip mroute vrf C-ONE(12.12.12.12, 231.1.1.1), 00:22:24/00:02:51, flags: TnQIncoming interface: Tunnel0, RPF nbr 2.2.2.2Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19

Прим обратите внимание на флаг Q, который говорит о том, что запись была создана благодаря сообщению BGP Source-Active


Рассмотренный вариант организации mVPN носит кодовое имя Profile 11. Его основные характеристики:

• для передачи многоадресного трафика наложенной сети используется Default MDT
• в качестве метода организации транспорта выступает протокол mGRE
• для сигнализации многоадресного дерева в рамках наложенной сети используется протокол BGP

В предыдущих выпусках:

Profile 0
Profile 1
Profile 3
Profile 11

Как мы узнали из прошлых записей, в опорной сети при реализации mVPN всегда присутствует конструкция Default MDT, к которой подключены все РЕ маршрутизаторы. В рамках данного MDT передаются служебные сообщения PIM (например Bootstrap, Auto-RP), а также пользовательский многоадресный трафик. В результате получается, что какие-то РЕ устройства получают даже тот трафик, на который они не подписывались.

Если хотите узнать как с этим бороться добро пожаловать под кат!



Для того чтобы повысить эффективность передачи данных используется дополнительная конструкция, которая именуется как Data MDT. Идея, которая лежит в её основе, заключается в следующем:

• В рамках дерева распространяется только C-(S, G) трафик
• Участниками дерева становятся только те Egress PE, у которых есть заинтересованные получатели
• Корневым устройством Data MDT является Ingress PE (маршрутизатор, за которым находится источник)

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



Если представить ситуацию, в которой источник начинает вещать на вторую многоадресную группу (230.1.1.2), получатели для которой находятся только за РЕ2 и РЕ3, то создаётся дополнительное Data MDT и общая картинка приобретает вид (Default MDT опущено):



Сигнализация по переключению трафика от Default MDT к Data MDT осуществляется исключительно по-требованию при превышении заданного порога со стороны Ingress PE либо средствами PIM, либо средствами BGP.

Data MDT с помощью PIM

Если для сигнализации используется PIM, то ingress PE генерирует специальное сообщение PIM Data-MDT TLV и отправляет его в рамках Default MDT чтобы быть уверенным в том, что все РЕ смогут получить данное сообщение. Одновременно с отправкой Data MDT TLV, Ingress PE запускает таймер, равный трём секундам. По истечении таймера, все пакеты будут передаваться в рамках Data MDT.

Также необходимо отметить тот факт, что информация, содержащаяся в Data-MDT TLV кешируется на всех РЕ. Причина тому довольно банальна даже если в текущий момент на конкретном РЕ нет заинтересованных получателей трафика, они могут появиться там спустя некоторое время. Соответственно, при получении PIM Join (внутри C-VRF) PE может моментально подключиться к уже существующему на сети Data MDT.

Прим. Data-MDT TLV передаются раз в минуту.

Каждое Data MDT устанавливается для отдельного (S, G) маршрута в рамках VPN/VRF. Администратору необходимо явно указать максимальное количество Data MDT, которое может быть создано на устройстве. Если в какой-то момент количество вновь устанавливаемых деревьев достигает заданного предела, то следующие деревья будут переиспользовать уже установленные.

Прим. На момент написания статьи, Cisco IOS не поддерживает PIM сигнализацию поверх Data MDT. Все профили с данной сигнализацией доступны только на операционной системе IOS XR.

Data MDT с помощью BGP

При использовании BGP в наложенной сети для сигнализации Data MDT, основные принципы остаются неизменными (по сравнению с PIM):

• ingress PE сигнализирует всем РЕ о том, что трафик для C-(S,G) будет передаваться в рамках Data MDT
• egress PE при получении BGP апдейта присоединяется к указанному дереву
• для сигнализации используется адресное семейство mVPN (sAFI 129).

Получается, что Ingress PE должен сформировать специальное BGP Update сообщение и отправить его всем РЕ в рамках mVPN. Для этого используется маршрут третьего типа.

Profile 14

Рассмотрим описанный переход на примере нашей лаборатории. В частности, применим конфигурацию, известную как Profile 14. Данный профиль характеризуется использованием BGP mVPN A-D для построения P2MP MLDP LSP.

На РЕ будем использовать следующий шаблон конфигурации:

ip vrf C-ONE
mdt auto-discovery mldp
mdt partitioned mldp p2mp
mdt overlay use-bgp
mdt strict-rpf interface
!
router bgp 1
address-family ipv4 mvpn
neighbor 8.8.8.8 activate
neighbor 8.8.8.8 send-community extended
exit-address-family

Прим. о предназначении команды mdt strict-rpf interface поговорим в следующем выпуске.

Auto-Discovery

Посмотрим, что происходит на РЕ1:

На каждом РЕ создаётся интерфейс Lspvif0, на котором активируется C-PIM.

*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up

Никаких соседей на данный момент нет:

PE1#show ip pim vrf C-ONE intAddress     Interface        Ver/  Nbr  Query DR     DRMode  Count Intvl Prior172.1.11.1    GigabitEthernet2.111   v2/S  1   30   1     172.1.11.11172.1.15.1    GigabitEthernet2.115   v2/S  1   30   1     172.1.15.151.1.1.1     Lspvif0         v2/S  0   30   1     1.1.1.1

Посмотрим BGP таблицу:

PE1#show bgp ipv4 mvpn allBGP table version is 39, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [3][1.1.1.1:1][*][*][1.1.1.1]/140.0.0.0              32768 ?*>i [3][1.1.1.1:1][*][*][2.2.2.2]/142.2.2.2         0  100   0 ?*>i [3][1.1.1.1:1][*][*][3.3.3.3]/143.3.3.3         0  100   0 ?*>i [3][1.1.1.1:1][*][*][4.4.4.4]/144.4.4.4         0  100   0 ?*>  [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/180.0.0.0              32768 ?Route Distinguisher: 2.2.2.2:1*>i [3][2.2.2.2:1][*][*][2.2.2.2]/142.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1*>i [3][3.3.3.3:1][*][*][3.3.3.3]/143.3.3.3         0  100   0 ?Network     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 4.4.4.4:1*>i [3][4.4.4.4:1][*][*][4.4.4.4]/144.4.4.4         0  100   0 ?

Как видно, в дополнение к уже рассмотренным ранее маршрутам первого типа, добавляются маршруты третьего типа S-PMSI A-D, которые используются для объявления РЕ в качестве Ingress маршрутизатора для конкретной C-(S,G) группы. На текущий момент группа равна (*, *). Это говорит о желании РЕ участвовать в построении Partitioned MDT.

Очевидно, чтобы заработала передача данных, в рамках VRF должна быть известна информация о точке рандеву. В нашем случае в качестве RP и BSR выступает CE15.

C-RP#sh run | i pimip pim bsr-candidate Loopback0 0ip pim rp-candidate Loopback0

Поскольку у C-RP построено PIM соседство с PE1, то на этом РЕ1 информация об RP также известна:

PE1#show ip pim vrf C-ONE rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 224.0.0.0/4RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 01:25:50, expires: 00:01:26

Необходимо доставить эту информацию до всех остальных PE/CE. Как это сделать? Чтобы лучше понять принцип, предлагаю пойти от обратного и начать просмотра уже известной информации на СЕ2:

CE2#show ip pim rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 224.0.0.0/4RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 01:27:54, expires: 00:02:26

Как видим, сообщения PIM BSR распространилось по mVPN инфраструктуре. Посмотрим дамп трафика на РЕ1:


Как видим PE1 инкапсулирует сообщение PIM BSR внутрь MPLS и помечает его меткой 28. Откуда она берётся? Можем предположить, что поскольку этот пакет достиг СЕ2 (а значит и РЕ2), то есть некий LSP до РЕ2.

PE2#show mpls mldp database* For interface indicates MLDP recursive forwarding is enabled* For RPF-ID indicates wildcard value> Indicates it is a Primary MLDP MDT BranchLSM ID : 1  Type: P2MP  Uptime : 04:17:40FEC Root      : 2.2.2.2 (we are the root)Opaque decoded   : [gid 65536 (0x00010000)]Opaque length   : 4 bytesOpaque value    : 01 0004 00010000Upstream client(s) :NoneExpires    : N/A      Path Set ID : 1Replication client(s):>  MDT (VRF C-ONE)Uptime     : 04:17:40   Path Set ID : NoneInterface   : Lspvif0    RPF-ID    : *LSM ID : 3  Type: P2MP  Uptime : 01:30:06FEC Root      : 1.1.1.1Opaque decoded   : [gid 131071 (0x0001FFFF)]Opaque length   : 4 bytesOpaque value    : 01 0004 0001FFFFUpstream client(s) :6.6.6.6:0  [Active]Expires    : Never     Path Set ID : 3Out Label (U) : None     Interface  : GigabitEthernet2.26*Local Label (D): 34      Next Hop   : 10.2.6.6Replication client(s):MDT (VRF C-ONE)Uptime     : 01:30:06   Path Set ID : NoneInterface   : Lspvif0    RPF-ID    : *

Из анализа базы mLDP видно, что на РЕ2 есть некое дерево (LSM ID: 3), корнем которого является PE1 (IP = 1.1.1.1), Opaque = 01 0004 0001FFFF и для этого дерева сгенерирована локальная метка 34, которая отправлена соседу R6 (P2).

Откуда РЕ2 узнал о дереве, корнем которого является PE1 да ещё и получил Opaque для него? Ответ прост с помощью BGP маршрута третьего типа.

Когда РЕ1 получил PIM BSR, то сгенерировал дополнительный BGP маршрут, который описывает группу (*, 224.0.0.13) (напоминаю, что это зарезервированный адрес для рассылки всех служебных PIM сообщений). Этот маршрут служит для объявления нового многоадресного mLDP дерева. Внутри РТА указано Opaque значение, которое необходимо использовать для сигнализации посредством mLDP.

PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Advertised to update-groups:1Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (1.1.1.1)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestCommunity: no-exportExtended Community: RT:65001:1PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FFrx pathid: 0, tx pathid: 0x0

Таким образом, РЕ2 импортируя этот маршрут, может начать mLDP сигнализацию в сторону РЕ1 для дерева (*, 224.0.0.13). Для полученной от РЕ2 метки, Р2 (R6) генерирует свой собственную локальную (29) и отправляет её в сторону P1 (R5):

P2#show mpls mldp database* For interface indicates MLDP recursive forwarding is enabled* For RPF-ID indicates wildcard value> Indicates it is a Primary MLDP MDT BranchLSM ID : 2  Type: P2MP  Uptime : 01:40:24FEC Root      : 1.1.1.1Opaque decoded   : [gid 131071 (0x0001FFFF)]Opaque length   : 4 bytesOpaque value    : 01 0004 0001FFFFUpstream client(s) :5.5.5.5:0  [Active]Expires    : Never     Path Set ID : 2Out Label (U) : None     Interface  : GigabitEthernet2.56*Local Label (D): 29      Next Hop   : 10.5.6.5Replication client(s):2.2.2.2:0Uptime     : 01:40:24   Path Set ID : NoneOut label (D) : 34      Interface  : GigabitEthernet2.26*Local label (U): None     Next Hop   : 10.2.6.2

Аналогичным образом поступает и Р1 (R5), генерируя свою локальную метку для дерева и отправляя её к РЕ1:

P1#show mpls mldp database* For interface indicates MLDP recursive forwarding is enabled* For RPF-ID indicates wildcard value> Indicates it is a Primary MLDP MDT BranchLSM ID : 2  Type: P2MP  Uptime : 01:41:24FEC Root      : 1.1.1.1Opaque decoded   : [gid 131071 (0x0001FFFF)]Opaque length   : 4 bytesOpaque value    : 01 0004 0001FFFFUpstream client(s) :1.1.1.1:0  [Active]Expires    : Never     Path Set ID : 2Out Label (U) : None     Interface  : GigabitEthernet2.15*Local Label (D): 28      Next Hop   : 10.1.5.1Replication client(s):4.4.4.4:0Uptime     : 01:41:24   Path Set ID : NoneOut label (D) : 34      Interface  : GigabitEthernet2.45*Local label (U): None     Next Hop   : 10.4.5.47.7.7.7:0Uptime     : 01:41:24   Path Set ID : NoneOut label (D) : 30      Interface  : GigabitEthernet2.57*Local label (U): None     Next Hop   : 10.5.7.76.6.6.6:0Uptime     : 01:41:24   Path Set ID : NoneOut label (D) : 29      Interface  : GigabitEthernet2.56*Local label (U): None     Next Hop   : 10.5.6.6

Визуально весь процесс представлен на рисунке ниже:

Присоединение к Shared Tree и построение корневого P2MP дерева (ROOT = RP-PE)

Шаг 2. В сети появляется получатель трафика. После того как Egress PE (РЕ2) получает PIM Join от CE для C-(*, G), PE2 производит RPF проверку чтобы найти BGP Next-Hop в сторону C-RP. Найденный Next-Hop (1.1.1.1) будет использоваться как Partitioned MDT ROOT для mLDP.

Дополнительно РЕ2 создаёт интерфейс Lspvif внутри C-VRF:

PE2#*Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to upPE2#*Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1

Шаг 3. Egress PE (PE2) генерирует сообщение mLDP mapping в сторону RP-PE (ROOT P2MP MDT) используя Opaque значение из BGP апдейта.

PE2#show mpls mldp database summaryLSM ID   Type  Root       Decoded Opaque Value     Client Cnt.4     P2MP  1.1.1.1      [gid 65536 (0x00010000)]   11     P2MP  2.2.2.2      [gid 65536 (0x00010000)]   13     P2MP  1.1.1.1      [gid 131071 (0x0001FFFF)]   1PE2#PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detailI-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI* - Indicates Wildcard source or group address[S-PMSI][1.1.1.1:1][*][*][1.1.1.1], JoinedOrig: Remote Uptime: 04:44:27 Type: MLDP P2MPRoot: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000)[S-PMSI][3.3.3.3:1][*][*][3.3.3.3],Orig: Remote Uptime: 04:44:22 Type: MLDP P2MPRoot: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000)[S-PMSI][4.4.4.4:1][*][*][4.4.4.4],Orig: Remote Uptime: 04:44:20 Type: MLDP P2MPRoot: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000)[S-PMSI][2.2.2.2:1][*][*][2.2.2.2], JoinedOrig: Local Uptime: 04:44:24 Type: MLDP P2MPRoot: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000)PE2#show mpls mldp database opaque_type gid 65536LSM ID : 4  Type: P2MP  Uptime : 00:03:43FEC Root      : 1.1.1.1Opaque decoded   : [gid 65536 (0x00010000)]Opaque length   : 4 bytesOpaque value    : 01 0004 00010000Upstream client(s) :6.6.6.6:0  [Active]Expires    : Never     Path Set ID : 4Out Label (U) : None     Interface  : GigabitEthernet2.26*Local Label (D): 35      Next Hop   : 10.2.6.6Replication client(s):MDT (VRF C-ONE)Uptime     : 00:03:43   Path Set ID : NoneInterface   : Lspvif1    RPF-ID    : 0x1

Шаг 4. Egress PE генерирует BGP маршрут шестого типа (присоединение к Shared Tree в сторону RP-PE). Данный маршрут импортируется только на RP-PE.

PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:1Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (2.2.2.2)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

Шаг 5. RP-PE транслирует полученный BGP маршрут шестого типа в PIM Join в сторону RP. На этот момент RP готово к отправке многоадресного трафика в сторону Egress PE. Необходимо доставить трафик от источника до RP.

PE1#show ip mroute vrf C-ONE | b \((*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SGIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15Outgoing interface list:Lspvif0, Forward/Sparse, 00:07:08/stopped

Шаг 6. Когда S-PE (PE4) получает первый многоадресный пакет от источника (CE4), трафик инкапсулируется внутрь сообщения PIM Register и отправляется как одноадресный пакет в сторону C-RP (используя обычные правила MPLS L3 VPN).

Шаг 7. После получения PIM Register, C-RP начинает процесс построения дерева С-(14.14.14.14, 230.1.1.1). RP-PE получает PIM Join для C-(14.14.14.14, 230.1.1.1) от C-RP. Данное сообщение транслируется в BGP маршрут седьмого типа. Однако, перед отправкой в сторону источника, необходимо построить новое дерево Partitioned MDT с РЕ в качестве ROOT.


Шаг 8. RP-PE производит RPF проверку чтобы найти BGP Next-Hop в сторону источника. Данный адрес будет использоваться как Partitioned MDT ROOT для mLDP.

Шаг 9. Используя полученный BGP Next-Hop и BGP маршрут третьего типа от Ingress PE, RP-PR генерирует сообщение mLDP mapping в сторону IP адреса Ingress PE, тем самым строя корневое P2MP дерево до Ingress PE.

Шаг 10. RP-PE отправляет BGP маршрут седьмого типа (Join от RP) в сторону Ingress PE.

Шаг 11. Ingress PE преобразует полученный BGP маршрут седьмого типа в PIM Join и отправляет его в сторону источника трафика.

Присоединение к Source Tree и построение P2MP (ROOT = S-PE)

Шаг 12. Ingress PE также отправляет BGP маршрут пятого типа ко всем mVPN PE, тем самым информируя их о наличии активного источника в сети. Данный маршрут является триггером для переключения к SPT дереву.

Шаг 13. Egress PE использует полученный BGP маршрут пятого типа для генерации сообщения mLDP mapping в сторону Ingress PE (информация о MDT берётся из BGP маршрута третьего типа).


Таким образом теперь трафик может быть перенаправлен оптимальным путём от источника к получателю, используя mpls (mLDP) метки.