North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Max Prefixes Configured on Customer BGP
- From: Richard A Steenbergen
- Date: Thu Aug 15 23:43:27 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 126.96.36.199 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 email@example.com 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 <firstname.lastname@example.org> 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)