LLDP and PROFINET Topology Detection

Back to Blog

How Neighbor Detection Works

LLDP is a standard link-layer protocol in which each port periodically sends a small frame advertising its own identity - device name and port - to whatever is directly connected. Its neighbor stores that, and vice versa, so both ends of every cable know precisely who is on the other side and through which port. PROFINET adopts LLDP so this per-port neighbor map exists across the whole network, giving the engineering tool the raw material to draw the actual wiring rather than a guessed layout.

Because the information is port-specific, the topology it produces is not just a list of devices but a diagram of which port connects to which port. That is far more useful than a flat device list: it distinguishes a line, a ring, and a star, and it tells you the physical order of devices along a segment. This neighbor data complements the higher-level view of a chosen daisy-chain topology with ground-truth about what is actually cabled.

What Topology Detection Buys You

The first payoff is fault location. Because each device knows its expected neighbor, a break or a miswire shows up as a specific device reporting that the wrong neighbor, or no neighbor, is on a given port. Instead of a vague network fault, you get the exact port where reality stopped matching the plan, which turns cable troubleshooting from a hunt into a lookup. The engineering tool can highlight the offending link on the topology diagram.

The second payoff is automatic device replacement without a supervisor laptop. When a device fails and an unnamed replacement is plugged into the same physical position, the controller uses the LLDP neighbor relationships to recognize where the new device sits and assign it the correct station name over the network, so it rejoins with no manual DCP step. This is the designed cure for the device name mismatch after replacement, and it only works when topology has been configured so the controller knows what should be where.

What an LLDP Frame Carries

An LLDP advertisement is a short frame built from type-length-value fields. The mandatory ones identify the sender: a chassis identifier for the device, a port identifier for the specific port doing the talking, and a time-to-live that tells the neighbor how long to trust the information before it goes stale. PROFINET adds its own extension fields on top of the base IEEE 802.1AB standard, carrying the station-name and port details the engineering tool needs to match the physical map against the project configuration.

Two properties make LLDP well behaved on a control network. The frames are link-local - addressed so a compliant switch consumes them at the port rather than forwarding them onward - which is precisely what makes a neighbor relationship mean 'physically adjacent'. And the protocol is advertisement-only: devices announce and listen, but nothing about LLDP polls, retries, or competes with the cyclic PROFINET exchange. It runs quietly alongside the process data as bookkeeping.

Switches Make or Break the Map

The neighbor map is only as truthful as the infrastructure between devices. A managed, PROFINET-aware switch participates in LLDP itself: it appears in the topology as a device with its own ports, so the map stays accurate through it. An unmanaged switch does one of two kinds of damage depending on how it handles the frames. If it drops them, the devices on either side see no neighbor and that stretch of the map goes dark. If it floods them through - which simple switches commonly do - the devices on either side record each other as directly connected when they are not, and the switch itself is invisible.

That second case is the sneaky one, because the topology looks complete and plausible while being physically wrong, and position-based features quietly misbehave: a fault gets located on a link that does not exist, and replacement-by-position identifies the wrong spot. The practical rule is that everything in the PROFINET path should speak LLDP, and any switch that cannot should be treated as a hole in the map you have knowingly chosen to live with.

What Automatic Replacement Actually Requires

Replacement without a laptop is the headline feature, but it only works when several conditions hold at once:

1. The topology was configured in the engineering project and matches the real cabling - this is the reference the controller compares against.
2. The controller is configured for automatic name assignment.
3. The replacement device is factory-fresh or reset, holding no station name of its own.
4. It is plugged into exactly the planned port, since its position is its identity.
5. The device type is compatible with what the project expects at that position.

When those hold, the controller recognizes the new device by where it sits and assigns its station name over the PROFINET discovery and configuration protocol (DCP), and the device rejoins on its own. When any of them does not hold - a spare that served elsewhere and still carries its old name being the classic - the replacement stalls and the fix is a manual naming step. It is worth writing the reset-the-spare step into the maintenance procedure for exactly that reason.

Reading a Mismatch Between Map and Plant

Symptom	Likely cause
Wrong neighbor reported on one port	Cables swapped between two ports during maintenance
No neighbor on a port that should have one	Broken cable or dead port, or a switch in the path dropping LLDP
Neighbors that skip over a known switch	Unmanaged switch flooding LLDP frames through
Mismatch appearing right after a repair	Reconnection in a different order than the planned topology

The general method: trust the LLDP data as a statement of what is cabled right now, and treat the engineering project as the statement of what should be. Diagnosis is the diff between the two, walked port by port - a workflow covered step by step in diagnosing PROFINET with LLDP neighbor data.

Frequently Asked Questions