CliDeck
PlatformLog in
Workspace

Catalyst 9300 PoE: Budget and Port State Checks

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

Short answer

On a PoE-capable Catalyst 9300, capture show power inline before changing power settings or reconnecting a powered device. Review the module budget and the selected port separately. Available watts do not establish that a particular port is supplying power, and an operationally powered port does not establish that its phone, camera or access point is functioning.

This is a read-only handoff for an owned or authorized switch. It gives the next operator a bounded starting point without interrupting attached devices.

Scope and prerequisites

The command workflow targets Catalyst 9300 switches running IOS XE 17.15.x. Confirm the exact SKU, software release and PoE capability first. Port names and power features vary across the family; a non-PoE port is outside the scope. Use authorized EXEC access and preserve the full response rather than only a filtered line.

Record the asset identifier, capture time, stack member and selected physical port. Identify the endpoint from the ticket and cabling record; do not trust a reported device name as unique identity. If the cable endpoint is uncertain, use the LLDP remote-hands checklist before acting.

Capture the budget and the selected port

Start with these commands:

show version
show power inline

For a switch whose actual port is GigabitEthernet1/0/1, request its detail:

show power inline GigabitEthernet1/0/1 detail

Replace that interface with the verified port name. Keep commands and output together in the transcript. If the detail keyword is rejected, record the rejection and use command help plus the exact-release reference; do not substitute an unrelated platform's syntax.

Read the module's Available, Used and Remaining columns as its reported power budget. Then read the port's Admin and Oper states, Power, Device, Class and Max fields. Preserve units and missing values. For detailed output, keep allocated power distinct from measured consumption when those labels are present. Do not relabel an allocation as a meter reading.

Make the handoff answer a specific question

For “is this endpoint receiving power?”, provide the selected port's operational state and the capture time. Add the budget row as context. Keep “switch reports power on” separate from “endpoint responds to its application check.” The latter needs evidence from the endpoint or service owner.

For “can another endpoint be added?”, provide the observed remaining budget and the proposed endpoint's requirements to the responsible engineer. A positive remainder alone does not approve the addition: port capability, configured limits, power policy and failure conditions still need review.

A compact ticket record can contain:

Asset / stack member:
Exact release / PoE-capable SKU:
Selected interface / endpoint record:
Capture start and end:
Module budget, with units:
Port admin / operational state:
Allocation / measured consumption, if labeled:
Endpoint service check: performed separately or not performed
Next decision owner:

Exceptions that should stop an automatic conclusion

An off port does not identify the cause by itself. A disconnected endpoint, configured policy, negotiation issue or other condition requires additional evidence. Likewise, n/a is not a zero measurement. Preserve unsupported or missing fields as unresolved.

If the attachment changes between captures, label the two states separately. Do not combine the earlier budget with the later port detail as though they were simultaneous. Avoid power cycling, changing inline-power limits or moving production cables merely to improve the evidence record. Those are separate authorized interventions.

Verification note: acceptance criteria for the capture

A useful capture identifies the exact switch, release, member and interface; retains complete budget and port-detail output; distinguishes allocation from consumption; and states whether endpoint functionality was checked separately. These are operator acceptance criteria, not a claim that this article's commands were tested on a device.

Store the transcript and decision in a CliDeck workspace, then follow the two-snapshot interface baseline if the remaining question concerns link errors rather than power.

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