What an LLDP Neighbor Entry Actually Describes

Start with the receiving point

Link Layer Discovery Protocol, or LLDP, lets devices advertise information using type, length and value elements called TLVs. Juniper's Junos OS explanation identifies chassis ID, port ID and time to live as mandatory information. Other information can accompany those identifiers.

Cisco's neighbor-information guide describes a receiving switch's stored neighbor information and its deletion after the received lifetime passes without another advertisement. The useful mental model is a cache of received advertisements, associated with the local receiving port.

An observation therefore needs an observer as well as a reported neighbor. A local-interface value identifies where the observing device received the information; the advertised port ID concerns the other device's reported port. Preserve that distinction when an export is copied into a drawing. A row stripped of its observing device, interface and observation time loses the context needed to interpret it.

References: [J1][LL1]

Keep identifier types with their values

Cisco's guide separates chassis ID subtype, chassis ID, port ID subtype and port ID. The subtype identifies how to interpret the associated value: a chassis ID whose subtype is MAC address is an advertised MAC address. It is not thereby an equipment serial number.

Juniper's separate Junos OS reference contrasts a port ID based on the interface's SNMP index with one based on its interface name. These are different software identification conventions; neither automatically supplies the chassis-printed designation.

System name and port description are separate fields. Juniper describes the system name and port description as user-configured information, and distinguishes optional information from the mandatory identifiers. A readable name can help a person recognize an entry without establishing its relationship to a chassis label.

For a buyer reconciling installation records, the missing step is often the mapping between the reported identifier and a physically locatable endpoint. Request that mapping from the equipment/network owner with its supporting reference. Keep the original advertised value beside the mapped asset and physical port. Replacing the advertised string with a familiar rack label erases the evidence needed to check the mapping later.

References: [LL1][J1][J2]

Read the lifetime on a stated clock

Consider an original, stipulated aging-only example. One advertisement arrives at t = 0 seconds with a time to live of 60 seconds. No later advertisement arrives, and no other cache event occurs. At t = 40 seconds, the cache can still retain the entry with 20 seconds of lifetime remaining. By t = 70 seconds, that entry has expired.

At 40 seconds, retaining the entry does not establish that another advertisement arrived at that moment. At 70 seconds, expiration establishes that the advertisement was not refreshed within its stipulated lifetime. The example supplies no observation of a disconnected cable, failed server or failed switch.

The 60-second value is an assumption for this example, not a recommended setting or a claimed product default. For an actual supplied export, establish whether its TTL field means the received lifetime or the remaining lifetime, and retain the snapshot time. A number copied without that meaning cannot safely establish when the last advertisement arrived. A saved export also remains a historical observation after the live cache has changed.

References: [LL1]

Interpret an absent entry with its coverage

An empty neighbor result leaves several questions open. Does the relevant endpoint support the discovery behavior in question? Was it advertising in the direction being observed, and was the observing interface receiving it? Which device, interfaces and time did the supplied result actually cover? Cisco's implementation documents transmission and reception separately, so one direction should not silently stand in for both.

Ask the network owner to state that coverage with the returned observation. A missing row, an expired row and an interface omitted from an export are different evidence states. None selects a physical repair by itself. Likewise, an advertisement received at one end does not supply the other end's observation or an application-readiness result.

This is an interpretation framework for supplied records; it provides no discovery, configuration or diagnostic procedure.

References: [LL2]

Separate protocol adjacency from passive patching

A passive patch-panel adapter is a physical connection point, not another LLDP advertising device. A neighbor entry consequently does not acquire a row for every patch cord, trunk, adapter or intermediate panel position in the signal path. Those items belong in the physical connection map.

The advertised identities alone cannot distinguish a direct assembly from an otherwise supported path through passive patching. They also do not identify the route, assembly lengths or number of installed cable items. Counting neighbor entries is therefore an unsuitable way to reconstruct a cable bill or claim that every passive stage has been documented.

Avoid the opposite overstatement that LLDP can never be forwarded. The Cisco Business switches 250 Series CLI Guide, updated February 28, 2025, documents conditional packet flooding when LLDP is globally disabled and that handling mode is in effect. This is a specific implementation exception, not a suggested configuration. It reinforces the need to retain the applicable platform behavior when interpreting what a received advertisement says about adjacency.

References: [LL2][J1][L1]

Compare one observation with a separate path map

Fictional observation EX-O7 associates observing switch EX-A, local interface EX-L7 and a supplied advertised chassis/port pair. Its identifier subtypes and snapshot time are retained. Separately, the network owner supplies reference EX-M2 mapping that advertised pair to asset EX-S1 and physical port EX-P3. That mapping is an additional input, not a fact inferred from the neighbor name.

For this example only, physical drawing EX-P4 specifies two endpoint patch cords, one trunk and two intervening panel-port positions. The drawing therefore identifies three cable assemblies along the defined connection. The one neighbor observation did not produce that quantity or identify those patch positions.

If EX-P4 is missing, the buyer can retain the neighbor observation and the supplied endpoint mapping while marking the physical route unresolved. If EX-M2 is missing instead, the advertised pair cannot simply be renamed as EX-S1/EX-P3. These are different missing inputs with different owners. Neither omission authorizes a port change or proves that the installed connection is wrong.

All identifiers and quantities in this example are invented. They illustrate how evidence joins together, without representing a discovered network or an approved channel design.

Request two linked handoff records

Request a neighbor-observation record that retains the observing device and local interface, advertised chassis and port values with their subtypes, supplied optional fields, snapshot time and the stated meaning of the lifetime field. Include last-received information only if the supplied evidence actually contains it. Identify missing coverage rather than filling empty fields with guesses.

Keep the physical-path record alongside it: the physically locatable endpoints, the reference mapping protocol identities to those endpoints, intervening patch positions, assembly identities and route evidence. Link the two records through an explicit mapping reference. Agreement between advertised endpoint identities does not automatically complete the intervening physical map.

When the gap concerns physical routing, labels or connection records, Leviathan's structured cabling service can discuss that defined installation and documentation scope. Bring the endpoint plan, known patching, material responsibilities and required handoff detail to the project inquiry. The network owner supplies the protocol observations and their operating context; the physical scope and agreed checks determine the installation return.

References: [L1]