Read a 'show interfaces' Output Like a Pro

The show interfaces command is fundamental for network engineers and system administrators troubleshooting connectivity issues or monitoring network…

The show interfaces command is fundamental for network engineers and system administrators troubleshooting connectivity issues or monitoring network health on Cisco IOS and NX-OS devices. Properly interpreting its extensive output provides immediate insight into physical layer problems, data link layer configurations, and network-layer statistics. This article breaks down key sections of the show interfaces output, offering practical guidance for diagnosis.

We'll primarily focus on outputs from Cisco IOS devices, specifically versions 15.x and newer, though most concepts apply broadly to NX-OS as well. Ethernet interfaces (GigabitEthernet, TenGigabitEthernet) will be used for examples, as they are the most common interface types.

Understanding the Interface Header

Each interface output begins with a header providing its administrative and operational status. This is the first place to look for immediate problems.


GigabitEthernet1/0/1 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is 001a.6b3d.ef01 (bia 001a.6b3d.ef01)
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, Loopback not set
  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output 00:00:00, output hang never
  Last clearing of "show interface" counters 01:23:45
  Queueing strategy: fifo
  Output queue: 0/40, 0 drops; input queue: 0/75, 0 drops
  • GigabitEthernet1/0/1 is up, line protocol is up (connected): This is critical. "is up" refers to the physical layer (Layer 1), meaning the interface is physically connected and detecting a carrier signal. "line protocol is up" refers to the data link layer (Layer 2), indicating successful negotiation and keepalives. If either is "down", troubleshoot Layer 1 (cabling, port status on remote device) or Layer 2 (encapsulation, duplex mismatch). "(connected)" specifically means a routing protocol or static route considers this interface active.
  • Hardware is Gigabit Ethernet, address is 001a.6b3d.ef01: Confirms the interface type and its MAC address.
  • MTU 1500 bytes: The Maximum Transmission Unit for IP packets. Default for Ethernet is 1500 bytes. Mismatched MTUs across a path can lead to fragmentation or dropped packets (PMTUD issues).
  • BW 1000000 Kbit/sec, DLY 10 usec: Configured bandwidth and delay values, used by routing protocols like EIGRP to calculate metrics. These are often default values and might not reflect actual throughput.
  • Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX: The negotiated speed and duplex settings. Mismatches here are a common source of performance problems (collisions, input errors). Always verify these match on both ends of a link.
  • Last clearing of "show interface" counters 01:23:45: Crucial for troubleshooting. Errors are cumulative. To diagnose current issues, clear the counters with clear counters GigabitEthernet1/0/1 (or clear counters for all interfaces) and then monitor for a period.

Input Packet Statistics and Errors

This section details inbound traffic and any issues encountered during reception. These are some of the most important counters for diagnosing link problems.


  5 minute input rate 1000 bits/sec, 1 packets/sec
     1234567 packets input, 123456789 bytes, 0 no buffer
     Received 1234567 broadcasts, 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
  • packets input, bytes: Total received frames and bytes. A healthy interface will show these incrementing.
  • no buffer: Indicates the router or switch temporarily ran out of buffer space to store incoming packets. This can point to an overloaded device or a bursty traffic pattern exceeding input buffer capabilities.
  • runts: Ethernet frames smaller than the minimum allowed size (64 bytes, including CRC) but otherwise well-formed. Often caused by collisions or faulty NICs/cabling.
  • giants: Ethernet frames larger than the maximum allowed size (1518 bytes for standard Ethernet, or more if jumbo frames are configured) but otherwise well-formed. Can indicate misconfigured MTUs or faulty hardware.
  • input errors: A cumulative count of all errors preventing the input datagram from being passed to higher-layer protocols. This includes runts, giants, CRC, frame, overrun, and ignored counts. Any non-zero and incrementing value here needs investigation.
  • CRC: Cyclic Redundancy Check errors. The most common indicator of physical layer problems: bad cabling, faulty transceivers, electrical interference, or a port on the remote device transmitting bad frames. A high number here usually points to a Layer 1 issue.
  • frame: Indicates frames with an invalid checksum (CRC error) and a non-integer number of bytes (a framing error). Often due to duplex mismatch, faulty cabling, or a bad NIC.
  • overrun: The receive buffer on the interface has been exceeded. This can happen when the system is unable to handle the input rate, often due to high CPU utilization or a burst of traffic.
  • ignored: Frames ignored by the interface because the interface hardware ran out of internal buffers. Can indicate a sustained high rate of small packets, high CPU, or issues with the internal bus.

Diagnosing Input Errors

As per the stub, input errors, especially CRC and frame errors, strongly suggest a bad cable, faulty transceiver, or a duplex mismatch. Compare the negotiated speed and duplex settings on both sides of the link using show interfaces <interface_id> status or show interfaces <interface_id> capabilities. If the duplex settings don't match (one side full, one side half), this is almost certainly the cause. For example, if one side is forced to full-duplex and the other auto-negotiates to half-duplex, you'll see a lot of collisions and input errors.

Output Packet Statistics and Errors

