Question

In a service provider MPLS L3VPN core, PE1 and PE2 exchange VPNv4 prefixes through a dedicated route reflector (RR) that is not in the data forwarding path. Customer routes appear in the BGP VPNv4 table on PE2 with the correct route target, but they never install into the customer VRF routing table on PE2. A show bgp vpnv4 unicast all reveals the routes are marked as inaccessible, and the next-hop of each VPNv4 prefix points to the RR's loopback rather than PE1's loopback. What is the most likely cause?

Accepted Answer

The RR is configured with 'neighbor next-hop-self' under the VPNv4 address family, rewriting the BGP next hop to itself

Answer

The route target import statement on PE2 does not match the export target on PE1

Answer

LDP is not enabled on the RR's loopback interface, so no label binding exists

Answer

The RD values on PE1 and PE2 are identical, causing the VPNv4 prefixes to be treated as duplicates