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