BGP

Troubleshooting BGP Route Advertisement Problems

The BGP session is Established but routes are missing. A missing prefix can be stopped at any of several pipeline stages, from injection to best path to output filtering. A methodical troubleshooting guide to BGP route advertisement.
Troubleshooting BGP Route Advertisement Problems
In: BGP

The BGP session is Established and healthy, but routes are missing. Maybe a prefix you're advertising isn't reaching your peer. Maybe a prefix your peer is sending isn't in your BGP table. Route advertisement problems are the second most common BGP issue after adjacency failures, and they're harder to diagnose because there's no flashing alarm — routes just silently disappear at some point in the pipeline.

The Route Pipeline

Every route passes through a defined path (see How BGP Advertises Routes). When a route is missing, it was stopped at one of these stages:

  1. Not injected: The route never entered the local BGP table (network command missing, or prefix not in IP RIB)
  2. Inbound filtered: Received from peer but blocked by inbound policy (prefix-list, route-map, filter-list)
  3. Not best path: Exists in BGP table but another path was selected
  4. Next-hop invalid: In BGP table but marked invalid (next-hop unreachable)
  5. Outbound filtered: Best path selected but blocked by outbound policy before reaching the peer
  6. iBGP split-horizon: Learned from one iBGP peer, not re-advertised to another iBGP peer

Diagnostic Workflow

Is the route in the local BGP table?

R1-HQ# show ip bgp 100.64.0.0/18
! If found: route exists locally, problem is outbound
! If not found: route never made it into the BGP table

Is the route being received from the peer?

! Pre-policy (all routes received, before filtering)
R1-HQ# show ip bgp neighbors 172.16.0.2 received-routes | include 100.64.0.0

! Post-policy (routes accepted after inbound filtering)
R1-HQ# show ip bgp neighbors 172.16.0.2 routes | include 100.64.0.0

If the route is in received-routes but not in routes, your inbound policy is filtering it. Check the inbound prefix-list, route-map, or filter-list.

Is the route being advertised to the peer?

R1-HQ# show ip bgp neighbors 172.16.0.2 advertised-routes | include 10.1.0.0

If not in advertised-routes: outbound policy is blocking it, or it's not the best path, or the iBGP split-horizon rule applies.

Common Scenarios and Fixes

Scenario 1: network command configured but route not in BGP table

R1-HQ# show ip bgp 10.1.0.0/16
% Network not in table

R1-HQ# show ip route 10.1.0.0 255.255.0.0
% Network not in table

The network command requires an exact prefix/mask match in the IP routing table. If you have 10.1.1.0/24 and 10.1.2.0/24 but no 10.1.0.0/16, the network command won't work.

Fix: Add a static route: ip route 10.1.0.0 255.255.0.0 Null0

Scenario 2: Route received but filtered inbound

! Shows in received-routes
R1-HQ# show ip bgp neighbors 172.16.0.2 received-routes | include 192.168
*  192.168.1.0/24    172.16.0.2              0             0 65010 i

! Missing from routes (post-policy)
R1-HQ# show ip bgp neighbors 172.16.0.2 routes | include 192.168
! (empty)

Your inbound prefix-list or route-map is blocking 192.168.1.0/24. Check the inbound policy and its hit counts.

Scenario 3: Route in BGP table but not in routing table

R1-HQ# show ip bgp 100.64.0.0/18
  ...
    172.16.0.2 (inaccessible) from 172.16.0.2 (203.0.113.1)
      Origin IGP, valid, internal

Next-hop unreachable. Fix with next-hop-self (see BGP Next-Hop-Self).

Scenario 4: iBGP route not re-advertised

! R2-HQ learns from R1-HQ via iBGP
R2-HQ# show ip bgp 100.64.0.0/18
*>i 100.64.0.0/18   1.1.1.1 ...

! R3 (another iBGP peer of R2-HQ) doesn't see it
R2-HQ# show ip bgp neighbors 3.3.3.3 advertised-routes | include 100.64
! (empty)

iBGP split-horizon rule: R2-HQ won't re-advertise an iBGP-learned route to another iBGP peer. Fix: make R2-HQ a route reflector, or ensure R1-HQ peers directly with R3.

Scenario 5: Route not advertised due to outbound policy

R1-HQ# show ip bgp neighbors 172.16.0.2 advertised-routes | include 10.2
! (empty)

! But the route is in the BGP table
R1-HQ# show ip bgp 10.2.0.0/16
*> 10.2.0.0/16 ...

! Check outbound policy
R1-HQ# show ip bgp neighbors 172.16.0.2 | include route-map
  Route map for outgoing advertisements is OUR-PREFIXES

R1-HQ# show ip prefix-list OUR-PREFIXES
  seq 10 permit 10.1.0.0/16
! Missing: 10.2.0.0/16 not in the outbound prefix-list

Fix: Add 10.2.0.0/16 to the outbound prefix-list.

Useful Debug Commands

! Watch UPDATE messages (filtered to specific peer)
R1-HQ# debug ip bgp updates 172.16.0.2

! Watch specific prefix activity
R1-HQ# debug ip bgp updates 172.16.0.2 prefix 100.64.0.0/18

! Check route-map evaluation
R1-HQ# debug ip bgp updates 172.16.0.2 in
*Mar 27 10:22:15: BGP(0): 172.16.0.2 rcv UPDATE w/ attr: nexthop 172.16.0.2
*Mar 27 10:22:15: BGP(0): 172.16.0.2 rcv UPDATE about 100.64.0.0/18 -- DENIED due to: route-map

Key Takeaways

  • Trace the route through the pipeline: injection → inbound policy → best path → outbound policy → peer.
  • Compare received-routes vs routes to identify inbound filtering. Check advertised-routes for outbound issues.
  • The network command requires an exact prefix/mask match in the IP routing table — this is the #1 cause of "I configured it but BGP isn't advertising it."
  • iBGP split-horizon silently prevents route re-advertisement. Route reflectors are the standard fix.
  • debug ip bgp updates [peer] shows real-time UPDATE processing, including which routes are denied by policy.
Written by
More from Ping Labz
MPLS L3VPN with MP-BGP and VPNv4
MPLS

MPLS L3VPN with MP-BGP and VPNv4

MPLS L3VPN architecture: VRFs, Route Distinguishers, Route Targets, MP-BGP for VPNv4, the two-label stack, PE-CE routing, and the Cisco IOS XE configuration.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ping Labz.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.