show interfaces – Interface Statistics & Error Analysis

1. Purpose and Importance

show interfaces is one of the most important diagnostic commands in Cisco IOS. It displays real-time statistics, error counters, speed/duplex settings, and physical status for every interface on the device. When a network problem is reported — slow performance, packet loss, or complete loss of connectivity — this command is almost always the first tool an engineer runs to understand what is happening at the interface level.

  • Monitor interface health, utilisation, and traffic rates
  • Diagnose physical (Layer 1) and data-link (Layer 2) problems
  • Identify the root cause of packet loss, errors, or hardware faults
  • Verify speed, duplex, and MTU settings after a configuration change

Related pages: show ip interface brief | show ip route | show running-config | ping | traceroute | debug commands | show logging | Router | Switch | Layer 2 Troubleshooting Lab

2. Interface Status Lines – What They Mean

The first line of show interfaces output is the most important: it tells you the state of the hardware (Layer 1) and the line protocol (Layer 2). There are four possible combinations:

Status Line Layer 1 (Hardware) Layer 2 (Protocol) Most Likely Cause Action
up / up OK OK Interface is fully operational No action needed; check error counters to confirm health
up / down Physical signal present Not establishing Encapsulation mismatch (e.g., PPP vs. HDLC), keepalive failure, mismatched clock rate on serial link Verify encapsulation and keepalive settings on both ends
down / down No signal Cannot start No cable, wrong cable type, broken cable, remote device off, SFP failure Check physical connection, cable type, and remote device
administratively down / down Manually disabled Cannot start Interface was shut down with the shutdown command Enter no shutdown to enable the interface

See OSI Model for the full Layer 1/Layer 2 context, and show ip interface brief for a condensed status view of all interfaces at once.

3. Annotated Sample Output

Below is a full show interfaces GigabitEthernet0/1 output with every significant field annotated. This interface belongs to a router — the same output format applies to switch ports. 

Router# show interfaces GigabitEthernet0/1

GigabitEthernet0/1 is up, line protocol is up          ← L1 up, L2 up (healthy)
  Hardware is Gigabit Ethernet, address is 001a.2b3c.4d5e (bia 001a.2b3c.4d5e)
  Internet address is 192.168.10.1/24                  ← L3 IP address
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,   ← MTU, bandwidth, delay
     reliability 255/255, txload 1/255, rxload 1/255   ← 255/255 = perfect health; load 1/255 = ~0% used
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is RJ45            ← full-duplex, gigabit speed
  output flow-control is unsupported, input flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:01, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes)       ← 0 drops = no congestion
  Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 128000 bits/sec, 64 packets/sec  ← current traffic rate
  5 minute output rate 64000 bits/sec, 32 packets/sec
     123456789 packets input, 987654321 bytes, 0 no buffer
     0 runts, 0 giants, 0 throttles                    ← all 0 = no frame-size issues
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored  ← all 0 = no corruption
     234567890 packets output, 876543210 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets  ← all 0 = no duplex issues
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier

Interpretation: This interface is completely healthy — all error counters are zero, duplex is full, speed is 1 Gbps, reliability is 255/255, and neither queue is dropping packets. The hardware address (MAC address) is shown in the second line.

4. Error Counter Quick Reference

