CCNA 200-301

CCNP Enterprise

CCNP Security

CCIE Enterprise Lab

CCIE Security Lab

CCNP Service Provider

CCNP Data Center

CCNP Collaboration

CCIE DC Lab

Link Layer Discovery Protocol (LLDP) is an IEEE standard (802.1AB) Layer 2 protocol that allows network devices to advertise identity, capabilities, and configuration details to directly connected peers. While Cisco switches historically rely on the proprietary Cisco Discovery Protocol (CDP), multi-vendor enterprise environments—incorporating devices from vendors such as Arista, Juniper, HP, and third-party VoIP manufacturers—require LLDP for seamless topology mapping and automated endpoint onboarding.

Activating and properly managing LLDP ensures that your network management systems, monitoring platforms, and access-layer devices maintain visibility across vendor boundaries. This comprehensive guide covers protocol differences, deployment workflows across Cisco IOS/IOS-XE and NX-OS, LLDP-MED configuration for IP endpoints, verification strategies, deployment automation templates, and platform specifications.


LLDP vs. CDP: Protocol Differences and Coexistence

Before enabling LLDP across a production fleet, network architects must evaluate how LLDP compares to CDP and how both protocols interact when running simultaneously on the same hardware.

Feature / CriterionIEEE LLDP (802.1AB)Cisco CDP (Proprietary)Deployment Recommendation
StandardizationOpen standard (IEEE 802.1AB)Cisco proprietaryUse LLDP in heterogeneous networks; CDP in Cisco-only setups.
Vendor CompatibilityUniversal (supported by virtually all enterprise networking vendors)Primarily Cisco devices (limited third-party licensing)LLDP is mandatory if connecting third-party switches, servers, or firewalls.
Default State on Cisco SwitchesDisabled by default on most Catalyst switches; enabled on some Nexus switchesEnabled globally by default on all interfacesEnable LLDP manually on access and distribution switches.
Default Advertisement Interval30 seconds60 secondsLLDP detects topology link changes faster under default timers.
Default Holdtime (TTL)120 seconds180 secondsBoth protocols maintain roughly a 4x or 3x hello multiplier.
Voice / Endpoint SupportLLDP-MED (ANSI/TIA-1057) extension required for VLAN/PoENative CDP TLVs natively negotiate voice VLAN and auxiliary powerUse LLDP-MED for Poly, Yealink, or Avaya; CDP works natively with Cisco IP phones.
Overhead & Frame SizeVariable depending on active TLVs (Type-Length-Value fields)Variable depending on CDPv1 or CDPv2 payloadsMinimal overhead difference; both generate negligible bandwidth demand.
CoexistenceCan run concurrently with CDP on the same physical switchportCan run concurrently with LLDP on the same physical switchportRecommended: Run both concurrently during migrations; disable CDP on non-Cisco edge ports for security.

Running both protocols in tandem is standard practice during multi-vendor integrations. A Cisco switchport can simultaneously broadcast CDP frames to downstream Cisco access points and LLDP frames to multi-vendor servers or desktop endpoints without protocol collisions or resource starvation.


Enabling LLDP Globally and Per Interface in Cisco IOS and IOS-XE

On Cisco Catalyst switches running IOS or IOS-XE (such as the Catalyst 2960X, 3650, 3850, and Catalyst 9000 series), LLDP is turned off by default. Activating it requires executing global initialization followed by granular interface tuning where necessary.

Step 1: Access Global Configuration Mode

Log in to the switch through SSH or the local console, enter privileged EXEC mode, and transition to global configuration:

Switch# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#

Step 2: Enable LLDP Globally

Execute the lldp run command. This initializes the LLDP subsystem, schedules advertisement timers, and enables the switch to begin processing Layer 2 discovery frames:

Switch(config)# lldp run

Note: To turn off LLDP across the entire switch at any time, execute no lldp run.

Step 3: Configure Per-Interface Transmission and Reception

Once LLDP is running globally, all supported physical interfaces default to transmitting and receiving LLDP advertisements. However, Cisco IOS allows administrators to toggle frame directionality using lldp transmit and lldp receive.

