CliDeck
PlatformLog in
Workspace

Cisco Catalyst Interface Errors: Measure the Change, Preserve the Baseline

Runbooks
#cisco#operational-evidence#runbooks#remote-operations#Runbooks#network-operations
← Back to Blog

Short answer

For a Cisco Catalyst interface-error investigation, preserve two timestamped observations of the same port and compare the counter changes. A large cumulative CRC or drop total alone does not tell you whether errors are occurring now. Keep the existing baseline intact, distinguish receive errors from output drops, and record counter discontinuities before drawing a conclusion.

Scope and prerequisites

Command syntax here follows the Catalyst 9300 IOS XE 17.12.x command reference. Other Catalyst platforms, port types, and releases can expose different fields and counter behavior. Record the actual model, software build, stack member, and interface identifier. Inspect command help if an example is unavailable.

The examples use GigabitEthernet1/0/1. Replace it with the confirmed physical port. A port-channel, an uplink on a different stack member, and a copper access port are different observation points; do not substitute one for another without understanding the topology.

Use approved privileged EXEC access and private transcript capture. This is a read-only investigation and does not authorize cable moves, counter clearing, link resets, or buffer tuning.

Take the first complete snapshot

Capture the device clock and detailed interface output:

show clock
show interfaces GigabitEthernet1/0/1
show interfaces GigabitEthernet1/0/1 counters errors

Save the full output rather than only a filtered error line. It supplies link state, speed/duplex context, traffic rates, packet totals, error fields, and the displayed last-clearing information. Check the actual clock against the observation record; a device timestamp can be wrong.

Agree on a bounded observation interval and the expected traffic with the service owner. Do not generate a production load test just to make counters move. If the port is idle, a zero delta has limited diagnostic value.

Take the second snapshot without clearing anything

At the end of the agreed interval, repeat the same commands on the same device and port. Record any link event, reboot, stack-member change, or counter clearing during the interval. If counters decrease or restart, reject the simple subtraction and establish a new baseline.

For a counter with a continuous baseline:

counter delta = second observation - first observation

A synthetic example illustrates the arithmetic: 120 CRC errors followed by 123 means three additional CRC errors during that interval. Those numbers are an example, not a CliDeck test result. Include elapsed time and packet activity when reporting the delta.

Interpret the fields as clues

ObservationUseful next question
Increasing CRC or frame errorsIs there a physical-link, transceiver, peer, or duplex issue?
Increasing input errorsWhich underlying receive-error categories are increasing?
Increasing total output dropsIs the egress path experiencing congestion or oversubscription?
No growth during an idle intervalWas there enough relevant traffic to exercise the suspected condition?

Input errors aggregate categories; do not count the aggregate and its component counters as independent failures. Output drops require queue and traffic context and do not, by themselves, identify a bad cable. Platform-specific hardware counters may require a separate vendor-scoped investigation.

Do not turn this observation into a universal numeric pass/fail threshold. Service requirements, traffic patterns, and the particular counter determine whether the measured change is acceptable.

Verification note: preserve the diagnostic baseline

An acceptable evidence record contains both complete observations, the port identity, model/build, interval, packet activity, relevant deltas, and any discontinuity. If the two snapshots are not comparable, say so and recollect rather than inventing a rate.

Keep remediation separate. Clearing counters removes useful history; resetting a port or swapping a component can disrupt service. Escalate with the evidence and an approved next-step plan.

These are verification criteria rather than claimed bench observations. CliDeck Workspace can preserve the paired transcripts and command handoff. For complete output capture, see the IOS XE terminal pagination guide.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on approved network devices inside a planned change or lab scope.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides