企业官网建设流程全解析

简介：H3C交换机巡检命令是一份面向网络管理员与运维人员的实用文档，系统梳理了H3C系列交换机日常巡检中最常用的8条命令，覆盖CPU使用率、内存占用、设备温度、设备汇总信息、风扇状态、电源状态、系统时钟及接口状态等关键检查项。每个命令均给出标准格式、作用说明和输出示例，并附有简要解释，帮助读者快速判断设备是否处于健康状态，定位潜在隐患。文档为单个doc文件，大小21KB，便于下载后直接查阅或打印作为现场巡检参考。目前已有588人学习下载，适合正在负责H3C设备维护、需要建立标准化巡检流程的初学者或一线工程师使用。通过对照文中命令与输出字段，可有效提升日常巡检效率，减少因硬件故障或资源占用过高导致的业务中断风险。

1. H3C 交换机巡检命令：一份能直接对着终端敲的 11 条清单

深夜 23 点被电话叫醒，核心交换机的温度告警刷了半屏，原因很简单：白天巡检只看了 CPU 和接口，风扇、电源没人核对。从那以后我把巡检收敛成一句话——H3C 交换机巡检命令的核心，就是按固定顺序把 display 命令敲一遍并逐项核对。CPU、内存、温度、风扇、电源、设备信息、接口、版本、序列号、运行配置，这 11 条命令覆盖一台交换机的主要健康面。这份文档整理的是一台 H3C S5500-34C-HI-D 在 Comware 5.20 Release 5203P03 下的实测输出，命令和判断标准都是现成的。刚接手 H3C 设备、需要做定期巡检的人可以照抄；想把巡检写成脚本的工程师，也能拿它当基线参考。

2. 命令解读：把 display 系列输出拆成四个维度看

2.1 CPU 与内存：使用率只是第一层信息

CPU 和内存是巡检最先看的两项，因为它们直接反映设备负载。文档里 CPU 命令的实测输出是这样的：

<H3C>display cpu-usage Slot 1 CPU usage: 6% in last 5 seconds 5% in last 1 minute 5% in last 5 minutes

三档采样窗口的用途不同。5 秒档是瞬时值，适合看正在发生的冲击；1 分钟和 5 分钟档是趋势值，适合判断设备是不是长期高负载。我一般以 5 分钟档为基线，5 秒档只作为"现在是否正在忙"的参考。如果 5 秒档和 5 分钟档差距很大，比如 5 秒档 60%、5 分钟档只有 8%，说明有个突发任务正在执行，不是常态；如果两档都在高位，那才是持续过载。

再看内存：

<H3C>display memory System Total Memory(bytes): 874453360 Total Used Memory(bytes): 117120680 Used Rate: 13%

这里有个容易被忽略的细节：Total 874453360 bytes 换算下来约 834MB，而 display version 里标称 1024M bytes SDRAM。两者对不上是正常的，标称 1024M 是物理内存总量，系统会把一部分保留给内核和数据转发面，display memory 显示的是系统可管理内存。

文档里 Used Rate 13% 这个数值并不可怕，但我建议把 Total Used Memory 的绝对值记录下来。原因是 Comware 5.20 的 Used Rate 包含缓存和缓冲，单看百分比容易被"看起来不高"骗过去。正确做法是每次巡检记下 Used 绝对值，下次对比，如果持续上涨且没有业务增长，才需要怀疑内存泄漏。

2.2 温度、风扇、电源：硬件健康三件套

硬件三件套里，温度信息最容易看错。文档里的 display environment 输出：

<H3C>display environment Slot 11 System temperature information (degree centigrade): ------------------------------------------------------------------------------- Sensor Temperature LowerLimit WarningLimit AlarmLimit ShutdownLimit Inflow 1 32 0 67 72 NA hotspot 1 38 0 77 82 NA

Inflow 表示入风口温度传感器，hotspot 表示热点温度传感器。S5500 的"设备温度"通常指热点温度，也就是 hotspot 这一行。文档里这台机器 hotspot 38 度，距离 WarningLimit 77 度还有很大余量。需要特别注意的是，有人会把 LowerLimit 当成"过冷告警"，实际这档对交换机意义不大，机房环境很难把设备冻到 0 度以下；真正要盯的是 Warning 和 Alarm 两档。

风扇和电源简单直接：

<H3C>display fan Slot 1 FAN 1 State : Normal <H3C>display power Slot 1 Input Power : 63(W) Power 1 State : Normal Type : AC/150(W) Power 2 State : Fault Type : Unknown

