Junos show interfaces extensive: Error Fields Explained

Every Junos engineer has stared at the error block of show interfaces extensive and wondered which counters actually matter. The output lists input errors such as Errors, Drops, Policed discards and L3 incompletes, plus output errors like Carrier transitions and HS link CRC errors - and misreading them leads to replacing perfectly good cables or chasing ghosts in the config. This article explains what each counter in the show interfaces extensive error block means, so you can classify a fault as Layer-1, queueing, or control-plane related in seconds.

What show interfaces extensive Actually Prints

The command prints five distinct blocks for each physical interface, and knowing which block a counter belongs to is half the diagnosis:

• Physical interface — flags, link mode, speed, admin status, and the high-level state such as Enabled, Physical link is Up.
• Traffic statistics — packets and bytes, split by unicast, multicast and broadcast, in both directions.
• Input errors and Output errors — the counter blocks this article focuses on.
• MAC statistics — received/transmitted MAC pause frames and routing fabric counters, where you confirm whether link-level pause is engaging.
• Logical interface — per-unit protocol information, addresses, and the Queue counters table with queued, transmitted and dropped packets per CoS queue.

The practical point: an "interface problem" is only a cable problem about half the time. The other half of the time the answer is in the traffic statistics block (is there even traffic?), the MAC block (is flow control engaging?), or the queue counters (which queue is shedding traffic?). Read the whole output before touching fibre.

The Input Error Block

A typical input error section looks like this:

Input errors:
  Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0,
  L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0,
  FIFO errors: 0, Resource errors: 0

• Errors: the sum of incoming frame aborts and FCS/CRC errors. On Ethernet, corruption arrives as CRC, alignment or PCS/FEC errors; frame aborts are typical of serial/T1/E1/HDLC links. A climbing value is a Layer-1 issue - bad fiber, bad optic or a faulty PIC/PIM.
• Drops: packets dropped by the input queue of the I/O Manager ASIC, normally because the interface is saturated and the RED mechanism is discarding.
• Framing errors: frames with invalid framing or alignment on the wire.
• Runts: frames shorter than the minimum Ethernet frame size.
• Policed discards: frames discarded by the incoming packet match code because the protocol was not recognized or not of interest - often normal, for protocols the router does not handle.
• L3 incompletes: packets dropped because they failed Layer-3 sanity checks, for example an IP header shorter than 20 bytes.
• L2 channel errors: the software found no valid logical interface for an incoming frame.
• FIFO errors / Resource errors: internal buffering or resource problems; Resource errors on 1G interfaces are a known discussion point in the Juniper community and usually trace back to shared-buffer pressure or specific PIC behavior.

Two of these deserve a second look because they are frequently misread. Runts that climb steadily alongside Errors almost always mean a duplex mismatch or a failing transmitter rather than a length problem — a 10/100 link where one side is forced full-duplex and the other auto-negotiates to half will generate runts, collisions and CRC errors simultaneously. L2 channel errors and L2 mismatch timeouts are Layer-2 plumbing faults, not cabling: the frame arrived intact but the software had no matching logical interface, which on Ethernet points at an encapsulation mismatch, a badly bonded interface, or a VLAN/unit that is not configured.

FIFO errors mean the hardware could not keep up with the internal handoff — a sign of a saturated device or a failing ASIC rather than a cable. Resource errors indicate the packet was dropped for lack of an internal resource such as a buffer or a next-hop descriptor; on some 1G platforms they are expected under bursts, on 10G and above they are not.

The Output Error Block

Output errors:
  Carrier transitions: 1, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0,
  FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0

• Carrier transitions: the number of times the interface went down and back up. This counter should increase slowly; if it climbs every few seconds, the cable, far-end system or PIC/PIM is malfunctioning.
• Errors: sum of outgoing frame aborts and FCS errors.
• Drops: packets dropped by the output queue of the I/O Manager ASIC under saturation.
• Aged packets: packets purged after sitting in shared packet SDRAM too long. This value should never increment - if it does, suspect a software bug or failing hardware.
• HS link CRC errors: errors on the high-speed links between the ASICs that handle the router interfaces. Growth here points inside the chassis rather than at the cable.
• MTU errors: packets dropped because they exceeded the interface MTU.

Interpretation notes that save time in the field. Collisions are normal on a half-duplex segment and abnormal on a full-duplex one — a growing collision count on a link you believe is full-duplex is a duplex mismatch, full stop. Carrier transitions is the single most useful counter in the block because it is the only one that measures state changes rather than packet-level damage; a value that increments while everything else stays flat means the physical layer is bouncing, which is a completely different investigation from CRC corruption. Aged packets is the canary: it should be zero for the life of a device, and any non-zero value justifies a case with JTAC. And HS link CRC errors growth means you stop looking at the cable entirely and start looking at the chassis — the corruption is happening between the ASICs that front the port.

