BGP Filtering

Ben Butler ben.butler at c2internet.net
Tue Jan 15 18:08:53 UTC 2008


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/4372fdf7/attachment.html>


More information about the NANOG mailing list