Ben, I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. You'd drop traffic, unless you had a default, in which case you'd just route it suboptimally. -Dave Ben Butler wrote:
Hi,
Agreed that is why I have lots of RAM - doesn't mean I should carry on upgrading my tower of babble though to make it ever higher and higher if there is a better way of doing things.
I still don't see how a default route to a portioned pop is going to help in the slightest - you are saved by getting the prefixes from an alternate transit and the default doesn't get used. Where is does help is to capture anything which has been filtered out completely and then there is no prefix from the alternate transit provider anyway - so whichever default gets used and takes its chances.
Bogons - obviously.
My question was if what I was asking was possible.
Kind Regards
Ben
-----Original Message----- From: Joe Abley [mailto:jabley@ca.afilias.info] Sent: 15 January 2008 17:07 To: Ben Butler Cc: nanog@merit.edu Subject: Re: BGP Filtering
On 15-Jan-2008, at 11:40, Ben Butler wrote:
Defaults wont work because a routing decision has to be made, my transit originating a default or me pointing a default at them does not guarantee the reachability of all prefixes..
Taking a table that won't fit in RAM similarly won't guarantee reachability of anything :-)
Filter on assignment boundaries and supplement with a default. That ought to mean that you have a reasonable shot at surviving de-peering/ partitioning events, and the defaults will pick up the slack in the event that you don't.
For extra credit, supplement with a bunch of null routes for bogons so packets with bogon destination addresses don't leave your network, and maybe make exceptions for "golden prefixes".
I am struggling to see a defensible position for why just shy of 50% of all routes appears to be mostly comprised of de-aggregated routes when aggregation is one of the aims RIRs make the LIRs strive to achieve. If we cant clean the mess up because there is no incentive than cant I simply ignore the duplicates.
You can search the archives I'm sure for more detailed discussion of this. However, you can't necessarily always attribute the presence of covered prefixes to incompetence.
Joe