BGP Route Flap Damping: Penalty, Half-Life, Reuse

Route flap damping assigns a penalty to a prefix every time it withdraws or is re-advertised, suppresses the route while the penalty is above a threshold, and lets it back in as the penalty decays. On paper that reduces churn for the whole internet; in practice the default parameters are aggressive enough that a short outage on one path can keep a perfectly healthy prefix suppressed for an hour. This article explains the arithmetic behind the counters, how to read them, and why tuning - or disabling - is a legitimate design choice.

The Mechanics

1. Penalty assignment: a route that flaps receives an initial penalty - in Cisco IOS the classic value is 1000; Junos raises the figure-of-merit by 1000 for a withdraw and by 1000 again for a re-advertisement (500 when path attributes change).
2. Accumulation: penalties add up, so repeated instability compounds quickly.
3. Suppression: when the accumulated penalty passes the suppress threshold, the route is marked ineligible and withdrawn from advertisement.
4. Decay: the penalty decays exponentially with a configurable half-life - typically 15 minutes - meaning it halves every half-life period.
5. Reuse: once the penalty falls below the reuse threshold, the route becomes eligible again; the hold-down time is a function of half-life, max-suppress and the reuse threshold.

Reading the State

! Cisco IOS / IOS XE
show ip bgp flap-statistics
show ip bgp dampened-paths
clear ip bgp flap-statistics        ! reset counters for a prefix or all
clear ip bgp dampening              ! unsuppress everything

! IOS XR
show bgp dampening parameters
show bgp dampening flap-statistics
show bgp dampening dampened-paths

! Junos
show route damping suppressed
show route damping parameters
show policy-options damping

Numeral parameters are configured with half-life, reuse, suppress and max-suppress-time. A practical Cisco shape is:

router bgp 65001
 bgp dampening 15 750 2000 60
!              |   |    |    └── max-suppress-time (minutes)
!              |   |    └────── suppress threshold
!              |   └─────────── reuse threshold
!              └─────────────── half-life (minutes)

Why Operators Tune It Down or Off

• Peering churn is not always path churn: a single flapping session can damp a large set of prefixes, including prefixes still reachable by other paths.
• Long suppression: with defaults, a prefix can stay suppressed long after the underlying fault is fixed, extending the outage far beyond the failure.
• Measurements and operator consensus: RFC 2439 defines the mechanism, and RIPE-580 and subsequent operational guidance recommend either not damping or using much gentler parameters, because aggressive damping measurably worsened reachability.
• Route reflectors and iBGP: damping does not apply to iBGP routes - it is ignored - so do not expect it to control internal churn.

If You Do Use It

1. Apply to eBGP customer or peer sessions where instability is genuinely undesirable, never to transit paths you cannot verify.
2. Use prefix-length-aware policy (different thresholds per mask length) so a /24 is not punished like a /8.
3. Keep an explicit exemption list for critical prefixes and loopbacks.
4. Monitor show ip bgp dampened-paths continuously; a non-empty list on a stable network means the parameters are wrong, not the network.
5. Document the parameters in your design and alert on suppression events - a silent damped route is invisible in normal BGP monitoring.

Related reading: BGP route dampening penalty and reuse limits, BGP route flap damping explained and BGP neighbour flapping: root causes and fixes.

原文链接：RFC 2439: BGP Route Flap Damping