Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Max Prefixes Configured on Customer BGP

  • From: Chris Woodfield
  • Date: Fri Aug 16 13:06:11 2002

That's why you make sure that any incidents where max-prefix is tripped is 
caught by a syslog watcher and brought to the immediate attention of whoever's 
sitting in your NOC. Honestly, if all you're dealing with is customer BGP 
session, I would propose that 90% of them don't advertise more than 10 prefixes, 
so a max-prefix number higher than, say, 100 should do for most cases. And for 
that last 10%, max-prefix is a per-session configuration, so that number can always 
be set higher. IMO, advertising 100 routes for 30 seconds is far less damaging 
than 8000 routes.

Also, don't forget about the warn option - if a customer's organic growth puts 
them close to the prefix limit, you should get a heads-up in most cases.

I recall an incident where we brought up a customer advertising around 600 
routes, and sent the prefix list our upstream, who dutifully added all 
600 routes to the prefix list, but neglected to raise their maximum-prefix limit 
from 300. This, of course, had predictable results. Doh.


> 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 <>
> PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

Attachment: pgp00012.pgp
Description: PGP signature

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.