Junos BGP Flap Damping: Parameters and Configuration Guide

BGP route flap damping is the classic defense against unstable peers that continuously advertise and withdraw routes, but on Junos OS it is disabled by default and needs both a parameter set and a routing policy to work. This guide explains the four damping parameters — half-life, max-suppress, reuse and suppress — with their Junos defaults, and shows how to enable flap damping correctly without accidentally suppressing stable routes. It is the Junos-specific companion to our general BGP route flap damping article.

What Junos Flap Damping Does

Junos marks flapping routes as ineligible for selection as the active route, which delays propagation but dramatically reduces the number of update messages between BGP peers. Damping is normally applied to EBGP routes and to confederation-boundary routes. Do not apply flap damping to IBGP routes — routing consistency inside an AS matters more than update reduction, and Junos ignores damping on IBGP routes anyway. From Junos 12.2 you can apply damping at the address family level, which works for both IBGP and EBGP.

Mechanically, damping works on a figure of merit: a numeric estimate of how unstable a route has been. Every incident that suggests instability adds to the figure of merit, and the value decays exponentially while the route stays stable. While the figure of merit is high, the route is still usable; once it crosses the suppression threshold, the route is held out of the routing table entirely and no longer advertised to peers. The two thresholds and the two timers in the table below are the whole of the mechanism.

Two consequences follow immediately, and both are easy to get wrong:

• Damping does not stop a route from flapping. It stops a flapping route from propagating. The instability is still there, on your router, in the BGP table - damping removes the noise from the rest of the network and buys support staff time to fix the underlying fault.
• Damping is a suppression mechanism, and suppression is a blunt instrument. A route you suppress is a route you are not advertising, which means traffic that would have used it is not using it. Tune accordingly.

How the Figure of Merit Works

The four parameters interact through a simple arithmetic that is worth internalising before you change any defaults.

• Each damping incident adds a penalty - in Junos, 1000 per event. Critically, Junos increases the figure of merit on both a route withdrawal and a route re-advertisement. Vendors whose implementations only count withdrawals reach the same thresholds more slowly; to map a threshold from such a platform onto Junos, multiply their reuse and suppress values by 2.
• While the route is stable, the figure of merit decays by half every half-life minutes.
• When the figure of merit exceeds suppress, the route is suppressed and held down.
• When decay brings the figure of merit back below reuse, the route becomes eligible again and is re-advertised.

The ceiling matters more than most engineers realise. The maximum figure of merit a route can accumulate is bounded, because a route that has been suppressed for max-suppress minutes is released regardless of how large its penalty is. That gives the merit ceiling:

merit_ceiling = reuse x 2^(max-suppress / half-life)

with Junos defaults:
merit_ceiling = 750 x 2^(60 / 15) = 750 x 16 = 12,000

If your suppress value is greater than that ceiling, the figure of merit can never reach it, and damping never happens at all - the configuration looks correct, the policy is committed, and the feature is silently doing nothing. With the defaults, suppress is 3000 and the ceiling is 12000, so there is comfortable headroom. Raise suppress towards the top of its 3000-20000 range while leaving the other parameters alone and you can cross that line.

One further constraint is enforced at commit time: half-life must be less than max-suppress. If it is not, the configuration is rejected outright, which is a rare kindness from the commit checker.

Default Damping Parameters

Read the defaults as a policy statement rather than as neutral values. A penalty of 1000 per event against a suppression threshold of 3000 means a route is suppressed after three damping events - that is, roughly one and a half flaps, since each flap contributes a withdrawal and a re-advertisement. A suppressed route then stays down for up to an hour. In other words, the Junos defaults are already fairly aggressive, which is exactly why most of the tuning advice below is about making damping less willing to suppress.

Configuring Damping with a Routing Policy

To change the defaults, create a named set of damping parameters and reference it from a routing policy using the damping action, then enable damping on BGP:

