Interface statistics and error counters are the network engineer's window into the physical and data link layer health of a network. On the CCNA 200-301 exam, understanding how to interpret these counters is essential for troubleshooting connectivity issues, identifying duplex mismatches, and verifying cable integrity. This chapter covers the key counters, their meanings, and how to use them in real-world troubleshooting scenarios, aligning with the 'Troubleshoot interface and cable issues' objective.
Jump to a section
Think of a network interface as a car's engine, and the interface statistics as its dashboard gauges. The 'Input Errors' counter is like the 'Check Engine' light — it tells you something is wrong, but not what. The specific error types are like diagnostic trouble codes (DTCs). For example, 'CRC errors' are like a misfire detected by the oxygen sensor — the engine (interface) receives data (frames) but the data is corrupted. 'Runts' are like a car that stalls immediately after starting — the frame is too short (less than 64 bytes) to be valid, just as an engine needs a minimum RPM to run. 'Giants' are like an engine that overheats because the coolant is overfilled — the frame exceeds the maximum size (1518 bytes for Ethernet). 'Collisions' are like two drivers trying to merge into the same lane at the same time — on half-duplex links, this is normal; on full-duplex, it indicates a duplex mismatch (like a car with its turn signal stuck on). 'Frame errors' are like a bent frame on a car — the frame doesn't have a proper ending delimiter. By monitoring these counters, you can diagnose whether the problem is physical (bad cable, like a dead battery), configuration (duplex mismatch, like wrong tire pressure), or environmental (noise, like a bad road). Just as a mechanic uses a scan tool to read DTCs, a network engineer uses 'show interface' to read counters.
What Are Interface Statistics and Error Counters?
Interface statistics are counters maintained by a router or switch for each interface. They track packets and bytes sent and received, as well as various error conditions. The counters are stored in hardware (on the interface ASIC) and are updated in real time. They are reset when the interface is cleared with the clear counters command or when the device reloads. These counters are critical for troubleshooting because they provide a historical record of interface health since the last reset.
Key Counters and Their Meanings
Input Errors: Total number of errors that occurred while receiving frames. This includes runts, giants, CRC errors, frame errors, and overrun errors.
Output Errors: Total number of errors that occurred while transmitting frames. This includes collisions, late collisions, underruns, and output buffer failures.
CRC Errors: Cyclic Redundancy Check errors. The frame's CRC checksum does not match the calculated value, indicating corruption during transmission. Common causes: faulty cabling, bad SFP, electromagnetic interference (EMI), or a duplex mismatch.
Runts: Frames smaller than 64 bytes (minimum Ethernet frame size) that have a valid CRC. Often caused by collisions or a faulty NIC.
Giants: Frames larger than 1518 bytes (for standard Ethernet) that have a valid CRC. Can be caused by a faulty NIC or misconfigured MTU.
Frame Errors: Frames that do not end on a byte boundary (i.e., they have an invalid Frame Check Sequence or alignment error). Often caused by collisions or electrical noise.
Collisions: Count of collisions on half-duplex links. A small number is normal; a high number indicates a duplex mismatch or excessive network congestion.
Late Collisions: Collisions that occur after the first 64 bytes of a frame have been transmitted. This indicates a duplex mismatch or a cable that is too long.
Ignored: Frames that the interface ignored due to hardware buffer exhaustion. Often indicates a broadcast storm or high CPU load.
Overruns: The receiver hardware was unable to transfer data to the buffer because the input rate exceeded the interface's ability to process. Often due to a slow CPU or high-speed interface.
Underruns: The transmitter hardware was unable to keep up with the data flow, causing the frame to be truncated. Often due to a slow CPU or a bus bottleneck.
How to View Interface Statistics
The primary command to view interface statistics is show interfaces. Example output:
Router# show interfaces GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is ISR4331-2x1GE, address is 5006.ab01.2345 (bia 5006.ab01.2345)
Internet address is 192.168.1.1/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is RJ45
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 1000 bits/sec, 2 packets/sec
123456 packets input, 12345678 bytes
Received 123 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
123456 packets output, 12345678 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped outUnderstanding the Counters
Input errors: Sum of runts, giants, CRC, frame, overrun, and ignored.
Output errors: Sum of collisions, late collisions, underruns, and output buffer failures.
Interface resets: The interface was reset (e.g., due to a hardware failure or a shutdown/no shutdown). A high number may indicate an unstable link.
Babbles: The transmitter has been on the channel longer than the maximum frame time (a jabber condition).
Deferred: The interface had to wait because the medium was busy (half-duplex only).
Lost carrier / No carrier: The carrier signal was lost during transmission (often due to faulty cabling).
Dribble condition: A frame is slightly too long (by a few bits) but still has a valid CRC.
Interpreting Error Patterns
Runts without CRC errors: Likely caused by collisions on half-duplex links.
Runts with CRC errors: Likely caused by faulty cabling or a duplex mismatch.
Giants: Usually caused by a faulty NIC or a misconfigured MTU (e.g., jumbo frames enabled on one side only).
CRC errors only: Often indicates a bad cable or SFP. Check the cable length and quality.
Collisions: On modern full-duplex links, any collision indicates a duplex mismatch. On half-duplex, a collision rate above 5% is problematic.
Late collisions: Always indicate a duplex mismatch or a cable that exceeds the maximum segment length (100m for Ethernet).
Input errors increasing but output errors normal: Problem is on the local interface (receiving side). Check the cable, SFP, and the remote device's transmit.
Output errors increasing but input errors normal: Problem is on the local interface (transmit side) or the remote device's receive.
Clearing Counters
To reset all counters on an interface, use:
Router# clear counters GigabitEthernet0/0
Clear "show interface" counters on this interface [confirm]This is useful for starting a clean baseline during troubleshooting.
Interaction with Other Features
EtherChannel: Interface counters are per-member port. To see EtherChannel statistics, use show etherchannel port-channel.
Port Security: Violations are not shown in the error counters; use show port-security interface.
Storm Control: Suppressed broadcasts are not counted as errors.
CDP/LLDP: These protocols generate small frames that may appear as runts if the interface is misconfigured.
Identify the problematic interface
Use `show interfaces` or `show interfaces status` to list all interfaces and their operational status. Look for interfaces that are 'up/up' but have high error counters. For example, `show interfaces status` shows the port name, status, vlan, duplex, speed, and type. An interface with 'err-disabled' status indicates a severe issue like a loop or port security violation. Start with interfaces that are up but have non-zero error counters.
View detailed interface counters
Use `show interfaces [interface]` to see all counters. Focus on the input and output error sections. For example: ``` Router# show interfaces GigabitEthernet0/1 ``` Look for runts, giants, CRC, frame, overrun, ignored, collisions, late collisions, and interface resets. Note the values. If counters are high, proceed to the next step. If they are zero, the interface is healthy.
Check for duplex mismatch
Compare the duplex setting on both ends of the link using `show interfaces` (look for 'Full-duplex' or 'Half-duplex'). If one end is full and the other is half, that is a duplex mismatch. This causes late collisions, CRC errors, and frame errors. On Cisco switches, the default is auto-negotiation. If auto-negotiation fails, the switch may default to half-duplex. To verify, use: ``` Switch# show interfaces GigabitEthernet0/1 | include Duplex ``` If a mismatch is found, configure both ends to the same duplex (preferably full) and speed.
Examine CRC and frame errors
High CRC and frame errors indicate a physical layer issue. Check the cable, connectors, and SFP modules. Use `show interfaces [interface] transceiver` to check SFP diagnostics (if supported). Look for high temperature, voltage, or laser bias current. Swap the cable with a known good one. If errors stop, the cable is faulty. If they persist, check the SFP or the port itself. Also, ensure the cable length does not exceed 100 meters for copper Ethernet.
Investigate runts and giants
Runts (frames < 64 bytes) and giants (frames > 1518 bytes) often indicate a software or hardware issue. Runts with valid CRCs are usually caused by collisions on half-duplex. Giants are often due to a faulty NIC or jumbo frame misconfiguration. Check the MTU settings on both ends with `show interfaces [interface] | include MTU`. If jumbo frames are enabled on one side but not the other, giants will appear. Also, check for a faulty NIC by testing with a different device.
Analyze collisions and late collisions
On modern full-duplex links, any collision is a problem. Use `show interfaces [interface] | include collisions` to see the count. If collisions are increasing, check for a duplex mismatch. Late collisions are always bad; they occur after the first 64 bytes have been transmitted. This indicates a duplex mismatch or a cable that is too long. Resolve by setting the duplex manually to full on both ends. If the cable is long, check the specification (max 100m for copper).
Clear counters and monitor
After making changes (e.g., replacing cable, fixing duplex), clear the counters with: ``` Router# clear counters GigabitEthernet0/1 ``` Then monitor the interface for a period (e.g., 5 minutes) using `show interfaces [interface]` repeatedly. If errors stop increasing, the issue is resolved. If they continue, further investigation is needed.
Scenario 1: Duplex Mismatch in a Legacy Environment
A network engineer at a manufacturing plant replaced an old 10/100 hub with a new switch. After the upgrade, users reported slow performance and intermittent connectivity. The engineer checked the interface counters on the switch port connected to the hub (which was still in place for some legacy devices). The show interfaces output showed thousands of late collisions and CRC errors. The hub was half-duplex, but the switch port was set to full-duplex (auto-negotiation resulted in full). The engineer manually configured the switch port to half-duplex using duplex half and speed 100. After clearing counters, the errors stopped. The lesson: always verify duplex settings when mixing old and new equipment.
Scenario 2: Faulty Cable Causing CRC Errors
A data center technician noticed that a server was experiencing packet loss. The switch port showed a high number of input errors, specifically CRC errors. The engineer used show interfaces gig0/1 and saw CRC errors incrementing rapidly. He checked the cable and found it was a Cat5e cable running at 1 Gbps over a distance of 80 meters. Although within spec, the cable was old and had a kink. He replaced it with a Cat6 cable. The errors stopped. He also used the show interfaces transceiver command to check the SFP's optical power, which was normal. The key takeaway: CRC errors often point to physical layer issues; swapping the cable is a quick test.
Scenario 3: Broadcast Storm Causing Ignored Frames
A network administrator noticed that a switch port connected to a printer had high 'ignored' counters. The printer was flooding the network with broadcast frames due to a malfunction. The switch's input queue was dropping frames because the CPU could not keep up. The engineer used show interfaces gig0/2 and saw 'ignored' increasing. He also used show buffers to see buffer misses. He disconnected the printer, and the ignored counters stopped increasing. He then enabled storm control on the port with storm-control broadcast level 50 to prevent future issues. The lesson: ignored counters indicate the interface is overwhelmed; check for broadcast storms or high traffic.
What the 200-301 Exam Tests
The CCNA 200-301 exam includes questions on interpreting interface statistics and error counters. Specifically, you need to know:
The meaning of each counter (runts, giants, CRC, frame, collisions, late collisions, overruns, ignored).
How to use show interfaces to identify duplex mismatches, cable faults, and other issues.
The difference between half-duplex and full-duplex operation and how collisions indicate a mismatch.
The minimum and maximum Ethernet frame sizes (64 and 1518 bytes).
The default duplex and speed settings (auto-negotiation).
Common Wrong Answers and Why Candidates Choose Them
'Runts are always caused by a faulty NIC.' This is wrong because runts can also be caused by collisions on half-duplex. Candidates often forget that collisions produce fragments (runts).
'CRC errors indicate a duplex mismatch.' While duplex mismatch can cause CRC errors, the most common cause is a bad cable or SFP. Candidates jump to duplex mismatch because it's a common exam topic.
'Late collisions are normal on a busy network.' Late collisions are never normal. They always indicate a duplex mismatch or a cable length violation. Candidates might think all collisions are the same.
'Clearing counters fixes the problem.' Clearing counters only resets the count; it does not fix the underlying issue. Candidates may think it's a troubleshooting step that resolves errors.
Specific Values and Commands to Memorize
Ethernet frame size: 64 to 1518 bytes (without VLAN tag). With 802.1Q tag, max is 1522 bytes.
show interfaces command is the primary tool.
clear counters [interface] resets counters.
show interfaces transceiver for SFP diagnostics.
show interfaces status for a quick overview.
Default duplex: auto (auto-negotiation).
Decision Rule for Scenario Questions
If a question describes input errors increasing on an interface, the first step is to check the cable and duplex settings. If CRC errors are present, suspect a physical issue. If late collisions are present, suspect a duplex mismatch. If runts without CRC, suspect collisions on half-duplex. If giants, suspect MTU mismatch or faulty NIC. Use elimination to rule out options that don't match the error pattern.
Interface statistics are stored in hardware and reset with 'clear counters' or reload.
Input errors include runts, giants, CRC, frame, overrun, and ignored.
Output errors include collisions, late collisions, underruns, and output buffer failures.
CRC errors usually indicate a bad cable or SFP; late collisions indicate duplex mismatch.
Runts are frames < 64 bytes; giants are frames > 1518 bytes (standard Ethernet).
Collisions on a full-duplex link always indicate a duplex mismatch.
The command 'show interfaces' is the primary tool for viewing all counters.
These come up on the exam all the time. Here's how to tell them apart.
Half-Duplex
Uses CSMA/CD to detect collisions.
Collisions are normal and expected.
Maximum cable length is 100 meters.
Only one device can transmit at a time.
Late collisions indicate a cable length problem.
Full-Duplex
No collision detection; uses separate transmit and receive pairs.
Collisions are abnormal and indicate a duplex mismatch.
Maximum cable length is 100 meters (same).
Both devices can transmit simultaneously.
Late collisions always indicate a duplex mismatch.
Mistake
Runts are always caused by a faulty NIC.
Correct
Runts can be caused by collisions on half-duplex links, where fragments are created. A faulty NIC is only one possible cause.
Candidates often associate runts with hardware issues, but collisions are a common cause in half-duplex environments.
Mistake
CRC errors are always due to a duplex mismatch.
Correct
CRC errors are most often caused by faulty cabling, bad SFP, or electromagnetic interference. Duplex mismatch can cause CRC errors, but it is not the only cause.
Duplex mismatch is a popular exam topic, so candidates over-attribute CRC errors to it.
Mistake
Late collisions are normal on a busy network.
Correct
Late collisions are never normal; they indicate a duplex mismatch or a cable length exceeding 100 meters.
Candidates may confuse late collisions with normal collisions that occur on half-duplex.
Mistake
Clearing counters fixes the problem.
Correct
Clearing counters only resets the count; it does not resolve the underlying issue. It is used to establish a new baseline for monitoring.
Candidates may think clearing counters is a troubleshooting step that removes errors, but it only hides the evidence.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CRC errors occur when the frame's cyclic redundancy check (CRC) value does not match the computed value, indicating corruption. Frame errors (also called alignment errors) occur when the frame does not end on a byte boundary (i.e., it has a non-integer number of bytes). Both are input errors and often have similar causes (bad cable, noise). However, frame errors are more specific to alignment issues, while CRC errors are checksum failures.
Late collisions occur when a collision happens after the first 64 bytes of a frame have been transmitted. In Ethernet, the collision detection window is the first 64 bytes (the slot time). If a collision occurs after that, it is considered late. This is typically caused by a duplex mismatch (one side full, the other half) or a cable that exceeds the maximum segment length (100m for copper). Late collisions are always a problem and should be investigated.
The 'ignored' counter counts frames that were received but ignored by the interface because the input buffer was full. This can happen during a broadcast storm or when the interface is overwhelmed with traffic. It is not a physical layer error but an indication that the device cannot process incoming frames fast enough. To resolve, check for excessive broadcast traffic or increase the input queue size (rarely needed).
Use the command 'show interfaces [interface]' and look for the 'Full-duplex' or 'Half-duplex' text. For example: 'show interfaces GigabitEthernet0/1 | include Duplex'. Alternatively, 'show interfaces status' shows duplex for all ports in a table format.
The default duplex setting on Cisco switches is 'auto', meaning auto-negotiation. If the connected device also supports auto-negotiation, the highest common speed and duplex are selected. If auto-negotiation fails, the switch may default to half-duplex on 10/100 ports, but on Gigabit ports, full-duplex is required.
Yes, a faulty SFP (Small Form-factor Pluggable) module can cause CRC errors, as well as other input errors. The SFP may have a dirty or damaged connector, or its electronics may be failing. To diagnose, use 'show interfaces transceiver' to check optical power levels and temperature. Swapping the SFP with a known good one is a quick test.
First, check the interface counters for CRC errors, frame errors, or late collisions. If present, try swapping the cable with a known good cable. If errors stop, the cable is faulty. Also, ensure the cable length is within specification (100m for copper). For fiber, check the optical power levels using 'show interfaces transceiver'. A cable tester can also be used to detect opens, shorts, or impedance mismatches.
You've just covered Interface Statistics and Error Counters — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?