Summary

  • Maximum-prefix is a capacity and admission control, not a judgment that the route crossing the limit is invalid. With teardown configured, one additional route can remove every route learned through the same BGP session.
  • A sound policy ties the limit to a named peer and address family, a documented counting point, measured growth and headroom, a proportionate enforcement action, and evidence that reaches from the notification to the RIB, FIB and packets.

The line in the log that changes the problem

Imagine a change window in which nothing visibly dramatic happens. No malformed BGP message arrives. No origin-validation alarm fires. The neighbor remains the neighbor the network intended to use. Then one counter crosses a configured integer and the session closes.

That sequence is what makes maximum-prefix different from an ordinary route filter. A filter evaluates something about a route: its prefix, origin, path, community, next hop or relationship. A maximum-prefix policy evaluates the accumulated quantity of state associated with a neighbor. If its action is to terminate, the decision applies at session scale. The announcement that increments the counter may be entirely ordinary, yet the response can withdraw thousands of previously usable routes.

This is not an argument against limits. Accidental full-table exports, explosive deaggregation and unexpected address-family growth can exhaust memory, prolong convergence or make a routing process unresponsive. A finite receiver needs a way to say that it will not accept unlimited state from one source. The argument is that the number cannot carry more meaning than it possesses. It is a budget, and the configured action determines who pays when the budget is exceeded.

What the protocol permits

RFC 4271 allows a BGP speaker to impose a locally configured upper bound on the number of address prefixes accepted from a neighbor. When the bound is reached, the speaker may discard newly received prefixes while maintaining the connection, or it may terminate the BGP connection. If it terminates because the upper bound has been exceeded, it sends a Cease notification.

RFC 4486 makes the reason observable through Cease subcode 1, Maximum Number of Prefixes Reached. Optional data can identify the AFI, SAFI and four-octet bound. That evidence matters because a closed session alone does not reveal whether the cause was an administrative action, a collision, a resource condition or an enforced prefix limit.

The standards deliberately leave the policy inputs local. They do not know whether the neighbor is a customer expected to announce twelve prefixes, a peer expected to announce part of the Internet, or a transit provider expected to deliver a full table. They do not know the receiver's control-plane capacity, the number of alternative paths, or the customer traffic that depends on the session. Local choice is unavoidable. So is local accountability.

A quantity control cannot certify route legitimacy

The route that crosses a threshold is not thereby bad. Legitimate customer onboarding, deaggregation during an incident, a merger of address holdings, a migration or a change in aggregation can increase the count. Conversely, a route leak, invalid origin or commercially improper route can remain below the limit.

Maximum-prefix therefore complements content controls rather than replacing them. Prefix and AS-path filters test declared routing policy. RPKI origin validation provides evidence about whether an origin is authorized for a prefix. Next-hop and community policy constrain how routes are processed. Maximum-prefix asks a narrower question: how much state from this source will be admitted before a specified action occurs?

Calling it a security control is useful only after naming the threatened resource and failure mode. It may protect routing-process memory, convergence time or the rest of a router from an accidental flood. It does not authenticate intent. It does not prove that the final route caused damage. It does not show that the remaining routes are safe. Treating the threshold as a verdict converts a capacity estimate into an unsupported accusation.

The most important setting may be what is counted

The same number can describe different boundaries on different systems.

FRRouting's BGP documentation describes maximum-prefix as counting accepted prefixes by default and, with force, all received prefixes including those rejected by inbound policy. The latter depends on retaining the relevant inbound state. FRRouting also warns that destroying a session is considerably more destructive than rejecting unwanted prefixes.

Junos exposes the distinction through separate controls. prefix-limit applies to received prefixes, while accepted-prefix-limit applies after routing policy has accepted them. Junos documents actions including teardown, dropping excess routes and hiding excess routes, each with different state and recovery consequences.

A pre-policy counter can reveal an attempted full-table export even when a strong import filter would reject nearly all of it. That can protect the cost of receiving and retaining the attempted feed. It can also terminate a valuable session because of state that would never have become a selected route. A post-policy counter aligns more closely with admitted routing state, but may conceal the raw volume that the input path had to process.

There is another ambiguity: prefix count is not always path count. ADD-PATH, VPN families and implementation-specific storage can preserve multiple paths for one destination. The operator must verify the semantics of the running release, not infer them from a familiar command name. A limit whose counter cannot be defined is not a control; it is a surprise generator.

