On Feb 25, 2012, at 9:39 AM, Christopher Morrow wrote: > it seems to me that most of the options discussed for this are .. bad, in one > dimension or another :(
Concur. > X prefixes/packets in Y seconds/milliseconds doesn't keep the peer from > blowing up your RIB, How so? If the configured parameters are exceeded, stop accepting/inserting updates until this is no longer the case. Exceptions would be made for peering session establishment, it would take effect after that. > it does slow down convergence :( Yes, but is this always necessarily a Bad Thing? For example, this particular circumstance (and many like it, c.f. AS7007 incident, et. al.) it could be argued that in this particular case, [incorrect? undesirable? premature? pessimal?] convergence led to a poor result, could it not? > If you have 200 peers on an edge device, dropping the whole device's routing > capabilities because of one AS7007/AS1221/AS9121 .. isn't cool > to your network nor the other customers on that device :( Apologies for being unclear; I wasn't suggesting dropping or removing anything, but rather refusing to further accept/insert updates from a given peer until the update rate from said peer slowed to within configured parameters. > max-prefix as it exists today at least caps the damage at one customer. But it doesn't, really, does it? The effects cascade in an anisotropic manner throughout a potentially large transit cone. > The knobs available are sort of harsh all the way around though today :( Concur again, sigh. ----------------------------------------------------------------------- Roland Dobbins <rdobb...@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
