简介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 命令的实测输出是这样的H3Cdisplay 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%说明有个突发任务正在执行不是常态如果两档都在高位那才是持续过载。再看内存H3Cdisplay 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 输出H3Cdisplay 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 NAInflow 表示入风口温度传感器hotspot 表示热点温度传感器。S5500 的设备温度通常指热点温度也就是 hotspot 这一行。文档里这台机器 hotspot 38 度距离 WarningLimit 77 度还有很大余量。需要特别注意的是有人会把 LowerLimit 当成过冷告警实际这档对交换机意义不大机房环境很难把设备冻到 0 度以下真正要盯的是 Warning 和 Alarm 两档。风扇和电源简单直接H3Cdisplay fan Slot 1 FAN 1 State : Normal H3Cdisplay 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这两条命令的价值在于确认自己管的是谁。文档输出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 5203P03Up Time 是关键字段。它表示设备连续运行了多长时间。如果两次巡检之间 Up Time 变小说明设备重启过。Brd Status 显示 Master说明这台设备在 IRF 堆叠中处于主设备角色如果和它堆叠的成员设备出问题会直接影响转发。再配合 display version 看硬件和软件细节H3Cdisplay 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] 24GE4SFP2SFP PLUS Hardware Version is REV.B[SubSlot 0] 后面的 24GE4SFP2SFP 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 1Link 列是物理链路状态UP 表示有设备连接且物理链路正常DOWN 表示没有对端或线路断开。Speed 和 Duplex 后面的 (a) 表示 auto 协商F(a) 是自动协商后的全双工。Type 列 A 是 access、T 是 trunk、H 是 hybridPVID 是端口所属 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 NormalPower 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_dirinspection): child pexpect.spawn( ssh -o StrictHostKeyCheckingno %s%s % (dev[user], dev[host]), timeout30, encodingutf-8, ) # 处理密码提示出现 password 关键词后发送密码 i child.expect([(P|p)assword:, pexpect.EOF, pexpect.TIMEOUT], timeout20) 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[#]], timeout10) 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, encodingutf-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 ---- 的逻辑放在了循环里遇到分页发空格直到提示符出现才认为命令执行完。参数使用上timeout30 是单条命令的等待上限如果你的设备响应慢可以调到 60encodingutf-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 1display 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 系列的基础阈值表指标合格基线关注线处理线CPU 使用率5 分钟档≤ 30%持续 60% 80% 且伴随丢包内存 Used Rate≤ 60% 70% 85% 且绝对值持续上涨热点温度 Hotspot≤ 60℃≥ 70℃≥ 77℃Warning入风口温度 Inflow≤ 55℃≥ 60℃≥ 67℃Warning风扇状态Normal—Abnormal 立即处理电源状态Normal—双电源中任一 Fault这张表里的温度处理线直接取自已文档的 WarningLimitCPU 和内存的线是我按 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 回退和版本号变化这两类差异会直接写进交接单哪怕其他指标全部正常也要写。这个习惯帮我抓住过两次没人承认重启过的设备异常也让我对巡检这事越来越不依赖临场发挥。希望帮到你。本文还有配套的精品资源点击获取
H3C交换机巡检命令详解：11条display命令清单与脚本批量巡检实践
简介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 命令的实测输出是这样的H3Cdisplay 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%说明有个突发任务正在执行不是常态如果两档都在高位那才是持续过载。再看内存H3Cdisplay 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 输出H3Cdisplay 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 NAInflow 表示入风口温度传感器hotspot 表示热点温度传感器。S5500 的设备温度通常指热点温度也就是 hotspot 这一行。文档里这台机器 hotspot 38 度距离 WarningLimit 77 度还有很大余量。需要特别注意的是有人会把 LowerLimit 当成过冷告警实际这档对交换机意义不大机房环境很难把设备冻到 0 度以下真正要盯的是 Warning 和 Alarm 两档。风扇和电源简单直接H3Cdisplay fan Slot 1 FAN 1 State : Normal H3Cdisplay 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这两条命令的价值在于确认自己管的是谁。文档输出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 5203P03Up Time 是关键字段。它表示设备连续运行了多长时间。如果两次巡检之间 Up Time 变小说明设备重启过。Brd Status 显示 Master说明这台设备在 IRF 堆叠中处于主设备角色如果和它堆叠的成员设备出问题会直接影响转发。再配合 display version 看硬件和软件细节H3Cdisplay 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] 24GE4SFP2SFP PLUS Hardware Version is REV.B[SubSlot 0] 后面的 24GE4SFP2SFP 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 1Link 列是物理链路状态UP 表示有设备连接且物理链路正常DOWN 表示没有对端或线路断开。Speed 和 Duplex 后面的 (a) 表示 auto 协商F(a) 是自动协商后的全双工。Type 列 A 是 access、T 是 trunk、H 是 hybridPVID 是端口所属 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 NormalPower 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_dirinspection): child pexpect.spawn( ssh -o StrictHostKeyCheckingno %s%s % (dev[user], dev[host]), timeout30, encodingutf-8, ) # 处理密码提示出现 password 关键词后发送密码 i child.expect([(P|p)assword:, pexpect.EOF, pexpect.TIMEOUT], timeout20) 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[#]], timeout10) 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, encodingutf-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 ---- 的逻辑放在了循环里遇到分页发空格直到提示符出现才认为命令执行完。参数使用上timeout30 是单条命令的等待上限如果你的设备响应慢可以调到 60encodingutf-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 1display 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 系列的基础阈值表指标合格基线关注线处理线CPU 使用率5 分钟档≤ 30%持续 60% 80% 且伴随丢包内存 Used Rate≤ 60% 70% 85% 且绝对值持续上涨热点温度 Hotspot≤ 60℃≥ 70℃≥ 77℃Warning入风口温度 Inflow≤ 55℃≥ 60℃≥ 67℃Warning风扇状态Normal—Abnormal 立即处理电源状态Normal—双电源中任一 Fault这张表里的温度处理线直接取自已文档的 WarningLimitCPU 和内存的线是我按 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 回退和版本号变化这两类差异会直接写进交接单哪怕其他指标全部正常也要写。这个习惯帮我抓住过两次没人承认重启过的设备异常也让我对巡检这事越来越不依赖临场发挥。希望帮到你。本文还有配套的精品资源点击获取