policy-options {
    damping my-damping {
        half-life 20;
        max-suppress 120;
        reuse 1000;
        suppress 4000;
    }
    policy-statement damp-flaps {
        term damp {
            from {
                protocol bgp;
                route-type external;
            }
            then {
                damping my-damping;
                accept;
            }
        }
    }
}
protocols bgp {
    group ebgp-peers {
        import damp-flaps;
    }
}

With damping enabled, the route's penalty increases on each flap; once it crosses the suppress threshold the route is held down for up to max-suppress minutes, and it is reused again when the penalty decays below the reuse threshold.

Written as CLI commands, the same configuration is more compact and easier to stage safely:

[edit]
set policy-options damping my-damping half-life 20
set policy-options damping my-damping max-suppress 120
set policy-options damping my-damping reuse 1000
set policy-options damping my-damping suppress 4000
set policy-options policy-statement damp-flaps term damp from protocol bgp
set policy-options policy-statement damp-flaps term damp from route-type external
set policy-options policy-statement damp-flaps term damp then damping my-damping
set policy-options policy-statement damp-flaps term damp then accept
set protocols bgp group ebgp-peers import damp-flaps
commit

What the policy engine is doing

Two details in that policy are load-bearing.

The damping action does not merely annotate the route - it hands the route to the damping machinery, which is why you must also declare the named parameter set under policy-options. Omitting the parameter set gives you a configuration that references something that does not exist, and the commit will tell you so.

The accept in the same term matters too. A policy that only applies damping and then falls through to an implicit deny will drop every route it touches. The term above accepts what it damps and lets everything else fall through to the BGP default, which is to accept.

Applied Where: EBGP, IBGP and Address Families

Where you attach the policy changes what you are protecting.

• On an EBGP group - the standard case. You are protecting your network from a customer or peer whose internal churn is leaking into your table, and the update reduction is paid for once, at the edge.
• On a confederation boundary - damping works there as well, since confederation sub-AS sessions behave like the external sessions.
• On IBGP - do not do it, and mostly you cannot: Junos ignores damping on IBGP routes. Suppressing a flapping prefix inside your own AS does not reduce updates anywhere, because every router in the AS sees the churn locally through the interior protocols. What it does do is create a situation where different routers disagree about which prefixes exist, which is a far worse problem than extra updates.
• At the address family level - from Junos 12.2 onward, damping can be applied per address family, which makes it usable for both IBGP and EBGP. This is the escape hatch when you have a specific scenario that the standard EBGP-only model cannot express, but it is not a reason to start damping your interior routes.

A related trap lives in route reflectors. If you damp a route on the RR, the suppression is inherited by the clients, so a flapping external prefix can disappear from a large part of your network in one step. That amplification is fine when damping is tuned conservatively and dangerous when it is not.

Verifying That Damping Is Working

Damping gives you plenty of visibility, and checking it after every change should be routine. Start with the parameters that are actually in effect - this is the fastest way to confirm that your policy is attached to the right peer, and it also shows the defaults you did not override:

user@host> show policy damping

Then look at routes that are currently held down, and at routes that have a penalty but are still active:

user@host> show route damping suppressed
user@host> show route damping suppressed 172.16.192.0/20 detail
user@host> show route damping decayed
user@host> show route detail

The detail view is the one worth reading during an incident: it shows the route's current and last figure of merit, the damping profile that matched it, and when the route is expected to become active again if it stays stable. From there you can decide whether to wait for the decay or intervene. The BGP summary counts the suppressed and damped routes per peer:

user@host> show bgp summary
user@host> show bgp neighbor 192.0.2.1 | match -i "flap|damp"

In show bgp summary, look for the Suppressed column (routes currently inactive because of damping) and the History column (withdrawn routes stored locally so their damping history is preserved). A route that has flapped and then gone away still carries its penalty, which is precisely why an intermittently-flapping prefix gets suppressed faster than a continuously present one.

If you need to release damped routes immediately - for example because you have fixed the root cause and do not want to wait out the hold-down timer - clear the damping state:

