Junos Interface Flapping: Hold-Time and Damping Configuration

Link instability is one of the most disruptive problems in production networks: interfaces that flap repeatedly trigger routing churn, unnecessary failovers, and in the worst case take down entire subscriber sessions. Junos OS gives operators two built-in mechanisms to suppress transient interface failures before they ever reach the routing process — static hold-time timers and exponential backoff damping. This guide explains when to use each method, how to choose timer values based on interface role, and how to deal with hardware faults at the data-plane level on MX-series routers, based on Juniper Networks' official guidance for the MX204, MX301, MX304, MX10004, and MX10008 platforms.

Why Interface Flapping Is Dangerous

Every time a physical link goes down and comes back up, Junos advertises the state change to routing protocols such as IS-IS, OSPF, and BGP. Short, repeated flaps cause the IGP to recompute SPF over and over, flooding LSAs across the network and consuming CPU on every adjacent router. In broadband edge designs where the MX terminates PPPoE sessions, a simultaneous flap can disconnect all subscribers at once. Damping the interface at the physical layer is therefore the first line of defense.

The damage is not limited to routing. A flapping interface also churns through MAC address tables on adjacent switches, forces ARP and neighbour entries to be re-resolved, resets interface counters that your monitoring depends on, and in a LAG keeps the bundle's hashing state in constant motion. Each flap becomes an event that triggers log entries, SNMP traps, and alerting, so a link that flaps twenty times an hour will generate more operational noise than a link that is simply hard down. Worse, a flapping link often stays up long enough between flaps for the control plane to declare it healthy and start using it again — which is exactly the behaviour that turns a marginal optic into a network-wide incident.

Recognising Flapping Before You Fix It

Both mechanisms below work on the symptom. Confirm the symptom first, or you will damp traffic on a perfectly healthy link. Three sources tell you almost everything:

• Carrier transitions in show interfaces <interface> extensive — the count of down/up cycles. It should climb slowly, a handful of times over a device's lifetime.
• Log messages — show log messages | match "SNMP_TRAP_LINK_DOWN" or a match on the interface name gives you a timestamped flap history you can correlate with events.
• Protocol churn — repeated adjacency resets in show isis adjacency or show ospf neighbor point at a single unstable member even when the counters look tame.

show interfaces ge-0/0/1 extensive | match "Carrier transitions|Link flags|Laser bias"
show log messages | last 500 | match "ge-0/0/1"
show isis adjacency brief
show ospf neighbor detail | match "ge-0/0/1"

Two classes of flap emerge from this data, and they map exactly onto the two damping methods. Flaps measured in milliseconds are usually transport artefacts — protection switching on an optical layer, an ADM or WDM regenerator briefly losing framing, or a SONET/SDH framer hole. Flaps measured in seconds, repeating on a regular cadence, are usually physical: a marginal optic, a dirty connector, a failing PSU on the far end, or a controller rebooting on a schedule.

Method 1: Static Hold-Time Timers

Static hold-time timers are configured per interface and per link state (up and down). They are expressed in milliseconds and are best suited to short-duration flaps in the millisecond range, such as those caused by transport protection switching.

set interfaces ge-0/0/1 hold-time up 5000
set interfaces ge-0/0/1 hold-time down 0

Juniper recommends setting hold-time up to a value greater than or equal to the IGP SPF hold-down timer (for example, 5000 ms for IS-IS by default). This prevents short repeated flaps from reaching the routing process and reduces unnecessary flooding. Keep hold-time down at 0 ms unless a specific use case requires a delay, so that link-down events are still reported to routing protocols immediately.

The mechanism is a filter, not a delay. When a down-to-up transition occurs, the up hold timer starts; every transition that happens while the timer is running is ignored, and when the timer expires with the interface still up, the router advertises "up" once. If the interface drops again inside the window, nothing is advertised at all and the cycle simply repeats. The physical link state is still tracked internally and still visible in your monitoring — what is suppressed is the advertisement to the upper-layer protocols and the hardware notification.

Two details matter in practice. Junos OS advertises the transition within 100 milliseconds of the configured value, so a 5000 ms timer is not exactly 5000 ms. And the acceptable values are not symmetric with reality: the timers default to 0 ms, which means transitions are not damped at all, and the range runs from 0 up to 4,294,967,295 ms — a range large enough that a typo can silently park a link's advertisement for weeks. Review any hold-time statement above 10,000 ms with real suspicion. On specific platforms Juniper also recommends a sub-second down hold timer of 500 ms: the MX204, and MX routers with MPC7E, MPC8E, MPC9E, MPC10E and MX10003-LC2103 MPCs. That sub-second down timer is not supported on interfaces built on MPC3E, MPC4E, MPC5E, MPC5EQ, MPC6E and MPC11E, so a configuration copied from a newer line card onto an older one will simply fail or be ignored.

Method 2: Exponential Backoff Damping

For periodic, longer-duration flaps measured in seconds, use interface damping with an exponential backoff mechanism similar to BGP route dampening:

• Each interface down event adds a penalty of 1000.
• The penalty decays by 50% every half-life interval while the interface stays stable.
• When the penalty exceeds the suppress threshold, Junos OS suppresses the interface and stops advertising state changes to routing protocols.

Choose damping parameters based on the interface role — core, customer, peer, or edge — and on whether redundant paths exist. Juniper also recommends using similar damping configuration on both ends of the physical interface; damping on one end only can produce undesired behavior.

