CliDeck
PlatformLog in
Workspace

Cisco EtherChannel Summary: Read Bundle and Member Flags Separately

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

Short answer

Read the port-channel flags and the member-interface flags as separate observations. Preserve the protocol and the output legend, then compare the observed membership with the approved topology. A bundle marked in use is not a test of application delivery, equal traffic distribution or the correctness of every downstream VLAN.

This guide applies to owned or customer-authorized Catalyst 9300 switches using the IOS XE 17.12.x command family. Collect the baseline from an authorized privileged EXEC session. Confirm the actual software and platform before interpreting additional flags.

Capture the complete summary

Record the device identity privately, collection time and the expected bundle. Start with:

show version
show etherchannel summary

Keep the whole summary, including its legend, group, port-channel, protocol and Ports columns. A cropped line can separate a flag from the interface it qualifies. Do not copy a legend from a different software release into the record and assume the meanings are identical.

The group number identifies a channel group. The port-channel column describes the logical interface; the Ports column reports its individual members. Read both columns before writing “healthy.”

Decode the bundle before its members

Common documented logical-interface flags include S for Layer 2, R for Layer 3, U for in use and D for down. The minimum-links condition has its own M indication in the documented legend.

Use the displayed combinations in context. SU describes a Layer 2 port-channel in use; it does not say every expected cable has joined. A Layer 3 bundle should be assessed against its intended routed design rather than judged against a Layer 2 example.

Retain the actual protocol column. Do not silently rename a static or differently negotiated bundle as LACP because that is what the work order expected.

Inspect every expected member

For member ports, P means bundled, I means stand-alone and lowercase s means suspended. H indicates LACP hot standby. Preserve case: uppercase S and lowercase s describe different conditions.

Build a private comparison record with the expected interfaces, observed interfaces and actual flags. A missing expected member and an extra unexpected member are separate exceptions. An interface absent from the summary is not automatically a failed cable; verify the intended group and supported platform views.

Hot standby can be intentional. Stand-alone operation and suspension require investigation against the approved design. Neither should trigger an automatic channel-group change.

Gather detail without rebuilding the bundle

For the relevant group, use the documented detail form. Group 1 is only an example selector:

show etherchannel 1 detail

Preserve the supported fields and any reported reasons. If the command is denied, unsupported or truncated, record a collection exception. Do not substitute a configuration session or a disruptive test to obtain an apparently cleaner result.

Do not remove and re-add a member, change negotiation mode, shut an interface or change minimum links during this inspection. Those actions alter the baseline and need a separately reviewed change plan.

Keep capacity and traffic conclusions bounded

Compare bundled members with the design requirement, including any minimum-link dependency. A logical interface can remain usable with fewer members than expected, while a configured minimum may prevent it from becoming active.

The summary also does not show equal utilization. EtherChannel forwarding uses a platform-dependent distribution mechanism; one flow should not be assumed to consume every member. Use appropriate counters and a separately authorized traffic investigation when the question concerns delivery or capacity.

Verification note: criteria for an EtherChannel baseline

An acceptable record contains the actual Catalyst model/build, complete legend and summary, expected membership comparison, collection time and relevant detail output or collection exceptions. It distinguishes logical bundle state from member state and leaves traffic success unclaimed.

These are operator acceptance criteria, not captured switch results. No bundle reconfiguration or packet test is claimed.

Use interface counter baselines for a separate counter investigation and LLDP endpoint checks for physical correlation. Store the handoff in the CliDeck workspace.

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 SSH, serial, browser terminal, and infrastructure operations workflows.

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