BGP Route Dampening: Penalty, Suppress and Reuse

BGP route dampening protects routers from flapping routes - prefixes that are advertised and withdrawn over and over again, each flap triggering a BGP UPDATE and burning CPU. Cisco IOS implements the dampening mechanism with four parameters (penalty, half-life, suppress and reuse limits), and this article explains how they interact, how to enable dampening globally or with a route-map, and how to verify dampened routes with show commands.

This page is the configuration companion: it focuses on the actual command syntax as it differs between Cisco IOS, IOS-XR, NX-OS, Juniper Junos, Huawei VRP and Nokia SR OS, and on the operational decisions you make once dampening is in place. The underlying mathematics - how penalty decays, how the reuse time is derived and how to size the ceiling - is covered separately in the linked article on penalty and reuse limits.

How BGP Route Dampening Works

Each flap adds a penalty of 1000 to the route. When the accumulated penalty exceeds the suppress limit (default 2000), the route is dampened: it is neither installed in the routing table nor advertised to neighbors. The penalty decays with a half-life timer (default 15 minutes), halving every interval, and the route is reused once the penalty drops below the reuse limit (default 750). The maximum suppress time (default 60 minutes) prevents routes from being dampened forever.

Three properties of that description drive every configuration decision below. Dampening is applied to learned routes, so it is a receive-side filter on EBGP routes rather than a global switch. It is evaluated per prefix and per path, so two paths to the same prefix can have different penalty values. And it is local - a router that dampens a prefix stops advertising it, but its neighbors continue to hold their own copy of that prefix until they too decide to suppress or withdraw it.

Vendor Terminology and Defaults at a Glance

The single most important cross-vendor difference is the suppress threshold. Cisco ships 2000 while Junos historically shipped 3000, which means identical flap patterns can be suppressed on one vendor's router and still announced by another in the same network. If your edge is multi-vendor, align the numbers manually rather than relying on defaults.

Configuration: Global or Route-Map

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

For selective dampening, use a route-map with explicit parameters (half-life 15, reuse 750, suppress 2000, max-suppress 60):

R2(config)# ip access-list standard R1_L0
R2(config-std-nacl)# permit host 1.1.1.1
R2(config)# route-map DAMPENING permit 10
R2(config-route-map)# match ip address R1_L0
R2(config-route-map)# set dampening 15 750 2000 60
R2(config)# router bgp 2
R2(config-router)# bgp dampening route-map DAMPENING

Note the asymmetry that trips people up: the parameters are configured with set dampening inside the route map, but the route map itself is attached with bgp dampening route-map <name> - a bare bgp dampening route-map NAME with no parameters reuses the defaults for matching routes. On IOS the route map matches on the source of the advertisement (neighbor address or prefix), which is how you restrict dampening to EBGP-learned customer routes while leaving internally originated prefixes untouched.

Cisco IOS-XR and NX-OS Syntax

IOS-XR moved the parameters entirely into a route policy. The BGP process only references the policy, and the numbers live inside it:

RP/0/RP0/CPU0:XR1(config)# route-policy DAMPEN
RP/0/RP0/CPU0:XR1(config-rpl)# set dampening 15 750 2000 60
RP/0/RP0/CPU0:XR1(config-rpl)# end-policy
RP/0/RP0/CPU0:XR1(config)# router bgp 65001
RP/0/RP0/CPU0:XR1(config-bgp)# bgp dampening 15 750 2000 60 route-policy DAMPEN

NX-OS keeps the IOS-style model but uses a different keyword: dampening is configured with dampening rather than bgp dampening:

NX1(config)# router bgp 65001
NX1(config-router)# dampening 15 750 2000 60
NX1(config-router)# dampening route-map DAMPENING
NX1# show bgp dampening parameters

Juniper Junos: Damping Profiles

Junos separates the parameters from the application point. Profiles are defined as named objects under policy-options, then referenced from BGP at the routing-instance, group or neighbor level:

set policy-options damping DAMP_DEFAULT half-life 15
set policy-options damping DAMP_DEFAULT reuse 750
set policy-options damping DAMP_DEFAULT suppress 2000
set policy-options damping DAMP_DEFAULT max-suppress 60
set protocols bgp group EBGP-PEER damping DAMP_DEFAULT
set protocols bgp group CUSTOMERS damping DAMP_AGGRESSIVE

Profiles can also be applied per prefix with a route filter using the damping action, which is the Junos equivalent of matching a prefix list inside a Cisco route map. Verification uses the routing table rather than a BGP-specific table:

user@router> show route damping suppressed
user@router> show route damping suppressed detail | match Damping
user@router> show bgp summary
user@router> show bgp neighbor 10.0.0.2 | match Damp

In the show bgp summary output the table header carries Suppressed, History and Damp State columns next to the totals:

Table inet.0  Tot Paths  Act Paths  Suppressed  History  Damp State  Pending

Those columns are the fastest way to notice that damping has started doing something in production, because they are printed for the table as a whole rather than per prefix.

Huawei VRP: dampening and Route-Policy

Huawei configures dampening inside the BGP view with the four values in the order half-life, reuse, suppress, ceiling - the same semantics as Cisco with a different keyword order and a different name for the final parameter:

