Catalyst 9300 Boot Checks: Running Image versus Next Reload
Short answer
Capture the running software and the settings for the next reload as separate evidence. On a Catalyst 9300, a successful running session does not establish what the switch will attempt after a restart. Compare the reported image with the complete boot-variable output before handing a reload request to another operator.
This is a read-only preflight for an owner-approved maintenance or refurbishment ticket. Its outcome is a reviewable record, not a boot change, an upgrade or permission to restart the device.
Scope and prerequisites
The command basis is Cisco's Catalyst 9300 IOS XE 17.12.x documentation. Confirm the exact hardware and installed release before adapting the workflow elsewhere. Use an authorized EXEC session and preserve the unedited output. Do not apply an EOS boot command or a ROMMON command just because its purpose sounds similar.
Prepare the device identity, stack inventory, intended maintenance scope and collection timestamp with timezone. Open a CliDeck workspace capture so another engineer can trace every extracted field back to its command. Keep customer identifiers and software inventory in the private work record.
Step 1: record what is running now
show version
Capture the full response, including the software version and any image, mode or member information reported by the installed release. Record the exact version string rather than shortening it to a release family. Preserve missing fields as missing; do not infer a per-member state from one line about the active switch.
If the request concerns a stack, reconcile the displayed members with the approved inventory. The Catalyst stack readiness guide covers that separate collection task. An unexplained missing member should remain an explicit review item.
Step 2: record the boot settings separately
show boot
Retain the headings and all sections. Cisco's documented example separates current boot variables from boot variables on the next reload, and includes a Manual Boot field. Copy the next-reload section into the ticket with its heading intact; do not substitute the current section because the values happen to match in an example.
The documented install-mode workflow uses flash:packages.conf as the boot target. That filename is a configuration reference, not a version number. Its presence does not by itself prove the intended packages exist, match the running release or are ready across every required stack member.
Do not equate the separate Boot Mode = DEVICE field with the software's install-versus-bundle classification. Keep the original field names when requesting a platform review. If the output differs from your release reference, stop interpreting unfamiliar fields rather than normalizing them to an expected result.
Step 3: compare observations with the work order
Create three ticket entries: running release and image information, next-reload target and manual-boot setting, and unresolved differences from the owner's intended state. Include a transcript reference and timestamp for each. These commands are sequential observations, not an atomic snapshot.
A matching filename is only one comparison. Ask the platform owner to confirm the intended release, required files and member coverage under the release-specific procedure. If an installation is in progress or another operator is changing boot settings, record that context and coordinate collection instead of issuing a competing command.
If the next target is blank, unexpected or unclear, hold the reload request for review. A disagreement may be intentional during planned maintenance, but it should have a named owner and an explicit disposition. Do not repair it by copying configuration commands from an upgrade guide into a collection session.
Step 4: hand off a bounded preflight result
State exactly what was checked and what remains outside this record. Keep image integrity, installation state, bootloader requirements, rollback preparation and post-reload service tests as separate acceptance items in the owner's maintenance procedure. This article supplies no install, file-removal, configuration-save or reload commands.
For a refurbishment intake, attach the observations to the asset record with the model and member mapping. Do not label an appliance “reboot tested” from these outputs. A restart test, if required, needs a separately authorized action and actual post-start evidence.
Verification note: acceptance criteria
The reviewer should be able to identify the device, read the exact running release, distinguish current from next-reload boot variables, and locate the reported manual-boot setting. Every mismatch or missing field should have a review owner. A successful command response alone is not an acceptance result for a restart.
After a separately approved maintenance action, fresh running-state evidence and the required service checks determine the outcome. These are operator criteria based on documentation; no physical boot test or successful upgrade 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
Quick decision table
| Situation | Better fit | Why |
|---|---|---|
| One authorized engineer needs a quick low-risk task | Traditional local workflow | It keeps the workflow simple when no shared context, batch work, or durable evidence is required. |
| The work needs verification, handoff, or documentation | CliDeck or browser workspace workflow | It creates a clearer path for notes, logs, stop conditions, and final checks. |
| Multiple people or devices are involved | CliDeck or browser workspace workflow | Structured workflows reduce ambiguity and make it easier to prove what happened. |
When option A is enough
The simpler option is usually enough when one authorized engineer is doing a low-risk task locally, the device state is known, and the work does not require shared context, batch processing, or durable evidence.
When option B is better
The more structured option is better when the work needs repeatability, collaboration, verification, logging, asset linkage, or a safer handoff between people or teams.
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
- Catalyst Err-Disabled Ports: Cause, Detection and Recovery - Collect Catalyst err-disabled state, detection settings and recovery information separately before approving a port retry.
- EOS VLAN Members: Active Ports versus Configured Ports - Compare EOS active and configured VLAN membership before declaring a port missing; keep logical ports and transport verification separate.
- Catalyst Trunk Checks: Read the Three VLAN Lists - Read allowed, active and forwarding/not-pruned VLAN lists separately, preserve native-VLAN context and compare both Catalyst trunk endpoints.
- 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 Stack Members: Roles and Readiness Checks - Capture Catalyst 9300 StackWise members, roles and readiness, then reconcile neighbors and port evidence with the approved physical inventory.