To selectively disable transmission on an untrusted or external-facing access port while still listening for connected device information:

Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)# no lldp transmit
Switch(config-if)# exit

Conversely, to completely disable LLDP processing on a security-sensitive port (e.g., public kiosks or DMZ demux links):

Switch(config)# interface GigabitEthernet1/0/2
Switch(config-if)# no lldp transmit
Switch(config-if)# no lldp receive
Switch(config-if)# exit

To re-enable either capability on an interface:

Switch(config)# interface range GigabitEthernet1/0/1 - 48
Switch(config-if-range)# lldp transmit
Switch(config-if-range)# lldp receive
Switch(config-if-range)# exit

Step 4: Fine-Tune Advertisement Timers (Optional)

In environments requiring faster discovery convergence or reduced multicast chatter, adjust the transmission interval, holdtime, and re-initialization delay:

Switch(config)# lldp timer 15
Switch(config)# lldp holdtime 60
Switch(config)# lldp reinit 2
  • lldp timer <seconds>: Frequency of periodic advertisements (default is 30 seconds).
  • lldp holdtime <seconds>: Duration the receiving device should retain information before discarding it (default is 120 seconds).
  • lldp reinit <seconds>: Delay before re-sending initialization packets on an interface after a link bounce (default is 2 seconds).

Configuring LLDP-MED for VoIP and IP Endpoint Discovery

LLDP Media Endpoint Discovery (LLDP-MED), defined under ANSI/TIA-1057, extends base LLDP capabilities to facilitate automated provisioning between network switches and media endpoints such as IP phones, conference systems, and video codecs. LLDP-MED communicates Voice VLAN IDs, Differentiated Services Code Point (DSCP) priorities, 802.1p Class of Service (CoS) tags, and fine-grained Power over Ethernet (PoE) demands.

Step 1: Define a Voice Network-Policy Profile

LLDP-MED requires a defined network policy profile that packages the operational parameters of the real-time application.

Switch(config)# network-policy profile 100 voice
Switch(config-network-policy)# voice vlan 150 cos 5
Switch(config-network-policy)# voice-signaling vlan 150 cos 3
Switch(config-network-policy)# exit

Step 2: Assign the Network Policy to Edge Interfaces

Apply the policy profile to switchports serving third-party or dual-homed VoIP telephones. Ensure the interface is configured as an access port with access and voice VLAN assignments:

Switch(config)# interface GigabitEthernet1/0/10
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# switchport voice vlan 150
Switch(config-if)# network-policy 100

Step 3: Enable LLDP-MED Specific TLVs and Power Negotiation

Cisco switches transmit inventory, capability, and power TLVs by default once LLDP is globally up. You can verify or explicitly instruct the interface to send advanced power-negotiation and inventory attributes:

Switch(config-if)# lldp med-tlv-select inventory-management
Switch(config-if)# lldp med-tlv-select network-policy
Switch(config-if)# lldp med-tlv-select power-management

Step 4: Configure Fast-Start Discovery

When an endpoint boots up, the standard 30-second transmission interval causes significant configuration delays. LLDP-MED Fast-Start accelerates this exchange by sending frames at rapid 1-second intervals upon link detection.

Switch(config)# lldp med-fast-start-repeat-count 5

This forces the switch to broadcast five LLDP-MED packets immediately when the link state transitions to up, accelerating the endpoint’s address acquisition and VLAN assignment.


Enabling LLDP on Cisco Nexus Switches (NX-OS)

Cisco Nexus data center platforms (Nexus 3000, 7000, and 9000 running NX-OS) employ a modular control plane where services run in isolated processes. Unlike Catalyst IOS/IOS-XE, LLDP must be enabled through the NX-OS feature subsystem before configuration syntax becomes available.

Step 1: Enable the LLDP Feature Subsystem

Enter configuration mode and initialize the process:

switch# configure terminal
switch(config)# feature lldp

To confirm the process is active:

