CliDeck
PlatformLog in
Workspace

Cisco Catalyst STP Root Checks: Compare Root ID, Bridge ID and Port Roles

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

Short answer

Read the VLAN's complete spanning-tree output and compare its Root ID with its local Bridge ID before judging any port. A blocked redundant path can be the intended topology. A forwarding port is an STP state, not proof that a particular application works.

This guide is a read-only baseline for authorized operators preparing remote maintenance or collecting evidence for a network owner. It does not change bridge priority, port cost, VLAN membership or protection settings.

When this applies

This workflow targets Catalyst 9300 running IOS XE 17.12.x, with the Root ID, Bridge ID, Role and Sts output fields. Confirm the installed release and actual STP mode rather than assuming every Catalyst has identical output.

The VLAN example below is 10. Replace it with the approved VLAN under investigation. For PVST+ and rapid PVST+, the observation is per VLAN. MST maps VLANs to instances; if the switch uses MST, collect the relevant instance and region context through that release's documented inspection procedure. Do not reinterpret a VLAN snapshot as an independent MST tree.

1. Establish the device and collection scope

Start from an authorized privileged EXEC session and capture:

show version
show spanning-tree summary
show spanning-tree vlan 10

Save the full output with collection time, switch or stack identity, release, selected VLAN and the incident question. Keep real MAC addresses and customer identifiers in the private record.

Do not use a filtered one-line result as the baseline. Removing the VLAN heading or protocol line can make two unrelated observations look comparable. If the VLAN is absent, the command is rejected or access is restricted, record that limitation and resolve the scope before drawing a topology conclusion.

2. Compare the two bridge identities

Root ID identifies the elected root for the displayed tree. Bridge ID identifies this switch's logical bridge. Compare the complete identities, including priority and address; an equal priority alone does not establish that this switch is the root.

When the complete identities match and the output identifies this bridge as root, record that local observation. When they differ, record the root identity and the shown path toward it. Compare the result with the owner's expected root, not with a rule that every access switch should be root.

The displayed priority can include a VLAN system ID extension. Preserve the printed value and its parenthetical breakdown. Do not silently replace it with a remembered configured priority.

A Catalyst stack appears as one STP node with a shared bridge identity. This output does not independently certify the health of each physical stack member.

3. Read Role and Sts separately

Keep the interface name, role, state and cost together. Root and designated describe a port's place in the tree. Forwarding and blocking describe its current STP state. An alternate path being blocked can be correct protection against a loop.

Do not instruct remote hands to reconnect or move a cable merely because its port is blocked. First map the physical endpoints and expected redundant path. The LLDP endpoint checklist supports that separate task.

If the table presents a port-channel, relate it to the EtherChannel bundle and member record. A logical STP port and its physical members are different scopes.

4. Handle unexpected or changing results

If the observed root differs from the design, stop at evidence collection and escalate to the topology owner. Preserve a second timestamped snapshot if roles are changing; do not erase counters, disable STP or adjust priorities to make the summary look normal.

Missing output is not proof that STP is unnecessary. A stable table is not proof that no earlier reconvergence occurred. Correlate the snapshot with authorized incident records and service checks.

Verification note: acceptance criteria

Accept the baseline when the device, VLAN and mode are explicit, both bridge identities are retained, and every questioned interface has its role and state recorded. Mark unexpected roots or missing instance context unresolved.

Use CliDeck Workspace to keep the transcript and checklist together. This collection passes when another operator can trace each conclusion to the original scope; it does not pass a traffic-delivery or maintenance-change test.

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