BGP Filtering
Dave Israel
davei at otd.com
Tue Jan 15 17:51:28 UTC 2008
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 at ca.afilias.info]
> Sent: 15 January 2008 17:07
> To: Ben Butler
> Cc: nanog at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080115/60398f59/attachment.html>
More information about the NANOG
mailing list