步骤3、同时设备上还有大量的ARP报文超过CPCAR后丢弃的日志记录。所有使能STP的端口，接收的TC报文计数均在增长。由此说明此接口入方向光纤线缆有问题，排查线缆故障后问题解决。配置此命令后可以保证设备频繁收到TC报文时，每2秒周期内最多只处理1次表项刷新。当设备收到TC报文后，默认会清除MAC、老化ARP。从而减少MAC、ARP表项频繁刷新对设备造成的负担。
很多系统工程师和网络工程师都碰到过，在现网中出现大量的TC报文，那么如果遇到该怎么办？今天从以下几点来做个描述。
一、第一种情况：网络中有网管软件处理过程步骤1、通过网管监控的CPU利用率情况，如下图所示：
通过网管监控看到的CPU利用率
步骤2、同时设备上还出现CPU占用率过高的日志信息。
步骤3、同时设备上还有大量的ARP报文超过CPCAR后丢弃的日志记录。
步骤4、查看端口TC（Topology Change）报文收发情况。
所有使能STP的端口，接收的TC报文计数均在增长。
下图：端口TC报文计数增长对比图
二、第二种情况：网络中没有网管软件步骤 1
1）因未在故障时查看信息，无法知道具体哪些进程引起CPU升高，怀疑为设备FTS任务进程要处理大量的TC报文，导致CPU占用率升高。
2）设备一直产生TC报文日志，首先确定此TC报文是本设备产生的，还是从其它设备收到的。
3）使用display stp tc-bpdu statistics命令查询TC报文是在S5700设备产生的，还是从其它设备收到的。
经查询S5700与SwitchA互连的端口GE0/0/X收到的TC报文一直增长，且同时转发至其它接入层交换机。由此可以判断该TC报文不是XXX设备产生的。
<S5700> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port TC(Send/Receive) TCN(Send/Receive)
0 GigabitEthernet0/0/51 29272/63 0/0
0 GigabitEthernet0/0/52 3/18363 0/0
步骤 2
1）使用display stp tc-bpdu statistics命令逐层排查TC报文入方向设备，确认此TC报文是在网络中的哪一台设备上产生的。
2）查询核心设备SwitchX1，发现XXX端口收到大量的TC报文，而XXX端口是与核心设备SwicthX2互联的，由此可以判断该TC报文不是SwitchX1产生的。
3）继续查询核心设备SwitchX2，发现GigabitEthernet0/0/2端口收到大量的TC报文，
而GigabitEthernet0/0/2端口是与SwitchX3设备的GigabitEthernet0/0/5互联，由此可以判断该TC报文不是SwitchX2产生的。
<SwitchX2> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port TC(Send/Receive) TCN(Send/Receive)
0 GigabitEthernet0/0/1 12495/13 0/0
0 GigabitEthernet0/0/2 135/8349 0/0
4）继续查询SwitchX3设备，发现GigabitEthernet0/0/51、GigabitEthernet0/0/52端口Send方向大量的TC报文计数增涨，初步判断TC报文由应由此设备产生。
<SwitchX3> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port TC(Send/Receive) TCN(Send/Receive)
0 GigabitEthernet0/0/51 8196/1123 0/0
0 GigabitEthernet0/0/52 8343/136 0/0
步骤 3
当查询到SwitchX3设备时，发现其TC报文只有在出方向上不断有增长计数，由此可判断该TC报文为SwitchX3设备产生。
此时执行命令display stp topology-change查询该TC报文的信息。
从以下回显可以看出，该设备GigabitEthernet0/0/51端口不断由阻塞变为放开后，由于状态变为detected而触发拓扑变化。
<SwitchX3> display stp topology-change
CIST topology change information
Number of topology changes :8233
Time since last topology change :0 days 0h:0m:26s
Topology change initiator(detected) :GigabitEthernet0/0/51
Number of generated topologychange traps : 9852
Number of suppressed topologychange traps: 13
步骤 4
1）执行命令display interface brief查询该接入设备端口信息，发现该设备GigabitEthernet0/0/51端口入方向有大量错包
2）隔一段时间后，再次查询该设备的端口信息，GigabitEthernet0/0/51端口入方向还是有大量错包。
由此说明此接口入方向光纤线缆有问题，排查线缆故障后问题解决。
<SwitchX3> display interface brief
PHY: Physical
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(E): E-Trunk down
(b): BFD down
(e): ETHOAM down
(dl): DLDP down
(d): Dampening Suppressed
InUti/OutUti: input utility/output utility
Interface PHY Protocol InUti OutUti inErrors outErrors
........
GigabitEthernet0/0/51 up up 0.01% 0.02% 38068638 0
解决方案
1、全局配置stp tc-protection。
配置此命令后可以保证设备频繁收到TC报文时，每2秒周期内最多只处理1次表项刷新。从而减少MAC、ARP表项频繁刷新对设备造成的CPU处理任务过多。
2、全局配置arp topology-change disable及mac-address update arp。
当设备收到TC报文后，默认会清除MAC、老化ARP。当设备上的ARP表项较多时，ARP的重新学习会导致网络中的ARP报文过多。
配置arp topology-change disable、mac-address update arp后，在网络拓扑变化时，可以根据MAC地址的出接口变化刷新ARP表项出接口。可以减少大量不必要的ARP表项刷新。
全局配置stp tc-protection命令，配置后可以保证设备频繁收到TC报文时，每2秒周期内最多只处理1次表项刷新。从而减少MAC、ARP表项频繁刷新对设备造成的负担。
