Catalyst 9300 Stack Members: Roles and Readiness Checks

Short answer

Run show switch before Catalyst 9300 StackWise maintenance to record member numbers, roles, priorities and reported states. Reconcile those rows with the approved physical inventory. A Ready row is useful membership evidence; it does not prove every stack cable, service or recovery path is healthy.

Scope and prerequisites

This workflow follows the Catalyst 9300 IOS XE 17.12.x command reference. It applies to an authorized inspection of a physical switch stack, not a procedure for configuring another redundancy technology. Confirm the actual models, installed release and stack design before interpreting the output.

Have the expected member list and maintenance ticket available. Record the session target and capture time. Keep MAC addresses and asset identifiers in the private evidence store; do not place unsanitized output in a broadly shared handoff.

1. Capture the membership view

From an authorized EXEC session, run:

show switch

Retain the heading and all rows. Read member number, role, priority and state separately. Do not substitute a remembered rack order for the number displayed by the device.

Map each listed member to the approved inventory. If a number is missing, unexpected or cannot be mapped confidently, stop the physical intervention and ask the coordinator to resolve it. Moving a cable based on an assumed mapping can affect a different chassis than intended.

A configured priority and the currently reported role are different observations. Do not infer that the highest displayed priority proves which switch will be active after every possible restart. This capture is evidence of the present view, not an election simulation.

2. Investigate unexpected rows

Compare the number of expected physical switches with the returned membership. Preserve unusual states exactly as printed. If a member has not reached the expected operational state, avoid treating the stack as ready for a disruptive step merely because another row says Ready.

Take a second bounded capture after an agreed interval when a member is transitioning. Keep both timestamps and note whether the maintenance team expected a transition. Do not remove an unexpected row by changing provisioning or renumbering during inspection.

When the planned work depends on neighbor mapping, capture the documented additional view:

show switch neighbors

Compare the reported neighbor numbers with the approved cable diagram. A missing neighbor can have different significance in different designs; retain that exception for the stack owner rather than guessing which cable to unplug.

3. Inspect stack-port evidence when needed

For a cable-related maintenance task, use:

show switch stack-ports

Read the stack-port states alongside the neighbor view. These outputs answer different questions from ordinary Ethernet interface counters. Keep the port labels printed by the release and map them to the physical work instruction.

If the summary is inconsistent with the expected design, leave the baseline intact and use the platform's documented troubleshooting procedure. Do not reload a member, change its priority or clear diagnostic evidence to make the table look simpler.

A normal summary does not certify application reachability or the outcome of a failover. The maintenance plan must separately define the service checks and recovery access needed for the specific intervention.

4. Produce an actionable handoff

Record the inspected release, listed members, unresolved mapping, neighbor exceptions and the person authorizing the next physical step. Assign a named owner to every exception. A technician should be able to identify the target chassis without interpreting an abbreviated chat message.

For external Ethernet evidence, see interface counter baselines. Use the CliDeck workspace to keep the membership capture and physical instructions in the same approved runbook.

Verification note: acceptance criteria

On the actual Catalyst 9300 models and IOS XE build, verify that the commands complete, all expected members are reconciled, roles and states are preserved, and required neighbor or port evidence matches the approved design. Unknown members, unexplained transitions and missing recovery access remain exceptions. These are operator checks to perform; no real stack transcript, failover test or hardware observation 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

• Arista EOS Logging Checks: Preserve Configuration and Coverage - Capture EOS logging settings, severity and retention limits before maintenance; distinguish available local evidence from confirmed collector receipt.
• Catalyst 9300 PoE: Budget and Port State Checks - Read Catalyst 9300 PoE budget and port state separately, preserve labeled power values, and avoid mistaking power-on for endpoint health.
• Junos Uptime Before Recovery: Separate Boot, Protocol and Configuration Times - Collect boot, protocol-start and configuration times in Junos while preserving Routing Engine, node and clock context before recovery.
• Cisco Catalyst STP Root Checks: Compare Root ID, Bridge ID and Port Roles - Read the elected STP root and local bridge identity separately, preserve port roles and states, and compare the snapshot with the approved topology.
• Cisco Catalyst Interface Errors: Measure the Change, Preserve the Baseline - Compare two Catalyst interface-counter snapshots without clearing the baseline; distinguish new receive errors, congestion, and counter discontinuities.