BGP Route Dampening Configuration: Penalty and Reuse Limits - 夜莺博客

BGP Route Dampening Configuration: Penalty and Reuse Limits

BGP route dampening exists for one reason: a route that flaps (advertised and withdrawn over and over) forces every router on the path to burn CPU processing UPDATE messages, and in the pre-1990s hardware era that could destabilize entire backbones. Modern routers are fast, which is why RIPE now recommends dampening be applied selectively - but the mechanics are still worth knowing cold. This article explains the penalty system and shows how to enable dampening globally or per-route on Cisco IOS.

How the Penalty System Works

Each time a route flaps, it receives a penalty of 1000. When the accumulated penalty crosses the suppress limit (default 2000), the route is dampened: it is neither installed in the routing table nor advertised to neighbors. From that moment the penalty decays with a half-life timer (default 15 minutes) - every half-life the penalty halves. Once the penalty drops below the reuse limit (default 750) the route is announced again, and below 50% of the reuse limit the penalty is removed completely.

Four parameters control the whole mechanism, and they are not independent - each one is an input to a small piece of arithmetic:

  • Half-life - the decay constant, in minutes. It sets how long the router "remembers" instability.
  • Reuse limit - the penalty floor at which a suppressed route is used again.
  • Suppress limit - the penalty ceiling at which a route is withdrawn from the RIB and from advertisements.
  • Max-suppress-time - the hard cap on how long a route may stay suppressed, regardless of how badly it flaps.

Because the decay is exponential, "penalty" is best understood not as a counter but as a weighted history: a flap that happened four half-lives ago still contributes 1/16 of its original 1000 points. The rest of this article works through the arithmetic behind those four knobs so that choosing values is a calculation rather than a guess.

The Decay Equation: Penalty as a Function of Time

Penalty decay is a plain exponential function. If a route carries penalty P0 at time zero and the half-life is H minutes, the penalty after t minutes is:

P(t) = P0 * 2 ^ (-t / H)

With the Cisco defaults (H = 15 minutes), a route suppressed at exactly 2000 points decays like this:

Elapsed time Half-lives Penalty
0 min 0 2000
15 min 1 1000
30 min 2 500
45 min 3 250
60 min 4 125

Two consequences fall directly out of the equation. First, decay never reaches zero on its own - the penalty only approaches it asymptotically, which is why IOS removes the entry once the value drops below half of the reuse limit. Second, the shape of the curve does not change when you scale the limits; only the intersection points move. That is why the ratio of reuse to suppress matters far more than the absolute numbers.

Deriving the Reuse Time for Any Penalty

Solving the decay equation for time gives the exact moment a suppressed route becomes eligible again. Set P(t) equal to the reuse limit R and solve for t:

t_reuse = H * log2(P0 / R)

The logarithm base 2 is the reason the numbers below look "nice" at powers of two, and why doubling the accumulated penalty always costs exactly one extra half-life:

Penalty when suppressed Calculation (H = 15, R = 750) Reuse time
2000 15 * log2(2.67) 21.2 min
2691 15 * log2(3.59) 27.7 min
6000 15 * log2(8) 45.0 min
12000 (ceiling) 15 * log2(16) 60.0 min

This is the arithmetic behind the line you see in a debug trace: suppress 1.1.1.1/32 for 00:24:40 (penalty 2349). Check it: 15 * log2(2349 / 750) = 15 * 1.647 = 24.7 minutes, which is the 24 minutes 40 seconds IOS quoted. If you can reproduce that number on paper, you understand the feature.

The Ceiling: Max-Suppress-Time and Max-Suppress-Penalty

Without a ceiling, a route flapping every few seconds would accumulate penalty faster than it decays and could stay suppressed for hours. The max-suppress-time parameter prevents that by defining a maximum penalty value, sometimes printed as the max suppress penalty:

ceiling        = reuse * 2 ^ (max_suppress_time / half_life)
max_suppress   = half_life * log2(ceiling / reuse)

