BGP Prefix Calculator
Calculate how many more-specific prefixes result from deaggregating a BGP block, and the routing table impact.
Inputs
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
Values used
Original Prefix Length = 20 /; New (More Specific) Prefix Length = 24 /
More-specific prefix count
more_specifics = 2^(new_prefix − original_prefix)
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
How it works
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
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.