CliDeck
PlatformLog in
Workspace

Catalyst Err-Disabled Ports: Cause, Detection and Recovery

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

Short answer

Capture the affected port, the recorded err-disable reason, and the detection and recovery settings as three separate pieces of evidence. An enabled detector does not identify the incident that disabled a particular port. An enabled recovery timer does not establish that reconnecting the port is safe.

This workflow produces a reviewable handoff for a switch owner before anyone changes interface state. It is useful when a remote operator inherits an unexplained disabled port and needs to avoid turning an incomplete ticket into a repeated outage.

Scope and prerequisites

The command reference used here covers Catalyst 9300 switches running IOS XE 17.12.x. Confirm your model and installed release before applying the sequence elsewhere. Use an authorized EXEC session with permission to run the commands. Output fields and supported reasons can differ across platforms; a rejected command is an applicability question, not a reason to improvise configuration.

Start a CliDeck workspace capture with the device identity, collection time and timezone, intended physical port and ticket reference. Check the stack member and port label against the request. A similar-looking interface on another member is not interchangeable. Keep the transcript private when it contains customer identifiers.

Step 1: locate the affected interface

Run the status query without filtering away columns:

show interfaces status err-disabled

The query lists interfaces currently in that state. Preserve the complete output and its headings. Record the exact interface and any displayed reason; do not assign a cause from memory when your release does not expose one here.

If the intended interface is absent, stop and reconcile the ticket with current state. A previous incident may already have cleared, or the ticket may refer to another device. Save that discrepancy instead of presenting an empty list as proof of successful remediation.

Step 2: capture detector settings separately

show errdisable detect

This view reports detection settings and modes by reason. Compare the relevant reason with the incident evidence. A setting describes what the switch is configured to detect; it is not a dated record that the feature triggered on this port.

In the handoff, keep a separate detection-settings field. Do not copy every enabled reason into the incident-cause field. If no reliable incident reason is available, write “cause unresolved” and request the switch owner's event evidence for this interface and time window. This article does not supply device logs or a substitute incident history.

Step 3: preserve recovery information

show errdisable recovery

Capture the recovery information exactly as displayed, including any interval and interface countdown information that your output provides. Distinguish a configured retry policy from an actual recovery attempt. A timer expiring describes eligibility to retry, not removal of the condition that caused the outage.

Cisco's 17.12 reference explicitly marks the displayed unicast-flood recovery field as invalid. Do not base a recovery decision on that field. When a reason, mode or field is unfamiliar, attach the raw output and leave its interpretation open for the platform owner.

Step 4: build a decision record

Use four separate ticket entries: current interface state, incident reason and its evidence, detection settings, and recovery information. Add capture timestamps because these commands run sequentially. If a retry occurs between queries, collect another set and retain both rather than merging them into one apparent snapshot.

Assign a named owner to investigate the recorded cause. A protective shutdown can involve a topology problem; repeated retries can disrupt more than the affected endpoint. This collection sequence supplies no configuration or interface-reset commands. The follow-up change should have its own diagnosis, authorization, observation window and rollback criteria.

For related link evidence, the Catalyst interface error baseline describes a separate collection task. Check the actual interface mapping before combining either transcript with this ticket.

Verification note: acceptance criteria

The operator should be able to identify the requested switch and physical port, reproduce all three queries, and locate the unedited outputs with timestamps. The ticket should distinguish a documented incident cause from enabled detectors and recovery settings. Missing or contradictory evidence should remain explicitly unresolved.

After a separately approved remediation, the owner needs fresh interface and incident evidence plus the required service check. Absence from an err-disabled list alone is insufficient to close a service ticket. These are acceptance criteria for an operator; no hardware test or successful recovery is claimed here.

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