Plug in the defaults - reuse 750, max-suppress-time 60 minutes, half-life 15 minutes - and the ceiling is 750 * 2^4 = 12000, which is exactly the "Max suppress penalty: 12000" value that show ip bgp dampening parameters prints on a default configuration. The two formulas are inverses of each other, so you can pick either value and let the other follow.

Note the trap hiding in this relationship: if max-suppress-time is set shorter than the half-life, the exponent becomes smaller than 1 and the ceiling can end up below the suppress limit. A route can then never accumulate enough penalty to be suppressed at all, and dampening silently becomes a no-op that looks configured.

Calculating the Flap Rate Needed to Suppress a Route

Reverse the question: given a route flapping with period T minutes, what penalty does it settle at? The geometric series of penalties converges to:

P_steady = 1000 / (1 - 2 ^ (-T / half_life))

With the default half-life of 15 minutes the curve is steep near the half-life itself, which is the practical safety property of the defaults:

Flap period Steady-state penalty Outcome with suppress 2000
60 min 1067 never suppressed
30 min 1333 never suppressed
15 min 2000 (asymptote) borderline - stays just under the limit
10 min 2703 suppressed on roughly the third flap
5 min 4848 suppressed quickly, stays damped
3 min 7728 approaches the ceiling

The row at 15 minutes deserves attention. A route flapping exactly once per half-life accumulates 1000, then 1500, then 1750, then 1875 - converging to 2000 from below and therefore never crossing the suppress limit. Flap even slightly faster, once every 10 minutes, and the same route reaches 2703 and is suppressed on its third flap. This is the mathematical reason dampening is described as a rate limiter rather than a link-failure detector: it ignores slow instability by design.

If you want a different threshold for that "slow but persistent" case, lower the half-life rather than the suppress limit. Shortening the half-life tightens the memory window and moves the knee of the curve - lowering the suppress limit only shifts the vertical cutoff.

Configuration: Global Dampening

R2(config)# router bgp 2
R2(config-router)# bgp dampening

That single line enables dampening with all defaults. To tune the behavior, the full syntax is:

R2(config-router)# bgp dampening <half-life> <reuse> <suppress> <max-suppress>
R2(config-router)# bgp dampening 15 750 2000 60

The order of the numbers matches the order of the formulas above: decay constant first, then the two thresholds, then the cap. The max-suppress-time (60 minutes by default) caps how long a route can stay dampened even if it keeps flapping - after that the penalty is frozen at the value that yields the maximum suppression period.

Parameter Selection: A Design Table

Once you can compute reuse times and steady-state penalties, tuning becomes a design exercise. Pick the longest outage you are willing to tolerate for a falsely suppressed prefix, then work backwards:

Profile half-life / reuse / suppress / max-suppress Worst-case suppression When to use
Default 15 / 750 / 2000 / 60 60 min RFC 2439 legacy defaults; EBGP learned routes only
Conservative 30 / 1500 / 6000 / 120 120 min small routing domains where a false suppression is cheap and flaps are rare
Aggressive 5 / 500 / 1500 / 30 30 min customer-facing CE routers with known flapping loops
Minimal not applied n/a RIPE-580 recommendation: dampening disabled by default

Two rules keep the numbers coherent. Keep reuse between one third and one half of suppress - a ratio well below 1 means the route must decay for a meaningful time before it is trusted again, while a ratio close to 1 makes suppression nearly meaningless. Then size max-suppress-time so the ceiling lands where you want it: max-suppress-time = half-life * log2(ceiling / reuse).

Selective Dampening with Route Maps

Because blanket dampening can hide a route that is genuinely bouncing due to a real outage, RIPE-580 recommends dampening only specific prefixes. Attach a route map to bgp dampening to restrict the feature:

