BGP Route Flap Damping Explained: How It Works and How to Configure It

BGP route flap damping is the mechanism that protects the global routing table from unstable prefixes. When a route flaps - goes up, down, up again - every flap is announced to every BGP peer, and a few flapping prefixes can burn router CPU across the whole internet. Damping assigns a penalty to a prefix every time it flaps; once the penalty crosses a suppress threshold the prefix is not advertised anymore, and it is only reused after the penalty decays below a reuse threshold. This article explains the mathematics of damping, shows real Cisco IOS and Junos configurations, and covers the caveats every network engineer should know before enabling it.

How Route Flap Damping Works

Each flap event adds a penalty (default 1000 per flap on Cisco) to the prefix's figure-of-merit. The penalty decays exponentially over time according to the half-life. Three parameters control the whole process:

• Suppress threshold (default 2000): penalty above this stops advertisement of the route.
• Reuse threshold (default 750): penalty must decay below this before the route is re-advertised.
• Maximum suppress time (default 60 min): cap on how long a prefix can stay suppressed.
• Half-life (default 15 min): time for the penalty to halve.

With defaults, two flaps (2 × 1000 = 2000) suppress the route immediately; after the penalty decays below 750 the route comes back.

The mechanism is described in full in RFC 2439. Everything below is a direct consequence of one exponential decay function and three thresholds - once you have the math, every timer value and every vendor default becomes predictable rather than folklore.

The Damping State Machine in One Picture

A damped prefix lives in one of three states. The diagram below is the whole mechanism; the code blocks that follow are just the arithmetic behind the arrows.

                       +1000 penalty per flap
    +--------------+   ---------------------------------->   +--------------+
    |  USABLE      |                                          |  PENALTY     |
    |  (advertised)|   <----------------------------------   |  BUILDING    |
    +--------------+        penalty < reuse (750)             +--------------+
            ^                                                       |
            |                                                       | penalty >= suppress
            |                                                       | (2000 Cisco / 3000 Junos)
            |                                                       v
            |                                              +--------------+
            |            penalty decays toward reuse       |  SUPPRESSED  |
            +------------------------------------------    |  (withdrawn) |
                     OR max-suppress-time (60 min)         +--------------+
                     expires - whichever comes first

Three observable events define the behaviour of any prefix: when it enters SUPPRESSED, how long it stays there, and whether the max-suppress-time cap ever binds. All three are arithmetic, and you can predict them on paper before you touch a router.

The Penalty Decay Equation, Without Hand-Waving

Penalties are additive and each contribution decays independently. If flaps happen at times t₁, t₂, ... t_n and the half-life is H (in minutes), the penalty at time t is:

P(t) = SUM over i of  1000 * 0.5 ^ ((t - t_i) / H)

Because every term decays at the same rate, the constant 0.5 can be factored out and the accumulated penalty for the last flap is all you need:

P(t) = P_last * 0.5 ^ ((t - t_last) / H)

Rearranging that for time gives the single most useful formula in damping - how long until a penalty falls back to a given threshold:

t_decay = H * log2( P / threshold )

With the Cisco defaults (H = 15 min, reuse = 750):
  a route suppressed at exactly 2000 needs 15 * log2(2000/750) = 21.2 min
  before it can be re-advertised.

That 21.2 minutes is the minimum suppression time with default timers. Any prefix that accumulates more than 2000 penalty stays down longer, up to the max-suppress-time ceiling of 60 minutes. Nothing else in the mechanism is hidden: suppress, reuse and half-life are the only knobs, and this formula converts them straight into wall-clock minutes.

Worked Example 1: One Flap Is Never Suppressed

t = 0 min   flap  ->  P = 1000     (below suppress 2000: still advertised)
            P decays:   1000 -> 750 requires 15 * log2(1000/750) = 6.2 min

A single flap adds 1000, which is half the suppress threshold. The prefix keeps advertising, and the penalty is back under the reuse threshold 6.2 minutes later. This is the design intent: a one-off line card reset or a fibre clean must not take a customer offline.

