How BGP Advertises Routes: NLRI, Withdrawn Routes, and the Adj-RIB

BGP is not like OSPF — it doesn't automatically advertise connected interfaces or discover routes on its own. Every prefix BGP advertises must be explicitly injected through one of three mechanisms: the network command, redistribution, or aggregation. Understanding how routes enter the BGP table and flow through the Adj-RIB pipeline is essential for controlling what your network advertises to the world.

Three Ways to Inject Routes into BGP

The network Command

The network command in BGP does not enable BGP on an interface (unlike OSPF's network). It tells BGP: "if this exact prefix exists in the IP routing table (from any source), advertise it in BGP with Origin IGP."

R1-HQ(config)# router bgp 65001
R1-HQ(config-router)# network 10.1.0.0 mask 255.255.0.0

Critical detail: the prefix and mask must match exactly what's in the routing table. If you have 10.1.0.0/24 and 10.1.1.0/24 as connected routes but no 10.1.0.0/16 summary, the network 10.1.0.0 mask 255.255.0.0 command won't advertise anything. You'd need a static route or summary to create the exact /16 in the RIB first.

R1-HQ(config)# ip route 10.1.0.0 255.255.0.0 Null0
R1-HQ(config)# router bgp 65001
R1-HQ(config-router)# network 10.1.0.0 mask 255.255.0.0

This is the cleanest way to advertise an aggregate — create a static null route for the summary and use the network command to inject it into BGP.

Redistribution

Redistribution imports routes from another routing protocol (OSPF, EIGRP, static, connected) into BGP. Redistributed routes get Origin Incomplete (?).

R1-HQ(config-router)# redistribute ospf 1 match internal external 1 external 2
R1-HQ(config-router)# redistribute connected route-map CONNECTED-TO-BGP

Always use a route-map with redistribution. Without one, you risk advertising every OSPF or connected route into BGP — including management networks, loopbacks, and infrastructure links that have no business being in the global routing table.

Aggregation

The aggregate-address command creates a summary prefix from more-specific routes already in the BGP table. The component routes must exist in the BGP table (not just the IP routing table).

R1-HQ(config-router)# aggregate-address 10.1.0.0 255.255.0.0 summary-only

Without summary-only, both the aggregate and the component routes are advertised. With summary-only, only the aggregate is sent — component routes are suppressed. We cover this in detail in BGP Route Aggregation and Summarization.

The Adj-RIB Pipeline

As we introduced in How BGP Works, BGP maintains three tables per peer per address family. Here's how routes flow through them:

Inbound: Adj-RIB-In → Loc-RIB

1. Peer sends UPDATE with NLRI and path attributes
2. Routes stored in Adj-RIB-In for that peer (all received routes, pre-policy)
3. Inbound route-map, prefix-list, or filter-list applied
4. Routes that pass policy enter the best path selection algorithm
5. Best paths installed in Loc-RIB (the main BGP table)
6. Best paths eligible for the IP routing table (if AD is competitive)

Outbound: Loc-RIB → Adj-RIB-Out

1. Best path from Loc-RIB is candidate for advertisement
2. Outbound route-map, prefix-list, or filter-list applied per peer
3. Routes that pass policy placed in Adj-RIB-Out for that peer
4. UPDATE message generated and sent to the peer

iBGP Advertisement Rules

The iBGP split-horizon rule constrains outbound advertisement: a route learned from an iBGP peer is NOT placed in the Adj-RIB-Out for any other iBGP peer. It IS advertised to eBGP peers. Routes learned from eBGP peers are advertised to both iBGP and eBGP peers (subject to policy). Route reflectors override this behavior — see BGP Route Reflectors.

Viewing the Tables

! All routes received from ISP-A (Adj-RIB-In, pre-policy)
R1-HQ# show ip bgp neighbors 203.0.113.1 received-routes

! Routes accepted after inbound policy (post-policy Adj-RIB-In)
R1-HQ# show ip bgp neighbors 203.0.113.1 routes

! Main BGP table (Loc-RIB) — best paths marked with >
R1-HQ# show ip bgp

! Routes advertised to R2-HQ (Adj-RIB-Out)
R1-HQ# show ip bgp neighbors 10.1.1.2 advertised-routes

The difference between received-routes and routes shows you what your inbound policy is filtering. If a route appears in received-routes but not in routes, your inbound route-map or prefix-list is blocking it.

Note: received-routes requires soft-reconfiguration inbound to be enabled (neighbor x.x.x.x soft-reconfiguration inbound) or the route-refresh capability to be negotiated (it is by default on modern IOS XE).

The network Command vs Redistribution — When to Use Which

• Use network when you want precise control over exactly which prefixes enter BGP. This is the preferred method for advertising your own address space to the internet.
• Use redistribution when you need to import a large number of prefixes dynamically (e.g., customer routes from OSPF into MP-BGP in an MPLS VPN PE router). Always pair with a route-map for safety.
• Use aggregate-address when you want to advertise a summary of more-specific BGP routes, typically at your AS boundary to reduce the number of prefixes your neighbors receive.

Troubleshooting

Key Takeaways

• BGP never advertises routes automatically — every prefix must be injected via network, redistribution, or aggregate-address.
• The network command requires an exact prefix/mask match in the IP routing table. It does not enable BGP on interfaces.
• Always use route-maps with redistribution to prevent unintended route leakage into BGP.
• The Adj-RIB-In → Loc-RIB → Adj-RIB-Out pipeline controls how routes are received, selected, and advertised. Understanding this pipeline is key to troubleshooting missing routes.
• Use received-routes vs routes to identify inbound policy filtering, and advertised-routes to verify what you're sending to a peer.