Re: Setting sensible max-prefix limits

["Dale W. Carder" <dwcarder () es net>]

Thus spake Chriztoffer Hansen (ch () ntrv dk) on Wed, Aug 18, 2021 at 12:03:51PM +0200:
> On Wed, 18 Aug 2021 at 11:33, Lars Prehn <lprehn () mpi-inf mpg de> wrote:
> > 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?

sadly, this is the state of the art.
 
> If you have automation in place. Another approach is to count the
> received prefix. Store the counted value in a database. Based on the
> avg prefix count over X (time period). Add e.g. 10 - 25 % headroom
> over the avg prefix count and use the calculated value as the
> max-prefix limit?
>
> PeeringDB data (sometimes or often?) be somewhat misleading (in
> contrast to actual avg prefix count) in the sense 'some' networks will
> input a value with headroom percentages already included.

Our code tries all 3:

a) using the max values in peeringdb
b) expand all the routes in the IRR record from peeringdb
b.1) if no object is specified, try to guess if it's named ASnnnnn
c) count the currently received prefixes

Many times the values in peeringdb can be off, or increasingly this is a good 
warning not to peer with a negligent operator.  For some peers 'b' can expand 
to a huge, unrealistic set (not always their fault), so if it's substantially 
larger than 'a' we throw it out.  (c) has proven the most reliable.

The count chosen then fits in the appropriate sized bin and given 30% headroom.
The code compares all this and gives the user a warning that in proactive gets 
ignored for option 'c'.  (For example we can override 'b' with a more appropriate 
object record in our provisioning db)

Dale