IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries

Jon Lewis jlewis at lewis.org
Fri Dec 21 23:24:00 UTC 2007

On Sat, 22 Dec 2007, Greenhalgh, John wrote:

> throughout the satellite industry. So if we didn't deaggregate RIR
> blocks, we'd have at least one RIR allocation per discontiguous network
> and so would be contributing the same number of prefixes to the global
> table.

True, but I've seen enough networks that deaggregate because they just 
don't know any better.  If we were to make an exception for every network 
that had reasonable cause to deaggregate, that probably wouldn't scale. 
Relaxing the filters by a few bits might work.  I'll have to run a few 
tests to see what happens to the route savings if I filter on APINC RIR+1 
bit, RIR+2 bits, etc.  The worst abusers are the ones to whom their RIR 
allocations are "collections of class C's" so it may be that there's 
enough savings at RIR+2 to make that worth using as a compromise.

>> I just filtered you (before
>> seeing your message) as we're now filtering APNIC on "RIR Minimums".
> The timing of my mail was pure coincidence. I am assuming that unless
> our immediate Tier 1 upstreams start filtering, we won't see any
> significant degredation as people start implementing these filters.

We don't normally point default anywhere (other than null0), but I knew 
I'd have to before adding the route filter...so you're still reachable as 
long as the networks between us aren't filtering.

For anyone interested, the filter I'm using is the APNIC section of the 
ISP-Ingress-In-Strict filter posted to nanog a few months ago, plus around 
10 additional deny rules that we'd normally have via an input 
distribute-list...since IOS doesn't seem to allow both an input 
distribute-list and input prefix-list on the same BGP peer.

  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

More information about the NANOG mailing list