网络以太网之(3)LLDP协议

网络以太网之(3)LLDP协议

Author: Once Day Date: 2026年4月15日

一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦...

漫漫长路，有人对你微笑过嘛...

全系列文章可参考专栏: 通信网络技术_Once-Day的博客-CSDN博客。

参考文章:

LLDP协议基础 - 知乎

LLDP帧 - IP报文格式大全 - 华为

什么是LLDP? 为什么需要LLDP？ - 华为

链路层链路发现协议（LLDP）讲解_lldp协议-CSDN博客

探究LLDP协议 - bfhyqy - 博客园

报文学习四（LLDP协议）「建议收藏」-腾讯云开发者社区-腾讯云

LLDP技术介绍-新华三集团-H3C

LLDP 基本原理 - 技术栈

文章目录

网络以太网之(3)LLDP协议
- - - [1. LLDP协议基础介绍](#1. LLDP协议基础介绍)
    - - [1.1 概述](#1.1 概述)
      - [1.2 应用场景](#1.2 应用场景)
      - [1.3 RFC文档概述](#1.3 RFC文档概述)
    - [2. 报文格式](#2. 报文格式)
    - - [2.1 LLDP帧](#2.1 LLDP帧)
      - [2.2 LLDPDU格式](#2.2 LLDPDU格式)
    - [3. 工作流程](#3. 工作流程)
    - - [3.1 基础工作流程](#3.1 基础工作流程)
      - [3.2 LLDP目的地址](#3.2 LLDP目的地址)
    - [4. 实践测试](#4. 实践测试)

1. LLDP协议基础介绍

1.1 概述

LLDP（Link Layer Discovery Protocol，链路层发现协议）是 IEEE 802.1AB 标准中定义的一种第二层发现协议，用于网络设备之间的自动识别与拓扑发现。该协议允许直连设备周期性地交换本端的能力信息、管理地址、设备标识、接口标识等关键属性，并将这些信息组织为标准的 LLDPDU（LLDP Data Unit）进行传输。邻居设备在收到报文后，会以 MIB（Management Information Base，管理信息库）的形式存储这些数据，供 NMS（Network Management System，网络管理系统）统一查询，从而帮助管理员准确掌握链路连接关系与通信状况。

LLDP 的一个核心设计目标是厂商无关性。在此协议出现之前，各厂商普遍采用私有的邻居发现协议（如 Cisco 的 CDP），导致异构网络中设备之间无法互相识别。LLDP 作为开放标准，使不同厂商的交换机、路由器、IP 电话等设备能够统一使用同一套发现机制进行互操作。同时，协议本身具备良好的扩展能力，允许通过定义新的 TLV（Type-Length-Value）结构来承载额外信息，例如 802.1 VLAN 信息、802.3 链路聚合参数，以及 VoIP 相关的媒体策略等。

从运行模型来看，LLDP 协议在每台设备上以 LLDP Agent 的形式运行，且以端口为基本单位------同一设备的不同端口可以独立配置不同的行为模式。LLDP 在网络层面上是无状态的，它仅周期性地发送通告报文，不存在请求-应答式的逻辑交互。因此，协议的部署可以是单向的，每个端口的收发行为通过 Admin Status 参数控制，共有以下四种模式：

Admin Status	发送	接收	说明
`TxRx`	✓	✓	既发送又接收，最常用的模式
`TxOnly`	✓	✗	仅发送本端信息，不接收邻居信息
`RxOnly`	✗	✓	仅接收邻居信息，不对外通告
`Disabled`	✗	✗	完全关闭 LLDP 功能

这种灵活的单向部署机制意味着"A 能发现 B，但 B 不能发现 A"的场景是完全合理的，具体取决于两端各自的 Admin Status 配置。

封装有 LLDPDU 的报文称为 LLDP 报文，其在数据链路层的封装格式支持两种：Ethernet II 和 802.3 LLC SNAP（Subnetwork Access Protocol）。在实际网络中，Ethernet II 封装更为常见，其 EtherType 字段值为 0x88CC，目的 MAC 地址使用 IEEE 预留的组播地址（如 01:80:C2:00:00:0E）。由于 LLDP 报文以组播方式发送且 TTL 限定在链路本地范围，交换机不会对其进行转发，因此协议的作用域严格限制在直连的两个端口之间。

尽管 LLDP 能显著提升网络的透明度与可管理性，但也需要注意其潜在的安全风险。由于 LLDP 报文以明文形式携带设备型号、操作系统版本、管理 IP 等敏感信息，攻击者可能利用这些数据进行针对性的渗透。因此在实际部署中，通常建议仅在受信任的内部互联端口上启用 LLDP，而在面向外部或不可控设备的接口上将其设置为 Disabled，以降低信息泄露的风险。

1.2 应用场景

在传统网络管理体系中，管理系统通常只能基于三层路由信息构建网络拓扑，对于二层链路的实际连接关系、端口对应情况以及设备间是否存在配置冲突等问题，往往缺乏有效的感知手段。随着网络规模持续增长，设备类型日趋多样，仅依靠人工记录和维护物理拓扑已难以为继。LLDP 正是在这一背景下被引入的标准化二层信息交互协议，为网络的自动化管理和故障定位提供了基础能力。

LLDP 最直接的应用是网络拓扑自动发现。网管系统（NMS）通过采集各设备 LLDP MIB 中存储的邻居信息，能够自动绘制出从客户端、交换机、路由器到应用服务器之间的完整二层路径。这一能力在数据中心环境中尤为重要------面对成百上千台服务器与 ToR 交换机的互联关系，手动维护接线表的方式既低效又容易出错，而 LLDP 可以实时、准确地反映物理连接状态。

在故障诊断方面，LLDP 提供的邻居信息可以帮助管理员快速判断链路是否正常建立、对端设备是否在线、接口是否发生了错接或误连。例如，当某台交换机的上联端口突然丢失了邻居条目，通常意味着物理链路中断或对端设备异常，管理员可以据此缩小排查范围。结合 LLDP 报文中携带的系统描述和端口描述字段，还能进一步检测设备间的配置冲突，例如 VLAN 不匹配、双工模式不一致等问题。

LLDP 在自动化配置场景中同样发挥着重要作用。以 VoIP 部署为例，IP 电话接入交换机后，交换机可通过 LLDP-MED（Media Endpoint Discovery）扩展协议向电话下发 Voice VLAN、QoS 策略等参数，实现即插即用，无需逐台手动配置。类似地，在网络访问控制（NAC）体系中，接入层设备可借助 LLDP 获取终端的设备类型与能力信息，作为准入策略判定的辅助依据。

除上述典型场景外，LLDP 在工业网络与安全审计领域也有广泛的应用，其主要场景可归纳如下：

应用场景	核心作用
拓扑发现与可视化	自动构建二层物理拓扑，替代人工接线记录
故障诊断与定位	检测链路中断、错接、配置冲突等异常
自动化设备配置	通过 `LLDP-MED` 实现终端的即插即用
数据中心资产管理	实时追踪服务器与交换机的端口对应关系
安全审计与准入控制	识别接入设备身份，辅助 `NAC` 策略决策
工业网络监控	在 `ICS/SCADA` 环境中监测现场设备互联状态

企业用户通过网管系统对支持 LLDP 的设备进行链路状态的持续监控，能够在网络故障发生时快速定位问题节点和问题链路，显著缩短平均修复时间（MTTR）。对于大规模组网环境而言，LLDP 已经成为网络运维体系中不可或缺的基础协议之一。

1.3 RFC文档概述

需要特别说明的是，LLDP 并非由 IETF 定义，而是一项 IEEE 标准，其核心规范文档为 IEEE 802.1AB。因此，与 LLDP 直接相关的技术文档主要来源于 IEEE 和 ANSI/TIA 标准体系，而非传统意义上的 RFC。不过，在 LLDP 的 MIB 定义、管理地址引用等方面，仍有部分 IETF RFC 文档与之存在关联。以下对这些标准文档做一个整体梳理。

IEEE 802.1AB 是 LLDP 协议的核心规范，其正式名称为"Station and Media Access Control Connectivity Discovery"。该标准自 2005 年首次发布以来，经历了多次修订，每个版本在 TLV 定义、MIB 结构和协议细节方面均有不同程度的完善。LLDP 的基础 MIB（LLDP-MIB）也直接定义在该标准内部，而非以独立 RFC 的形式发布。

文档编号	名称 / 描述
`IEEE 802.1AB-2005`	`LLDP` 协议的首个正式版本，定义了基本帧格式、必选 TLV 集合及协议状态机
`IEEE 802.1AB-2009`	第一次修订版，完善了 MIB 结构，增强了与 `802.1Q` 的协同定义
`IEEE 802.1AB-2016`	当前最新修订版，进一步更新了 TLV 扩展机制和一致性要求
`IEEE 802.1Q`	桥接与桥接网络标准，其中定义了 `802.1` 组织特定 TLV（如 Port VLAN ID、VLAN Name 等）
`IEEE 802.3`	以太网标准，定义了 `802.3` 组织特定 TLV（如 MAC/PHY Configuration、Link Aggregation、Maximum Frame Size 等）
`ANSI/TIA-1057`	`LLDP-MED`（Media Endpoint Discovery）标准，面向 VoIP 终端和媒体设备的扩展协议，定义了网络策略、位置标识、PoE 管理等专用 TLV

在 IETF 体系中，虽然没有直接规范 LLDP 协议本身的 RFC，但部分文档为 LLDP 的实现和管理提供了支撑。RFC 2922（Physical Topology MIB）定义了物理拓扑发现相关的管理信息库，可视为 LLDP 拓扑发现能力的前序工作。此外，LLDP 报文中管理地址 TLV 所引用的地址族编号遵循 IANA 的地址族定义，这部分内容记录在 RFC 3232 等文档中。

对于实际开发和部署而言，IEEE 802.1AB-2016 是最主要的参考文档，建议作为首选阅读材料。若涉及 VLAN 相关的 TLV 扩展，则需结合 IEEE 802.1Q 中对应的附录章节；若涉及 VoIP 场景下的自动化配置，则应重点参考 ANSI/TIA-1057 中关于 LLDP-MED 的定义。这些文档共同构成了 LLDP 协议族的完整技术规范体系。

2. 报文格式

2.1 LLDP帧

封装有 LLDPDU 的报文称为 LLDP 帧，其在数据链路层的封装格式支持两种：Ethernet II 和 SNAP（Subnetwork Access Protocol，子网访问协议）。两种封装方式承载的 LLDPDU 内容完全一致，区别仅在于二层帧头的组织形式。在当前以太网环境中，绝大多数设备默认采用 Ethernet II 封装，SNAP 封装主要用于兼容部分早期的 802.3 网络设备。

LLDP 帧的目的 MAC 地址使用 IEEE 预留的组播地址，不同的组播地址对应不同的传播范围。IEEE 802.1AB 定义了三个可选的目的 MAC 地址：

目的 MAC 地址	作用范围	说明
`01:80:C2:00:00:0E`	Nearest Bridge	最常用，报文到达最近的桥设备即停止转发
`01:80:C2:00:00:03`	Nearest Non-TPMR Bridge	可穿越两端口 MAC 中继（TPMR），到达最近的非 TPMR 桥
`01:80:C2:00:00:00`	Nearest Customer Bridge	用于运营商网络场景，到达最近的客户桥设备

这三个地址均属于 IEEE 802.1D 中定义的链路本地保留组播地址段（01:80:C2:00:00:00 ~ 01:80:C2:00:00:0F），符合规范的交换机不会对携带这些目的地址的帧进行常规转发，从而确保 LLDP 报文的作用域严格限制在直连链路范围内。源 MAC 地址则为发送端口自身的物理 MAC 地址。

Ethernet II 封装是最常见的格式，其帧结构相对简洁，EtherType 字段固定为 0x88CC，紧随其后即为 LLDPDU 数据。整体结构如下：

yacas 复制代码

+------------------+------------------+------------+-----------+-------+
| Destination MAC  |   Source MAC     | EtherType  | LLDPDU    |  FCS  |
|    (6 Bytes)     |    (6 Bytes)     | (2 Bytes)  | (Variable)| ( 4 ) |
|01:80:C2:00:00:0E |  Port MAC Addr   |  0x88CC    |  ......   |       |
+------------------+------------------+------------+-----------+-------+

SNAP 封装则在 802.3 帧头基础上叠加了 LLC（Logical Link Control）和 SNAP 头部。其中 LLC 头部的 DSAP 和 SSAP 均为 0xAA，Control 字段为 0x03，表示使用 SNAP 扩展；SNAP 头部的 OUI（Organizationally Unique Identifier）为 0x000000，Type 字段同样为 0x88CC。

两种封装格式的关键区别在于：Ethernet II 通过 EtherType 字段直接标识上层协议类型，而 SNAP 封装需要额外 8 个字节（3 字节 LLC + 5 字节 SNAP）来达到相同目的。这意味着在相同 MTU 限制下，SNAP 封装可承载的 LLDPDU 有效载荷略小。实际部署时，除非网络中存在仅支持 802.3 帧格式的老旧设备，否则推荐统一使用 Ethernet II 封装以保持最大兼容性和效率。

字段	长度	含义
DMAC	6字节	LLDP帧的目的MAC地址。
SMAC	6字节	源MAC地址，为端口MAC地址或设备桥MAC地址（如果有端口地址则使用端口MAC地址，否则使用设备桥MAC地址）。
Type	2或8字节	协议类型：如果是Ethernet II封装，值为0x88CC。如果是802.3 LLC SNAP封装，值为0xAAAA-0300-0000-88CC。
Data	变长	数据字段，标识帧的负载，为LLDPDU。 LLDPDU就是封装在LLDP报文数据部分的数据单元。在组成LLDPDU之前，设备先将本地信息封装成TLV格式，再由若干个TLV组合成一个LLDPDU封装在LLDP报文的数据部分进行传送。
FCS	4字节	帧校验序列FCS（Frame Check Sequence）是为接收网卡提供判断是否传输错误的一种方法，如果发现错误，丢弃此帧。 FCS只是通用叫法，具体的FCS还可以细分多种校验方法。在以太帧中，FCS通常采用循环冗余码校验CRC（Cyclical Redundancy Check）。

2.2 LLDPDU格式

LLDPDU 是 LLDP 帧中实际承载设备信息的数据单元，其内部由多个 TLV（Type-Length-Value）结构顺序排列组成。每个 TLV 包含三个字段：Type 占 7 bit，标识 TLV 的类型编号；Length 占 9 bit，指示 Value 字段的字节长度；Value 为变长字段，承载具体的信息内容。这种统一的编码结构使得接收端可以逐个解析 TLV，遇到不识别的类型时也能根据 Length 字段安全跳过，保证了协议的前向兼容性。

yacas 复制代码

|<-  7bit ->|<- 9bit ->|<- 0~511 Bytes ->|
+-----------+----------+-----------------+
|   Type    |  Length  |     Value       |
+-----------+----------+-----------------+

LLDPDU 对 TLV 的排列顺序有严格要求。报文必须以 Chassis ID TLV、Port ID TLV、TTL TLV 这三个必选 TLV 依次开头，中间部分为若干可选 TLV，末尾以 End of LLDPDU TLV（Type = 0，Length = 0）作为结束标记。缺少任何一个必选 TLV 的报文将被视为非法报文而丢弃。整体布局如下：

yacas 复制代码

+------------+-----------+-----------+---------------------+-----------------+
| Chassis ID |   Port ID |    TTL    |  Optional TLVs ...  | End of LLDPDU   |
|    TLV     |    TLV    |    TLV    |  (0 or more)        |    TLV          |
| (Mandatory)|(Mandatory)|(Mandatory)|                     | (Type=0,Len=0)  |
+------------+-----------+-----------+---------------------+-----------------+

IEEE 802.1AB 将所有 TLV 划分为三大类别：基本 TLV （Basic TLV）、组织特定 TLV （Organizationally Specific TLV）以及保留 TLV。基本 TLV 由标准直接定义，涵盖了设备发现所需的核心信息，其类型编号与用途如下表所示：

Type	TLV 名称	是否必选	说明
0	End of LLDPDU	必选	标识 LLDPDU 结束，Length 和 Value 均为 0
1	Chassis ID	必选	设备标识，可为 MAC 地址、网络地址、设备名称等
2	Port ID	必选	端口标识，可为接口名称、MAC 地址等
3	Time To Live	必选	邻居信息老化时间，单位为秒，为 0 时表示立即删除
4	Port Description	可选	端口描述字符串，通常对应 `ifDescr`
5	System Name	可选	系统名称，通常对应设备主机名
6	System Description	可选	系统描述，包含设备型号、OS 版本等
7	System Capabilities	可选	系统能力，标识设备支持的功能（如桥接、路由等）
8	Management Address	可选	管理地址，用于 NMS 管理设备的网络地址

组织特定 TLV 的 Type 值统一为 127，其 Value 字段的前 3 个字节为 OUI（Organizationally Unique Identifier），后 1 个字节为该组织自定义的子类型编号，再之后才是实际数据。通过这种机制，不同的标准组织和厂商可以在不冲突的前提下自行扩展 TLV。常见的组织特定 TLV 来源包括：IEEE 802.1（OUI: 00-80-C2）定义的 VLAN 相关 TLV、IEEE 802.3（OUI: 00-12-0F）定义的以太网物理层 TLV，以及 TIA（OUI: 00-12-BB）定义的 LLDP-MED 相关 TLV。

yacas 复制代码

组织特定 TLV (Type = 127) 的 Value 结构：
+----------+----------+---------------------+
|   OUI    | Subtype  |   Organization      |
| (3 Bytes)| (1 Byte) |  Defined Info       |
+----------+----------+---------------------+

保留 TLV 对应 Type 值 9 ~ 126 的范围，这些编号当前尚未被标准使用，留作未来扩展。符合规范的实现在接收到保留类型的 TLV 时，应当根据 Length 字段跳过该 TLV 而不做处理，既不丢弃整个报文，也不尝试解析其内容。这一设计与组织特定 TLV 的扩展机制共同保证了 LLDP 协议在演进过程中的平滑兼容。

3. 工作流程

3.1 基础工作流程

LLDP 的工作模式属于单向通告机制，协议本身不存在请求-应答交互，每台设备独立地将自身信息封装为 LLDPDU 并周期性地从各个使能端口发出。接收端解析报文后，将邻居信息存储在本地 MIB 库中，并依据 TTL 值进行老化管理。整个协议的工作流程可以划分为信息封装与发送、信息接收与更新、老化与维护三个主要阶段。
设备 B 设备 A 设备 B 设备 A 封装本地信息为 LLDPDU 解析 TLV，存储至 LLDP MIB 封装本地信息为 LLDPDU 解析 TLV，存储至 LLDP MIB 双方独立周期性发送，互不依赖 LLDP 帧 (Chassis ID, Port ID, TTL, ...) LLDP 帧 (Chassis ID, Port ID, TTL, ...)

在信息封装阶段，设备从本地系统中采集需要通告的信息，包括设备标识（Chassis ID）、端口标识（Port ID）、系统名称、系统描述、管理地址、端口能力等，按照 TLV 格式逐一编码后组装为一个完整的 LLDPDU，再封装到 Ethernet II 或 SNAP 帧中发出。每个使能端口独立维护自己的发送内容，因此同一台设备的不同端口发出的 Port ID TLV 是不同的，但 Chassis ID TLV 和 System Name TLV 等设备级信息保持一致。

报文发送机制遵循定时器驱动的模型。设备为每个使能端口维护一个发送定时器，默认周期为 30 秒（txInterval），定时器到期即触发一次 LLDPDU 发送。此外，当本地信息发生变化（如端口状态变更、系统名称修改等）时，设备会立即触发一次快速发送，但为避免突发大量报文，标准引入了 txDelay 参数（默认 2 秒）作为两次发送之间的最小间隔。当端口 Down 或 LLDP 功能被关闭时，设备会发送一个 TTL 为 0 的 LLDPDU，通知对端立即删除相应的邻居条目。

在接收侧，设备对收到的 LLDP 帧进行合法性校验，包括检查必选 TLV 是否完整、TLV 顺序是否正确等。校验通过后，以 Chassis ID + Port ID 的组合作为邻居的唯一标识，在本地 LLDP MIB 中查找对应条目。若该邻居已存在，则更新信息并重置老化定时器；若为新邻居，则创建新条目。老化时间由对端报文中 TTL TLV 的值决定，通常计算公式为 TTL = txInterval × txHold，其中 txHold 默认为 4，因此默认老化时间为 120 秒。当老化定时器到期且未收到新的报文时，对应的邻居条目将被自动删除。

关键参数	默认值	说明
`txInterval`	30 秒	周期性发送 LLDPDU 的时间间隔
`txHold`	4	TTL 乘数因子，TTL = txInterval × txHold
`txDelay`	2 秒	连续两次发送之间的最小间隔
`reinitDelay`	2 秒	端口 LLDP 重新初始化的延迟时间
`msgFastTx`	1 秒	快速发送模式下的发送间隔

网管系统（NMS）可通过 SNMP 协议读取各设备 LLDP MIB 中的本地信息表和远端邻居信息表，从而汇总全网的邻居关系，自动构建出完整的二层物理拓扑。这一过程无需在网络中部署额外的探测报文，完全依赖各设备本地已缓存的 LLDP 邻居数据。对于网络运维而言，管理员既可以直接在设备 CLI 上查看邻居表项以快速确认端口连接关系，也可以通过集中式网管平台实现全网拓扑的可视化展示与变更告警，为故障定位和容量规划提供数据支撑。

3.2 LLDP目的地址

LLDP 帧使用 IEEE 预留的链路本地组播地址作为目的 MAC 地址，这些地址均位于 01-80-C2-00-00-00 ~ 01-80-C2-00-00-0F 的保留地址段内。IEEE 802.1AB 规定了三个可用的目的地址，每个地址对应不同的设备发现范围，其核心差异在于报文能够穿透的网桥类型不同。

目的 MAC 地址	名称	用途
`01-80-C2-00-00-0E`	Nearest Bridge	用于直连链路两端设备的相互发现
`01-80-C2-00-00-03`	Nearest non-TPMR Bridge	用于发现最近的非 TPMR 网桥设备
`01-80-C2-00-00-00`	Nearest Customer Bridge	用于发现对端的 Customer Bridge 设备

理解这三个地址的行为差异，需要先明确 IEEE 802.1 体系中几个网桥术语的含义。TPMR Bridge（Two-Port MAC Relay）是一种仅有两个端口的简化网桥，其功能类似于 IEEE 802.1D 定义的标准网桥，但缺少 STP 等部分特性，常见于小型嵌入式中继设备。Customer Bridge 和 Service Bridge 的概念则源自运营商桥接网络（IEEE 802.1ad，即 QinQ），前者对应用户侧设备，处理 C-VLAN 标签；后者对应运营商侧设备，处理 S-VLAN 标签。

三种目的地址的报文穿透能力可通过以下示意来理解。使用 01-80-C2-00-00-0E（Nearest Bridge）时，报文无法穿透任何类型的网桥，符合 IEEE 802.1D 中对该保留地址段的处理规则------任何收到该帧的桥设备都必须终结处理而不得转发。这是最常用的地址，适用于绝大多数场景下的直连邻居发现。

yacas 复制代码

Nearest Bridge (01-80-C2-00-00-0E):
  [Device A] ---LLDP---> [Any Bridge] × (终结，不转发)

Nearest non-TPMR Bridge (01-80-C2-00-00-03):
  [Device A] ---LLDP---> [TPMR] ---透传---> [non-TPMR Bridge] × (终结)

Nearest Customer Bridge (01-80-C2-00-00-00):
  [Customer A] ---LLDP---> [Service Bridge] ---透传---> [Customer B] × (终结)

当使用 01-80-C2-00-00-03（Nearest non-TPMR Bridge）时，TPMR Bridge 会将该报文视为普通数据帧进行透传，报文直到到达一个非 TPMR 的标准网桥才会被终结。在这种模式下，TPMR 设备对于 LLDP 而言是透明的，不会出现在拓扑发现结果中。这一设计适用于网络路径中存在简单两端口中继设备、而管理员希望发现其后方真正的交换设备的场景。

使用 01-80-C2-00-00-00（Nearest Customer Bridge）时，报文可以穿透运营商侧的 Service Bridge，在整个运营商网络中透明传递，直到到达对端的 Customer Bridge 才被终结。这使得运营商骨干网对用户侧设备的 LLDP 发现过程完全透明，两端的客户设备能够跨越中间的运营商网络建立邻居关系。该地址主要应用于 QinQ 或 PBB（Provider Backbone Bridging）等运营商桥接网络环境中。

在实际部署中，设备的每个端口可以针对这三个目的地址分别独立地配置 LLDP 的工作模式（发送、接收或双向）。三个地址对应的邻居信息也分别存储在不同的 LLDP MIB 表项中，互不干扰。大多数企业网场景仅需使用默认的 01-80-C2-00-00-0E 即可满足需求，只有在涉及运营商网络或特殊中继拓扑时才需要考虑另外两个地址的配置。

4. 实践测试

在 Ubuntu 系统上进行 LLDP 的实践测试，最常用的开源实现为 lldpd，该守护进程由 Vincent Bernat 开发维护，支持 LLDP、CDP、EDP 等多种链路层发现协议，并提供 lldpcli 命令行工具用于配置和查询。通过 apt 即可完成安装：

bash 复制代码

sudo apt update
sudo apt install lldpd
# 安装完成后服务自动启动，可通过 systemctl 查看状态
sudo systemctl status lldpd

安装完成后，lldpd 会自动在所有活跃的物理网卡上启用 LLDP 报文的收发。使用 lldpcli 可以查看本机向外通告的信息以及从邻居接收到的信息。以下为几个常用的查询命令：

bash 复制代码

# 查看本机 LLDP 通告的信息
sudo lldpcli show chassis

# 查看所有接口上发现的邻居信息
sudo lldpcli show neighbors

# 以详细模式查看邻居，包含所有 TLV 信息
sudo lldpcli show neighbors details

# 查看 LLDP 的接口级统计信息
sudo lldpcli show statistics

在实际测试环境中，若手边没有物理交换机，可以利用 veth 虚拟网卡对或 network namespace 模拟两台直连设备。以下示例创建了一对 veth 接口，分别置于不同的命名空间中，各自运行 lldpd 实例来模拟邻居发现过程：

bash 复制代码

# 创建命名空间和 veth 对
sudo ip netns add ns1
sudo ip netns add ns2
sudo ip link add veth1 type veth peer name veth2
sudo ip link set veth1 netns ns1
sudo ip link set veth2 netns ns2

# 启动接口
sudo ip netns exec ns1 ip link set veth1 up
sudo ip netns exec ns2 ip link set veth2 up
sudo ip netns exec ns1 ip link set lo up
sudo ip netns exec ns2 ip link set lo up

# 在两个命名空间中分别启动 lldpd
sudo ip netns exec ns1 lldpd -d &
sudo ip netns exec ns2 lldpd -d &

# 等待约 30 秒后查看邻居
sudo ip netns exec ns1 lldpcli show neighbors

若需要直接观察 LLDP 帧的原始内容，可以使用 tcpdump 对指定接口进行抓包。LLDP 的 EtherType 为 0x88CC，过滤表达式如下：

bash 复制代码

# 抓取 eth0 上的 LLDP 报文并以十六进制显示
sudo tcpdump -i eth0 ether proto 0x88cc -vv

# 也可以保存为 pcap 文件，后续用 Wireshark 分析
sudo tcpdump -i eth0 ether proto 0x88cc -w lldp_capture.pcap

Wireshark 对 LLDP 协议有完善的解码支持，打开捕获的 pcap 文件后，可以在数据包详情面板中清晰地看到每个 TLV 的类型、长度和解析后的值，包括 Chassis ID、Port ID、TTL、System Name、System Description 以及各类组织特定 TLV 的详细内容，这对于排查邻居发现异常或验证 TLV 配置是否生效非常有用。

lldpcli 还支持对本机通告内容进行自定义配置，例如修改系统描述、配置管理地址、调整发送间隔等：

bash 复制代码

# 修改系统描述信息
sudo lldpcli configure system description "Ubuntu Test Node"

# 设置管理地址
sudo lldpcli configure system ip management pattern 192.168.1.100

# 调整发送间隔为 10 秒
sudo lldpcli configure lldp tx-interval 10

# 设置 TTL 乘数为 3（TTL = tx-interval × tx-hold）
sudo lldpcli configure lldp tx-hold 3

# 查看当前运行配置
sudo lldpcli show running-configuration

测试完成后，应及时清理创建的虚拟网络资源，避免残留配置对系统产生影响：

bash 复制代码

# 停止后台 lldpd 进程
sudo killall lldpd

# 删除命名空间（veth 对会自动销毁）
sudo ip netns del ns1
sudo ip netns del ns2

Once Day

也信美人终作土，不堪幽梦太匆匆......
如果这篇文章为您带来了帮助或启发，不妨点个赞👍和关注！
(｡◕‿◕｡)感谢您的阅读与支持~~~