BGP Route Dampening: Penalties, Half-Lives, and Why It Fell Out of Favor

BGP route dampening is one of the few networking features with a genuine story arc: invented to save the internet, deployed everywhere, then quietly turned off by nearly everyone because it was making things worse. It is still on the CCIE Enterprise Infrastructure blueprint, still in the IOS XE CLI, and still occasionally the right answer. You need to know how it works, and you need to know why the industry backed away from it.

This article covers the penalty algorithm, the four timers, and real dampening output captured on a two-router CML lab running Cisco IOS XE 17.18.2 on iol-xe nodes: a prefix crossing the suppress limit at penalty 2818, the *d flag, and an identical prefix from the same neighbor sitting untouched at *>. For the fundamentals, start with the guide to how BGP carries routes between autonomous systems.

It also covers the gotcha that makes most dampening labs produce absolutely nothing, which is not the algorithm's fault and is nowhere near well enough known.

The problem it was invented to solve

An unstable link somewhere on the internet does not stay local. Every time a prefix goes down and comes back, its origin AS sends a withdraw and then an announcement. Those propagate outward, hop by hop, and every router in the path burns CPU running the best-path algorithm again. A single flapping circuit in one corner of the world could, in the 1990s, meaningfully load routers everywhere else.

Dampening (RFC 2439) puts a cost on instability. Each time a route flaps, the router adds a penalty. When the penalty crosses a threshold, the route is suppressed: the router stops using it and stops advertising it, even if the route is currently up. The penalty then decays exponentially. When it drops below a reuse threshold, the route is allowed back.

It is a circuit breaker, and it is deliberately unfair to routes that misbehave.

The algorithm

Four numbers control everything, and IOS takes them in a fixed order:

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

Bare bgp dampening with no arguments gives you exactly those four values. The penalty arithmetic itself is fixed and not configurable:

• +1000 for a route withdrawal (a flap).
• +500 for an attribute change, on some implementations. IOS by default only penalises withdrawals unless you enable bgp dampening ... route-map with attribute-change tracking.
• Exponential decay between events, governed by the half-life.

The gap between suppress at 2000 and reuse at 750 is not decoration. It forces a route that just crossed the threshold to wait through most of a half-life, so a marginal prefix cannot oscillate in and out of suppression on every decay tick.

Two scoping facts worth committing to memory. Dampening only applies to eBGP-learned routes, because your own AS's instability is your own problem to fix, not something to hide behind a circuit breaker. And penalty is tracked per path, so the same prefix learned from two neighbors carries two independent penalties and can be damped from one while still usable from the other.

What this was captured on

Two routers, one eBGP session, two prefixes from the same origin. One is deliberately abused, the other is a control that is never touched, and that is what makes the difference legible.

Flap timing is the whole experiment here, so flapping the loopback by hand introduces jitter you cannot account for afterwards. That is why scripting a repeatable fault on the device itself with EEM was worth the setup: the same cadence every run, and captures taken at a fixed offset.

The receiving side is one line:

router bgp 65002
 bgp dampening 15 750 2000 60

Lab: watching a route get suppressed

The gotcha that nearly ruined this lab

The first run produced nothing at all. Five clean shut and no-shut cycles on R1's Lo2, dampening configured and confirmed on R2, and R2 counted zero flaps. Nothing suppressed, nothing in the flap statistics, no penalty recorded anywhere.

The reason is the eBGP advertisement interval, or MRAI, which defaults to 30 seconds toward eBGP peers. IOS batches eBGP updates on that timer. If a prefix goes down and comes back inside one interval, the sender does not transmit a withdraw followed by an announcement; it transmits whatever the net state was when the timer expired, and if the prefix ended up where it started, that is nothing at all. Dampening cannot penalise a flap it never received.