Counter Category What It Counts Probable Cause Resolution
Input errors Input Total count of all inbound errors (sum of runts, giants, CRC, frame, overrun, ignored) Faulty cables, EMI, hardware fault, duplex mismatch Inspect and replace cable; check for interference; verify duplex settings
CRC errors Input Frames that failed the Cyclic Redundancy Check — the received data does not match the checksum Damaged cable, EMI/interference, bad NIC, duplex mismatch Replace or re-seat cable; eliminate noise sources; set duplex manually
Frame errors Input Frames with an incorrect number of bits (not an exact multiple of 8) or invalid FCS Collisions, damaged cable, hardware fault Fix duplex mismatch; replace cable; check NIC and transceiver
Runts Input Frames smaller than the minimum Ethernet size of 64 bytes (including FCS) Collisions on the segment (the collision fragments a frame); faulty NIC Set both ends to full-duplex; replace NIC; check for shared media issues
Giants Input Frames larger than the maximum Ethernet size of 1518 bytes (without 802.1Q tag) MTU mismatch between devices; jumbo frames sent to a device that does not support them; faulty NIC Align MTU settings on all devices in the path; disable jumbo frames if unsupported
Overruns Input Packets received faster than the interface can pass them to the input queue — buffer overflow at hardware level Sudden traffic burst exceeding hardware processing capacity Investigate traffic patterns; implement QoS to prioritise critical traffic; consider hardware upgrade
Input queue drops Input Packets dropped because the software input queue is full High CPU load, bursty traffic, congestion; router cannot drain the queue fast enough Reduce traffic load; implement QoS; upgrade router CPU/memory
Output errors Output Total errors on transmitted frames (sum of underruns, collisions, deferred, etc.) Duplex mismatch, overloaded output queue, hardware fault Fix duplex settings; reduce congestion; check hardware
Collisions Output Two devices transmitted simultaneously on the same half-duplex segment — frames collided and were destroyed Half-duplex operation, duplex mismatch, shared media Set both ends of every link to full-duplex; should be zero on switched full-duplex links
Late collisions Output Collisions detected after the first 64 bytes of a frame have been sent (after the slot time) Duplex mismatch (most common); excessive cable length beyond Ethernet spec Correct duplex mismatch; shorten cable runs; replace defective NIC
Deferred Output Frames that waited because the medium was busy when the device tried to transmit High utilisation on a half-duplex segment; heavy traffic Upgrade to full-duplex; manage traffic load
Babble Output Excessively long frames transmitted by the interface — frame did not stop when expected Malfunctioning NIC or transceiver Replace the NIC, transceiver, or interface card
Output queue drops Output Packets dropped because the software output queue is full Interface congestion, link too slow for traffic volume, no QoS prioritisation Implement QoS; upgrade interface bandwidth; reduce offered load. Consider ACL-based traffic filtering to limit unwanted flows.
Reliability Health Running average of the interface’s error-free operation expressed as a fraction of 255. 255/255 = perfect; lower values indicate persistent errors. Ongoing CRC/frame errors; hardware failure; degraded cabling Address the underlying error source; replace hardware if necessary

5. Common Problems, Indicators, and Solutions

Symptom Key Output Field Probable Cause Resolution
Interface up / down Status line Encapsulation mismatch (serial links), keepalive failure, clock rate not set Match encapsulation on both ends; set clock rate on DCE serial; verify keepalives
Interface down / down Status line No cable, wrong cable type, broken cable, remote device powered off, dead SFP Check physical layer: cable, connectors, and remote device power and port
Interface administratively down Status line shutdown command was applied to the interface Apply no shutdown in interface configuration mode. Verify with show running-config.
High CRC and frame errors Input errors Damaged or faulty cable, EMI near the cable run, bad NIC or transceiver Replace cable; re-route away from noise sources; replace NIC or SFP
High collisions and late collisions Output errors Duplex mismatch (one side full, one side half); excessively long cable Explicitly set speed and duplex to match on both ends; check cable length. See Layer 2 Troubleshooting Lab.
Increasing runts Input errors Collisions fragmenting frames (half-duplex or duplex mismatch) Fix duplex; runts should drop to zero on a properly configured full-duplex link
Increasing giants Input errors MTU mismatch; jumbo frames hitting a device that does not support them Align MTU settings; disable jumbo frames if not universally supported in the path
High input / output queue drops Queues and drops Traffic congestion exceeding processing capacity; bursty traffic; no QoS Implement QoS; rate-limit offending flows with ACLs; upgrade interface or device
Low reliability (below 255/255) Reliability Persistent errors — hardware failure, degraded cable, or severe EMI Identify the error counter that is incrementing; replace hardware or cable

6. Understanding Duplex and Speed

The speed and duplex line in show interfaces output is one of the most actionable fields for troubleshooting performance issues: 

  Full-duplex, 1000Mb/s, auto-negotiation    ← healthy: both sides agreed on same settings
  Half-duplex, 100Mb/s, auto-negotiation     ← warning: connected to hub or auto-neg failed
Duplex Setting Behaviour When to Use
Full-duplex Both sides transmit and receive simultaneously; no collision detection; should show zero collisions All modern switched Ethernet links — standard for everything connected to a switch port
Half-duplex Only one side transmits at a time; uses CSMA/CD collision detection; collisions are expected and normal Legacy hubs; some wireless links; very old equipment. Rare in modern networks.

