BGP Prefix Calculator
Calculate the number of BGP prefixes and routing table impact for an address block.
About BGP Prefix Calculator
Deaggregating (splitting) a BGP-advertised block into longer, more specific prefixes multiplies the number of routes announced to the internet's routing table. Each additional bit of prefix length doubles the number of resulting blocks, so the count of more-specific prefixes is 2 raised to the power of the difference in prefix length. Excessive deaggregation is a known contributor to global routing table (DFZ) growth and is often filtered by upstream providers beyond conventional minimum announcement sizes (commonly /24 for IPv4).
Formula
More-specific prefix count
more_specifics = 2^(new_prefix − original_prefix)
- p_new
- New, longer prefix length
- p_orig
- Original, shorter prefix length
Worked example
With the default values below, BGP Prefix Calculator returns Resulting More-Specific Prefixes of 16. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Original Prefix Lengthaccepts 0–32 /
- 20 /
- New (More Specific) Prefix Lengthaccepts 0–32 /
- 24 /
Results
- Resulting More-Specific Prefixes
- 16
- Routing Table Impact
- High — notable routing table growth
- Addresses per More-Specific Prefix
- 256
- Total Addresses in Original Block
- 4,096
Step by step
- 1Values used
- 2More-specific prefix count
- 3Resulting More-Specific Prefixes= 16
- 4Routing Table Impact= High — notable routing table growth
- 5Addresses per More-Specific Prefix= 256
- 6Total Addresses in Original Block= 4,096
Assumptions and limits
- The result is derived only from the 2 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to whole numbers, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why would someone deaggregate a BGP prefix?
Common reasons include traffic engineering (sending different subnets out different upstream links), multihoming with unequal provider preferences per subnet, or working around a provider's policies — though deaggregation purely for traffic engineering is discouraged because it inflates the global routing table for everyone.
Why do many ISPs filter out prefixes longer than /24?
To control the size of the global BGP routing table (the Default-Free Zone), most transit providers refuse to accept or propagate IPv4 prefixes longer than /24 (and IPv6 prefixes longer than /48 typically), since accepting every possible more-specific announcement would make the global table unmanageably large and consume excessive router memory and CPU everywhere.
What is the practical downside of excessive deaggregation?
Every additional announced prefix consumes memory and CPU on every BGP router that accepts it globally, increases convergence time during route flaps, and can trigger route flap damping or outright filtering by upstream providers — the individual operator's local traffic-engineering gain is a shared cost across the entire internet's routing infrastructure.