The four parameters that control the algorithm are all tunable, and their defaults are deliberately conservative:

• half-life — how fast the penalty decays, 1 to 30 seconds, default 5 seconds.
• reuse — the penalty value at which the interface leaves the suppressed state, 1 to 20,000, default 750.
• suppress — the penalty value that puts the interface into the suppressed state, 1 to 20,000, default 3000.
• max-suppress (max-suppress-time) — the ceiling on how long an interface can stay suppressed regardless of how unstable it has been, 1 to 255 seconds, default 60 seconds.

set interfaces et-0/0/0 damping half-life 10
set interfaces et-0/0/0 damping reuse 750      # default - quick recovery
set interfaces et-0/0/0 damping suppress 2000  # lower than default 3000 = more sensitive
set interfaces et-0/0/0 damping max-suppress 60
set interfaces et-0/0/0 damping enable

With the defaults, three down events in quick succession (3 × 1000 penalty) push a link past the 3000 suppress threshold and it stops advertising until the penalty decays below 750. The relationship between the thresholds is what makes the timer meaningful: a reuse value close to suppress means the interface unsuppresses almost immediately after the penalty starts decaying, while a wide gap keeps a flaky link out of service for much longer. Setting suppress below the default makes the mechanism more sensitive — a 2000 threshold trips on two flaps rather than three, which is appropriate for a link with full redundancy and inappropriate for a single-homed customer access port.

Note the interaction between the two methods. Damping is driven by interface down events, while a hold timer removes short events from the event stream entirely. Configure both and the hold timer acts as a pre-filter: sub-second noise never accumulates penalty, and only flaps that survive the hold window contribute to the damping counter. That combination is the recommended end state for core and aggregation links.

Choosing Values by Interface Role

There is no single correct timer set; the right values depend on what a false "up" or an unnecessary "down" costs you. A workable starting framework:

• Core and P2P transport interfaces — hold-time up in the 3000–5000 ms range to swallow protection-switch blips, hold-time down 0 so genuine failures are announced immediately. Damping enabled with default thresholds. False suppression is cheap because an IGP still has alternate paths, and the 60-second max-suppress cap bounds the damage.
• Aggregation and LAG members — hold-time up 2000–3000 ms, damping on. A LAG member that flaps costs you capacity and hash rebalancing, not reachability, so suppressing it is almost always the right trade. Pair damping with set interfaces ae0 aggregated-ether-options minimum-links N so that a bundle losing too many members goes down cleanly instead of running congested.
• Single-homed customer or edge access ports — hold-time up small or unset, damping with a high suppress threshold (or disabled). Here the link is the service: suppressing the advertisement means the customer's session stays down even after the link physically recovers, and a subscriber will notice that far sooner than they notice one extra flap.
• Inter-provider or BGP peering links — hold-time up 2000–5000 ms so that micro-flaps do not reset BGP sessions and burn through route churn and prefix dampening penalties downstream. Set max-suppress no higher than your BGP hold timer, otherwise a suppressed interface can outlast the session it protects.

Whatever values you pick, set them in a configuration group and apply the group per interface role rather than hand-editing each port. It makes intent reviewable and it makes a fleet-wide change a single edit.

Resolving Data-Plane Hardware Issues

When flapping is caused by actual hardware faults rather than transport issues, Junos can be configured to react automatically. On MX platforms, the system can isolate a faulty Packet Forwarding Engine and, depending on the design, remove up to two links from a LAG; if another PFE carrying upstream traffic fails, that PFE is disabled to prevent traffic impact. Operators can also collect diagnostics manually:

• get-state — collect additional diagnostic data and store it in /var/tmp
• CM-ALARM — generate an internal CMERROR notification
• LOG — generate a syslog message
• RESET — restart the affected component (PFE or line card)

Designing around PFE-level failure matters as much as configuring the timers. On a chassis where each line card carries several independent PFEs, distributing interfaces across at least two line cards and limiting connections to a maximum of two ports per PFE on the same line card means that losing a single chip degrades bandwidth rather than removing reachability. Apply the same rule to LAGs: spread member links across different PFEs and line cards so that one hardware fault can only ever take a fraction of the bundle.

Before escalating to a component reset, rule out the cheap causes. Check optical receive power with show interfaces diagnostics optics, reseat the optic, and confirm the far end is not rebooting on a schedule. A large share of "hardware flap" tickets resolve as a dirty fibre end face or a transmitter running at the edge of its budget.

Operational Takeaways

Start with hold-time timers for sub-second transport flaps, then layer on exponential damping for persistent periodic flaps, and finally address the hardware root cause on the data plane. For more Junos operational detail, see our guides on identifying a flapped interface with Junos EX CLI commands and troubleshooting Junos LAN reachability issues; a quick cross-vendor command reference is available in the multi-vendor network CLI cheat sheet, and the Layer-1 side of the same problem is covered in our Junos Layer-1 interface flapping troubleshooting guide.

Finally, monitor the damping state itself. An interface that sits suppressed for hours at a time is not being protected, it is hiding a fault — the damping state and its time-to-unsuppress counter belong on your dashboard next to carrier transitions. Damping buys you stability while you diagnose; it is not a substitute for diagnosis.

原文链接：https://juniper.net/documentation/us/en/software/platform/mx301-configuration-essentials/configuration-essentials-mx301-mx304/topics/concept/mx-resolving-hw-issues.html