Max Prefixes Configured on Customer BGP

Richard A Steenbergen ras at e-gerbil.net
Fri Aug 16 03:41:17 UTC 2002


On Thu, Aug 15, 2002 at 11:12:00PM -0400, Jared Mauch wrote:
> 
> warning: operational content

Thank you Jebus!

> 	in 12.0(22)S there was a new max-prefix feature added that
> people running this software (or similar) can enable to shut down
> your customers who leak routes.
> 
> 	Most customers don't advertize 8k prefixes, so a simple
> setup like this:
> 
> (config-router)#nei 1.2.3.4 maximum-prefix 8000 restart ?
>   <1-65535>  Restart interval in minutes
> 
> 	and configure some reasonable number of minutes (lets say 15)
> and the session will come back up for them and flap again until they
> fix it.
> 
> 	- Jared
> 
> (follow-ups should probally go to cisco-nsp at puck.nether.net or a similar
> cisco specific related list)

This isn't a terribly cisco-specific reply so I'll keep it here.

The problem with restart systems (btw thank you cisco for finally adding
this)  is, think about how much damage can be done by announcing 8k routes
for the 30 seconds (or 5-10 minutes if there is a Foundry in the mix :P)
before you get to the limit and kill the session. Now add in the damage 
caused by this happening every 15 minutes, and the dampening. Or even 
worse, someone who turns up more routes and happens to hit right around 
the exact number or close to it. Imagine a session which goes over by 1 
route, trips, stays down for 15 minutes, comes back up and this time has 1 
less route, and noone notices the prefix limit needs to be raised. You 
should make sure that the restart time exceeds the number/length of flaps 
necessary to trigger dampening, which on a connect you transit is pretty 
darn hard to accurately guess.

IMHO, using only prefix limits on a customer is actually doing them (and
the rest of the internet that listens to your announcements) a disservice.

A better system might be where the session is kept up (or periodically
polled, if you want to make it obvious to the other party that there is a
problem) without installing the routes, and kept in a "quarantine" state
for X amount of time to make sure that things stay below a configured
number. This would be at least a slightly better way of recovering quickly
once the "problem" has passed, without mucking things up every 15 minutes 
in the process.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)



More information about the NANOG mailing list