Internet Routing Table Size: What 1M Routes Means

By Savvas Bout, Founder of Prefixx. Last updated 5 October 2026.

Every route announcement your network issues adds one more entry to the global BGP routing table, and that table keeps growing decade after decade.

In the meantime, older boxes hit forwarding table limits. De-aggregated announcements, as expected, add to the totals. Meanwhile, the growing secondary IPv4 market is characterized by an increasing number of specific advertisements announcing newly acquired or rented blocks of IP addresses by companies. This Are announced on the Internet for the first time by the company. These announcements fragment the routing table as organizations seek to advertise their holdings with more specific advertisements tailored to their operational needs.

We dive into the root cause of this increased growth, and its relevance to your routing infrastructure. We also outline the implications when a new IPv4 block is brought online, such as a line card review of the prefix distribution amongst the RIRs as seen through route views. This summary examines both the technical causes and operational consequences of routing table expansion.

We will also highlight the key hardware constraints that influence the router’s routing table size, and some best practices to ensure that your announcements are clean and aggregated rather than contributing to the problem. We start with the basics of what a routing table is, and how a router uses it. Understanding the interplay between routing protocols and hardware capabilities requires careful attention to how modern routers implement forwarding technology.

What is the internet routing system and internet routing table size

The global BGP table is a master list of where to send traffic on the public internet. The table contains hundreds of thousands of routes, each specifying a block of IP addresses and the nearest router to send packets to. Without the routing table, there would be nowhere for packets to travel to their destinations. For community perspectives, see What will the IPv6 routing table look like in a few years.

Rib versus fib: two tables, one job

A router’s knowledge of routing information is maintained in two separate data structures. The Routing Information Base (RIB) contains ALL information received from BGP-speaking neighbors for a destination, including duplicates of the same route and suboptimal paths. When we speak of ‘routing information’ in BGP documents, this is what we mean. The RIB essentially mirrors the full BGP table as seen by that router, storing every path advertisement before the best-path selection algorithm runs.

An active subset of the forwarding information base (FIB) is maintained by the router.

Prefix length and how routes are selected

Each entry in the table is represented by an IP block followed by a / and the prefix length in slash notation (e.g. /24, /20). A longer prefix length means a more specific route. If two routes are covering the same area then the router will take the longest match for that area. This is the longest-prefix-match rule used on every network, everywhere on the internet. The router applies this longest-prefix-match algorithm to determine the most specific route for each destination address.

The next hop field indicates on which peer or interface a router should forward packets. Thousands of autonomous systems announce prefixes in a routing table, each prefix having announced with a next hop. Routers perform a longest-prefix-match search against this table to determine the correct forwarding path for each incoming packet.

Why the BGP table size matters in practice

Many older routers had a limited TCAM memory supporting up to 512,000 routes in the forwarding information base (FIB), and as the global table size grew beyond that, it caused serious problems.

They need to make sure that the assigned IP address space will route cleanly. Prefixx checks the routing hygiene of every block of IP addresses in advance of them being sold by running Tixx quality control. The real question is how big the current table size is and how fast it is increasing. Operators must verify that newly acquired blocks consist of routable addresses that will propagate correctly through BGP peers worldwide.

How big is the entire internet routing table today

The global BGP routing table is dynamic, which is why we report a range instead of a fixed number.

Current BGP table size estimates

The number of routes in the global IPv4 table varies by collector, ranging from roughly 600,000 to 725,000 prefixes.

Average number of prefixes announced by all route views collectors analyzed in this report.

Growth rate and new entries

The BGP data for 2024 IPv4 analysis by APNIC reports a net increase of about 53k new IP addresses (6% growth) in the IPv4 routing table.

What the historical data means for your network

A router today with a full routing table needs memory and forwarding capacity to handle a table size that grows by tens of thousands of prefixes each year. Planning for this sustained growth rate requires operators to evaluate hardware refresh cycles and capacity thresholds well in advance of reaching critical limits.

If you are allocating new address space and want to know where the new block fits in the routing landscape already, Prefixx BGP monitoring through the client portal helps. Origin ASN, prefix length, RPKI validity and IRR consistency can all be monitored from day one using the best data available from RIPEstat.

In order to explain why a routing table has grown to its current size, it is useful to explain the growth to the current size in reverse. The portal allows operators to search routing data by prefix, ASN, or RPKI status to verify announcements before they propagate.

A brief history of routing system and table growth

The Internet routing table has grown exponentially from a few hundred IP addresses in the early 1980s to hundreds of thousands today. The arc above helps explain why the amount of memory on a router and the speed at which a router looks up IP addresses are critical to the continued growth of the Internet and why this growth is a real concern to today’s network operators.

The classful era and the cidr shift

1. Classful routing (pre-1993). This type of routing used to use fixed size buckets for Class A, B and C networks. Each packet would have to be searched in a single large table to determine where to forward it. The size of the table was limited to the coarseness of IP address space allocation.
2. CIDR adoption (from 1993 onwards). By abandoning the fixed class based approach of IP addressing in favor of Classless Inter-Domain Routing using variable length IP address prefixes, for a short while it slowed the growth of routing tables. However, it soon allowed for more ‘specific’ advertisements as people started to cut up the allocated space for their networks into smaller blocks.

