The architecture chapter promised isolation without core state; this one shows the machinery keeping the promise. It has two halves, control and data, and the exam-grade skill — the outage-grade skill — is narrating both without notes.
Control plane: one route's journey
A CE at site 2 advertises 172.16.2.0/24 to PE2 by eBGP. PE2 installs it in VRF CUST-A, then re-originates it into MP-BGP's VPNv4 address family: prefix 65000:101:172.16.2.0/24, next hop PE2's loopback, extended community RT 65000:101 attached — and one more attribute that makes forwarding possible: a VPN label (say 30), allocated by PE2, meaning 'whatever arrives under this label belongs to CUST-A'. The route crosses the iBGP mesh — in practice via VPNv4 route reflectors — to PE1. PE1 checks the RT against its VRFs' import lists, accepts the route into CUST-A, strips the RD, and advertises plain 172.16.2.0/24 to its CE. Neither the RD, the RT, the VPN label nor MP-BGP itself ever touched a P router.
PE1(config)# router bgp 65000PE1(config-router)# neighbor 10.255.1.4 remote-as 65000PE1(config-router)# neighbor 10.255.1.4 update-source loopback0PE1(config-router)# address-family vpnv4PE1(config-router-af)# neighbor 10.255.1.4 activatePE1(config-router-af)# neighbor 10.255.1.4 send-community extendedPE1(config-router)# address-family ipv4 vrf CUST-APE1(config-router-af)# neighbor 192.168.1.2 remote-as 65101
Data plane: two labels, one story
A packet for 172.16.2.9 arrives at PE1 on the CUST-A interface. Lookup in the CUST-A FIB: route via PE2's loopback, VPN label 30. PE1 pushes label 30, then pushes the LDP transport label for PE2's loopback (24007) on top, and forwards. The core swaps the top label hop by hop — 24007, 24012 — while label 30 rides untouched beneath. The penultimate P router pops the transport label (PHP), so the packet reaches PE2 leading with exactly label 30; PE2's LFIB says 'label 30 = CUST-A', pops it, routes 172.16.2.9 in the customer table, and delivers to the CE. Isolation held at every hop: the core never read an address, and the only router that interpreted the VPN label is the router that allocated it.
PE1# show bgp vpnv4 unicast vrf CUST-A 172.16.2.0/24 ... 10.255.1.4 (metric 30) from 10.255.1.4 (10.255.1.4) Extended Community: RT:65000:101 mpls labels in/out nolabel/30PE1# show ip cef vrf CUST-A 172.16.2.0/24 detail ... labels imposed {24007 30}
Where it breaks, in order of likelihood
- RT mismatch — route reaches PE1's BGP but not the VRF: export list on one side does not intersect import list on the other. Check with show bgp vpnv4 unicast all 172.16.2.0/24 versus the VRF view.
- send-community extended missing — RTs stripped in flight; the route arrives naked and imports nowhere. Silent and classic.
- Broken transport LSP — control plane perfect, data blackholed: the two-label stack falls apart if LDP has a gap (the previous book's verification chapter is the drill; ping mpls tells the truth).
- Next-hop not /32 — PE loopback advertised with a mask that desynchronises the FEC, so the VPN label rides an LSP that terminates early.
- PE-CE routing issues — the mundane majority: eBGP session down, wrong AS, missing address-family activation under the VRF.
Verification mirrors the journey: VRF table on both PEs, VPNv4 table with labels, CEF's imposed label stack, and an MPLS ping between PE loopbacks. Run the narration forward for routes and backward for packets and any L3VPN fault localises in minutes — the skill the SPVI course drills until it is reflex.