Junos Interface Flapping: Layer 1 Troubleshooting Checklist

An interface that flaps — repeatedly toggling between up and down — is almost always a Layer 1 problem wearing a disguise. Juniper's interface troubleshooting methodology is blunt about this: if the logs show clean RPD_INTERFACE_DOWN and RPD_INTERFACE_UP transitions with no protocol errors in between, stop looking at configuration and start looking at cables, optics and signal. This article turns Juniper's official troubleshooting topics into a checklist you can run from the console, and adds the Layer 2 causes worth ruling out once the physical layer is proven clean.

Recognise the Symptom Pattern

Feb 15 10:00:02 router rpd[1234]: RPD_INTERFACE_DOWN: Interface ge-0/0/0.0 changed state to Down
Feb 15 10:00:03 router rpd[1234]: RPD_INTERFACE_UP: Interface ge-0/0/0.0 changed state to Up

Rapid up/down cycles with clean logs point to degraded optics, loose cables or marginal signal — not MTU mismatch, duplex or IP conflicts, which produce error counters and negotiation failures instead of link transitions. The JNCIA troubleshooting material sums it up as: "if the link dances but the logs are clean, suspect the SFP."

The reverse is equally diagnostic. If the interface comes up and stays up but the counters climb, you have a signal-integrity problem, not a link problem. Telling those two cases apart in the first two minutes is what separates a fast repair from an hour of guessing.

Flapping Is Not Damping

Before touching hardware, be clear about which problem you have. Flapping is the physical link bouncing: the optics or cable are marginal and the link state really does change. Damping and hold-time are configuration responses that suppress rapid transitions so routing protocols are not destabilised by a link that is bouncing for an unrelated reason. Damping will not fix a bad SFP - it only hides it from the routing layer while the counters keep rising. Once you have identified and repaired the physical fault, damping and hold-time are appropriate hardening, and our hold-time and damping configuration guide covers that second step.

Check the Physical Link and Media State

user@router> show interfaces ge-0/0/1 media
user@router> show interfaces ge-0/0/1 terse

show interfaces media is the first diagnostic: it reports Physical link is Up/Down, the Active alarms and Active defects fields, SFP type, speed and auto-negotiation state. A physical link down with a Link defect means the interface is not receiving a valid signal — go check the cable and the far end. The terse view confirms whether the interface is administratively disabled.

user@router> show interfaces ge-0/0/1 extensive | match "Physical link|Active alarms|Active defects|Link mode|Speed"
user@router> show configuration interfaces ge-0/0/1

Read the media output carefully for the specific defect. Loss of signal (LOS) means no light at all arrives; loss of light and loss of frame indicate a signal that is present but unusable. Those two cases point at different culprits - a broken fibre or an unseated connector in the first case, contamination or a failing laser in the second.

Inspect Statistics for the Real Story

user@router> show interfaces ge-0/0/1 extensive

The extensive output shows input/output errors, the Last flapped timestamp, link-level statistics and any alarm state. Look for input errors, L2 channel errors and CRC errors — they indicate signal integrity problems that will eventually produce flaps even if the link currently looks up. The field-by-field breakdown of that output is covered in our guide to Junos show interfaces extensive error fields.

Keep the session simple: run show interfaces extensive twice, a minute apart, and compare. A counter incrementing between two reads proves the fault is active; an error count that is large but static is history from an event that has already passed.

Also check the system log around each flap to correlate with other events:

user@router> show log messages | match ge-0/0/1
user@router> show log messages | last 100
user@router> show log chassisd | match ge-0/0/1

Correlating the timestamps of the flaps with events elsewhere in the log is often the decisive clue. Flaps that line up exactly with a building's air-conditioning cycle, a particular time of day, or a workstation being switched on point at temperature and power rather than at the transceiver itself.

Check Optical Power Levels

For any fibre interface, read the digital diagnostics from the transceiver before swapping anything. Most Junos platforms expose transmit and receive power directly:

user@router> show interfaces diagnostics optics ge-0/0/1
user@router> show interfaces diagnostics optics

Compare the reported receive power against the module's own specification, which the same command prints as high/low alarm and warning thresholds. A receive level that sits a few decibels above the alarm threshold is a link that will flap whenever temperature shifts or a connector is disturbed - the classic "works fine in the morning" fault. Transmit power that has drifted down compared with a known-good module of the same type is a dying laser. Compare the reading against the module baseline recorded at commissioning.

Loopback and Cable Diagnostics

Isolate the fault to one side with a loopback test. For fiber interfaces, physically loop TX to RX and check whether the link comes up:

