Junos EX: How to Identify a Flapped Interface with CLI Commands

2026年8月27日 LOG admin

Interface flapping on a Juniper EX switch is a classic source of intermittent packet drops and traffic disruption that can take hours to pinpoint. Junos keeps the evidence you need right in the CLI — you just have to know which commands to run and which fields to read. This guide walks through the exact Junos commands to confirm that an interface has flapped, find when it happened, and cross-check the event against switch logs and system uptime. By the end you will have a repeatable three-step routine for every flap investigation, plus the follow-up commands that separate a bad cable from a bad optic, an administrative shutdown, or a remote-end restart.

Why Interface Flaps Are Hard to Chase

An interface that goes down and comes back quickly often leaves no lasting alert, only a timestamp buried in the output of show interfaces and a few lines in the message log. On an EX series switch the flap may be caused by a bad cable, a failing transceiver, or even an administrative disable — and each cause leaves a different fingerprint in the logs. The fastest path is to collect the flap timestamp first, then correlate it with log entries and the switch's own clock.

Two things make the search harder than it should be. First, EX switches running ELS (Enhanced Layer 2 Software) report a lot of state under show interfaces but do not raise an alarm for a link that has already recovered — by the time you log in, the interface is up and everything looks normal. Second, a flap is often reported by users as "the network was slow for a minute", which points at an application long before it points at a link. Treating the flap timestamp as the anchor for the whole investigation turns an open-ended hunt into three lookups.

Step 1 — Confirm the Flap with show interfaces

Run show interfaces <interface-name> on the EX switch and look for the Last flapped field. To scan every interface at once, filter for the relevant lines:

lab@Switch> show interfaces | match "Physical|flapped"
Physical interface: ae13 (MC-AE-14, active), Enabled, Physical link is Down
  Last flapped   : 2022-01-19 15:34:34 IST (4d 23:13 ago)
Physical interface: ae14 (MC-AE-15, active), Enabled, Physical link is Down
  Last flapped   : 2022-01-19 15:34:34 IST (4d 23:13 ago)

The Last flapped field tells you which physical interface changed state and how long ago — the single most useful pointer when users complain of drops but the link looks fine now. Two refinements make the scan more precise. Add extensive when you also need error counters and the current logical state, and use a narrower match when only a single member of a bundle is suspect:

lab@Switch> show interfaces ge-0/0/0 extensive
lab@Switch> show interfaces ge-0/0/0 | match "flapped|errors|Speed|Duplex"
lab@Switch> show interfaces ae13 extensive | match "flapped|LACP|members"

If the flap affects an aggregated interface, remember that ae bundles inherit their state from their member links: a bundle recorded as flapped at 15:34 means at least one member went down then, so check each ge- or xe- member listed under the bundle for its own Last flapped value. The member with the matching timestamp is the physical link to investigate.

Step 2 — Correlate with the Message Log

Next, check what the switch logged around that timestamp. The mib2d process records link state changes as SNMP traps:

root@Switch> show log messages | match ge-0/0/0
Dec 27 08:26:30 r001 mib2d[38304]: SNMP_TRAP_LINK_DOWN: ifIndex 512,
ifAdminStatus up(1), ifOperStatus down(2), ifName ge-0/0/0

If the flap was caused by an administrative shutdown, the log shows ifAdminStatus down(2) — a different signature that points to configuration rather than hardware. Distinguishing the two up front saves you from replacing optics that were never at fault.

Three more log queries turn a single timestamp into a full picture of the event. Search for the paired up-trap to measure how long the outage lasted, look at the surrounding lines rather than just the matched ones, and shorten the window so you are reading a minute of log instead of a day:

root@Switch> show log messages | match "SNMP_TRAP_LINK"
root@Switch> show log messages | match ge-0/0/0 | last 20
root@Switch> show log messages | last 200 | find "ge-0/0/0"
root@Switch> show log messages.0.gz | match "ge-0/0/0"

If the flap happened before the current messages file started, the rotated copies messages.0.gz through messages.9.gz still hold it — show log messages.0.gz | match works directly on the compressed file. For a device that logs to a syslog server, searching the server is usually faster and gives you longer retention than the on-box buffer. Also worth a look: show system alarms and show chassis alarms for power, fan or temperature events that could have reset a line card port at the same moment.

Step 3 — Cross-Check with Switch Uptime

Finally, verify the switch clock so the log timestamp and the flap time line up:

root@Switch> show system uptime
Current time: 2021-12-27 09:03:01 PST
System booted: 2021-10-15 16:21:09 PDT
Last configured: 2021-12-27 08:31:36 PST

