核心交换机堆叠后边缘端口为何频繁 errdisable？一次 BPDU Guard 误触发与配置漂移的排查记录

Fri, 18 Sep 2026 00:00:00 +0000

问题背景

公司核心交换机在 2026 年 8 月底完成堆叠升级（两台 Catalyst 9300 组成 StackWise-480），原计划是提升冗余与带宽。升级后一周内，接入层边缘端口开始频繁出现 errdisable，现象集中在会议室、打印机、IP 电话等非 PC 设备端口。运维团队最初怀疑是终端发送异常 BPDU，实则根源在于堆叠后 STP 根桥选举漂移与 BPDU Guard 全局配置不匹配。

故障现象

边缘端口（配置了 spanning-tree portfast edge + spanning-tree bpduguard enable）在堆叠升级后 3-7 天内随机进入 errdisable 状态。
show interfaces status err-disabled 显示原因为 bpduguard。
受影响端口包括会议室投影仪、打印机、多功能一体机、IP 电话等「非 PC」设备。
PC 端口（同样配置了 PortFast + BPDU Guard）反而稳定，说明问题与设备类型强相关。
日志中可见 \%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port 反复出现，但抓包显示这些 BPDU 的源 MAC 正是堆叠成员自身的桥 ID。

排查过程

第 1 步：确认 BPDU Guard 触发日志

在核心堆叠上执行：

`1`	`show logging \| include BLOCK_BPDUGUARD`

发现触发时间集中在早 8:00-9:00 与晚 18:00-19:00，正好对应员工上下班高峰。进一步查看具体端口：

`1`	`show spanning-tree interface GigabitEthernet1/0/23 detail`

发现该端口收到了来自桥 ID 32768.4c71.0dxx.xxxx 的 BPDU，而这个桥 ID 正是堆叠升级后的新根桥。

第 2 步：对比堆叠前后根桥选举

升级前根桥是老的 Catalyst 3850（桥 ID 优先级 32768 + MAC），升级后两台 9300 组成堆叠，系统自动选出更低的桥 ID（默认优先级相同，但 9300 的 MAC 地址池更低）。结果导致原先被「信任」的上行 BPDU 现在被边缘端口收到，形成环路假象。

第 3 步：抓包验证 BPDU 来源

在受影响的边缘端口做 SPAN 镜像，抓到：

BPDU 的源 MAC 是堆叠成员 2 的系统 MAC（4c71.0dxx.xxxx）。
该 BPDU 的 Flags 中 Topology Change 位被置位，说明堆叠成员在发送 TCN（Topology Change Notification）。
边缘端口本应只收到来自终端的 BPDU（极少），却持续收到来自核心的 BPDU。

第 4 步：检查全局配置漂移

执行 show running-config | section spanning-tree 发现：

堆叠升级前配置了 spanning-tree extend system-id（老 Catalyst 3850 必需）。
升级后 9300 默认已启用 extend system-id，但团队在迁移配置时误删了 spanning-tree mode rapid-pvst 下的 spanning-tree vlan 10-100 priority 4096（原根桥优先级）。
结果两台 9300 都以默认优先级 32768 参选，MAC 地址更小的成员 2 当选根桥，而边缘端口的 BPDU Guard 把「来自根桥的合法 BPDU」误判为攻击。

解决方案

立即止血（不改配置）

1
2
3

interface range GigabitEthernet1/0/1-48
 spanning-tree bpduguard disable
 spanning-tree portfast edge

先把所有边缘端口的 BPDU Guard 临时关闭，恢复业务。后续逐步排查。

根治方案（三步走）

明确根桥与备份根桥

1
2

spanning-tree vlan 10-100 priority 4096   ! 成员 1 成为根桥
spanning-tree vlan 10-100 priority 8192   ! 成员 2 成为备份根桥（在成员 1 配置 session 内执行）

区分「边缘端口」与「上行端口」
- 边缘端口（连终端）：保留 portfast edge + bpduguard enable，但仅在明确「不会收到来自核心 BPDU」的端口上启用。
- 上行端口（连防火墙/核心）：绝不配置 BPDU Guard，允许正常 STP 收敛。

引入 BPDU Guard 的「白名单」机制

spanning-tree portfast edge bpduguard default   ! 全局默认开启
interface range Gi1/0/1-48
 spanning-tree bpduguard enable
! 对会议室、打印机等「可能被误触发」的端口，改用：
spanning-tree bpduguard disable
spanning-tree guard root   ! 改用 Root Guard，更温和

监控与告警 在 Zabbix 中增加 errdisable 计数器告警，阈值设为「单端口 24h 内 errdisable 超过 3 次」即触发。

根因分析

根本原因是配置漂移 + 根桥选举变化的组合拳：

堆叠升级改变了桥 ID（MAC 地址更低），导致原先「不该被边缘端口看到」的 BPDU 现在被看到。
团队在迁移配置时遗漏了「根桥优先级」的显式声明，造成选举结果不可预期。
BPDU Guard 的设计初衷是「防止终端发送恶意 BPDU」，但在堆叠场景下，合法的根桥 BPDU 也被误杀，形成「自伤」。

预防措施

堆叠/升级前必做的 STP 健康检查
1 2 3

show spanning-tree summary show spanning-tree root show spanning-tree bridge id
记录当前根桥、备份根桥、所有 VLAN 的优先级。
配置版本控制
- 所有交换机配置必须纳入 Git（或至少做差异备份）。
- 升级前执行 show archive config differences 对比新旧配置，重点关注 spanning-tree 段。
BPDU Guard 的「分层防御」
- 边缘端口：portfast edge + bpduguard enable
- 服务器端口：portfast edge + bpduguard enable（服务器极少发 BPDU）
- 会议室/打印机端口：portfast edge + root guard（更温和，允许 BPDU 但不允许抢根桥）
- 上行端口：禁用 BPDU Guard
定期演练「根桥漂移」场景 每季度模拟一次「主根桥宕机」，验证备份根桥是否能快速接管，且边缘端口不会误触发。
监控指标
- errdisable 计数器（按端口、按原因分类）
- STP 拓扑变更计数器（show spanning-tree detail | include Topology change）
- 根桥 ID 变化告警（通过 SNMP Trap 或脚本定期比对）

总结

一次看似「常规」的核心交换机堆叠升级，因为遗漏了根桥优先级的显式声明，导致 BPDU Guard 把合法的根桥 BPDU 误判为攻击，造成边缘端口大面积 errdisable。这起故障再次印证了「配置漂移」在网络变更中的杀伤力——表面上看是「设备行为异常」，实则是「人的配置遗漏」被放大了。

关键教训：任何涉及 STP 根桥选举的变更，必须显式声明优先级、做好配置版本对比、并在边缘端口上采用「Root Guard」而非「BPDU Guard」作为更温和的兜底策略。

BPDU Guard on Zero Day Notes