That is not a lab artefact, it is a real and important property: the advertisement interval is itself a flap suppressor, it works upstream of dampening at no cost and with no hold-down, and whatever it absorbs never reaches the penalty algorithm. When dampening is configured and appears to do nothing, check this before you start questioning your thresholds. For the demo we disable it on the sending side:

router bgp 65001
 neighbor 10.0.12.2 advertisement-interval 0

Now every flap propagates immediately, and dampening has something to count. Even then, note what happened: five interface flaps produced three counted ones. Some transitions were still absorbed before becoming distinct update events. Do not calibrate a dampening policy assuming every physical bounce equals one penalty step.

The other version of "dampening never fires" is a session dropping entirely rather than a prefix bouncing, since a reset withdraws everything behind it at once. Rule that out by understanding what a BGP session that keeps cycling back to Idle is actually doing before you blame the penalty math.

Suppression

With the advertisement interval out of the way, the per-prefix view on R2 is where the arithmetic stops being theory:

R2#show ip bgp 100.100.111.0/24

BGP routing table entry for 100.100.111.0/24, version 8
Paths: (1 available, no best path)              <-- path exists, but is not a candidate
  Not advertised to any peer
  Refresh Epoch 1
  65001, (suppressed due to dampening)          <-- the smoking gun
    10.0.12.1 from 10.0.12.1 (100.100.111.1)
      Origin IGP, metric 0, localpref 100, valid, external
      Dampinfo: penalty 2818, flapped 3 times in 00:01:43, reuse in 00:06:49
      rx pathid: 0, tx pathid: 0
      Updated on Jul 20 2026 22:59:25 UTC

Three lines carry the story. Paths: (1 available, no best path) says the path is sitting in the BGP table but is excluded from best-path selection, so it is not in the RIB and not advertised onward. (suppressed due to dampening) names the reason outright, which saves you a long detour through route policy and next-hop reachability. And Dampinfo: penalty 2818 is the number itself.

Now check that number against the flap count on the same line. Three withdrawals at roughly 1000 each is about 3000 of raw penalty, and the router reports 2818. The missing 180-odd is decay: the first flap's penalty had already been shrinking for over a minute and a half by the time the third one landed. Penalty is not a counter, it is a decaying quantity that gets topped up, which is why a prefix flapping three times across an afternoon never gets near suppression while one flapping three times in 103 seconds does.

2818 is past the 2000 suppress limit, so the path is out of service until decay drags it under 750. The router has already worked out how long that takes: 6 minutes 49 seconds. The route is up. The customer's loopback is fine. The link is fine. And R2 is refusing to use it or carry it for the next six and a half minutes.

That last sentence is the whole controversy.

The fleet-wide views

Two commands give you the whole router at once. The first lists only what is currently held down, with the release time:

R2#show ip bgp dampening dampened-paths
   Network          From             Reuse    Path
*d 100.100.111.0/24 10.0.12.1        00:06:49 65001 i

The second adds flap history, and will show you prefixes that have accrued penalty without yet crossing the suppress limit:

R2#show ip bgp dampening flap-statistics
    Network          From            Flaps Duration Reuse    Path
*d  100.100.111.0/24 10.0.12.1       3     00:01:43 00:06:49 65001

Read Duration carefully: it is the window the flaps occurred over, not how long the route has been suppressed. Three flaps in 00:01:43 is a prefix in trouble. Three flaps in 04:00:00 would never come close to the suppress limit, because decay eats each one before the next arrives. The stable control prefix has no flap history and appears in neither output.

Status codes and history entries

The status code legend at the top of show ip bgp is the fastest read on the box:

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, ...

Four of those matter here. * is valid, > is best, and d is damped. The one that catches people out is h, a history entry: the router is tracking a penalty for a prefix that is currently withdrawn. There is no route to use, so there is nothing to suppress, and the router is simply remembering in case it comes back. If it stays down long enough for the penalty to decay below reuse, the history entry is garbage-collected.

