VPRN Route-Target Asymmetry After Adding a Third Site
A service provider runs a VPRN (IP VPN) service for a retail customer across three PE routers: PE1, PE2, and PE3. PE1 and PE2 already exchange the customer's prefixes correctly. PE3 was added last week. Its VRF is configured with vrf-import target 65000:100 and vrf-export target 65000:300. PE1 and PE2 both use vrf-import 65000:200 and vrf-export 65000:100. MP-BGP is established between all PEs. On PE3, the customer's connected prefix 10.40.30.0/24 is present, and PE3 receives the other sites' prefixes. However, the other sites do not receive 10.40.30.0/24, and a traceroute from PE1 to 10.40.30.1 stops at the PE1 VRF. The customer's CE at PE3 can ping its local gateway but not the remote sites. No ACLs or filters are configured.
1. Diagnose the control-plane fault. Which side is asymmetric, and what evidence supports it?
Read the worked answer
The asymmetry is on the export side of PE3. PE3 imports 65000:100, and PE1/PE2 export 65000:100, so PE3 receives remote prefixes. PE1/PE2 import 65000:200, but PE3 exports 65000:300, so PE1/PE2 reject PE3's VPN-IPv4 route. Route targets are extended communities attached to MP-BGP VPN-IPv4 routes, not to the CE prefix itself. Evidence: PE3 has remote routes, while PE1 lacks 10.40.30.0/24. The data plane then fails because there is no matching VRF route on PE1. This is a control-plane import/export mismatch, not a forwarding or ACL problem.
2. Give the minimal configuration change and a verification sequence.
Read the worked answer
Set PE3 vrf-export to 65000:100, or add 65000:100 as an additional export target. Then check MP-BGP: on PE3, the local 10.40.30.0/24 should be advertised as VPN-IPv4 with RT 65000:100. On PE1, show router bgp routes vpn-ipv4 should show it with the matching RT, and the VRF route-table should install it. Also verify the import policy is not dropping it and that the next-hop is reachable. No data-plane change is needed. If multiple RTs are used, confirm that both import and export lists match on all PEs.
3. If the customer later requires all inter-site traffic to pass a hub firewall at PE1, how would you change the RT design without causing a loop?
Read the worked answer
Use hub-and-spoke RTs. Define hub RT 65000:999. PE2 and PE3 export spoke RT 65000:100 and import only 65000:999. PE1 imports 65000:100 and exports 65000:999. That forces PE2-to-PE1 and PE3-to-PE1 traffic through the hub, and PE1 forwards it. Do not let PE2/PE3 import 65000:100 directly, or they bypass the hub. Use route-target filtering and verify that no spoke-to-spoke VPN-IPv4 route is imported. Watch for asymmetric return paths: PE1 must export the hub RT for all sites, and the firewall must permit the return direction.