BGP Route Flap Damping Explained: Penalty and Timer Tuning

BGP route flap damping is a mechanism that protects routers from unstable neighbors that keep advertising and withdrawing the same route. Every flap forces a router to process a BGP UPDATE and to re-run best-path selection, and in the worst case this churn is propagated across the whole Internet. Damping assigns a penalty to a flapping route and temporarily suppresses it when the penalty crosses a threshold, which stabilizes routing tables and reduces CPU load. This article explains the penalty model, the default timers, how to configure damping on Cisco IOS and Junos, and why operators must tune it carefully today.

Most engineers learn damping from a textbook that still quotes the 1990s numbers. Those numbers are why a generation of operators switched damping off entirely. This guide is the practical follow-up: what RIPE-580 and RFC 7196 actually changed, how to derive the right values instead of copying them, and a step-by-step tuning procedure that keeps a well-connected customer from being punished for normal convergence.

How Route Flap Damping Works

Each time a route is withdrawn and re-advertised (a flap), the router adds a penalty of 1000 to that route. The route is suppressed - removed from the routing table and not advertised to neighbors - once the penalty exceeds the suppress limit (2000 by default on Cisco IOS). The penalty then decays exponentially: after one half-life period (15 minutes by default), the penalty is halved. When the penalty falls below the reuse limit (750 by default), the route is reused and advertised again. The maximum suppress time (60 minutes) caps how long a route can stay suppressed even if it keeps flapping.

The penalty is not only added on withdrawal, and the details differ per vendor. RFC 7196 records the constants that a cross-vendor deployment has to live with:

• Withdrawal (W): 1000 on both Cisco and Juniper
• Re-advertisement (RA): 0 on Cisco, 1000 on Juniper
• Attribute change: 500 on both platforms

The Cisco and Juniper disagreements matter operationally. With the same suppress threshold, a Junos router accumulates penalty roughly twice as fast on a flapping prefix as an IOS router that only counts withdrawals, so identical "default" configurations do not produce identical damping behaviour. That vendor divergence is precisely the problem RIPE's early documents set out to solve.

BGP Damping Parameters and Defaults

• Penalty per flap: 1000
• Suppress limit: 2000 (route is dampened above this value)
• Half-life: 15 minutes (penalty reduced by 50% per interval)
• Reuse limit: 750 (route usable again below this value)
• Max suppress: 60 minutes

Once the penalty drops below 50% of the reuse limit, the penalty is removed from the route entirely. Cisco and Juniper ship the same half-life, reuse limit and max-suppress time, but different suppress thresholds: 2000 on Cisco IOS against 3000 on Junos. Junos also raises the penalty on re-advertisement, so its effective aggressiveness is higher than the number alone suggests.

Configuring BGP Dampening on Cisco IOS

Enable dampening globally, or use a route-map to dampen only selected routes:

router bgp 65000
 bgp dampening
 !
 ! selective dampening with a route-map:
 bgp dampening route-map DAMPEN-CUSTOMER-PREFIXES

route-map DAMPEN-CUSTOMER-PREFIXES permit 10
 match ip prefix-list CUSTOMER-PREFIXES
 set dampening 15 750 2000 60

The route-map form sets half-life reuse suppress max-suppress respectively. Verify with show ip bgp dampened-paths, and clear the history with clear ip bgp dampening.

Note the scale of the penalty values. The thresholds are integers, not percentages, and IOS silently refuses configurations that are internally inconsistent - if the ceiling implied by the four values cannot reach the suppress threshold, the route can never be damped and the router may commit a configuration that does nothing at all.

Damping Parameters on Junos OS

Junos applies flap damping through routing policy. Default values are a half-life of 15 minutes, max-suppress of 60 minutes, reuse of 750 and a suppress threshold of 3000. To customize, define a damping profile and reference it with a damping action:

set policy-options damping DAMP-CUSTOMER half-life 15
set policy-options damping DAMP-CUSTOMER reuse 750
set policy-options damping DAMP-CUSTOMER suppress 3000
set policy-options damping DAMP-CUSTOMER max-suppress 60

set policy-options policy-statement DAMP-IN term 10 from protocol bgp
set policy-options policy-statement DAMP-IN term 10 then damping DAMP-CUSTOMER

