I'd like to share my perspective on the feature. My work does not use MikroTik gear (wrong market segment), however I do use it personally and am a fan. I'm hoping I can at least provide some illumination around what it provides and why we use it. Since my work is probably not the target market for MikroTik, it'll be up to the people here and MikroTik to determine if this feature is important and how the feature applies. I'm just providing an outside perspective.
A little bit about our network -- On the customer side of things, we have BGP neighbor adjacencies with around 200 ASNs (customer-of-customer ASN count is around 1000). On the peer side, we have around 500 settlement-free BGP adjacencies (note: I'm talking with our peering architect to get better numbers, these were a guess on my part). Some are peer networks are cloud/content/cdn providers, some are consumer ISPs, some are networks in other geographies with a similar organization structure.
There are two different kinds of max-prefix-limit settings that we've used in the past, so I'm going to mention both here. The most common one applies to routes that are accepted -- this is the one we use today. The other setting applies to all prefixes, regardless of whether they are accepted or not (as far as I know, this is a JunOS specific feature). Unless stated otherwise, I'm talking about a max-prefix-limit that applies to accepted routes only.
In either case, these features act as a circuit breaker
, both on the control plane and data plane. I want to emphasize the circuit breaker
aspect word. it works a lot like an electrical circuit breaker or fuse -- you have fuses/breakers in smaller devices like your PC, you might have 15/20A circuits for appliances, and 30-50A circuits for heavy appliances like ranges, ovens, air conditioning, etc. They're sized for the use case and protects the wires, the appliances, humans (if it's an RCD/GFCI protected circuit), and sometimes upstream components like the breaker panel itself. Even the breaker-box itself might have a 100-150A fuse or circuit breaker for the whole house. The point being is that this feature is there to protect things locally and also to isolate faults
in a system before that fault can cascade.
max-prefix-limit protects the local router, the entire SP network, and even neighboring networks. Accidental route leaks do happen, RPKI is making those happen less often, but they still do happen and RPKI is not widely deployed - indeed in some network scenarios, RPKI may not be available.
We often have prefix-limits tripped (either at the warning level, or actually shutting down BGP sessions). These are the cases I can think of:
- Misconfiguration that leaks neighbor prefixes - usually this is corrected fairly fast (within an hour). Resetting the BGP session functions to protect our network -- both local router control plane, but also other routers in the network and even backbone links -- Route leaks can shift 100+Gbps of traffic. As a nice side-effect, it's a clear signal to the neighboring network that "something went wrong with your BGP policies".
- Misconfiguration that leaks BGP optimizer injected routes. These can be particularly dangerous because they're often more-specific prefixes that will override every BGP selection criteria.
- Legitimate gradual network growth - We usually hit some alarm threshold (75%) and will increase the session size. This often happens without disruption.
- Legitimate, but significant network growth - Sometimes a merger/acquisition or peering agreement can mean that the neighboring network grew significantly and trips the reset/shutdown threshold. This is one is rare, but it would give us a chance to look at link speeds and ensure that there is sufficient capacity. We've had to drop a % of routes (usually done via routing policy) as we arrange for capacity increases. In one specific case we actually had to use that to convince someone we could saturate the capacity of a link for a period of time before they'd let us upgrade to a faster peering connection.
In all cases we let the BGP session retry after ~15 minutes or whatever the vendor default is. If a neighbor goes over, the BGP neighbor is held in a down state for 15 minutes then allowed to retry. We've found this to be a use-case.
On the private circuit side of things, we provide a small truck load of L3VPNs to customers, and by default we limit it to 50 prefixes. We occasionally see a customer accidentally (try to) leak a full internet routing table into their private L3VPN. Many of the other tools to protect the routing table like RPKI are unavailable since the L3VPN also needs to carry RFC1918 addresses. Here it's absolutely vital to have those protections because of the collateral damage that a flood of routes could cause.
max-prefix-limit may not be as applicable to every network, but as a network moves from sitting at the edge of a network to sitting more at the center, these protections start to become more and more important. It protects the local router's control-plane, other router control-planes, but also protects upstream links by preventing an uncontrolled deluge of traffic being directed in the wrong direction.
Finally, from a dollars and cents perspective even though my work is not in the right market segment for MikroTik, the lack of this feature would most certainly disqualify a vendor from being considered as part of an RFP or purchase. And that's not any single engineer/architect making a unilateral decision. That's just how it is for networks like us.