很多系統工程師和網絡工程師都碰到過，在現網中出現大量的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表項頻繁刷新對設備造成的負擔。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!