企业官网建设流程全解析

简介：H3C交换机巡检命令.doc是一份面向网络管理员与运维人员的H3C设备日常巡检速查文档，重点解决交换机状态难掌握、故障排查效率低的问题。文档系统梳理了CPU使用率、内存占用、设备温度、设备汇总信息、风扇状态、电源状态、系统时间及接口状态八类核心查看命令，逐条给出命令作用与输出含义，覆盖硬件健康、运行状态、接口链路等多个维度。包体十分精简，只有1个doc文件，大小约21KB，离线即可查阅，适合带教培训或现场运维时快速对照。目前已有588人学习浏览，对刚接触H3C设备的新手和需要规范巡检流程的团队都很实用。文档不仅列出命令，还结合典型输出解释关键指标，如CPU最近5分钟平均使用率、内存已用比例、入风口与热点温度阈值、风扇和电源是否Normal等，帮助管理员从输出中快速判断设备是否异常，及时定位问题并采取修复措施，为交换机稳定运行提供保障。

1. H3C交换机巡检命令：为什么“敲了一遍命令”不等于“做完了巡检”

做网络运维的人对H3C交换机巡检都不陌生，一张表列十几条display命令，SSH进去挨个敲一遍，输出存个档，这动作很多人每个星期都在做。但真到了设备出故障回翻记录的时候，经常会发现：当时光模块收光已经贴着灵敏度下限了没在意，CPU那行有一个90%的尖峰没有记录上下文，logbuffer里反复出现的down/up被当成普通告警略过了。原因是巡检的重点不在“敲命令”，而在“看懂输出”和“持续对比”。这篇笔记按H3C设备实际运维习惯，把登录、命令、判读、归档这条链路拆开讲，给出可以直接抄走复用的命令模板和阈值参考，也把容易让结果失效的坑逐一列出来。

2. 连接H3C设备的三种方式与登录阶段最常见的三个翻车点

做巡检的起点不是敲命令，而是稳定地把会话建起来。H3C设备的日常管理入口无非三种：Console、Telnet（基本淘汰）、SSH。Telnet明文传密码，现在没人敢直接用，除非在完全隔离的带外管理网里。所以实际巡检以Console兜底、SSH为主。这一章把两种常用方式的配置要点和登录现场最常见的三个坑讲清楚。

2.1 Console登录：波特率、USB驱动和线序，连不上时按这个顺序查

Console口的参数所有H3C交换机出厂基本一致：波特率9600、数据位8、停止位1、无校验、无流控。用MobaXterm这类终端工具新建Serial会话时，先选对COM口，再把波特率改成9600，其他参数保持默认。连接时有一点容易被忽略：Console线建议在设备上电前插好，带电插拔偶尔会把设备的Console口打挂，遇到过不止一次，重启才能恢复。

连不上时按这个顺序查。第一，看Windows设备管理器里USB转串口芯片有没有被识别。H3C随机线和市面上的USB转console线常用CP2102、FT232、CH340，Windows 10以上的系统偶发把驱动识别成“其他设备”，重新装一下对应芯片的驱动就好。第二，确认选的COM口号和实际一致，多插拔几次COM号会变。第三，数据位、停止位、校验位别乱调，默认值就是H3C的出厂值。终端工具推荐SecureCRT或MobaXterm，自带串口会话类型，不需要额外配置。

新设备首次通过Console登录，通常直接用默认账号进到用户视图，有的版本会让你先设置密码。这一步如果卡住，绝大多数情况是波特率没对上，或者终端工具的“本地回显”设置有误导致输入看不到。

2.2 SSH批量登录：CRT连不上H3C交换机的常见原因与解决

H3C设备的SSH服务默认是关闭的，需要在设备上先启用：

# 开启SSH服务并配置登录用户，生产设备上提前配好，别等巡检时抓瞎 [H3C] ssh server enable [H3C] public-key local create rsa [H3C] local-user admin password simple Admin@123 [H3C] local-user admin service-type ssh [H3C] local-user admin authorization-attribute user-role network-admin [H3C] ssh user admin authentication-type password

这段命令把SSH服务打开、生成本地RSA密钥、建立admin用户并把认证方式设为密码。注意不同Comware版本里ssh server enable这个开关的名字可能有差异，部分老版本还要在VTY接口下加一行protocol inbound ssh。