R2(config)# route-map DAMPEN-CUSTOMER permit 10
R2(config-route-map)# match ip address prefix-list CUSTOMER-PREFIXES
R2(config-route-map)# set dampening 15 750 2000 60
R2(config)# router bgp 2
R2(config-router)# bgp dampening route-map DAMPEN-CUSTOMER

Verification

R2# show ip bgp dampening parameters
 dampening 15 750 2000 60 (DEFAULT)
  Half-life time      : 15 mins       Decay Time       : 2320 secs
  Max suppress penalty: 12000         Max suppress time: 60 mins
  Suppress penalty    :  2000         Reuse penalty    : 750
R2# show ip bgp dampened-paths
R2# show ip bgp dampening flap-statistics
R2# clear ip bgp dampening

show ip bgp dampening parameters confirms the active timers, show ip bgp dampened-paths lists currently suppressed prefixes, and the clear command manually releases dampened routes after an incident is resolved.

It is worth cross-checking the printed values against the formulas the first few times you deploy a custom profile. The "Decay Time" field, for instance, is the calculated reuse time for a route sitting exactly at the suppress limit: 2320 seconds is 15 * 60 * log2(2000 / 750) rounded up. If your configured ceiling and the printed Max suppress penalty disagree, you have a typo in the parameter order rather than a mystery.

Worked Example: Sizing a Profile for a Flapping CE Router

Suppose a customer edge router loses its LAN interface roughly every eight minutes during a maintenance project, and each cycle withdraws a /24. The ISP wants the prefix suppressed once it is clearly unstable, but wants it back within half an hour of the noise stopping.

Step one, compute the steady-state penalty at the observed flap period with the default half-life: 1000 / (1 - 2^(-8/15)) = 1000 / (1 - 0.691) = 3236. That is comfortably above the default suppress limit of 2000, so the defaults already catch this route - but the resulting reuse time is the problem. Suppressing at 3236 points means waiting 15 * log2(3236 / 750) = 15 * 2.11 = 31.6 minutes after the last flap, which is slightly over the 30-minute budget.

Step two, move one knob. Raising reuse to 1000 drops the wait to 15 * log2(3236 / 1000) = 25.4 minutes. Raising the half-life to 20 minutes would push it the other way, to over 40 minutes. Step three, bound the worst case: with reuse 1000, half-life 15 and a 60-minute cap the ceiling becomes 1000 * 2^(60/15) = 16000, so no route can stay suppressed for more than an hour no matter how violently it flaps. That cap never binds for this particular customer, whose flap pattern peaks near 3236 points and therefore reuses after about 25 minutes.

The result is bgp dampening 15 1000 2000 60 applied through a route map that matches only the customer prefix list. Everything else on the router keeps its routes. This is the whole point of treating dampening as arithmetic: the difference between a 31-minute and a 25-minute outage window is a single decision made on paper, before the change window.

Common Parameter-Tuning Mistakes

  • Raising suppress without raising reuse. The two thresholds define a band; widening only the top of the band lengthens the penalty walk-down without making suppression more sensitive.
  • Setting max-suppress-time below the half-life. As shown above, the ceiling can fall under the suppress limit, leaving dampening configured but inert.
  • Applying dampening to iBGP or to all prefixes. RFC 2439 expects operations on EBGP-learned routes; blanket application inside an AS creates inconsistent views between routers that do and do not dampen.
  • Expecting identical results on every vendor. Cisco ships a 2000 suppress threshold while other implementations historically started at 3000, so a route that is suppressed on one router may still be announced by its neighbor.
  • Forgetting to clear state after an outage. Real instability can leave a healthy route suppressed for the full max-suppress-time; clear ip bgp dampening and a documented incident note are part of the process.

Related Reading on This Site

See also BGP route dampening penalty, suppress and reuse limits for the vendor configuration walk-through, RIPE-580 tuning guidance for route flap damping, BGP neighbor flapping root causes and the BGP timers deep dive.

原文链接:https://networklessons.com/bgp/bgp-route-dampening