尧图网站建设 
简介面向网络运维与系统管理员的 H3C 交换机巡检命令参考文档汇总日常设备健康检查中最常用的 8 条命令覆盖 CPU、内存、温度、设备汇总、风扇、电源、系统时钟及接口状态等关键巡检项同时给出每条命令的作用释义与判断方法例如通过 display cpu-usage 查看多时段平均使用率、用 display environment 区分入风口与热点温度、按 display fan 和 display power 的 Normal/Abnormal 状态识别硬件故障等可帮助管理员快速定位性能下降或硬件异常等隐患。文档采用“命令、作用、解释、输出示例”的结构每条均附有实际回显与判断要点便于对照交换机执行巡检和排障。资源为单个 doc 文件大小约 21KB内容紧凑适合打印或导入笔记工具随时查阅目前已有 588 人学习下载是一份轻量实用的 H3C 交换机日常维护参考资料。1. H3C 交换机巡检命令十一二条命令撑起日常维护的底裤H3C 交换机的日常巡检命令其实就十一二条翻来覆去是display cpu-usage、display memory、display device这些。但真正值钱的不是命令本身而是「看什么、怎么判、出了差异怎么处理」。这份《H3C交换机巡检命令》文档把 S5500-34C-HI-D 上最常用的巡检命令整理成了清单每条命令带输出样例和解释。它解决的痛点很具体网络管理员拿到一台运行中的 H3C 交换机不知道从哪下手怕漏看关键项怕看到异常不知道怎么描述。适合刚接手 H3C 设备的一线运维、机房值班人员以及需要把巡检动作固化成脚本或交接文档的人。下面我把每条命令拆开讲顺带补上文档里没写但实际巡检一定会踩的坑。2. 拆解 11 条核心巡检命令输出怎么读、阈值怎么定、异常怎么判2.1display cpu-usageCPU 使用率要看趋势不要只看当前值CPU 使用率是巡检第一个要看的指标。命令执行后输出三段数据最近 5 秒、1 分钟、5 分钟的平均使用率。文档里的例子是 6%、5%、5%这在 S5500 这种盒式交换机上属于完全健康的水平。判断标准我一般这样卡5 分钟均值持续超过 60%或者 5 秒瞬时值反复冲到 80% 以上就值得查一下是什么流量或什么任务在打 CPU。中兴、锐捷的框式设备上还有display cpu带槽位号的写法H3C 这边如果是 IRF 堆叠命令会变成display cpu-usage slot 1文档里已经体现了这一点。这里有个容易误读的点Slot 1 CPU usage后面那几行每个 Slot 下还可能细分 CPU 核比如双主控设备上 Slot 1 CPU 1、CPU 2巡检记录时要写明是哪个槽位哪个核。只抄一个百分比回去事后对不上号。2.2display memory内存看已用率还要留意「越用越多」的积累内存命令输出很简单System Total Memory和Used Rate两个关键值。文档例子里 874453360 字节总内存、已用 13%在纯二层转发场景下正常。但内存巡检的重点不是单次数值而是两次巡检之间的增量。如果每次巡检已用率都在涨且涨幅明显比如一个月涨 5% 以上多半是 ARP 表项异常、MAC 地址表震荡、或者某个进程内存泄漏。H3C 的 Comware 5.20 平台上有display process memory可以看进程级内存占用文档里没提但实际排查内存泄漏时必用。2.3display environment温度看热点阈值别等告警才处理温度输出里有Inflow入风口和Hotspot热点两类传感器。文档例子 32/38 度属于凉爽区间。但每台设备物理位置不同不能死套一个绝对阈值。我的习惯是关注WarningLimit和AlarmLimit两列只要热点温度接近 WarningLimit 的 80%就开始查风扇转速、机柜通风、设备周围是否有杂物堆积。S5500-34C-HI-D 的 Warning 阈值是 77 度热点 38 度看起来离得远但夏天机柜空调故障时温度能在半天内从 40 冲到 70。2.4display device verbose设备汇总信息重点记型号、运行时长、软件版本这条命令输出分成两段上段是槽位硬件信息子卡类型、PCB 版本、CPLD、BootRom下段是整机信息。文档例子里给出了关键字段Brd Type: H3C S5500-34C-HI-D、Sft Ver: 5.20 Release 5203P03、Up Time: 10 weeks。这些信息在开故障工单或联系厂商支持时是必填项。特别注意Patch Ver: None意思是没打补丁这对安全加固来说是个薄弱点巡检时看到 None 要单独登记。2.5display fan/display power风扇看状态电源还要看类型和功率风扇和电源的巡检文档里的判断标准就一条Normal正常Abnormal异常。但电源输出里有个容易被忽略的字段——Type: AC/150(W)和Input Power: 63(W)。前者是电源模块的额定功率后者是当前实际输入功率。如果实际功率长期超过额定功率的 70%一旦另一路电源故障单电源带载可能过载保护。另外注意文档里的第二个电源State: Fault这是典型的双电源冗余失效场景——设备还在跑但冗余已经丢了这种状态必须当天处理。2.6display clock时间不对日志和排障全乱NTP 没配或者 NTP 服务器不可达时交换机时间会越走越偏。巡检时display clock主要确认两件事时间是否接近真实时间、时区是否正确。文档例子里显示17:08:12 UTC Mon 11/24/2014注意这里是 UTC 不是北京时间如果设备部署在中国且没配时区日志时间戳会差 8 小时排障时对不上号。这个问题在跨时区机房特别常见巡检发现时间偏差超过 5 分钟就要查 NTP 配置。2.7display interface brief接口状态、速率、VLAN 归属一屏看完这条命令是巡检里信息量最大的一条。文档输出分两部分路由模式接口M-GE0/0/0、Vlan1 等和桥接模式接口GE1/0/1 到 XGE1/0/30。桥接部分每一行包含 Link 状态、实际速率、双工模式、PVID。巡检时重点看两类异常一是本该 UP 的口 DOWN 了物理链路中断或对端设备关机二是速率异常——比如 GE 口显示100M(a)说明对端只有百兆能力或线缆老化降速了。文档例子里 GE1/0/20 显示10M(a)这种口如果实际承载业务必须查线缆和对端设备。2.8display version版本号是排障和升版的第一依据版本输出里最核心的是Comware Software, Version 5.20, Release 5203P03和H3C S5500-34C-HI-D uptime。uptime is 10 weeks, 0 day, 6 hours表示设备连续运行了 10 周这是判断设备是否发生过重启的直接证据。如果设备标称运行时间远短于上次巡检记录的时间说明期间设备重启过——可能是断电、死机自动重启也可能是被误操作 reboot。这条信息在追查「设备为什么丢配置」或「业务为什么中断过」时是重要线索。2.9display device manuinfo序列号、MAC、出厂日期资产管理和保修查询全靠它DEVICE_SERIAL_NUMBER: 210235A0X8H138000042是这台设备的唯一身份标识报障、查保修、核对资产台账都靠这个串号。MANUFACTURING_DATE: 2013-08-29说明这台设备已经服役多年巡检时要额外关注电解电容老化、风扇异响这类「高龄设备」常见问题。文档里还展示了Power 2: Error的输出——不是所有模块都支持查询序列号电源模块查询失败不一定代表硬件故障但要在巡检记录里备注。2.10display current-configuration配置备份的入口也是排查配置冲突的底稿这条命令输出当前生效的完整配置文档里截取了 Sysname、VLAN、接口、SNMP、SSH、本地用户等片段。巡检时把输出保存下来就是一份配置备份但有两个注意点一是输出里有密文密码password cipher $c$3$...存档时要注意文件权限二是配置里能看到arp static 192.168.0.166 0025-220f-b5eb这类静态 ARP 条目巡检时要确认这些静态条目是否还有效设备搬迁或 IP 规划调整后常留下失效的静态 ARP。3. 把命令串成巡检脚本从手工敲命令到一条命令完成采集3.1 用 expect 脚本自动登录并批量执行巡检命令H3C 交换机的命令行交互和 Linux 终端类似可以用 expect 脚本自动完成登录和命令采集。下面这段脚本适用于通过 SSH 登录设备后依次执行巡检命令并把输出重定向到以设备名命名的文件中。#!/usr/bin/expect set timeout 30 set host [lindex $argv 0] set user [lindex $argv 1] set pass [lindex $argv 2] spawn ssh $user$host expect { password: { send $pass\r } yes/no { send yes\r; exp_continue } } expect send screen-length disable\r expect send display cpu-usage\r expect send display memory\r expect send display environment\r expect send display device verbose\r expect send display fan\r expect send display power\r expect send display clock\r expect send display interface brief\r expect send display version\r expect send display device manuinfo\r expect send display current-configuration\r expect send quit\r expect eof这段脚本的核心逻辑是「发一条命令等一个提示符再发下一条」。screen-length disable是第一次登录后必须先执行的命令否则display current-configuration输出超过一屏时会停下等待翻页expect 脚本会卡在分页交互上。脚本里每个expect 都做了一个「等待命令执行完」的同步点实际使用中如果设备 CPU 繁忙导致命令响应慢set timeout 30要适当调大。注意脚本里的密码是明文传入的用完记得改权限。3.2 记录和判读巡检不是敲完命令就结束跑完脚本后输出文件要按日期归档命名规则建议是「设备名_IP_YYYYMMDD.txt」。判读时不要只看有没有Fault或Abnormal字样还要比对历史数据。比如display interface brief里某个端口上个月显示1G(a)这个月变成100M(a)这是典型的链路劣化信号——可能是光模块衰减、网线老化、对端设备端口故障。我的习惯是把每次巡检的关键数值CPU、内存、温度、电源状态、端口速率异常数提取到一张表格里连续看三个月的数据比单次巡检结论可靠得多。3.3 输出保存与归档翻车往往出在「忘了留档」巡检脚本把命令输出保存到文件后还要做两步一是用grep -E Fault|Abnormal|Error快速过滤异常关键字二是把文件同步到备份服务器或网盘。很多团队巡检做完不留档出了问题想对比历史状态时无从下手。归档时建议按季度打包文件名带上设备型号方便后续做设备健康度趋势分析。如果设备数量多还可以写一个循环脚本批量执行上面的 expect 脚本配合 Ansible 的 raw 模块也能达到类似效果。4. 避坑指南H3C 交换机巡检里的五个常见翻车现场4.1 分屏卡住导致脚本假死现象跑 expect 脚本时命令输出到一半脚本不动了等多久都没反应。原因display current-configuration输出超过一屏设备进入分页等待状态---- More ----脚本没有处理分页提示符。解决在脚本开头先执行screen-length disable关闭分页如果是交互式手工巡检可以在命令后加| no-more管道符跳过翻页例如display current-configuration | no-more。这个管道符在 H3C Comware 5.20 上有效支持所有display命令。4.2 CPU 使用率正常但业务卡顿现象display cpu-usage显示 CPU 只有 10%但业务丢包率高、Ping 延迟不稳定。原因CPU 使用率是平均值瞬时尖峰被平滑掉了或者问题不在 CPU 而在端口缓存溢出、STP 震荡、环路。解决用display cpu-usage的同时跑display cpu-usage history查看历史曲线配合display interface看端口丢包计数input errors和output errors再检查是否有环路display mac-address看 MAC 漂移。平均 CPU 低不代表转发路径健康。4.3 温度正常但风扇声音异常现象display fan显示Normal但设备运行噪音明显变大有咔哒声或高频啸叫。原因风扇状态检测只判断「转不转」不判断「转得快不快、稳不稳」。轴承磨损、缺油的风扇可能还在转但转速不均匀或已到寿命末期。解决除了看状态字还要用display environment对比热点温度和风扇转速如果设备支持display fan verbose可以看到转速值物理上每月听一次声音机柜环境嘈杂时可以用听诊器或手机录音辅助判断。风扇故障是渐进式的等Abnormal出现时往往已经高温告警了。4.4 时间偏差影响日志关联现象网络出问题后翻核心交换机日志发现和出口防火墙日志的时间对不上前后差了好几个小时排障时无法对齐时间线。原因交换机没配 NTP 或者 NTP 服务器不可达设备时间漂移。解决巡检时display clock看到的 UTC 时间要先换算再记录接入 NTP 后还要确认时区配置clock timezone有些设备配了 NTP 但时区是 UTC日志时间戳会少 8 小时。建议在配置里同时设置 NTP 服务器和clock timezone Beijing add 08:00:00并在巡检脚本里加一条display ntp-status确认 NTP 同步状态。4.5display interface brief里状态 DOWN 但物理链路正常现象端口显示DOWN但网线/光纤插着对端设备也正常拿测线仪测链路是通的。原因端口被shutdown了ADM状态或者端口配置了loopback或者对端设备端口 shutdown。解决看Link字段后面有没有ADM标记有ADM说明是人为 down 的在接口视图下执行undo shutdown恢复没有ADM但物理链路正常的检查对端设备端口状态。还有一个常见情况是光口没有插光模块display interface brief会显示DOWN这不一定是故障但要在巡检备注里注明「端口未使用」。5. 进阶用法把巡检命令和网络监控系统对接起来5.1 定期巡检 SNMP 采集两条腿走路手工巡检和脚本巡检解决了「有没有问题」的问题但解决不了「问题什么时候开始」的问题。进阶做法是把上面这些display命令的判读逻辑转化成 SNMP OID 采集。H3C 设备默认开启 SNMP 后CPU、内存、温度、端口状态都可以通过 snmpwalk 拉到监控系统里配合 Grafana 画趋势图。下面是一个用 Python 通过 SNMP 拉取 CPU 使用率的小脚本原理是把display cpu-usage的数据换成 SNMP 读取from pysnmp.hlapi import * def get_cpu_usage(ip, community): # H3C CPU 使用率的 OID不同型号可能不同S5500 系列用这个 oid 1.3.6.1.4.1.25506.2.6.1.1.1.1.12.1 error_indication, error_status, error_index, var_binds next( getCmd(SnmpEngine(), CommunityData(community), UdpTransportTarget((ip, 161)), ContextData(), ObjectType(ObjectIdentity(oid))) ) if error_indication: return None for var_bind in var_binds: return int(var_bind[1]) return None ip 192.168.0.100 community gpdc_lan cpu get_cpu_usage(ip, community) print(f{ip} CPU usage: {cpu}%)这段脚本的 OID 是 H3C 私有 MIB 里 CPU 使用率的常见位置但要注意不同型号、不同 Comware 版本的 OID 可能不同。最稳妥的做法是先在本机跑snmpwalk -v2c -c gpdc_lan 192.168.0.100 | grep -i cpu找出实际的 OID 路径再写进脚本。上面例子里community用的就是文档中配置片段里出现的gpdc_lan只读团体字实际生产环境要按自己的配置改。5.2 用主机名和序列号反推设备台账display device manuinfo输出的序列号文档例子210235A0X8H138000042有一个隐藏用途H3C 设备序列号的前缀和生产批次挂钩同样的序列号段往往意味着同一批采购、同样的硬件版本。批量巡检时把序列号收集起来整理成 Excel 台账后续做固件升级、硬件维保时可以按批次筛选不用一台台去设备上查。这个工作手工做一遍 100 台设备可能要一整天但用上面的 expect 脚本批量采集后再写个 Python 脚本正则提取DEVICE_SERIAL_NUMBER10 分钟就能出一份完整的序列号清单。5.3 巡检文档化把命令输出变成长期资产巡检的真正价值在于长期记录。我见过太多团队巡检就是「看一眼没事就走」真出事了拿不出依据。从这套命令出发建议每台核心设备建一个巡检档案按季度归档输出文件。巡检记录表固定格式巡检时间、设备型号、序列号、固件版本、CPU 均值、内存使用率、热点温度、电源状态、风扇状态、端口 DOWN 数量、异常备注。连续记录两个季度后你会对自己网络的「正常基线」有清晰认知之后再看到异常数值可以立刻判断严重程度。档案要放版本控制或网盘里换人交接时也能快速上手。5.4 最后说一个我踩过的坑——端口速率从 1G 掉到 100M 的隐患前年巡检一批 S5500 时display interface brief显示某台设备上联口从1G(a)变成了100M(a)当时觉得只是协商降速不影响业务。一个月后这个口彻底 DOWN 了业务中断。事后排查是网线水晶头氧化、线对接触不良导致链路不稳定。从那以后我每次巡检display interface brief都强制走一遍「对比上次速率记录」这个动作凡是速率和双工模式与上次不一致的端口当场标记为待排查项优先安排更换线缆或模块不等它自然恶化到断链。希望这个习惯对你的巡检工作也有帮助。本文还有配套的精品资源点击获取 H3C交换机巡检命令详解：11条必知命令与自动化实践
简介面向网络运维与系统管理员的 H3C 交换机巡检命令参考文档汇总日常设备健康检查中最常用的 8 条命令覆盖 CPU、内存、温度、设备汇总、风扇、电源、系统时钟及接口状态等关键巡检项同时给出每条命令的作用释义与判断方法例如通过 display cpu-usage 查看多时段平均使用率、用 display environment 区分入风口与热点温度、按 display fan 和 display power 的 Normal/Abnormal 状态识别硬件故障等可帮助管理员快速定位性能下降或硬件异常等隐患。文档采用“命令、作用、解释、输出示例”的结构每条均附有实际回显与判断要点便于对照交换机执行巡检和排障。资源为单个 doc 文件大小约 21KB内容紧凑适合打印或导入笔记工具随时查阅目前已有 588 人学习下载是一份轻量实用的 H3C 交换机日常维护参考资料。1. H3C 交换机巡检命令十一二条命令撑起日常维护的底裤H3C 交换机的日常巡检命令其实就十一二条翻来覆去是display cpu-usage、display memory、display device这些。但真正值钱的不是命令本身而是「看什么、怎么判、出了差异怎么处理」。这份《H3C交换机巡检命令》文档把 S5500-34C-HI-D 上最常用的巡检命令整理成了清单每条命令带输出样例和解释。它解决的痛点很具体网络管理员拿到一台运行中的 H3C 交换机不知道从哪下手怕漏看关键项怕看到异常不知道怎么描述。适合刚接手 H3C 设备的一线运维、机房值班人员以及需要把巡检动作固化成脚本或交接文档的人。下面我把每条命令拆开讲顺带补上文档里没写但实际巡检一定会踩的坑。2. 拆解 11 条核心巡检命令输出怎么读、阈值怎么定、异常怎么判2.1display cpu-usageCPU 使用率要看趋势不要只看当前值CPU 使用率是巡检第一个要看的指标。命令执行后输出三段数据最近 5 秒、1 分钟、5 分钟的平均使用率。文档里的例子是 6%、5%、5%这在 S5500 这种盒式交换机上属于完全健康的水平。判断标准我一般这样卡5 分钟均值持续超过 60%或者 5 秒瞬时值反复冲到 80% 以上就值得查一下是什么流量或什么任务在打 CPU。中兴、锐捷的框式设备上还有display cpu带槽位号的写法H3C 这边如果是 IRF 堆叠命令会变成display cpu-usage slot 1文档里已经体现了这一点。这里有个容易误读的点Slot 1 CPU usage后面那几行每个 Slot 下还可能细分 CPU 核比如双主控设备上 Slot 1 CPU 1、CPU 2巡检记录时要写明是哪个槽位哪个核。只抄一个百分比回去事后对不上号。2.2display memory内存看已用率还要留意「越用越多」的积累内存命令输出很简单System Total Memory和Used Rate两个关键值。文档例子里 874453360 字节总内存、已用 13%在纯二层转发场景下正常。但内存巡检的重点不是单次数值而是两次巡检之间的增量。如果每次巡检已用率都在涨且涨幅明显比如一个月涨 5% 以上多半是 ARP 表项异常、MAC 地址表震荡、或者某个进程内存泄漏。H3C 的 Comware 5.20 平台上有display process memory可以看进程级内存占用文档里没提但实际排查内存泄漏时必用。2.3display environment温度看热点阈值别等告警才处理温度输出里有Inflow入风口和Hotspot热点两类传感器。文档例子 32/38 度属于凉爽区间。但每台设备物理位置不同不能死套一个绝对阈值。我的习惯是关注WarningLimit和AlarmLimit两列只要热点温度接近 WarningLimit 的 80%就开始查风扇转速、机柜通风、设备周围是否有杂物堆积。S5500-34C-HI-D 的 Warning 阈值是 77 度热点 38 度看起来离得远但夏天机柜空调故障时温度能在半天内从 40 冲到 70。2.4display device verbose设备汇总信息重点记型号、运行时长、软件版本这条命令输出分成两段上段是槽位硬件信息子卡类型、PCB 版本、CPLD、BootRom下段是整机信息。文档例子里给出了关键字段Brd Type: H3C S5500-34C-HI-D、Sft Ver: 5.20 Release 5203P03、Up Time: 10 weeks。这些信息在开故障工单或联系厂商支持时是必填项。特别注意Patch Ver: None意思是没打补丁这对安全加固来说是个薄弱点巡检时看到 None 要单独登记。2.5display fan/display power风扇看状态电源还要看类型和功率风扇和电源的巡检文档里的判断标准就一条Normal正常Abnormal异常。但电源输出里有个容易被忽略的字段——Type: AC/150(W)和Input Power: 63(W)。前者是电源模块的额定功率后者是当前实际输入功率。如果实际功率长期超过额定功率的 70%一旦另一路电源故障单电源带载可能过载保护。另外注意文档里的第二个电源State: Fault这是典型的双电源冗余失效场景——设备还在跑但冗余已经丢了这种状态必须当天处理。2.6display clock时间不对日志和排障全乱NTP 没配或者 NTP 服务器不可达时交换机时间会越走越偏。巡检时display clock主要确认两件事时间是否接近真实时间、时区是否正确。文档例子里显示17:08:12 UTC Mon 11/24/2014注意这里是 UTC 不是北京时间如果设备部署在中国且没配时区日志时间戳会差 8 小时排障时对不上号。这个问题在跨时区机房特别常见巡检发现时间偏差超过 5 分钟就要查 NTP 配置。2.7display interface brief接口状态、速率、VLAN 归属一屏看完这条命令是巡检里信息量最大的一条。文档输出分两部分路由模式接口M-GE0/0/0、Vlan1 等和桥接模式接口GE1/0/1 到 XGE1/0/30。桥接部分每一行包含 Link 状态、实际速率、双工模式、PVID。巡检时重点看两类异常一是本该 UP 的口 DOWN 了物理链路中断或对端设备关机二是速率异常——比如 GE 口显示100M(a)说明对端只有百兆能力或线缆老化降速了。文档例子里 GE1/0/20 显示10M(a)这种口如果实际承载业务必须查线缆和对端设备。2.8display version版本号是排障和升版的第一依据版本输出里最核心的是Comware Software, Version 5.20, Release 5203P03和H3C S5500-34C-HI-D uptime。uptime is 10 weeks, 0 day, 6 hours表示设备连续运行了 10 周这是判断设备是否发生过重启的直接证据。如果设备标称运行时间远短于上次巡检记录的时间说明期间设备重启过——可能是断电、死机自动重启也可能是被误操作 reboot。这条信息在追查「设备为什么丢配置」或「业务为什么中断过」时是重要线索。2.9display device manuinfo序列号、MAC、出厂日期资产管理和保修查询全靠它DEVICE_SERIAL_NUMBER: 210235A0X8H138000042是这台设备的唯一身份标识报障、查保修、核对资产台账都靠这个串号。MANUFACTURING_DATE: 2013-08-29说明这台设备已经服役多年巡检时要额外关注电解电容老化、风扇异响这类「高龄设备」常见问题。文档里还展示了Power 2: Error的输出——不是所有模块都支持查询序列号电源模块查询失败不一定代表硬件故障但要在巡检记录里备注。2.10display current-configuration配置备份的入口也是排查配置冲突的底稿这条命令输出当前生效的完整配置文档里截取了 Sysname、VLAN、接口、SNMP、SSH、本地用户等片段。巡检时把输出保存下来就是一份配置备份但有两个注意点一是输出里有密文密码password cipher $c$3$...存档时要注意文件权限二是配置里能看到arp static 192.168.0.166 0025-220f-b5eb这类静态 ARP 条目巡检时要确认这些静态条目是否还有效设备搬迁或 IP 规划调整后常留下失效的静态 ARP。3. 把命令串成巡检脚本从手工敲命令到一条命令完成采集3.1 用 expect 脚本自动登录并批量执行巡检命令H3C 交换机的命令行交互和 Linux 终端类似可以用 expect 脚本自动完成登录和命令采集。下面这段脚本适用于通过 SSH 登录设备后依次执行巡检命令并把输出重定向到以设备名命名的文件中。#!/usr/bin/expect set timeout 30 set host [lindex $argv 0] set user [lindex $argv 1] set pass [lindex $argv 2] spawn ssh $user$host expect { password: { send $pass\r } yes/no { send yes\r; exp_continue } } expect send screen-length disable\r expect send display cpu-usage\r expect send display memory\r expect send display environment\r expect send display device verbose\r expect send display fan\r expect send display power\r expect send display clock\r expect send display interface brief\r expect send display version\r expect send display device manuinfo\r expect send display current-configuration\r expect send quit\r expect eof这段脚本的核心逻辑是「发一条命令等一个提示符再发下一条」。screen-length disable是第一次登录后必须先执行的命令否则display current-configuration输出超过一屏时会停下等待翻页expect 脚本会卡在分页交互上。脚本里每个expect 都做了一个「等待命令执行完」的同步点实际使用中如果设备 CPU 繁忙导致命令响应慢set timeout 30要适当调大。注意脚本里的密码是明文传入的用完记得改权限。3.2 记录和判读巡检不是敲完命令就结束跑完脚本后输出文件要按日期归档命名规则建议是「设备名_IP_YYYYMMDD.txt」。判读时不要只看有没有Fault或Abnormal字样还要比对历史数据。比如display interface brief里某个端口上个月显示1G(a)这个月变成100M(a)这是典型的链路劣化信号——可能是光模块衰减、网线老化、对端设备端口故障。我的习惯是把每次巡检的关键数值CPU、内存、温度、电源状态、端口速率异常数提取到一张表格里连续看三个月的数据比单次巡检结论可靠得多。3.3 输出保存与归档翻车往往出在「忘了留档」巡检脚本把命令输出保存到文件后还要做两步一是用grep -E Fault|Abnormal|Error快速过滤异常关键字二是把文件同步到备份服务器或网盘。很多团队巡检做完不留档出了问题想对比历史状态时无从下手。归档时建议按季度打包文件名带上设备型号方便后续做设备健康度趋势分析。如果设备数量多还可以写一个循环脚本批量执行上面的 expect 脚本配合 Ansible 的 raw 模块也能达到类似效果。4. 避坑指南H3C 交换机巡检里的五个常见翻车现场4.1 分屏卡住导致脚本假死现象跑 expect 脚本时命令输出到一半脚本不动了等多久都没反应。原因display current-configuration输出超过一屏设备进入分页等待状态---- More ----脚本没有处理分页提示符。解决在脚本开头先执行screen-length disable关闭分页如果是交互式手工巡检可以在命令后加| no-more管道符跳过翻页例如display current-configuration | no-more。这个管道符在 H3C Comware 5.20 上有效支持所有display命令。4.2 CPU 使用率正常但业务卡顿现象display cpu-usage显示 CPU 只有 10%但业务丢包率高、Ping 延迟不稳定。原因CPU 使用率是平均值瞬时尖峰被平滑掉了或者问题不在 CPU 而在端口缓存溢出、STP 震荡、环路。解决用display cpu-usage的同时跑display cpu-usage history查看历史曲线配合display interface看端口丢包计数input errors和output errors再检查是否有环路display mac-address看 MAC 漂移。平均 CPU 低不代表转发路径健康。4.3 温度正常但风扇声音异常现象display fan显示Normal但设备运行噪音明显变大有咔哒声或高频啸叫。原因风扇状态检测只判断「转不转」不判断「转得快不快、稳不稳」。轴承磨损、缺油的风扇可能还在转但转速不均匀或已到寿命末期。解决除了看状态字还要用display environment对比热点温度和风扇转速如果设备支持display fan verbose可以看到转速值物理上每月听一次声音机柜环境嘈杂时可以用听诊器或手机录音辅助判断。风扇故障是渐进式的等Abnormal出现时往往已经高温告警了。4.4 时间偏差影响日志关联现象网络出问题后翻核心交换机日志发现和出口防火墙日志的时间对不上前后差了好几个小时排障时无法对齐时间线。原因交换机没配 NTP 或者 NTP 服务器不可达设备时间漂移。解决巡检时display clock看到的 UTC 时间要先换算再记录接入 NTP 后还要确认时区配置clock timezone有些设备配了 NTP 但时区是 UTC日志时间戳会少 8 小时。建议在配置里同时设置 NTP 服务器和clock timezone Beijing add 08:00:00并在巡检脚本里加一条display ntp-status确认 NTP 同步状态。4.5display interface brief里状态 DOWN 但物理链路正常现象端口显示DOWN但网线/光纤插着对端设备也正常拿测线仪测链路是通的。原因端口被shutdown了ADM状态或者端口配置了loopback或者对端设备端口 shutdown。解决看Link字段后面有没有ADM标记有ADM说明是人为 down 的在接口视图下执行undo shutdown恢复没有ADM但物理链路正常的检查对端设备端口状态。还有一个常见情况是光口没有插光模块display interface brief会显示DOWN这不一定是故障但要在巡检备注里注明「端口未使用」。5. 进阶用法把巡检命令和网络监控系统对接起来5.1 定期巡检 SNMP 采集两条腿走路手工巡检和脚本巡检解决了「有没有问题」的问题但解决不了「问题什么时候开始」的问题。进阶做法是把上面这些display命令的判读逻辑转化成 SNMP OID 采集。H3C 设备默认开启 SNMP 后CPU、内存、温度、端口状态都可以通过 snmpwalk 拉到监控系统里配合 Grafana 画趋势图。下面是一个用 Python 通过 SNMP 拉取 CPU 使用率的小脚本原理是把display cpu-usage的数据换成 SNMP 读取from pysnmp.hlapi import * def get_cpu_usage(ip, community): # H3C CPU 使用率的 OID不同型号可能不同S5500 系列用这个 oid 1.3.6.1.4.1.25506.2.6.1.1.1.1.12.1 error_indication, error_status, error_index, var_binds next( getCmd(SnmpEngine(), CommunityData(community), UdpTransportTarget((ip, 161)), ContextData(), ObjectType(ObjectIdentity(oid))) ) if error_indication: return None for var_bind in var_binds: return int(var_bind[1]) return None ip 192.168.0.100 community gpdc_lan cpu get_cpu_usage(ip, community) print(f{ip} CPU usage: {cpu}%)这段脚本的 OID 是 H3C 私有 MIB 里 CPU 使用率的常见位置但要注意不同型号、不同 Comware 版本的 OID 可能不同。最稳妥的做法是先在本机跑snmpwalk -v2c -c gpdc_lan 192.168.0.100 | grep -i cpu找出实际的 OID 路径再写进脚本。上面例子里community用的就是文档中配置片段里出现的gpdc_lan只读团体字实际生产环境要按自己的配置改。5.2 用主机名和序列号反推设备台账display device manuinfo输出的序列号文档例子210235A0X8H138000042有一个隐藏用途H3C 设备序列号的前缀和生产批次挂钩同样的序列号段往往意味着同一批采购、同样的硬件版本。批量巡检时把序列号收集起来整理成 Excel 台账后续做固件升级、硬件维保时可以按批次筛选不用一台台去设备上查。这个工作手工做一遍 100 台设备可能要一整天但用上面的 expect 脚本批量采集后再写个 Python 脚本正则提取DEVICE_SERIAL_NUMBER10 分钟就能出一份完整的序列号清单。5.3 巡检文档化把命令输出变成长期资产巡检的真正价值在于长期记录。我见过太多团队巡检就是「看一眼没事就走」真出事了拿不出依据。从这套命令出发建议每台核心设备建一个巡检档案按季度归档输出文件。巡检记录表固定格式巡检时间、设备型号、序列号、固件版本、CPU 均值、内存使用率、热点温度、电源状态、风扇状态、端口 DOWN 数量、异常备注。连续记录两个季度后你会对自己网络的「正常基线」有清晰认知之后再看到异常数值可以立刻判断严重程度。档案要放版本控制或网盘里换人交接时也能快速上手。5.4 最后说一个我踩过的坑——端口速率从 1G 掉到 100M 的隐患前年巡检一批 S5500 时display interface brief显示某台设备上联口从1G(a)变成了100M(a)当时觉得只是协商降速不影响业务。一个月后这个口彻底 DOWN 了业务中断。事后排查是网线水晶头氧化、线对接触不良导致链路不稳定。从那以后我每次巡检display interface brief都强制走一遍「对比上次速率记录」这个动作凡是速率和双工模式与上次不一致的端口当场标记为待排查项优先安排更换线缆或模块不等它自然恶化到断链。希望这个习惯对你的巡检工作也有帮助。本文还有配套的精品资源点击获取