SecureCRT或MobaXterm登录时提示“Key exchange failed”或直接卡住不动，常见原因是两端密钥交换算法不匹配。H3C老设备默认只支持较旧的kex算法和ssh-rsa，而新版终端工具出于安全默认禁用这些算法。解决办法：在SSH会话的高级选项里，把Key Exchange勾上diffie-hellman-group14-sha1，Host Key算法勾上ssh-rsa，重连一般就好了。这不是设备故障，是密码学算法兼容性问题。

顺带说一句，Telnet在带外管理网里临时应急能用，但所有一线运维都会尽快把它关掉。一是密码明文，二是H3C老设备Telnet服务本身不如SSH稳定。如果巡检环境里只能Telnet，把它列入整改清单，别形成依赖。

2.3 巡检会话的“进场规范”：分页、超时和时间戳

登录进去后，正式敲巡检命令前先把会话环境整理好。第一句先执行screen-length disable关闭分页输出——H3C设备默认一屏显示24行后停顿等回车，巡检脚本一旦挂起，输出就停在半截，后面的记录全部缺失。第二句用display clock确认设备时间，时间不对的话日志和光衰记录的时间线都是错的，后面做基线对比没有意义。

然后是超时。H3C的VTY默认空闲超时是10分钟，一次完整巡检如果边看边记很容易超过这个时间导致会话被踢。可以在设备配置里把超时调到30分钟以上：

[H3C] user-interface vty 0 15 [H3C-ui-vty16] idle-timeout 60 0

idle-timeout 60 0表示空闲60分钟后断开，参数按运维规范调整。需要注意的是这是设备侧全局行为，所有VTY口都受这个影响，安全要求高的场景建议保持短超时，巡检时靠脚本连续发命令避免空闲即可。

3. H3C核心巡检命令拆解：display cpu、光口光衰和logbuffer的判读要点

这一章是巡检命令的主体，按“系统健康、CPU/内存、接口/光模块、MAC/ARP/日志”四组拆开。每组说明命令是什么、输出看哪几个字段、异常长什么样，免得命令敲了却不知道在看什么。

3.1 系统健康快照：display version、display device、display environment

三个命令组成设备级健康快照：

<H3C> display version <H3C> display device <H3C> display environment

display version看软件版本、Bootrom版本、设备运行时长。重点不是版本号本身，而是uptime：如果重启时间与你已知的重启记录对不上，说明中途发生过你没掌握的异常重启，这比任何告警都值得追。display device看板卡、电源、风扇的Status字段，Normal之外的任何状态都要重点核查。框式设备像S7006X，这里会列出主控板、交换网板、接口板的在位状态。

display environment看温度、风扇转速、电源电压。H3C框式设备一般分“当前温度”和“告警阈值”两列，重点关注当前温度是否在阈值以内、风扇转速是否在正常范围。风扇转速偏低不一定是故障，机房温度低时转速会下降，但如果温度偏高转速却上不去，就是风扇故障的前兆。

3.2 CPU与内存：5秒平均值别当故障，持续高占用才要追

H3C上查看CPU和内存的常用命令是：

<H3C> display cpu <H3C> display memory

不同Comware版本命令名有差异，Comware V7上也可以用display cpu-usage。输出会直接给出CPU利用率的5秒、1分钟、5分钟三个平均值，以及每个CPU核的占用。看的时候先把眼光放到1分钟和5分钟的平均值上，5秒的尖峰参考价值有限。设备在执行配置下发、路由收敛、堆叠同步时，5秒平均冲到80%以上很正常，没有持续意义。反过来，如果5分钟平均长期超过60%，就要用display process cpu查一下是哪个进程在消耗，通常是某类协议进程或软转发进程。

内存的使用率看display memory输出里的Memory Utilization字段，持续超过80%需要关注内存泄漏风险。一个实用技巧是记录一周内每天的闲时内存值，如果数值一路下降不回升，比单次超标更值得警惕。H3C和华为的命令有很多相似之处，但别把华为设备上的判读习惯直接套过来，两个厂商对CPU均值的统计口径和进程划分方式并不完全一致。

<H3C> display cpu CPU utilization: 5 seconds: 23% 1 minute: 18% 5 minutes: 15%