The dangerous one is s. That is a more specific prefix suppressed by an aggregate, a different mechanism that happens to share the word. Read an s as dampening and you will go looking for flaps that never happened.

Damped against stable, side by side

This is the capture that makes dampening click, because both prefixes come from the same neighbor over the same session with the same attributes:

R2#show ip bgp
BGP table version is 8, local router ID is 10.0.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, ...

     Network          Next Hop            Metric LocPrf Weight Path
 *>   100.100.100.0/24 10.0.12.1                0             0 65001 i   <-- stable: valid + best
 *d   100.100.111.0/24 10.0.12.1                0             0 65001 i   <-- damped: present, not installed

The control prefix is *>: valid, best, installed in the RIB, advertised onward. The abused prefix is *d: valid and damped. It is not missing, not filtered, not unreachable, and its next hop resolves perfectly. It simply never entered the tournament, which is a different failure mode from a path that entered and lost on one of the tiebreakers in the order BGP compares candidate paths in. Dampening is a gate in front of that process, not a step inside it.

That is the value proposition in one screen: one unstable prefix stops churning the RIB and stops propagating updates downstream, while everything else behind the session carries on untouched. The session never went down. Only the badly behaved prefix was punished.

Why the industry turned it off

The killer problem is that dampening penalises the wrong thing. It counts updates received, not instability at the source.

Consider a prefix advertised through several ASes. When it flaps once at the origin, the withdraw propagates. But BGP path exploration means that intermediate routers, before converging on "gone", will announce a series of alternative paths they briefly believe in. Each of those is an update. Each of those looks like a flap to a downstream dampener. A single flap at the origin can look like five or six flaps three ASes away.

The result, documented in a 2002 study by Mao, Govindan, Varghese and Katz, is that well-connected prefixes get dampened harder than poorly-connected ones. The more paths available to reach you, the more path exploration, the more updates, the more penalty. Multihoming, the thing you paid for to be more reliable, actively made you more likely to be suppressed.

Combined with default timers that suppress a route for up to an hour after a couple of genuine flaps, dampening was routinely turning a 30-second outage into a far longer one, so the mitigation caused more customer-visible downtime than the instability it was mitigating. RIPE issued RIPE-378 in 2006 recommending operators simply stop using it.

The rehabilitation: RIPE-580 and RFC 7196

The consensus later shifted again. RIPE-580, published alongside the work that became RFC 7196, made the case that the algorithm was never really the problem: the shipped default parameters were. Router CPUs and BGP implementations had improved enormously, and thresholds chosen for 1990s hardware were punishing prefixes that any modern router absorbs without noticing.

The direction of that guidance is toward substantially more tolerant thresholds than the defaults, and toward scaling how aggressive you are by prefix length, on the reasoning that a flapping short prefix carries far more traffic than a flapping /24. Take the actual numbers from the current published guidance rather than from any article, including this one. They have been revised more than once, and a stale suppress threshold copied off a web page is precisely how this feature earned its reputation in the first place.

Selective dampening instead of blanket dampening

Plain bgp dampening applies one set of parameters to every eBGP path the router learns. That is fine in a lab and a poor fit for a real edge, where one misbehaving customer is usually the actual problem and where a flapping /8 and a flapping /24 are not the same event. The selective form drives the parameters from a route-map:

! values below are illustrative - take production thresholds from current guidance
route-map DAMPEN-POLICY permit 10
 match community NOISY-CUSTOMER
 set dampening 30 1500 6000 60
!
route-map DAMPEN-POLICY permit 20
 match ip address prefix-list LONG-PREFIXES
 set dampening 30 750 3000 60
!
router bgp 65002
 address-family ipv4
  bgp dampening route-map DAMPEN-POLICY

Normal route-map ordering applies: first match wins, and a path matching no clause is not dampened at all, which is a useful default posture. In production the match is usually a community rather than a prefix list, because the tag travels with the route and survives readvertisement, so the real groundwork is a community scheme you can hang policy off rather than the dampening syntax itself.

