交換機流量 很多 案例分享 自己 交換機 堆疊 技術分享 示意圖 mark

交換機CPU負載高達90%以上（一）
一.前言
自從工作以來 ，接觸了很多的項目，也遇到了無數多的問題，有些問題看似很奇葩，其實從理論上來解
釋都是行的通的，當然我們排除是設備或是軟件自身的bug問題，因為這樣的問題令人很惡心，想必同道中人
也是深有感觸吧；總結這幾年的工作，我為H3C，CISCO也提交過不少的bug信息了吧；之前在我的博客中多
數都是講解網絡相關的理論知識，而這樣的文章網上也是比比皆是；前段時間突發感慨國內實際案例分享的是
少之又少，所以接下來在我的博客中我將為大家帶來我在工作中近6年來的工作經歷和經驗，與大家共享，在
提供案例的同時，我盡可能還原“現場”，分享實際經驗的文章，文字內容都是比較多的，所以博客們要想從
接下來的博文中獲取更大的利益，那只能仔細耐心的閱讀文字了，讓博客們能夠感受當時的情景，也希望給大
家帶來更多的利益！

二.第一案例

雪飄人間分享案例之cpu負載90%以上（一）

1. 事發經過
   由於這個是某公司集團真實網絡環境，所以我不能將全網的環境在博文中體現,只能“斷章取義”，
   但是大家放心，這個一點也不影響我們呈現當時的問題，接著往下走吧，現在我們開始講故事了，希望大家可
   以聽下去！
   這是一個全新的項目，當時客戶使用了自己機房，采購了4臺12510（兩臺核心，兩臺匯聚），圖中體現的
   就是兩臺匯聚交換機了，40多臺接入交換機，495臺server，其中交換機全部都是兩倆堆疊（如圖所示）；這
   個項目的負責人是我，我也主要掌管網絡這塊，還有做主機和數據庫的，當然還有H3C廠商的人，事發當晚，
   
   我們都在機房，當時這兩個機櫃機器時常不通 ，丟包嚴重，一開始我並沒有註意這塊，因為我主要負責規劃和
   統籌協調這一塊，具體的技術實施和命令配置是由廠家完成的；當時已經準備下班回去了，業務的人開始反應
   說機器丟包，而且越來越嚴重，我讓廠家的人先去排查，過了一段時間問他們怎麽樣了 ，他們說沒什麽異
   常，，，我這個時候就開始懷疑了，怎麽會正常，當時我過去登上一臺交換機查看，確實沒有什麽異
   常，包括cpu和內存使用率，不行就重啟交換機試試 ，於是我就重啟交換機，因為是新的環境所以並不會有什
   麽太大的影響，重啟完之後就正常了 ，我們觀察10多分鐘沒什麽問題，我們就都下班了 ；
   第二天一早業務的人反應又開始丟包，我又跑到機房去看，如果要是交換機有什麽問題重啟也不應該會恢
   
   復問題呀 ，再說當時交換機流量並沒有那麽大，所以也不應該是流量造成的呀，我當時忙於其他事情，讓廠商
   的人去排查，，可廠商的人好像已經黔驢技窮了，不知道該怎麽辦，確實丟包的問題和不通的問題排查難度
   相差很大，我當時忙完手頭上的事情，就過去看這個問題，並且和他們說不要怕，一切都能搞定；首先我排查
   每個接口的流量，發現有個接口流量非常大，我就單條命令查看該接口的數據包變化，，， 後來發現接口的利
   用率一直在緩慢的增長，但是CPU確實很正常，大概30多分鐘，後接口的利用率竟然達到了100%；當時我就直
   接去排查線路問題，發現施工隊在接線的時候接錯了，原來是要把一個櫃上的交換機到另一個機櫃上的服務器
   連接起來，結果他錯把要接在服務器上的線接在了交換機上面，導致我的二層拓撲出現了環路（全網STP是關
   閉的），如下圖接線示意圖：
   
   雪飄人間分享案例之cpu負載90%以上（一）

2.總結結論
1.對於交換機而言，一般來說如果網絡中有環路，那麽交換機的CPU會很快上升到100%，但是H3C不是
這樣的，當時查看了CPU沒有問題，就沒有在向環路上面想，所以這是一個坑，判斷環路不能僅僅看
交換機的CPU和內存
2.環路產生是由於施工隊錯拔錯插線路導致的，現場部署的線路確實很多也非常復雜，所以物理線路一
定要理順

交換機CPU負載高達90%以上（一）【新任幫主】