Juniper Ethernet Interface Troubleshooting Checklist

When a Juniper router or switch port stays down or drops packets, most engineers jump straight to swapping cables and transceivers. That approach wastes time: Junos gives you a precise, ordered set of diagnostic commands that isolate the fault in minutes. This guide condenses the official Juniper troubleshooting checklist for Ethernet physical interfaces on M, MX and T series platforms into a practical workflow with real CLI output.

The checklist is deliberately ordered from the physical layer upward. Each step either clears the fault or produces evidence that justifies the next step, so you never end up replacing a good transceiver because you skipped the loopback test that would have proven the PIC was at fault.

Why Use a Structured Juniper Interface Checklist

Physical-layer faults account for the majority of "port down" tickets, but the root cause can be anything from a dirty optical connector to an unsupported transceiver. Working through the checklist from the physical layer upward prevents duplicate work and gives you evidence — interface statistics, alarm states, loopback results — before you escalate to JTAC.

A second benefit is cost. Loopback tests and optical diagnostics take about five minutes and can tell you with confidence whether to open an RMA. Cable swaps, by contrast, are almost always a guess, and each one resets counters that you may have needed for the escalation.

Know What You Are Looking At: Naming, Slots and Ports

Junos interface names encode the physical location of the port, and the mapping is not always the one printed on the front panel. The format is type-fpc/pic/port: channelised and multi-rate interfaces add a fourth field (type-fpc/pic/port:channel), and on modular platforms the FPC slot and PIC slot on the chassis may not match the silkscreen.

user@router> show chassis hardware | match "FPC|PIC"
    FPC 0            REV 10   750-043231   ABC1234
      PIC 0          REV 06   750-050726   DEF5678     4x 10GE XFP
    FPC 5            REV 12   750-040901   GHI9012
      PIC 0          REV 04   750-048772   JKL3456     20x 1GE TX

Before you begin diagnosing "port ge-5/0/1", confirm that ge-5/0/1 is what you think it is, and confirm from show chassis hardware that the PIC is actually recognised. A PIC that fails to appear in the hardware inventory, or appears without a part number, points to a seating or backplane problem rather than a cable problem.

Step 1: Verify the Physical Link Status

Start with the show interfaces ge-5/0/1 media operational command to check whether the physical link is up and whether alarms or defects are active. A healthy port shows Physical link is Up with Active alarms: None and Active defects: None. If the link is down, confirm cabling on both ends and swap in a known-good cable before going further.

user@router> show interfaces ge-5/0/1 media
Physical interface: ge-5/0/1, Enabled, Physical link is Up
Interface index: 317, SNMP ifIndex: 1602
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps
Active alarms  : None
Active defects : None

The words alarms and defects have specific meanings here and are worth reading literally. An alarm is a condition detected at the local end that was signalled from the far end or from the link itself — LOCAL-FAULT, REMOTE-FAULT, LOS (loss of signal) and LOF (loss of frame) are the common ones. A defect is a condition detected locally, such as LINK-LOSS or an out-of-range optical level. A single-sided fault such as REMOTE-FAULT tells you the far end has a problem while your receive path is fine — a very different diagnosis from LOS.

Step 2: Inspect Detailed Interface Statistics

If the link is up but traffic suffers from errors or loss, run show interfaces ge-5/0/1 extensive. Pay attention to input errors, framing errors and the physical-layer counters. Rising FCS or framing errors point to bad optics or marginal cable quality rather than configuration issues.

user@router> show interfaces ge-5/0/1 extensive | match "errors|dropped|CRC|Frame|FIFO"
    Input errors:
      Errors: 14892, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0
      Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0
      L2 mismatch timeouts: 0, FIFO errors: 14892, Resource errors: 0
    Output errors:
      Carrier transitions: 3, Errors: 0, Drops: 0, MTU errors: 0

How to read the counters, in the order they matter:

Clear the counters with clear interfaces statistics ge-5/0/1, wait a minute under production load, and re-read. Only a counter that continues to increment after the reset represents a live fault; a large historical number tells you nothing on its own.

Step 3: Run Loopback Tests to Isolate the Fault

