3.3 网络拓扑发现：LLDP 报文视角
3.3 网络拓扑发现：LLDP 报文视角
本节摘要：OpenFlow 协议本身没有"拓扑发现"消息，控制器的全局视图完全靠自己搭建：向每台交换机的每个端口注入 LLDP 报文，再从别的端口的 Packet-In 里收集答案，两两对照织出链路图。本节拆解这套机制的报文细节、为什么非用 LLDP 不可、以及链路翻动时的 Port-Status 上报。
学习目标
阅读完本节，你应当能够：
- 描述 LLDP 主动发现的完整消息闭环
- 解释为什么不能用广播帧（如 ARP）做拓扑发现
- 说出链路 up/down 在报文层面的表现
问题：控制器是天生的近视眼
握手之后控制器只知道"有哪些交换机、有哪些端口"（Features-Reply 给的清单），但不知道交换机之间谁连谁。要做最短路路由，这张"端口邻接图"是刚需。协议没给，控制器就自己造——用的还是你已经认识的 Packet-Out 和 Packet-In。
拓扑发现的报文闭环
LLDP（链路层发现协议）帧是纯本地协议帧：目标 MAC 固定组播地址 01:80:c2:00:00:0e，eth_type 0x88cc，不会被转发，寿命一跳。帧体里携带 TLV：发送方 DPID、发送端口、TTL。控制器伪造这些 TLV，让每台交换机每个端口都周期性发出；对端交换机的流表里有一条专门的规则（匹配 eth_type=0x88cc → CONTROLLER），于是每份 LLDP 都以 Packet-In 的形式回到控制器手里。
拼接逻辑一句话：发方的 (DPID, 端口) 与收方的 (DPID, 端口) 配成一对，就是一条有向链路；双向都齐，链路健康。
为什么必须是 LLDP
用 ARP 或普通广播泛洪探测不行吗？不行，原因有二：
- 广播帧会沿全网泛洪再回到发送口，控制器看到的是"处处都在"，无法区分真实下一跳与回声
- 广播打扰主机（每台虚机都收到无关心跳），LLDP 一跳即亡，拓扑信息不泄漏给终端
在实验台观察这条规则（simple_switch_13 之外的拓扑应用会装它）：
sudo ovs-ofctl -O OpenFlow13 dump-flows s1 | findstr 88cc # 输出应含：dl_type=0x88cc actions=CONTROLLER:65535
链路翻动的报文表现
物理链路断开时，交换机立刻发 Port-Status（Asynchronous 类）：reason=DELETE、携带端口与队列统计。控制器把邻接表里对应的边标记失效，重算受影响路径的流表（删旧 Flow-Mod 下发新规则）。链路恢复则 reason=ADD。整个收敛过程在抓包里就是"一帧 Port-Status + 一串 Flow-Mod"，解剖起来非常干净。
⚠️ 常见坑：LLDP 周期设得比链路抖动还慢，拓扑库长期滞后。工程上发现周期通常秒级，且要配合端口翻动抑制（debounce）防止抖动风暴。
解剖实例：一条 LLDP 帧的逐字段拆解
把实验台上抓到的 LLDP Packet-In 拆开，每个字段都在讲拓扑的故事：
Ethernet dst: 01:80:c2:00:00:0e <- LLDP 专用组播 MAC，交换机不转发 src: 3a:1c:...:f2 <- 发送端口的 MAC type: 0x88cc <- LLDP ethertype LLDP Chassis ID TLV (type=1): 00:00:00:00:00:01 <- 发方 DPID（OUI 扩展） Port ID TLV (type=2): 2 <- 发方端口号 TTL TLV (type=3): 120 End TLV (type=0)
控制器收到这条上送后做的拼图极简单：Packet-In 的 in_port 字段告诉自己"这条 LLDP 从 s1 的 3 号口进来"，帧体里的 Chassis ID 加 Port ID 告诉自己"它由 s2 的 2 号口发出"，两个三元组合并成一条链路记录。两台交换机之间若无直连链路，LLDP 一跳即死，对端永远收不到——这个"收不到"本身就是拓扑信息，控制器靠周期重发加超时清理来区分"没链路"与"链路刚断"。
为什么不用别的：候选机制的排除法
正文从正面论证了 LLDP 的资格，排除法同样有教学价值。ARP 可达性探测要求主机响应，交换机之间没有 IP 标配地址，租户环境里 ARP 广播还会跨隧道泄漏；ICMP 探测同病。CDP 是思科私有，多厂商网络不可用。自制 ethertype 探测帧理论上可行，但中间若串有传统交换机，未知 ethertype 的默认处理（丢弃或泛洪）不受你控制，泛洪会让探测帧出现在不该出现的端口上，拓扑就被"画歪"了。LLDP 的组播 MAC 在 01:80:c2:00:00:0x 这一保留段，任何合规交换机都不转发它——这个"不转发"是 IEEE 替你做好的隔离保证。SDN 里借用它，等于免费继承了全网交换机的默认静默，这正是排他性的来源。顺带一提，控制器自己也不能免检：LLDP 周期要与 Port-Status 事件、链路老化超时三者对齐，周期过短白白消耗 Packet-In 配额，过长则链路翻动的感知滞后于真实收敛。
还有一个部署级细节：LLDP 周期与链路老化窗口的比例关系决定误报率。周期 5 秒、老化 3 个周期未收到即判死，链路感知延迟就是 15 秒上下；把周期压到 1 秒，感知变快，但每台交换机每端口每秒一条 Packet-In，千端口规模就是每秒千条上送，控制器与通道都吃不消。真实控制器的默认值多在两者之间取舍，调优时的判断依据是业务对收敛时间的要求，而不是越快越好。同时要把 Port-Status 事件与 LLDP 老化看作两套互补的证据源：前者是交换机的主动汇报（快、但只覆盖本地端口状态），后者是端到端的活性确认（慢、但能发现中间链路的静默故障），只依赖其一的拓扑模块都有盲区。
本节要点回顾
- 机制：Packet-Out 注入 LLDP → 对端 Packet-In 回收 → 端口对拼链路
- LLDP 特性：组播 MAC 01:80:c2:00:00:0e、eth_type 0x88cc、一跳寿命
- 匹配规则：交换机上有一条 88cc → CONTROLLER 的专用规则
- 翻动感知：Port-Status ADD/DELETE 驱动重收敛
基础解剖到此完成——下一章进入高级特性：组表、Meter、端口与队列。