What happens when you overshare? A Look into the BGP Maximum-Prefix Feature#

Orlando Eduardo Martínez-Durive — NetAI & IMDEA Networks (work done as a research intern at Cisco ThousandEyes); Antonis Chariton — Cisco

• Why: Everyone configures max-prefix limits, almost nobody knows what actually happens when they're exceeded. This quantifies it over 6.5 months, which turns a superstition into data for setting limits.
• What: Using RIPE RIS RIBs (Jan 1 – mid-July 2025) plus historical PeeringDB data: of 88,223 identified ASes, only 16,351 (18.5%) had PeeringDB entries updated within two years and were analyzable. Findings: only a relatively small number of ASes exceed their advertised limit; on average only a small fraction of peers drop the session when it happens — but there are extreme cases where a network loses >80% of its peers, with obvious connectivity impact. Notably, the authors could not confirm that observed drops were actually caused by the limit being exceeded.
• How: Correlating announced prefix counts against PeeringDB-listed maximum-prefix values over time, plus tracking peer-count changes after exceedance.
• Where applicable: General BGP session-management practice. Big caveat: PeeringDB-listed limits are a proxy for actual peer-side configuration, and the analyzable population is skewed toward networks that maintain their PeeringDB entries. Practical takeaway offered: set peer limits "just slightly higher" than expected, and the open question of per-session limit signaling (à la OPEN extension) is worth community thought.