这三个数值，日常记录用1分钟，判定故障用5分钟。如果5分钟均值超过50%，建议持续观察；超过80%，需要立刻追查进程。不同型号的处理能力不同，S7500系列和低端S5024完全不是一个量级，绝对阈值要按设备型号分别定。

3.3 接口状态与光模块：查光口光衰的命令和参数解释

接口部分先扫汇总，再查细节。第一句执行display interface brief：

<H3C> display interface brief

这个命令输出所有接口的Link状态、协议状态、速率和入出方向报文计数（部分版本有）。巡检时重点看Link为down但物理口实际插着线的端口，以及状态一直在up/down之间翻转的端口。后者通常指向光模块劣化或对端设备异常。

逐接口详情用display interface GigabitEthernet 1/0/1，看Input/Output的rate、CRC错误、错包、丢弃计数。速率字段要从速率、广播/组播占比、错误包增量三个维度看，后面避坑章再展开。

光模块是巡检的重中之重。查光口光衰的命令是display transceiver diagnostic-information，一次性输出所有光模块的诊断信息。要单独查某个光模块的收发光，用：

<H3C> display transceiver interface GigabitEthernet 1/0/1 verbose

输出里的关键参数按这个表理解：

对RX Power的判断有两条经验：一是看绝对值和模块类型是否匹配，多模短距模块和单模长距模块的灵敏度差异很大，不能拿同一阈值套用；二是和上次巡检的数值对比，衰减超过3dB就要引起注意，衰耗曲线比绝对值更能说明问题。单模模块收光在-20dBm以下建议进入观察名单，多模模块低于-15dBm时也需要警惕。这些数值因光模块型号而异，最好把上下两条线标在巡检模板里，别只写一个“正常”。

3.4 MAC、ARP与日志：环路、扫描与瞬时中断的快速发现

环路是巡检中最隐蔽的问题，MAC地址表是第一个暴露点：

<H3C> display mac-address <H3C> display arp

正常情况下MAC表项数量和网络的活跃终端数大致匹配。如果表项数量在短时间涨了几百甚至上千条，优先怀疑存在环路或者有终端在扫描。ARP表同样如此，表项异常膨胀时先查是不是有人私接设备或下挂终端过多。配合display logbuffer查看日志：

<H3C> display logbuffer | include DOWN|UP|FDD <H3C> display logbuffer | include SLAVE|FLAPPING

logbuffer里反复出现端口down/up，是在提示物理链路不稳，常见原因有光模块劣化、光纤接头脏、网线老化或对端供电异常。日志的时间间隔如果呈现周期性规律，可以直接去看对端设备是否在周期重启。具备堆叠的组网，把display irf也加进巡检列表，关注堆叠成员的状态和链路是否健康。H3C设备的堆叠状态一旦出问题，所有成员设备会同时影响转发，重要性高于普通接口。

4. 把巡检命令落成可复用模板：Python + paramiko跑全量巡检并归档

手动敲命令做巡检的最大问题是不可重复：每个人敲的顺序不一样、看的角度不一样、漏的命令不一样。这一步把它变成一份固定清单，用脚本在SSH会话里逐条执行并把输出落盘。这样每次巡检拿到的是同样的字段、同样的格式，才有对比的底子。

4.1 一套可直接改的巡检脚本：登录、关分页、逐条执行、落盘

有人喜欢用SecureCRT自带的日志功能，手工连接设备后把输出直接存文件。缺点也很明显：日志按会话时间分割，不能按命令拆分，没有自动化重连，也无法批量。下面这套用Python和paramiko库实现的最小可用巡检脚本，解决的就是批量、拆分、归档这三个问题：

