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:
- Not injected: The route never entered the local BGP table (
networkcommand missing, or prefix not in IP RIB) - Inbound filtered: Received from peer but blocked by inbound policy (prefix-list, route-map, filter-list)
- Not best path: Exists in BGP table but another path was selected
- Next-hop invalid: In BGP table but marked invalid (next-hop unreachable)
- Outbound filtered: Best path selected but blocked by outbound policy before reaching the peer
- 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 tableIs 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.0If 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.0If 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 tableThe 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-mapKey Takeaways
- Trace the route through the pipeline: injection → inbound policy → best path → outbound policy → peer.
- Compare
received-routesvsroutesto identify inbound filtering. Checkadvertised-routesfor outbound issues. - The
networkcommand 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.