Re: Setting sensible max-prefix limits

[Jon Lewis <jlewis () lewis org>]

On Wed, 18 Aug 2021, John Kristoff wrote:

> On Wed, 18 Aug 2021 11:33:09 +0200
> Lars Prehn <lprehn () 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.
>
> Maybe because there isn't a simple, universal approach to setting it.
> Probably like a lot of people, historically I'd set it to
> some % over the current stable count and then manually adjust when the
> limits were about to be breached, or often was the case when they were
> and I wasn't ready for it. Not ideal.

We tackled this problem at $work recently after I wrote some code to audit 
configured prefix-limits and found how inconsistent we were.  My guess 
was, this was due to combination of each engineer "doing their own thing" 
with regard to how to set prefix-limits based on what was published in 
peeringdb and growth (peers increasing the suggested limits over time, 
after we'd configured [some of] their sessions).

The solution I implemented was:

In the script that builds peering config, fetch the peer's suggested 
limits from peeringdb via API (I still miss the open mysql access).

Multiply those values by 2.

If that's too close to the "full table size", try suggested limits * 1.5.

If that's still too close to the "full table size", just use the suggested 
limits.

> I've never felt the automation of this setting however was worth the
> effort.  Of course I am not usually responsible for hundreds of routers
> and thousands of peering sessions.

Yeah...that changes things when you have thousands of peering sessions to 
maintain.

> At the risk of advocating for more junk in BGP or the RPKI, a max prefix
> setting might be something that could be set by the announcing peer in
> a BGP message, or possibly as an RPKI object with an associated ASN.

It actually sounds like a cool feature, and could be implemented entirely 
on the sender's side.  i.e. You configure a peer with a self-imposed limit 
of 1000 routes.  If you screw up your routing policy facing that peer and 
leak the full table, once you hit 1001 advertised routes, your router's 
BGP process terminates the session.

Who hasn't had a new peer leak full routes to them at least once?

Who hasn't configured a new peer, only to have them immediately trip your 
prefix-limit because they haven't updated peeringdb for "some time" and 
advertise more routes than their suggested limits?

----------------------------------------------------------------------
 Jon Lewis, MCP :)           |  I route
 StackPath, Sr. Neteng       |  therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________