I85PREP
⌘ K
JNCIP-SP study materials
JNCIP-SP study resources

VPN Prefix Installed in the Wrong Customer VRF

JNCIP-SP · Put your knowledge to work in context.

All case studies

VPN Prefix Installed in the Wrong Customer VRF

PE-3 and PE-4 are PEs in AS 65000 peering iBGP with a route reflector. PE-3 hosts VRF CUST-A, whose CE advertises 172.16.8.0/24; the VRF is built with vrf-target target:65000:100. On PE-4, show route table bgp.l3vpn.0 does contain 172.16.8.0/24 with community target:65000:100, but show route table CUST-A.inet.0 is empty. A colleague finds the prefix installed in CUST-B.inet.0 - a different customer's VRF that has a live CE attached and is now forwarding toward 172.16.8.0/24. Both VRFs were cloned from one template six weeks ago. CUST-B is production and its CE must not lose its own routes. You cannot change anything on PE-3, and the change window is 30 minutes. The service desk has already promised CUST-B that no traffic will be interrupted, so everything you touch must be reversible within one commit.

1. Explain the mechanism that puts PE-3's prefix into CUST-B and state exactly what you would inspect to confirm the discrepancy and its blast radius.

Read the worked answer

vrf-target is shorthand that sets both an import and an export target. If CUST-B was cloned from the CUST-A template and the target was never edited, CUST-B has import target:65000:100 as well, so it imports every VPN route carrying that community - including PE-3's CUST-A prefix. The route is correctly present in bgp.l3vpn.0; the fault is purely which VRF imports it.

Confirm with:

  1. show configuration routing-instances | display set | match "vrf-target|65000:100" - look for every VRF referencing 65000:100, not just the two you know about.
  2. show route table CUST-B.inet.0 172.16.8.0/24 extensive - the Communities line should show target:65000:100 and the route should be a BGP VPN route.
  3. show route table CUST-A.inet.0 - empty, confirming the import side of CUST-A is fine.
  4. show route advertising-protocol bgp <CUST-B CE neighbor> - prove whether the leaked prefix has already been handed to the CUST-B CE.

Step 4 defines the blast radius: if the CE has learned it, removing it later is a visible routing change for that customer and must be handled in the same window.

2. Give the corrective configuration and the safe commit sequence, including what you must check in both directions before and after.

Read the worked answer

Correct CUST-B's target to its own route target, which you must confirm from the design (assume 65000:200):

set routing-instances CUST-B vrf-target export target:65000:200
set routing-instances CUST-B vrf-target import target:65000:200

Checking import and export separately is important: with the cloned target, CUST-B has also been exporting its prefixes with 65000:100, which means CUST-B's own routes may be leaking into CUST-A. Check show route table CUST-A.inet.0 for prefixes that are not CUST-A's before and after the change.

Sequence inside the 30-minute window:

  1. Record the pre-change state: show route table CUST-A.inet.0, show route table CUST-B.inet.0, and show route advertising-protocol bgp <CE-B>.
  2. Commit with commit confirmed 5 so an error reverts itself.
  3. Verify 172.16.8.0/24 now appears in CUST-A and is gone from CUST-B; verify CUST-B's legitimate prefixes are still present and still advertised to its CE.
  4. Verify CUST-A does not retain CUST-B prefixes.
  5. Confirm the commit and inform CUST-B's NOC that its CE may log a withdrawn route.

3. What residual risk remains after the fix, and how would you detect leaked prefixes that you have not already noticed?

Read the worked answer

Removing a route from a VRF withdraws it from the CE, so CUST-B's CE may briefly reconverge or, if it had installed the leaked prefix in a static or redistribution path, may keep it in its own table until the hold-down expires. Confirm with the CUST-B operator rather than assuming the PE view is the whole picture.

The larger residual risk is other VRFs built from the same template. Detection:

  • show configuration routing-instances | display set | match "vrf-target" and audit every VRF's import/export pair against the route-target plan.
  • show route table bgp.l3vpn.0 detail | match "65000:100" to see how many distinct prefixes carry the shared target.
  • For each VRF, show route table <vrf>.inet.0 and check that every prefix belongs to that customer.
  • show route advertising-protocol bgp <neighbor> on each CE session to catch leaks that have already reached a customer device.

Also check whether an explicit vrf-import policy exists on these VRFs; a policy with a permissive from community clause can import routes even after vrf-target is corrected, and it will not show up in a vrf-target audit.