BGP Filtering

Dave Israel davei at otd.com
Tue Jan 15 18:52:31 UTC 2008


The /17 isn't sitting there still being filtered; it was never there to 
begin with.  Your router heard the /17, saw that it didn't want it 
because of your filter settings, and promptly forgot it.  You can tell 
your router to remember routes it doesn't install; it's called soft 
reconfiguration on a Cisco and is the normal mode of operation for a 
Juniper.  But if you do that, you're not saving memory; an inactive 
route does not take less RAM than an active one. 

I am pretty sure that there isn't a way to match a route on whether a 
larger aggregate exists using the current route map/policy statement 
verbage on the routers I have worked with.  Doing so would be a 
reasonably simple code tweak, but without a purpose it isn't a tweak 
you're going to see any time soon.

-Dave

Ben Butler wrote:
> Hi Dave,
>  
> Yes that is what I was thinking I want to do - so I am guessing here - 
> I think what we are saying is the /17s never get re-added when the /16 
> is withdrawn because this does not - for very good reasons when I 
> think about it- cause the filter to be evaluated upon the withdrawal 
> of a prefix, only on when it is newly announced does it get checked - 
> or maybe the odd table scan in the code?? But basically the /17s just 
> sit there and continue to be filtered.  Is that approximately correct?
>  
> so umm, yes a default would be needed, ummm.
>  
> Is it even technically possible to easily achieve though?
>  
> Ben
>
> ------------------------------------------------------------------------
> *From:* Dave Israel [mailto:davei at otd.com]
> *Sent:* 15 January 2008 17:51
> *To:* Ben Butler
> *Cc:* nanog at merit.edu
> *Subject:* Re: BGP Filtering
>
>
> 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/5433b96f/attachment.html>


More information about the NANOG mailing list