I85PREP
⌘ K
Nokia VPRN study materials
Nokia VPRN study resources

VPRN route valid in BGP but absent from the route table

Nokia VPRN · Put your knowledge to work in context.

All case studies

VPRN route valid in BGP but absent from the route table

A service provider runs SR OS 22.10 on PE-1 and PE-2 in AS 65000, with RR-1 as route reflector. VPRN 100 serves a rail customer: RD 65000:100, vrf-target target:65000:100 on both PEs. CE-1 at PE-1 advertises 172.16.10.0/24 by eBGP; CE-2 at PE-2 advertises 172.16.20.0/24. Transport between the PEs is LDP-signaled only, to system addresses 10.0.0.1/32 and 10.0.0.2/32; there are no RSVP-TE LSPs and no segment routing. The design standard for this customer is auto-bind-tunnel in the VPRN, and the junior engineer configured it with resolution-filter rsvp on both PEs. On PE-1, show router bgp routes vpn-ipv4 shows 172.16.20.0/24 with next-hop 10.0.0.2, the correct route target and a valid path. show router 100 route-table shows only the local connected and eBGP routes; no remote prefix appears. OSPF in the base router has a route to 10.0.0.2/32, and the tunnel table shows two LDP LSPs. CE-1 cannot reach CE-2. The change window closes in 45 minutes.

1. Using the outputs, explain why BGP shows 172.16.20.0/24 as a valid VPN route while the VPRN route table has no entry for it. State the exact check that fails and where.

Read the worked answer

The route passes the BGP gate and fails the resolution gate.

  • Import: PE-1 receives the VPN-IPv4 route from RR-1, the route target target:65000:100 matches vrf-target, so the route is imported into VPRN 100's BGP RIB. That is why show router bgp routes vpn-ipv4 shows it with a valid path.
  • Resolution: SR OS does not install a VPRN BGP route until the BGP next-hop (10.0.0.2) resolves to a transport tunnel that the VPRN's auto-bind-tunnel policy permits. With resolution-filter rsvp and only LDP LSPs in the tunnel table, resolution fails. The route stays in BGP and never reaches the route table or FIB.
  • Confirm: show router bgp routes vpn-ipv4 172.16.20.0/24 detail for the unresolved/not-used indication, show router tunnel-table (LDP only, no RSVP), and show service id 100 for the auto-bind-tunnel filter.
  • Why it matters: BGP-level validity and service-level usability are two different gates. Monitoring that only counts BGP VPN routes will report the service as healthy while the customer is down.

2. What is the minimal configuration change, and what should you audit so this cannot recur silently across the other VPRNs?

Read the worked answer

Minimal change: add ldp to the resolution filter (or set the filter to any) under configure service vprn 100 auto-bind-tunnel, commit, then verify with show router 100 route-table that 172.16.20.0/24 is present with the LDP tunnel next-hop, show router 100 fib 1 for the FIB entry, and an end-to-end ping from CE-1 to CE-2. Keep the filter expressed as the tunnel types the design actually deploys; a filter listing a technology you do not run is a latent outage.

Audit: export every VPRN's auto-bind-tunnel filter and compare it against the tunnel types actually up in each PE's tunnel table. Standardize the value in the service template (NFM-P/NSP service template or configlet) so new VPRNs inherit it. Add a post-change check that compares the count of remote prefixes installed in the VPRN route table with the count of imported VPN routes - a mismatch is exactly this silent failure, and it is cheap to automate.

3. Suppose the filter had included both LDP and RSVP and the route still did not install. What three things would you check next, and why in that order?

Read the worked answer

Cheapest and most likely first:

  1. Import policy: a vrf-import policy can silently drop the route even when the RT matches. Check the policy contents and any counters or logs attached to it. A one-character RT difference or a stale policy after a template edit produces exactly this symptom.
  2. Base-router reachability of the BGP next-hop: 10.0.0.2/32 must be in the base RTM. An OSPF export policy, prefix filter or new summarization that removes the system address breaks resolution even when the LSP is fine. Check the base route table, not the tunnel table.
  3. Tunnel quality: the LDP LSP may exist but be down, or have a metric or MTU problem. Check show router tunnel-table for the FEC 10.0.0.2/32 and compare the tunnel MTU with the VPRN interface MTU; a tunnel with insufficient MTU is not a usable path for the service.

After those, verify the RD/RT on both PEs and that the remote PE actually originates the prefix into its VPRN.