文档里的 Power 2 是 Fault 状态，这恰好是巡检最该发现的问题——双电源设备一路电源损坏，另一路还在工作，业务没受影响，但冗余已经丢了。如果这台电源再出问题，设备直接断电。所以看到这样的输出，巡检记录里必须标记"电源冗余失效"，而不是只写一句"电源异常"。

2.3 设备身份与运行时长：display device verbose 与 display version

这两条命令的价值在于"确认自己管的是谁"。文档输出：

<H3C>display device verbose Slot 1 SubSNo PortNum PCBVer FPGAVer CPLDVer BootRomVer AddrLM Type State 0 30 REV.B NULL 003 210 IVL MAIN Normal slot 1 info: Up Time : 10 weeks, 0 days, 6 hours, 26 minutes Brd Type : H3C S5500-34C-HI-D Brd Status : Master Sft Ver : 5.20 Release 5203P03

Up Time 是关键字段。它表示设备连续运行了多长时间。如果两次巡检之间 Up Time 变小，说明设备重启过。Brd Status 显示 Master，说明这台设备在 IRF 堆叠中处于主设备角色；如果和它堆叠的成员设备出问题，会直接影响转发。

再配合 display version 看硬件和软件细节：

<H3C>display version H3C Comware Platform Software Comware Software, Version 5.20, Release 5203P03 H3C S5500-34C-HI-D with 2 Processors 1024M bytes SDRAM 4096K bytes Nor Flash Memory 512M bytes Nand Flash Memory [SubSlot 0] 24GE+4SFP+2SFP PLUS Hardware Version is REV.B

[SubSlot 0] 后面的 24GE+4SFP+2SFP PLUS 说明这块板卡是 24 个千兆电口加 4 个 SFP 光口加 2 个 SFP PLUS 万兆口。这解释了后面 display interface brief 里为什么 GE1/0/1 到 GE1/0/28 是电口和光口混排，XGE1/0/29 和 XGE1/0/30 是万兆口。版本号 Release 5203P03 里的 P03 是小版本，遇到疑难问题报障时，这个字段必须原样提供给厂家。

2.4 接口状态与运行配置：链路健康与配置归档

display interface brief 的输出分两段，route mode 和 bridge mode。对于纯二层接入场景，重点看 bridge mode 这段：

Interface Link Speed Duplex Type PVID Description GE1/0/1 UP 1G(a) F(a) A 1 GE1/0/2 UP 100M(a) F(a) A 1 GE1/0/3 DOWN auto A A 1

Link 列是物理链路状态，UP 表示有设备连接且物理链路正常；DOWN 表示没有对端或线路断开。Speed 和 Duplex 后面的 (a) 表示 auto 协商，F(a) 是自动协商后的全双工。Type 列 A 是 access、T 是 trunk、H 是 hybrid，PVID 是端口所属 VLAN。如果看到某个 trunk 口 DOWN，它比 access 口 DOWN 更值得关注，因为 trunk 口通常连接上级交换机或服务器，DOWN 意味着上联断了，业务大概率受影响。

最后是 display current-configuration。这条命令输出最长，文档里的关键配置包括 local-user unipower 的 authorization-attribute level 3、service-type ssh telnet terminal、snmp-agent community read gpdc_lan、vty 0 15 authentication-mode scheme。巡检时我不逐行看，重点确认三件事：管理账号是否还在、SSH 是否开启、SNMP 读团体字是否和网管平台一致。如果账号清单里出现不认识的用户，或者 SNMP 团体字被改过，这是比接口 DOWN 更需要警惕的信号。

3. 巡检指标判断：哪些数字要紧张，哪些可以放手

3.1 CPU 三档平均值的正确打开方式

CPU 使用率的判断，我见过两种典型误判。一种是看到 5 秒档冲到 40% 就紧张，实际上 5 秒档是瞬时值，Comware 设备在做周期性 ARP 扫描或路由收敛时，CPU 短时间抬高很正常；另一种是只盯 5 分钟档，完全忽略瞬时冲击，结果设备周期性丢包却查不出原因。

我的判断顺序是：先看 5 分钟档是否超过 60%，超过再看 1 分钟档和 5 秒档是否同步抬高。如果三档同步高，说明设备持续繁忙，这个时候要查是不是有广播风暴、环路，或者某台服务器在大量收发报文。如果只有 5 秒档高，等几分钟再看一次，回落了就不用管。要注意的是，这台 S5500 是三层交换机，如果启用了路由功能，CPU 还要处理路由协议报文和软件转发，同样的使用率阈值，在三层模式和纯二层模式下含义不同。

