Link Layer Discovery Protocol (LLDP)

Introduction to LLDP

In a large network, an administrator must determine which switches, routers, and servers are connected and which ports carry those connections. This previously required physical diagrams and manual cable tracing. Documentation could become outdated, while an undocumented change or misconfiguration made troubleshooting more difficult.

The Link Layer Discovery Protocol (LLDP), defined in the IEEE 802.1AB standard, exchanges physical-topology information between directly connected stations. It is a Data Link Layer (Layer 2) protocol that lets network devices advertise their identity and capabilities to directly connected neighbors. Messages can include the device name, the connected port, and capabilities such as a switch or VoIP-phone role. LLDP itself does not authenticate these claims, so management systems should consider the data source and configuration.

Why LLDP Was Created: Interoperability

Neighbor discovery was previously implemented through vendor protocols such as Cisco Discovery Protocol (CDP). Other manufacturers had similar solutions, but support depended on device compatibility. A Dell switch could not interpret CDP messages from a Cisco switch, and an HP phone could not receive configuration information from a Juniper switch.

LLDP was created by the IEEE as a common, open standard. Its vendor neutrality supports interoperability and lets an administrator collect physical-topology information from equipment made by different vendors. The data supports network mapping, troubleshooting, and configuration of management systems.

How LLDP Works

LLDP operates without establishing a formal connection or session. Devices periodically send protocol data units and store information received from neighbors.

1. Periodic Advertisements:An LLDP-enabled device, such as a switch, router, or IP phone, periodically sends special frames called LLDPDUs (Link Layer Discovery Protocol Data Units) on active ports. Many implementations and configurations use a 30-second interval, but the value depends on the device. An entry may also be refreshed after a port-state change or during a supported fast-start procedure.
2. Listening for Neighbors:Simultaneously, the device listens for LLDPDUs coming in from its directly connected neighbors on each port.
3. Building a Neighbor Table:When a device receives an LLDPDU, it caches the information contained within it in a local database, often called an LLDP neighbors table or a Management Information Base (MIB). This table associates a specific port with the identity and capabilities of the neighbor connected to it. Management software can read the data locally or through SNMP when the device exposes the relevant MIB.
4. Keeping Information Fresh (TTL):Each LLDPDU contains a Time To Live (TTL)value. A typical configuration uses 120 seconds, but the value depends on the transmit interval and device settings. When a neighbor's information is stored, a timer is started. If another LLDPDU does not arrive before it expires, the device treats the entry as stale and removes it from the table. This allows topology information to reflect the current state of the links. The timer is refreshed by a valid LLDPDU from that neighbor, rather than by an arbitrary frame.

The LLDP TLV Format

LLDP extensibility comes from its message format. Information within an LLDPDU is organized into blocks called TLVs (Type-Length-Value).

Each block has three fields:

• Type (7 bits): A numeric code that identifies the kind of information being sent, such as Type 1 = Chassis ID and Type 2 = Port ID.
• Length (9 bits): A number that specifies the length (in bytes) of the Value field. This tells the receiver exactly how much data to read for this piece of information.
• Value (Variable):The actual information itself, such as the MAC address, the port name, or the device's IP address.

The TLV format makes the protocol extensible. A new Type code can be defined for a new kind of information. A device that does not understand it reads the Length field, skips the Value, and can continue parsing the rest of the frame.

Common TLVs

LLDP defines several standard TLVs, which are divided into mandatory and optional categories.

LLDP-MED for Voice and Video

LLDP-MED (Media Endpoint Discovery), described in ANSI/TIA-1057, extends LLDP for voice and video over IP (VoIP) devices such as IP phones and video conferencing units. It can reduce manual endpoint configuration by conveying network parameters to those devices. The extension adds organizationally specific TLVs for areas including device capabilities, network policy, power, and location.

A switch that supports LLDP-MED can use organizationally specific TLVs to provide media endpoint devices with information needed for operation. The result depends on compatibility and configuration of the phone, switch, and management system:

• Voice VLAN: The switch can tell an IP phone which VLAN to use for voice traffic. The phone and switch can then separate voice from data traffic when their configuration supports it.
• QoS / Traffic Priority: The switch can provide policy for marking voice packets. It can specify the CoS or DSCP value that the phone may place on its voice packets.
• Power Management (PoE): A phone can use LLDP-MED to tell the switch how much power it requires through Power over Ethernet (PoE). The switch can include this information in its power budget and confirm the allocation.
• Location Information:For emergency services such as E-911, the caller's physical location is important. An LLDP-MED enabled switch can be configured with location information, for example "123 Main Street, London, 4th Floor, East Wing", and provide it to the phone. A phone system can use the data during an emergency call when it supports that mechanism.

Example LLDP-MED Exchange

After an IP phone is connected to a switch, the exchange may proceed as follows.