Worked Example 2: Three Flaps Ten Minutes Apart

Now the interesting case. Flaps at t = 0, t = 5 and t = 10 minutes on default timers:

t = 0   flap                        P = 1000.0
t = 5   decay 5 min, then flap      P = 1000*0.5^(5/15) + 1000   = 1793.7   (not suppressed)
t = 10  decay 5 min, then flap      P = 1793.7*0.5^(5/15) + 1000 = 2423.7   (SUPPRESSED)

Time to reach reuse 750:  15 * log2(2423.7 / 750) = 25.4 min after t = 10
Total outage for the prefix:  ~35.4 min from the first flap

Note the shape of the numbers: after the first flap the penalty had already decayed to 793.7 by t = 5, so the second flap only reached 1793.7 - still under 2000. The third flap crossed the line. This is why flap counting with a 15-minute half-life is not intuitive: flaps spread wider than 15 minutes apart decay so far that they never accumulate, while a burst of three inside ten minutes takes a prefix out for half an hour.

Worked Example 3: A Chronic Flapper and Why max-suppress-time Exists

A defective CPE that resets every minute produces a burst pattern that no threshold can outrun. If a prefix flaps every 1 minute indefinitely, the penalty converges on a steady state:

P_steady = penalty_per_flap / (1 - 0.5^(interval / H))
         = 1000 / (1 - 0.5^(1/15))
         = 1000 / (1 - 0.95484)
         = 22,144

Time to decay from 22,144 to reuse 750:
         15 * log2(22144 / 750) = 73.3 min
max-suppress-time (60 min) binds: the route IS readvertised after 60 min.

Without a max-suppress-time ceiling, a permanently flapping prefix would be suppressed forever - even after the fault was repaired. The cap guarantees that a prefix is re-advertised at least once every 60 minutes, giving the BGP table a chance to see it again. That is the whole purpose of the fourth timer, and it is also why the ceiling must be longer than the reuse decay time for normal cases: with defaults, the deepest penalty that a healthy route can build still clears 750 well inside 60 minutes.

The Decay Table: Penalty vs Time

Same example as above - a prefix suppressed at 2423.7 - evaluated minute by minute with the closed-form formula. This is exactly the shape you see in show ip bgp dampening flap-statistics:

Two practical readings follow from the table. First, the decay is front-loaded: most of the penalty disappears in the first 15 minutes, so a suppressed prefix comes back sooner than a linear intuition suggests. Second, the residual penalty never returns to zero in any practical time window - a prefix that flaps again at minute 60 starts from 179, not from 0, which is exactly how damping remembers "repeat offenders".

What the Numbers Mean Operationally

• Penalty is additive, not a flap counter. Two flaps in quick succession cross a 2000 threshold; two flaps an hour apart never will.
• Reuse is a one-way gate. A prefix does not need to be re-advertised to be re-suppressed - once it is back under the reuse threshold it is advertised again and a fresh flap can push it straight back over the suppress threshold.
• Suppression does not extend itself. Per RFC 2439, a route that is already suppressed does not accumulate further penalty for flap events while suppressed, so continued flapping cannot push the reuse time past max-suppress-time. Verify the exact behaviour of your platform in a lab before you rely on the edge cases - vendor implementations differ in the details.
• The thresholds, not the half-life, decide how many prefixes get hit. Raising suppress from 2000 to 6000 requires six flaps instead of three to take a prefix down, which is the difference between ~14% and ~2% of prefixes being suppressed in the RIPE measurement discussed below.

Cisco IOS Configuration

router bgp 65001
 bgp dampening
 bgp dampening 15 750 2000 60
 bgp dampening route-map ONLY-DAMPEN

Plain bgp dampening uses defaults. The four-argument form is bgp dampening <half-life> <reuse> <suppress> <max-suppress>. A route-map lets you dampen only selected prefixes (for example, only customer routes, never transit or local prefixes). Because the four numbers are positional and easy to transpose, always confirm what the router actually parsed with show ip bgp dampening parameters after applying them.

