Day 55 — BGP Maximum-Prefix Controls and Safe Threshold Design

1. Opening

Maximum-prefix is one of the simplest controls that can prevent a peer from overwhelming a routing table or accidentally sending far more routes than the relationship should carry. Its simplicity is also its danger: a threshold chosen without a route-count model can turn normal growth into an avoidable outage.

The recurring design principle in this security block is fail safely without confusing safety with availability. A routing control can prevent a leak and still cause an outage if thresholds, recovery logic or operator assumptions are wrong. The engineer must therefore define both the threat being contained and the service consequence of containment.

2. Concept and standards behavior

RFC 7454 recommends a maximum-prefix limit on peerings. Cisco IOS XE applies the limit per neighbor and address family. Cisco documents session termination as the default behavior when the configured maximum is exceeded, with recovery requiring operator action unless restart/warning behavior is configured. The correct limit is therefore an operational contract, not a random round number.

Protocol behavior, standards recommendations, vendor implementation and local routing policy are deliberately separated. A standards document may define a capability or validation state; the router still needs explicit configuration to decide what operational action follows.

3. Scenario

Transit-A should send approximately 12 lab prefixes to AS65010. Configure a maximum of 15 with an early warning threshold. Transit-B sends only a default route and a small management prefix set, so it receives a much lower limit.

Common lab topology

Customer AS65010 ---- Edge-1 ---- Transit-A AS65020
          |              |
          |              +---- Transit-B AS65030
          |
      203.0.113.0/24

Documentation prefixes and private ASNs are used throughout. The topology is intentionally small enough that every prefix and policy decision can be traced manually.

Success criteria

1. The protection mechanism detects the intended unsafe condition.
2. Normal routes remain reachable during the healthy state.
3. The failure action is predictable and documented.
4. A negative test proves that an unauthorized route or state is rejected/contained.
5. Rollback restores the captured baseline without weakening unrelated controls.

4. Topology diagram

A matching SVG and PNG are stored in media/diagrams/.

5. Prerequisites

• IOS XE 17.18.x documentation baseline.
• Stable eBGP sessions.
• Explicit prefix inventory and expected route counts where applicable.
• Independent management access.
• Logging and time synchronization.
• For RPKI labs: a separate validator/cache is assumed; no private keys or real production ROAs are distributed.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

router bgp 65010
 address-family ipv4
  neighbor 192.0.2.1 maximum-prefix 15 80
  neighbor 198.51.100.1 maximum-prefix 5 80
 exit-address-family
!
! Verify exact restart/warning-only options on the target image before use.

Any command whose exact support differs by platform must be checked against the target image before execution.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast neighbors
show logging

Topic-specific verification may add show bgp ... dampening, RPKI cache/validation output, received-prefix counts or neighbor capability/policy detail. The important question is always: what evidence proves the mechanism is acting on the intended object?

8. Controlled modification

Increase the simulated Transit-A route set from 12 to 14. The warning threshold should be crossed without exceeding the hard maximum. Then revert to 12 and confirm normal state.

Predict the effect on the BGP session, Loc-RIB, Adj-RIB-In/Out and forwarding state before applying the change.

9. Fault injection

Illustrative lab — not a real incident.

Advertise 16 prefixes from Transit-A. Observe the documented maximum-prefix failure behavior, logs and session state. Do not clear the neighbor until evidence is captured.

Inject exactly one fault and preserve the pre-fault evidence. Do not change multiple safety controls simultaneously.

10. Step-by-step troubleshooting

1. Confirm the affected peer and prefixes.
2. Confirm the BGP session state.
3. Confirm the expected baseline route count or route set.
4. Inspect the configured safety/validation mechanism.
5. Determine whether the mechanism changes state, rejects routes, or resets a session.
6. Inspect logs/NOTIFICATIONs/validation status.
7. Distinguish protocol state from operator policy.
8. Verify forwarding separately from BGP-table presence.
9. Test the approved positive case.
10. Test the forbidden/invalid case.
11. Correct the smallest proven cause.
12. Re-run the same evidence set and observe stability.

11. Root cause and correction

The configured hard ceiling was exceeded. If the peer's route set was legitimate, the root cause is bad capacity planning; if the extra routes were accidental, the control worked as designed. Correct either the peer advertisement or the approved threshold—do not simply raise it until the session stays up.

12. Post-fix verification

Verify BGP state, accepted prefix count, selected path, validation/policy state where relevant, forwarding, negative containment and recovery behavior.

13. Rollback

Restore the exact previous safety threshold or policy. Preserve evidence before clearing sessions. If rollback would re-open a known leak path or accept invalid routing data, use an approved temporary containment policy rather than blindly removing the control.

14. Deep-dive engineering notes

Threshold engineering

A usable threshold is derived from the relationship. A customer that is authorized to advertise two prefixes should not get a full-table-sized limit. A transit peer carrying the Internet table needs headroom for normal growth and transient path behavior.

Warning versus hard action

An early warning creates time to investigate before the hard action. Monitoring should alert on both absolute count and percentage of limit. A limit that is never monitored is only a future outage trigger.

Restart behavior

Automatic restart can improve availability after a transient overshoot, but it can also create repeated session flapping if the peer continues sending too many routes. Model the behavior before enabling automatic recovery.

Address-family scope

IPv4 unicast, IPv6 unicast and VPN families can have very different expected counts. Do not copy one numeric threshold across address families.

Dynamic neighbors

If maximum-prefix is combined with dynamic-neighbor persistence/restart features, verify Cisco's timer interaction and avoid conflicting recovery timers.

15. Production lessons

• Size limits from measured/contracted route expectations plus documented growth margin.
• Alert before the hard threshold.
• Treat an exceeded limit as an incident requiring evidence, not an invitation to raise the number.
• Keep separate limits per relationship and address family.
• Document manual versus automatic recovery behavior.

16. Knowledge check

1. What failure mode is this control designed to contain?
2. What is the service consequence if it triggers incorrectly?
3. What evidence proves the control worked without causing unintended collateral damage?

Answers

1. The topic-specific leak, instability, invalid-origin or excessive-route condition.
2. Depending on the mechanism: route suppression, loss of prefixes, session shutdown or policy rejection.
3. Compare logs, route counts/validation state, forwarding and negative tests against the documented baseline.

17. Sources

• RFC 7454 — BGP Operations and Security, Section 8 (maximum prefixes)
• Cisco IOS XE 17.x — BGP Maximum-Prefix on IOS XE
• RFC 4271 — BGP-4