set protocols bgp group EBGP import DAMP-IN

Note that by default Junos does not apply damping to internal BGP routes; since Release 12.2 you can enable it per address family if required. Routing policy gives Junos an advantage over IOS here: a damping profile can be attached to a specific BGP group or even a specific neighbor, so a transit customer with a history of flapping can be damped aggressively while an internet exchange peer is left untouched.

From RIPE-229 to RIPE-580: why the old advice died

Damping did not fail because the idea was wrong. It failed because the recommended parameters were wrong, and the story is worth knowing because it explains the numbers you are about to configure.

• 1998 - RIPE-178: the routing working group published coordinated damping parameters so that every ISP treated flapping prefixes identically. RIPE-210 and RIPE-229 followed; the RIPE-229 values became best current practice in 2001.
• 2002 - Mao et al., SIGCOMM: "Route Flap Damping Exacerbates Internet Routing Convergence" showed that damping can delay convergence rather than improve it, because suppressed routes stay suppressed while the topology has already recovered.
• 2006 - RIPE-378: the working group formally recommended disabling route flap damping. It created more harm than good. Many large networks turned it off, and a whole generation of engineers never learned the feature.
• 2011 - Pelsser et al., PAM 2011: measurement work showed that a tiny minority of prefixes causes a disproportionate share of all BGP updates, and that the damage came from the suppress threshold being far too low - not from damping itself.
• 2013 - RIPE-580: damping was declared usable again, but only with substantially higher suppress thresholds.
• 2014 - RFC 7196: the IETF published the same conclusion as a standards-track document and added a hard requirement about the internal maximum penalty value.

The measurement finding is the whole argument. In a one-week experiment with real feeds from a Tier-1 provider and an internet exchange, roughly 3% of prefixes produced 36% of all BGP messages, and just 0.01% of prefixes produced 10%. Damping should target those prefixes and nothing else. The default suppress threshold of 2000 targets everything.

What RIPE-580 and RFC 7196 actually recommend

Strip away the history and the recommendation is four sentences long:

1. Raise the internal maximum penalty to at least 50,000. This is a vendor implementation constant, and it is a MUST in RFC 7196.
2. Do not change the default configurable values. RFC 7196 explicitly says implementations SHOULD NOT change their defaults, so that existing operational configurations keep behaving as before.
3. Minimum suppress threshold: 6000. Operators who want damping that is much less destructive than the current behaviour but still somewhat aggressive configure a suppress threshold of no less than 6000.
4. Conservative suppress threshold: 12000. Conservative operators configure a suppress threshold of no less than 12000.

RIPE-580 adds the same recommendation from the vendor side: raise the maximum suppress threshold that a router can represent to 50,000, and suggest 6000 as a new default. It also notes the trade-off honestly - raising the threshold increases the forwarding table size and announcement rate for operators who currently rely on the aggressive default.

RFC 7196 adds one optional feature worth asking your vendor for: a calculate but do not damp test mode, where the router scores every prefix according to a proposed configuration without actually suppressing anything. That is the safest way to choose parameters, because you can measure what your policy would have done before you let it drop traffic.

The measured case for a higher suppress threshold

The Pelsser 2011 data, reproduced in RFC 7196, shows how quickly the collateral damage falls away as the threshold rises. The damped-prefix column is the part that matters: it is the share of the table your damping policy would have punished.

Read the second and fourth columns together. Moving from 2000 to 6000 still removes about 81% of the churn that damping was designed to remove, but it cuts the number of damped prefixes by a factor of ten. Moving to 12000 keeps roughly 89% of the churn reduction while damping fewer than a quarter of a percent of the table. The old default was not buying much extra stability; it was buying a lot of reachability risk.

Calculating the maximum penalty ceiling

This is the part most tuning guides skip, and it is where misconfiguration hides. Implementations do not let the penalty grow without bound. RFC 2439 defines the ceiling as an exponential function of the other parameters:

ceiling = reuse_limit * 2^(max_suppress_time / half_life)

Substitute the Cisco defaults (reuse 750, half-life 15, max-suppress 60) and you get 750 * 2^4 = 12,000. That is the highest penalty the router can ever accumulate, and it explains why the default suppress threshold of 2000 "works": 2000 sits comfortably below the 12000 ceiling. You can see the value directly with show ip bgp dampening parameters, which prints a Max suppress penalty field.

