BGP Prefix-Limit: Protect Routers from Route Table Blowups - 夜莺博客

BGP Prefix-Limit: Protect Routers from Route Table Blowups

A single misconfigured peer can announce tens of thousands of prefixes and fill your table, your FIB, or both. Prefix-limit is the guard rail: you tell BGP the maximum number of prefixes acceptable from a peer, optionally with a warning threshold, and what to do when the limit is crossed. Two decisions matter - the limit itself and whether the session is torn down or just stops accepting routes - and both should be made deliberately rather than defaulted.

Choosing the Number

  • Baseline from real data: the peak of show bgp summary per neighbour over 30 days, plus 20-30 percent headroom.
  • Full-table peers roughly follow the global table size; customer and internal peers are fractions of it.
  • A limit that is too tight causes outages during legitimate growth; one that is too loose protects nothing.
  • Set the warning threshold below the hard limit so monitoring fires before the session resets.

Junos Configuration

set protocols bgp group EBGP neighbor 192.0.2.1 family inet unicast prefix-limit maximum 200000
set protocols bgp group EBGP neighbor 192.0.2.1 family inet unicast prefix-limit teardown 90
set protocols bgp group EBGP neighbor 192.0.2.1 family inet unicast prefix-limit log-only

# apply to a whole group
set protocols bgp group TRANSIT family inet unicast prefix-limit maximum 1200000
set protocols bgp group TRANSIT family inet unicast prefix-limit teardown 95
commit check
commit

teardown accepts a percentage of the maximum at which the session is dropped (90 percent here). Without teardown, the peer simply stops being advertised beyond the limit and the session stays up. With log-only, nothing is enforced but violations are logged - the right way to validate a new number before enforcing it.

Cisco IOS-XE / IOS-XR and FRR

! IOS-XE
router bgp 65000
 neighbor 192.0.2.1 maximum-prefix 200000 90 restart 30
 ! 200000 = limit, 90 = warning threshold %, restart 30 = retry after 30 min
 address-family ipv4 unicast
  neighbor 192.0.2.1 maximum-prefix 200000 threshold 90

! IOS-XR
router bgp 65000
 neighbor 192.0.2.1
  address-family ipv4 unicast
   maximum-prefix 200000 90

! FRR
router bgp 65000
 neighbor 192.0.2.1 maximum-prefix 200000 90 restart 30

Note that restart interacts with initial convergence: if the limit is crossed while the peer is still sending its initial table, the reset can loop. Set restart long enough for the peer to recover, or omit it and fix the peer manually.

What Happens When the Limit Is Hit

  • The session is torn down (or capped, if you omitted teardown). Alarms fire, and if this is a transit peer, your traffic moves to the next best path.
  • Wait-and-see is usually wrong: the correct action is to contact the peer, agree the correct number, and only then raise the limit.
  • Log lines to look for: Junos logs prefix-limit exceeded per neighbour; IOS logs %BGP-3-MAXPFX.
  • Do not disable the limit to restore service without understanding why it filled - a peer hitting the limit usually means a leak or a hijack.
show bgp summary | find 192.0.2.1
show bgp neighbor 192.0.2.1 | match prefix-limit
show bgp neighbor 192.0.2.1 | match maximum
show log messages | match prefix-limit
show bgp summary | match Idle && show bgp neighbor 192.0.2.1 | match Last

Complete Guard-Rail Set

  • Prefix-limit plus an inbound filter (prefix list, AS-path filter, RPKI origin validation) - the limit stops volume, the filter stops content.
  • Warning threshold below the limit, alerting in the NMS, and a runbook entry for who calls whom.
  • Max-prefix values in your monitoring template so any new peer cannot be added without one.
  • For iBGP from route reflectors, set a higher limit but never unlimited - a leaking route reflector is just as damaging.

Related: route flap damping for the mechanism that limits repeated churn rather than volume, route reflector design for the iBGP side, and BGP neighbor flapping for diagnosing a session that is already unstable.

原文链接:https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/statement/prefix-limit-edit-protocols-bgp.html