Setting sensible max-prefix limits

Wed Aug 18 13:21:41 UTC 2021

While there are good solutions in this thread, some of them have scaling
issues with operator overhead.

We recently implemented a strategy that I proposed a couple years ago that
uses a bucket system.

We created 5 or 6 different buckets of limit values (for v4 and v6 of
course.) Depending on what you have published in PeeringDB (or told us
directly what to expect), you're placed in a bucket that gives you a decent
amount of headroom to that bucket's max. If your ASN reaches 90% of your
limit, our ops folks just move you up to the next bucket. If you start to
get up there in the last bucket, then we'll take a manual look and decide
what is appropriate. This covers well over 95% of our non-transit sessions,
and has dramatically reduced the volume of tickets and changes our ops team
has had to sort through.

Of course, we can also afford to be a little looser in limits based on the
capability of the equipment that these sessions land on, other environments
may require tighter restrictions.

On Wed, Aug 18, 2021 at 5:34 AM Lars Prehn <lprehn at mpi-inf.mpg.de> wrote:

> As I understand by now, it is highly recommended to set a max-prefix
> limit for peering sessions. Yet, I can hardly find any recommendations
> on how to arrive at a sensible limit.
>
> I guess for long standing peers one could just eyeball it, e.g., current
> prefix count + some safety margin. How does that work for new peers? Do
> you negotiate/exchange sensible values whenever you establish a new
> session? Do you rely on PeeringDB (if available)? Do you apply default
> values to everyone except the big fishes?
>
> Apart from your peers, do you also apply a limit to your transit sessions?
>
> Best regards,
>
> Lars
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210818/2ba2513e/attachment.html>