BGP Route Dampening Part 1: The Flapping Problem, Exponential Decay, and Cisco Configuration

28 May 2026 ciscobgpnetworkingiosrouting

BGP route dampening is one of those features where the gap between “I know what it does” and “I understand why it does it that way” turns out to matter enormously. The feature’s history, the mathematics behind it, and a string of catastrophic misapplications all live inside that gap. This is Part 1 of a two-part deep dive. Here we cover everything mechanical: the history that created the feature, the exponential decay algorithm, every Cisco parameter and what it controls, and a complete configuration and verification reference. Part 2 covers the modern picture — why the IETF now discourages it on the public internet, how BFD interacts with it, and where it remains a legitimate and necessary tool.

The Problem: What Route Flapping Actually Costs

A route flap is a BGP withdrawal immediately followed by a re-announcement of the same prefix. In isolation, a single flap from a single peer is cheap. The router receives a WITHDRAW UPDATE, removes the prefix from the BGP RIB, re-runs best-path selection, updates the FIB, then seconds later receives an ANNOUNCE UPDATE and reverses all of it. A few microseconds of CPU, a negligible memory operation, and a handful of UPDATE messages sent to downstream peers. Annoying, but harmless.

The problem is that BGP does not contain flaps locally. A withdrawal received from one eBGP peer is re-advertised as a withdrawal to every other iBGP peer and every other eBGP peer. Each of those peers does its own best-path recalculation, updates its own FIB, and propagates the withdrawal further. A single flapping prefix at a small edge site ripples outward across the entire BGP topology until every router carrying that prefix has processed two UPDATEs per flap. At internet scale, with a full BGP table and hundreds of peers per core router, a heavily flapping prefix is not a localised annoyance — it is a CPU event distributed across the global routing system simultaneously.

The late 1990s made this concrete. The commercial internet was growing explosively. The full global BGP table crossed 50,000 prefixes in 1997 and was growing by thousands of entries per month. Router hardware of that era — a Cisco 7500 with an RSP4 — had roughly 30 MHz of route-processor clock and somewhere between 32 and 128 MB of DRAM. These machines were already running close to capacity under normal BGP convergence load. A flapping link — and in the dial-up/leased-line era, physical links went down far more frequently than they do now — could generate hundreds of UPDATE cycles in a short period, saturating the route processor on every router in the path and causing convergence delays across unrelated prefixes as the CPU queues backed up.

The need for a mechanism that would let routers absorb flapping routes without propagating the instability outward was real, urgent, and practically motivated.

RFC 2439 and the Birth of Route Flap Damping

Villamizar, Chandra, and Govindan published RFC 2439, “BGP Route Flap Damping,” in November 1998. The core insight is simple: rather than reacting to every flap as it arrives, assign a running penalty to each unstable prefix, and suppress the prefix entirely once that penalty crosses a threshold. While the prefix is suppressed, further flaps from the peer still update the penalty, but no UPDATEs are propagated to other routers. The rest of the network is shielded from the instability.

The mechanism needed two properties to be useful. First, it had to eventually release suppressed routes — a prefix that flapped for five minutes a year ago should not stay suppressed forever. Second, suppression had to be more difficult to achieve the longer the prefix had been stable — a route that was steady for an hour before flapping should recover faster than one that flapped eight times in the last ten minutes. Both properties are delivered by the same mechanism: exponential decay of the accumulated penalty over time.

The Exponential Decay Algorithm

The penalty at any point in time follows:

P(t) = P₀ × (1/2)^(t / H)

Where P₀ is the penalty at the last event, t is the time elapsed since that event in seconds, and H is the half-life in seconds. The half-life is the time required for the penalty to decay to half its current value, assuming no new flaps occur.

Why exponential decay specifically? Several reasons. It is bounded — no matter how large the penalty accumulates, it eventually approaches zero without asymptoting at some non-zero value that would cause permanent suppression. It has the right shape: the penalty decays quickly at first and more slowly as it approaches the reuse limit, giving recently-stabilised routes a fast path back but penalising routes that oscillate repeatedly with an accumulating history. And the mathematics is computationally cheap — the decay can be computed at event time rather than requiring continuous recalculation, because the closed-form expression gives you P(t) at any future time t from P₀ and the half-life constant.