user@host> clear bgp damping

A Quick Lab Walkthrough

The most reliable way to understand damping is to induce it. On a lab pair, restart the routing process on a neighbour or clear the session repeatedly and watch the counters climb:

user@host> clear bgp neighbor 192.0.2.1
user@host> show bgp summary
user@host> show route damping suppressed
user@host> show route damping suppressed detail

Four rounds of that on a link carrying a dozen prefixes is usually enough to see a subset of them hidden by damping, with the detail output showing which damping profile matched each prefix. Add a second damping profile and a policy that selects it by mask length and you can reproduce the standard Junos example: aggressive damping for long, specific prefixes and conservative damping (or none at all) for aggregates.

Damping Tuning Best Practices

Start with conservative thresholds and monitor actual flaps before tightening them. Aggressive damping can take down legitimate routes during temporary network incidents — the same trap documented in our BGP route flap damping explained article. Also review BGP neighbor flapping root causes before deciding damping is the answer, and see BGP ECMP configuration on Cisco, Juniper and Arista for related tuning.

On top of those, five rules cover most of the mistakes people make:

1. Raise the thresholds before you shorten the timers. If you are seeing legitimate prefixes suppressed, raising suppress to 4000-6000 fixes it. Changing half-life instead changes how long everything stays suppressed, including the routes you wanted to catch.
2. Keep half-life comfortably below max-suppress. A 15-20 minute half-life against a 60-120 minute hold-down is the sane region. These are the two parameters that determine how much of your policy is decay versus blunt-force hold-down.
3. Recompute the merit ceiling every time you touch suppress. If suppress approaches reuse x 2^(max-suppress/half-life), damping quietly stops working. With defaults, anything above 12000 is suspect.
4. Never damp interior routes. The Junos implementation declines to damp IBGP routes for good reasons; do not work around it.
5. Treat damping as a symptom manager, not a fix. A route that needs damping is a route with a problem underneath it. Damping buys you time to find the problem - it does not remove the fault, and it will not stop the next flap.

There is also a wider industry context worth knowing. The most aggressive damping profiles popularised in the 1990s were later shown to cause collateral damage during real incidents, and many operators moved to the much more conservative RIPE-580 style recommendations or disabled damping altogether on EBGP. Our parameter-by-parameter walkthrough of how half-life and reuse interact, BGP route flap damping: half-life and reuse, digs into the arithmetic; the practical conclusion is that Junos ships with parameters that work, and the burden of proof is on you if you intend to make them more aggressive.

Common Mistakes and Gotchas

Damping is configured but nothing is suppressed. Check the merit ceiling formula above first, then confirm with show policy damping that your policy is actually attached to the peer, and with show route damping suppressed that the routes are really accumulating penalties. A policy applied as export instead of import on the intended group is a classic quiet failure.

A stable route got suppressed. Look at the route's history rather than its current state. A prefix that flaps a few times an hour and then goes quiet can still sit above the suppress threshold, because the penalty decays slowly by design. The History counter in show bgp summary is where those withdrawals are remembered.

Different routers disagree about a prefix. Somebody is damping where they should not, typically on IBGP or at a route reflector. Remove the policy from the interior path and let the edge do the work.

Thresholds do not match the vendor documentation. They probably do, and you are comparing a platform that counts only withdrawals to Junos, which counts withdrawals and re-advertisements. Multiply the other vendor's reuse and suppress by 2 for an equivalent comparison.

Damping looks like the wrong fix entirely. If a single peer is flapping, damping hides the symptom and leaves a flapping session in place. Session-level problems - a bad optic, an MTU mismatch, a route-limit violation - belong to interface and session troubleshooting, and it is often faster to fix the flap than to tune the damping that conceals it.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/routing-policy/bgp/topics/concept/routing-policy-security-damping-parameter-understanding.html

Additional reference: Using Routing Policies to Damp BGP Route Flapping (Junos OS)