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

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.

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.

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.

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.

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.

Related Reading

For more Junos troubleshooting techniques, see our guides on Junos BGP 建立排障 and Junos 接口 Damping 机制. If you are also chasing MAC instability on switching platforms, the Catalyst-side workflow in 思科交换机排障命令手册 is a useful cross-vendor comparison.

原文链接：https://supportportal.juniper.net/s/article/EX-How-to-identify-an-interface-that-has-flapped