3.2 温度阈值四档的边界纪律

设备温度有四档：LowerLimit、WarningLimit、AlarmLimit、ShutdownLimit。文档里这台 S5500 的 hotspot 是 Warning 77 度、Alarm 82 度，Inflow 是 Warning 67 度、Alarm 72 度，ShutdownLimit 是 NA，表示该传感器没有硬件关机保护。

我的处理原则是：hotspot 超过 Warning 前 5 度就开始关注，超过 Warning 就必须现场处理。因为温度是渐变指标，从 77 度涨到 82 度可能只需要十几分钟，等到了 Alarm 再处理，留给你的时间窗口很短。场景上，夏季机房空调故障时，温度上升速度比想象中快得多。如果 hotspot 和 Inflow 的温差过大，超过 15 度，优先怀疑风扇转速异常或风道堵塞，而不是空调问题。

3.3 接口 DOWN 不等于故障：分清 ADM、Link down 和 Type

初次巡检的人最容易犯的错，是看到一屏 DOWN 就以为设备坏了。实际上未接线的普通接入端口，物理链路本来就是 DOWN，这是正常状态。

真正要分清楚的是三种情况。第一种是 Link 列显示 ADM，那是 administratively down，端口被管理员手动 shutdown 了，属于人为保留端口；第二种是 Link 列 DOWN 但端口接了线，可能是对端关机、网线断开或光模块故障；第三种是端口以前 UP，这次巡检变成 DOWN，变化本身才是问题。所以巡检要留历史记录，对比"上次 UP 这次 DOWN"的端口，而不是按端口总数判断。另外，Type 是 trunk 的接口 DOWN 优先级最高，它直接影响跨交换机通信；access 口 DOWN 一般只影响一台终端。

3.4 电源 Fault 与风扇 Abnormal 的处置顺序

文档里的电源输出是个很好的案例：Power 1 Normal，Power 2 Fault。设备还能正常工作，是因为单电源供电足以支撑当前负载，但冗余已经失效。处置顺序应该是：先确认设备的实际功耗和当前电源的负载能力，比如这台输入功率 63W，电源规格是 AC/150W，单电源带载没问题；然后联系备件，安排变更窗口更换 Fault 电源；在更换之前，不要做任何可能增加设备功耗的操作，比如插更多光模块。

风扇的处置更紧迫。风扇 Abnormal 时设备散热能力下降，温度会快速上升，尤其在机房空调不给力的情况下。看到风扇异常，我的习惯是同时盯温度传感器的读数，如果 hotspot 在 10 分钟内涨了超过 5 度，直接准备备件更换，别等它到 Warning 再动手。

4. 批量巡检：用 Python 脚本把 11 条命令串成一条流水线

4.1 为什么推荐用脚本而不是一条条敲

如果只有一两台设备，手工敲命令没问题；设备超过五台，逐条敲就变成体力活，而且很容易漏命令。常见的做法是借助 SecureCRT 的 plink 批处理或者写脚本。SecureCRT 可以加载命令文件批量发送，适合简单的"敲完就收日志"场景；但它的输出解析能力弱，做不到自动判断异常。所以我更倾向于用 Python 加 pexpect 库，把登录、执行、分页处理、关键字检查一次性做完。

如果你之前接触过华为交换机，会发现这套思路完全通用——H3C 和华为的 display 命令大量互通，脚本改一下提示符匹配规则就能在两家的设备上跑。

4.2 pexpect 巡检脚本：登录、关分页、逐条执行

