十年網(wǎng)站開發(fā)經(jīng)驗 + 多家企業(yè)客戶 + 靠譜的建站團隊
量身定制 + 運營維護+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
交換機cpu負載90%以上(二)
一.背景介紹:
來到這個公司2個多月,就又遇到了一起“交通事故”,交換機cpu90%以上,公司的人上公網(wǎng),訪問idc數(shù)
據(jù)總是出現(xiàn)丟包的情況,公司使用的都是cisco的設(shè)備 ,接入有2960,2950,3560交換機,core 是4506交換
機,防火墻是juniper, 出口路由器是routeros;
二.案例賞析
雪飄人間分享案例之cpu負載90%以上(二)
如上是網(wǎng)絡(luò)的部分拓撲圖,由于是辦公生產(chǎn)網(wǎng)絡(luò),并且有內(nèi)部server數(shù)據(jù),所以整個拓撲圖無權(quán)限展現(xiàn)出
來,不過這將完全不影響我們展現(xiàn)問題所在;
首先在接到同事反映網(wǎng)速慢時,我就采用分段隔離法,逐級測試外網(wǎng)地址 ,最終確定是我們自己內(nèi)部到網(wǎng)
關(guān)就有問題;這個可不好排查了,因為不是所有人到網(wǎng)關(guān)都有問題,其實絕大多數(shù)到網(wǎng)關(guān)都沒有問題
當(dāng)時的判斷是某個接入交換機到核心交換機線路有問題,要是這個問題的話,那就不好搞了 ,因為辦公網(wǎng)是從
1996年就開始成立了 ,線路老化也是非常有可能的,要真的是線路的問題,那么換線是非常麻煩的事情
了,但是后來仔細觀察發(fā)現(xiàn),丟包同事的pc機器并不都在一臺交換機上,而是分布在很多臺上,這個就可以排
除是線路老化造成的了,因為線路老化不可能同一時間很多條線路都老化了;問題變得越來越棘手
當(dāng)時考慮最近有沒有上什么新的業(yè)務(wù)導(dǎo)致辦公網(wǎng)流量徒增造成的,但是事實是沒有上新業(yè)務(wù),和往常一樣,
于是我就利用我們的監(jiān)控Cacti查看這臺核心交換機的流量圖,發(fā)現(xiàn)交換機在和防火墻對接的口流量非常的大
而我們的防火墻又是現(xiàn)上的;看來就是防火墻和交換機之間的連線問題了,在這個之前我們也用wireshark抓
包看過內(nèi)網(wǎng)流量,發(fā)現(xiàn)除了大量的budp,沒有其他的異常流量
我看了下防火墻到交換機的兩條線路,防火墻本身是個1000兆的接口 ,但是交換機基本上都是百兆的接口
千兆接口少之又少,而且基本上都被占用,并且防火墻和交換機對接的有一個線是千兆,而另一根線是百兆
的,看來是流量阻塞造成的了
過程是這樣的,內(nèi)網(wǎng)網(wǎng)關(guān)放在防火墻上,流量經(jīng)交換機二層到防火墻,然后再由防火墻經(jīng)由交換機到路由
器,由于進到防火墻是個千兆,所以很多流量都能過去,但是防火墻將流量轉(zhuǎn)發(fā)的交換機上的時候,交換機卻
用百兆網(wǎng)口去接收,導(dǎo)致交換機接口的利用率達到了100%,然后交換機采用cpu去計算,這樣交換機的cpu自
然會升高
后來我是在交換機上找了個千兆口接在防火墻,cpu下去了,丟包現(xiàn)象消失
事情到此任然沒有結(jié)束,let‘s go !
當(dāng)我再次查看cpu的時候,發(fā)現(xiàn)cpu利用率還是很高:
雪飄人間分享案例之cpu負載90%以上(二)
通過查看其進程發(fā)現(xiàn)是Cat4k Mgmt LoPri 非常的高,這里的HiPri代表是處理高優(yōu)先級的進程,LoPri代
表處理低優(yōu)先級的進程,LoPri 值比較大原因是因為進程超過了HiPri給定的Target,然后交給了LoPri來處理
最終才帶來了LoPri值比較大的問題:
雪飄人間分享案例之cpu負載90%以上(二)
我開始再次查看cpu的進程(show platform health)
雪飄人間分享案例之cpu負載90%以上(二)
這條命令是能夠查看時哪個進程占用了大量cpu:
intra# sh platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
K2PortMan Review 2.00 2.81 15 11 100 500 2 2 2 8242:09
Gigaport0 Review 0.40 0.00 4 0 100 500 0 0 0 0:00
Gigaport1 Review 0.40 0.00 4 0 100 500 0 0 0 0:00
Gigaport2 Review 0.40 0.00 4 0 100 500 0 0 0 0:00
Gigaport3 Review 0.40 0.00 4 0 100 500 0 0 0 0:00
K2FibPerVlanPuntMan 2.00 0.00 15 2 100 500 0 0 0 0:00
K2FibFlowCache flow 2.00 0.02 10 8 100 500 0 0 0 195:34
K2FibFlowCache flow 2.00 54.00 10 8 100 500 58 65 45 41846:36
K2FibFlowCache adj r 2.00 0.09 10 4 100 500 0 0 0 280:52
可以看到 其他的值Target的值是比Actual大的,但是K2FibFlowCache flow 是不正常的,查看
官網(wǎng)對應(yīng)的解釋:
雪飄人間分享案例之cpu負載90%以上(二)
這個值之所以大是因為,PBR在作怪,我們核心交換機上確實配置了PBR做特別需求處理,當(dāng)我把
PBR給去掉了時候,再次查看K2FibFlowCache flow
雪飄人間分享案例之cpu負載90%以上(二)
發(fā)現(xiàn)這個值立刻就下去了,然后在看看CPU 雪飄人間分享案例之cpu負載90%以上(二)
三.總結(jié)結(jié)論
1.對于交換機的cpu升高有很多種因素造成,排查起來相對困難
2.排查cpu故障時,如果是突然的升高,那么也要從好幾個方面排查,主要是看最近業(yè)務(wù)有沒有變動,架構(gòu)有
沒有變動,配置有沒有變動等,有可能是誤操作導(dǎo)致,當(dāng)然老的機器還有可能是硬件出現(xiàn)故障
3.一般來說流量徒增,對交換機cpu影響是比較大的,比如交換機接口轉(zhuǎn)發(fā)流量,×××流量等等
4.官網(wǎng)也有很多對于cpu升高問題處理解決辦法,在解決問題時還要結(jié)合其他有用的資源,比如本例中的流量
監(jiān)控工具Cacti
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場景需求。