簡介面向網絡運維人員與H3C設備管理員這份H3C交換機巡檢命令文檔系統(tǒng)梳理了日常設備巡檢中最關鍵的八類檢查項CPU使用率、內存占用、設備溫度、硬件匯總信息、風扇運行狀態(tài)、電源健康狀態(tài)、系統(tǒng)時鐘準確性以及接口鏈路狀態(tài)。每個命令都配有作用說明、具體執(zhí)行方式與典型輸出示例并對關鍵輸出字段進行了解讀如內存使用率百分比、溫度傳感器的入風與熱點閾值、風扇和電源的Normal/Fault狀態(tài)標識、設備型號與運行時間、接口的Link/Protocol狀態(tài)等。通過對照這些信息運維人員可以快速識別設備潛在風險并采取修復措施有效避免因資源耗盡、高溫或硬件故障導致的業(yè)務中斷。資源為單個doc文檔體積僅21KB內容緊湊實用適合打印或在終端旁快速查閱。目前已有588人學習下載可作為H3C交換機日常維護與故障排查的入門參考。1. 先把H3C交換機巡檢命令.doc這件事說清楚它解決什么、適合誰每天早上到客戶機房我習慣先把核心交換機登錄上去看一眼CPU、光衰、日志有沒有異常確認昨晚沒出幺蛾子才敢開始動配置。H3C交換機巡檢命令.doc就是這個動作的物化把散在官方手冊里的display命令挑出十幾條排成一張固定順序的檢查清單讓任何接手的人都能在半小時內完成一次“不漏項、結果可對比”的設備體檢。它不是網管系統(tǒng)的替代品但對剛接手H3C設備、沒有統(tǒng)一監(jiān)控平臺、或者要替客戶做例行巡檢的工程師來說比翻手冊高效得多。這篇文章就圍繞命令怎么選、執(zhí)行順序怎么排、輸出怎么判讀來講。2. 巡檢前先處理三件事登錄方式、會話設置和配置基線2.1 登錄方式怎么選Console、Telnet、SSH各有各的脾氣巡檢第一步是登錄設備但登錄方式選不對后面全白搭。常見做法是優(yōu)先走SSH因為它加密遠程改配置不會明文暴露Console口留給設備失聯(lián)或SSH登錄不了時的最后手段Telnet能用但明文傳輸我在生產環(huán)境基本不碰除非客戶內網隔離得足夠干凈。如果你用的是SecureCRT或者MobaXtermConsole登錄就是選Serial波特率9600數據位8無校驗。MobaXterm的Session面板里直接選Serial端口會自動識別USB轉串口的那個COM號連上后回車就能看到H3C的提示符。這里有個容易被忽略的點H3C設備默認不一定開啟SSH服務很多新拿到的設備只配了Telnet或者Console你直接用CRT去SSH連接會卡在“Connection failed”上——這不是密碼錯了是設備壓根沒開這個服務。在設備上按下面方式開啟SSH以Comware V7為主V5大體類似system-view ssh server enable # 創(chuàng)建一個本地用戶并讓它能通過SSH登錄 local-user admin class manage password simple YourPassword service-type ssh authorization-attribute user-role network-admin quit這段配置的關鍵在于local-user admin class manage里的service-type ssh。很多踩坑的人只開了ssh server enable忘了給本地用戶加SSH服務類型結果就是“密碼正確但登錄被拒”。V5設備上不用寫class manage直接local-user admin即可。巡檢建議不要用超級管理員賬號做日常登錄能用一個只讀級別賬號最好但現(xiàn)實是客戶給的往往是admin所以至少要做到巡檢時不亂敲配置命令。2.2 會話設置關閉分頁和日志回顯讓命令輸出不被截斷登錄之后先別急著敲巡檢命令把會話環(huán)境調好。H3C默認開啟分屏顯示輸出長一點就會停在---- More ----等你按空格。巡檢時如果你用的是CRT或MobaXterm這一屏一屏翻過去既慢又容易漏而且腳本批量操作時會直接卡死。我的習慣是登錄后先執(zhí)行下面兩條screen-length disable undo terminal monitorscreen-length disable在用戶視圖下執(zhí)行只對當前會話生效作用是臨時關閉分屏讓display輸出一次性完整滾出來不會卡在More上。注意它是“臨時”的重登就恢復默認所以不用擔心影響其他運維同事。undo terminal monitor是關掉終端的日志回顯——設備上有接口up/down、OSPF鄰居抖動之類的信息時會往終端刷屏把命令輸出和日志混在一起影響判斷。巡檢時把它關掉輸出干凈巡檢完建議重新登錄或者直接不管因為會話結束就恢復。還有一條容易被忽略但很重要先執(zhí)行display clock確認設備時間。日志里的事件時間全靠這個時鐘如果時間不對后面所有告警分析全是錯的。display clock這一步我一般放在會話設置之后、正式巡檢之前幾秒鐘的事但能避免后面分析日志時發(fā)現(xiàn)時間基準是歪的。常見做法是把display clock作為巡檢命令模板的第一條固定命令。2.3 巡檢前的基線備份先留后路再動手巡檢不只是“看狀態(tài)”還要和上次的狀態(tài)做對比所以巡檢前把當前配置備份下來是鐵律。很多剛入行的工程師習慣最后才備份但巡檢過程中可能會因為誤操作改到配置或者發(fā)現(xiàn)某個配置不對勁順手調了一下這時如果已經備份過至少有個后悔藥。display current-configuration save cfg-backup-YYYYMMDD.cfgdisplay current-configuration是查看運行配置輸出很長建議配合前面的screen-length disable一起用輸出重定向到本地保存。save命令是把運行配置保存到下次啟動的配置文件里文件名里帶上日期比如cfg-backup-20250611.cfg。需要注意save會覆蓋設備默認的啟動配置。如果只是巡檢、沒有改動需求不要隨便save如果確實改了配置需要保存先display current-configuration看一眼改動是否合理再執(zhí)行save。我見過有人巡檢時順手save結果把之前臨時調試用的interface shutdown配置固化了設備重啟后端口起不來——這就是典型的“巡檢變事故”。3. 日常巡檢命令組從硬件到日志一路查過來3.1 系統(tǒng)和硬件狀態(tài)版本、序列號、風扇、電源和溫度巡檢命令不是亂敲的我按“從底層到上層”的順序來。第一組關注設備本身能不能穩(wěn)定運行。display version display device display fan display power display environmentdisplay version看軟件版本和系統(tǒng)運行時間重點看版本是否已知有Bug以及設備是否剛重啟過。display device看板卡狀態(tài)重點看State是不是Normal如果有Fault就要留意了。display fan和display power分別看風扇和電源Status字段為Normal才算正常。display environment看溫度H3C設備一般有當前溫度、上下限閾值溫度接近上限說明機房通風有問題需要處理。這幾個命令都比較短輸出也不長適合巡檢模板開頭先打出來。如果設備是堆疊環(huán)境再加一條display irf看堆疊成員是否齊全、角色是否正常。堆疊設備巡檢漏掉IRF狀態(tài)是常見失誤——單臺設備看著正常但堆疊分裂了業(yè)務其實已經出問題了。3.2 接口與光模塊光衰怎么看、什么范圍算健康接口是交換機最核心的資源。巡檢時我通常先看接口概覽再重點查光模塊收發(fā)光。display interface brief display transceiver diagnosis interface Ten-GigabitEthernet 1/0/1display interface brief列出所有接口的Link狀態(tài)和Protocol狀態(tài)一眼就能看出哪些端口down了。如果某個關鍵業(yè)務端口down可能只是對端設備關機也可能是光纜斷了需要進一步排查。光模塊是另一個高頻問題點。display transceiver diagnosis interface會輸出光模塊的收發(fā)光功率、溫度、電壓等數字診斷信息。注意這個命令需要光模塊支持DDM數字診斷監(jiān)控功能原廠模塊基本都支持有些第三方模塊會顯示--這是模塊不帶監(jiān)控或兼容性問題不代表光路正常。紫光等國產設備命令風格與H3C相近也適用這個思路。光衰的參數解釋需要單獨說清楚收發(fā)光功率的單位是dBm數值越小表示功率越低。常見閾值是接收光功率在-3dBm到-14dBm之間屬于正常低于-20dBm就要警惕可能出現(xiàn)誤碼低于-27dBm基本會閃斷甚至完全不通。發(fā)送光功率一般比接收高不同模塊差異大但關鍵是看它是否穩(wěn)定不要忽高忽低。如果這條命令不支持退一步用display transceiver interface Ten-GigabitEthernet 1/0/0看模塊基礎信息至少能確認模塊是否被識別、溫度是否異常。3.3 CPU、內存與日志系統(tǒng)是否在“帶病運行”CPU和內存代表設備當前的負載日志則記錄它過去發(fā)生過什么。三者一起看才能判斷設備是健康還是“帶病運行”。display cpu-usage display memory display logbufferComware V7用display cpu-usageV5上是display cpu注意區(qū)分。CPU使用率看兩個值當前值和5秒內峰值。H3C交換機轉發(fā)主要靠芯片CPU高不一定影響轉發(fā)但如果長期超過50%要查是不是有大量控制報文沖擊比如ARP攻擊、路由震蕩。display memory看內存使用率長期超過70%就要關注是否有內存泄漏常見誘因是開啟了過多NetStream采樣或大量ACL統(tǒng)計。display logbuffer看的是設備內存里的日志緩沖區(qū)重點看有沒有反復出現(xiàn)的告警比如接口頻繁up/down、光模塊告警、協(xié)議鄰居震蕩。日志緩沖區(qū)容量有限如果設備長時間未重啟老日志會被覆蓋所以巡檢發(fā)現(xiàn)重要日志時建議用display logbuffer看完后關鍵內容截取保存。有一條命令容易被忽略display ntp-status。設備時間如果通過NTP同步這里能看到同步狀態(tài)。沒有NTP的設備日志時間會慢慢漂移出現(xiàn)問題后回溯時對不上時間點。巡檢時發(fā)現(xiàn)NTP未同步可以在后續(xù)整改時把NTP配置補上。3.4 鏈路與冗余聚合口、STP狀態(tài)看一眼更安心如果設備承擔著核心或匯聚角色鏈路冗余狀態(tài)必須納入巡檢范圍。display link-aggregation summary display stp brief display mac-addressdisplay link-aggregation summary看聚合口成員是否都在Selected狀態(tài)如果成員口是Unselected說明鏈路有問題或者對端配置不一致。display stp brief看STP端口狀態(tài)正常應該是FORWARDING出現(xiàn)BLOCKING不一定有問題——可能是冗余路徑故意阻塞但如果是應該轉發(fā)的端口在Blocking就要檢查配置了。display mac-address看MAC表項數量是否正常數量異常波動可能意味著環(huán)路或MAC漂移。這一組命令通常不用每次巡檢都完整執(zhí)行。我一般每周做一次完整巡檢時跑一遍每日快速巡檢只跑接口和CPU。4. 把命令固化成doc模板腳本采集和判讀標準一起落地4.1 doc模板怎么排先結構后命令別讓巡檢變成碰運氣“H3C交換機巡檢命令.doc”這個標題的關鍵在“doc”也就是巡檢模板本身。模板的價值在于固定順序、固定項目、留出判讀空間。我見過不少人把命令直接堆在一個文檔里巡檢時照著敲但輸出沒有對齊過幾天就忘了上次結果是什么。我習慣的模板結構分六塊設備基本信息、硬件狀態(tài)、接口狀態(tài)、光模塊、CPU內存、日志告警。每塊列出對應的命令、預期輸出字段、以及“正常/異常”判讀標準。設備基本信息用display version和display clock開頭記錄巡檢日期讓每次巡檢都有時間錨點。模板里給每條命令留一個“判讀”列不寫死結果而是寫閾值比如“CPU使用率50%峰值80%”這樣巡檢人有據可依。表格在doc里有獨特價值。比如光模塊判讀表參數正常范圍關注范圍異常范圍接收光功率-3dBm ~ -14dBm-14dBm ~ -20dBm低于-20dBm發(fā)送光功率穩(wěn)定在模塊標稱范圍波動超過3dB明顯衰減或無輸出模塊溫度低于報警閾值接近閾值超過閾值電壓標準值±5%偏差較大嚴重偏差這個表格我每次都會放進巡檢doc里比單純列命令有用得多。華為、思科、銳捷的命令與H3C有相似之處尤其華為和H3C同源display風格接近思科更偏show體系。做巡檢模板時如果團隊同時管多種設備建議按設備品牌分sheet命令不要混在一個模板里容易敲串。4.2 用Python批量采集命令輸出解放雙手但別盲目自動化手動逐條敲命令適合少數幾臺設備設備一多就容易漏。我自己會用Python的paramiko庫寫一個批量巡檢腳本把命令輸出按設備存檔。腳本邏輯很簡單連接設備→執(zhí)行命令列表→把輸出寫入txt文件。import paramiko import datetime devices [ {host: 192.168.1.10, username: admin, password: YourPass}, ] commands [ display clock, display version, display device, display interface brief, display transceiver diagnosis interface, display cpu-usage, display memory, display logbuffer, ] today datetime.datetime.now().strftime(%Y%m%d) 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) output_lines [] for cmd in commands: stdin, stdout, stderr ssh.exec_command(cmd \n, timeout30) output stdout.read().decode(utf-8, errorsignore) output_lines.append(f {cmd} ) output_lines.append(output) ssh.close() filename fh3c_{dev[host]}_{today}.txt with open(filename, w, encodingutf-8) as f: f.write(\n.join(output_lines)) print(f已保存 {filename})腳本里要注意幾個參數paramiko本身需要pip install paramiko安裝exec_command每執(zhí)行一條命令都是獨立的SSH會話命令之間不保留上下文所以screen-length disable這類會話級設置要放進每條命令之前或者在命令列表里把每條display命令后面加上分頁關閉參數。更穩(wěn)妥的方式是連接后先執(zhí)行screen-length disable但exec_command之間的會話不共享這確實是個坑。我一般會改成用ssh.invoke_shell()創(chuàng)建交互式shell先發(fā)screen-length disable再逐條發(fā)送命令這樣能模擬手動操作時的完整會話。timeout參數建議設30秒以上某些命令如display current-configuration在設備繁忙時會很慢超時太短會導致輸出截斷。4.3 判讀標準要寫在doc里輸出不等于結論采集完輸出最關鍵的是怎么判讀。很多巡檢表格只記了輸出原文沒有判讀結論這就失去了巡檢的意義。我建議doc模板里加一列“結論”用“正常/關注/異?！比龣n來標記。判讀的基本原則CPU和內存看是否超過基線接口看有沒有非預期down口光模塊看收發(fā)光是否在正常范圍日志看有沒有重復告警?；€數據從哪來來自設備穩(wěn)定運行期間的多次巡檢平均值。沒有基線單看一次輸出很難判斷CPU 40%是高還是低。如果發(fā)現(xiàn)異常doc模板里應該留“排查行動”欄寫下一步要做什么。比如光衰低于-20dBm行動是檢查尾纖是否彎折、法蘭是否松動、對端模塊是否正常。沒有行動項的巡檢報告客戶看了也不知道該怎么辦最后只能變成一張沒意義的表格。5. 巡檢避坑5個最常見的問題與排查思路5.1 現(xiàn)象CRT的SSH連不上H3C設備提示連接失敗或被拒絕原因H3C設備默認沒有開啟SSH服務或者本地用戶沒有SSH服務類型只開了Telnet。很多新交付的設備配置里只有Console和Telnet訪問遠程SSH 22端口并不存在。解決登錄Console口在系統(tǒng)視圖下執(zhí)行ssh server enable然后local-user admin class manage里加service-type ssh。檢查是否還有其他限制比如ACL限制了管理網段。排查時按順序看display ssh server status和display local-user確認服務開啟和用戶綁定都正確。5.2 現(xiàn)象執(zhí)行display命令輸出卡在More腳本或粘貼的命令被吞掉原因H3C默認開啟分屏輸出長度超過一屏就暫停等待輸入此時粘貼的后續(xù)命令會被當作翻頁操作吞掉導致命令不完整或誤操作。解決用戶視圖下執(zhí)行screen-length disable臨時關閉當前會話分屏。需要寫腳本批量巡檢時注意在每條命令前確保分頁已關閉如果是CRT手動操作登錄后第一件事就執(zhí)行這條命令。不要試圖用CRT的“自動發(fā)送空格”去翻頁那樣既慢又容易漏。5.3 現(xiàn)象光模塊收發(fā)光顯示--查詢不到任何數值原因光模塊不支持DDM數字診斷功能或者模塊與設備兼容性不佳導致設備讀取不到診斷數據。常見于第三方模塊。解決用display transceiver interface查看模塊基礎信息確認模塊是否被識別。如果基礎信息正常但無DDM數據只能更換支持DDM的原廠模塊否則光衰判斷無依據。巡檢模板里要特別標注哪些口是這類模塊避免每次巡檢都誤判為異常。5.4 現(xiàn)象日志里的時間與當前時間相差數小時告警分析對不上原因設備沒有配置NTP也沒有設置時區(qū)或者時區(qū)設置錯誤。Comware設備默認使用UTC時間國內環(huán)境需要手動設置UTC8時區(qū)。解決配置clock timezone Beijing add 8再配置NTP同步ntp-service enable、ntp-service unicast-server指向NTP服務器。巡檢時執(zhí)行display ntp-status確認同步狀態(tài)如果NTP服務器不可達至少手動校準clock datetime。不解決時間問題日志分析基本等于猜。5.5 現(xiàn)象巡檢時隨手save重啟后配置與預期不符原因save會把運行配置寫入啟動配置覆蓋原有配置文件。如果巡檢前設備上有臨時改動比如測試接口shutdown或臨時加了一條ACLsave會把它們固化導致重啟后行為改變。解決巡檢前用display current-configuration查看完整配置確認沒有臨時調試配置再執(zhí)行save。異常存儲時使用save cfg-backup-YYYYMMDD.cfg不要直接覆蓋默認啟動配置。設備多臺批量巡檢時尤其要注意別在腳本里自動save——腳本操作沒有人在現(xiàn)場確認配置狀態(tài)。6. 巡檢結果歸檔一張時間線表加一條救命習慣巡檢做完結果不能只留在終端里。我現(xiàn)在的習慣是每臺設備一個文件夾按日期命名里面放巡檢輸出txt、告警截圖、配置備份。文件夾里額外放一張歸檔說明表記錄巡檢日期、設備IP、關鍵判讀結論。日期設備CPU峰值內存峰值接收光衰最差日志告警結論2025-06-11核心-S7006X35%42%-13.5dBm無正常2025-06-04核心-S7006X42%45%-15.2dBm接口抖動1次觀察這張時間線表是判斷設備“是否在惡化”的核心依據。單次巡檢只能反映當下狀態(tài)多次巡檢拉出趨勢才能發(fā)現(xiàn)光衰在逐周下降、內存緩慢增長這類問題。沒有歸檔巡檢就只是重復勞動。還有一個習慣值得分享每次巡檢前先執(zhí)行display clock和display version這兩條命令的輸出是后續(xù)所有判讀的時間錨點和版本錨點。版本變了要知會變更流程時間不對要先校準再談日志分析。這個習慣幫我發(fā)現(xiàn)過兩次設備在夜間自動重啟的隱患重啟日志在logbuffer里被覆蓋了但版本運行時間出賣了它。日志集中化也是值得做的延伸網管平臺上用syslog-ng搭建一個日志服務把交換機日志實時收到服務器上巡檢時就多了一個歷史日志回溯的渠道。設備本地日志緩沖區(qū)再大也會被覆蓋集中化日志才是長期可追溯的方案。巡檢這件事本身不產生價值產生價值的是持續(xù)的對比和及時的行動。希望對你有幫助。本文還有配套的精品資源點擊獲取