别再死记硬背了！用Wireshark抓包实战，带你一步步‘看’懂STP选举的完整过程
用Wireshark透视STP选举：从报文交互看网络自愈逻辑
第一次在GNS3里抓到STP的BPDU报文时，那些十六进制字段就像天书——直到我注意到每个数字背后都对应着交换机之间的"对话"。这就像观察一群陌生人通过举手投票选出一个领队，而Wireshark就是我们的实时翻译器。本文将用三个真实抓包案例，带你用协议分析师的视角理解STP的选举机制。
1. 实验环境搭建与基础配置
在EVE-NG中搭建包含三台交换机的三角拓扑时，建议先关闭STP功能进行初始配置。这个反直觉的操作能让我们后续观察到完整的选举过程：
# Cisco交换机配置示例 configure terminal spanning-tree vlan 1 priority 32768 # 统一设置初始优先级 interface range gig0/1-2 no spanning-tree vlan 1 # 临时关闭STP end关键配置要点：
- 所有交换机MAC地址前三位设置为
00:0C:12，后三位分别设为3456、3457、3458 - 链路开销值采用短路径开销标准：千兆链路=4，百兆链路=19
- 使用
spanning-tree extend system-id命令确保VLAN信息被包含在BID中
实验提示：在华为设备上需要先执行
stp enable全局命令，思科设备默认开启STP
2. 根桥选举的报文证据
当同时在三台交换机上开启端口镜像并启动Wireshark抓包时，会看到密集的BPDU报文风暴。过滤表达式stp可以快速定位关键报文：
No. Time Source Destination Protocol Info 1 0.000 00:0c:12:34:56 01:80:c2:00:00:00 STP Conf. Root = 32768/00:0c:12:34:56 2 0.002 00:0c:12:34:57 01:80:c2:00:00:00 STP Conf. Root = 32768/00:0c:12:34:57 3 0.004 00:0c:12:34:58 01:80:c2:00:00:00 STP Conf. Root = 32768/00:0c:12:34:58观察前三个报文可以发现：每台交换机初始都宣告自己是根桥（Root = 自己的BID）。真正的选举发生在报文交互过程中：
优先级比较阶段：当交换机收到BPDU时，会依次比较：
- 根桥ID（优先级+MAC）
- 到达根桥的路径开销
- 发送者桥ID
- 发送端口ID
收敛过程：约30秒后，抓包会显示所有BPDU中的根桥ID统一为MAC最小的交换机：
No. Time Source Destination Protocol Info 45 30.123 00:0c:12:34:57 01:80:c2:00:00:00 STP Conf. Root = 32768/00:0c:12:34:56 46 30.125 00:0c:12:34:58 01:80:c2:00:00:00 STP Conf. Root = 32768/00:0c:12:34:563. 根端口选举的路径开销计算
在非根桥交换机上，Wireshark可以清晰展示路径开销的动态计算过程。以交换机S2为例：
- 初始状态：所有端口宣称到达根桥的开销为0
- 学习阶段：收到根桥的BPDU后，端口会加上本地链路开销：
# 路径开销计算伪代码 if received_bpdu.root_bridge_id == self.bridge_id: # 来自根桥的BPDU new_path_cost = port_cost else: # 来自其他交换机的BPDU new_path_cost = received_bpdu.path_cost + port_cost- 选举决策：比较所有端口的累计开销值，选择最小值的端口作为根端口。在Wireshark中可以通过以下字段验证：
| 字段名 | 示例值 | 计算说明 |
|---|---|---|
| Root Path Cost | 19 | 从该端口到根桥的总开销 |
| Designated Bridge ID | 32768.000C123456 | 当前网段的指定桥 |
| Port ID | 0x8003 | 高字节为优先级，低字节为端口号 |
4. 指定端口与阻塞端口的最终确定
当网络拓扑稳定后，通过Wireshark的显示过滤器stp.port.role==3可以快速定位阻塞端口。关键观察点包括：
指定端口选举规则：
- 每个网段选择到达根桥路径开销最小的端口
- 开销相同时选择发送者BID较小的端口
- BID相同时选择发送端口ID较小的端口
阻塞端口特征：
- 仍然会接收BPDU但不再转发流量
- 在Wireshark中可见其BPDU的Message Age持续增长
- 当Max Age（默认20秒）超时会重新触发选举
实验中发现一个反常识的现象：即使某个端口被阻塞，它仍然会持续接收BPDU报文。这实际上是STP的故障检测机制——就像心跳检测一样确保拓扑的稳定性。
5. 高级调试与故障排查
在实际项目中遇到STP问题时，可以结合Wireshark和交换机日志进行诊断。以下是几个典型场景：
案例1：根桥摇摆
- 现象：抓包显示根桥ID在不断变化
- 分析：检查BPDU中的Configuration Flags字段，确认是否有TCN（拓扑变更通知）位被置位
- 解决：排查物理链路抖动或配置不一致问题
案例2：端口状态异常
- 现象：端口在Listening和Blocking状态间循环
- 抓包关键：
stp.flags.tc == 1 # 过滤拓扑变更报文 stp.port.state == 3 # 过滤阻塞端口 - 对策：检查端口双工模式是否匹配，是否存在单向链路故障
通过持续观察BPDU中的Bridge ID、Path Cost等字段变化，就像给网络做了一次"心电图"检查，能直观理解STP的收敛过程。这种基于报文的分析方法，比单纯记忆选举步骤要深刻得多。