关于生成树协议STP 的故障案例分析和配置优化

1 引言

在典型的以太网局域网中，为 了增加 络通信的可靠性和 余 会对通信设备和通信链路进行环形冗余部署。在提高可靠性的同时也 了能够有效消除二层环路问题，在二层交换机上都会部署生成树 从而避免形成二层环路。当网络拓扑变更的时候，它能够及时的发 恢复网络通信。生成树协议给网络通信带来极大的便利和好处的同时， 也衍 问题， 笔 遇到的一些故障现象进行分析，希望能够对网络设备运维人员有一些启发。

2 端口的状态改变

2.1 故障现象

某日部门 A 反馈说可以访问部门内部终端，但是无法访问 OA 服务器。其现场的通信拓扑部分示意图如下图所示：

2.2 故障分析

经现场检查发现，故障现象确实如部门工作人员反馈的一致。为了找到故障原因，登录 SW2 查看日志，发现日志上显示如下信息：

Jul 1 2022 13：34：32 SWA %%01IFPDT/4/IF_STATE（l）[1]：Interface GigabitEthernet0/0/3 has turned into UP state.

Jul 1 2022 13：34：32 SWA %%01MSTP/4/SET_PORT_DISCARDING（l）[2]：In MSTP process 0 instance 0， MSTP set port GigabitEthernet0/0/5 state as discarding.

Jul 1 2022 13：34：32 SWA %%01MSTP/4/SET_PORT_FORWARDING（l）[3]：In MSTP process 0 instance 0， MSTP set port GigabitEthernet0/0/3 state as forwarding.

从日志信息上可以看到 SWA 连接 SWB 的端口 5 处于 discarding 的状态，而端口 3 变成 UP state 并处于forwarding 状态，为了进一步得到详细的信息，在终端窗口上输入display stp brief 命令，显示如下信息：

从输出的信息中可以看到端口 3 变成了一个根端口，而端口 5 变成了一个指定端口并处于 discarding 的状态。在这种情况下，部门 A 的用户也应该能通过端口 3 正常访问 OA 服务器，但是现场部门 A 用户的终端确实无法登陆OA 服务器。检查SWA 的端口3 和端口5 的配置。

从上面的信息可以看出VLAN13 的流量无法通过端口3 转发给核心交换机SW1，而OA 服务器正好就部署在VLAN13。在端口3 上添加了允许通过VLAN13 后，部门A 的同事恢复正常访问OA 服务器，但是SWA 端口5 的故障仍然没有解决。在正常的情况下，如果端口角色为ALTE，STP 状态为discarding，属于正常情况，并不需要进一步的检查。但是端口角色为DESI，而STP 状态一直为discarding，则说明该端口状态异常，需要进一步排查，这有可能是因为：1、设备收到了自己发出的BPDU 报文。2、启用根保护功能，确收到了更优的BPDU 报文。3、启用环路保护功能，端口在指定时间内收不到BPDU 报文。4、使用不同厂商的设备导致接收异常协商的报文。从现场SWA 的物理线路上检查发现，部门A 的用户接入SWA 的端口并没有发现变化，在部门B 的SWB 上可以看到外接了一台与SWA 不同厂商的交换机SWC，通信拓扑如下所示：

登陆 SWC 上全局关闭了 STP 协议后，在 SWA 上再次输入 display stp brief 命令可以看到，端口 5 也恢复了正常的 forwarding 状态。

终端设备无法参与 STP 计算和回应 STP 报文，在生产办公环境中可以把用户侧的端口配置成边缘端口 stpedge-port enable，并开启 BPDU 报文过滤功能 stp bpdu- 使端口不再发送BPDU 报文，也可以考虑端口下配置 stp disable 去使能 ST 协议，使端 直保持在转发状态 启用根保护功能的指定端口收到优先级更高的 BPDU 报文时，端口状态将进入 Dis ding 状态，不再转发报文，可以防止由于维护人员的错误配置或网络中的恶意攻击，导致网络中出现优先级更高的 BPDU 报文，使得当前合法根桥失去根桥的地位，引起网络拓扑结构的震荡变动，导致网络通信出现故障。

3 TC 包泛洪

3.1 故障现象

某日部门 A 反馈说访问内部的文件服务器时，网络通信时断时续。根据现场的通信设备连接情况，其通信拓扑部分示意图如下图所示，

3.2 故障分析