A Worked Example

Take Cisco’s default parameters: half-life = 15 minutes, suppress limit = 2000, reuse limit = 750, max suppress time = 60 minutes. Penalty per withdrawal = 1000.

Event	Time	Action	Calculation	Penalty After
Flap 1	T=0	Withdrawal received	0 + 1000	1000
Flap 2	T=5min	Withdrawal received	decay: 1000 × (0.5)^(5/15) = 794, then +1000	1794
Flap 3	T=8min	Withdrawal received	decay: 1794 × (0.5)^(3/15) = 1634, then +1000	2634 → SUPPRESSED (> 2000)
Stable	T=8–68min	No flaps	—	Decaying from 2634
Check	T=8+15min = T=23min	One half-life from T=8	2634 × 0.5 = 1317	1317 (still suppressed)
Check	T=8+30min = T=38min	Two half-lives from T=8	2634 × 0.25 = 659	659 → REUSED (< 750)

From the third flap at T=8 minutes to route reuse at approximately T=38 minutes is 30 minutes of suppression. The route was unavailable for that entire window even though the underlying link stabilised immediately after the third flap. That is the cost dampening imposes in exchange for protecting the routing system — a topic we will examine critically in Part 2.

The hysteresis between suppress (2000) and reuse (750) is intentional. If reuse were set to 1999 (just below suppress), a route at exactly the boundary would suppress and immediately reuse on the next decay cycle, creating a rapid oscillation between suppressed and active states — which would itself generate UPDATE storms. The gap between 2000 and 750 means a route must decay substantially before it can re-enter the routing table, giving the underlying link time to prove it has actually stabilised.

Cisco Parameters: What Each One Does

Cisco implements dampening with five configurable values. Understanding what each one controls and why the defaults are what they are is essential before touching the configuration.

Penalty Values

Two penalty values are applied per event, not one.

A route withdrawal (the prefix is completely withdrawn from BGP) incurs a penalty of 1000 by default. This represents a full adjacency or prefix loss — the most disruptive BGP event type.

A route attribute change (the prefix remains reachable but its attributes change — a path attribute modification, community change, or next-hop shift) incurs a penalty of 500 by default. This is half the withdrawal penalty because the prefix remains reachable during an attribute change; traffic is not dropped, just potentially rerouted. Attribute churn is also more common in legitimate network re-optimisation events that should not be treated the same as link failures.

Suppress Limit (default: 2000)

The penalty level at which a route transitions from Active to Suppressed. At the default, a single withdrawal from a stable route (penalty = 1000) does not suppress it. Two rapid withdrawals in succession will cross 2000 and suppress it. The logic is deliberate: a route that flaps once and immediately stabilises is not actually problematic, and suppressing it would cause unnecessary traffic loss. A route that flaps twice in rapid succession is demonstrating genuine instability.

The ratio of suppress-limit to per-withdrawal penalty (2000/1000 = 2) means two flaps in rapid succession are required to trigger suppression with default settings.

Reuse Limit (default: 750)

The penalty level below which a suppressed route is reinstated. Must be lower than the suppress limit to provide hysteresis. The default 750 means a suppressed route must decay to 37.5% of the suppress limit before it re-enters the RIB.

Half-Life (default: 15 minutes)

The rate of penalty decay. Applies equally to penalty accumulation from flaps that occurred recently and to the long tail of accumulated penalty from extended instability. A 15-minute half-life means:

After 15 minutes of stability: penalty is halved.
After 30 minutes: penalty is 25% of its value.
After 45 minutes: penalty is 12.5%.
After 60 minutes: penalty is 6.25%.

Shortening the half-life makes dampening more forgiving (routes recover faster after stabilising but also re-accumulate faster during flapping). Lengthening it creates a longer memory — useful when links have a pattern of appearing to stabilise briefly before flapping again.

Max Suppress Time (default: 60 minutes)

