Session up, prefixes zero, and the silent policy mismatch

Introduction BGP sessions follow the finite‑state machine defined in RFC 4271. A session can reach Established while exchanging no usable routes if one of three conditions occurs:

1. Adj‑RIB‑In receives no UPDATEs (peer not sending or transport loss).
2. The negotiated AFI/SAFI set does not include the address family of interest, causing UPDATEs to be dropped before they reach Adj‑RIB‑In.
3. An overly restrictive inbound policy discards every route after it has been placed in Adj‑RIB‑In.

The sections below explain each component, show how to verify them, and map the exact checks that reveal where the loss occurred.

Adj‑RIB‑In

Definition

Adj‑RIB‑In holds the raw, unfiltered routing information received from inbound UPDATE messages. It is maintained per‑peer and contains the exact NLRI, path attributes, and optional transitive attributes as received. No best‑path selection, MED comparison, or local‑pref assignment occurs here.

Verification

If the output shows 0 routes received, Adj‑RIB‑In is empty → the problem lies before the UPDATE reaches the router (AFI/SAFI mismatch, transport loss, or peer not sending updates).

Negotiated AFI/SAFI

How It Works

During the OPEN exchange each peer advertises a list of AFI/SAFI pairs it supports (MP‑BGP capability, RFC 4760). The intersection of the two lists becomes the negotiated set. Only UPDATEs whose NLRI matches a negotiated pair are processed; all others are silently discarded, even though the TCP session stays in Established.

Verification

If the expected AFI/SAFI (e.g., IPv4 unicast) is absent from the negotiated list, UPDATEs for that family are dropped before Adj‑RIB‑In.

Inbound Policy

Definition

Inbound policy consists of route‑maps, prefix‑lists, filter‑lists, distribute‑lists, or community‑based filters applied after a route is stored in Adj‑RIB‑In but before it is considered for the Loc‑RIB.

How It Affects Routes

1. UPDATE → stored unchanged in Adj‑RIB‑In.
2. Inbound route‑selection reads Adj‑RIB‑In entry.
3. Each policy clause is evaluated in sequence:
   • deny → route discarded.
   • permit (with optional attribute changes) → route proceeds to next clause or Loc‑RIB.
4. If all clauses deny or no clause matches and the default action is deny, the route is not installed.

Thus, a restrictive inbound policy can yield an empty Loc‑RIB while Adj‑RIB‑In remains populated.

Verification

If received‑routes > 0 but the BGP table shows 0 prefixes for that AFI/SAFI, inbound policy is filtering everything out.

Troubleshooting Flow

1. Confirm session state

   show bgp summary   # or show ip bgp summary

   Ensure the peer is in Established.

2. Check Adj‑RIB‑In

   • Run the appropriate received‑routes command.
   • 0 received → investigate transport/AFI/SAFI (go to step 3).
   • >0 received → go to step 4.

3. Verify negotiated AFI/SAFI

   • Use the neighbor‑detail command for your platform.
   • Missing expected AFI/SAFI → correct the capability configuration on either side (activate the address family, ensure matching capabilities).
   • If AFI/SAFI matches but received‑routes = 0, look for packet loss, ACLs blocking TCP/179, or the peer not sending updates.

4. Examine inbound policy

   • Display the policy applied to the neighbor (show run | section neighbor <ip> or equivalent).
   • Temporarily disable the inbound policy (remove route-map … in, prefix-list … in, etc.) and re‑check received‑routes vs. BGP table.
   • If routes appear after removal, refine the policy (adjust prefix‑lists, AS‑PATH filters, route‑map sequence actions).

5. Validate

   • After fixing the issue, re‑run the received‑routes and BGP table commands to confirm prefixes are now installed.
   • Monitor for flaps or further drops.

Quick Reference Commands

Cisco IOS‑XR

# Session state
show bgp summary

# Received routes (Adj‑RIB‑In)
show bgp ipv4 unicast neighbors 10.0.0.2 received-routes

# Negotiated capabilities
show bgp neighbors 10.0.0.2

# Loc‑RIB (for comparison)
show bgp ipv4 unicast

Juniper Junos

show bgp summary
show route receive-protocol bgp 10.0.0.2
show bgp neighbor 10.0.0.2
show route protocol bgp

Cisco IOS (classic)

show ip bgp summaryshow ip bgp neighbors 10.0.0.2 received-routes
show ip bgp neighbors 10.0.0.2
show ip bgp

By following this systematic check‑list you can pinpoint whether a silent BGP session failure stems from missing UPDATEs, an AFI/SAFI mismatch, or an overly strict inbound policy, and then apply the precise corrective action.