genuity - any good?

David Schwartz davids at webmaster.com
Sat Apr 13 00:23:04 UTC 2002




On Fri, 12 Apr 2002 20:00:37 -0400 (EDT), Sean Donelan wrote:

>On Fri, 12 Apr 2002, Roy wrote:
>>Registering is not "bad", its just not beneficial.  Given that the routes I
>>want
>>to announce are within my assigned range, why is it a good thing to
>>register
>>them?  If the transit provider always add entries when I ask for them, it
>>seems
>>to be very little benefit..

>The simple reasons is some people (or their buggy router) deaggregated
>multiple Class B's or A's and broke some upstream providers.  You can
>blame whomever you want, but registration gives the user a chance to
>notice a typo resulted in 65,535 routes before actually announcing all
>those routes.  No, it doesn't stop a malcious router engineering.  But
>it is a nice "defense in depth" or "speed bumb" for dumb mistake(tm)
>prevention.

	There are certainly reasonable and unreasonable cases one can imagine. 
Someone with a single /20 who wants to be able to advertise /24s or larger 
from within his block is (probably) a reasonable request. Someone with a /16 
who wants to be able to advertise down to /32s within his block is 
unreasonable, especially if he expects his provider to advertise these routes 
to its peers/providers.

	One common need for advertising small routes within large blocks is dealing 
with dos attacks. If you have, say, 4 100Mbps circuits, and 1.2.3.4 is being 
DOSed, you can advertise nothing but 1.2.3.4/32 on one of the circuits and 
the DOS is now clamped at 100Mbps and everything else will be fine. However, 
it's hard to work out in advance how not to propogate the route outside the 
appropriate scope and how to do this without special arrangements for that 
particular IP while still not allowing every customer you have to advertise 
/32s for every IP they own.

	The moral is, negotiate a reasonable BGP policy before you pay/sign. Make 
sure what seems reasonable to you also seems reasonable to your (prospective) 
provider.

	DS





More information about the NANOG mailing list