Max Prefix Out, was Re: Verizon 701 Route leak?
Job Snijders
job at instituut.net
Sat Sep 2 17:41:20 UTC 2017
On Sat, Sep 02, 2017 at 12:08:41PM -0400, Christopher Morrow wrote:
> > I think you'll find that some of your peers will make an educated
> > guess and set an inbound limit anyway. Actively requesting that no
> > limit is applied may make one part of a fringe minority.
>
> This is a quick survey of your peers and setting the buckets from
> above at 'sane' limits, right?
yes
> > Speaking as an ISP for ISPs: NTT/2914 applies an inbound
> > maximum-prefix limit on each and every EBGP session.
>
> you can answer this if you want, or not.. but I'm curious, is this
> tuned-per-peer? or via some bucket form as I proposed above? I expect
> ntt COULD per-peer, since I think almost-all-config is auto-generated,
> but I'd be curious still if you decided at the bucket level instead
> because it's saner to think about it that way (for me anyway) or just
> went 'current +N%' for each peer?
I can contribute two examples:
NTT (AS 2914):
We use both approaches. For downstream customers a simple bucket
system is used (currently with just one bucket: 31000 for IPv4, 2000
for IPv6). On the peering side of things the announcement count for
each peer is polled at regular intervals and a +N% limit is set. In
both approaches an override option is available in case someone
emails the NOC "hey, we are about to turn up something big, can you
ensure there is sufficient headroom".
Coloclue (AS 8283):
For every peering partner, data is fetched from the PeeringDB API
and the fields visible here https://www.peeringdb.com/asn/2914 as
'IPv4 Prefixes' and 'IPv6 Prefixes' are used as input into the
router configuration process. Coloclue's formula is simple, if the
field's value is less than 100, set the limit to 100, if the value
is over 100: add 10% to whatever value was published. This process
is executed every 12 hours. In case no PDB record for the ASN
exists: set 10,000 for IPv4 / 1,000 for IPv6. A manual override
mechanism exists.
If I compare the two: NTT's method emphasizes business continuity and
has no external dependencies, Coloclue (being a network for
experimentation) explores how to avoid explicit noc-to-noc coordination
and relies on self-published data being kept up to date.
Whatever your cooking method, maximum prefix limits should never get in
the way of normal operations (e.g. organic growth), but exist only to
try to nip obvious route leaks in the bud. This means one can be quite
generous when picking values.
Kind regards,
Job
More information about the NANOG
mailing list