Calculate the number of BGP prefixes and routing table impact for an address block.
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).
More-specific prefix count
more_specifics = 2^(new_prefix − original_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.
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.
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.