LLDP/CDP Discovery for Network Automation: Prevent Wrong-Port Changes

LLDP and CDP discovery are often treated as nice-to-have operational data, but they can become a very practical safety net for network automation. Before a script, CI pipeline or AI-assisted workflow changes an interface, VLAN, port-channel or routing adjacency, it should know what is physically connected to that port right now.

This article shows a simple, vendor-neutral pattern for turning neighbor discovery into a lightweight source-of-truth check. It fits the Start Here networking topics, Data Center Networking and AI Infrastructure & Automation sections because cabling truth matters in data centers, branch networks and AI infrastructure clusters alike.

X Follow @ipexptobe

The goal is not to replace NetBox, an IPAM/DCIM system or disciplined change control. The goal is to add a cheap pre-flight question: “does the live network still look like the design we are about to change?”

Source: generic sanitized diagram created for Network freak / IPexpToBe.

The problem: interface intent drifts from physical reality

Most risky access-port and fabric-port mistakes are not caused by a lack of syntax knowledge. They happen because the configuration target is not what the change author thinks it is. A port was repatched during a maintenance window, a server team moved a NIC, a firewall HA cable was swapped, or a temporary test connection became permanent.

Common examples:

• A server-facing interface is converted to a trunk, but the port now connects to a different host.
• A port-channel member is shut for maintenance, but LLDP shows it is the only live uplink from a downstream switch.
• An EVPN/VXLAN leaf port is placed into the wrong VLAN/VNI because the neighbor name in the request is stale.
• A branch firewall replacement is prepared for the expected switch port, while the actual neighbor is an unmanaged intermediate device.

In AI-assisted network automation this matters even more. A language model can summarize a change, generate commands or review a diff, but it cannot safely infer the current cabling state unless the workflow supplies current discovery data.

Design: use discovery data as a pre-change guardrail

The pattern is deliberately small:

1. Collect LLDP/CDP neighbors from the devices that will be touched.
2. Normalize local interface names, neighbor names, chassis IDs, management addresses and remote ports.
3. Compare the observed neighbor with the intended neighbor stored in your design, ticket, inventory or change payload.
4. Classify the result as pass, warning or hard stop.
5. Attach the evidence to the change review so a human can see why the automation proceeded or stopped.

This should be a guardrail, not a single source of truth. LLDP can be disabled, CDP may be vendor-specific, some hosts advertise generic names, and intermediate appliances may hide the real endpoint. That is fine. Unknown data should trigger a review path, not blind confidence.

Suggested decision matrix

Observed state	Automation decision	Reason
Expected neighbor and remote port match	Pass	Live topology matches intent.
Neighbor name matches, remote port differs	Warning or manual review	Could be a harmless renumbering, vPC/MLAG move or cabling drift.
Different neighbor detected	Hard stop	The change may affect the wrong system.
No LLDP/CDP neighbor	Review, unless interface type allows it	Host NICs, security policy or disabled discovery may be normal.

Implementation workflow

A minimal implementation can be built with NAPALM, Netmiko, pyATS/Genie, vendor APIs or even scheduled command snapshots. The important part is to store structured facts, not raw terminal output only.

{
  "device": "leaf-01",
  "local_interface": "Ethernet1/21",
  "expected_neighbor": "gpu-node-07",
  "expected_remote_port": "nic0",
  "observed_protocol": "lldp",
  "observed_neighbor": "gpu-node-07",
  "observed_remote_port": "ens2f0",
  "decision": "pass",
  "timestamp_utc": "2026-09-01T06:00:00Z"
}

For port-channel, MLAG/vPC and EVPN fabric ports, evaluate the bundle and the member links separately. The logical interface may be correct while one physical member is connected to the wrong neighbor. For access ports, decide whether the endpoint is expected to advertise LLDP. Many servers, hypervisors and firewalls do, but not all environments allow it.

What to collect

• Local device and local interface.
• Neighbor system name, chassis ID and management address.
• Remote interface ID and description.
• Protocol used: LLDP, CDP or both.
• Last-seen age if the platform exposes it.
• Interface admin/oper status and error counters for context.

If you already monitor BGP, EVPN or interface state, link this data to those workflows. For example, a planned leaf-spine change can check both discovery facts and BGP neighbor state before proceeding. Related routing operational material lives in BGP Table Watch, and external tools and references are collected on the Resources page.

Verification and troubleshooting

Do not trust the guardrail until you test its failure modes. Build a small lab or maintenance-window test with three cases:

1. A correct neighbor, which should pass.
2. A known mismatch, which should block the change.
3. A discovery-disabled endpoint, which should move to manual review rather than pass silently.

When results look wrong, troubleshoot in this order:

• Confirm LLDP/CDP is enabled globally and on the specific interface.
• Check whether the neighbor advertises a hostname, chassis ID or only a MAC-like identifier.
• Normalize interface aliases: Eth1/1, Ethernet1/1 and ethernet-1/1 may represent the same port.
• Handle stacked switches, MLAG systems and modular chassis carefully; the advertised neighbor may be a virtual system name.
• Expire old facts. A stale “last seen yesterday” neighbor is worse than no neighbor at all.

Practical takeaways

• LLDP/CDP is not just documentation; it is live evidence for change safety.
• Use discovery facts as a pre-flight check before interface, VLAN, port-channel, routing and EVPN changes.
• Classify mismatches explicitly: pass, warning, review or hard stop.
• Feed the same structured facts to AI-assisted reviewers so recommendations are grounded in the current network.
• Keep sensitive data out of logs and prompts: anonymize hostnames, site names, management IPs and customer identifiers when sharing examples.

A small discovery guardrail will not fix a weak change process, but it can prevent many “wrong port” incidents with very little infrastructure. That makes it one of the highest-value first steps for practical network automation.

Follow Network freak for more networking notes, diagrams and troubleshooting tips.

X @ipexptobe on X