import paramiko import datetime import time import os devices = [ {"host": "192.168.10.1", "user": "admin", "password": "Admin@123"}, {"host": "192.168.10.2", "user": "admin", "password": "Admin@123"}, ] cmd_list = [ "screen-length disable", # 关闭分页，避免输出卡在中途 "display clock", # 记录设备当前时间，确认时钟同步 "display version", # 软件版本与启动时间 "display device", # 板卡/电源/风扇状态 "display environment", # 温度与风扇转速 "display cpu", # CPU利用率（V7也可用display cpu-usage） "display memory", # 内存利用率 "display interface brief", # 接口状态总览 "display transceiver diagnostic-information", # 全量光模块收发光 "display mac-address", # MAC表项数量与来源 "display arp", # ARP表项 "display logbuffer", # 设备日志 ] def run_inspection(dev): today = datetime.datetime.now().strftime("%Y%m%d") out_dir = os.path.join("inspection", today, dev["host"]) os.makedirs(out_dir, exist_ok=True) cli = paramiko.SSHClient() cli.set_missing_host_key_policy(paramiko.AutoAddPolicy()) cli.connect(dev["host"], port=22, username=dev["user"], password=dev["password"], timeout=10) shell = cli.invoke_shell() time.sleep(1) shell.recv(65535) # 吃掉登录 banner for cmd in cmd_list: shell.send(cmd + "\n") time.sleep(3) output = b"" while shell.recv_ready(): output += shell.recv(65535) time.sleep(0.5) filename = cmd.replace(" ", "_").replace("/", "_") with open(os.path.join(out_dir, f"{filename}.txt"), "wb") as f: f.write(output) print(f"[{dev['host']}] {cmd} -> {len(output)} bytes") cli.close() if __name__ == "__main__": for dev in devices: run_inspection(dev)

代码逻辑说明：invoke_shell()而不是exec_command()，是因为H3C的display命令在交互式shell中执行更稳定，exec_command对分页输出和长命令返回时机的处理不理想，容易提前截断结果。screen-length disable特意放在命令列表首位，保证后续命令输出不会被分页卡住。每条命令后先等3秒，再通过recv_ready()循环把残余数据全部取完，避免抓取不完整。

参数的调整建议看设备和命令列表。devices可以直接扩充，也可以改成从CSV文件读取资产清单，核心逻辑不变。需要调整的只有cmd_list里的巡检命令序列和每台设备的登录凭据。用户名密码用明文写在脚本里不适合放进公开仓库，生产环境可以用环境变量或密钥替代。

4.2 归档命名与结果结构：让每次巡检可比对

脚本里的目录结构是inspection/日期/主机IP/命令名.txt，这样设计有几个原因：一是按日期分目录，逐次巡检记录自然形成时间序列；二是每个命令单独存一个文件，比把全部输出拼在一个大文档里更容易做后续diff；三是文件名直接用命令名，一眼看出这个文件内容是什么，不用额外维护索引。

如果环境中有设备命名规范，建议把host字段换成业务名称（比如core-sw-01），目录层级会更直观。同一台设备的两次巡检结果存放在不同日期的目录里，第6章讲的基线对比就建立在这个目录结构上。

4.3 定时执行与巡检报告生成：别让脚本成为新的运维负担

脚本能跑通之后，维护成本要压到最低。常见做法是放到crontab或Windows任务计划里每周自动执行一次，执行完向运维群发一条通知。自动执行时注意不要在业务高峰时段跑display mac-address和display arp，这两个命令在核心设备上会短暂消耗一些CPU，放在低峰时段执行，比如周日凌晨。

输出报告不一定非要装一套网管平台。把每次巡检的CPU利用率、内存使用率、光模块收光数值抽出来形成一张表，用Python的csv模块落成一个汇总文件。表格里横向是一次巡检，纵向是每台设备或每个光模块的关键参数，连续几张表排在一起，趋势自然就出来了。发现趋势恶化再去翻详细输出，比打开几十个txt文件一个个看高效得多。这一步才是脚本巡检的价值所在，而不是单纯省去敲命令的时间。

5. H3C交换机巡检避坑：五个让结果失效的高频问题

这一章写的都是实际巡检中让结果失真、误判、甚至直接失效的现场，每条按“现象、原因、解决”梳理。踩过其中任意一条，都说明巡检已经从“工具问题”变成了“方法论问题”。

5.1 光模块收光误判：拿单一阈值套所有模块类型

现象：巡检记录显示某千兆光口收光-22dBm，数值在“网上流传的阈值”内，于是没处理。两周后该口频繁错包，业务受影响。

原因：不同模块的灵敏度、告警阈值不同。单模10km模块灵敏度一般在-19到-21dBm，多模300m模块灵敏度在-10到-12dBm左右，拿一个通用阈值套所有端口必然漏判。

解决：用display transceiver interface查看Transceiver Type，对照该型号数据手册的Rx Sensitivity值设定端口级基线。同一倍数的衰减在不同模块上含义完全不同，按模块型号分别建立阈值表。

5.2 CPU瞬时飙高被误报

现象：某次巡检抓到的CPU 5秒均值91%，直接升级告警，结果一查是正常的堆叠同步窗口。

原因：display cpu输出的第一个数字是最近5秒均值。设备在配置下发、IRF合并、路由重收敛时出现短暂峰值是行为特征，不是故障。

解决：以1分钟和5分钟均值为准，持续超过60%且维持10分钟以上再升级。判断时配合display process cpu看具体进程，别让一个瞬时尖峰打乱巡检节奏。

5.3 接口流量只看速率不看带宽占比

现象：千兆口速率显示400Mbps，判断为正常。实际该口对端是百兆设备，链路早被打满。

原因：display interface brief只给速率，不计算带宽利用率。同样400Mbps在千兆口和百兆口上的意义完全相反。

解决：用display interface看单位时间速率并与接口速率做比值，同时关注错误包、广播包、丢弃计数的增量变化。比值超过70%就要列入重点观察，单看绝对值等于没看。

5.4 会话超时或分页导致巡检记录不完整

现象：巡检脚本跑完后，某些文件只有几十字节甚至为空，数据缺失。

原因：设备的VTY空闲超时默认10分钟，命令间隔过长就被踢下线；或screen-length未关闭，输出分页后停在那里等待回车，脚本没有处理分页交互。

解决：把screen-length disable放在命令列表第一条；脚本里对每条命令的处理时间控制在3秒内，避免触发空闲超时；登录时确认VTY会话没有被全局策略限制。巡检结果不完整比不巡检更危险，因为缺失会被误读为“设备无输出”。

5.5 日志告警级别误读

现象：凌晨收到告警，logbuffer里出现多条“环境温度高于上限”，值班同事直接打电话叫醒了所有人。

原因：H3C日志分为Informational、Notice、Warning、Error等级别，部分温度告警是Warning甚至Notice，属于“需要注意”而非“设备故障”。只看日志条数不看级别，很容易把通知当事故。

解决：巡检时按级别过滤，用display logbuffer | include Error|Critical筛出真正需要处理的项，把周期性的Warning归类为观察项。日志解读的原则是“先看级别，再看次数，最后看时间范围”，顺序反了就会得出完全错误的结论。

6. 进阶一步：基线对比和增量记录，让巡检命令变成长期有效的“后悔药”

巡检命令的全部价值在于对比：和上周自己的记录比，和同型号设备的基准比。一台设备正常时什么样，记录下来的基线远比记忆可靠。我的做法是：第一次完整巡检后，把结果目录拷贝一份作为基线；之后每周巡检自动执行，执行完后与前一次输出的diff结果定向汇总。

具体做法可以是脚本里的最后一步，用Python的difflib对两个目录下的同名文件逐行对比：

import difflib import os baseline_dir = "inspection/baseline" latest_dir = "inspection/20241027" for fname in os.listdir(latest_dir): if not fname.endswith(".txt"): continue base_path = os.path.join(baseline_dir, fname) latest_path = os.path.join(latest_dir, fname) if not os.path.exists(base_path): print("新增文件:", fname) # 说明配置有变更 continue diff = list(difflib.unified_diff( open(base_path).readlines(), open(latest_path).readlines(), fromfile="baseline", tofile="latest", lineterm="")) if diff: print(fname, "有差异，共", len(diff), "行")

difflib对比不是拿来做精确代码评审，它帮你快速定位“什么变了”：MAC表项数量、收光数值、接口up/down状态、日志里出现的模式。凡是diff里有变化的字段，都值得去查一次原因。重点看三个方向：MAC表短时间内新增大量地址，往往对应私接路由或环路；同一端口收光连续两次巡检下降超过3dB，就该安排更换；接口状态变化对不上配置变更记录，说明有人在现场动了线。

日志集中收集对持续性巡检的作用比想象大。用一台Linux服务器搭一个syslog-ng或rsyslog的接收端，H3C设备配置一条info-center loghost 192.168.x.x，所有日志外送到服务器并按日期存档。这套东西不加网管平台，成本很低，适合一个人维护几百台设备的场景。我之前在一台核心交换机上配置日志外送后，发现某端口早已出现光模块告警，但因为没人盯着logbuffer，整整拖了一个月。后来在基线对比阶段快速定位到那个端口，换模块后问题消失。设备是个黑匣子，不持续记录就没有“后悔药”，而基线对比就是那味药。希望帮到你。

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