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