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.
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.
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.
A: Assuming you have member credentials, you can see your prefix limits here.
A: We can also set a static limit for you, please contact us and state the limit you wish.
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.
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|
|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|