N4N063: Link Layer Discovery Protocol
Link Layer Discovery Protocol (LLDP) is a standardized Layer 2 protocol that enables network devices to announce information about themselves to directly connected neighbors, facilitating network topology discovery and device identification in multi-vendor environments. The protocol uses Ethernet frames with special multicast destination MAC addresses to ensure frames don't propagate beyond immediate neighbors, and includes mandatory TLVs (Type-Length-Values) like chassis ID, port ID, and TTL alongside optional ones for extended information.
Summary
Ethan Banks and Holly Podibilak discuss LLDP, a Layer 2 discovery protocol defined in IEEE 802.1ab standard (with extensions via ANSI TIA 1057 for LLDP-MED). LLDP operates as a non-interactive advertisement protocol where devices announce information about themselves at configurable intervals (default 30 seconds, range 5 to 32,768 seconds) to help network engineers map topology and identify connected devices without manual inspection. The protocol uses Time-To-Live (TTL) values to manage how long information is retained; the default TTL is calculated by multiplying the message transmission interval by a hold-time multiplier of four, with a hard maximum of 65,535 seconds.
The technical implementation uses Ethernet frames with a source MAC from the sending device and a destination MAC from a special range of MAC Bridge Filtered Group Addresses (0180C2 followed by specific values ending in 00-0E). These multicast addresses signal to receiving switches that frames should never be forwarded further—ensuring LLDP remains local to the direct link. The payload consists of Type-Length-Value (TLV) fields that carry structured information; mandatory TLVs include chassis ID, port ID, and TTL, while optional TLVs can include port description, system name, management address, system capabilities, and proprietary vendor-specific information via Type 127 TLVs.
The hosts discusses practical security considerations: LLDP frames are unencrypted and contain valuable infrastructure information including device names, model numbers, management IP addresses, and capabilities. This makes LLDP a potential security risk on edge ports where unknown devices might connect. Best practices include disabling LLDP on unused ports entirely, configuring ports as send-only or receive-only rather than bidirectional, and avoiding LLDP on ports where untrusted devices might connect. The protocol does not propagate over wireless; access points connected via backhaul will exchange LLDP frames, but wireless clients won't receive LLDP over-the-air because the protocol provides no value for mobile, transient connections and would waste limited airtime.
Historically, numerous vendors created proprietary discovery protocols (Cisco Discovery Protocol/CDP, MikroTik Neighbor Discovery Protocol/MNDP, Extreme Discovery Protocol/EDP, Alcatel Mapping Adjacency Protocol/AMAP) before LLDP became the industry standard. While CDP and MNDP remain in limited use, LLDP's standardized, vendor-neutral approach has become dominant. The hosts note that CDP provides some capabilities LLDP lacks, particularly detecting native VLAN mismatches on trunk ports, but most modern deployments favor LLDP for multi-vendor interoperability. Tools like Wireshark can decode LLDP frames and parse all TLVs, providing network engineers with visibility into device relationships and infrastructure details.
About this episode
Ethan and Holly tackle the Link Layer Discovery Protocol (LLDP). They explain how this protocol helps network engineers map network topologies and validate wiring. They also discuss how LLDP devices use frames to send information, mandatory and optional type length values (TLVs), and why security on edge ports remains critical. Episode Links: Watch this episode<a class="excerpt-read-more" href="https://packetpushers.net/podcasts/n-is-for-networking/n4n063-link-layer-discovery-protocol/" title="ReadN4N063: Link Layer Discovery Protocol">... Read more »</a>
Key Insights
- LLDP is a non-interactive advertisement protocol that sends information about a device on a regular interval without establishing neighbor relationships or receiving acknowledgments from receivers.
- LLDP uses special multicast destination MAC addresses from the MAC Bridge Filtered Group range (0180C2 followed by specific values) that signal to switches the frame must not be forwarded beyond the immediate hop.
- The default Time-To-Live for LLDP information is 120 seconds, calculated by multiplying the default 30-second transmission interval by a hold-time multiplier of four, with frames overwriting previous data rather than accumulating.
- LLDP does not propagate over wireless links to clients because wireless airtime is a precious resource and LLDP provides no value for transient, mobile devices that constantly join and leave networks.
- Unencrypted LLDP frames leak sensitive infrastructure information including device names, model numbers, management IP addresses, and capabilities, creating security risks if enabled on edge ports where untrusted devices might connect.
- Proprietary discovery protocols like CDP, MNDP, and EDP from individual vendors cannot interoperate with each other, whereas standardized LLDP enables multi-vendor environments to share device information transparently.
- LLDP frames consist of mandatory TLVs (chassis ID, port ID, TTL) and optional TLVs (port description, system name, management address, capabilities), with vendor-specific information encoded as Type 127 organizationally-specific TLVs.
- Cisco Discovery Protocol provides capabilities LLDP lacks, such as detecting native VLAN mismatches on trunk ports, which may justify its continued use in some Cisco-dominant environments despite LLDP's superior interoperability.
Topics
Transcript
. On today's N is for Networking, Holly and I will break down the Link Layer Discovery Protocol for you. I'm Ethan Banks with Holly, and Holly is Holly Podmilak. You can follow us on LinkedIn and chat with us on the Packet Pushers Community Slack group in the N is for Networking pod channel. N is for Networking is part of the Packet Pushers Network of Fine Technology podcast for IT professionals. If you like this show, check out packetpushers.net to discover many other pods that Packet Pushers offers, like Heavy Networking and Life and Uptime and Network Break and Day2DevOps and Network Automation Nerds. And I'm not going to tell you all of them. You just need to…
Full transcript available for MurmurCast members
Sign Up to AccessMore from The Everything Feed - All Packet Pushers Pods
IPB207: Flying Blind: Monitoring Might Not See IPv6
The IPv6 Buzz hosts discuss critical gaps in IPv6 monitoring across enterprise networks, highlighting that many monitoring platforms lack IPv6 awareness, vendor parity, and advanced analytical capabilities. They emphasize that while basic IPv6 data ingestion has improved, sophisticated features like cross-protocol event correlation, extension header analysis, and device identity tracking remain significant industry challenges.
TCG083: Superintelligence for Everyone: Who Actually Holds the Power?
Three technology experts discuss Mark Zuckerberg's manifesto on distributed superintelligence, examining whether his promises of universal access and individual empowerment align with infrastructure realities. They conclude that while decentralized AI is theoretically safer than centralized control, the manifesto fails to account for human complexity, existing inequalities, and the enormous capital requirements that will likely concentrate power rather than distribute it.
NAN130: Network Automation Forum: From Simple Survey to Global Community
Network Automation Forum co-founders Scott Robon and Chris Grunman discuss how their community grew from a simple survey about network automation adoption into a global series of conferences with 600+ attendees across multiple continents. They emphasize maintaining the organization's vendor-neutral, practitioner-led ethos while managing rapid growth and evolving industry trends like MCPs and AI agents.
HS141: EA vs AI
Jon and Jonna debate whether Enterprise Architecture (EA) and AI can coexist, concluding that EA remains essential for governing AI systems. They argue that while AI is inherently non-deterministic and boundary-crossing, organizations need architectural frameworks to define data governance, security policies, and business alignment—especially for high-stakes applications.
PP124: How Coruna, DarkSword, and Other Exploits Slice Up Apple iPhones
The podcast discusses sophisticated iOS exploit frameworks Karuna and DarkSword that have evolved from state-sponsored tools into widely-available threats used by criminals. These exploits achieve kernel-level access, dump encrypted keychains, and persist across reboots, requiring fundamental changes to how enterprises approach mobile security beyond traditional patching and lockdown mode.