switch(config)# show feature | grep lldp
lldp                   1          enabled

Step 2: Configure Interface Transmit and Receive Flags

In NX-OS, enabling feature lldp activates the protocol across all supported Ethernet and fabric interfaces by default. To disable or customize on specific downlinks:

switch(config)# interface Ethernet1/1
switch(config-if)# no lldp transmit
switch(config-if)# no lldp receive

To adjust global NX-OS transmission intervals:

switch(config)# lldp timer 30
switch(config)# lldp holdtime 120

Key Differences Between IOS-XE and NX-OS

  1. Activation Command: IOS-XE uses lldp run, whereas NX-OS uses feature lldp.
  2. Subsystem Architecture: Disabling the feature on NX-OS (no feature lldp) completely tears down the daemon and flushes runtime memory, whereas no lldp run on IOS-XE turns off frame processing while retaining interface-level command bindings.
  3. Data Center Bridging (DCBX): NX-OS integrates DCBX over LLDP natively for Priority Flow Control (PFC) and Enhanced Transmission Selection (ETS) in Fibre Channel over Ethernet (FCoE) and RoCE environments.

How to Verify and Troubleshoot LLDP Discovery

Once activated, validating protocol operation and diagnosing discovery failures requires a systematic examination of global statistics, neighbor tables, and interface parameters.

Step 1: Verify Global Operational State

Check whether LLDP is actively processing packets and review configured timers:

Switch# show lldp
Global LLDP Information:
    Status: ACTIVE
    LLDP advertisements are sent every 30 seconds
    LLDP hold time advertised is 120 seconds
    LLDP interface reinitialisation delay is 2 seconds

If the status reads INACTIVE, confirm that lldp run (or feature lldp on NX-OS) was issued in configuration mode.

Step 2: Inspect Connected Neighbors

Display a summary of all directly connected Layer 2 neighbors:

Switch# show lldp neighbors
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID           Local Intf     Hold-time  Capability      Port ID
sw-dist-01.corp     Gi1/0/24       118        B,R             Gi0/1
poly-ccx500-4b21    Gi1/0/10       115        B,T             0004.f24b.2100
srv-kvm-02.infra    Gi1/0/12       109        S               eth0

Total entries displayed: 3

Step 3: Analyze Detailed Neighbor Parameters

To view the advertised IP management address, firmware revision, VLAN assignment, or PoE requirements of a specific peer, use the detail modifier:

Switch# show lldp neighbors GigabitEthernet1/0/10 detail
------------------------------------------------
Local Interface: Gi1/0/10
Chassis id: 0004.f24b.2100
Port id: 0004.f24b.2100
Port Description: Poly CCX 500
System Name: poly-ccx500-4b21
System Description: Polycom CCX 500 Phone; UC Software 7.2.1

Time remaining: 112 seconds
System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses:
    IP: 10.150.2.45
Auto Negotiation - supported, enabled
Physical media capabilities:
    1000baseT(FD)
    100base-TX(FD)
Media Attachment Unit type: 30
Vlan ID: 150

Step 4: Isolate Discovery Failures

If a known physical link is established but no neighbor appears in the table:

  1. Check Directional Flags: Run show lldp interface <interface-id>. Ensure both TX: enabled and RX: enabled are displayed.
  2. Review Error Counters: Execute show lldp errors. Increments in Bad Packet Errors or TLVs Discarded indicate corrupted frames or unsupported vendor TLV lengths.
  3. Inspect Physical Port Type: LLDP frames carry EtherType 0x88CC. Ensure the port is not an unsupported tunnel or encapsulated sub-interface that silently drops standard Layer 2 multicast control frames.
  4. Physical Layer Mismatches: Unidirectional fiber conditions or autonegotiation mismatches prevent bidirectional frame verification, blocking entry registration.

Baseline LLDP Deployment Configuration Templates

For automated deployments via script, configuration manager, or copy-paste implementation across fleet hardware, use the following standardized baselines.

Standard Cisco IOS / IOS-XE Switch Baseline