Milestone markers with historical data

1. Early allocation data. ACM research found that over the decades of the Internet’s existence there have been some 63,000 address space blocks allocated, a steady stream of new allocations.
2. Hardware crises. The table of IP addresses was growing: 256k, 500k, and 512k routes caused real trouble on routers that didn’t have enough TCAM memory. Every now and then such crises had to be solved by updating hardware of all routers in the industry.

IPv4 exhaustion and deaggregation pressure

1. Free pool closure (2011 to 2020). All 5 RIRs had exhausted their free pools by around this time. As a consequence, IP holders started to split up their blocks in order to sell/lease them in smaller chunks, injecting highly focused adverts into the global table.
2. Sustained growth rate: We have seen the table grow by around 6% per year for the last few years. Therefore memory and forwarding capacity must be planned well ahead of the next threshold.

Note: Deaggregating a block to sell a /24 out of a /22 is operationally valid, but each additional prefix adds load to every transit router worldwide. Aggregate where policy allows.

History shows us the trajectory.

What drives routing table growth

The routing table does not grow because more addresses are added to the address space. It grows because existing address space is split up into smaller pieces and announced via BGP. In order to understand this, it is necessary to realize that every BGP router has to carry and look up every single prefix in hardware. Each time operators split address space into smaller blocks, they generate additional routing entries that every BGP router must process and store.

More specifics, deaggregation, and connectivity degree

Operator traffic engineering of a /20 by splitting it into 16 /24s results in 16 BGP announcements instead of 1. Even though the total amount of announced address space has not changed much, the total number of prefixes has been increasing fast. According to the APNIC IPv4 statistics the IPv4 router table size has increased with about 53k announcements in 2024. 6% of the total span of address space announcements for only a small increase in the actual address space announcements.

Secondary market activity generates a much higher total span of route views and route objects when a /16 is sold as a whole and then leased out in smaller /24 blocks. Every single new holder of an ASN announcing a new block of IP addresses generates even more route objects. The increase in the routing table due to fragmentation of IP address space ownership is exemplified here.

Multihoming pressure and address span

Redundancy for enterprises and ISPs is achieved by multi-homing. A multihomed site announces the prefixes for the site’s connections to two or more upstreams in BGP. If an enterprise is multihomed, it can add several prefixes to the global table, depending on the enterprise’s address space structure. Each upstream provider must accept and propagate those announcements to deliver uninterrupted service during link failures or maintenance windows.

Why hardware makes this a hard constraint

Routers do longest-prefix matching in TCAM (ternary content addressable memory), a very expensive and limited resource. If the routing table exceeds the size of the TCAM then the router will either start dropping prefixes or it will crash. So operators care very much about the number of prefixes they have, quite apart from the total bandwidth or number of addresses in use. Unlike TCAM, ordinary RAM cannot perform the parallel lookups required for wire-speed forwarding at scale.

For most BGP peers, a /24 is the minimum size prefix that is accepted. Larger sized prefixes may be filtered at the edge of a network. Deaggregation therefore tends to cease at /24s rather than continuing down to /25s and /26s.

Understanding what drives growth leads to a natural question of how much of the table a given router needs to hold, and what trade-offs there are to carrying less. Operators must weigh the cost and complexity of carrying a full table against the risk of reachability gaps when assuming partial views will suffice for their traffic patterns.

Why routing table size matters when you bring your own IP space

When you acquire a block, it usually comes with a routing table history. Before you announce it, you should figure out how the history of that routing table affects reachability, filtering and the statistics your peers will see. Routing table history reveals which autonomous systems previously announced the addresses and whether any filtering or reputation issues exist.

Preparation: audit the block's routing footprint

1. For each previously deaggregated block, check for existing routing table entries. It is possible that in the meantime in the BGP table already multiple more specific prefixes for a previously deaggregated block have been announced. Use e.g. longest-prefix matching to determine all announced prefixes within a range of prefixes that have been deaggregated before. These deaggregated routes greatly increase the size of the forwarding information base on every transit router of the world, so it is a good idea to consolidate them before announcing them.
2. Check the length of your prefix. Most peers will filter out longer prefixes than /24. Smaller prefixes like /25 and less will often get dropped at the edge. /24 is the minimum length that will get you any kind of reliable connectivity over the IP routing table.

Execution: align ROA, IRR, and announcement

1. Your RPKI ROA and IRR route objects must match the announced prefix(es) exactly. A mis-match between the announced prefix and the ROA for that announced prefix will mark the route as RPKI-invalid. Many networks will immediately drop such routes. In addition, RPKI consistency with IRR is also very important. A route-object filter on a peer will reject an announced address if there is no matching route object.
2. File the LOA before you announce. Transit providers require a Letter of Authorization to accept your announcement. Note: announcing without a valid LOA on file is the most common cause of rejected sessions at onboarding.