Cisco Verification Commands

show ip bgp dampening parameters
show ip bgp dampening flap-statistics
show ip bgp dampened-paths
clear ip bgp dampening

show ip bgp flap-statistics lists flapping prefixes with their current penalty; show ip bgp dampened-paths shows prefixes currently suppressed. When you see a penalty value in this output, divide it by 1000 to count "flaps equivalent" - a prefix sitting at 6000 has effectively banked six flaps and will need 15 · log2(6000/750) = 45 minutes to clear once the flapping stops.

Junos Configuration

Junos implements damping as a policy option applied to BGP import/export:

policy-options {
    damping DAMP {
        half-life 15;
        reuse 750;
        suppress 2000;
        max-suppress 60;
    }
}
protocols bgp {
    group CUSTOMERS {
        import DAMP-IMPORT;
        export DAMP-EXPORT;
    }
}

Then reference the damping profile in a policy statement:

policy-options {
    policy-statement DAMP-IMPORT {
        term damp {
            from protocol bgp;
            then {
                damping DAMP;
                accept;
            }
        }
    }
}

Junos Verification Commands

show route damping
show route damping flap-statistics
show route damping suppressed

Junos ships with a higher default suppress threshold than Cisco (3000 rather than 2000), so out of the box a Junos edge suppresses a prefix one flap later than a Cisco edge running defaults. In a mixed-vendor transit fabric that asymmetry shows up as a prefix that stays reachable through one provider and disappears through another - a debugging trap worth remembering.

Choosing Timer Values: Defaults, RIPE-580 and Customer-Only Damping

The published defaults are the worst-supported numbers in the mechanism: they were chosen to be conservative in an era when control-plane CPU was scarce, and they suppress far too many well-behaved prefixes. RIPE-580 measured the trade-off directly and recommends a suppress threshold of at least 6000:

The RIPE-580 measurements put numbers on what each threshold costs: a suppress threshold of 2000 reduced BGP churn by 47% but suppressed 14% of all observed prefixes at some point, while 6000 reduced churn by only 19% but suppressed just 2.1% of prefixes. Since 0.01% of prefixes cause 10% of the update load, the practical conclusion is to dampen hard on a very small population: raise the threshold, keep the half-life, and scope damping with a route-map or policy so that only customer-facing prefixes are ever eligible.

Deployment Checklist Before You Enable Damping

1. Scope it. Apply damping to customer routes only. Never to iBGP, never to transit or peering prefixes you do not control.
2. Raise the suppress threshold. Start at 6000. If your platform caps the suppress value, check the release notes - RIPE-580 asks vendors for a ceiling of 50,000 because 6000+ values are the point of the exercise.
3. Write down the arithmetic. For the profile you chose, compute t_decay = H · log2(suppress/reuse). If that number is longer than you are willing to be unreachable, lower the half-life.
4. Verify what the device parsed. show ip bgp dampening parameters or show route damping - not the config diff.
5. Monitor the suppression count. A non-zero population of dampened paths on a customer edge is a signal, not background noise: it means at least one customer prefix is flapping enough to be punished.

When Damping Hurts (RFC 7196)

Research and RFC 7196 showed that damping can make things worse: a prefix that flaps repeatedly is often a slow-converging but stable destination, and damping delays its recovery, effectively blackholing it for minutes. As a result, most large ISPs have either disabled damping entirely or restrict it to customer edge prefixes. Practical guidance:

• Never dampen iBGP or full-table routes from transit providers.
• Dampen only customer-announced prefixes, and only when flap rates are pathological.
• Use route-maps/policy to scope damping narrowly.

Related articles: BGP neighbor flapping root causes and fixes, BGP ECMP configuration on Cisco, Juniper and Arista, BGP route dampening: penalty, suppress and reuse limits and BGP timers explained: hold, keepalive and MRAI.

原文链接：https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/46000-route-flap-damp.html