The Size (in Bytes) of the Internet Routing Table

I have always wanted to know the size of the BGP routing table of the Internet. I think because the number of routes (prefixes) on the Internet changes constantly (CIDR Report, Table History) no one really wants to commit to how much RAM you might need on your Internet facing router when receiving full routes from your ISP. Things like BGP soft-reconfiguration, or multi-homed configurations are going to vary your usage wildly. So I can see why this question might be hard to answer even before we get to how router manufactures might go about storing the routing information they receive.

Well, I’m here to quickly and messily delineate what I have seen very recently (January of 2025, connected to an ISP in the Midwest of the United States).

Here is a breakdown of our routes received and memory utilized (identifiable information changed or redacted):

internetrouter#sh ip bgp sum
BGP summary information for VRF default
Router identifier 4.5.6.7, local AS number 65001
Neighbor Status Codes: m - Under maintenance
  Neighbor    V AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  4.5.6.8     4 65002         243488       421    0    0 00:19:31 Estab   963340 963340

So, we have received and accepted 963,340 prefixes from our ISP’s router. Next, let’s look at our memory utilization via ‘top’ (sorted by %MEM):

top - 14:12:35 up 20 days,  3:16,  2 users,  load average: 6.09, 6.24, 6.51
Tasks: 253 total,   1 running, 252 sleeping,   0 stopped,   0 zombie
%Cpu(s): 75.8 us,  0.5 sy,  0.0 ni, 23.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  31709.2 total,   5540.7 free,  22057.2 used,   6071.2 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   9652.0 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                                                   
 5987 root      20   0   51.3g   1.1g 812192 S   0.3   3.7   2:00.87 Bgp-main                                                                                                                                                                                  
 5356 root      20   0  213.5g 924132 344564 S 631.2   2.8 174431:01 Sfe                                                                                                                                                                                       
 5988 root      20   0   51.0g 899992 647868 S   0.0   2.8   1:03.97 BgpCliHelper                                                                                                                                                                              
 3277 root      20   0 1690644 655896 335180 S   0.0   2.0 117:04.55 ConfigAgent                                                                                                                                                                               
 4171 root      20   0  774948 478140 111528 S   0.3   1.5   2:07.15 KernelFib

The ‘Bgp-main’ process is using 1.1 gigabytes (GB) of memory. To get this down to bytes, we are gonna have to math (I’m assuming 1024 in an order of magnitude, not 1000):
1.1 GB (gigabytes), *1024 =
1126.4 MB (Megabytes), *1024 =
1153433.6 KB (Kilobytes), *1024 =
1181116006.4 B (Bytes)

So… 1181116006.4 Bytes divided by 963,340 prefixes is 1226.063 bytes per route, or 1.2 KB per route.

The quick guestimate then is about 1.1 Gigabytes for a full route table, with 1.2 KB used per entry. Double this if you want soft-reconfiguration, and double that if you have a multi-homed configuration with an iBGP peer that you also do soft-reconfiguration with. Or, said another way:

  • 1.1 GB for a single eBGP peer
  • 2.4 GB for a single eBGP peer with soft-reconfiguration
  • 4.8 GB for a single eBGP peer with soft-reconfiguration and an iBGP peer with soft-reconfiguration in a multi-homed situation

Notes: Yeah, I know I didn’t include the “BgpCliHelper” process. But you can see it, you do the math. Yeah, this math is probably wrong or the logic is wonky; I think this is better than nothing.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.