Теоретические основы и архитектура

Лабораторная работа: доставка IPTV-канала через MPLS-ядро в клиентской VRF A с помощью NG-MVPN и mLDP P2MP. Источник 192.168.10.10 находится за PE1, получатели 192.168.20.10 и 192.168.30.10 - за PE2 и PE3; канал 232.1.1.1 относится к диапазону SSM, поэтому RP не нужен. Вы настроите семейство mvpn на PE и RR, mLDP как туннель PMSI, IGMPv3 и PIM на клиентских интерфейсах, а затем проверите всю цепочку: BGP-маршруты Type 1 и Type 7, PIM и IGMP в VRF, базу mLDP на корне, ветвлении и листьях, multicast-таблицу VRF и счётчики в плоскости данных. Вторая часть - два негативных теста: RPF failure из-за отсутствия юникастного маршрута к источнику и отсутствие PMSI из-за неактивного семейства mvpn. Цель - научиться определять неисправный уровень по минимальному набору команд и восстанавливать работу сети.

Цель лаборатории и схема

Лабораторная связывает три урока модуля: PE1 выступает корнем P2MP LSP, PE2 и PE3 - листьями, P1 - транзитным узлом ветвления, RR 10.255.0.100 передаёт маршруты семейства mvpn. Источник IPTV 192.168.10.10 подключён к VRF A на PE1, получатели 192.168.20.10 и 192.168.30.10 - к VRF A на PE2 и PE3. Канал (192.168.10.10,232.1.1.1) из диапазона SSM 232/8 не требует RP, поэтому нужны только Type 1 (автообнаружение), Type 7 (join) и mLDP. Профиль «BGP-AD + BGP c-multicast + mLDP P2MP»: PIM остаётся только на стороне клиента, между PE PIM-соседей нет.

Порядок работы

Сначала убедитесь, что базовая сеть работает: IGP, LDP до loopback всех PE, vpnv4 сессии и юникастная доступность между сайтами VRF A (пинг из VRF между PE1 и PE2). Затем добавьте семейство mvpn на PE и RR: без него нет Type 1. Затем настройте VRF A: mLDP как туннель, BGP как сигнализацию. И только потом подключайте клиентский PIM и IGMPv3. Такой порядок позволяет локализовать неисправность: если Type 1 есть, а дерева нет, проблема в LDP; если Type 7 нет - в членстве или RPF.

Многоуровневая проверка

  1. Control plane BGP: сессии mvpn Established, Type 1 каждого PE на каждом PE. 2) Членство клиента: IGMP-группа на интерфейсе получателя, PIM включён на интерфейсе источника и получателей. 3) RPF: маршрут к источнику есть в VRF и ведёт к PE1; для VRF PE2 show ip rpf vrf A должен показать next hop 10.255.0.1. 4) C-multicast: Type 7 присутствует на PE1 (и на RR, если нет фильтров). 5) Туннель: mLDP database на PE2/PE3 содержит корень PE1, на P1 - ветвление с двумя нижестоящими клиентами. 6) Forwarding: входной интерфейс (S,G) на листе - виртуальный интерфейс туннеля (Lspvif на IOS-XE, lsi на Junos), счётчики растут. Если шаг N не выполняется, шаги после него проверять бессмысленно.

Что отличает NG-MVPN от Rosen в лаборатории

Нет GRE и нет PIM-соседей между PE: show ip pim vrf A neighbor на PE пуст там, где нет CE, а в ядре не создаётся (PE,G). Накладные расходы - одна метка mLDP (4 байта), а не 24 байта GRE, поэтому клиентские пакеты по 1500 байт проходят при том же MTU на звене, на каком проходят метки VPN. Для IPTV типичный пакет содержит 7 кадров MPEG-TS (1316 байт) в UDP, так что запас по MTU есть, но проверять его нужно. TTL клиентского пакета уменьшается на PE, а не на P.

Негативные тесты

