VPNv4 Route Arrives Without Its Route Target
A route reflector (RR) serves PE1 and PE2 in AS 65000. PE2 exports VRF BLUE prefix 10.20.20.0/24 with RD 65000:2 and route target 65000:100. PE1's VRF BLUE imports route target 65000:100. The underlay OSPF has PE2's loopback reachable. On PE1, show bgp vpnv4 unicast all 10.20.20.0/24 shows the prefix with next-hop 10.255.255.2, but the Extended Community field is empty. show bgp vrf BLUE 10.20.20.0/24 shows nothing, and show ip route vrf BLUE has no entry for the prefix. The RR has neighbor 10.255.255.1 send-community standard, and the PE1-RR session is up. A previous engineer removed send-community extended to reduce CPU after a BGP flap. You must determine why a route that is visible in VPNv4 is not imported into the VRF.
1. Explain why an empty extended community prevents import even though PE1's import route target is correctly configured.
Read the worked answer
In VPNv4, the route target is carried as a BGP extended community, not as a normal community or as part of the NLRI. The VRF import decision compares the route's extended-community route targets against the VRF's import route-target list. If the RR strips extended communities, PE1 still receives the VPNv4 prefix, but it has no route target to match. The route remains in the global VPNv4 table and is not imported into VRF BLUE. The local configuration on PE1 can be perfectly correct; the missing attribute on the wire is the problem. This is why the prefix is visible in show bgp vpnv4 unicast all but absent from show bgp vrf BLUE and the VRF routing table.
2. What commands confirm the issue, and what is the exact fix?
Read the worked answer
On PE1, recheck show bgp vpnv4 unicast all 10.20.20.0/24 and look specifically at the extended-community field. Compare with show bgp vpnv4 unicast all 10.20.20.0/24 on the RR and with the RR's neighbor configuration. On the RR, show bgp vpnv4 unicast all neighbors 10.255.255.1 advertised-routes can show whether the extended community is being sent. The fix is to restore neighbor 10.255.255.1 send-community extended on the RR, and ensure the same is true on the other iBGP direction if applicable. After the change, PE1 should show route target 65000:100 in the extended-community field, the prefix should appear in show bgp vrf BLUE, and it should be installed in the VRF routing table.
3. After the fix, the route still does not appear in PE1's VRF. What are the next checks?
Read the worked answer
First confirm that PE1's VRF import and export route targets match exactly and that the VRF is up. Check for an inbound route policy on PE1 that might strip or filter extended communities or reject the prefix. Verify next-hop reachability and recursive lookup for 10.255.255.2 in the global table; a VPNv4 route with an unreachable next hop will not be usable. Check for a VRF route limit, a maximum-prefix policy, or a route-target constraint filter. Also confirm that the RD is unique and that PE2 is actually exporting the prefix with the intended route target, not a similarly named one. Finally, inspect show bgp vrf BLUE for a route that is present but not best, and check whether the global VPNv4 route is selected as best.