Every BGP-speaking router on the internet’s backbone holds a copy of the global routing table — the list of every prefix that’s reachable, who announces it, and the AS path to get there. As of 2026, that’s roughly 1 million IPv4 routes plus 200,000 IPv6 routes, and it keeps growing.
This sounds like trivia. It’s not. The growth of the routing table is one of the long-running operational concerns in internet engineering — it drives memory requirements on every backbone router, affects convergence times during failures, and shapes decisions about IP allocation policy.
This post explains what the routing table is, how big it is, why it’s grown, what “deaggregation” means, and what would happen if it kept growing unbounded.
What’s in the Table
A BGP routing table entry roughly looks like:
Prefix: 8.8.8.0/24
Next-hop: 10.0.0.1
AS path: [our_as, transit_as, ..., 15169]
MED: 0
Local pref: 100
Communities: [...]Multiplied by ~1 million for IPv4 and ~200,000 for IPv6.
Each backbone router has to:
- Receive all these prefixes from peers (often multiple paths per prefix).
- Store them in memory.
- Compute the best path per prefix.
- Install the best paths in the forwarding table that hardware uses for packet lookups.
- Re-converge when routes change.
The “memory” and “forwarding table size” parts are the operational bottlenecks.
Growth Over Time
Approximate routing table size at various points:
- 1994: ~20,000 routes (when CIDR was introduced to slow growth)
- 2000: ~80,000
- 2010: ~330,000
- 2015: ~550,000
- 2020: ~830,000
- 2024: ~970,000
- 2026: ~1,000,000+ (just crossed the threshold)
Growth rate has slowed as IPv4 has exhausted — no new big allocations being added — but deaggregation continues to drive growth.
IPv6 has grown faster:
- 2010: ~3,500 routes
- 2015: ~20,000
- 2020: ~85,000
- 2026: ~200,000+
IPv6 will eventually be larger than IPv4 by route count, but it’s not there yet.
Why So Many Routes?
The original design intent was for each AS to advertise its aggregate prefix — one big block per organization. With ~120,000 ASes globally, you’d expect ~120,000 routes.
Reality has many more reasons routes get advertised:
Multihoming
A network with two upstream providers needs to be reachable through both. It advertises the same prefix to both, often with more-specific subprefixes to control traffic engineering. Each subprefix is a separate route.
Traffic engineering
“Send this part of my address space via ISP A; that part via ISP B.” Done by announcing more-specific routes with different preferences.
Customer subdelegations
A large ISP gives a /24 to a small business customer. Sometimes that’s announced separately for various reasons.
Anti-hijack precaution
A /16 owner sometimes announces their /16 plus every /24 within it, so even if someone tries a more-specific hijack, the legitimate /24 announcements compete.
IPv4 fragmentation
The IPv4 marketplace has resulted in many /22 and /23 blocks being sold to new owners, each announced separately. The “one /8 per organization” of 1995 has become “many /24s per organization” in 2026.
Sub-allocation
Cloud providers (AWS, Azure, GCP) hold large blocks and announce many subprefixes for different regions, services, and customers.
The combination: ~1 million routes for what could theoretically be ~120,000 if everyone aggregated maximally.
Why It Matters: Hardware Limits
Routers don’t just store routes in regular RAM. The fast packet-forwarding path uses specialized memory:
- TCAM (Ternary Content-Addressable Memory) for exact lookups.
- Hardware tables with limited entries.
A backbone router from 2010 might have hardware tables sized for 500,000 routes. When the table grew past that, the router had to either fall back to slower software lookups or upgrade.
This is why the “default-free zone” (the routers that hold the full BGP table without using a default route) requires expensive, high-end equipment. Smaller networks often use a default route (“if I don’t know where to send this, send it to my upstream”) to avoid carrying the full table.
In 2026, modern routers handle 2-3 million IPv4 routes comfortably, with hardware sized for growth. But the architecture’s underlying constraint — that each backbone router holds a copy of the global table — remains.
What Happens If It Keeps Growing?
A few failure modes if the table grew unboundedly:
Older routers become unreachable
Hardware tables fill up. Routes are dropped. Some destinations become unreachable for users behind that router.
Convergence slows
With more routes, BGP takes longer to recompute best paths when something changes. A link failure that previously caused 30 seconds of suboptimal routing might cause 5 minutes.
Costs go up
Bigger forwarding tables mean newer hardware, more memory, more power. Every backbone network operator pays for routing-table growth.
Internet fragmentation
Eventually, some smaller networks might drop the global table entirely, relying on default routes. Functional, but it reduces the granular reachability that makes routing flexible.
The general concern is “BGP routing table growth is a tragedy of the commons” — each individual announcement is cheap to add but the cumulative cost is borne by every backbone router everywhere.
CIDR and Aggregation Pressure
In the 1990s, the routing table was growing fast and there was real fear of “internet collapse.” The response was CIDR (Classless Inter-Domain Routing) and aggressive aggregation rules.
CIDR allowed prefixes of any length (instead of just /8, /16, /24). This let ISPs allocate just-right block sizes to customers and announce a single aggregate covering all of them, rather than dozens of separate /24s.
CIDR worked. Growth slowed dramatically through the late 1990s. Then the IPv4 marketplace, traffic-engineering needs, and multihoming proliferation pushed it back up.
What Operators Do
A few responses by backbone operators to growing tables:
Hardware upgrades
The most common. Newer routers ship with more capacity. Cisco, Juniper, Arista, Nokia all release platforms periodically with higher-capacity forwarding tables.
Prefix filtering
Operators can filter out routes that are obviously deaggregated. A /24 of a /16 you have anyway is redundant. Some operators drop very-long prefixes (/25 and longer in IPv4 are sometimes filtered).
Aggregation incentives
Some networks encourage or require customers to aggregate before announcing. RFC 7454 (BGP Operations and Security) recommends practices.
Looking forward to IPv6
IPv6 was designed with aggregation in mind. If IPv6 grows to be the dominant address family, the IPv4 routing-table problem becomes a legacy concern.
How to See the Table Yourself
A few practical ways:
Public BGP looking glasses
bgp.tools— modern web UI with rich visualization.bgp.he.net— Hurricane Electric’s classic looking glass.- RIPE RIS — RIPE’s routing information service.
These let you query any prefix and see how it’s announced globally.
Public BGP feeds
- RouteViews (
routeviews.org) — Real-time BGP feeds from many vantage points. - RIPE RIS — Same for RIPE.
You can subscribe to these feeds if you want a real-time view of routing.
CAIDA and other research
CAIDA, RIPE Labs, NIST, and similar publish ongoing routing-table statistics. Useful for trend tracking.
What This Means for Application Developers
For most application code, the routing table is invisible. You query DNS, you get an IP, you send a packet, the internet delivers it. The routing table is what makes that happen, but you don’t interact with it.
Where it matters indirectly:
Reachability incidents
When some part of the internet is unreachable, BGP routing issues are a common cause. Recovery times for routing convergence are measured in seconds to minutes.
Geolocation freshness
IP geolocation databases infer location partly from BGP announcements. Recent route changes can cause geolocation to lag.
CDN POP selection
Anycast CDN routing is sensitive to BGP path selection. If routing changes, the POP a user reaches can change unexpectedly.
ASN data quality
ASN classification databases are derived from BGP origin announcements. Hosting providers that announce from new ASes take time to be reclassified.
TL;DR
- The global IPv4 routing table is ~1 million routes in 2026, IPv6 is ~200,000.
- Each backbone router holds a copy in memory and in hardware forwarding tables.
- Growth drivers: multihoming, traffic engineering, IPv4 marketplace deaggregation, sub-allocations.
- CIDR slowed growth in the 1990s but couldn’t stop the underlying pressures.
- Modern routers handle current sizes fine but the architecture is fundamentally O(n) in advertised routes.
- IPv6 was designed for better aggregation. Long-term growth may shift.
- For application developers, the table is invisible — but it underpins reachability, convergence, geolocation freshness.
The routing table is one of the unglamorous-but-essential pieces of internet infrastructure. It’s grown 50x since the mid-1990s and continues to grow today. Whether the architecture scales for another 50x growth without changes is one of the open operational questions in internet engineering. For the protocol that maintains all this, see BGP routing explained; for the ASN level that aggregates the prefixes, what is an ASN.