The action determines the blast radius

The threshold receives most of the review, but the action shapes the failure.

Warning preserves the session and the full route set. It creates time for investigation but does not stop growth. Its effectiveness depends on delivery, ownership and response time. An alert that nobody can act on is evidence of observation, not containment.

Dropping excess routes preserves the session and the routes already admitted while refusing later arrivals. This avoids the all-route withdrawal caused by teardown, yet it creates a partial routing view. Arrival order may influence which routes survive. Recovery may require a route refresh or explicit re-evaluation rather than simply waiting for the counter to fall.

Hiding excess routes can retain information for later use while keeping it ineligible for normal selection. That may simplify recovery, but it can also consume the memory the limit was intended to protect. Whether hiding serves the objective depends on the platform's real storage and convergence behavior.

Teardown stops the source decisively. It also removes every route whose only usable copy came from that session. The resulting recalculation may shift traffic onto other peers, increase path length, overrun backup capacity or expose destinations with no alternative at all.

Vendor vocabulary is not a safe substitute for state inspection. Cisco's maximum-prefix guidance documents a warning percentage, default teardown, warning-only behavior and an optional restart interval. Arista EOS documentation describes maximum-route behavior that can disable peering, while warning-only operation can retain peering and drop later routes. Similar labels can therefore lead to materially different residual route sets.

The budget begins with the relationship

RFC 7454 recommends maximum-prefix limits sized to the peering relationship. A limited peer's threshold may sit below the full Internet table so that an accidental full-table export triggers protection. A transit provider intentionally delivering full routing requires a ceiling above the expected table, but still below the amount the receiver can safely handle.

This yields a practical design equation, though not a universal number. Start with the route set justified by the relationship. Add observed variance and credible growth. Include planned customer additions, normal deaggregation and migration behavior. Compare the result with platform capacity and with the service cost of the configured action. Then assign a review date and an owner.

RFC 4778 emphasizes coordination about the expected number of prefixes and sufficient padding for valid swings. A threshold that is technically enforced but commercially unknown is likely to turn normal change into an avoidable outage. RFC 7454 also makes periodic review essential because route populations evolve.

Headroom is better expressed as time and variance than as a copied percentage. Twenty percent may represent years for one relationship and days for another. Too little headroom makes the safeguard brittle. Too much turns it into decoration. The objective is not to maximize distance from the limit; it is to preserve enough decision time without accepting state the receiver cannot support.

Recovery needs evidence, not just a timer

An automatic restart interval can shorten a transient interruption. It can also automate a loop: establish, receive the same oversized set, exceed, close, wait, repeat. A briefly established session between failures is not recovery.

Elapsed time does not prove that the sender withdrew the surplus or repaired its export policy. A defensible restart should be supported by a changed condition: confirmed withdrawal, corrected filtering, an intentionally approved new limit, or a capacity change. Manual clear is not automatically safer; without recorded evidence it is merely a human-triggered retry.

RFC 8538 suggests that a maximum-prefix Cease condition should be treated as a hard reset in Graceful Restart behavior. The distinction prevents deliberate route-volume enforcement from being obscured by stale-route retention as if the neighbor were undergoing a routine restart. The recovery mechanism should preserve the meaning of the enforcement event, not make its service impact harder to observe.

Prove the path from counter to packets

A configuration screenshot proves only intended syntax. A complete case file needs to connect the limit with its operational result.

First, preserve the effective peer and AFI/SAFI configuration, including group inheritance and warning settings. Record the running software release and authoritative documentation for its received-versus-accepted and path-versus-prefix semantics. Capture current count, recent peak, growth rate and the exact warning crossing.

Second, capture enforcement: last accepted update, counter transition, Cease code and subcode, optional AFI/SAFI/bound data, session state, retry timer and logs that may have been rate-limited. Distinguish routes discarded, hidden, retained and withdrawn.

Third, follow reachability. Identify the exact destinations whose selected paths changed. Verify alternative candidates in the RIB, installation in the FIB and capacity on the interfaces that inherit the traffic. Run packet canaries for critical destination classes. Equal route totals before and after recovery do not prove equal prefixes, attributes or next hops.

The control succeeds only when two claims are simultaneously true: the named resource remains within its safe objective, and the resulting service state matches the trade-off the organization approved. The counter by itself proves neither.

Sources