A hard ceiling on how long any route can remain suppressed, regardless of how large the accumulated penalty has become. Without this safety valve, a link that flapped continuously for two hours could accumulate a penalty of tens of thousands, requiring twelve or more half-lives to decay below the reuse limit — potentially suppressing the route for ten or twelve hours after the link finally stabilises.

The default maximum of 60 minutes is four times the default half-life. This relationship is not accidental. If max-suppress-time is less than the natural decay time from maximum observed penalty to reuse limit, the max-suppress-time becomes the binding constraint and routes are released before they would naturally recover. If max-suppress-time is much greater than the natural decay time, it has no practical effect. The 4× relationship keeps it as a safety valve rather than the primary control.

Important constraint: if you customise dampening parameters, keep max-suppress-time ≥ 4 × half-life. Violating this creates a configuration where the max-suppress timer fires before the route would naturally recover, causing routes to re-enter the RIB while still carrying significant penalty and suppressing again quickly — a dampening-induced oscillation.

The Operational State Machine

A BGP prefix under dampening moves through four states:

Active — the route is in the BGP RIB, installed in the FIB, and advertised to peers. Accumulated penalty is below the suppress limit.

Pending — the route has begun accumulating penalty from flaps but has not yet reached the suppress limit. The route remains in the RIB and is advertised normally. This state is not always explicitly shown in Cisco output but is the logical pre-suppression phase.

Suppressed (also called Dampened or History) — penalty has crossed the suppress limit. The route is removed from the RIB and FIB. Cisco installs a “history” entry recording the route’s dampening state, but the prefix is not in the forwarding table. The router stops advertising this prefix to its peers. Crucially, if the underlying peer continues to send withdrawals and re-announcements, the router continues updating the penalty internally — it just does not propagate any of this to the rest of the network.

Reuse — the penalty decays below the reuse limit (or the max-suppress timer expires, whichever comes first). The router reinstates the route in the RIB, re-runs best-path selection, updates the FIB, and re-advertises to peers. Dampening history is not cleared immediately; the route carries a residual penalty that continues decaying, meaning a second flap shortly after reuse can re-suppress the route more easily than the first occurrence did.

State Transition Scenario

Consider a customer edge link that flaps four times in eight minutes and then stabilises permanently. Using default Cisco parameters:

T=0:00  — Link DOWN. Withdrawal received. Penalty = 1000. State: Active (below 2000).
T=0:30  — Link UP. Re-announcement received. Penalty decays slightly, then +500 (attr change) ≈ 1480.
T=3:00  — Link DOWN. Withdrawal received. Penalty decays to ~1284, +1000 = 2284. State: SUPPRESSED.
           Router stops advertising prefix to peers. History entry created.
T=5:00  — Link UP. Re-announcement from peer received. Penalty decays to ~2040, +500 = 2540.
           Still suppressed. Update noted internally but not propagated.
T=6:00  — Link DOWN. Withdrawal from peer received. Penalty decays to ~2382, +1000 = 3382.
T=6:30  — Link UP. Re-announcement from peer received. Penalty decays to ~3260, +500 = 3760.
T=8:00  — Link stable. No further flaps.

Decay from T=8:00:
  T=23:00 — 15 min later: 3760 × 0.5   = 1880. Still suppressed (> 750).
  T=38:00 — 30 min later: 3760 × 0.25  = 940.  Still suppressed (> 750).
  T=53:00 — 45 min later: 3760 × 0.125 = 470.  REUSE (< 750). Route reinstated.

The link stabilised at T=8:00. The route did not return to the RIB until approximately T=53:00 — 45 minutes after the link stopped flapping. During that window, traffic destined for that prefix was blackholed or rerouted via a less-preferred path. This is the fundamental trade-off dampening makes, and understanding it is essential before touching the configuration in a production environment.

Cisco Configuration Reference

Global Dampening: Default Parameters

The simplest form enables dampening with all defaults across all BGP prefixes received on all peers in the default VRF:

router bgp 65001
 bgp dampening

This applies to eBGP-learned routes by default. In IOS, dampening does not apply to iBGP sessions unless explicitly configured (and you generally should not apply it to iBGP sessions, for reasons covered in Part 2).

Global Dampening: Custom Parameters