! ==========================================
! Standard Cisco IOS-XE Baseline LLDP Setup
! ==========================================
configure terminal
!
! Activate protocol globally
lldp run
lldp timer 30
lldp holdtime 120
lldp reinit 2
!
! Define Voice Network Policy for LLDP-MED
network-policy profile 1 voice
 voice vlan 100 cos 5
 voice-signaling vlan 100 cos 3
!
! Apply standard interface parameters
interface range GigabitEthernet1/0/1 - 48
 lldp transmit
 lldp receive
 network-policy 1
 exit
!
end
write memory

Ansible Deployment Task (IOS-XE)

---
- name: Deploy LLDP Configuration on Cisco IOS-XE Switches
  hosts: cisco_switches
  gather_facts: no
  connection: network_cli

  tasks:
    - name: Ensure LLDP is globally enabled
      cisco.ios.ios_lldp_global:
        config:
          state: true
          timer: 30
          holdtime: 120
          reinit: 2
        state: merged

    - name: Enable LLDP on all active access interfaces
      cisco.ios.ios_lldp_interfaces:
        config:
          - name: "{{ item }}"
            transmit: true
            receive: true
        state: merged
      loop:
        - GigabitEthernet1/0/1
        - GigabitEthernet1/0/2
        - GigabitEthernet1/0/3

Cisco IOS-XE LLDP Technical Specification and Command Reference

According to Cisco’s official documentation for enterprise platforms (including the Catalyst 9200, 9300, 9400, 9500, and 9600 series), LLDP operation is subject to the following technical parameters and platform restrictions:

Standardized TLV Architecture

Cisco IOS-XE supports both mandatory base IEEE 802.1AB Type-Length-Value (TLV) attributes and optional organizational TLVs:

  • Mandatory Baseline TLVs (Always Transmitted):
  • Chassis ID TLV (Subtype 4: MAC Address)
  • Port ID TLV (Subtype 3: MAC Address or Subtype 5: Interface Name)
  • Time-to-Live (TTL) TLV
  • End of LLDPDU TLV
  • Optional IEEE 802.1 / 802.3 TLVs:
  • System Name and System Description
  • System Capabilities
  • Management Address (advertises the primary routed loopback or switch virtual interface [SVI])
  • MAC/PHY Configuration/Status (negotiation state and duplex)
  • Link Aggregation (identifies physical membership inside a Port-Channel)
  • Maximum Frame Size (MTU validation)

Platform Limitations and Caveats

  1. Virtual Stack Architecture: On StackWise and StackWise Virtual (SV) clusters, LLDP uses the MAC address of the active switch chassis as the Chassis ID across all stack members.
  2. Channelized and Logical Interfaces: LLDP operates on physical Layer 2 and Layer 3 interfaces. It is not supported directly on logical VLAN interfaces (SVIs), tunnel interfaces, or loopback interfaces (though loopback IPs may be advertised within the Management Address TLV).
  3. Neighbor Table Capacity: Catalyst 9000 switches support a platform-dependent ceiling for neighbor caching (typically 2,048 entries per switch). When the table saturates, newly discovered neighbors are dropped until existing entries age out.
  4. Documentation Navigation: Authoritative command syntax, configuration updates, and hardware-specific caveats are maintained on Cisco.com under Products > Switches > Catalyst 9000 Series Switches > Configuration Guides > Layer 2 Configuration Guide (Catalyst 9000 Switches).

Conclusion

Enabling LLDP establishes standardized Layer 2 visibility across your entire network infrastructure, eliminating the operational blind spots created by single-vendor discovery protocols. By executing lldp run on Cisco Catalyst switches or feature lldp on Cisco Nexus platforms, configuring LLDP-MED profiles for voice endpoints, and validating associations using show lldp neighbors, administrators can maintain consistent automated endpoint onboarding, simplified multi-vendor troubleshooting, and accurate physical topology mapping.

Please follow and like us:
Last modified: November 3, 2026

Author

Comments

Write a Reply or Comment

Your email address will not be published.