#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ H3C 交换机批量巡检脚本 流程：SSH 登录 -> 关闭分页 -> 逐条执行命令 -> 关键字健康检查 -> 输出报告 依赖：pip install pexpect """ import pexpect import datetime # 设备清单，按需增删；host/user/passwd 三项必填 DEVICES = [ {"host": "192.168.0.100", "user": "unipower", "passwd": "ChangeMe"}, ] # 巡检命令，与文档 1.1~1.11 保持一致 CMDS = [ "screen-length disable", # 关闭分页，避免长输出卡在 ---- More ---- "display cpu-usage", "display memory", "display environment", "display fan", "display power", "display clock", "display interface brief", "display device verbose", "display version", "display device manuinfo", "display current-configuration", ] # 输出里命中这些关键字就判定为异常 ALERT_WORDS = ["Abnormal", "Fault", "ShutdownLimit"] def check_output(text): """逐行匹配告警关键字，返回异常列表""" hits = [] for word in ALERT_WORDS: if word in text: hits.append(word) return hits def run_one(dev, log_dir="inspection"): child = pexpect.spawn( "ssh -o StrictHostKeyChecking=no %s@%s" % (dev["user"], dev["host"]), timeout=30, encoding="utf-8", ) # 处理密码提示，出现 password 关键词后发送密码 i = child.expect(["(P|p)assword:", pexpect.EOF, pexpect.TIMEOUT], timeout=20) if i != 0: print(dev["host"], "login failed") return child.sendline(dev["passwd"]) child.expect(r"[>#]") # 等待用户视图提示符 report = [] for cmd in CMDS: child.sendline(cmd) # 遇到 ---- More ---- 就发空格翻页；等提示符出现则认为命令执行完 while True: m = child.expect([r"---- More ----", r"[>#]"], timeout=10) if m == 0: child.send(" ") else: break # 读回本命令输出并做关键字检查 text = child.before hits = check_output(text) report.append((cmd, hits)) print("[%s] %s -> %s" % (dev["host"], cmd, hits if hits else "OK")) child.sendline("quit") child.close() # 写巡检报告 fname = "%s/%s_%s.txt" % (log_dir, dev["host"], datetime.datetime.now().strftime("%Y%m%d_%H%M")) with open(fname, "w", encoding="utf-8") as f: for cmd, hits in report: f.write("%s : %s\n" % (cmd, ";".join(hits) if hits else "OK")) print("report ->", fname) if __name__ == "__main__": for dev in DEVICES: run_one(dev)

