简介该文档面向网络运维人员与H3C设备管理员系统整理交换机日常巡检所需的八类核心命令用途在于快速掌握CPU、内存、温度、风扇、电源等关键指标的查看方法帮助提前发现隐患并保障设备稳定运行。资源包含1个doc文件整体压缩包仅21KB适合作为随身查阅的速查手册或嵌入现有运维规范文档使用。内容逐条给出命令行、作用与结果解读例如通过display cpu-usage查看近期负载display environment关注入风口与热点温度display interface brief检查接口链路状态等并对Normal、Fault等输出含义做出说明便于巡检时对照执行。当前已有588人学习下载适用于从基础巡检到日常排障的多种场景能显著提升交换机状态确认与问题定位效率。1. H3C交换机巡检命令哪些命令真正值钱判断标准又是什么我接手过不少华三设备的故障现场见过最典型的翻车案例不是设备当场宕机而是巡检流于形式——值班的人每天用display cpu-usage和display memory看一眼就交班风扇、电源、温度、接口协商状态全都不看结果一台 S5500 的双电源悄悄坏了一路冗余丢了三个星期没人知道直到另一路也跳电才暴露。H3C交换机巡检命令核心就是一套用 display 命令把设备状态逐项问一遍的方法。这份《H3C交换机巡检命令》文档整理的是 S5500 系列实测可用的完整命令集覆盖 CPU、内存、温度、风扇、电源、时钟、接口、版本、序列号与运行配置每个命令都带真实输出和判读要点。适合机房值班、网络运维、备考 H3C 认证的人直接拿去做巡检模板。命令本身不复杂难的是知道看哪里、阈值多少、哪些输出是误报。2. CPU、内存与温度巡检三个命令盯住设备核心健康2.1 display cpu-usage区分整机使用率与单核占用华为与华三这条命令同源但 S5500 这种老设备在 Comware V5 平台上的输出有自己的特点。文档中这条命令的完整输出是H3Cdisplay cpu-usage Slot 1 CPU usage: 6% in last 5 seconds 5% in last 1 minute 5% in last 5 minutes Slot 1 CPU 1 CPU usage: 0% in last 5 seconds 0% in last 1 minute 0% in last 5 minutes第一行的Slot 1 CPU usage是整机 CPU 的统计口径下面那个Slot 1 CPU 1 CPU usage是多核架构下的单核占用率。S5500-34C-HI 配备 2 个处理器启动后会打印每个处理器核的详细占用。巡检时看第一行就够了第二行只有在怀疑单核跑满、某个协议进程把单个 CPU 核耗尽时才需要逐核排查。判读标准我一般是这样掌握的5 秒均值受突发流量影响大打游戏时瞬间 80% 都出现过不能作为告警依据1 分钟和 5 分钟均值超过 50% 要引起注意持续超过 70% 就意味着设备处理能力接近瓶颈需要查是不是有广播风暴、环路或者异常大流量。文档示例里 5 分钟均值 5% 属于非常健康的负载适合作为基线值记下来。提示这条命令建议分三次采集取中间值每次间隔 1 分钟可以有效避开瞬时尖峰的干扰。遇到 CPU 长期偏高的场景不要急着下结论。先用display interface brief看所有端口有没有异常流量如果是 V7 平台还可以用display process cpu看具体是哪个进程在吃 CPU但 V5 平台支持有限我一般会配合display logbuffer看有没有大量中断日志确认是不是物理层震荡导致的软中断开销。2.2 display memory算清楚字节数再看判断阈值内存输出比 CPU 直观但很多人栽在单位换算上H3Cdisplay memory System Total Memory(bytes): 874453360 Total Used Memory(bytes): 117120680 Used Rate: 13%874453360 字节换算过来约 833MB对应这台设备标称的 1024M bytes SDRAM——系统保留了一部分内存给内核和转发芯片所以实际可见总量比标称小这不是故障。已用 117120680 字节约 111MBUsed Rate 13%健康。判断内存问题的关键不是瞬时值而是趋势。我建议连续一周在固定时间点记录 Used Rate如果发现单调上升、重启后回落、然后再次爬升基本可以断定有内存泄漏。常见元凶是异常的网络协议会话、SNMP 频繁被拉取导致的缓存堆积或者设备开启了过多的服务进程。老设备 S5500 的内存只有 1GV7 平台上的新机型动辄 4G 起步但判断方法是一样的。遇到内存使用率超过 90% 的情况优先检查是不是有异常会话或环回流量不要一上来就重启设备——重启虽然能临时释放内存但如果没有找到泄漏源过一段时间还是会复发而且重启一台在线交换机的风险远高于内存高负载本身。2.3 display environmenthotspot 才是设备真实温度温度命令的输出最容易看错因为里面有两类温度传感器H3Cdisplay environment Slot 1 System temperature information (degree centigrade): ------------------------------------------------------------------------------- Sensor Temperature LowerLimit WarningLimit AlarmLimit ShutdownLimit Inflow 1 32 0 67 72 NA hotspot 1 38 0 77 82 NAInflow 1是入风口温度传感器hotspot 1是热点温度传感器。设备手册里说的“设备温度”默认指 hotspot 温度不是进风口温度。文档示例中 hotspot 38 度这台设备的 WarningLimit 是 77 度AlarmLimit 是 82 度余量很大。阈值对照关系如下传感器当前值下限告警门限严重告警门限关机门限Inflow 132℃0℃67℃72℃NAhotspot 138℃0℃77℃82℃NAShutdownLimit显示 NA 表示该型号没有启用温度关机保护也就是说即使温度超标设备也不会自动关机只会持续告警。这意味着巡检发现温度接近 AlarmLimit 时必须人工干预不能指望设备自我保护。一个实战经验夏天机房空调故障时Inflow 温度先升高hotspot 有热容滞后会慢半小时到一个小时才跟上。所以巡检时发现进风口温度异常升高、还没到告警阈值时就应该提前检查空调和机柜通风真等 hotspot 告警再处理可能已经来不及了。3. 风扇、电源、时钟与设备信息硬件健康与台账核查3.1 display fanNormal 之外的状态都要当场处理风扇输出格式简单但地位不低H3Cdisplay fan Slot 1 FAN 1 State : Normal这台设备只有一个风扇但很多机架式交换机有两个甚至四个风扇模块输出会列出 FAN 1、FAN 2 等每一行的状态。State 只有两种取值Normal 和 Abnormal。巡检时只要看到 Abnormal就要当场处理。风扇故障的可怕之处在于它不会立刻导致设备宕机而是让设备散热能力下降温度缓慢爬升最终在业务高峰时触发告警甚至丢包。我处理过一台设备风扇报 Abnormal 之后拖了一周才换期间 hotspot 温度从 45 度涨到 58 度虽然没到告警线但已经逼近盛夏机房的危险区间。如果风扇报异常先检查是不是被灰尘卡住、转速明显下降再查模块有没有插紧。S5500 这类设备的风扇模块支持热插拔但更换时要确认手上备件的型号和原装一致混用不同转速的风扇会导致风道异常。3.2 display powerFault 状态为什么最容易被漏判电源状态是巡检里最容易被忽视的一项因为它在业务无感的时候悄悄发生故障。看文档里的实际输出H3Cdisplay power Slot 1 Input Power : 63(W) Power 1 State : Normal Type : AC/150(W) Power 2 State : Fault Type : Unknown这台设备配置了两个电源模块Power 1 是交流 150W 模块状态 NormalPower 2 状态 Fault类型显示 Unknown。Input Power 63W 是当前整机实际输入功率。这里有个关键点电源模块在故障或未插电时设备无法读取它的型号信息所以 Type 会变成 Unknown。Power 2 的 Fault 状态最合理的解释是第二路电源没有插电或者模块已经损坏。双电源设备的巡检逻辑和单电源完全不同业务还在跑是因为一个电源在供电但冗余能力已经没了。此时如果另一个电源再出问题或者机房发生单路断电设备直接掉电所有业务中断。我的处理习惯是任何一台双电源设备display power 里出现 Fault无论业务是否正常先看现场电源线有没有插插了就是模块故障走备件流程没插就是维护失误当天补上。文档里这个示例恰好是巡检时最容易翻车的场景——值班人员看到业务正常就以为没事实际上设备已经在单电源模式下裸奔了。3.3 display clock时区不配对排障的连锁影响时钟命令的输出本身很简单H3Cdisplay clock 17:08:12 UTC Mon 11/24/2014注意输出里的UTC字样说明这台设备没有配置时区用的是世界协调时。在中国机房这等于设备时间比北京时间慢了 8 小时。如果刚好是下午 17 点巡检设备时间显示上午 9 点左右很多值班的人会以为只是差几个小时无伤大雅但排障时问题就大了设备日志时间戳和网管平台、防火墙、服务器的日志对不上出现安全事件时无法做时间线关联。我一般会在设备上补两个配置H3Csystem-view [H3C]clock timezone Beijing add 8 [H3C]ntp-service enable [H3C]ntp-service unicast-server 192.168.0.2clock timezone Beijing add 8把时区设为东八区ntp-service unicast-server指定内网 NTP 时间源让设备自动同步时间。注意这个命令在 V5 和 V7 平台写法略有差异V7 新机型上通常是ntp-service enable加ntp-service unicast-server x.x.x.x含义一致。配好之后再用display clock确认输出里变成CST或Beijing而不是 UTC。3.4 display device verbose从 Up Time 看设备是否异常重启设备汇总信息是巡检台账的入口H3Cdisplay 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 Patch Ver : None PCB Ver : REV.B BootRom Ver : 210 CPLD Ver : 003第一行表格里的 30 表示该槽位有 30 个业务口和 S5500-34C-HI-D 的端口形态吻合。下面Up Time显示这台设备已经连续运行 10 周说明没有异常重启。巡检时遇到过 Up Time 只有几小时的设备这类设备往往刚经历过断电或故障重启需要格外关注系统日志确认重启原因。Brd Status: Master表示设备是主控角色。单机运行时显示 Master 是正常的但如果在 IRF 堆叠组里Master 和 Standby 的状态就很重要了——堆叠中如果出现双 Master会导致整个堆叠分裂业务中断。巡检 IRF 设备时除了这里要看还建议用display irf确认堆叠成员和优先级。4. 接口与配置巡检读懂 interface brief 和 current-configuration4.1 display interface brief分清 ADM down 与物理 downdisplay interface brief是整个巡检里信息量最大、也最容易误读的命令。文档中的完整输出分为三层接口和二层接口两段H3Cdisplay interface brief The brief information of interface(s) under route mode: Link: ADM - administratively down; Stby - standby Protocol: (s) - spoofing Interface Link Protocol Main IP Description M-GE0/0/0 DOWN DOWN -- NULL0 UP UP(s) -- Vlan1 UP UP 192.168.0.100三层接口这一段M-GE0/0/0 是管理口DOWN DOWN 表示管理口没有接线路NULL0 是系统内置的 Null 接口UP(s) 是软件虚拟接口s 表示 spoofing不用管Vlan1 是管理 VLAN 的三层接口192.168.0.100 是管理地址。这一段重点看管理地址是否正确、Vlan 接口有没有 down。二层接口段的信息量更大The brief information of interface(s) under bridge mode: Link: ADM - administratively down; Stby - standby Speed or Duplex: (a)/A - auto; H - half; F - full Type: A - access; T - trunk; H - hybrid 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 ... GE1/0/20 UP 10M(a) F(a) A 1看这张表有个顺序先看 Link 列UP 代表物理链路通了DOWN 代表物理不通或被人为关闭再看 Speed 列确认协商速率是否正常。文档里 GE1/0/20 的速率是10M(a)这是个异常信号——千兆口协商到 10M要么是网线质量差到了极点要么对端是古董级设备。正常千兆口至少应该是1G(a)或者对端百兆设备时的100M(a)。GE1/0/8、GE1/0/10、GE1/0/23 这几个口协商到了 1G说明这些口上接的是正经的服务器或交换机。接口字段含义整理如下字段取值含义LinkUP / DOWN物理链路通断ADMadministratively down被 shutdown 命令手工关闭Speed1G(a) / 100M(a) / 10M(a)当前协商速率a 为自适应DuplexF(a) / H / A全双工 / 半双工 / 自适应TypeA / T / HAccess / Trunk / Hybrid 端口类型PVID数值端口缺省 VLAN表格里端口 DUPLEX 出现 H半双工时也要注意。现在的设备极少应该跑在半双工除非对端设备故障或网线有问题。另外看到 Link 列 DOWN 先别慌下行口没接电脑自然 down或者被人为 shutdown 了也会显示 down——这正是文档里 Link 字段说明的ADM - administratively down的含义。判断“被动 down”和“主动 down”很简单显示DOWN auto的是物理层就断了显示ADM down是管理员手动关的。排障时这两个状态的处理方式完全不同。注意如果某个本该 UP 的口变成了 DOWN用display interface GigabitEthernet 1/0/x看这个口单独的详细信息重点看 Last link down 时间和 reason能直接定位是光模块、网线还是对端问题。4.2 display current-configuration巡检不光看状态还要看基线状态命令反映的是当前健康度配置命令反映的是设备是否还在管理基线内。文档里display current-configuration的输出片段很长但巡检时值得逐行关注的就那么几处。sysname H3C说明这台设备没有改主机名。生产环境用默认名多台设备同时在线时很容易登错机器执行错误配置。我经手的项目里开局第一件事就是sysname 机房-位置-业务这种命名规则。文档里还有local-user unipower password cipher $c$3$O7NpaPtUI913wxdrwnmmPeJrEztlBAk4D6WCK/RteA authorization-attribute level 3 service-type ssh telnet terminallocal-user 账号权限是 level 3即管理级权限同时开放了 ssh、telnet、terminal 三种服务类型。密码虽然是 cipher 密文但 level 3 账号泄露的后果是设备完全失控。巡检时如果发现不需要 telnet建议在 VTY 配置里关掉这个服务保留 SSH 就够了。SNMP 配置同样值得注意snmp-agent snmp-agent local-engineid 800063A20374258AD93294 snmp-agent community read gpdc_lancommunity read gpdc_lan是只读团体字这条配置本身问题不大但如果是 write 权限或者用了默认的 public/private就要当场改掉。很多网管平台纳管交换机时依赖 SNMP但团体字是明文传输的建议用 ACL 限制 SNMP 访问来源只允许网管服务器网段访问。还有一个细节arp static 192.168.0.166 0025-220f-b5eb这是一条静态 ARP 绑定把 192.168.0.166 绑到了固定 MAC 上通常是防 ARP 欺骗或重要服务器的保护措施。巡检时核对一下这条绑定是否还在生效、对方设备是否已经变更了 MAC如果服务器换了网卡而绑定没更新会导致这台设备无法访问。4.3 display version 与 manuinfo版本台账与序列号采集版本信息是设备资产台账的基础也是判断软件是否存在已知缺陷的依据H3Cdisplay version H3C Comware Platform Software Comware Software, Version 5.20, Release 5203P03 H3C S5500-34C-HI-D uptime is 10 weeks, 0 day, 6 hours, 27 minutes H3C S5500-34C-HI-D with 2 Processors 1024M bytes SDRAM 4096K bytes Nor Flash Memory 512M bytes Nand Flash Memory Hardware Version is REV.B CPLD Version is 003 Bootrom Version is 210Release 5203P03 是这台设备的软件版本。华三设备跨大版本升级有严格的路径要求比如从 V5 升到 V7 系列一般是换设备而不是刷版本同系列内小版本升级也要看 Release Notes。Bootrom 210 这个参数容易被忽略Bootrom 管理着设备启动引导和底层硬件初始化版本过旧有时会影响设备对某些接口模块的识别。工程上一般趁设备软件升级的维护窗口把 Bootrom 一起升到配套版本。序列号信息用display device manuinfoH3Cdisplay device manuinfo Slot 1: DEVICE_NAME : S5500-34C-HI-D DEVICE_SERIAL_NUMBER : 210235A0X8H138000042 MAC_ADDRESS : 7425-8AD9-3293 MANUFACTURING_DATE : 2013-08-29 VENDOR_NAME : H3C Power 1: The operation is not supported on the specified power. Power 2: Error: Failed to display the manufacture information of the specified power.序列号和 MAC 地址是设备入资产库的关键字段报修、维保查询都靠它。但注意最后两行电源模块上报了 not supported 和 Error。这里是个容易误判的点这不是电源故障而是该型号对电源子模块不支持 manuinfo 查询。判断依据是刚才display power输出的 Power 1 状态是 Normal如果电源真坏了应该首先在 power 状态里反映。所以 manuinfo 的报错以主槽位信息为准即可。5. H3C巡检常见问题与避坑排查五个翻车点实录5.1 现象CPU 瞬时冲到 90%误报频发值班平台根据display cpu-usage抓取的数据频繁告警7×24 小时监控里时不时冒出一条 CPU 超阈值值班人员疲于确认最后干脆把告警关掉了。原因在命令本身display cpu-usage的第一个采样点是 5 秒内均值广播风暴、环路瞬间流量、病毒扫描这类突发流量都会把 5 秒均值顶上去但它不代表设备持续过载。解决告警判定改用 1 分钟和 5 分钟均值连续采样 3 次每次间隔 1 分钟均超过 70% 才触发告警。监控平台抓取这条命令时也建议在抓取脚本里做同样处理不要拿单次数值直接出告警。5.2 现象接口批量 DOWN是新交换机坏了吗新装一批 S5500 接入交换机上架后display interface brief显示一大半端口 DOWN现场以为是设备故障急着联系售后。原因下行口接的电脑、IP 电话本来就没开机物理层自然就是 down 的另一部分端口被开局工程师 shutdown 保留显示 ADM down。设备本身没有任何问题。解决先把拓扑摸清确定哪些口是上行口、哪些口接服务器这些口必须 UP对既没接设备也不打算用的口全部 shutdown 处理。这样做还有一个好处之后的巡检里只要看到被 shutdown 的口变成 UP说明有人私接设备安全事件可以提前发现。5.3 现象Power 显示 Fault 但业务不断就没人处理巡检记录里display power显示 Power 2 Fault业务没有中断机房值班人员认为不影响使用持续了数周没有处理。原因双电源设备在单电源供电时仍能正常转发业务Fault 只代表第二路冗余缺失。Type 显示 Unknown 是因为电源模块没有被设备正常识别常见于电源线没插、模块故障或模块型号不兼容。解决巡检流程中把 Power 状态列为必看项只要出现 Fault 就必须当场确认。先检查电源线两端是否插牢再确认机房配电柜对应空开有没有合上排除外部原因后走备件更换流程。高危业务设备建议在制度上明确双电源冗余缺失超过 24 小时必须升级处理。5.4 现象设备日志时间全是 UTC排障时和网管平台对不上设备出现安全告警需要把交换机日志、防火墙日志、服务器日志放在一起做时间线分析结果交换机日志的时间比其它设备差了 8 小时关联失败。原因display clock输出显示 UTC设备没有配置时区。国内机房默认应该用东八区时间设备出厂默认时区是 UTC不配就会一直差 8 小时。解决一次配齐两件事——clock timezone Beijing add 8设置时区ntp-service unicast-server指向内网时间源保证时间持续准确。配完用display clock确认输出中出现北京时区标识。从那以后我巡检只要看到display clock输出带 UTC直接记一条问题项不留给下次。5.5 现象manuinfo 在电源模块上报 Error被当成设备故障上报巡检执行display device manuinfo电源模块报 not supported 和 Error有人误判为电源模块故障安排了设备停机排查。原因该型号的电源模块不支持 manuinfo 信息查询命令命令本身对子模块的兼容性有限。这个报错与电源健康状况无关。解决判断设备硬件状态以display power和display fan为准manuinfo 只需采集主槽位的序列号、MAC、出厂日期用于台账。如果display power显示 Normalmanuinfo 的 Error 可以忽略反之如果 power 已经显示 Fault才需要按电源故障处理。6. 把巡检命令做成定时脚本从手敲到自动化留痕6.1 一个可直接落地的巡检 shell 脚本手动一条条敲命令固然可靠但每天重复执行很容易漏项。我习惯把巡检命令整理成脚本用 SSH 批量执行输出落盘。下面这个脚本适合在 Linux 跳板机上运行#!/bin/bash # H3C交换机日常巡检脚本 # 用法: ./inspect_h3c.sh 192.168.0.100 admin password # 依赖: sshpassCentOS/Ubuntu 均可安装 DEV_IP$1 DEV_USER$2 DEV_PASS$3 LOG_DIR/var/log/switch_inspect STAMP$(date %Y%m%d_%H%M) OUT_FILE${LOG_DIR}/${DEV_IP}_${STAMP}.log # 巡检命令清单按文档1.1~1.11顺序执行 CMDS( display cpu-usage display memory display environment display fan display power display clock display interface brief display version display device verbose display device manuinfo display current-configuration ) mkdir -p ${LOG_DIR} echo ${DEV_IP} 巡检开始 $(date) ${OUT_FILE} for cmd in ${CMDS[]}; do echo ----- 执行: ${cmd} ----- ${OUT_FILE} sshpass -p ${DEV_PASS} ssh -o StrictHostKeyCheckingno \ ${DEV_USER}${DEV_IP} ${cmd} ${OUT_FILE} 21 done echo 巡检结束 ${OUT_FILE} # 只保留最近90天日志避免磁盘被巡检记录占满 find ${LOG_DIR} -name *.log -mtime 90 -delete脚本核心是把命令清单放在CMDS数组里for 循环逐条执行。sshpass -p负责把密码传给 SSHStrictHostKeyCheckingno跳过首次连接的主机指纹确认否则全自动执行会在第一次连接时卡住。生产环境如果对密码落盘有顾虑可以改用 SSH 密钥认证把sshpass那行换成ssh -i ~/.ssh/id_rsa。文件名带 IP 和时间戳方便多台设备轮巡时快速找到某台设备某一天的巡检记录。find删除 90 天前的日志防止跳板机磁盘被巡检文件塞满。6.2 crontab 定时任务与日志留痕脚本准备好之后用 crontab 设置定时执行。我一般选每天早上 8 点跑一次这个时间点避开了夜间备份和凌晨的业务高峰又能赶在上班前留好记录# 每天8点执行一次日志追加到 cron 记录 0 8 * * * /opt/scripts/inspect_h3c.sh 192.168.0.100 admin password /var/log/switch_inspect/cron.log 21crontab 五个字段分别对应分、时、日、月、周0 8 * * *是每天早上 8 点整。注意脚本里的密码如果写在 crontab 行里任何能登录跳板机的用户都能看到建议改成脚本读取独立配置文件权限设为 600。6.3 用 grep 快速筛出关键状态行日志落盘之后每天逐个文件翻太慢我一般用 grep 把关键状态行筛出来做快速对比# 只看电源、风扇、温度、CPU、内存、接口状态 grep -E CPU usage|Used Rate:|State|Link|hotspot|Inflow /var/log/switch_inspect/192.168.0.100_$(date %Y%m%d)_*.log这条命令把State、Link、CPU usage、hotspot这些关键字段一次性打出来。如果今天的结果和昨天有明显差异比如某个端口从 UP 变成 DOWN、电源从 Normal 变成 Fault说明夜间发生了变更或故障需要回溯display logbuffer确认时间点。我自己的习惯是每天花两分钟扫一遍这些状态行重点盯状态字段有没有变化而不是重复核对每个数字。这份命令集覆盖了巡检的核心场景值得下载留存把里面的 IP 和账号换掉就能直接当成自己的巡检模板用。希望你也能把巡检做到自动化、留痕、有对比设备才能少给你惹麻烦。本文还有配套的精品资源点击获取