Тест 1 - RPF failure: уберите на PE1 redistribute connected из address-family ipv4 vrf A или импортируйте другой RT на PE2. Тогда PE2 не имеет VPNv4-маршрута к 192.168.10.0/24, show ip rpf vrf A 192.168.10.10 сообщает об отсутствии маршрута, PE2 не может определить upstream PE и не создаёт Type 7; получатель отправляет IGMP, но поток не приходит. Тест 2 - отсутствие PMSI: на PE1 отключите neighbor 10.255.0.100 activate в address-family ipv4 mvpn. Другие PE перестают видеть Type 1 от PE1, у них нет данных о туннеле и корне; RPF работает (VPNv4-маршрут есть), но входного туннеля нет, и mLDP-дерево не строится. Разница важна: в первом случае сломано юникастное основание, во втором - multicast-обнаружение при исправном юникасте.

Восстановление и эксплуатация

После тестов восстановите конфигурацию и убедитесь, что Type 1/7 вернулись, а дерево перестроилось. Если на ветке есть ECMP, mLDP выбирает один из путей (на разных реализациях по разным правилам), поэтому используйте счётчики на нужном линке, а не предположения. Для мощных каналов подумайте о selective туннеле, чтобы получатели не принимали чужие потоки. Для мониторинга сводите вместе число Type 1 на PE (должно равняться числу PE минус один), число Type 7 и состояние mLDP. Типичные ошибки лаборатории: отсутствие send-community extended на RR, фильтр LDP-привязок, IGMPv2 на хосте вместо IGMPv3 для SSM, MTU и забытый ip multicast-routing vrf A.

Критерии успеха

Получатели на PE2 и PE3 принимают поток 232.1.1.1; в mLDP database на PE1 один корневой LSP с двумя листьями; P1 показывает ветвление; при выключении PE3 или потере одного из получателей поток для PE2 не прерывается; в негативных тестах вы можете назвать неисправный уровень по выводам одной-двух команд.

Схема архитектуры и топология

text
[IPTV source 192.168.10.10]--Gi2--PE1--Gi1--(10.0.11.0/30)--P1--(10.0.12.0/30)--PE2--Gi2--[Rx 192.168.20.10]
 VRF A, SSM channel 232.1.1.1    10.255.0.1       10.255.0.11   |                  10.255.0.2
                                                                +--(10.0.13.0/30)--PE3--Gi2--[Rx 192.168.30.10]
                                                                |                  10.255.0.3
                                                                +--(10.0.100.0/30)--RR 10.255.0.100 (AS 65000)
Existing: IGP + LDP in the core, MP-BGP vpnv4 PE <-> RR, VRF A (RD 65000:<n>, RT 65000:100)
Added:    BGP address family mvpn (AFI 1 / SAFI 5), mLDP P2MP tunnel, IGMPv3 + PIM on the customer interfaces
Test 1:   RPF failure  - PE2 has no VPNv4 route to 192.168.10.0/24
Test 2:   missing PMSI - PE1 does not originate the Type 1 route (mvpn family down)

Схема прохождения трафика и стек меток

text
1. Verify the baseline: IGP, LDP, vpnv4 sessions and VRF A unicast reachability between PE1, PE2 and PE3.
2. Enable the mvpn address family on PE1, PE2, PE3 and the RR; configure the mLDP P2MP tunnel in VRF A.
3. Check Type 1 routes: every PE must see the Type 1 of the other two PEs with the PMSI Tunnel attribute.
4. Start the IPTV source; a receiver behind PE2 sends an IGMPv3 report for (192.168.10.10, 232.1.1.1).
5. Check Type 7 on PE1, the mLDP database on P1 and PE2, the VRF mroute and the packet counters.
6. Add the receiver behind PE3: the P2MP LSP gets a second leaf and P1 replicates.
7. Negative test 1: remove the unicast route to the source; observe the RPF failure and the missing Type 7.
8. Negative test 2: shut the mvpn session on PE1; observe the missing Type 1 and no tunnel; then restore.

Таблица состояний и параметров