Prefixx prepares the LOA, RPKI ROAs, IRR route objects, and route views as part of its BYOIP deployment support. The technology behind the client portal provides BGP monitoring and RPKI validity checks so you can verify routing health after announcement. Monitoring tools track prefix visibility and measure how quickly the announcement propagates through the global routing system, giving operators insight into the response time of their BGP peers.

Verification: confirm geolocation and routing health

1. Wait a bit for your geolocation to catch up. Geolocation databases for IP addresses are not updated as frequently as routing changes are announced. After the announcement, send corrections to the geolocation providers and wait until they have updated their databases to the correct region. This especially matters if the addresses have been moved between regions served by different RIRs.

Note: skipping the geolocation step can cause traffic to route correctly but land in the wrong country in every database that downstream services query.

Frequently asked questions

Given its growth, what address span do specific advertisements in the routing table now cover?

The global BGP routing table crossed 1 million IPv4 prefixes in 2024 and continues to climb. That figure counts distinct prefixes visible in the default-free zone, the core of the global network where no default route is used. The number varies slightly by vantage point and collector, but major route servers and looking glasses consistently report figures in that range. Growth has been steady for decades, with no sign of plateauing. Operators around the world must account for this growth when planning capacity and selecting hardware capable of handling the expanding table.

What is the growth rate of the internet routing table?

The IPv4 table has grown at roughly 40,000 to 60,000 new prefixes per year over the past several years. Much of that growth comes from prefix deaggregation: operators announcing more-specific /24s alongside their covering aggregates for traffic engineering or multihoming. IPv6 table growth is faster in percentage terms but starts from a much smaller base. There is no technical mechanism that automatically caps growth, so the trend is expected to continue.

How does the growth rate of routing entries differ between the rib and the fib?

The RIB (Routing Information Base) is the full database of routes a router has learned from all BGP peers, including multiple paths to the same destination. The FIB (Forwarding Information Base) is the distilled, hardware-programmed table that actually drives packet forwarding decisions, containing only the optimal route per prefix. Routers execute this selection process by applying BGP path attributes and local policy to determine which route enters the FIB.

A router may hold over a million entries in its RIB but program a similarly sized FIB into its TCAM. TCAM capacity is the hard physical limit: when the FIB overflows it, the router drops routes or crashes, which is why table size is a hardware procurement concern, not just a software one. As the number of routes continues to climb, operators must carefully monitor TCAM utilization to ensure their hardware can accommodate future table growth without service disruption.

Why does routing table size matter for network operators?

Every prefix in the global table must be stored in a router's TCAM, a fast but expensive and capacity-limited memory. When the table exceeds a router's TCAM limit, the device either drops less-specific prefixes or stops forwarding traffic correctly. At this point, operators must either upgrade hardware or implement aggressive filtering to remain operational.

Older line cards and edge routers deployed years ago were sized for a much smaller table and next hop database, and are now at or near their limits. Operators must either upgrade hardware, filter prefixes aggressively, or accept reachability gaps, all of which carry cost or risk. As the number of routes continues to climb, these legacy devices face increasing pressure to maintain full reachability without dropping critical prefixes.

What is the minimum prefix length accepted in the global BGP table?

The de facto community standard is to filter anything longer than a /24 for IPv4 and a /48 for IPv6 at the public network exchange and transit level.

Announcing a /25 or longer is technically possible, but most next hop routers and networks widely filter those prefixes, so they will not reach much of the worldwide web. This convention is one reason the /24 has become the standard unit of IPv4 address trading: it is the smallest block that any specific router in the global table can be relied upon to carry.

How IPv4 trading affects advertised address space and routing table growth

When a large block changes hands in the secondary market, the new owner often updates the next hop and announces it as multiple more-specific prefixes rather than a single aggregate. This happens for legitimate reasons: traffic engineering, multihoming, or because the buyer only acquired part of a larger block. These more specific advertisements allow the new owner to steer traffic independently for each subnet and signal distinct routing policies to upstream providers.

Each additional more-specific adds an entry to the global table. Brokers like Prefixx address this directly by preparing RPKI ROAs, IRR route objects, and LOAs as part of every transfer, ensuring new announcements are clean and correctly scoped to forward traffic from day one rather than contributing unnecessary deaggregation to the table.

A few hundred routing entries for the global network was once the norm. Today over a million prefixes are listed in the global prefix table, which continues to grow with every new network operator, with every PI allocation, with every deaggregated block of IP block.

For your own networks, the decision between a full BGP table, a reduced set of routes and a default route affects the amount of memory your routers need, how fast they converge and the level of traffic engineering granularity you can achieve.

IPv4 address scarcity sits at the center of this growth. As organizations acquire IP range through the secondary market and announce it independently, the total span of prefix counts visible across route views continues to climb. If you are buying, selling, or leasing IPv4 space and need the block properly announced, registered in IRR, covered by an RPKI ROA, and clean before it ever reaches a router, Prefixx handles that paperwork end to end. Start with a block inquiry to see what is available.