user@router> show interfaces ge-0/0/1 media
! with TX-RX loopback physically installed

If the interface stays down with the loopback in place, the fault is on the local port or optics; if it comes up, the problem is the cable or the far end. For copper interfaces, Junos provides TDR-based cable diagnostics (supported on copper only, not fiber) that report open and short conditions with distance estimates — useful for finding a damaged patch cable:

user@router> show interfaces ge-0/0/1 cable-test

Always remove the loopback configuration after testing. Verify light levels are within receiver/transmitter specification when fiber is involved — a marginal SFP will flap long before it fails outright.

When Layer 1 Is Clean: Layer 2 and Upstream Causes

If the media state, the counters and the optics all look healthy and the interface still transitions, look further up the stack. These are the usual suspects:

• LACP and aggregated Ethernet. A member link that drops out of a bundle because of an LACP timeout or a mismatched configuration produces repeated up/down events. Check show lacp interfaces and show interfaces ae0 lacp.
• Spanning tree events. An interface that comes up and is immediately blocked by STP looks like flapping in some monitoring systems. show spanning-tree interface distinguishes topology changes from physical transitions.
• Speed and duplex negotiation. A hard-coded speed on one side and auto-negotiation on the other can cause intermittent link loss, especially with older copper PHYs.
• PoE faults. On access switches, a device drawing more power than the port can supply causes the port to power-cycle the attached device, which looks like a flap from the network side. show poe interface shows the current and class.
• Power and environment. A failing PSU or an over-temperature condition can reset a line card; show chassis environment and show chassis alarms settle the question quickly.
• Uptime correlation. Compare the flap timestamps with the device's own uptime and with unrelated interfaces. Flaps on several interfaces at the same instant point at the chassis, not at one cable.

Time-Boxing the Diagnosis

A flap investigation can sprawl. Keep it bounded with a fixed command sequence that answers the three questions in order: is the link physically stable, is the signal clean, and is the fault local or remote. Run all of these in one session before you touch any hardware, then save the output to a file so the evidence survives the repair:

user@router> show interfaces ge-0/0/1 terse
user@router> show interfaces ge-0/0/1 media
user@router> show interfaces ge-0/0/1 extensive | no-more
user@router> show interfaces diagnostics optics ge-0/0/1
user@router> show log messages | match ge-0/0/1
user@router> show chassis alarms
user@router> show chassis environment

Two readings taken a minute apart turn that output into a measurement rather than a snapshot. If the receive power is stable and well inside the module's thresholds, if the error counters are not incrementing, and if the log shows only clean link transitions, then the physical layer is not the fault and you should move to the Layer 2 list above rather than continuing to swap cables. If the opposite is true - power sitting near a threshold, CRC errors climbing, or a defect reported in the media output - stop after the optics swap and escalate with the collected evidence, because the next step is a hardware replacement rather than more configuration.

Write the sequence down as a runbook and keep it with the console cables. The value of a fixed procedure is not that it is clever; it is that a tired engineer at 2 a.m. can follow it without deciding what to check next, and that two different engineers reach the same conclusion from the same evidence.

Resolution Order

• Reseat the optics and cable on both ends; swap in a known-good cable.
• Match fiber types — single-mode cable to a single-mode interface, multimode to multimode.
• Replace the SFP with a known-good unit and re-test before suspecting the switch port.
• If the flap follows the SFP, the module is faulty; if it stays on the port, escalate with the extensive output collected.

Work through the list in that order and record which step changed the behaviour. A fault that follows the transceiver is a replacement, a fault that stays on the port is a hardware case, and a fault that disappears when the cable is swapped is an inventory item - three very different tickets with three very different costs.

Prevention: Monitoring and Hardening

• Alert on Last flapped changing rather than waiting for a link to go fully down. A single flap in a week is an early warning that the optics are drifting.
• Poll show interfaces diagnostics optics and alarm when receive power approaches the warning threshold, not the alarm threshold.
• Apply interface hold-time once the physical layer is clean, so a momentary transition does not trigger a routing reconvergence or a full BGP reset.
• Keep a known-good spare SFP and patch lead for each optic type you deploy - the fastest possible test is substitution.
• Record the link's original power levels when it is commissioned, so you have a baseline to compare against later.

For Junos gear beyond physical links, our SRX troubleshooting command cheat sheet and the Cisco vs Juniper command mapping cover the wider toolkit.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/interfaces-fundamentals/topics/topic-map/troubleshooting-interfaces.html