Duplex mismatch is the single most common cause of unexpected poor performance on a link that appears to be “up.” When one side is set to full-duplex and the other is half-duplex, the half-duplex side detects the full-duplex side’s continuous transmissions as collisions, causing late collisions, CRC errors, and significant throughput degradation. Always set speed and duplex explicitly on both sides rather than relying on auto-negotiation between mismatched devices. See Layer 2 Troubleshooting Lab for practical duplex mismatch diagnosis.

7. Related Commands

Command Use Case Key Output
show interfaces GigabitEthernet0/1 Full detail for a single interface All error counters, speed/duplex, traffic rates, reliability
show interfaces status Concise summary of all switch ports (switches only) Port name, connected/notconnect/disabled, VLAN, duplex, speed
show ip interface brief Quick L1/L2/L3 status of all interfaces Interface name, IP address, OK?, method, status, protocol
show interfaces counters errors Error statistics only across all interfaces (switches) CRC, input errors, runts, giants, collisions — all in one table
show interfaces trunk Trunk port status and allowed VLANs Trunking mode, encapsulation, VLANs allowed/active
show running-config Verify interface speed/duplex/shutdown configuration Current interface configuration including any explicit duplex/speed commands
clear counters GigabitEthernet0/1 Reset all error and traffic counters to zero Use after fixing a problem to confirm the issue does not recur
show logging Check for interface-related syslog messages Line protocol up/down events, error messages with timestamps
debug interface Real-time interface event monitoring (use with care) Layer 1/2 state changes, keepalive exchanges in real time

8. Step-by-Step Troubleshooting Procedure

  1. Check the status line — run show interfaces GigabitEthernet0/1 and note whether the interface is up/up, up/down, down/down, or administratively down. This immediately tells you whether the problem is physical, protocol, or configuration. Use show ip interface brief for a quick view of all interfaces simultaneously.
  2. Examine the error counters — look at input errors, CRC, runts, giants, collisions, and late collisions. Non-zero and increasing values indicate an active problem.
  3. Correlate errors to symptoms:
    • Slow throughput with good connectivity → check collisions and late collisions (duplex mismatch)
    • Random disconnects or packet loss → check CRC and frame errors (cabling/EMI)
    • No connectivity at all → check the status line (down/down or administratively down). Verify with show ip interface brief.
    • Intermittent drops under load → check input/output queue drops (congestion)
  4. Verify speed and duplex — confirm both sides are set identically. On Cisco IOS: 
    interface GigabitEthernet0/1
 duplex full
 speed 1000
    Check the current setting with show running-config.
  5. Test Layer 3 connectivity — use ping to verify IP reachability once the interface is up/up, and traceroute to trace the path hop-by-hop. Check show ip route to confirm routing is in place.
  6. Clear counters and monitor — use clear counters GigabitEthernet0/1 after making a fix, wait a few minutes, then re-run show interfaces to confirm that error counters are no longer incrementing.
  7. Escalate to hardware — if errors persist after replacing cables and correcting settings, suspect the NIC, transceiver (SFP), or switch port. Move the device to a different port and observe whether errors follow the port or the device.

9. Key Points & CCNA Exam Tips

  • show interfaces displays Layer 1/2 status, speed/duplex, traffic rates, and all error counters for every interface
  • The status line format is <interface> is <L1 status>, line protocol is <L2 status>; memorise all four combinations and their causes
  • CRC errors = data corruption; almost always caused by a bad cable, EMI, or duplex mismatch
  • Runts = frames under 64 bytes; almost always caused by collisions (duplex mismatch)
  • Giants = frames over 1518 bytes; caused by MTU mismatch or jumbo frames reaching a device that does not support them
  • Collisions and late collisions on a switched link = duplex mismatch; should be zero on full-duplex links
  • Late collisions specifically (after byte 64) = duplex mismatch or cable too long; regular collisions can occur in half-duplex; late collisions should never occur
  • Input / output queue drops = congestion; the interface is processing packets faster than they can be forwarded or the queues are full. Consider ACL-based traffic control to mitigate congestion.
  • Reliability 255/255 = perfect; lower values indicate ongoing errors; it is a decaying average
  • Use show interfaces status on switches for a compact view of all ports (VLAN, duplex, speed). For trunk port details use show interfaces trunk.
  • Always clear counters after making a fix, then re-check to confirm the problem is resolved
  • Fix duplex mismatches by explicitly setting duplex full and speed on both ends rather than relying on auto-negotiation. Check syslog events with show logging for timestamped interface flap messages.

