H3C | 基础维护篇 – STP TC问题排查与优化

小伙伴们在日常维护中是否发现，交换机上可能经常产生STP TC报文的日志告警，比如：

TC报文对现网业务的影响可大可小，有时仅仅体现为偶尔出现告警打印，有时却能引起报文泛洪、拥塞丢包。因此为了网络的正常稳定运行，应该尽可能消除异常TC报文的产生。那TC报文到底是什么呢？

我们常说的TC报文其实就是TCN BPDU，它的作用是网络中的其他网桥通知根桥网络拓扑发生了变化。上面的告警中出现了两种TC报文，一种是STP_DETECTED_TC，这是接口所在生成树实例或VLAN拓扑发生变化，本端设备检测到拓扑变化后产生的TC报文。另一种是STP_NOTIFIED_TC，这是远端相连设备通知本设备某接口所在生成树实例或VLAN的拓扑发生变化后产生的TC报文。

按照IEEE协议规定，TCN BPDU的产生条件有两个：

1. 网桥上有端口转变为Forwarding状态，且该网桥至少包含一个指定端口。

2.网桥上有端口从Forwarding状态或Learning状态转变为Blocking状态。

若上述两个条件之一满足，就说明网络拓扑发生了变化，网桥就需要使用TCN BPDU通知根桥这一变化。在日常维护中，TC报文的产生通常有以下几种情况：

1. 设备或链路出现故障，引发STP重新计算，产生TC报文。

2. STP配置参数更改，引发STP重新计算，产生TC报文。

3. 连接终端的端口使能了STP，但没有配置为边缘端口，当终端发生重启等情况导致该端口链路状态变化时，该端口产生TC报文。

4. 来自用户设备的攻击TC报文也可能传入其所接入的二层网络。

H3C系列交换机上实现的是标准MSTP的STP兼容模式，接口收到TC报文后，将把所有VLAN或Instance实例中所有VLAN的MAC表项删除，由流量触发重新学习，ARP表项会由设备会主动发送ARP请求报文来进行更新。

下面我们通过一个小实验来说明该过程。

一、实验拓扑

在Spine和Leaf上共起四个网关地址，使用一台交换机来模拟PC，配置四个VLAN虚接口模拟四个终端设备。

除PC外的其他设备均开启MSTP，Access-2与PC互联接口配置边缘端口和BPDU保护功能。

通过手动打开和关闭Access-1的上行接口来模拟网络中的链路故障和新接入交换机，构造拓扑改变触发条件。

二、网络初始状态

Spine为根设备，初始TC收发为0，正常学习到55.1.1.2和66.1.1.2的ARP表项。

Leaf设备上初始TC收发为0，正常学习到77.1.1.2和88.1.1.2的ARP表项。

接下来通过手工关闭一次再打开一次Access-1的上行口，来模拟网络中互联接口UP/DOWN和新接入交换机的场景，在整个过程中观察以下三方面情况：

1. 观察各设备的TC报文收发情况。

2. PC和网关之间不进行互ping操作，观察Spine和Leaf的ARP表项老化时间的更新情况。

3. 在Access-2上行口抓包，观察网络中ARP报文的传递过程。

三、TC报文收发情况

1. Spine设备上

手工关闭一次再打开一次Access-1的上行口后，可以看到Spine打印了两条TC告警。这是因为Access-1的上行接口DOWN再UP一次时，Access-1和Leaf上都有非边缘端口转为Forwarding状态，满足TC报文产生的条件，所以Access-1和Leaf各会产生一个TC报文然后泛洪到Spine上。

通过display stp tc命令查看TC报文的收发计数，也可以看到Spine收到2个TC报文。

2. Leaf设备上

可以看到Leaf上打印两条TC告警，其中一个TC报文是Leaf自身端口震荡产生的，另一个TC报文是Access-1端口震荡后产生并泛洪发给Leaf的。

这里需要注意是，如果是设备自身端口震荡产生的TC报文，日志中的关键字是DETECTED，如果是收到其他设备泛洪过来的TC报文，日志中关键字是NOTIFIED。

四、ARP表项更新情况

1. Spine设备上

初始ARP表项在1091S后将老化，Access-1接口UP后，Spine收到泛洪过来的TC报文，触发ARP表项更新，ARP表项的默认老化时间为1200S，变为1181S说明刚刚学习更新。

2. Leaf设备上

初始ARP表项在750S后将老化，Access-1接口UP后，Leaf收到泛洪过来的TC报文，触发ARP表项更新，ARP表项的默认老化时间为1200S，变为1176S说明刚刚学习更新。

五、抓包观察ARP报文收发情况

在Access-2上行口抓包，可以看到在接口UP后，Spine和Leaf均发出了ARP请求报文去更新自己设备上的ARP表项。

六、小节

1. 非边缘端口出现UP/DOWN时设备会产生STP TC报文，并会通过根端口和非边缘端口往其他设备发送TC报文，从而导致TC报文的整网泛洪。

2. 收到TC报文的设备会触发MAC和ARP表项的刷新，MAC表项被删除后由流量触发重新学习，ARP表项由设备主动发起ARP请求报文更新。

交换机偶尔出现少量STP TC日志告警可以不必过分关注，但在规模较大的二层网络域中，若交换机频繁收到TC报文，则会频繁刷新MAC地址表，可能造成短暂的未知单播流量泛洪，拥塞丢包；频繁刷新ARP表可能造成网络中瞬时出现大量ARP协议报文，导致核心设备CPU利用率升高，影响其他协议报文的处理。

因此我们应该尽可能消除频繁产生的TC报文，主要可以按照以下几点进行排查和优化：

1. 首先尽量从源头消除TC报文，找到是哪台设备的接口在频繁震荡。执行命令diplay stp tc查看频繁收到TC报文的端口，如果某端口收到的TC报文一直递增，查看该端口的对端设备的TC接收端口，一级一级往下直到找到TC源。

2. 根据上一步的排查结果，再继续定位接口震荡的原因。如果是设备间的互联接口，建议做一些硬件替换测试消除接口震荡。如果是互联终端的接口则建议配置STP边缘端口和BPDU保护功能。

3. 对于某些不便排查源头的网络，可以在端口上配置stp tc-restriction命令来开启TC-BPDU传播限制功能，此后当该端口收到TC-BPDU时，不会再向其他端口传播。

4. 在我司设备网络和其他厂商设备网络的交界处，如果只有单条路径连接，可以在该链路所连端口上配置stp disable或者bpdu drop。如果存在多条路径，则对其异常收TC情况进行监控和检查。

5. 尽可能合理规划和控制二层网络域的规模，当二层网络域规模较大，汇聚、接入和终端设备数量较多时，建议在核心和汇聚设备之间关闭STP功能，使每台汇聚设备与其下联网络构成一棵单独的STP树，每颗树之间互不影响，从而减小TC报文的泛洪和影响范围。