[150495] in North American Network Operators' Group
Re: do not filter your customers
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Sat Feb 25 02:16:18 2012
In-Reply-To: <4FF16005-0D5E-4E4A-A492-8C8AECCE52B4@arbor.net>
Date: Sat, 25 Feb 2012 02:15:20 -0500
From: Christopher Morrow <morrowc.lists@gmail.com>
To: "Dobbins, Roland" <rdobbins@arbor.net>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Fri, Feb 24, 2012 at 10:52 PM, Dobbins, Roland <rdobbins@arbor.net> wrot=
e:
>
>> X prefixes/packets in Y seconds/milliseconds doesn't keep the peer from =
blowing up your RIB,
>
> How so? =A0If the configured parameters are exceeded, stop accepting/inse=
rting updates until this is no longer the case. =A0Exceptions would be made=
for peering session establishment, it would take effect after that.
>
if the rate is 1/ms ... I can fill the rib in 2million ms ... ~30mins?
Rate alone isn't the problem :( size matters.
>> it does slow down convergence :(
>
> Yes, but is this always necessarily a Bad Thing? =A0For example, this par=
ticular circumstance (and many like it, c.f. AS7007 incident, et. al.) =A0i=
t could be argued that in this particular case, [incorrect? =A0undesirable?=
=A0premature? pessimal?] convergence led to a poor result, could it not?
>
it's not clear, to me at least, that slowing convergence is good. it
seems to me that folk do all manner of 'interesting' things in order
to limit convergence time. People aren't trying to actively make
convergence take longer, that I've seen at least.
>> If you have 200 peers on an edge device, dropping the whole device's rou=
ting 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 any=
thing, but rather refusing to further accept/insert updates from a given pe=
er until the update rate from said peer slowed to within configured paramet=
ers.
>
yup, I think I jumped a bit around, my penalizing every other customer
was a reference to not having any limiting system in place.
>> max-prefix as it exists today at least caps the damage at one customer.
>
> But it doesn't, really, does it? =A0The effects cascade in an anisotropic=
manner throughout a potentially large transit cone.
>
dropping a single customer sucks, dropping an entire edge device is
far far worse.
>> The knobs available are sort of harsh all the way around though today :(
>
> Concur again, sigh.
hurray! sort of.
thanks!
-chris
