企业官网建设流程全解析

简介：该文档面向网络运维人员与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 平台上的输出有自己的特点。文档中这条命令的完整输出是：

<H3C>display 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 直观，但很多人栽在单位换算上：

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

874453360 字节换算过来约 833MB，对应这台设备标称的 1024M bytes SDRAM——系统保留了一部分内存给内核和转发芯片，所以实际可见总量比标称小，这不是故障。已用 117120680 字节约 111MB，Used Rate 13%，健康。

判断内存问题的关键不是瞬时值，而是趋势。我建议连续一周在固定时间点记录 Used Rate，如果发现单调上升、重启后回落、然后再次爬升，基本可以断定有内存泄漏。常见元凶是异常的网络协议会话、SNMP 频繁被拉取导致的缓存堆积，或者设备开启了过多的服务进程。老设备 S5500 的内存只有 1G，V7 平台上的新机型动辄 4G 起步，但判断方法是一样的。

遇到内存使用率超过 90% 的情况，优先检查是不是有异常会话或环回流量，不要一上来就重启设备——重启虽然能临时释放内存，但如果没有找到泄漏源，过一段时间还是会复发，而且重启一台在线交换机的风险远高于内存高负载本身。

2.3 display environment：hotspot 才是设备真实温度

温度命令的输出最容易看错，因为里面有两类温度传感器：

<H3C>display 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 NA

Inflow 1是入风口温度传感器，hotspot 1是热点温度传感器。设备手册里说的“设备温度”默认指 hotspot 温度，不是进风口温度。文档示例中 hotspot 38 度，这台设备的 WarningLimit 是 77 度，AlarmLimit 是 82 度，余量很大。

阈值对照关系如下：

ShutdownLimit显示 NA 表示该型号没有启用温度关机保护，也就是说即使温度超标，设备也不会自动关机，只会持续告警。这意味着巡检发现温度接近 AlarmLimit 时必须人工干预，不能指望设备自我保护。

一个实战经验：夏天机房空调故障时，Inflow 温度先升高，hotspot 有热容滞后，会慢半小时到一个小时才跟上。所以巡检时发现进风口温度异常升高、还没到告警阈值时，就应该提前检查空调和机柜通风，真等 hotspot 告警再处理，可能已经来不及了。

3. 风扇、电源、时钟与设备信息：硬件健康与台账核查

3.1 display fan：Normal 之外的状态都要当场处理

风扇输出格式简单，但地位不低：

<H3C>display fan Slot 1 FAN 1 State : Normal

这台设备只有一个风扇，但很多机架式交换机有两个甚至四个风扇模块，输出会列出 FAN 1、FAN 2 等每一行的状态。State 只有两种取值：Normal 和 Abnormal。巡检时只要看到 Abnormal，就要当场处理。风扇故障的可怕之处在于它不会立刻导致设备宕机，而是让设备散热能力下降，温度缓慢爬升，最终在业务高峰时触发告警甚至丢包。我处理过一台设备，风扇报 Abnormal 之后拖了一周才换，期间 hotspot 温度从 45 度涨到 58 度，虽然没到告警线，但已经逼近盛夏机房的危险区间。

如果风扇报异常，先检查是不是被灰尘卡住、转速明显下降，再查模块有没有插紧。S5500 这类设备的风扇模块支持热插拔，但更换时要确认手上备件的型号和原装一致，混用不同转速的风扇会导致风道异常。

3.2 display power：Fault 状态为什么最容易被漏判

电源状态是巡检里最容易被忽视的一项，因为它在业务无感的时候悄悄发生故障。看文档里的实际输出：

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

这台设备配置了两个电源模块，Power 1 是交流 150W 模块，状态 Normal；Power 2 状态 Fault，类型显示 Unknown。Input Power 63W 是当前整机实际输入功率。这里有个关键点：电源模块在故障或未插电时，设备无法读取它的型号信息，所以 Type 会变成 Unknown。Power 2 的 Fault 状态最合理的解释是第二路电源没有插电或者模块已经损坏。

