BGP RIB and FIB growth: monitoring route-table size before it bites

The global BGP routing table grows every year. In 2026, the IPv4 default-free zone sits at approximately 940,000 prefixes, with IPv6 adding roughly 190,000 more. These numbers increase steadily, and the hardware that programs forwarding decisions from them has finite capacity. When that capacity runs out, new routes do not get installed in the forwarding plane. Traffic to affected destinations blackholes. The BGP session stays Established the entire time.

This is one of the few failure modes where the control plane reports healthy while the data plane silently breaks. If you monitor BGP session state but not route-table size, you will not know the router has stopped installing routes until users complain.

What it is and why it matters

The Routing Information Base (RIB) is the set of routes a router has learned from all sources: BGP peers, IGP, static routes, connected networks. The Forwarding Information Base (FIB) is the optimized subset of the RIB that the hardware forwarding plane (typically TCAM on modern routers) uses to make packet-forwarding decisions. The RIB lives in control-plane memory. The FIB lives in hardware.

The RIB is always larger than the FIB. A router accepting full Internet feeds from three peers accumulates every received path in the RIB, including rejected, hidden, and dampened routes. On a multi-peer edge router, the RIB can hold 2 to 3 times more entries than the active FIB. Both resources are finite: the RIB consumes control-plane memory, and the FIB consumes TCAM.

When TCAM fills, the router stops installing new routes into the FIB. The RIB keeps growing because BGP sessions are still exchanging UPDATE messages. The control plane has no idea the data plane is rejecting routes. No trap fires. No syslog entry appears. The BGP FSM stays Established. Traffic to the affected destinations starts taking suboptimal paths, loops, or blackholes.

The global table crossed 768,000 IPv4 routes in 2019, triggering TCAM exhaustion on legacy Cisco Catalyst 6500 and 7600 platforms with older supervisor engines. Non-XL supervisors cap at 256,000 IPv4 routes and cannot be extended. The XL variants (SUP720-3BXL and SUP720-3CXL) support extended capacity but still have hard limits. The “768k day” was a preview of what happens when organic growth outpaces hardware capacity without warning.

How it works

The following diagram shows how multiple BGP peers feed the RIB, how best-path selection produces the FIB, and where the silent failure occurs when TCAM capacity is exhausted:

flowchart TD
    PA[Peer A: full feed] --> RIB[RIB: all received paths]
    PB[Peer B: full feed] --> RIB
    PC[Peer C: partial feed] --> RIB
    RIB -->|best path selection| FIB[FIB: active routes only]
    FIB -->|program into hardware| TCAM[TCAM: finite capacity]
    TCAM -->|below limit| OK[Forwarding works]
    TCAM -->|at capacity| DROP[New routes silently rejected]
    DROP --> SESS[BGP session stays Established]
    DROP --> BH[Traffic blackholed for new destinations]

The failure is not between the peers and the RIB. BGP keeps working. The failure is between the FIB and TCAM. Once TCAM is full, the forwarding ASIC cannot accept additional entries. The control plane has no standard mechanism to alert on this condition. Detection requires actively monitoring route counts and comparing them against known hardware limits.

Where it shows up in production

Internet edge routers accepting full feeds. An edge router taking full tables from two or three transit providers is the most common exposure. Each peer contributes roughly 940,000 IPv4 prefixes and 190,000 IPv6 prefixes. The RIB holds all of them. The FIB holds the best-path subset. As the global table grows organically at 5 to 10 percent per year, a router that had comfortable headroom three years ago may be approaching its limit today.

Multi-VRF environments. Standard BGP MIBs (RFC 1657, later updated by RFC 4273) do not expose per-VRF route counts natively. Cisco’s cbgpPeer3Table in CISCO-BGP4-MIB adds VRF context via cbgpPeer3VrfId and cbgpPeer3VrfName. Juniper gained per-VRF RIB monitoring through BMP starting in Junos OS Release 22.4R1. If you run VRFs and rely on standard MIB polling, you may have per-VRF blind spots.

Legacy hardware in critical paths. Older supervisor engines have hard TCAM limits. Cisco Catalyst 6500 and 7600 platforms with non-XL supervisors cannot hold the current full table. The mls cef maximum-routes ip 1000 command can reallocate TCAM from IPv6, multicast, or MPLS toward IPv4 on these platforms. This requires a configuration save and reboot. Check current per-protocol route counts with show mls cef summary before applying.

BGP session teardown from prefix limits. When a peer exceeds a configured maximum-prefix limit, the router sends a BGP Cease notification with subcode 1 (Maximum Prefixes Reached, RFC 4486) and tears down the session. This is a different failure: it is loud, it drops the session, and it is visible. But it only fires if the limit is configured. Routers without maximum-prefix limits on their peers silently absorb whatever the peer sends until TCAM fills.

