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 <lpr...@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 > > >