双电源设备的巡检逻辑和单电源完全不同：业务还在跑，是因为一个电源在供电，但冗余能力已经没了。此时如果另一个电源再出问题，或者机房发生单路断电，设备直接掉电，所有业务中断。我的处理习惯是：任何一台双电源设备，display power 里出现 Fault，无论业务是否正常，先看现场电源线有没有插，插了就是模块故障，走备件流程；没插就是维护失误，当天补上。文档里这个示例恰好是巡检时最容易翻车的场景——值班人员看到业务正常就以为没事，实际上设备已经在单电源模式下裸奔了。

3.3 display clock：时区不配对排障的连锁影响

时钟命令的输出本身很简单：

<H3C>display clock 17:08:12 UTC Mon 11/24/2014

注意输出里的UTC字样，说明这台设备没有配置时区，用的是世界协调时。在中国机房，这等于设备时间比北京时间慢了 8 小时。如果刚好是下午 17 点巡检，设备时间显示上午 9 点左右，很多值班的人会以为只是差几个小时无伤大雅，但排障时问题就大了：设备日志时间戳和网管平台、防火墙、服务器的日志对不上，出现安全事件时无法做时间线关联。

我一般会在设备上补两个配置：

<H3C>system-view [H3C]clock timezone Beijing add 8 [H3C]ntp-service enable [H3C]ntp-service unicast-server 192.168.0.2

clock 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 看设备是否异常重启

设备汇总信息是巡检台账的入口：

<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 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-configuration

4.1 display interface brief：分清 ADM down 与物理 down

display interface brief是整个巡检里信息量最大、也最容易误读的命令。文档中的完整输出分为三层接口和二层接口两段：

<H3C>display 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，说明这些口上接的是正经的服务器或交换机。

接口字段含义整理如下：

表格里端口 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 terminal

local-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_lan

community 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：版本台账与序列号采集

版本信息是设备资产台账的基础，也是判断软件是否存在已知缺陷的依据：

<H3C>display 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 210

Release 5203P03 是这台设备的软件版本。华三设备跨大版本升级有严格的路径要求，比如从 V5 升到 V7 系列一般是换设备而不是刷版本，同系列内小版本升级也要看 Release Notes。Bootrom 210 这个参数容易被忽略，Bootrom 管理着设备启动引导和底层硬件初始化，版本过旧有时会影响设备对某些接口模块的识别。工程上一般趁设备软件升级的维护窗口，把 Bootrom 一起升到配套版本。

序列号信息用display device manuinfo：

<H3C>display 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显示 Normal，manuinfo 的 Error 可以忽略；反之如果 power 已经显示 Fault，才需要按电源故障处理。

6. 把巡检命令做成定时脚本：从手敲到自动化留痕

6.1 一个可直接落地的巡检 shell 脚本

手动一条条敲命令固然可靠，但每天重复执行很容易漏项。我习惯把巡检命令整理成脚本，用 SSH 批量执行，输出落盘。下面这个脚本适合在 Linux 跳板机上运行：

#!/bin/bash # H3C交换机日常巡检脚本 # 用法: ./inspect_h3c.sh 192.168.0.100 admin 'password' # 依赖: sshpass（CentOS/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 StrictHostKeyChecking=no \ "${DEV_USER}@${DEV_IP}" "${cmd}" >> "${OUT_FILE}" 2>&1 done echo "===== 巡检结束 =====" >> "${OUT_FILE}" # 只保留最近90天日志，避免磁盘被巡检记录占满 find "${LOG_DIR}" -name "*.log" -mtime +90 -delete

脚本核心是把命令清单放在CMDS数组里，for 循环逐条执行。sshpass -p负责把密码传给 SSH，StrictHostKeyChecking=no跳过首次连接的主机指纹确认，否则全自动执行会在第一次连接时卡住。生产环境如果对密码落盘有顾虑，可以改用 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 2>&1

crontab 五个字段分别对应分、时、日、月、周，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 和账号换掉就能直接当成自己的巡检模板用。希望你也能把巡检做到自动化、留痕、有对比，设备才能少给你惹麻烦。

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