When this matters

Route-table growth monitoring is most critical when:

• You accept full or near-full Internet feeds from one or more peers.
• You operate hardware with known TCAM limits within a few years of the global table size.
• You run multiple VRFs on shared hardware, where one VRF’s growth can consume another’s capacity.
• You have recently changed peers, filters, or routing policy, causing sudden shifts in received prefix counts.

It is less critical when:

• You receive only a default route or partial feeds (your FIB stays small).
• Your hardware has TCAM capacity orders of magnitude above the global table.
• You operate in a closed network with controlled prefix growth (enterprise core, campus, OT networks).

A common misuse is monitoring BGP session state as a proxy for route health. Session Established does not mean routes are installed. It only means the TCP session and BGP keepalive exchange are functioning. Track prefix counts and FIB utilization separately.

Signals to watch in production

Instrumentation paths

SNMP polling. The standard BGP4-MIB provides bgpPeerInUpdates and bgpPeerOutUpdates at .1.3.6.1.2.1.15.3.1.10 and .1.3.6.1.2.1.15.3.1.11. These track UPDATE message counts, not prefix counts directly. For per-peer accepted prefix counts on Cisco, use cbgpPeer2AcceptedPrefixes in CISCO-BGP4-MIB (1.3.6.1.4.1.9.9.187). The index includes peer address, AFI, and SAFI. Verify the exact suffix on your target IOS XE version.

The older bgp4PathAttrTable indexes by prefix first, requiring a full table walk to isolate a single peer’s routes. This is operationally inefficient at scale. The cbgpRouteTable indexes by peer address first, then prefix, enabling efficient per-peer polling without walking the entire BGP RIB. Prefer the newer table where available.

CLI verification. The most reliable on-box commands:

# Per-peer prefix counts
ssh <router> 'show ip bgp summary | begin Neighbor'

# Route table size by protocol
ssh <router> 'show ip route summary'

# FIB summary (route counts; TCAM utilization requires platform-specific commands)
ssh <router> 'show ip cef summary'

# Per-peer received routes (requires soft-reconfiguration inbound on the peer;
# memory-intensive on full-feed peers)
ssh <router> 'show ip bgp neighbors <peer> received-routes | include Total'

For TCAM utilization specifically, the command varies by platform. On Catalyst 6500/7600, use show mls cef summary. On Nexus 9000, use show hardware access-list resource profile. On Juniper MX, use show chassis forwarding.

BMP for deep visibility. BGP4-MIB’s bgp4PathAttrTable only reflects best-path routes. Adj-RIB-In entries (pre-policy and post-policy routes) are not exposed via standard SNMP. For full visibility into what each peer is actually sending before your local policy filters it, deploy BMP (RFC 7854). BMP streams per-prefix, real-time route data to a monitoring station, including withdrawals and AS-path changes that BGP4-MIB cannot surface. Juniper supports per-VRF BMP monitoring from Junos 22.4R1 onward.

Note that show ip bgp summary resets counters on clear ip bgp *, so baselines are not preserved across a reset. Track prefix counts via SNMP or BMP for persistent trending.

How Netdata helps

• Per-peer prefix count trending at minute granularity. Netdata’s SNMP collector can poll BGP4-MIB and vendor-specific BGP MIBs at per-minute intervals. A sudden 20% spike triggers alerting before it becomes a route leak or TCAM overflow. Correlate with the detection signals in BGP route leak and hijack.
• FIB-to-TCAM ratio monitoring. If your platform exposes FIB utilization via SNMP or CLI scrape, Netdata can alert when utilization crosses 70% of capacity.
• Control-plane CPU and memory correlation. When BGP reconvergence occurs (new peer, mass withdrawal, route reflector change), CPU and memory spikes accompany the RIB rebuild. Netdata correlates these alongside prefix-count changes so you can see whether a table rebuild is progressing or stuck.
• Stale session detection. A BGP session that stays Established while prefix counts flatten is a silent failure. Per-minute polling of bgpPeerInUpdates catches the moment UPDATE traffic stops, even when the FSM reports healthy. See BGP session Established but stale.
• Cease subcode alerting. A Cease/1 (Maximum Prefixes) notification is always actionable. Netdata can parse BGP NOTIFICATION events from syslog or traps and alert immediately, distinguishing routine maintenance shutdowns from prefix-limit violations.

Related guides

• BGP route leak and hijack: the detection signals and alerts that matter
• BGP session Established but stale: detecting silent route loss
• Network monitoring checklist: the signals every production network needs
• SNMP poll response latency: diagnosing a slow poller
• SNMP counter rollover: fake traffic spikes from 32-bit counters