Traffic Statistics: The Context You Need

Error counters are meaningless without the packet counts next to them. One input error in ten million packets is a measurement; one input error in a hundred is a link that is effectively dead. Always read the two together:

Traffic statistics:
  Input  bytes  :          9302837240                   470.8 Mb/s
  Output bytes  :           318712310                   82.1 Mb/s
  Input  packets:             14028461                    1.5 Kpps
  Output packets:              2212938                  174 pps
  Unicast packets:             14017932                    1.5 Kpps
  Multicast packets:               8838                    0 pps
  Broadcast packets:               1691                    0 pps

This is also where you spot the interfaces that are receiving far more broadcast and multicast than they should — a broadcast storm shows up as a ballooning broadcast packet count, which then explains the input Drops you were about to blame on the cable. And it is where you measure utilisation: comparing the byte rate against the link speed tells you immediately whether the interface is congested, which is the only legitimate reason for input or output Drops to climb.

Triaging by Counter: A Quick Reference

The Queue Counters That Explain Output Drops

Output errors tell you that packets were dropped; the queue counters below the logical interface tell you why. Each logical interface carries a per-queue table, and the dropped column is the one that matters:

Queue counters:       Queued packets  Transmitted packets      Dropped packets
0 best-effort                    0                    0                    0
1 expedited-forwarding           0                    0                    0
3 network-control                0                    0                    0

A drop count that is concentrated in one queue is a CoS design problem: either the scheduler is giving that class too little bandwidth, or traffic is being classified into a best-effort queue that the design intended to be protected. A drop count spread across all queues is genuine oversubscription. Either way, the conclusion is configuration, and no amount of cable swapping will change it. This distinction — output drops without Layer-1 errors — is the fastest way to close a ticket that has been wrongly escalated to the field team.

How to Use the Counters in Practice

1. Run monitor interface <interface> or repeat show interfaces <interface> extensive a few seconds apart and note which counters are increasing.
2. If Errors and Framing/CRC-type counters climb while drops stay flat, treat it as Layer-1: check optics, fiber and the far end first.
3. If only Drops climb, the interface is congested - check utilization and the CoS configuration rather than the cable.
4. If Carrier transitions increments repeatedly, look for flapping causes (power, SFP seating, far-end reboots) before anything else.
5. Clear the counters with clear interfaces statistics <interface> to get a clean measurement window.

Two habits turn a single command into a real measurement. First, always baseline: clear the counters, note the timestamp, and take two readings at least a minute apart — a counter that is non-zero from the days of the last chassis install tells you nothing about the incident you are debugging. Second, never clear counters on an interface you did not first photograph; the counters are the only record that a fault existed before the field engineer reseated the optic. And remember that clear interfaces statistics resets error counters as well as traffic statistics, so copy the output into the ticket first.

False Positives: Counters That Are Supposed to Move

Not every non-zero counter is a fault, and knowing the benign ones prevents unnecessary outages:

• Policed discards on an interface carrying non-IP traffic (LLDP neighbours you do not run, IS-IS hellos on a router that only speaks OSPF) are the design working as intended.
• L2 mismatch timeouts can appear in small numbers on links where the peer sends a frame type the local encapsulation does not expect.
• Collisions are expected on any genuine half-duplex segment and are not a fault by themselves.
• Resource errors on older 1G PICs under heavy burst are documented behaviour rather than a defect.
• MAC pause frames increasing means flow control is engaging — expected if you deliberately run flow control, alarming if you do not.

The rule that keeps this list useful: a counter matters when its rate of change is abnormal for that interface's role, not when it is merely non-zero. Ten carrier transitions over five years is a healthy core link; ten carrier transitions in the last hour is an outage waiting to happen.

Related Link-Level Checks

When input errors point at Layer 1, pair this analysis with show interfaces diagnostics optics to inspect optical power, and check whether the physical interface itself is flapping - see the interface flapping troubleshooting guide for the full workflow.

Related reading: Junos layer-1 interface flapping troubleshooting and Optical transceiver power: dBm, RX/TX thresholds. If the counters show carrier transitions rather than corruption, the suppression side of the problem is covered in Junos interface flapping: hold-time and damping configuration, and the command sequence for tracking a flapped interface down is in identifying a flapped interface with Junos EX CLI commands.

Original article: Juniper KB24601: Input and output errors in 'show interface extensive'