Theoretical foundations and architecture
Lab: delivering an IPTV channel across an MPLS core inside the customer VRF A with NG-MVPN and mLDP P2MP. The source 192.168.10.10 sits behind PE1 and the receivers 192.168.20.10 and 192.168.30.10 behind PE2 and PE3; the channel 232.1.1.1 belongs to the SSM range, so no RP is needed. You will configure the mvpn family on the PEs and the RR, mLDP as the PMSI tunnel, and IGMPv3 and PIM on the customer interfaces, and then check the whole chain: the Type 1 and Type 7 BGP routes, PIM and IGMP in the VRF, the mLDP database on the root, the branch and the leaves, the VRF multicast table and the data-plane counters. The second part consists of two negative tests: an RPF failure caused by a missing unicast route to the source and a missing PMSI caused by an inactive mvpn family. The goal is to learn to identify the faulty layer with a minimal set of commands and to restore the network.
Lab goal and topology
The lab ties together the three lessons of the module: PE1 is the root of the P2MP LSP, PE2 and PE3 are the leaves, P1 is the transit branching node and the RR 10.255.0.100 carries the routes of the mvpn family. The IPTV source 192.168.10.10 is attached to VRF A on PE1, the receivers 192.168.20.10 and 192.168.30.10 to VRF A on PE2 and PE3. The channel (192.168.10.10,232.1.1.1) from the SSM range 232/8 needs no RP, so only Type 1 (auto-discovery), Type 7 (join) and mLDP are required. The profile is "BGP-AD + BGP c-multicast + mLDP P2MP": PIM remains only on the customer side and there are no PIM neighbours between the PEs.
Order of work
First make sure the baseline works: the IGP, LDP to the loopbacks of all PEs, the vpnv4 sessions and unicast reachability between the VRF A sites (a ping from the VRF between PE1 and PE2). Then add the mvpn family on the PEs and the RR: without it there is no Type 1. Then configure VRF A: mLDP as the tunnel, BGP as the signalling. Only after that attach customer PIM and IGMPv3. This order localises faults: if Type 1 exists but the tree does not, the problem is in LDP; if Type 7 is missing, it is in membership or RPF.
Layered verification
- BGP control plane: the mvpn sessions are Established and every PE sees the Type 1 of every other PE. 2) Customer membership: an IGMP group on the receiver interface, PIM enabled on the source and receiver interfaces. 3) RPF: a route to the source exists in the VRF and leads to PE1; for the VRF on PE2
show ip rpf vrf Amust show the next hop 10.255.0.1. 4) C-multicast: the Type 7 is present on PE1 (and on the RR if there are no filters). 5) The tunnel: the mLDP database on PE2/PE3 contains the root PE1, and on P1 a branch with two downstream clients. 6) Forwarding: the incoming interface of (S,G) on a leaf is the tunnel's virtual interface (Lspvif on IOS-XE, lsi on Junos) and the counters grow. If step N fails, checking the steps after it is pointless.
How NG-MVPN differs from Rosen in the lab
There is no GRE and there are no PIM neighbours between PEs: show ip pim vrf A neighbor on a PE is empty where there is no CE, and no (PE,G) state appears in the core. The overhead is one mLDP label (4 bytes) rather than 24 bytes of GRE, so 1500-byte customer packets pass at the same link MTU as VPN-labelled packets. A typical IPTV packet carries 7 MPEG-TS cells (1316 bytes) in UDP, so there is MTU headroom, but it should still be checked. The TTL of the customer packet is decremented on the PE, not on the P.
Negative tests
Test 1 - RPF failure: on PE1 remove redistribute connected from address-family ipv4 vrf A, or import a different RT on PE2. PE2 then has no VPNv4 route to 192.168.10.0/24, show ip rpf vrf A 192.168.10.10 reports that no route exists, PE2 cannot determine the upstream PE and does not create a Type 7; the receiver sends IGMP but the flow does not arrive. Test 2 - a missing PMSI: on PE1 remove neighbor 10.255.0.100 activate in address-family ipv4 mvpn. The other PEs stop seeing the Type 1 from PE1 and have no information about the tunnel and the root; the RPF works (the VPNv4 route exists) but there is no incoming tunnel and the mLDP tree is not built. The difference matters: in the first case the unicast foundation is broken, in the second the multicast discovery is broken while unicast is healthy.
Recovery and operations
After the tests restore the configuration and make sure the Type 1/7 routes have returned and the tree has been rebuilt. If a branch has ECMP, mLDP selects one of the paths (by different rules on different implementations), so use the counters on the relevant link instead of assumptions. For heavy channels consider a selective tunnel so that receivers do not take foreign flows. For monitoring, combine the number of Type 1 routes per PE (it should equal the number of PEs minus one), the number of Type 7 routes and the state of mLDP. Typical lab mistakes: a missing send-community extended on the RR, an LDP binding filter, IGMPv2 on the host instead of IGMPv3 for SSM, MTU and a forgotten ip multicast-routing vrf A.
Success criteria
The receivers on PE2 and PE3 receive the flow 232.1.1.1; the mLDP database on PE1 shows one root LSP with two leaves; P1 shows a branch; when PE3 is shut down or one receiver leaves, the flow for PE2 is not interrupted; in the negative tests you can name the faulty layer from the output of one or two commands.
Architecture Diagram & Topology
[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)Traffic Flow & Label Stack Scheme
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.