Loopback testing separates a faulty port/PIC from a faulty cable or remote peer. Configure the internal loopback under [edit interfaces ge-5/0/1 gigether-options] with the loopback statement; the link should come up cleanly with no alarms if the local hardware is healthy. For fiber interfaces you can also physically loop TX to RX on the port and re-check show interfaces ge-5/0/1 media.

user@router# set interfaces ge-5/0/1 gigether-options loopback
user@router# commit confirmed 5
user@router> show interfaces ge-5/0/1 media
Physical interface: ge-5/0/1, Enabled, Physical link is Up
Active alarms  : None
Active defects : None

Use commit confirmed for any loopback you enable on a live port: the configuration reverts automatically if you lose your session. Delete the statement with delete interfaces ge-5/0/1 gigether-options loopback and commit when you are done.

The interpretation is binary. If the link comes up clean with loopback and fails without it, the local PIC, port and optics are fine and the fault is in the cable or the far end. If the port cannot even come up in loopback, the local hardware or optics are suspect and you can move directly to the transceiver step without touching the cable again. Many routed platforms also support request diagnostics tdr interface ge-5/0/1 on copper ports, which reports cable length and open/short faults per pair — check platform support before relying on it.

Step 4: Check Administrative State and Auto-Negotiation

Use show interfaces ge-5/0/1 terse to confirm the interface is not administratively disabled, and verify that speed, duplex and auto-negotiation in the extensive output match the peer. Speed mismatches are a classic cause of intermittent links that no amount of cable swapping will fix.

user@router> show interfaces ge-5/0/1 terse
Interface               Admin Link Proto    Local                 Remote
ge-5/0/1                up    up
ge-5/0/1.0              up    up   inet     10.0.0.1/30

user@router> show interfaces ge-5/0/1 extensive | match "Speed|Duplex|Auto"
  Speed: 1000mbps, Loopback: Disabled, Source filtering: Disabled
  Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online

A link where one side shows Auto-negotiation: Enabled and the other is hard-set is the textbook setup for a duplex mismatch: the link comes up, passes light traffic, and then drops under load while runts and late collisions climb. Hard-set both ends or leave both on auto — never mix.

Step 5: Validate Transceiver Compatibility

Transceivers that are not on the Juniper Hardware Compatibility Tool are a frequent hidden cause of flapping ports. Reseat and clean the optics at both ends, swap in a known-working module, and check the hold-time and damping configuration if the port flaps instead of staying down — damping can mask a marginal link for hours. If every step passes and the port still fails, collect show interfaces output and contact JTAC for an RMA assessment.

Step 6: Read the Optical Diagnostics

For any optical port this step is decisive and takes seconds. Junos exposes the digital optical monitoring values the module itself reports:

user@router> show interfaces diagnostics optics ge-5/0/1
Physical interface: ge-5/0/1
    Module temperature                        :  42 degrees C / 107 degrees F
    Module voltage                            :  3.29 V
    Laser bias current                        :  6.204 mA
    Laser output power                        :  0.5930 mW / -2.27 dBm
    Receiver signal average optical power     :  0.0512 mW / -12.91 dBm
    Laser rx power                            :  0.0490 mW / -13.10 dBm
    Laser bias current high alarm threshold   :  11.500 mA
    Laser bias current low alarm threshold    :   4.000 mA
    RX power low alarm threshold              : -13.97 dBm
    RX power low warning threshold            : -11.98 dBm
    Laser bias current high alarm             : Off
    Module temperature high alarm             : Off
    RX power low alarm                        : On

Four things to check, in order:

• RX power against the alarm and warning thresholds. The receive level should sit comfortably above the low warning threshold. Sitting a fraction of a dB above the low alarm threshold means the link will drop out as soon as the connector gets dirty or the temperature moves.
• Bias current. A laser bias current that has drifted toward its high alarm threshold usually means the transmitter is at the end of its life — replace the optic rather than chase the link.
• Module temperature and voltage. Values outside the normal window point at a PIC airflow or power problem, not the fibre.
• Any alarm or warning flag set to On. Each one carries its own threshold; a RX power low alarm: On with an otherwise healthy link is a warning that you have no margin left.

Compare both ends. If the far end reports healthy TX power while the near end reports low RX power, the fibre path between them is the problem — a dirty connector, a kinked patch lead, or a bad patch panel port.