The consequence for RIPE-580 adoption is immediate and easy to miss. If you raise the suppress threshold to 12000 while leaving the defaults alone, the suppress threshold equals the ceiling. A route would have to accumulate a penalty of exactly 12000 to be damped - and in practice it will be reused first. Configure reuse 750, half-life 15, max-suppress 60 together with suppress 12000 and your new policy is a no-op that looks correct in the running configuration.

To satisfy RFC 7196's 50,000 requirement with the default half-life and reuse limit, solve for the max-suppress time:

2^(T / 15) >= 50000 / 750 = 66.67
T / 15 >= log2(66.67) = 6.06
T >= 90.9 minutes  ->  use 105 minutes (7 half-lives)

check: 750 * 2^7 = 96,000  >= 50,000

Two ready-made profiles fall out of this arithmetic. Both keep the conventional 15-minute half-life and the 750 reuse limit, so the decay behaviour that operators already understand is unchanged:

• Aggressive-but-usable (RIPE-580 minimum): 15 750 6000 105 - ceiling 96,000, suppression lasts about 45 minutes (15 * log2(6000/750) = 45).
• Conservative: 15 750 12000 105 - ceiling 96,000, suppression lasts about 60 minutes (15 * log2(12000/750) = 60).

Step-by-step: RIPE-580 values on Cisco IOS

Do not enable damping for the whole address family. Scope it to the prefixes that actually deserve it - customer and transit space where you are the one absorbing the churn.

! 1. identify the space you are willing to damp
ip prefix-list DAMP-CANDIDATES seq 10 permit 203.0.113.0/24 le 24
ip prefix-list DAMP-CANDIDATES seq 20 permit 198.51.100.0/24 le 24
!
! 2. build the policy with RIPE-580 minimum values
route-map DAMP-RIPE580 permit 10
 match ip address prefix-list DAMP-CANDIDATES
 set dampening 15 750 6000 105
!
! 3. attach it - never use bare "bgp dampening" in production
router bgp 65000
 bgp dampening route-map DAMP-RIPE580
 bgp log-neighbor-changes
!
! 4. verify before you trust it
show ip bgp dampening parameters
show ip bgp dampened-paths
show ip bgp dampening flap-statistics

If you want the conservative profile, change the last value of the set dampening line to set dampening 15 750 12000 105. Nothing else in the procedure changes.

Step-by-step: RIPE-580 values on Junos OS

Junos gives finer control, because the damping profile is attached by policy term rather than globally. Build two profiles - one for transit, one for peering - and attach them to the correct BGP groups.

set policy-options damping RIPE580-MIN half-life 15
set policy-options damping RIPE580-MIN reuse 750
set policy-options damping RIPE580-MIN suppress 6000
set policy-options damping RIPE580-MIN max-suppress 105

set policy-options damping RIPE580-CONSERVATIVE half-life 15
set policy-options damping RIPE580-CONSERVATIVE reuse 750
set policy-options damping RIPE580-CONSERVATIVE suppress 12000
set policy-options damping RIPE580-CONSERVATIVE max-suppress 105

set policy-options policy-statement DAMP-TRANSIT term 10 from protocol bgp
set policy-options policy-statement DAMP-TRANSIT term 10 then damping RIPE580-MIN
set policy-options policy-statement DAMP-TRANSIT term 20 then accept

set policy-options policy-statement DAMP-PEER term 10 from protocol bgp
set policy-options policy-statement DAMP-PEER term 10 then damping RIPE580-CONSERVATIVE
set policy-options policy-statement DAMP-PEER term 20 then accept

set protocols bgp group TRANSIT import DAMP-TRANSIT
set protocols bgp group IX-PEERS import DAMP-PEER

Verify the profile on Junos with the operational commands that show the live penalty for each route:

show policy damping
show policy damping RIPE580-MIN
show route damping
show route damping suppressed
show route damping decayed

Calculate but do not damp: rolling out safely

Changing suppression parameters is a reachability change, so treat it like a routing policy change rather than a tuning tweak. A four-stage rollout keeps the risk bounded:

