Reading show interfaces Counters: CRC, Runts, Giants, and Drops

An IOS counter block answers two different questions, and keeping them apart is the whole skill. Error counters (CRC, frame, runts, giants, overrun, ignored, late collisions) accuse the physical path or the receiving hardware: something arrived damaged or could not be taken in. Drop counters (total output drops, input queue drops) accuse capacity: the frames were perfectly good and there was nowhere to put them. An interface with rising output drops and every error counter at zero is congested, not broken, and replacing its cable will change nothing.

Line and port status

SW9# show interfaces status
Port      Name               Status       Vlan    Duplex  Speed Type
Gi1/0/3   Lab-PC-3           notconnect   30        auto   auto 10/100/1000BaseTX
Gi1/0/8   Conf-Room-AP       err-disabled 40        auto   auto 10/100/1000BaseTX
Gi1/0/21  Spare-Uplink       disabled     1         full   1000 1000BaseSX

Each status value implies a different action:

• connected. Link is up and the port is forwarding.
• notconnect. The port is administratively enabled but sees no link partner. Check the patch cord, the far-end device, and whether the far end is itself shut down. no shutdown accomplishes nothing here, because the port is not shut down.
• disabled. An administrator entered shutdown. The recovery is no shutdown on that interface, and there is no physical fault to chase.
• err-disabled. A protection feature such as port security, BPDU guard, or link-flap detection took the port down. Remove the condition that tripped it, then bounce the port with shutdown followed by no shutdown, or wait for errdisable recovery if a recovery timer is configured. The state does not mean the attached device has failed, and it does not always clear itself.

The router equivalent is the first line of show interfaces. “GigabitEthernet0/1 is up, line protocol is up” means Layer 1 and Layer 2 are both healthy. “up, line protocol is down” points at a Layer 2 problem such as a keepalive or encapsulation mismatch. “administratively down” is shutdown.

Input error counters

input errors is a total, not a category. It is the sum of runts, giants, no buffer, CRC, frame, overrun, and ignored. Reading the total alone tells you almost nothing; the value of the line is that the subtotals sit right next to it.

• CRC. The frame arrived intact in length but failed its frame check sequence. Cabling, connectors, a dirty or failing transceiver, electromagnetic interference, or a duplex mismatch. Matching the optic and the fiber grade to the run is covered in Cisco transceivers and cabling. CRC errors are the single strongest physical-layer accusation in the block.
• frame. A failed frame check sequence plus a non-integral number of octets, historically called an alignment error. Same suspects as CRC.
• runts. Frames shorter than the 64-byte minimum. On a half-duplex segment these are ordinary collision fragments. On a full-duplex link they suggest a duplex mismatch or a failing sender.
• giants. Frames longer than the interface’s maximum frame size. Usually a jumbo frame or MTU configuration that disagrees between the two ends, or a misbehaving NIC. The same disagreement stalls a routing adjacency, which is why an OSPF neighbor stuck in EXSTART is an MTU question.
• overrun. The receive hardware could not move arriving data into a buffer fast enough. This is a rate and resource problem inside the receiving device. Overruns say nothing about cable quality, and with CRC and frame both at zero the frames themselves were clean.
• ignored. The interface discarded frames because it had no free internal buffers, commonly during a broadcast storm or an extreme traffic burst.
• throttles. The interface briefly disabled itself because the receiving processor was overloaded.

Output counters

• Total output drops. The transmit queue was full when a packet arrived to be sent, so the packet was discarded. This is egress congestion: more offered traffic than the link speed or the queue depth can absorb. It is a capacity statement, not a fault.
• input queue drops. Reported inside the Input queue: 0/75/1842/0 (size/max/drops/flushes) field. The third number is drops. Packets arrived faster than they could be taken off the input queue.
• output errors. Frames the interface tried and failed to transmit.
• collisions. Normal in small numbers on half duplex, and expected to be zero on a full-duplex link.
• late collision. A collision detected after the first 64 bytes were already transmitted. On Ethernet this means a duplex mismatch or a cable run longer than the standard allows. Late collisions never indicate congestion, which is covered further in duplex mismatch symptoms.
• deferred. The interface waited for a quiet wire before transmitting, which only happens on half duplex.
• interface resets. The interface restarted. A large and growing count means the link keeps failing and recovering, and each restart is logged once. With every error counter at zero, the frames that do get through are clean, so suspicion falls on the transceiver, the fiber or copper run, or a far-end device that keeps restarting the port.