If the interface flapped moments after Last configured, suspect a recent configuration change; if it flapped during a known maintenance window, hardware or cabling work is the likely trigger. When the interface will not come back up at all, escalate to the physical-interface resolution workflow referenced in Juniper KB19797.

The clock itself is worth verifying, because a drifted switch clock makes every cross-reference wrong. Compare the current time against your own, then check that NTP is actually synchronised rather than merely configured:

root@Switch> show ntp associations
root@Switch> show ntp status
root@Switch> show system uptime | match "booted|configured"

Two more uptime details matter. If System booted is only minutes or hours ago, the whole switch restarted and your flap is really a reload symptom — check show system boot-messages | last 40 for the reason. And if Last configured is inside the flap window, treat it as a strong hint that somebody committed a change to the interface, its VLAN membership, or its speed/duplex settings at the same time.

Step 4 — Narrow the Cause

With the timestamp in hand, confirm or eliminate the usual suspects in one pass. Optics statistics are the highest-value command here, because a failing transceiver usually shows low or fluctuating receive power before it fails outright:

lab@Switch> show interfaces diagnostics optics ge-0/0/0
lab@Switch> show interfaces ge-0/0/0 media
lab@Switch> show interfaces ge-0/0/0 statistics | last 20
lab@Switch> monitor interface ge-0/0/0

Read the receive power against the specified range for the optic type: a 10GBASE-SR at 850 nm wants roughly -9.5 to 0 dBm at the receiver, and a value drifting toward the low end after each flap means the fibre or the connector is degrading. Rising CRC or frame-check errors alongside the flaps point at the physical layer; a clean error count with an ifAdminStatus down signature points at configuration. monitor interface gives a live view of input and output rates and error counters, which is the quickest way to catch a late-collision or runts pattern while the problem is happening rather than afterwards.

Finally, decide whether the link should be damped. Damping suppresses flapping interfaces by delaying their return to service, which protects routing protocols from repeated recalculation while you replace a cable:

set interfaces ge-0/0/0 dampening
set interfaces ge-0/0/0 dampening suppress 1200
set interfaces ge-0/0/0 dampening half-life 30
show interfaces ge-0/0/0 | match damping

Damping is a mitigation, not a fix: it hides the symptom from the routing protocols and buys you time. Pair it with a hardware swap or a replacement patch lead and remove it once the link is stable.

Quick Reference: Which Command Answers Which Question

Question	Command
Did this interface flap, and when?	`show interfaces <int> \| match flapped`
Which interfaces flapped at all?	`show interfaces \| match "Physical\|flapped"`
Was the transition administrative?	`show log messages \| match <int>`
How long was the outage?	match the paired `SNMP_TRAP_LINK_UP` entry
Is the switch clock trustworthy?	`show ntp associations`
Did the whole switch reload?	`show system uptime`
Is the optic degrading?	`show interfaces diagnostics optics <int>`
Is the link erroring right now?	`monitor interface <int>`

Escalating with the Right Evidence

Most flap tickets are closed in-house, but the ones that reach JTAC move faster when the evidence is already collected. Capture the interface's own view of the event first, then the bundle and the logs around the timestamp:

lab@Switch> show interfaces ge-0/0/0 extensive
lab@Switch> show interfaces diagnostics optics ge-0/0/0
lab@Switch> show log messages | match ge-0/0/0
lab@Switch> show configuration interfaces ge-0/0/0
lab@Switch> show chassis hardware | match "ge-0/0/0|PIC"

Include the switch model, the Junos version and the exact outage window in the ticket. A flap caused by a hardware fault is usually provable from the optics statistics alone: if one direction loses 6 dB of receive power at the same instant the link drops, no amount of configuration review will help, and the evidence points straight at the fibre or the module. A flap that appears only under load, or only at a particular time of day, is more often a negotiation or a power-supply event, and the log-correlation step is what proves it.

Automating the Routine

Once the three-step routine is familiar, push the evidence off the box so you are not racing the log buffer. Send link-state syslog to a server with set system syslog host 10.0.0.50 any info plus set system syslog host 10.0.0.50 facility-override local0, and raise SNMP traps for link up/down so monitoring catches flaps that users never report. If you want the switch itself to react, an event policy can run an operation script whenever the mib2d trap fires:

set event-options policy FLAP-TRACK events snmp_trap_link_down
set event-options policy FLAP-TRACK then execute-commands commands "show interfaces | match flapped"

Between syslog retention on a server and a targeted match on Last flapped, you will normally identify the offending link before the users finish describing the problem.