Dynamic per-AS Prefix Limits

The problem at hand:

Route leaks. Either due to fat fingers, software bugs, or even malicious intent, route leaks are a fact of BGP life. A simple way to deal with the issue is using prefix limits.

Setting a static (fixed) limit to prevent customers from advertising more prefixes than intended does not really work for a route server service: The customer advertising the most prefixes has to be taken as the standard from which the limit is derived.

That leaves all the other customers with a wide margin in which they can freely leak routes; if the limit was set to 15,000, a customer advertising only one prefix could leak 14,999 more before being shut down.

Adding insult to injury, this also has a cascading effect: Other route server peers having set a prefix limit for the session with the route servers, would potentially shut down the session, as they are now seeing thousands of additional prefixes.

Enter dynamic per-AS prefixes:

Since late October 2013, AMS-IX is applying prefix limits specific to the AS connecting to the route server service. For instance, peers advertising only a couple of prefixes will have a maximum prefix limit of 100. Peers advertising thousands of prefixes will be calculated based on an inversely proportional coefficient.

Please see this question for examples and a breakdown of the formula used.

Fluctuations in advertisements are normal and expected. As long as these are within reason, our limits will adapt accordingly (hence "dynamic"). Please also see below FAQ.

FAQ

Q: I'm concerned that the limits for my AS are not big enough!

A: We hate to tear down sessions for no good reason, so rest assured that the limits are sufficiently relaxed. A 2 month lead period in which we were observing peer behavior and fine-tuned the algorithm ensured this as much as possible.

That being said, we value the stability of the service above everything else, so peers advertising suddenly thousands of prefixes when historically they have been advertising only a handful *will* hit the limit. In such cases, please contact us and we will be happy to reactivate the sessions.

Q: What is the prefix limit set for my AS?

A: Assuming you have member credentials, you can see your prefix limits here.

Q: I'm still concerned about the sanity of the limits, though.

A: We can also set a static limit for you, please contact us and state the limit you wish.

Q: Why not use IRRDB objects/RPKI to contain announcements?

A: AMS-IX specifically wants to ensure that the route server service is as stable as possible. Having peers announce unexpectedly large amounts of prefixes wreaks havoc as it tears down sessions for considerable amounts of peers causing CPU churn to all parties involved. This is a different matter compared to the *type* of prefixes advertised.

Cross checking announcements using Internet Resource Registries or other means is something we consider outside of our scope. We strive towards neutrality. Setting aside the route servers as a value added service, AMS-IX is basically, or at least behaves, as a Layer 2 platform, therefore we try to be as Layer 3 agnostic as possible.

Furthermore, IRRDB data is prone to inconsistencies and even more importantly, their usage is mostly limited to the western world. ASes from other regions of the world generally disregard IRRs.

Q: Can you give me examples of how this works?

A: Please consult the tables below:

Announced Prefixes y Coefficient x Prefix Limit (yx < z)
y < 50 2 100
50 < y < 249 2 500
250 < y < 499 2 1000
500 < y < 999 2 2000
1000 < y < 2000 2 - 1,5 next step of 1000
2000 < y < 10000 1,5 - 2 next step of 1000
y > 10000 1,2 next step of 1000
Examples
25 Announced Prefixes x 2 = 50. Limit set to 100
51 Announced Prefixes x 2 = 102. Limit set to 500
300 Announced Prefixes x 2 = 600. Limit set to 1000
900 Announced Prefixes x 2 = 1800. Limit set to 2000
1500 Announced Prefixes x 1,35 = 2025. Limit set to 3000
9000 Announced Prefixes x 1,22 = 10980. Limit set to 11000
15000 Announced Prefixes x 1,2 = 18000. Limit set to 19000