簡介面向H3C交換機運維與管理場景這份實操型巡檢命令文檔匯總了設(shè)備日常健康檢查最常用的8類核心命令覆蓋CPU使用率、內(nèi)存占用、設(shè)備溫度、匯總信息、風扇與電源狀態(tài)、系統(tǒng)時間及接口狀態(tài)等關(guān)鍵監(jiān)測維度。每條命令均給出標準語法格式、回顯輸出示例及結(jié)果解讀能夠幫助管理員快速判斷設(shè)備運行是否正常及時發(fā)現(xiàn)并排查潛在故障隱患。資源包僅含1個doc文檔大小約21KB輕量便于下載后隨時查閱適合網(wǎng)絡工程師、數(shù)據(jù)中心運維人員及H3C設(shè)備管理員用于制定標準化巡檢清單或開展例行設(shè)備檢查。目前已有588人學習下載。文檔內(nèi)容以實際設(shè)備輸出為參照對CPU近期平均使用率、內(nèi)存使用率、熱點溫度告警閾值、風扇Normal/Abnormal判定等關(guān)鍵指標逐一做了說明讀者可直接對照自己設(shè)備的回顯信息進行健康度評估提升日常巡檢效率與故障定位準確性。1. H3C交換機巡檢命令為什么這套命令值得你背下來半夜被電話叫醒說核心交換機端口瘋狂閃斷業(yè)務時斷時續(xù)。趕到機房接console敲命令手忙腳亂——這種場景里一份H3C交換機巡檢命令清單就是后悔藥。它不是拿來應付檢查的而是幫你把CPU、內(nèi)存、端口、日志、堆疊、聚合口這些最常出問題的位置用最短時間掃一遍留下可對比的記錄。這套巡檢思路適合機房運維、中小企業(yè)網(wǎng)管也適合剛接手H3C設(shè)備的新人。下面從命令拆解到腳本落地把怎么用、參數(shù)怎么看、坑在哪一次講透。2. 巡檢前的基礎(chǔ)準備先解決登錄方式與基線存檔2.1 登錄H3C設(shè)備的三種方式Console、Telnet、SSH怎么選巡檢的第一步不是敲命令是能穩(wěn)定連上設(shè)備。H3C設(shè)備常見三種登錄方式各有各的適用場景。Console口是最后手段帶外管理不依賴業(yè)務網(wǎng)絡。交換機起不來、IP配置錯誤、SSH失效時只能靠它。但Console線比較嬌貴USB轉(zhuǎn)Console串口線的芯片兼容性是典型的“玄學”問題——有些便宜線在Windows 10/11下認不出串口驅(qū)動裝了一堆還是沒反應。建議手頭備一條FTDI芯片的轉(zhuǎn)接線別在深夜救火時掉鏈子。Telnet是明文協(xié)議在可信內(nèi)網(wǎng)里巡檢沒問題跨公網(wǎng)或半信任網(wǎng)絡就不要用了。H3C很多老設(shè)備默認開Telnet登錄密碼和配置命令全部明文抓包就能看到。生產(chǎn)環(huán)境能不開就不開至少要限制管理網(wǎng)段訪問。SSH是巡檢首選配置一次以后一直用。在H3C設(shè)備上開啟SSH的完整步驟system-view public-key local create rsa ssh server enable local-user admin password simple Admin123 local-user admin service-type ssh local-user admin authorization-attribute user-role network-admin ssh user admin service-type all authentication-type password quit save force這段配置做了四件事生成RSA主機密鑰、開啟SSH服務、創(chuàng)建本地用戶并授予network-admin角色、把這個用戶綁定到SSH服務。注意public-key local create rsa必須執(zhí)行否則SSH服務起不來save force一定要做否則重啟后配置丟失下次巡檢又連不上。實際登錄時我一般用SecureCRT就是網(wǎng)工常說的CRT或Xshell。CRT里建會話時選擇SSH2、端口22認證方式選password。有一個高頻坑H3C新版本默認只支持SSH 2.0老版本客戶端算法不匹配會直接報No compatible algorithm。這時候優(yōu)先升級客戶端別去設(shè)備上關(guān)算法那是自降安全級別。2.2 建立巡檢基線第一次巡檢先存檔后面才有對比巡檢最重要的不是看絕對值是看變化量。CPU利用率30%算不算高對一臺轉(zhuǎn)發(fā)量很小的接入交換機來說偏高對一臺跑著OSPF/BGP的核心設(shè)備來說很輕松。所以第一次巡檢時把每臺設(shè)備的輸出完整存一份這就是基線?；€存什么我一般分三層。第一層是身份信息display version、display device、display inventory記錄設(shè)備型號、序列號、軟件版本、單板狀態(tài)。設(shè)備升級、更換備件之后這些信息必須跟著更新否則半年后翻報告不知道當時跑的是什么版本。第二層是運行狀態(tài)display cpu、display memory、display interface brief、display fan、display power、display temperature這是每次巡檢必看的六條。第三層是協(xié)議與業(yè)務狀態(tài)display ospf peer、display bgp peer、display stp、display vlan、display mac-address看你網(wǎng)絡里實際跑了什么就存什么。接入交換機沒跑OSPF就不用存?；€的存檔格式我用一個簡單約定按設(shè)備IP建目錄文件名帶日期。inventory/192.168.10.1/20250610_display_cpu.txt inventory/192.168.10.1/20250610_display_interface_brief.txt inventory/192.168.10.1/20250610_logbuffer.txt不搞數(shù)據(jù)庫不搞CMDB純文本文件就夠了。后面做對比用diff拉兩個日期的文件看一眼diff inventory/192.168.10.1/20250501_display_interface_brief.txt inventory/192.168.10.1/20250610_display_interface_brief.txt有變化的地方diff會標出來哪里變了心里有數(shù)。比如某臺接入交換機多了一個Down端口或者聚合組成員數(shù)量變了diff一眼就能看到。提示基線不是存一次就完事。每次變更窗口后比如加VLAN、改聚合口、升級版本都要重新抓一次相關(guān)部分的輸出把基線滾到最新?；€過期了對比就沒意義。3. 核心巡檢命令逐條拆解CPU、內(nèi)存、端口、日志一個不落3.1 CPU與內(nèi)存display cpu 和 display memory 的關(guān)鍵指標CPU利用率是設(shè)備健康的晴雨表。H3C設(shè)備上執(zhí)行H3C display cpu Slot 1 CPU 0: CPU utilization statistics in 5 seconds: 3% CPU utilization statistics in 1 minute: 5% CPU utilization statistics in 5 minutes: 4%在單臺設(shè)備上這三行輸出很直觀。5秒瞬時值看一眼重點是1分鐘和5分鐘的均值。CPU持續(xù)在80%以上就要查是什么業(yè)務在吃資源。但display cpu看不到CPU占用是中斷高還是進程高。要往下挖一層用display cpu-usage task看具體進程占用或者用display cpu history看歷史曲線。有些型號還支持直接查看每個核的利用率多核設(shè)備某個單核跑滿是常見現(xiàn)象尤其是部署了ACL、NAT這類消耗CPU的業(yè)務時。這里順便說一句熱詞里常被問到的“CPU和vCPU關(guān)系”。在IRF堆疊環(huán)境或者H3C的虛擬化產(chǎn)品上物理機上多個vCPU共享物理核心在虛擬交換機里敲display cpu看到的利用率并不等于它在物理宿主機上的真實占用。做容量規(guī)劃時別拿總核數(shù)直接換算先看宿主機層面分配給這臺虛擬交換機的CPU份額。巡檢時出現(xiàn)虛擬交換機CPU高要去宿主機上看真實負載別只在虛擬層找原因很容易誤判。內(nèi)存看display memoryH3C display memory Slot 1: Memory utilization statistics in 5 seconds: 25% Memory utilization statistics in 1 minute: 23% Memory utilization statistics in 5 minutes: 22%這里有個容易踩的坑H3C不同軟件版本對“已用內(nèi)存占比”的計算基數(shù)不同。老版本Comware V5的25%和新版本Comware V7的25%含義不完全一樣V7把文件緩存也算進已用內(nèi)存?？绨姹緦Ρ葧r別直接比數(shù)值同一批設(shè)備同版本之間比才有意義。配套看單板狀態(tài)用display device這條命令輸出各單板、電源、風扇的運行狀態(tài)。巡檢時把它和display fan、display power、display temperature一起跑硬件層面就齊了。3.2 端口與鏈路display interface 輸出里的告警信號端口是故障高發(fā)區(qū)也是巡檢命令的重頭戲。先看總覽H3C display interface brief Interface Link Protocol InLoop PortType VLAN Description GE1/0/1 UP UP UP access 1 to-core GE1/0/2 DOWN DOWN DOWN access 10 office GE1/0/3 UP DOWN DOWN access 20 idle ...看Link和Protocol兩列。Link是物理層狀態(tài)Protocol是鏈路層協(xié)議狀態(tài)。物理UP、協(xié)議DOWN多半是配置問題比如VLAN沒放通、端口被shutdown物理DOWN直接查線纜和光模塊。如果Description里標注了業(yè)務信息比如to-core、to-print-server巡檢時一眼就能看出哪個端口重要選擇性地優(yōu)先處理。單端口詳細狀態(tài)用display interface GigabitEthernet1/0/1重點看Input/Output的錯誤計數(shù)H3C display interface GigabitEthernet1/0/1 GigabitEthernet1/0/1 Current state: UP Line protocol state: UP Description: to-core Bandwidth: 100000 kbps ... Input: 123456 packets, 789012 bytes Input errors: CRC: 0, FCS: 0, giants: 0, runts: 0 Output: 123456 packets, 456789 bytes Output errors: collisions: 0, aborts: 0, deferred: 0CRC錯誤持續(xù)增長是物理層問題的強信號——線纜老化、光模塊光功率下降、電磁干擾都會導致CRC。每次巡檢時記錄CRC數(shù)值下次對比有沒有增長比只看當前值可靠得多。光模塊狀態(tài)用display transceiver interface GigabitEthernet1/0/1Transceiver information: Transceiver type: 1000_BASE_SX_SFP Connector type: LC Wavelength: 850nm ... Diagnostic information: Temperature: 42 Celsius Voltage: 3.30 V Bias current: 6.2 mA TX power: -2.5 dBm RX power: -10.8 dBmRX power接收光功率是重點。不同模塊接收靈敏度不同一般-20dBm以下要警惕但最可靠的標準是看模塊本身的告警閾值——在display transceiver diagnosis里通常有高/低告警門限。TX和RX功率比剛裝機時掉3dB以上哪怕沒到閾值也要備好替換模塊。光模塊老化是不定時炸彈巡檢的意義就在于提前發(fā)現(xiàn)。3.3 日志與告警display logbuffer 與 trap 信息的篩選技巧日志是事故現(xiàn)場的監(jiān)控錄像。H3C設(shè)備日志默認存在logbuffer里用display logbuffer查看H3C display logbuffer Log buffer: 512 entries, 300 used, 212 free ... %Jun 10 03:22:15 2025 IFNET/3/LINK_UPDOWN: GigabitEthernet1/0/5 changed state to DOWN.日志條目多的時候翻屏不現(xiàn)實用管道加過濾條件H3C display logbuffer | include LINK_UPDOWN H3C display logbuffer | include PPPOE|IFNETinclude后面支持正則把多個關(guān)鍵字用|隔開一次篩完。巡檢時重點看兩類一類是LINK_UPDOWN、IFNET這類端口狀態(tài)抖動另一類是AAA、SSH、LOGIN這類登錄相關(guān)告警——如果有人深夜反復登錄失敗可能是暴力破解。Trap緩存用display trapbuffer查看。它和logbuffer內(nèi)容有重疊但更偏SNMP事件。巡檢時兩邊都看一眼重點看有沒有重復刷屏的告警一條端口up/down告警幾分鐘內(nèi)出現(xiàn)幾十次說明物理鏈路在抽風光模塊可能要報廢。display diagnostic-information是最后的兜底一條命令打包所有狀態(tài)信息輸出量大可以直接重定向到設(shè)備存儲里H3C display diagnostic-information diag.txt平時巡檢不必每次跑遇到疑難雜癥時配合抓包用。這份文件導出后發(fā)給H3C技術(shù)支持或自己留檔都是排查問題的完整素材。4. 把巡檢命令變成腳本批量執(zhí)行與結(jié)果歸檔的落地做法4.1 用 plink 批處理跑批量巡檢的最小腳本設(shè)備數(shù)量一多一臺臺敲命令不現(xiàn)實。最輕量的做法是用plinkPuTTY自帶的命令行工具加Windows批處理不需要裝額外軟件。先準備命令清單文件注意第一行必須是關(guān)分頁的命令screen-length disable temporary display version display device display cpu display memory display interface brief display logbufferscreen-length disable temporary是H3C設(shè)備關(guān)閉分頁顯示的臨時命令。不關(guān)分頁的話輸出超過一屏設(shè)備會停下來等待按鍵腳本就會卡死這是所有自動化連網(wǎng)絡設(shè)備的第一個坑。批處理腳本echo off set HOST192.168.10.1 set USERadmin set PASSAdmin123 plink -ssh -l %USER% -pw %PASS% -batch -m commands.txt %HOST% output_%HOST%.txt-m參數(shù)讓plink逐行執(zhí)行commands.txt里的命令-batch跳過主機密鑰確認和交互提示。如果plink版本支持-pwfile可以用它代替-pw密碼不直接暴露在命令行參數(shù)里更安全。這個腳本會把所有命令的輸出拼到一個文件里不方便按命令歸檔。改進一下用循環(huán)逐條執(zhí)行echo off set HOST192.168.10.1 set USERadmin set PASSAdmin123 set DATE%date:~0,4%%date:~5,2%%date:~8,2% for /f %%i in (commands.txt) do ( echo %%i output_%HOST%_%DATE%.txt plink -ssh -l %USER% -pw %PASS% -batch %HOST% %%i output_%HOST%_%DATE%.txt )%date:~0,4%%date:~5,2%%date:~8,2%是拼接當天日期的寫法生成類似20250610的文件名。注意for循環(huán)內(nèi)部引用變量要用%%i而不是%i這是批處理的經(jīng)典翻車點第一次寫很容易錯。4.2 用 Python 做閾值解析與結(jié)果歸檔批處理適合快速抓取要做閾值判斷和格式化報告還是Python方便。用netmiko庫連設(shè)備它能自動處理交互和分頁from netmiko import ConnectHandler import re device { device_type: h3c, ip: 192.168.10.1, username: admin, password: Admin123, } with ConnectHandler(**device) as conn: conn.send_command(screen-length disable temporary) cpu_output conn.send_command(display cpu) mem_output conn.send_command(display memory) intf_output conn.send_command(display interface brief) cpu_match re.search(rCPU utilization statistics in 5 seconds:\s*(\d)%, cpu_output) mem_match re.search(rMemory utilization statistics in 5 seconds:\s*(\d)%, mem_output) cpu_usage int(cpu_match.group(1)) if cpu_match else -1 mem_usage int(mem_match.group(1)) if mem_match else -1 if cpu_usage 80 or mem_usage 80: print(f[WARN] {device[ip]} CPU{cpu_usage}% MEM{mem_usage}%)with ConnectHandler會自動登錄并在退出時斷開連接screen-length disable temporary先關(guān)分頁后面每條命令的輸出就不會被截斷。正則從輸出里抽出百分比數(shù)值超過閾值打印告警。再補充一個統(tǒng)計DOWN端口的片段down_ports re.findall(r(\S)\sDOWN, intf_output) if down_ports: print(f[INFO] {len(down_ports)} down ports: {down_ports})這個片段批量巡檢上千臺接入交換機時很實用只把有異常的設(shè)備列出來正常的直接忽略。4.3 為什么我不推薦現(xiàn)成的“一鍵生成命令工具”有人把巡檢命令封裝成Web工具填I(lǐng)P、用戶名密碼一鍵跑完所有命令生成報告。這類工具有個共同問題把設(shè)備密碼交給第三方頁面命令執(zhí)行過程不可審計。出故障時拿著工具生成的報告別人問“這條命令的輸出完整嗎中間有沒有失敗的命令”你答不上來。自己維護一套腳本雖然土但每一步都在掌控里。腳本本身就是你的巡檢知識庫加了什么命令、改了哪個參數(shù)同事接手時看腳本就懂。做運維可控比方便重要。5. H3C巡檢避坑手冊堆疊、聚合口、日期同步與模擬器5.1 IRF堆疊巡檢display irf 的輸出怎么看H3C的堆疊叫IRF多條物理鏈路把兩臺或多臺設(shè)備虛擬成一臺邏輯設(shè)備。巡檢IRF環(huán)境第一件事是看成員是否完整H3C display irf Member Role Priority CPU MAC Description *1 Master 32 1 000c-29a0-xxxx Member 2 Standby 15 2 000c-29a1-yyyy Member*1表示當前登錄的設(shè)備是Master帶的是本設(shè)備。巡檢要點成員設(shè)備里必須存在Standby角色如果全是Master沒有備說明堆疊分裂了——這是大故障。正常情況下堆疊里的Master和Standby各司其職Standby的優(yōu)先級低于Master防止異常重啟后角色漂移。用display irf topology看拓撲是否完整兩個成員之間堆疊鏈路應該顯示正常。堆疊分裂是H3C網(wǎng)絡里最嚴重的故障之一成員設(shè)備之間堆疊線斷了每臺設(shè)備都認為自己是Master全網(wǎng)路由被攪亂業(yè)務直接癱瘓。巡檢時發(fā)現(xiàn)成員數(shù)量少了或者拓撲不完整要馬上處理不能等。5.2 聚合口“滿了”display link-aggregation 的邊界判斷聚合口滿通常有兩層意思一是成員端口數(shù)量到了上限二是流量hash不均導致單個成員端口打滿。巡檢先看聚合概要H3C display link-aggregation summary Aggregation Interface Type Oper Status Member Ports Bridge-Aggregation1 Static UP GE1/0/1 GE1/0/2重點看Oper Status和Member Ports。Oper Status不是UP聚合口就是壞的Member Ports比預期少先查被移除的端口為什么掉線。聚合口成員數(shù)量有上限不同設(shè)備平臺限制不同端口滿了再加不進去業(yè)務側(cè)就會看到帶寬不夠的瓶頸。流量hash不均的問題光看summary看不出來。用display counter rate interface看成員端口的實時流量H3C display counter rate interface GigabitEthernet1/0/1 H3C display counter rate interface GigabitEthernet1/0/2兩個成員端口一個跑滿一個閑置就是hash策略的問題。常見原因聚合成員數(shù)不是2的冪次3條、5條這種或者業(yè)務流量源目MAC太少導致hash不到所有成員。解決思路是調(diào)整聚合的hash模式或者把成員數(shù)補到2的冪次。這個故障在熱詞里被搜成“聚合口滿了”實際排查路徑就是這么幾步不用急。5.3 設(shè)備時間不同步NTP配置與巡檢時間戳陷阱設(shè)備時間不準是個低頻但致命的問題。H3C S1850這類設(shè)備默認時間可能停在出廠狀態(tài)日志時間戳跟著錯。巡檢時看logbuffer發(fā)現(xiàn)事件時間和你對不上第一反應先看display clock。同步時間最省心的方式是NTP配置三條命令system-view ntp-service enable ntp-service unicast-server 192.168.10.254檢查同步狀態(tài)H3C display ntp-service status Clock status: synchronized Clock stratum: 3 ...關(guān)鍵看Clock status。顯示synchronized說明已同步顯示unsynchronized說明沒同步上檢查NTP服務器是否可達、UDP 123端口是否被防火墻攔截。熱詞里“h3c s1850 自動同步網(wǎng)絡日期和時間”說的就是這套NTP配置。時間不同步的巡檢陷阱在排查故障時暴露設(shè)備日志里的時間和你手表差好幾個小時拿著日志去對業(yè)務異常時間點怎么都對不上?？鐧C房、跨時區(qū)場景更明顯。我的巡檢報告里會把每臺設(shè)備的時鐘偏差記下來偏差超過1分鐘的列為一類隱患攢夠一批集中處理。5.4 模擬器與真機差異H3C模擬器設(shè)備啟動失敗怎么排查熱詞里“h3c模擬器設(shè)備啟動失敗”“h3c虛擬化軟件設(shè)備啟動失敗”被搜得很多。我自己用HCLH3C Cloud Lab練巡檢命令時也踩過不少坑。常見失敗原因有三個。第一模擬器和VirtualBox版本沖突。HCL老版本依賴特定VirtualBox版本升級VirtualBox后設(shè)備起不來報錯信息又很模糊。解決方式是卸載當前VirtualBox重新安裝HCL自帶或官方文檔指定的版本。第二嵌套虛擬化沒開。在虛擬機里跑HCL需要CPU支持并開啟VT-x/AMD-VBIOS里沒開的話設(shè)備啟動直接失敗。物理機上跑則要確認BIOS虛擬化功能是Enable。第三設(shè)備鏡像啟動慢。HCL里的設(shè)備啟動經(jīng)常要兩三分鐘界面看起來像卡死了實際在后臺跑。別急著關(guān)掉重開等兩分鐘再看不遲。模擬器練的是命令流程和配置思路練不了真機的溫度和光功率——這兩項在模擬器里沒有對應輸出。別在模擬器里找display temperature的輸出樣式真機上才有省得白費功夫。6. 巡檢報告的提煉與驗證一張表說清設(shè)備健康度采集了命令輸出最后一步是把原始文本翻譯成能給別人看懂的結(jié)論。我習慣用一張健康度表匯總每臺設(shè)備一行檢查項巡檢命令良好需關(guān)注故障CPUdisplay cpu均值50%50-80%80%持續(xù)內(nèi)存display memory60%60-80%80%端口CRCdisplay interface無增長單端口少量持續(xù)增長光功率display transceiver在閾值內(nèi)接近閾值超閾值設(shè)備時間display clock/ntp-service statussynchronized偏差1分鐘unsynchronizedIRF堆疊display irf成員齊全缺Standby分裂鏈路聚合display link-aggregation summary成員完整UP少成員整組DOWN這張表就是巡檢報告的骨架。每臺設(shè)備按檢查項打勾綠色正常、黃色關(guān)注、紅色故障出問題的設(shè)備附上關(guān)鍵輸出片段。網(wǎng)管拿這個表能直接決定要不要處理、什么時候處理不用再翻了原始輸出找結(jié)論。驗證方法是必須做的一步腳本跑完之后抽一臺設(shè)備手動連上去敲同一條命令對比輸出是否一致。自動化和手動結(jié)果不一致多半是分頁沒關(guān)、命令寫錯或者登錄到了錯誤的設(shè)備——跳板機轉(zhuǎn)發(fā)配置錯了腳本連的是A臺你以為在查B臺。這個習慣幫我抓出過一次腳本里IP寫反的低級錯誤從那以后每次跑完批量巡檢都抽檢一臺。我的固定節(jié)奏是每月1號和15號跑全量巡檢變更窗口后加跑一次關(guān)鍵設(shè)備。積累半年回頭看這些報告哪臺設(shè)備的CRC在緩慢增長、哪臺CPU均值在悄悄爬升一目了然。這套笨辦法比任何監(jiān)控系統(tǒng)都靠譜——監(jiān)控系統(tǒng)告訴你“現(xiàn)在壞了”巡檢報告告訴你“快要壞了”。希望幫到你。本文還有配套的精品資源點擊獲取