Step 7: Check Hardware Alarms and the System Log

user@router> show chassis alarms
user@router> show chassis fpc brief
user@router> show log messages | match "ge-5/0/1"
Mar 11 08:14:02  router snmpd[2148]: SNMP_TRAP_LINK_DOWN: ifIndex 1602
Mar 11 08:14:09  router snmpd[2148]: SNMP_TRAP_LINK_UP: ifIndex 1602

The log is the fastest way to establish how the port is failing. A port that logs LINK_DOWN followed by LINK_UP a few seconds later is flapping; a port that logs nothing but stays down was never up in the first place. Those two histories lead to completely different next steps — damping and hold-time for the flapper, physical-layer checks for the one that never came up. Use monitor interface for a live view of the counters while you make changes.

Step 8: Handle Flapping Deterministically

Once you know the port flaps, the question is what direction to fix it in. Hold-time is the cleaner tool for a physical problem you cannot fix immediately: it keeps the interface down (or up) until the link has been stable for a set period, which stops the ripple effect on routing protocols and MLAG heartbeats.

user@router# set interfaces ge-5/0/1 hold-time up 10000 down 3000
user@router# set interfaces ge-5/0/1 hold-time up 0 down 0   # remove it later

Damping is the alternative, and on Junos interfaces it suppresses the interface entirely until the penalty decays. It is a stopgap, not a fix: it will hide a link that is genuinely marginal. Use hold-time while you plan the optics replacement, and document that it is in place so the next engineer is not surprised by a port that stays down after a brief blip.

Quick Reference: Command to Purpose

Layer 2 and Layer 3 Checks After the Link Is Up

A physically healthy port can still be useless, so confirm the logical side before closing the ticket. On a trunk, verify the VLAN membership and that the interface is not blocked by spanning tree. On an IRB or VLAN interface, verify the SVI is up, that the VLAN exists in the bridging domain, and that ARP resolves the gateway. If hosts on the VLAN never answer, the problem has moved up a layer — our LAN where static hosts never answer walkthrough covers exactly that case, and troubleshooting an IRB or VLAN interface handles the interface-level checks.

Collecting Evidence for JTAC

If your loopback and optics results point at the hardware, gather everything in a single pass so the case moves on the first round trip:

user@router> show interfaces ge-5/0/1 extensive > /var/tmp/int.txt
user@router> show interfaces diagnostics optics ge-5/0/1 >> /var/tmp/int.txt
user@router> show chassis hardware detail >> /var/tmp/int.txt
user@router> show chassis alarms >> /var/tmp/int.txt
user@router> show version >> /var/tmp/int.txt
user@router> show log messages | last 200 >> /var/tmp/int.txt
user@router> file copy /var/tmp/int.txt user@host:/tmp/

Include the loopback test result and the value that made you suspect the optic. "Port down, cable swapped, no change" is a weak case; "port fails internal loopback with RX power alarm asserted and bias current at 78% of the high alarm threshold" is a strong one.

FAQ

Link is up but there is no traffic at all — is that physical? Usually not. If show interfaces media is clean and counters are static, move to the L2/L3 checks: VLAN membership, spanning tree state, IRB status, and ARP.

Can a bad optics module really produce only occasional errors? Yes, and it is common. Marginal RX power produces FCS errors under load that vanish when traffic is light, which is why the optical diagnostics step is worth running even when the counters look almost clean.

Should I enable flow control? Leave it at the platform default unless a peer device documents otherwise. Mismatched flow-control settings generate pauses that look like packet loss at the application layer.

How long should I wait after clearing counters? A minute under normal production load is enough to distinguish a live fault from historical noise. On a lightly used link, generate traffic rather than waiting.

Related reading: how to identify a flapped interface with Junos CLI and Junos interface flapping: a Layer 1 troubleshooting checklist. For the counter-by-counter meaning of the extensive output, see Junos show interfaces extensive error fields explained; for a broader command set, 10 essential Junos operational commands and the Cisco versus Juniper troubleshooting cheat sheet cover the same ground from the other direction. When you are ready to change interface configuration on a live port, wrap it in commit confirmed and rollback.

原文链接：https://supportportal.juniper.net/s/article/Troubleshooting-Checklist-Ethernet-Physical-Interfaces