This section focuses on traffic leaving the interface and any issues encountered during transmission.


  5 minute output rate 1000 bits/sec, 1 packets/sec
     1234567 packets output, 123456789 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
  • packets output, bytes: Total transmitted frames and bytes.
  • underruns: The transmit buffer was empty when the interface was ready to send data. This is typically due to the CPU not being able to feed data to the interface fast enough, or a misconfigured burst setting.
  • output errors: A cumulative count of errors that prevented the output datagram from being transmitted. This includes collisions, late collisions, and interface resets.
  • collisions: Number of times a frame transmission had to be reattempted due to an Ethernet collision. In half-duplex environments, some collisions are normal. In full-duplex, this should ideally be zero. High collision counts in full-duplex indicate a serious problem, usually a duplex mismatch.
  • late collision: A collision that occurs after the first 64 bytes of the frame have been transmitted. Always a strong indicator of a duplex mismatch (one side full-duplex, other half-duplex) or a cable segment that is too long.
  • deferred: The number of times the interface had to wait before transmitting a frame because the medium was busy. Common in half-duplex environments.
  • output buffer failures: The device attempted to allocate a buffer for an outgoing packet but failed. This implies memory exhaustion or misconfiguration.

Diagnosing Output Issues

High collisions or late collisions on an interface configured for full-duplex are a definitive sign of a duplex mismatch. If the remote end is half-duplex, it will transmit without listening for a clear channel, leading to collisions. If the remote end is full-duplex and you still see collisions, investigate cabling, faulty NICs, or transceiver issues. output drops (seen in the queueing strategy section) often indicate congestion; consider QoS, increasing port speed, or optimizing network topology.

Queueing Statistics

This section provides insight into how the interface queues packets for transmission and reception.


  Queueing strategy: fifo
  Output queue: 0/40, 0 drops; input queue: 0/75, 0 drops
  • Queueing strategy: fifo: First-In, First-Out. Other strategies include Weighted Fair Queueing (WFQ) or Class-Based Weighted Fair Queueing (CBWFQ) if QoS is configured.
  • Output queue: 0/40, 0 drops: The current number of packets in the output queue, followed by the maximum queue depth, and the number of packets dropped due to the queue being full. Significant output drops indicate congestion on this interface. This means the interface cannot transmit packets as fast as they are being presented to it. Solutions include increasing bandwidth, implementing QoS to prioritize critical traffic, or redistributing traffic.
  • input queue: 0/75, 0 drops: Similar to the output queue, but for packets entering the interface. High input queue drops are less common on modern switches but can occur if a specific ingress port is overwhelmed and internal buffers are exhausted, or if the CPU cannot process packets fast enough.

Example Output Walkthrough (Problem Scenario)


GigabitEthernet0/1 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is 0011.2233.4455 (bia 0011.2233.4455)
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 3/255, rxload 1/255
  Encapsulation ARPA, Loopback not set
  Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
  Last input 00:00:02, output 00:00:01, output hang never
  Last clearing of "show interface" counters 00:05:30
  Input queue: 0/75, 0 drops
  Output queue: 0/40, 5000 drops
  ...
  1234567 packets input, 123456789 bytes, 0 no buffer
  Received 1234567 broadcasts, 0 runts, 0 giants, 1000 CRC, 500 frame
  0 overrun, 0 ignored, 0 watchdog
  ...
  1234567 packets output, 123456789 bytes, 0 underruns
  200 output errors, 150 collisions, 100 late collisions
  0 interface resets

Analysis of the Problem Output:

  1. Full-duplex, 100Mb/s: The interface is configured for full-duplex at 100Mbps. This is an important baseline.
  2. Input queue: 0/75, 0 drops: No incoming queue drops.
  3. Output queue: 0/40, 5000 drops: 5000 packets have been dropped from the output queue. This indicates significant congestion. The interface cannot transmit data fast enough.
  4. 1000 CRC, 500 frame: High numbers of CRC and frame errors on input suggest a Layer 1 problem (bad cable, transceiver, or interference) or a duplex mismatch on the *remote* end where the remote device is sending bad frames.
  5. 200 output errors, 150 collisions, 100 late collisions: Critically, seeing collisions (especially late collisions) on a full-duplex interface is a definitive symptom of a duplex mismatch. One side is likely forced to full-duplex, while the other auto-negotiated to half-duplex. The high number of output drops, combined with collisions, reinforces this, as a half-duplex sender has to retransmit, causing congestion.

Conclusion for this scenario: The high CRC and frame errors, along with collisions and late collisions on a full-duplex interface, strongly indicate a duplex mismatch. The output drops are a consequence of the retransmissions and the underlying mismatch. The fix is to ensure the speed and duplex settings match precisely on both ends of the link, ideally by letting both sides auto-negotiate, or by manually setting both to the same speed and duplex (e.g., speed 100, duplex full).

Common Pitfalls and Troubleshooting

  • Ignoring Last clearing of "show interface" counters: Always clear counters (clear counters <interface>) before beginning a new troubleshooting session to get a fresh baseline of errors. Errors accumulate over the uptime of the device.
  • Misinterpreting is up, line protocol is down: This usually means Layer 1 is fine (cable connected, power), but Layer 2 negotiation failed. Common causes include mismatched encapsulation (e.g., HDLC vs. PPP on serial links), authentication failures, or misconfigured keepalives.
  • Assuming BW and DLY are actual throughput: These are administrative values used for routing metrics, not actual link capacity or latency.
  • Forgetting show interfaces status: This command provides a quick summary of port status, speed, duplex, and VLAN assignment, often useful for a quick check without the verbosity of show interfaces.
  • Not checking both ends of a link: Many interface problems (duplex mismatch, cabling) require examining the show interfaces output from both connected devices to pinpoint the exact cause.

Back to the knowledge base · Ask the AI assistant