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, real dampening output from a CML lab, and the RIPE guidance that changed the consensus. For the fundamentals, start at the complete BGP guide.

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>

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.

Crucially, dampening only applies to eBGP-learned routes. iBGP routes are never dampened, because your own AS's instability is your own problem to fix, not something to hide behind a circuit breaker.

Lab: watching a route get suppressed

ISP-A (R3) applies dampening to routes learned from its customer, AS 65001 (R1). We tighten the timers so the demo runs in minutes rather than an hour:

router bgp 100
 address-family ipv4
  bgp dampening 15 750 2000 60

Then we flap a customer prefix, 10.30.30.0/24, by shutting and un-shutting the loopback that originates it.

The gotcha that nearly ruined this lab

The first attempt produced almost nothing. Five shut/no-shut cycles, and R3 recorded exactly one flap:

R3#show ip bgp 10.30.30.0/24
  65001 (history entry)
      Dampinfo: penalty 992, flapped 1 times in 00:00:12

The reason is the eBGP advertisement interval. By default, IOS batches eBGP updates on a 30-second timer. Flap a prefix four times in ten seconds and your neighbour never sees four events - it sees whatever state you were in when the timer expired. 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, and it does its work before dampening ever gets a chance. For the demo we disable it on the sending side:

router bgp 65001
 address-family ipv4
  neighbor 10.0.13.2 advertisement-interval 0
  neighbor 10.0.113.2 advertisement-interval 0

Now every flap propagates immediately, and dampening has something to count.

Suppression

Five flaps later:

R3#show ip bgp dampening flap-statistics
    Network          From            Flaps Duration Reuse    Path
*d  10.30.30.0/24    10.0.13.1       5     00:02:58 00:07:33 65001
*d                   10.0.113.1      5     00:02:58 00:07:33 65001

The d flag is the tell: damped. There is no >, so the route is not best, and it is not in the routing table. The Reuse column says how long until it is allowed back.

R3#show ip bgp dampening dampened-paths
   Network          From             Reuse    Path
*d 10.30.30.0/24    10.0.13.1        00:07:33 65001 i
*d 10.30.30.0/24    10.0.113.1       00:07:33 65001 i

And the detail view gives you the penalty itself:

R3#show ip bgp 10.30.30.0/24
BGP routing table entry for 10.30.30.0/24
Paths: (2 available, no best path)
  65001, (suppressed due to dampening)
      Dampinfo: penalty 4852, flapped 5 times in 00:02:59, reuse in 00:07:33

Penalty 4852, well past the 2000 suppress threshold. The route is up. The customer's loopback is fine. The link is fine. And ISP-A is refusing to carry it for the next seven and a half minutes.

That last sentence is the whole controversy.

The intermediate state: history entries

Before a route accumulates enough penalty to be suppressed, it sits in a state IOS calls a history entry, flagged h:

R3#show ip bgp dampening flap-statistics
    Network          From            Flaps Duration Reuse    Path
 h  6.6.6.6/32       10.0.113.1      1     00:04:26          65001 200 300
 h  6.6.60.0/24      10.0.113.1      1     00:04:26          65001 200 300

A history entry means: the route is currently withdrawn, and the router is keeping a penalty record in case it comes back. There is no route to use, so there is no suppression to apply - the router is simply remembering. If the route stays down and the penalty decays below reuse, the history entry is garbage-collected.

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 single genuine flap, dampening was routinely turning a 30-second outage into a 60-minute one. RIPE issued RIPE-378 in 2006 recommending operators simply stop using it.

The rehabilitation: RIPE-580

In 2013, RIPE revisited the topic in RIPE-580. Router CPUs and BGP implementations had improved enormously; path exploration was better understood; and the real problem was not dampening itself but the absurdly aggressive default timers.

RIPE-580's recommendation is to dampen, but far more gently, and to scale the aggressiveness by prefix length - because a flapping /24 matters less than a flapping /8:

You implement prefix-length-dependent dampening in IOS with a route-map:

ip prefix-list LONG-PFX seq 5 permit 0.0.0.0/0 ge 24
ip prefix-list SHORT-PFX seq 5 permit 0.0.0.0/0 le 21

route-map DAMPEN permit 10
 match ip address prefix-list SHORT-PFX
 set dampening 30 1500 12000 120
route-map DAMPEN permit 20
 match ip address prefix-list LONG-PFX
 set dampening 30 820 6000 60

router bgp 100
 address-family ipv4
  bgp dampening route-map DAMPEN

Operational commands you will actually use

! What is currently suppressed
show ip bgp dampening dampened-paths

! Penalty and flap history for everything
show ip bgp dampening flap-statistics

! Just one prefix
show ip bgp dampening parameters
show ip bgp 10.30.30.0/24

! Rescue a route right now (customer is on the phone)
clear ip bgp dampening 10.30.30.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.

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 a service provider carrying customer routes and you have a specific customer or region generating pathological update volume. Use RIPE-580 timers, never the defaults. And instrument it, so you know when it fires.

For everyone else, the modern answer to instability is fix the instability: BFD to detect failures fast and cleanly, carrier-delay and dampening on the interface, and a hard look at whatever physical layer keeps bouncing.

Key takeaways

• Dampening adds a penalty (1000 per flap) that decays exponentially. Above suppress, the route is dropped; below reuse, it comes back.
• It only ever applies to eBGP-learned routes.
• The d flag in show ip bgp means damped. The h flag means a history entry - penalty recorded, route currently withdrawn.
• 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 hour-long ones. If you dampen at all, use RIPE-580-style values scaled by prefix length.
• 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.

Next: designing BGP policy with communities, including a working remote-triggered black hole. The full cluster index is on the BGP pillar guide.