[101679] in North American Network Operators' Group
Re: BGP Filtering
daemon@ATHENA.MIT.EDU (Dave Israel)
Tue Jan 15 13:56:33 2008
Date: Tue, 15 Jan 2008 13:52:31 -0500
From: Dave Israel <davei@otd.com>
To: Ben Butler <ben.butler@c2internet.net>
CC: nanog@merit.edu
In-Reply-To: <F9181128E9584B40B5A04C43800604B406DCE1@anyanka.c2internet.net>
X-OTD-MailScanner-From: davei@otd.com
Errors-To: owner-nanog@merit.edu
This is a multi-part message in MIME format.
--------------040306000609060409060501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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@otd.com]
> *Sent:* 15 January 2008 17:51
> *To:* Ben Butler
> *Cc:* nanog@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@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
>>
--------------040306000609060409060501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
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. <br>
<br>
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.<br>
<br>
-Dave<br>
<br>
Ben Butler wrote:
<blockquote
cite="mid:F9181128E9584B40B5A04C43800604B406DCE1@anyanka.c2internet.net"
type="cite">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16544" name="GENERATOR">
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="168480118-15012008">Hi Dave,</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="168480118-15012008"></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="168480118-15012008">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?</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="168480118-15012008"></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="168480118-15012008">so umm, yes a default would
be needed, ummm.</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="168480118-15012008"></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="168480118-15012008">Is it even technically
possible to easily achieve though?</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="168480118-15012008"></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"
size="2"><span class="168480118-15012008">Ben</span></font></div>
<br>
<div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us">
<hr tabindex="-1"><font face="Tahoma" size="2"><b>From:</b> Dave
Israel [<a class="moz-txt-link-freetext" href="mailto:davei@otd.com">mailto:davei@otd.com</a>] <br>
<b>Sent:</b> 15 January 2008 17:51<br>
<b>To:</b> Ben Butler<br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:nanog@merit.edu">nanog@merit.edu</a><br>
<b>Subject:</b> Re: BGP Filtering<br>
</font><br>
</div>
<br>
Ben,<br>
<br>
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.<br>
<br>
-Dave<br>
<br>
<br>
Ben Butler wrote:
<blockquote
cite="mid:F9181128E9584B40B5A04C43800604B406DCDE@anyanka.c2internet.net"
type="cite">
<pre wrap="">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 [<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="mailto:jabley@ca.afilias.info">mailto:jabley@ca.afilias.info</a>]
Sent: 15 January 2008 17:07
To: Ben Butler
Cc: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:nanog@merit.edu">nanog@merit.edu</a>
Subject: Re: BGP Filtering
On 15-Jan-2008, at 11:40, Ben Butler wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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..
</pre>
</blockquote>
<pre wrap=""><!---->
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".
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
</blockquote>
</body>
</html>
--------------040306000609060409060501--
