排查High CPU網絡故障

引言：在日常網絡管理中，CPU使用率高簡稱High CPU的問題會經常碰到。通常CPU進程高分中斷高和進程高。中斷高大多是由于實時的流量造成的，通過查詢端口流量，處理相對容易，日常網管工作中，進程高，特別是IP Input進程引起的High CPU會時有發生。這里結合筆者最近剛剛處理的一起IP Input進程引起的High CPU問題，進行總結分析。

故障現象

最近在一次日常工作中，突然接到某臺匯聚設備Cisco 6506短信告警。立刻遠程登錄該設備，運行show processes cpu sorted，發現CPU利用率已經高達99%，IP Input進程占了73%。正常情況下，該設備的CPU使用率都在10%以下。

圖1 用show interface summary查看端口流量

故障排查

1.執行show interface或 show interface summary，查看哪些端口有較多的流量轉發，以及這些接口是使用何種轉發機制。建議執行本步驟之前，先執行clear counters，對計數進行清零，便于觀察流量的增長情況。

筆者喜歡用show interface summary，相對簡潔易看（如圖1）。這里重點關注RXBS和RXPS兩個指標的值，分別是每秒端口輸入流量和數據包數。筆者發現，24號端口RXPS數為34241，遠遠大于同類型端口。查看端口配置發現，該端口為級聯端口，進入該端口shutdown，CPU使用率立刻恢復正常。

故障基本可以確定是該端口下聯設備所導致，聯系下聯單位網管處理即可。本著更加負責任的態度，決定揪出最終的“兇手”。

2.show ip traffic的輸入，可以告訴我們是哪類流量增長最快，之后再檢查一下這類流量是否需要上送CPU做進一步處理，就能得出大致結論，High CPU問題是哪類流量導致的。

3. 執 行debug ip packet detail，更直接查看到底是什么樣的報文上送到CPU出 發CPU High，在執行該命令之前，建議在配置模式下先執行no logging console和no logging monitor。

執行完debug ip packet detail后3到5秒，立刻輸入undebug all命令停止。

4.使用show logging查看結果，筆者發現某網段下兩臺主機以每2ms的速度發源端口為14001，目的地址為255.255.255.255，目的端口隨機的UDP廣播包。通過查詢廣播主機MAC地址對應的端口，正是第一步查到的24口，也驗證了第一步的結果。

故障解決

找到“病根”問題自然好解決。有兩種方法，第一種“簡單粗暴法”，shutdown端口，通知故障單位網管，下聯設備所屬單位網管找到問題主機解決后，再回復。我們采用第二種：做ACL，只需要輸入兩條deny udp any eq 14001 any，permit ip any any，在故障端口24口in方向上應用。再次輸入show processes cpu查看，恢復正常。

經驗總結

在IOS中我們把SW process叫做IP Iput進程，簡而言之就是數據報文沒有被硬件switching cache或者CEF處理，而是punt到CPU去做進一步的處理。

在我們日常網絡運維中，處理High CPU問題，除了采用我們上面的方法外，還可以依據實際情況用以下方式解決：如果您經驗豐富去現場又方便，可以用Sniffer或Wireshark進行抓包；如果網絡基礎薄弱可以采取依次shutdown端口等同于現場依次拔網線，觀察CPU的占用情況，從而發現故障端口。