现场检查发现，故障确实如用户反馈，部门 A 的终端去 ping 文件服务器时，时断时续。通过 SCSWA 和SCSWB 去访问文件服务器时，通信正常，没有出现通信中断的情况，故障应该集中在 SW5 上，检查日志发现有大量的TC 报文：

Oct 13 2021 21：08：21-08：34 S5700 %%01INFO/4/SUPPRESS_LOG（l）[10]：Last message repeated 1 times.（InfoID=1086487152， ModuleName=MSTP， InfoAlias=RECEIVE_MSTITC）

Oct 13 2021 21：07：21-07：29 S5700 %%01INFO/4/SUPPRESS_LOG（l）[11]：Last message repeated 3times.（InfoID=1086487152， ModuleName=MSTP， InfoAlias=RECEIVE_MSTITC）

Oct 13 2021 21：06：13-06：16 S5700 %%01INFO/4/SUPPRESS_LOG（l）[12]：Last message repeated 3times.（InfoID=1086487152， ModuleName=MSTP， InfoAlias=RECEIVE_MSTITC）

输入命令 display cpu-usage，发现 SW5 的 CPU 占用率最高达到了 98%。

结合报文日志和 CPU 的曾经的占用率，初步怀疑是因为设 备在接收到拓扑变化报文后，对 MAC 地址表项和ARP 表项的执行删除操作，造成短时间 地址表和 ARP 表项被删除后，短时间内会产生大量的 ARP 请求，导致大量的 U 的负荷，从而导致通信拥塞中断。MAC地址表项和ARP 表项的频繁更新也会对CPU 造成比较大的负荷，可能造成CPU 占用率过高。

为了确认出现大量的 TC 报文的问题是怎么产生的，得先确定 TC 报文是从哪台设备产生的。通过 displaystp tc-bpdu statistics 命令，根据拓扑结构，逐层排查 TC 报文的入方向设备，检查报文是在网络中的哪一台设备上产生的。

通过 display stp tc-bpdu statistics 命令查询 TC 报文，可以看到 SW5 的端口 27 收到了大量的 TC 报文，而且一直在增长，由此可以判断TC 报文不是SW5 产生的，而是来源于跟SW5 互联的SWA 设备端口2。

在 SWA 上输入命令 display stp tc-bpdu statistics，从 SWA 上可以看到每个端口都有往外发送大量的TC 报文，只有端口28 收到了大量的TC 报文，而SWA 端口28 是跟SWB 设备的端口28 互联的。

根据 SWA 上查询到的情况，在 SWB 上查询，同样发现只有端口 2 收到了大量的 TC 报文，而端口 2 的互联设备是SW4。

在SW4 上查询，发现只有端口27 和28 Send 方向有大量的TC 报文增长，其他端口并没有接收和发送TC 报文，从检查的情况来看，TC 报文应该主要来源于部门B 的SW4。

在 SW4 上执行命令 display stp topology-change 查询该 TC 报文的信息，通过以下信息，我们可以看到收到拓扑变化报文而触发拓扑变化的端口主要是端口27。

输入命令 display interface brief 查询 SW4 设备端口信息，发现端口 27 入方向有大量错误的数据包，隔一段时间再次输入命令查看，发现端口27 入方向错误的数据包数量仍然在增加。

现场检查端口 27 的线缆两端接头，发现该线缆接 SW3 的 RJ45 接头是由人工手工制作的接头，水晶头内部的压线有被压爆的情况，用万用表测量，发现其中 2 个管脚时断时开，接上设备，其端口的灯也是时亮时灭，重做此水晶头后，端口 27 不再有生成新的错误的数据包，SW4 也不再大量的往外发送 TC 报文，网络时断时续的故障也得到解决。

在生产环境中，为了防止设备短时间 大 量拓扑变化的 BPDU 报文，造成频繁的删除 MAC 或者 ARP 表项操作给设备造成很大的负担，造成 topology-change disable ；2、开启 TC 保护功能 stp t 数量的拓扑变化报文所需时间 stp tc-protectioninterval ；4、配置设备在设定时 tection threshold ，可以最大程度避免因网络的拓扑频繁变化， 态 化引起整个网络震荡而重新收敛，造成短时间内的网络通信中断。

4 结语

通过本文两个故障案例的分析，我们发现生成树 靠性和冗余性的同时也带了一些风险，如果运维人员不熟悉协议中各种场 成通信网络的负优化。希望通过以上案例的学习，运维人员能够认识到根桥保护 学习到如何通过设备日志和报文统计等功能排查故障的思路。