pjhtech Tools
Cisco · Cisco IOS XE

Cisco IOS XE Interface Commands: Status, Errors and Drops

Quick answer #

Use show interfaces counters errors to find suspect switch ports, then inspect the specific port with show interfaces. A nonzero lifetime counter is a starting point, not proof of an active fault. Compare two snapshots taken during the reported problem before deciding whether errors are increasing.

Scope: Catalyst IOS XE 17.x switching interfaces. Documentation baseline: Catalyst 9500 17.15.x. Interface names and available counters vary by model. Router interfaces do not necessarily support Catalyst-wide status and counter views.

Read-only commands #

Read-only commands
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only
show interfaces status
Read-only
show interfaces description
Read-only
show interfaces counters errors
Read-only

Replace these example values: GigabitEthernet1/0/1.

show interfaces GigabitEthernet1/0/1
Read-only
show interfaces status err-disabled
Read-only

Replace these example values: GigabitEthernet1/0/1.

show running-config interface GigabitEthernet1/0/1
Output may contain sensitive operational data.

What to read #

  • The status view gives a compact inventory. Confirm the interface name and description before investigating a port identified in an old diagram.
  • The detailed interface view adds line state, speed, duplex, rates and error totals. Record when counters were last cleared, if the output provides it.
  • CRC or input errors point toward a receive-side problem that needs investigation. They do not identify a particular patch lead or transceiver by themselves.
  • Output drops are a different symptom from damaged frames. A queue can discard traffic during congestion without recording CRC errors.

Workflow #

  1. Write down the affected application, client, switch port and incident time. A complaint about one host and a complaint about the entire uplink need different comparisons.
  2. Capture the compact status and error views. Inspect the access port and the next uplink rather than assuming the client's port is the only possible failure point.
  3. Repeat the relevant interface output while normal traffic continues. Retain both samples so another engineer can calculate the change over the same interval.
  4. Compare the corresponding far-end port. A clean local transmit view does not tell you what the far-end receiver observed.
  5. If the physical counters remain stable, continue to VLAN membership, spanning tree and routing. Link-up is only the first condition for successful forwarding.

Interpretation pitfalls #

Five-minute rate averages can conceal short bursts. An interface with low average utilization can still experience brief queue pressure. Conversely, a large historical error total may reflect an old fault that has already been repaired.

An err-disabled port is not the same as an unplugged port. Record the reason and correlate it with the relevant protection feature before planning recovery. This reference intentionally leaves counters intact and makes no configuration changes. That preserves the evidence needed to distinguish a current failure from historical noise.

Evidence to save #

Keep the local and peer interface names, timestamps, two counter samples and the service impact together. This is more useful for escalation than a screenshot of one unexplained error number.

Useful tools and references #

Sources

Documentation reviewed: 8 October 2026