[150487] in North American Network Operators' Group
Re: do not filter your customers
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Fri Feb 24 21:40:30 2012
In-Reply-To: <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
Date: Fri, 24 Feb 2012 21:39:37 -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 9:12 PM, Dobbins, Roland <rdobbins@arbor.net> wrote=
:
>
> On Feb 25, 2012, at 8:59 AM, Christopher Morrow wrote:
>
>> max-prefix already exists... sometimes it works, sometimes it's a burden=
.
>
> Some sort of throttle - i.e., allow only X number of routing updates with=
in Y number of [seconds? =A0milliseconds? BGP packets?] would be more usefu=
l, IMHO. =A0If the configured rate is exceeded, maintain the session but st=
op accepting further updates until either manually reset or the rate of upd=
ates falls back within acceptable parameters.
it seems to me that most of the options discussed for this are .. bad,
in one dimension or another :(
typical max-prefix today will dump a session, if you exceed the number
of prefixes on the session... good? maybe? bad? maybe? did the peer
fire up a full table to you? or did you just not pay attention to the
log messages saying: "Hey, joe's going to need an update shortly..."
X prefixes/packets in Y seconds/milliseconds doesn't keep the peer
from blowing up your RIB, it does slow down convergence :(
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 :( max-prefix
as it exists today at least caps the damage at one customer.
The knobs available are sort of harsh all the way around though today :(
-chris
