簡介一份面向網(wǎng)絡(luò)運維人員的H3C交換機日常巡檢命令整理文檔聚焦設(shè)備狀態(tài)監(jiān)控與隱患排查適合網(wǎng)絡(luò)管理員與H3C設(shè)備維護人員參考。文檔以H3C S5500系列為示例系統(tǒng)梳理8條高頻巡檢指令包括查看CPU使用率display cpu-usage、內(nèi)存占用display memory、設(shè)備溫度display environment、設(shè)備匯總信息display device verbose、風(fēng)扇狀態(tài)display fan、電源狀態(tài)display power、系統(tǒng)時間display clock以及接口簡要信息display interface brief。每條命令均提供實際輸出示例并解釋關(guān)鍵字段如CPU 5秒/1分鐘/5分鐘平均使用率、內(nèi)存總?cè)萘颗c已用量、入風(fēng)口與熱點溫度、設(shè)備型號與運行時間、風(fēng)扇及電源Normal/Fault狀態(tài)、接口Link/Protocol狀態(tài)等方便管理員快速判斷設(shè)備健康度并定位故障。整個資源為1個doc文件壓縮包僅21KB內(nèi)容精煉實用適合作為日常巡檢速查手冊。目前已有588人學(xué)習(xí)下載適合需要快速掌握H3C交換機巡檢要領(lǐng)的網(wǎng)絡(luò)工程師。1. H3C交換機巡檢命令不是背命令是建立一條能救命的檢查鏈H3C交換機巡檢命令說白了就是十來個display命令但真正把巡檢當(dāng)回事的人都明白命令敲一遍十分鐘把設(shè)備狀態(tài)看明白才是一整天的事。這張命令清單不是給新手背的是給那些網(wǎng)絡(luò)出過事的人用的——交換機動不動跑一兩年不重啟風(fēng)扇堵灰、電源掉壓、單核CPU打滿這些都不會主動上報到網(wǎng)管只有巡檢時看到了才能救回來。我見過太多“巡檢做了但沒發(fā)現(xiàn)問題”的翻車現(xiàn)場原因從來不是命令沒敲而是沒按順序敲、沒把輸出留下來、沒和上次的記錄做對比。2. 巡檢順序怎么定按「硬件—系統(tǒng)—接口—日志」四層過先看命再看病2.1 硬件層風(fēng)扇、電源、溫度這三樣先查再談性能H3C的網(wǎng)絡(luò)操作系統(tǒng)從Comware V5到V7巡檢命令變化不大硬件層我一般固定敲這一組display device display environment display fan display powerdisplay device看的是單板、電源模塊的在線狀態(tài)和狀態(tài)字段。輸出里每一行都有Slot、Status、Type信息Slot 0是主控板Status必須是Normal。如果看到Fault或者Absent基本可以判定硬件故障這種屬于必須當(dāng)天處理的級別。display environment一條命令能把溫度、風(fēng)扇轉(zhuǎn)速都拉出來。H3C交換機在V7版本里溫度告警閾值一般是高溫告警在65℃左右但真正需要關(guān)注的不是絕對值而是趨勢。我巡檢時習(xí)慣把歷史溫度記錄翻出來比比如上次38℃、這次52℃哪怕沒到告警閾值十幾度的漲幅也說明散熱通道在惡化。常見原因是設(shè)備間積灰、風(fēng)扇轉(zhuǎn)速下降或者機柜氣流被堵這類問題靠一次display環(huán)境看不出來必須留記錄。display fan和display power在盒式設(shè)備上基本上就是確認Present和Normal。這里有一個容易被忽略的細節(jié)部分風(fēng)扇模塊是支持調(diào)速的輸出里能看到轉(zhuǎn)速檔位如果長時間跑在高檔位說明設(shè)備自己在被動散熱環(huán)境溫度可能已經(jīng)偏高。電源模塊則要關(guān)注是否處于冗余狀態(tài)如果兩個電源里有一個Failed但設(shè)備還在運行巡檢時必須馬上安排更換因為當(dāng)前是單電源撐著再壞一個就整機斷電。2.2 系統(tǒng)層與NTP版本、時間、堆疊狀態(tài)時間不對全盤皆錯系統(tǒng)層看四條命令就夠display version、display clock、display irf、display ntp-status。但恰恰是最便宜的一條命令埋了很多坑。display version要看的其實不是版本號本身而是設(shè)備的運行時間。輸出末尾有“H3C Comware Software, Version 7.1.064”和系統(tǒng)啟動時間uptime只有幾天說明設(shè)備最近重啟過。注意重點是異常重啟還是人為重啟這個需要對照日志確認。常見認知是交換機uptime都很長如果某臺設(shè)備的uptime只有三天那大概率發(fā)生過掉電或死機這種設(shè)備在跑核心業(yè)務(wù)時要高度警惕必要時安排窗口期重啟一次。display clock看的是設(shè)備本地時間。這里有一個絕大多數(shù)人都會踩的坑H3C交換機的本地時間如果不做NTP同步跑幾個月就會慢幾分鐘甚至十幾分鐘。時間不準(zhǔn)的直接后果是日志時間戳錯亂排障時把事件順序完全顛倒。很多盒式設(shè)備比如H3C S1850系列默認通過DHCP獲取地址時可以從Option 4拿到NTP服務(wù)器地址或者通過在Web界面配置NTP。命令行下可以這樣檢查display ntp-status輸出里看Clock source是NTP還是LOCAL。如果是LOCAL說明設(shè)備在用本地時鐘這個必須處理。命令行配置NTP的常見做法是ntp-service unicast-server 192.168.10.1設(shè)備側(cè)配置完NTP后還有一個細節(jié)display ntp-status里看到的Clock offset要小于100ms才算正常否則即使同步了時間線也還是對不齊。2.3 接口與鏈路層聚合口、物理口、光模塊狀態(tài)對不上就是事故前兆接口層是巡檢里信息量最大的一塊但大多數(shù)人只敲一條display interface brief就完事了。這條命令看的是所有接口的物理狀態(tài)和鏈路協(xié)議狀態(tài)第三列Physical和第四列Link的狀態(tài)組合是關(guān)鍵Physical down, Link down物理不通查光模塊、網(wǎng)線、對端設(shè)備Physical up, Link down物理層通了但協(xié)議起不來查配置、VLAN、鏈路協(xié)商實際環(huán)境里最容易出問題的不是普通物理口而是聚合口。H3C的聚合命令在V7里叫display link-aggregation summary在V5里叫display link-aggregation verbose。巡檢時要核對聚合組里的成員口是不是和設(shè)計一致。很多事故是這樣的聚合口兩端都正常但成員口全Down了流量實際上在走透傳或者已經(jīng)斷掉只看聚合接口狀態(tài)根本發(fā)現(xiàn)不了。光模塊是另一個巡檢盲區(qū)。display transceiver interface Ten-GigabitEthernet 1/0/1能看光模塊的收發(fā)光功率一般模塊接收功率在-20dBm以上、發(fā)送功率在-3到-8dBm之間算正常。但更關(guān)鍵的是看趨勢接收功率從-15dBm掉到-19dBm雖然還在閾值內(nèi)但光鏈路在劣化。巡檢時把重要鏈路的光功率記錄下來做對比比看任何告警都管用。有些老模塊還會出現(xiàn)溫度偏高的問題display transceiver diagnosis可以看模塊內(nèi)部溫度超過70℃就要警惕了。2.4 日志層display logbuffer 不看等于白巡日志是最后一道關(guān)卡也是最容易被忽略的。display logbuffer默認顯示的是最新的一部分日志很多人敲完看到?jīng)]有ERROR就跳過了。實際上要看的是三類東西接口反復(fù)Up/Down、CPU沖擊記錄、協(xié)議狀態(tài)機異常。接口反復(fù)Up/Down在日志里的表現(xiàn)是大量“Ten-GigabitEthernet1/0/5 link state change to DOWN”和“UP”交替出現(xiàn)這種問題在日志里刷屏但網(wǎng)管軟件往往顯示為“當(dāng)前正?！币驗樗豢醋詈鬆顟B(tài)。巡檢時遇到這類日志要順著光纖去找原因大概率是對端設(shè)備重啟或光模塊不穩(wěn)定。CPU沖擊記錄要看的是“Task ran too long”或“CPU usage is high”這一類信息。Comware V7會在CPU持續(xù)超過80%時周期性輸出日志日志里會帶出具體的任務(wù)名。如果是“VIDL”任務(wù)占用高一般是硬件轉(zhuǎn)發(fā)異常如果是某些協(xié)議任務(wù)占用高比如BFD、OSPF通常是網(wǎng)絡(luò)內(nèi)有震蕩。這些信息在網(wǎng)管軟件里不一定有但日志里看得清清楚楚。3. 落一條可復(fù)現(xiàn)的巡檢命令鏈從登錄方式到批量抓取按這套流程走3.1 登錄準(zhǔn)備Console線連接參數(shù)和會話初始化三條命令做巡檢第一件事不是敲display而是把登錄環(huán)境準(zhǔn)備好。H3C交換機的Console口線序是固定的RJ45口的第3腳是TX、第6腳是RX用標(biāo)準(zhǔn)Console線連接時不需要管交叉不交叉設(shè)備端會自動翻轉(zhuǎn)。串口參數(shù)固定為9600波特率、8位數(shù)據(jù)位、1位停止位、無校驗、無流控。CRT或Xshell里新建串口會話時按這個填填錯最典型的癥狀是屏幕出現(xiàn)亂碼不是連不上。登錄成功后先敲三條命令這也是很多老工程師的習(xí)慣screen-length disable temporary undo terminal monitorscreen-length disable temporary是關(guān)掉分頁顯示。默認情況下設(shè)備輸出超過一屏?xí)Ｏ聛淼冉换パ矙z時這種交互會打斷腳本自動抓取。加上temporary參數(shù)只對當(dāng)前會話有效不寫入配置不影響其他登錄用戶。undo terminal monitor是關(guān)閉日志輸出到當(dāng)前終端否則巡檢過程中設(shè)備產(chǎn)生的實時日志會混進命令輸出里機器抓取時容易被干擾。有一個小細節(jié)如果通過SSH登錄而非Console關(guān)掉分頁之后建議順手做一次display clock確認設(shè)備時間因為SSH登錄的設(shè)備如果沒有NTP時間偏差可能很大后續(xù)所有日志排查都建立在錯誤的時間線上。3.2 核心巡檢命令串十一個命令按順序執(zhí)行每個輸出都有明確目的下面這一段是我在實際環(huán)境里固定使用的巡檢命令串適用于Comware V5和V7盒式和框式都通用screen-length disable temporary display device display environment display version display clock display irf display interface brief display link-aggregation summary display cpu display memory display logbuffer reverse save force逐條說明執(zhí)行后看什么display device所有單板Status為Normal如果有Fault直接進入故障流程。display environment溫度和風(fēng)扇狀態(tài)。框式設(shè)備能看到每個槽位的溫度重點看與上次巡檢對比的差值溫差超過10℃就要查散熱。display version確認運行時間。uptime超過300天屬于正常少于30天要回頭查日志看重啟原因。display clock確認當(dāng)前時間。和你的電腦時間或NTP服務(wù)器時間相差超過1分鐘記為待整改項。display irf只有堆疊設(shè)備需要執(zhí)行。看IRF的Role是Master還是Standby再看Member數(shù)量是否和實際設(shè)備數(shù)一致。堆疊分裂是重大事故巡檢時看到Master和Standby不在同一個框里就要立刻處理。display interface brief掃一眼所有接口狀態(tài)正常情況管理口Up、業(yè)務(wù)口按設(shè)計狀態(tài)存在其余接口基本是DOWN狀態(tài)。display link-aggregation summary核對聚合組狀態(tài)。Selected成員數(shù)量必須大于1如果看到只有1個Selected或者0個Selected聚合組已經(jīng)是單鏈路承載或完全故障了。display cpuV5設(shè)備看CPU占用率V7設(shè)備看各核占用率。單核100%時總占用率可能只有20%這種也要標(biāo)記為異常。display memory看內(nèi)存使用率。盒式設(shè)備內(nèi)存占用超過70%要留意超過85%基本可以認定存在內(nèi)存泄漏需要計劃重啟或升級版本。display logbuffer reverse用reverse參數(shù)讓最新的日志顯示在最前面。重點看First Time和Last Time之間有沒有嚴重級別以上日志以及有沒有接口翻動記錄。save force這條不是查看命令是保存配置。很多工程師巡檢查完不保存結(jié)果下次設(shè)備重啟回滾到兩個月前的配置所有巡檢期間的臨時改動全沒了。save force會將當(dāng)前配置寫入下次啟動配置文件這個動作要有意識地養(yǎng)成習(xí)慣。3.3 三條高危命令單獨說CPU、內(nèi)存、日志緩沖區(qū)的輸出怎么讀display cpu在V7版本里的輸出會細分為Total CPU使用率、每個核的使用率和任務(wù)級占用列表。讀的時候先看總占用率是否超過70%再看有沒有單核跑滿——V7設(shè)備上單核跑滿但整體不高的情況很常見通常是某個協(xié)議任務(wù)如OSPF的IPC任務(wù)出現(xiàn)異常循環(huán)導(dǎo)致。接著看任務(wù)列表里占用率最高的幾個任務(wù)名正常的最高任務(wù)一般是“VIDL”空閑任務(wù)如果“VIDL”排不進前三說明系統(tǒng)負載異常。display memory要看兩行Memory Used和Memory Free。注意Comware V5顯示的是“System Total Memory Bytes”和“Total Memory Used Low/LowWater”這類字符串V7里變成百分比顯示。讀的時候關(guān)鍵是看Used比例的變化趨勢因為我見過內(nèi)存使用率緩慢爬升直到85%后整機重啟的案例。如果兩次巡檢之間內(nèi)存使用率漲了超過10%要當(dāng)作內(nèi)存異常增長處理不能等它漲到告警閾值。display logbuffer有一個容易混淆的參數(shù)問題設(shè)備默認只輸出最近的一部分日志緩沖區(qū)本身有容量上限默認256條級別以上日志。想完整導(dǎo)出得用display logbuffer reverse或者加| include做過濾。最實用的做法是抓全部日志存到本地后再用文本工具做二次篩選。因為巡檢當(dāng)時人眼掃一遍只能看到最后一屏歷史日志里往往藏著重要線索比如一周前某接口抖動了五次而網(wǎng)管系統(tǒng)沒有告警。4. 常見問題與避坑五個真實翻車場景每個都有后悔藥4.1 display logbuffer刷屏?xí)捒ǖ角妹顩]反應(yīng)現(xiàn)象執(zhí)行display logbuffer后終端輸出持續(xù)滾動命令完全無法中斷等了幾分鐘還在刷。原因設(shè)備日志緩沖區(qū)里積累了數(shù)千條日志其中大部分是接口翻動或合規(guī)審計類的低級別日志。默認分頁被關(guān)閉后所有內(nèi)容一次性輸出串口帶寬只有9600bps刷完整個緩沖區(qū)需要很長時間。解決登錄后不要直接執(zhí)行display logbuffer先執(zhí)行display logbuffer summary看日志總量。如果條數(shù)超過500條先過濾再抓取比如用display logbuffer | include link state只抓接口狀態(tài)變化記錄或者指定時間范圍display logbuffer log-buffer size 200。抓取前也可以通過info-center loghost把日志轉(zhuǎn)發(fā)到日志服務(wù)器減輕設(shè)備側(cè)緩沖區(qū)壓力。4.2 聚合口狀態(tài)明明是Up流量卻斷斷續(xù)續(xù)現(xiàn)象某業(yè)務(wù)網(wǎng)段的流量時通時不通查看display link-aggregation summary看到聚合口狀態(tài)是Up但實際轉(zhuǎn)發(fā)異常。原因聚合組成員口狀態(tài)和聚合口狀態(tài)不一致。成員口中部分接口物理Down或協(xié)商失敗但聚合組仍處于Loaded狀態(tài)流量被哈希到失效的成員口上導(dǎo)致部分會話丟包。解決巡檢時不僅要看聚合口還要逐成員核對。常見做法是執(zhí)行display link-aggregation member-port display interface Ten-GigabitEthernet 1/0/1逐一確認成員口的Last 300 seconds input/output速率如果某個成員口速率接近0而其他口有流量說明哈希不均勻或成員口異常。另外V7里可以執(zhí)行display link-aggregation load-sharing查看是否啟用了增強負載均衡默認按報文五元組取模哈希如果流數(shù)量較少很容易出現(xiàn)流量集中在單成員口的情況這種不算故障但需要調(diào)整負載均衡模式。4.3 堆疊設(shè)備只看了主框備框的告警全瞎現(xiàn)象IRF堆疊環(huán)境里巡檢時只在當(dāng)前登錄的框上敲了一遍display命令沒有切到備框查看結(jié)果備框單板Fault一直沒有被發(fā)現(xiàn)。原因IRF堆疊后通過任意一個成員框登錄命令默認只作用于當(dāng)前框。很多命令不帶slot參數(shù)時只顯示當(dāng)前框的信息特別是display device不同版本行為不一致有的顯示全量有的只顯示本框。解決巡檢IRF堆疊時養(yǎng)成帶irf參數(shù)的暴力習(xí)慣display irf display device irf display environment irfdisplay device irf會列出所有成員框的單板狀態(tài)。如果只想看某個成員框用display device slot 1或display device slot 2分別查看。另外要注意文本框和備框的版本一致性display version的輸出里如果看到兩個成員框的軟件版本不同要立刻安排升級否則堆疊系統(tǒng)在角色切換時會出現(xiàn)兼容性問題。4.4 save force把上線配置覆蓋了回滾不了現(xiàn)象巡檢時執(zhí)行了save force第二天發(fā)現(xiàn)設(shè)備重啟后配置變成了舊版本某些業(yè)務(wù)VLAN的接口配置缺失業(yè)務(wù)中斷。原因save force保存的是當(dāng)前運行配置到下次啟動配置。如果巡檢前有人調(diào)試過配置但沒有確認正確性運行配置里可能殘留錯誤或中間態(tài)配置此時保存就把壞配置寫死了。更常見的是巡檢人員登錄后什么都不改直接save但之前另一位工程師已經(jīng)改了運行配置且還沒保存save操作把半成品配置固化。解決save 前先執(zhí)行一次display current-configuration | include vlan和display startup確認下次啟動配置文件的修改時間與當(dāng)前配置一致。最穩(wěn)妥的做法是保存前先備份現(xiàn)有啟動配置copy startup.cfg backup_20240601.cfg然后才執(zhí)行save force。這樣即使保存出錯還能用startup saved-configuration backup_20240601.cfg回滾。巡檢命令串聯(lián)里save force必須排在所有檢查命令之后并且保存前確認無人正在設(shè)備上調(diào)試這是血的教訓(xùn)。4.5 設(shè)備時間沒同步日志對不上網(wǎng)管時間線現(xiàn)象網(wǎng)絡(luò)出故障后回溯日志設(shè)備日志時間比網(wǎng)管系統(tǒng)時間慢了一個多小時事件順序錯亂無法定位真正的故障起點。原因設(shè)備沒有正確配置NTP或者NTP服務(wù)指向的服務(wù)器不可達。很多H3C盒式設(shè)備比如S1850默認開啟DHCP時自動從Option 4獲取NTP服務(wù)器但如果使用靜態(tài)IPNTP服務(wù)就是空的設(shè)備時間靠手動設(shè)置跑幾天就會漂移。解決巡檢時把display ntp-status作為必查項看到Clock source為LOCAL就是問題。命令行配置NTP的完整做法ntp-service unicast-server 192.168.10.1 ntp-service enable配置完成后等待幾分鐘再執(zhí)行display ntp-status確認Clock source變成NTP、Clock offset降到100ms以下。如果NTP服務(wù)器不可達至少也要保證每月手動校準(zhǔn)一次否則時間漂移到小時級后日志排查完全失效。這個問題在巡檢命令里特別容易被忽略但它是最便宜、收益最高的一個動作。4.6 光模塊功率是負的但鏈路正常三個月的趨勢線才見分曉現(xiàn)象某條鏈路偶爾出現(xiàn)丟包每次持續(xù)幾分鐘后自動恢復(fù)。檢查光模塊接收功率在-20dBm邊緣但接口狀態(tài)一直是Up設(shè)備沒有告警。原因光模塊接收功率處于靈敏度和飽和點之間的邊緣區(qū)域。多數(shù)光模塊的告警閾值設(shè)得很寬從-30dBm到-3dBm都不告警但實際鏈路質(zhì)量已經(jīng)在劣化偶發(fā)誤碼導(dǎo)致丟包。解決巡檢時對重要鏈路執(zhí)行display transceiver interface記錄收發(fā)光功率。我的做法是把功率數(shù)據(jù)寫進巡檢表每次巡檢后對比上一次的值如果接收功率下降超過3dB就列入觀察名單再降3dB就該換模塊或清洗光纖接頭。這種方法比等設(shè)備告警可靠得多因為光模塊故障從來不是突變的都是慢慢劣化而網(wǎng)管軟件不會給你畫功率趨勢線。5. 進階一點把巡檢命令固化成腳本跑完自動留痕對比基線巡檢不能永遠靠人肉敲命令。到了這一步我的做法是把整套命令寫進Python腳本借助paramiko庫批量SSH登錄設(shè)備執(zhí)行并抓取輸出然后存儲為帶日期的文本文件再和上次的基線做diff。一個最小可用的腳本長這樣import paramiko import datetime # 定義設(shè)備清單按實際環(huán)境修改IP、賬號、密碼 devices [ {host: 192.168.10.1, username: admin, password: passwd}, {host: 192.168.10.2, username: admin, password: passwd}, ] # 巡檢命令串每條命令之間留一點間隔等待輸出 commands [ screen-length disable temporary, display device, display environment, display clock, display interface brief, display cpu, display memory, display logbuffer reverse, ] for dev in devices: ssh paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect(dev[host], port22, usernamedev[username], passworddev[password], timeout10) # 通過invoke_shell進入交互式shell逐條執(zhí)行命令 shell ssh.invoke_shell() output for cmd in commands: shell.send(cmd \n) time.sleep(2) # 等待設(shè)備輸出可根據(jù)設(shè)備性能調(diào)整 # 讀取全部回顯 while shell.recv_ready(): output shell.recv(65535).decode(utf-8, errorsignore) # 保存為帶日期的文件文件名格式IP_YYYYMMDD.txt date_str datetime.datetime.now().strftime(%Y%m%d) filename f{dev[host]}_{date_str}.txt with open(filename, w, encodingutf-8) as f: f.write(output) ssh.close()這個腳本里的每個參數(shù)都值得說明shell.send每次發(fā)一個命令加換行符發(fā)送后sleep 2秒是因為H3C設(shè)備執(zhí)行display命令需要時間sleep太短會導(dǎo)致輸出和下一屏內(nèi)容拼接在一起抓到的文本就對不上號了。shell.recv_ready()循環(huán)讀取回顯是一次性把緩沖區(qū)內(nèi)容取空避免部分輸出殘留到下一個設(shè)備。腳本跑完后的關(guān)鍵動作是留痕和對比。我習(xí)慣把巡檢文本按設(shè)備分目錄存放然后每周用diff工具和上周的記錄比一遍。重點看的是設(shè)備重啟時間變化、CPU使用率波動、日志緩沖區(qū)里有沒有新的嚴重告警。有條件的團隊還可以再進一步把巡檢腳本掛到計劃任務(wù)里每周固定時間跑一次輸出文件自動歸檔到共享盤。設(shè)備超過十條以后人肉巡檢本質(zhì)上已經(jīng)不可靠了定期巡檢的收益并不在于每條命令的執(zhí)行而在于那根橫跨兩周時間、爬升了10℃的溫度曲線或者一條悄悄從-15dBm掉到-19dBm的光路功率。我自己現(xiàn)在的習(xí)慣是每次巡檢完順手用display save存一份配置快照哪怕不改任何配置也存。三個月后設(shè)備出了問題拿著當(dāng)時的配置文件和日志對著查比現(xiàn)場翻設(shè)備省力十倍。希望這份命令清單和腳本思路幫到你少踩幾個我當(dāng)年踩過的坑。本文還有配套的精品資源點擊獲取