Counter interpretation

Counter rising	Points at	Rules out
CRC, frame	Cable, connector, transceiver, interference, duplex mismatch	Congestion; a full queue does not corrupt frames
Runts, giants	Duplex mismatch, MTU or jumbo mismatch, failing NIC	A pure capacity problem
Overrun	Receive hardware or buffering cannot keep up with the arrival rate	A physical fault, when CRC and frame are zero
Ignored, no buffer	Buffer exhaustion, often a broadcast storm	Corruption on the wire
Total output drops	Egress congestion on the transmit path	Cabling, duplex, and MTU, when all error counters are zero
Input queue drops	Ingress congestion toward the process path	Physical damage
Late collision	Duplex mismatch or an over-length segment	Congestion
Interface resets	Link flapping: transceiver, media, or far-end port restarting	Congestion and corruption, when error counters are zero

Load, reliability, and collection window

R7# show interfaces GigabitEthernet0/1
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 231/255, rxload 12/255

All three fractions are out of 255 and are averaged over the load interval, five minutes by default. reliability 255/255 is a perfect reading, the absence of errors, not the presence of them. txload 231/255 is roughly 90 percent of the interface’s bandwidth in the transmit direction, and rxload 12/255 is a lightly loaded receive direction. A transmit load near the top of the scale together with a large Total output drops value and zero error counters is the textbook profile of an interface that needs more bandwidth, not repair.

Counters are cumulative since the last reset. The Last clearing of "show interface" counters 2d10h line tells you the window they represent, and clear counters GigabitEthernet0/1 restarts it. Before diagnosing from a large absolute number, clear the counters and watch whether it grows, because a five-figure CRC count from three years of uptime may be meaningless while forty CRCs in ten minutes is an active fault.

On a Catalyst switch, show interfaces counters errors prints the same information as a table across all ports at once, with columns such as Align-Err, FCS-Err, Runts, Giants, and Late-Col, which is faster than reading one interface at a time.

How the 200-301 exam tests this

• Counter block to conclusion. A full block is printed and you pick the supported conclusion. Read which subtotals are nonzero and which are zero, because the zeros carry as much weight as the nonzeros: zero CRC and zero frame eliminate every cable answer.
• Congestion versus fault as a multi-select. You are asked which counters, rising while all others stay at zero, indicate congestion. Total output drops and input queue drops are the pair; CRC, runts, and late collisions belong to the physical group.
• Status value to action. A show interfaces status listing mixes notconnect, err-disabled, and disabled, and you choose the correct action for each. Only disabled is fixed with no shutdown, and err-disabled needs the cause removed followed by a port bounce.
• Misreading reliability. A distractor treats reliability 255/255 as a maximum error reading. It is the opposite, a perfect score.
• Interface resets. Short repeating outages plus a high reset count and clean error counters points at a flapping link, not at congestion and not at a duplex mismatch.

The zeros carry the diagnosis as often as the nonzeros, and that reading habit comes from working practice exam questions with full counter blocks in them.

Quick reference

• input errors is the sum of runts, giants, no buffer, CRC, frame, overrun, and ignored; read the subtotals.
• CRC and frame errors accuse the cable, connectors, transceiver, interference, or a duplex mismatch.
• Runts are undersized frames; giants exceed the maximum frame size and suggest an MTU or jumbo mismatch.
• Overruns are a receive-side hardware and buffering limit, not a cabling defect.
• Total output drops with all error counters at zero means egress congestion.
• Input queue drops appear as the third value in Input queue: size/max/drops/flushes.
• Late collisions mean duplex mismatch or an over-length segment, never congestion.
• Rising interface resets with clean counters mean the link is flapping.
• reliability 255/255 is perfect; txload and rxload are fractions of 255 over the load interval.
• show interfaces status: disabled needs no shutdown, notconnect needs a cable or far-end check, err-disabled needs the cause cleared and a shutdown then no shutdown.
• Use clear counters and re-observe before diagnosing from a cumulative total.