CliDeck
PlatformLog in
Workspace

Catalyst CDP Checks: Map Neighbor Ports Before Remote Hands

Remote Hands
#cdp-handoff#operational-evidence#runbooks#remote-operations#Remote Hands#remote-hands#network-operations
← Back to Blog

Short answer

Before asking remote hands to move a cable, capture the CDP neighbor record and keep the local interface separate from the neighbor's advertised port. Compare that record with the approved cabling map and current physical labels. CDP supplies discovery evidence; a row in its table is not permission to disconnect a port or proof that an application works.

The useful deliverable is a port-to-port handoff with a timestamp, an evidence reference and any unresolved mismatch. This prevents a shorthand ticket such as “move the uplink” from becoming an ambiguous instruction at the rack.

When this workflow applies

The command basis is the Catalyst 9300 IOS XE 17.12.x CDP guide. Confirm your installed release and platform before extending the sequence to other devices. Use an authorized EXEC session. This is a collection workflow for a device you own or are authorized to administer; it does not change discovery settings.

Prepare the expected switch identity, stack member, local port, destination and work-order reference. Open a CliDeck workspace capture and record the collection time and timezone. Keep device names, addresses and customer topology in the private ticket, with access limited to the people doing the work.

Step 1: collect discovery scope

show cdp
show cdp interface

The first view describes global CDP information, including advertised timing. The interface view identifies interfaces on which CDP is enabled. Preserve the output so the reviewer can distinguish a discovery-scope question from a missing-neighbor question.

If the requested interface is absent or the command is rejected, record the response and check the platform reference and your access level. Do not enable CDP just to fill a worksheet. A change to discovery policy needs its own approval and review of the affected endpoints.

Step 2: capture neighbors and details

show cdp neighbors
show cdp neighbors detail

Keep the complete headings and each relevant neighbor block. The documented information includes platform, capabilities, holdtime and port identifiers. In your ticket, label the two sides explicitly: the queried switch's local interface and the neighbor's advertised port ID. Do not swap them when transcribing the relationship.

Record the advertised device identifier as an observation, then reconcile it with the asset record. A familiar name alone is insufficient to select a cable. If the port label, member number or expected neighbor disagrees, assign that mismatch for review before drafting a move instruction.

Step 3: account for cached information

CDP retains received neighbor information until its holdtime expires unless refreshed. Preserve the timing context with the capture. An entry can outlast the last advertisement that created or refreshed it; a positive remaining holdtime is not a live service probe.

If the cabling may have changed during collection, take another timestamped snapshot and retain both. Document which observation belongs to which work stage. Do not combine an old neighbor block with a new physical label and present them as a simultaneous observation.

An empty result also needs a bounded conclusion: no CDP neighbor was displayed in that collection context. It does not establish that the cable is disconnected. The other endpoint may not advertise CDP, or discovery may be disabled. Ask for the relevant endpoint and interface evidence rather than changing settings or declaring hardware failure.

Step 4: write a usable remote-hands request

Build the handoff around a single intended connection. Include the confirmed local device and port, expected remote device and port, physical label or rack reference, capture timestamps and the exact authorized action. Keep unresolved facts in a separate section with a named owner.

Require the onsite operator to read back the physical labels before the action. Define the post-action collection and service checks in advance, with a stop condition for unexpected labels or neighbors. Discovery evidence should inform the request, while the work order determines what the operator may change.

For a separate protocol comparison, see the LLDP neighbor handoff guide. Keep CDP and LLDP observations named and timestamped independently when both are available.

Verification note: acceptance criteria

The reviewer should be able to locate the raw command outputs, identify the local and remote ends without inference, and match them to the intended work order. Discovery scope, timing and any mismatch should be explicit. Missing data should remain unresolved rather than being replaced with an expected value.

After authorized work, collect fresh evidence and perform the service checks required by the owner. A neighbor appearing in CDP is one discovery outcome, not the complete acceptance test. These are operator criteria; no physical cable move, device test or successful service restoration is claimed here.

Who this is for

This guide is for remote hands teams, senior engineers, data center teams, vendor support, and operations teams who need to share terminal context, coordinate onsite work, or hand off command-line work safely on live terminal sessions, onsite devices, and remote support 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.

Shared terminal sessions let another authorized engineer watch the live terminal and, when permitted, type commands without taking over the operator’s entire desktop.

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