VRF Missing Route: Local, VPNv4 or Forwarding Table?

A customer says a prefix is missing after a route-target change, and the first screenshot they send is usually the wrong table. Three different tables answer three different questions: whether the prefix exists inside the VRF, whether it was advertised and imported as a VPNv4 route, and whether a forwarding entry was actually installed. Reading them out of order produces confident, wrong conclusions. This runbook walks one local prefix and one remote prefix through all three, in order, and ends with a rollback plan for the RT edit that started it.

Name the prefix and the table it belongs in

Write down two prefixes before typing anything. One is local to the customer site, learned from a connected interface or a CE advertisement. The other is remote, expected to arrive over the provider backbone. They take different paths into the same VRF, and a fault in one says nothing about the other.

Keep the distinction between the two identifiers straight, because most of the confusion in these tickets comes from it. The route distinguisher is part of the VPNv4 NLRI and exists to make otherwise identical customer prefixes unique across the backbone. The route target is an extended community carried as an attribute, and it is what import and export policy matches on. It is not a second name for the distinguisher and it is not carried in the customer's packets.

Step 1: prove the prefix is in the VRF

Start with the local view, then the RTs that govern import. If the local prefix is missing here, nothing upstream can be at fault:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

A prefix that appears as connected or static is locally learned, and its presence says nothing about whether it was exported. That is the single most common misreading in this workflow: a healthy VRF table is evidence about local learning only. The export side is a separate question, answered by the neighbor view and the attached export target.

Check the RT lists on the VRF while you are here. If the intended import target is not in the list, everything downstream is irrelevant. If it is present but different from what the remote PE exports, you have found the fault without opening a single packet capture.

Step 2: read the VPNv4 table and its targets

The VPNv4 table shows what the control plane actually exchanged. Look for the remote prefix under the correct distinguisher, then look at the communities attached to it:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

An entry with the right route target but no local installation points at import policy or at route selection, not at reachability. An entry that never appears in the VPNv4 table at all points upstream: the originating PE may not have exported it, or the session may not carry the address family.

There is a third case that trips people up during changes. Some platforms constrain which VPN routes they request or retain, using route-target membership information, so the absence of a remote NLRI in one filtered view is not proof that the advertisement does not exist anywhere. Check the unfiltered table and the neighbor's advertised-routes before concluding that a route was withdrawn globally.

Step 3: confirm something was installed and labelled

A BGP entry is a decision, not a path. The forwarding tables tell you whether packets have somewhere to go:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

A CEF entry with a resolved adjacency and an outgoing label means data-plane traffic should work, and any remaining symptom belongs to the application or to filtering inside the VRF. A CEF entry showing an unresolved next hop means the label path is incomplete even though BGP looks healthy, which is exactly the case where a screenshot of the BGP table has misled a change review.

Compare the label the local PE imposes with the one the remote PE expects to receive. A mismatch across the two views is a label allocation or session problem, and it will not be fixed by editing route targets no matter how many times you do it.

Roll back the RT change with a stated scope

If the fault started with a route-target edit, undo it as one deliberate step and say what scope you are changing. Removing an import target withdraws eligibility inside that VRF. It does not delete the VPNv4 advertisement from the backbone, and on some platforms the route stays retained in the table. Those are different outcomes and the user-visible effect depends on which one you mean.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

A soft reconfiguration inbound is enough when the session already stores the prefixes; a hard reset of a provider-facing session during business hours is a decision someone else should make. On Junos the equivalent checks read the per-VRF table and the VPN table directly, and the rollback is a commit-time revert rather than a per-command undo, so capture the configuration diff before you start.

Finish with the same three commands you began with, in the same order, and record their output with a timestamp. A ticket that says the RT was wrong and now it is right is not reusable; one that shows the prefix present in the VRF, present in VPNv4, and installed in CEF is evidence the next person can compare against. If only the first two changed, you have not finished the change.