Operational commands you will actually use

! What is currently suppressed, and when it comes back
show ip bgp dampening dampened-paths

! Flap count and duration for everything with a penalty
show ip bgp dampening flap-statistics

! The configured thresholds
show ip bgp dampening parameters

! One prefix: penalty, flap count, reuse timer
show ip bgp 100.100.111.0/24

! Rescue a route right now (customer is on the phone)
clear ip bgp dampening 100.100.111.0 255.255.255.0

! Rescue everything
clear ip bgp dampening

clear ip bgp dampening is the command you will type at 3 a.m. It zeroes the penalty and immediately reinstates the route. Know it before you need it, because a suppressed prefix raises no alarm of its own: it is simply, quietly absent, and everything else looks healthy.

Should you turn it on?

Honest answer for most enterprises: no. You are not a transit provider. Your neighbour count is small. Your router CPU is not remotely challenged by BGP updates. The failure mode of dampening, extending a short outage into a long one, is strictly worse for you than the problem it solves.

Turn it on if you are carrying somebody else's instability: a provider edge facing one customer generating pathological update volume, or an internal boundary where one region's churn keeps rippling into the core. You are dampening an identified source, not the whole table on principle. Use tolerant thresholds from current guidance, apply them selectively through a route-map, and instrument the result so you know when it fires.

For everyone else, the modern answer to instability is fix the instability: detect failures fast and cleanly with sub-second failure detection instead of protocol hold timers, use carrier-delay and dampening on the interface, and take a hard look at whatever physical layer keeps bouncing.

Common mistakes and gotchas

• Dampening configured, nothing ever dampens. The eBGP advertisement interval is almost always why. Rapid flaps get coalesced into a net-zero update the receiver never sees, and it cannot penalise what it was not sent.
• Assuming every physical flap becomes a penalty step. Five interface bounces produced three counted flaps in this lab, even with batching disabled on the sender.
• Reading penalty as a flap counter. Three flaps showed 2818, not 3000, because decay was already eating the first one. Timing changes the total, which is the entire point of an exponential decay.
• Expecting *d to mean the route is gone. The path is present, valid and correctly formed, just excluded from best-path selection. Chasing it as a filtering or next-hop problem wastes hours.
• Confusing s with d. s is aggregation suppressing a more specific prefix. d is dampening. Different feature, same word.
• Deploying the defaults because they are the defaults. A 15 minute half-life with a 2000 suppress limit is the exact configuration the operator community spent a decade warning about.

Key takeaways

• Dampening adds a penalty (about 1000 per flap) that decays exponentially. Above suppress, the route is dropped from best-path selection; below reuse, it comes back.
• The lab proved the math: penalty 2818 from 3 flaps in 00:01:43, (suppressed due to dampening) with no best path, reuse in 6m49s, while the control prefix from the same neighbor stayed *>.
• It only ever applies to eBGP-learned routes, and penalty is tracked per path.
• The d flag in show ip bgp means damped. The h flag means a history entry: penalty recorded, route currently withdrawn. The s flag is aggregation, not dampening.
• The eBGP advertisement interval batches updates and hides fast flaps from dampening entirely. If your dampening lab "does not work", this is why.
• IOS default timers are far too aggressive and turn brief outages into long ones. If you dampen at all, use current published thresholds and apply them selectively with bgp dampening route-map.
• Path exploration means well-connected prefixes generate more updates and therefore get dampened harder. This is the core reason the internet backed away from the feature.
• clear ip bgp dampening <prefix> is your emergency override.

Dampening is a blueprint topic to reason about cleanly and a production feature to deploy narrowly. Know the four parameters, know the advertisement interval sits in front of them, and know that *d means a healthy path held out of service on purpose. For where this sits among path attributes, policy and convergence, work through the rest of the BGP cluster in order.