router bgp 65001
 bgp dampening <half-life> <reuse> <suppress> <max-suppress-time>

Concrete example with slightly more aggressive-than-default settings:

router bgp 65001
 bgp dampening 10 750 2000 40

This uses a 10-minute half-life (routes recover slightly faster), same suppress and reuse limits, and a 40-minute max suppress time (still ≥ 4 × 10 minutes, so the constraint is satisfied).

Selective Dampening with a Route-Map

Applying dampening to all prefixes from all peers is a blunt instrument. The more surgical approach is to apply different dampening parameters to different prefix ranges using a route-map. This allows you to dampen unstable customer-facing routes aggressively while leaving your transit and peering prefixes untouched:

!-- Match only prefixes that should be dampened
ip prefix-list PL-CE-CUSTOMER permit 10.200.0.0/16 le 24

!-- Route-map clause 10: dampen customer prefixes with custom values
route-map RM-BGP-DAMPENING permit 10
 match ip address prefix-list PL-CE-CUSTOMER
 set dampening 15 750 2000 60

!-- Route-map clause 20: explicitly permit everything else with no dampening
route-map RM-BGP-DAMPENING permit 20

router bgp 65001
 bgp dampening route-map RM-BGP-DAMPENING

The set dampening action in the route-map clause takes the same four parameters as the global command: <half-life> <reuse> <suppress> <max-suppress-time>. A route-map clause that matches but has no set dampening statement results in no dampening for those prefixes, even if global dampening is also configured.

Per-Address-Family Configuration

On IOS-XE and modern IOS images, dampening can be scoped to a specific address family, which is the preferred form for multiprotocol deployments:

router bgp 65001
 address-family ipv4 unicast
  bgp dampening 15 750 2000 60
 !
 address-family ipv6 unicast
  bgp dampening 15 750 2000 60

IOS-XR Syntax

IOS-XR implements dampening via route policy, which is worth noting if you operate across both platforms:

route-policy DAMPENING-EDGE
  set dampening halflife 15 suppress 2000 reuse 750 max-suppress-time 60
end-policy

router bgp 65001
 address-family ipv4 unicast
  dampening route-policy DAMPENING-EDGE

The parameter order differs from IOS (halflife ... suppress ... reuse ... rather than <half-life> <reuse> <suppress> ...). This is a common source of misconfiguration when applying identical dampening intent across a mixed IOS/IOS-XR estate.

Applying Dampening to Specific Neighbors

Dampening can be applied on a per-neighbor basis using neighbor x.x.x.x dampening, though the route-map approach is generally more useful in practice since you usually want to dampen based on prefix characteristics rather than the specific peer they arrived from:

router bgp 65001
 neighbor 192.0.2.1 dampening
 neighbor 192.0.2.1 dampening route-map RM-BGP-DAMPENING

Verification and Troubleshooting Commands

Checking Configured Parameters

show ip bgp dampening parameters

Sample output:

BGP dampening is enabled
 Half-life time    : 15 mins       Decay SHalf-life time : 15 mins
 Suppress penalty  : 2000          Reuse  penalty      : 750
 Keepdown time     : 60 mins       Restart penalty     : 0

Viewing All Flap Statistics

show ip bgp dampening flap-statistics

This shows every prefix that has accumulated any dampening penalty, whether or not it is currently suppressed:

BGP table version is 1234, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

   Network            From             Flaps Duration  Reuse    Path
s> 192.0.2.0/24      198.51.100.1         4 00:12:33  00:31:00 65002
   10.0.99.0/24      203.0.113.5          1 00:02:01            65003

The s prefix indicates a currently suppressed route. Duration is the time since dampening history began for this prefix. Reuse shows the estimated time until the route will be reinstated (blank for routes not currently suppressed). The route with one flap and no s flag is accumulating history but has not yet hit the suppress limit.

Viewing Only Currently Suppressed Routes

show ip bgp dampening dampened-paths

This is the most operationally useful command during an incident — it shows you exactly which prefixes are currently black-holed from the perspective of this router:

BGP table version is 1234, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

   Network            From             Reuse    Path