这段脚本有几个关键设计。第一，screen-length disable 放在命令列表第一位，这是 H3C 设备批量操作的前提，如果不关闭分页，display current-configuration 这种长输出会卡在 ---- More ---- 上；这个设置只对当前会话有效，不影响其他登录用户。第二，登录后的提示符匹配用的是[>#]，覆盖用户视图和系统视图两种提示符，避免命令在不同视图下执行失败。第三，处理 ---- More ---- 的逻辑放在了循环里，遇到分页发空格，直到提示符出现才认为命令执行完。

参数使用上，timeout=30 是单条命令的等待上限，如果你的设备响应慢，可以调到 60；encoding="utf-8" 是为了避免中文注释或设备返回的非 ASCII 字符导致解码报错。ALERT_WORDS 里的三个词覆盖了风扇、电源和温度告警，如果你还想检查接口错误计数，可以在列表里追加 "error" 或 "CRC"。

4.3 输出健康检查：关键词命中与巡检报告

脚本跑完后，每个命令只会显示 OK 或命中的关键词。这里要说明一个边界：关键词检查是粗筛，命中 Fault 一定是告警，但没命中不代表设备完全健康。比如接口的 CRC 错误计数、CPU 使用率超过 70% 这类问题，关键字里没有覆盖，需要靠人工看报告里的具体数值才能判断。

所以脚本生成的报告文件我建议保留全量输出，而不是只存"OK/异常"结果。把每台设备的输出存成带时间戳的文本文件，就是在给下一次巡检留对比样本。我的习惯是巡检报告按日期归档，目录结构是 inspection/20240615/，里面每台设备一个文件。这样到了月底，可以翻出同一台设备的历史报告，对比 Up Time、CPU 趋势和温度变化。

另外要注意脚本的权限前提：登录用户需要有足够的命令执行权限。文档里的 local-user unipower 配置了 authorization-attribute level 3，能执行所有 display 命令和 screen-length disable；如果账号只有 level 1，display current-configuration 都会被拒绝。这是批量巡检最容易踩的坑，下文具体说。

5. 巡检常见问题排查：五个翻车案例与解决记录

5.1 现象：display interface brief 里一屏 DOWN，以为链路大面积故障

第一次拿这份文档去巡检的人，看到 GE1/0/3、GE1/0/12、GE1/0/14 这些端口全是 DOWN，很容易在巡检单上写"大量端口 DOWN"。原因其实很朴素：这些端口根本没有接线。交换机的接入端口默认就是物理 DOWN，只有插了网线或光模块并和对端协商成功才会 UP。解决方法是先对号入座——把端口 Description 和实际布线表对一遍，没有业务规划的端口 DOWN 直接忽略。真正要记录的是链路状态的变化，也就是"上次 UP 这次 DOWN"的端口。从那以后我每次巡检只对比变化量，不数 DOWN 的总数，误报率降了一大截。

5.2 现象：display memory 的 Used Rate 只有 13%，判定内存非常健康

百分比低不等于没问题。Comware 5.20 的内存统计里，Used Rate 包含了文件缓存等可回收部分，业务模块实际占用的内存在这个输出里看不全。遇到过一台设备 Used Rate 长期 20% 以下，但业务模块内存池耗尽，表现为登录慢、转发丢包。解决方法是结合 display memory pool 看按模块划分的内存池占用，以及跨天对比 Total Used Memory 的绝对值。如果绝对值每周涨几个百分点且业务无变化，比单纯盯着 Use Rate 更有参考价值。

5.3 现象：设备 display environment 显示 hotspot 38 度，网管平台却报温度告警

设备侧温度不高，网管却告警，这种不一致很常见。原因有两种：一是网管平台采集的是 Inflow 即入风口温度，而设备侧你只看 hotspot 热点温度，两者本来就不是同一个传感器，入风口 67 度已经接近 Warning，热点 38 度当然显得"正常"；二是网管平台的告警阈值是模板默认值，和这台设备的实际 WarningLimit 不一致。解决方法是以设备侧的 display environment 实测值为准，把网管平台的传感器类型和阈值重新核对一遍，重点确认网管告警对应的是哪一行 Sensor 数据，而不是只对温度数值。

5.4 现象：display device manuinfo 里 Power 项报错，以为设备的制造信息查不到

文档里的输出就很典型：Power 1 显示不支持该操作，Power 2 显示无法显示制造信息，但 Slot 1 的 DEVICE_SERIAL_NUMBER 是完整的。原因是一些电源模块内部没有存储制造信息的芯片，或者固件不支持回读功能，报错不是设备故障。序列号以 DEVICE_SERIAL_NUMBER 为准，电源模块的序列号如果平台没绑定，可以用设备序列号加端口位置描述来管理，不影响维保。遇到这种情况不用报障，在设备台账备注"电源模块不支持读取"就行。

5.5 现象：脚本执行到 display current-configuration 卡住不动，超时没反应

这是批量巡检最常见的翻车点。display current-configuration 输出几百行，终端一屏装不下，设备会停在 ---- More ---- 等待输入，脚本如果没有处理分页符，就会一直等下去直到超时。原因就是前面说的分页机制。解决方法是登录后先执行 screen-length disable 关掉当前会话的分页，或者在代码里遇到 ---- More ---- 就发一个空格继续翻页。顺带说一句，SecureCRT 的批处理发送命令文件时也会遇到同样问题，命令文件里第一行就要写 screen-length disable，不然后面的命令全被卡住。这条经验是从一次误操作里总结出来的——那次批处理跑了半小时，实际只执行了两条命令，剩下的全卡在分页符上。

6. 把巡检沉淀成基线：阈值表、记录模板与 Up Time 对比

巡检不能停留在"敲完命令看完数字"。要让巡检真正有效，得把指标变成一张可以横向对比的基线表。我基于这份文档的输出，整理了一张适合 S5500 系列的基础阈值表：

这张表里的温度处理线直接取自已文档的 WarningLimit，CPU 和内存的线是我按 S5500 的实际运行经验给的参考值。如果你的设备型号不同，首先要改的是温度阈值，以 display environment 输出的实际 WarningLimit 为准，不要沿用我这边的数字。

巡检记录我建议固定成一行一项的格式，方便后期直接粘进表格：日期时间、设备 IP、CPU 5 分钟档、内存 Used 绝对值、热点温度、风扇状态、Power 1 状态、Power 2 状态、异常接口数、Up Time、备注。备注里写"Power 2 Fault，已报备件""GE1/0/5 从 UP 变 DOWN，业务确认中"这类具体事项。

我最想强调的验证手法是 Up Time 对比。display device verbose 里的 Up Time 是设备的连续运行时长，把上次巡检记录和本次对比，如果这次比上次短，哪怕只短了几分钟，都说明设备在两次巡检之间重启过。重启的原因可能是断电、设备崩溃自动恢复，也可能有人手动 reboot。配合 display version 的版本号是否变化，还能判断是不是有人升级过软件。这个验证不需要额外命令，成本为零，但能发现很多"看起来一切正常"的问题。

从那以后我每次巡检走完 11 条命令，都会把当天的 clock、device verbose、version 三组输出单独存成一个文本，和上次的文本做一次 diff。Up Time 回退和版本号变化这两类差异，会直接写进交接单，哪怕其他指标全部正常也要写。这个习惯帮我抓住过两次"没人承认重启过"的设备异常，也让我对巡检这事越来越不依赖临场发挥。希望帮到你。

本文还有配套的精品资源，点击获取