1. Measure first. Leave damping disabled and collect flap statistics for one to two weeks - show ip bgp dampening flap-statistics on IOS, show policy damping on Junos. You will usually find a handful of prefixes accounting for the bulk of the events, which tells you whether a threshold of 6000 or 12000 is right for your table.
2. Stage the policy on one router. Apply the conservative profile (12000) on a single edge router that is not on a critical path, with logging enabled, and let it run for a full week. Compare the damped set against your measurement baseline.
3. Check the collateral damage explicitly. Every prefix that appears in the damped list should map to a known customer, transit provider or a prefix you would genuinely expect to flap. A well-connected multi-homed customer showing up in the list is the signal to raise the threshold again.
4. Roll sideways, then tighten. Extend the clean profile to the rest of the AS. Only then consider dropping from 12000 to 6000 on the specific peers where you own the churn and want it damped.

Where a vendor supports calculate-but-do-not-damp test mode, use it at stage one. It gives you the same answer as a live deployment with none of the reachability exposure.

Monitoring, verification and alarms

• Damped prefix count as a time series. A sudden step change after a policy edit is a bug, not a success - unless it is a genuine internet-wide event, in which case the count should fall back within max-suppress-time plus the decay window.
• Suppression duration. Any single route held down longer than max-suppress-time plus one half-life means the ceiling arithmetic is wrong.
• Syslog and SNMP traps. Enable neighbour-change logging and ship the logs off-box, so a damping event is correlated with the topology event that caused it rather than being diagnosed weeks later.
• The 50,000 threshold check. After a firmware upgrade, re-read the maximum penalty field. Vendor defaults can move, and a raised internal constant without a raised suppress threshold is harmless - whereas the reverse is not.
• Independent of damping: verify that BGP itself is stable. If a session flaps hard enough, RTBH or a prefix-level community action is the right tool, not a penalty timer.

Common mistakes when adopting RIPE-580

• Reading "do not change the defaults" as "do not change anything". RFC 7196 is telling vendors not to break existing configurations. Operators are explicitly expected to change their suppress threshold.
• Raising suppress and forgetting max-suppress. With a 60-minute max-suppress and a 15-minute half-life the ceiling is 12000; a suppress threshold of 12000 or more then never triggers. Raise max-suppress alongside suppress.
• Damping more-specifics and aggregates together. A withdrawal of an aggregate plus its more-specifics produces several penalties for what a human sees as one event, which pushes a normally stable prefix over the threshold.
• Damping iBGP routes. Damping belongs on the edge, where the churn arrives. Damping inside the AS propagates suppression through route reflectors and turns a local fault into a network-wide one.
• Asymmetric parameters between neighbours. If only one side of a peering damps, the undamped side keeps generating updates that re-penalise prefixes the other side already suppressed, producing oscillation instead of stability.
• Never revisiting the deployment. A threshold that was safe with 400,000 prefixes may behave differently with a full table after a major outage, when many valid prefixes get penalised at the same moment.

Tuning Advice and the RIPE-580 Debate

Route flap damping is not a "configure and forget" feature. RIPE-580 and years of operational experience show that aggressive default damping can suppress stable but slowly recovering routes, and can even make convergence worse after large-scale failures because many valid prefixes get dampened at the same time. Operators commonly reduce damping on critical peerings, avoid damping more-specific prefixes, and monitor dampened-paths output regularly to confirm that damping is not punishing healthy routes. On the Junos side, interface-level hold-time and damping for physical links is a separate mechanism that also helps to stabilize routing protocols during flapping links.

The honest summary of the debate is this: damping with default parameters is harmful, damping with a suppress threshold of 6000 or higher is defensible, and damping is never a substitute for fixing the underlying instability. If a prefix is flapping because a link is oscillating, fix the link. Damping only buys the rest of the network time to converge while you do.

Related reading: BGP route dampening penalty, suppress and reuse limits and BGP best path selection: the 13-step algorithm. For the protocol-level view of unstable sessions, see Juniper BGP session and route flaps: prevention guide.

Original article: https://networklessons.com/bgp/bgp-route-dampening | Juniper: Understanding Damping Parameters | RIPE-580: RIPE Routing Working Group Recommendations on Route Flap Damping | RFC 7196: Making Route Flap Damping Usable