s  192.0.2.0/24      198.51.100.1     00:31:00 65002
s  198.51.100.128/25 198.51.100.1     00:18:45 65002

Inspecting a Specific Prefix

show ip bgp 192.0.2.0/24

For a dampened prefix, the output includes a dampening information block:

BGP routing table entry for 192.0.2.0/24, version 892
Paths: (1 available, no best path)
  Path not in bestpath calculation.
  Dampinfo: penalty 1840, flapped 4 times in 0:12:30
         reuse in 0:31:00
  198.51.100.1 from 198.51.100.1 (198.51.100.1)
    Origin IGP, metric 0, localpref 100, valid, external
    Community: 65002:100
    Dampinfo: penalty 1840, flapped 4 times in 0:12:30

The no best path flag and Path not in bestpath calculation confirm the route is suppressed. The Dampinfo block shows the current accumulated penalty, flap count, flap history window, and estimated reuse time.

Clearing Dampening State

To release all dampened routes immediately (useful after maintenance or when you determine a route was suppressed incorrectly):

clear ip bgp dampening

To release a specific prefix:

clear ip bgp dampening 192.0.2.0/24

Note that clear ip bgp dampening does not reset flap history counters — it releases suppressed routes by zeroing their penalties, but the flap-statistics counters remain until you clear them separately with clear ip bgp flap-statistics.

To reset all history and statistics:

clear ip bgp flap-statistics

To reset statistics for a specific prefix:

clear ip bgp flap-statistics 192.0.2.0/24

Configuration Pitfalls

Applying dampening to iBGP sessions. In IOS, bgp dampening applies only to eBGP sessions by default. Explicitly applying dampening to iBGP sessions is almost always wrong. If a prefix is suppressed on one iBGP router but not another, the two routers will have inconsistent views of what is reachable, which can cause asymmetric routing and persistent forwarding loops. The instability protection dampening provides should be applied at eBGP boundaries, not inside the AS.

Ignoring the max-suppress / half-life relationship. As discussed above, set max-suppress-time ≥ 4 × half-life. If you halve the half-life to 7.5 minutes but leave max-suppress at 60 minutes, routes can accumulate extreme penalties (from persistent flapping) that take 10+ half-lives to decay, effectively making the max-suppress timer non-functional for heavily penalised prefixes unless the timer fires first.

Setting reuse too close to suppress. The gap between suppress and reuse creates hysteresis. Reducing the gap (e.g., suppress=2000, reuse=1900) means a route barely crosses the suppress threshold and almost immediately re-enters the RIB. If the underlying link continues to be unreliable, this produces rapid suppress-reuse oscillation that defeats the purpose of dampening and generates its own UPDATE churn.

Forgetting that route-map permit with no set dampening means no dampening, not default dampening. A route-map clause that matches and permits without a set dampening action results in no dampening for those prefixes, overriding any global bgp dampening statement. This is the correct behaviour for selective dampening, but it surprises engineers who expect the global setting to apply as a fallback.

Not accounting for asymmetric paths. Dampening acts on prefixes as seen from a specific peer. If a prefix arrives via two different eBGP peers and one peer’s link flaps, dampening may suppress the route as learned from that peer while leaving the other peer’s path active. This is generally the correct behaviour (best-path selection continues using the stable path), but it means show ip bgp dampening dampened-paths does not tell you whether a given prefix is actually unreachable — it tells you which paths to that prefix are being suppressed.

Confusing BGP dampening with interface dampening. IOS supports a separate dampening command at the interface level (interface GigabitEthernet0/0 / dampening) that implements a similar decay mechanism at the link layer — suppressing the interface’s carrier-up/carrier-down notifications to higher-layer protocols including BGP. These two features are independent and can be applied simultaneously. Interface dampening fires before BGP dampening and can prevent BGP from ever seeing the flap. We will return to this in Part 2 when discussing the modern alternatives.

Part 2 covers the other half of this story: why the IETF formally discourages global dampening in RFC 7454, how Bidirectional Forwarding Detection works and what it means for the suppress-or-detect question, the specific scenarios where dampening remains the right answer, and how to configure a modern, targeted dampening policy at an enterprise edge.