Show Interfaces Quiz

1. What does the show interfaces command primarily display?

Correct answer is B. show interfaces displays the Layer 1/2 status line, speed and duplex, MTU, reliability, traffic rates (5-minute averages), and all error counters for each interface. It is the primary command for diagnosing physical and data-link layer problems on Cisco routers and switches. Use show ip interface brief for a concise one-line-per-interface summary.

2. What does "GigabitEthernet0/1 is up, line protocol is up" indicate?

Correct answer is C. The first status word (up/down) reflects the physical (Layer 1) state — whether the hardware detects a signal. The second (line protocol up/down) reflects the data-link (Layer 2) state — whether keepalives and framing are working. Both up means the interface is fully functional. See OSI Model for the full layer context.

3. Which error counter typically indicates data corruption caused by cabling or EMI?

Correct answer is A. CRC (Cyclic Redundancy Check) errors occur when the checksum calculated on the received frame does not match the one in the frame trailer, indicating that bits were corrupted in transit. Common causes are a damaged cable, high EMI near the cable run, a bad NIC, or a duplex mismatch. Use ping to verify whether the corruption causes actual packet loss.

4. What is the most common cause of high collisions and late collisions on a switched link?

Correct answer is D. On a modern switched network, collisions should be zero. A duplex mismatch (one side full, the other half) is the primary cause of collisions and late collisions. The half-duplex side detects the full-duplex side’s continuous transmission as a collision, causing a cascade of errors and severe throughput degradation. See Layer 2 Troubleshooting Lab.

5. What do runts and giants indicate on an interface?

Correct answer is B. Runts are Ethernet frames smaller than 64 bytes — typically caused by collision fragments from a duplex mismatch. Giants are frames larger than 1518 bytes (or 1522 with a 802.1Q VLAN tag), typically caused by an MTU mismatch or a device sending jumbo frames to a device that does not support them.

6. What does a reading of "0 input queue drops" signify?

Correct answer is A. Input queue drops occur when the router’s software input queue is full and it must discard incoming packets. Zero input queue drops means the router is processing incoming traffic faster than it arrives — no congestion at the input. A non-zero and rising count indicates CPU overload or bursty traffic exceeding processing capacity. ACLs or QoS policies can help limit unwanted traffic flows.

7. Which command gives a concise summary showing VLAN, speed, and duplex for all switch ports?

Correct answer is C. show interfaces status (available on Cisco switches) provides a compact table of all ports showing name, connected/notconnect/disabled state, VLAN, duplex (a-full, a-half, full), and speed. It is much faster to read than running show interfaces for each port individually. Use show ip interface brief for a similar summary on routers.

8. What does a reliability value of 255/255 indicate on an interface?

Correct answer is D. Reliability is expressed as a fraction of 255. A value of 255/255 means the interface has recorded zero errors during the measurement window — perfect health. As errors accumulate the number drops below 255. The value is an exponentially decaying average, so it recovers over time once errors stop.

9. What is the best first action when you see high input errors and CRC errors on an interface?

Correct answer is A. CRC errors are almost always a physical layer (Layer 1) problem. The first step is to replace the cable, re-seat connectors, or re-route the cable away from power lines, motors, or other sources of electromagnetic interference. If errors persist after replacing the cable, suspect the NIC or transceiver (SFP). Check show logging for any timestamped error messages that may help pinpoint when the issue began.

10. Which symptom on a switched full-duplex link is the clearest indicator of a duplex mismatch?

Correct answer is B. On a switched network, collisions should never occur on a full-duplex link. When one end is full-duplex and the other is half-duplex, the half-duplex side sees the other’s transmissions as collisions and generates late collisions. This causes degraded performance, runts, and CRC errors — even though the link shows as up/up. See Layer 2 Troubleshooting Lab for diagnosis steps.

← Back to Home