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@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@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)