[HUAWEI] bgp 65001
[HUAWEI-bgp] dampening 15 750 2000 60
[HUAWEI-bgp] dampening route-policy DAMPEN
[HUAWEI] route-policy DAMPEN permit node 10
[HUAWEI-route-policy] if-match ip-prefix CUSTOMER
[HUAWEI-route-policy] apply dampening 15 750 2000 60

Verification and manual release follow the VRP house style - display for inspection and reset for action:

<HUAWEI> display bgp routing-table dampened
<HUAWEI> display bgp routing-table 1.1.1.1
<HUAWEI> reset bgp dampening
<HUAWEI> reset bgp dampening 1.1.1.1 255.255.255.255

In the Huawei BGP table a dampened route is flagged with d in the status column, exactly as Cisco prints *d. If a route shows as dampened in display bgp routing-table but not in display bgp routing-table dampened, you are most likely looking at a prefix whose penalty has dropped below the reuse limit; the status flags and the dampened view are refreshed at different points in the decay cycle.

Verification Commands

R2# show run all | include dampening
R2# show ip bgp dampening parameters
R2# show ip bgp dampening flap-statistics
R2# show ip bgp dampening dampened-paths
R2# show ip bgp 1.1.1.1/32

show ip bgp dampening parameters displays the half-life, max suppress penalty, suppress and reuse values; show ip bgp dampening dampened-paths lists routes currently suppressed with their reuse time. show ip bgp dampening flap-statistics is the underused one - it shows prefixes that have flapped but are not yet suppressed, which is where you want to be watching during an incident rather than after the prefix disappears from the table.

Watching Damping in Action

R2# debug ip bgp dampening
R1(config)# interface Loopback 0
R1(config-if)# shutdown          ! flap 1: penalty 1000
R1(config-if)# no shutdown
R1(config-if)# shutdown          ! flap 2: penalty 1835
R1(config-if)# no shutdown
R1(config-if)# shutdown          ! flap 3: penalty 2691 (above 2000)
R1(config-if)# no shutdown
R2# 
BGP(0): suppress 1.1.1.1/32 path 1 for 00:24:40 (penalty 2349)
halflife-time 15, reuse/suppress 750/2000

The route is now dampened (*d in the BGP table), not installed in the routing table, and not advertised. As the penalty decays below 750 the route is unsuppressed automatically; to force it, run clear ip bgp dampening 1.1.1.1 255.255.255.255.

Do this lab exercise once per platform you operate. The debug output is where the theory becomes concrete: the second flap shows a penalty below 2000 because decay has already started eating the first 1000 points, and only the third flap pushes it over. That is also why a route flapping once every fifteen minutes - exactly the half-life - hovers just under the suppress limit and is never dampened.

Operational Tuning: What to Change in Production

Dampening defaults are designed for a full routing table on a 1990s router. In production the goal is the opposite of a broad sweep: identify the adjacency or the customer that is actually flapping, and dampen only those prefixes.

• Scope it to EBGP. Apply dampening on the peer group or route-map that matches external peers. Internal flapping should be fixed at the source - an unstable IGP or an interface error counter - not hidden behind a penalty timer.
• Match on the flapping source. A route map or damping profile keyed on the neighbor address is more precise than a prefix list, because it keeps the treatment attached to the device that is unstable.
• Watch the right counters. Alert on show ip bgp dampening flap-statistics rows and on the number of dampened paths, and correlate with interface flap counters and IGP adjacency logs before you tune anything.
• Keep the ceiling under control. The maximum suppress time, not the suppress limit, determines the worst-case outage you are creating. A 60-minute default is a long time to have a customer prefix missing from the Internet.
• Align across vendors. If your network mixes Cisco, Junos and Huawei, document one parameter set and configure it explicitly everywhere instead of inheriting different defaults.
• Prefer route-refresh over hard resets when applying policy changes, so that re-evaluating dampening does not cost you a session flap of its own.

Change Control and Rollback

Dampening is a change to how quickly your network forgets instability, which makes it a change worth recording. Before enabling it, capture a baseline: show ip bgp summary for prefix counts and show ip bgp flap-statistics if the platform supports accumulating flap counters. Write down the four parameter values as configured rather than as defaulted, and note the time the change was applied - the decay timers make "when did this start" a legitimate forensic question later.

Rolling back has two parts. Removing the configuration stops new penalties from being accumulated, but it does not resurrect prefixes that are currently suppressed on some implementations; clear the dampening state explicitly with clear ip bgp dampening (Cisco), clear bgp damping (Junos) or reset bgp dampening (Huawei) after the rollback. If you rolled back because a legitimate prefix was suppressed, keep the prefix in a route map exclusion for the next attempt rather than abandoning the feature for the whole network.

Operational Guidance

Dampening should not be enabled blindly - RIPE publishes recommendations (RIPE-580) on safe default parameters because overly aggressive dampening can suppress stable routes for long periods. Published practice now leans towards not using route flap damping on transit sessions at all, and towards applying it - if at all - only where the flapping source is known and the blast radius is small. Apply it mainly to EBGP-learned routes and keep the defaults close to RFC 2439 values. In multi-vendor edges, remember that a suppressed route on one router is still announced by its neighbors until their own penalty timers expire, which is why inconsistent parameters produce the confusing symptom of a prefix that appears to come and go depending on which router is asked.

Related articles: BGP route dampening penalty and reuse limits explained, Junos BGP flap damping parameters and configuration, BGP dampening configuration guide for Cisco and Junos and BGP timers: hold, keepalive and MRAI explained.

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