简介一份面向H3C交换机运维人员的巡检命令速查文档覆盖设备日常健康检查的典型场景适用于网络管理员、运维工程师等需要定期掌握设备运行状态并快速定位隐患的读者。资源包共1个doc文件大小仅21KB便于下载后打印或离线查看虽体量精简但内容针对性强。正文围绕8条高频巡检命令展开CPU使用率、内存使用率、设备温度、设备汇总信息、风扇状态、电源状态、系统时间及接口信息并对每条命令对应的display指令、输出字段和正常/异常判断给出简要说明例如通过display cpu-usage判断负载、通过display environment识别温度隐患、通过display power和display fan核查冗余状态。掌握这套命令可以帮助管理员在巡检中快速摸清交换机运行健康度发现CPU过载、内存不足、高温、风扇或电源故障等问题并及时处理从而保障网络稳定运行。目前已有588人学习下载适合现场运维时对照参考。1. 巡检命令多而散最怕的不是设备多是漏项凌晨被群里一条“核心交换机 CPU 90%”的告警吵醒登上去一查发现有个接口的错误包已经连续涨了三个月没人看过。这不是个例。H3C 交换机巡检命令本身不难难在散落在十几个 display 命令里临时想查哪个就查哪个最后巡检就变成“看一眼 CPU、看一眼接口没红就关”。这篇把 H3C 交换机巡检命令按设备健康、接口链路、二层三层、堆叠聚合几条线串起来每步讲清楚命令是什么、输出看哪个数、什么值该处理适合正在维护 H3C 交换机的网络运维和弱电工程师直接照着抄也适合刚接手华三设备的人把它当成第一份巡检清单。2. 巡检前先立规矩display 只读、时间对齐、输出关分屏2.1 display 命令体系先分清状态类和统计类H3C 交换机的查询命令全部以display开头命令行里常用dis缩写加?补全。这里有个关键认知display系命令全部只读不会改配置所以巡检时放开胆子敲不用怕把设备敲坏。真正要担心的是不知道每条命令的输出里哪个字段才是需要盯住的数。我习惯把巡检命令分成两堆来记状态类display device、display cpu-usage、display memory、display environment、display interface brief。这类命令看的是“当下设备处于什么状态”是个快照。统计类display interface里的错包计数、display logbuffer里的日志、display mac-address的表项。这类命令看的是“从开机到现在累计发生了什么”是时间序列。两类分开的价值在于状态类命令拿来看当下有没有病统计类命令拿来看病是不是在加重。只看状态不看统计就会漏掉“接口一直是 UP但 CRC 错包已经涨了几万”这种隐患只看统计不看状态又会因为一个历史告警浪费半天排查时间。巡检时先过状态类再过统计类顺序固定不要乱。另外一个常见误用是拿display current-configuration当巡检命令。这条命令适合做配置备份或变更前存档不适合日常巡检因为输出太长而且配置对不对要结合现网行为判断不是看一眼就能知道有没有问题。2.2 时间对齐时间不对日志等于白看巡检时最容易被忽略的前提是时间。设备时间不准日志告警、错误包时间戳全部失去意义。我曾经接过一台 H3C S1850 的故障客户说“每天早上八点断网”结果日志里全是凌晨四点的记录一查才发现设备本身没做时间同步和真实时间差了四个小时。常见做法是开局就把 NTP 配上让交换机自动同步网络日期和时间。配置命令本身很简单ntp-service enable ntp-service unicast-server 192.168.100.100第一行启用 NTP 客户端第二行指定 NTP 服务器地址这里写的是内网常见的时间服务器。配置完用display ntp-service status确认同步状态看到时钟已同步、服务器可达再往下走。不同软件版本的命令可能有细微差异如果提示命令不识别敲display ntp-service ?看当前版本究竟支持什么。巡检时我每台设备都会先敲display clock确认设备时间和 NTP 服务器偏差在 30 秒以内。偏差太大的设备后续所有日志分析都不可信先解决时间再谈别的。2.3 screen-length disable批量收结果前必须解决分屏交互H3C 命令行默认输出超过一屏会停下显示---- More ----需要按空格逐屏翻。人肉操作时这没问题但如果你把命令粘进脚本批量执行输出会在第一屏就停住脚本傻等设备端一堆会话就这么挂着。解决办法是在进入会话后先关掉分屏screen-length disable这条命令在用户视图执行只对当前会话有效断开重连就恢复默认所以脚本里每次连接都要在开头发一次。批量收结果时把它放在所有巡检命令之前后面的display输出就会一口气全部滚出来。V7 之后的版本基本都支持这个命令老平台的设备如果不识别可以试screen-length 0效果相同。如果两条都不认说明设备命令行版本太老只能接受翻页或者把单条命令的输出重定向到 FTP 目录再取文件。2.4 开局三连保存配置、看日志缓冲、确认启动文件开始巡检前我习惯先做三个动作比任何高级技巧都保命。第一是save force先把当前配置保存到启动文件。巡检时经常发现上一班同事改完配置没保存你这边查线、理业务设备一旦重启就全回去了这种翻车太常见一个有save force的习惯等于给自己留了后悔药。save force display logbuffer display startupsave force跳过交互式确认直接把配置写入 Flash。接下来display logbuffer看最近日志重点关注端口 up/down、告警、登录失败记录display startup确认下次启动时加载的配置文件确实是当前运行的这份。顺带说一句现在有些 H3C 设备会用 Web 管理辅助运维涉及ip http enable和local-user这类命令日志里会多出 HTTP 登录成功或失败的记录。巡检看到这类日志别当成攻击大惊小怪先确认是不是同事登录的重点还是放在端口、链路、CPU 这些硬件和转发相关的日志上。3. 核心巡检命令拆解设备层到业务层逐条看什么3.1 设备层CPU、内存、温度、风扇都不该被略过设备层巡检从display version开始。这里不只看软件版本更重要的是看 Uptime也就是设备已运行时间。刚开机的设备意味着近期发生过重启要追问是断电、重启命令还是设备自行复位这是排查隐患的第一线索。display version display device display cpu-usage display memory display environmentdisplay device显示各单板状态Slot Status 是 Normal 才正常如果你的设备是框式交换机还要关注电源和风扇模块的状态。display cpu-usage会给出 5 秒、1 分钟、5 分钟的平均使用率不要只看当前值重点看 1 分钟和 5 分钟是不是持续走高持续走高说明有协议计算或转发异常在积累。display memory看内存使用率内存碎片化严重的设备会出现“内存还够但业务起不来”的怪现象。display environment用于查温度和风扇转速盒式交换机不一定支持这条命令不支持会直接报错跳过即可。我一般把阈值定在CPU 持续超过 70% 开始观察超过 85% 要尽快处理内存使用率超过 90% 告警机箱温度超过 70 摄氏度就要检查风扇和机房环境。这些是我经验的参考线不同型号差异很大最终以设备手册上的指标为准。3.2 接口与链路接口 UP 不等于链路健康display interface brief是第一眼望向整个设备接口状态的地方。输出会列出所有物理接口的 Link 状态、Speed、Duplex一眼能扫出哪些接口 down、哪些协商成了低速率。这里有个极易踩的坑down 的接口不一定有故障可能是对端没接设备或管理性关闭但一个预期该 up 的接口 down 了就要往下查。display interface brief display interface counters errors display transceiver interface GigabitEthernet1/0/1display interface counters errors是巡检接口错误包最好用的命令一次列出所有接口的输入输出错误计数。看到 CRC 错误持续增长优先怀疑线缆质量、水晶头氧化、光模块光衰看到 input errors 和 output errors 同步涨先检查两端双工模式是否一致交换机对接交换机时尤其常见两端一台是百兆一台是千兆协商过程翻车就会导致大量错包。光口设备还要查光模块状态。对光模块执行display transceiver interface看输出光功率和接收光功率接收光功率接近灵敏度的临界值是最麻烦的情况接口显示 UP、业务也不完全断但错包和丢包率缓慢上升。这种问题后面单独在避坑章节展开。普通电口或没有 DDM 功能的光模块这条命令会返回 N/A属正常现象。3.3 二层链路VLAN、STP、MAC 一条线顺下来二层巡检从display vlan brief开始确认 VLAN 存在确认每个业务 VLAN 的端口成员符合预期。这里要特别留意 Trunk 口的放通列表新增业务时最容易犯的错是 VLAN 建了、接口也加入了但 Trunk 口忘了放通导致上层设备根本看不到这个 VLAN。display vlan brief display stp brief display mac-addressdisplay stp brief看生成树端口角色和状态。正常网络里根桥端口为 ROOT、转发端口为 DESI、阻塞端口为 ALTE端口状态基本都在 FORWARDING。如果看到大量端口在 LEARNING 和 FORWARDING 之间反复切换说明拓扑在震荡环路风险高。MAC 地址表则看是否有同一个 MAC 出现在多个接口上并且源端口频繁切换这是广播环路最典型的早期征兆等风暴起来再抓包就晚了。我一般会把这三条命令排在一起执行二层问题往往不是单一表象。VLAN 配错了体现为业务不通STP 阻塞错了体现为链路不用MAC 漂移体现为间歇性卡顿单独看任何一条命令都容易被误导串起来读才有全局画面。3.4 三层与网关ARP、路由表、VRRP 的检查顺序三层巡检对核心交换机尤其重要因为网关挂在核心上。先查display arp确认 IP 与 MAC 对应关系正常重点看有没有同一个 IP 对应两个 MAC这是 IP 冲突的铁证。再查display ip routing-table看默认路由是否还在、动态路由是否正常学习缺省路由丢了全网出不了外网表现却是“内网没事外网全断”。display arp display ip routing-table display vrrpVRRP 是网关冗余的核心机制display vrrp输出里最关键的是每个 VRRP 组的 Master/Backup 角色。正常一个组只有一个 Master其它全是 Backup。如果看到两个设备同时是 Master就是 VRRP 抢占配置或心跳线出了问题网关会间歇性不可达用户感知就是“网络好一阵坏一阵”。检查顺序我建议固定为 ARP → 路由表 → VRRP因为地址解析是通信的起点路由决定转发路径冗余协议决定故障切换。顺序反了容易在链路正常但业务不通时绕远路。3.5 堆叠与聚合IRF 和 Eth-Trunk 一眼看出隐患核心层华三交换机的常见架构是堆叠加链路聚合也就是 IRF 加 Eth-Trunk。很多华三交换机堆叠配置实例里这两者会同时出现多台设备堆叠成一台逻辑设备跨设备的物理链路聚合成一条逻辑链路。巡检堆叠设备命令组合是display irf display irf topology display link-aggregation summarydisplay irf看堆叠成员信息和角色正常情况下只有一个 Master其余为 Standby。如果出现两个或多个 Master说明堆叠分裂了这是重大故障会让广播报文和业务流量在分裂后的设备间来回绕。display irf topology看堆叠拓扑是否闭合IRF 的堆叠链路应该有完整连接断了一条就要尽快处理否则再断一条就可能裂堆叠。display link-aggregation summary看聚合组的状态。很多人遇到过“h3c 聚合口满了”的情况表现是成员端口都 UP但 Selected 端口数比成员数少聚合带宽上不去。原因多半是成员端口速率或双工不一致、对端端口没加入对应聚合组、或者是静态聚合和动态聚合模式不匹配。巡检时记住一个判断标准聚合组成员应该全部处在 Selected 状态有不 Selected 的聚合链路就是残缺的这比接口掉线更隐蔽。4. 批量巡检落地用 Paramiko 半小时收集全部交换机输出4.1 为什么不推荐人肉敲命令以及 Python 怎么选型设备超过十台人肉 SSH 逐台敲命令的做法就很痛苦不只是慢还会漏命令。我见过有人巡检二十台设备敲到第十五台时漏了display memory自己完全没察觉。批量巡检的刚需是把命令固定成模板每台设备跑同一套命令输出落盘再统一分析。选型上我优先推荐用 Python 加 Paramiko这是 SSH 协议的纯 Python 实现pip 装一个就能用没有额外服务端依赖。比 Paramiko 更省事的是 Netmiko它封装了设备登录、等提示符、关分屏这些通用逻辑如果你愿意装依赖把device_type配成hp_comware就能直接用。Paramiko 的好处是让你能看清每一步交互出了问题容易排查本文就以它为主。4.2 可抄作业的 Paramiko 巡检脚本下面这个脚本我日常在用去掉业务细节后保留核心逻辑直接复制保存成inspect_h3c.py就能用import paramiko import time import datetime DEVICES [ # [设备IP, 用户名, 密码, 备注名] [192.168.10.1, admin, Pssw0rd, core-sw-01], [192.168.10.2, admin, Pssw0rd, core-sw-02], ] CMDS [ screen-length disable, display clock, display version, display device, display cpu-usage, display memory, display environment, display interface brief, display interface counters errors, display vlan brief, display stp brief, display arp, display ip routing-table, display vrrp, display irf, display link-aggregation summary, display logbuffer, ] def collect(host, username, password, tag): client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, port22, usernameusername, passwordpassword, timeout10, banner_timeout15, auth_timeout15) shell client.invoke_shell() time.sleep(2) # 等待设备发送 banner shell.recv(65535) # 清掉 banner 内容 lines [] for cmd in CMDS: shell.send(cmd \n) time.sleep(1.5) # 等待命令输出按设备性能调整 data shell.recv(65535).decode(utf-8, errorsignore) lines.append(########## cmd ##########) lines.append(data) client.close() filename f{tag}_{datetime.datetime.now():%Y%m%d_%H%M%S}.txt with open(filename, w, encodingutf-8) as f: f.write(\n.join(lines)) print(f[OK] {tag} - {filename}) if __name__ __main__: for dev in DEVICES: try: collect(*dev) except Exception as e: print(f[ERR] {dev[3]} 连接失败: {e})逻辑说明脚本先定义设备和要执行的命令清单collect函数负责连接设备、清空 banner、逐条发送命令并读取回显最后把结果写入以设备名加时间戳命名的文件。命令清单里第一条就是screen-length disable确保后续输出不会卡在分屏交互上。参数说明方面time.sleep是粗糙等待策略1.5 秒通常够普通交换机回完一个 display 命令设备性能差或命令输出特别长时可以调到 2 秒以上。recv(65535)单次最多读 64KB命令输出超过这个量会读不全display logbuffer在日志多的时候可能遇到解决办法是改成循环读取直到输出完毕或者把display logbuffer的日志行数限制一下。banner_timeout和auth_timeout是针对慢网络环境的超时保护避免 SSH 握手阶段无限期卡住。4.3 脚本参数说明与跑通步骤跑通这套脚本的步骤只有三步。第一步安装依赖pip install paramiko第二步把开机设备清单填进脚本的DEVICES列表建议先在字段里只放一台测试设备密码用明文只是为了演示生产环境建议改成从环境变量读取设备密码落在脚本里本身就是一个安全隐患。第三步运行脚本输出会直接生成在当前目录。我一般每台设备一个子目录比如20250630/core-sw-01_20250630_231000.txt文件名带日期时间后续做趋势对比时直接用文件名排序就能找到同设备的历史巡检记录。这个脚本真正的短板是等待和读取全部是固定节奏遇到慢设备会读不全输出。如果不想写这种“苦力活”更推荐 Netmiko它会自动等提示符命令执行更可靠from netmiko import ConnectHandler device { device_type: hp_comware, host: 192.168.10.1, username: admin, password: Pssw0rd, } conn ConnectHandler(**device) for cmd in CMDS: print(conn.send_command(cmd)) conn.disconnect()device_type写hp_comware是因为 Netmiko 对华三平台的驱动名沿用了历史名称H3C 和 HPE 的 Comware 平台通用。这段代码省掉了所有分屏和等待处理因为 Netmiko 内部已经做了提示符等待和分页关闭。我的建议是新手先用 Paramiko 理解交互过程被等待问题坑过之后再迁到 Netmiko。4.4 不写 Python 的备选方案plink 批处理如果现场没有 Python 环境或者只是临时收一批设备的输出plink 是更轻的办法。plink 是 PuTTY 自带的命令行 SSH 工具在 Windows 下可以直接用。把要执行的命令按顺序写进一个文件比如commands.txtscreen-length disable display clock display version display cpu-usage display memory display interface brief display interface counters errors display vlan brief display stp brief display arp display ip routing-table display vrrp display irf display link-aggregation summary display logbuffer quit然后通过 plink 在批处理里逐台执行plink -ssh -pw Pssw0rd admin192.168.10.1 -m commands.txt core-sw-01.txtplink 会把commands.txt里的命令逐条发送给设备并把回显重定向到本地文件。注意两点plink 首次连接会询问是否信任主机密钥批处理脚本里建议加-batch参数让它遇到确认提示直接失败而不是卡住另外文件里绝对不能放save这种会进入交互模式的命令plink 没有处理 Y/N 确认的能力。想批量保存配置单独用一个文件放save force或者干脆用 Python 脚本处理。5. 避坑指南H3C 巡检中常踩的 5 个坑5.1 分屏截断脚本收到一半就停结果还不报错现象脚本执行不报错但输出文件到某条命令就断了断点基本都停在同一行带---- More ----的位置。原因新开的 SSH 会话默认分屏 24 行命令超过一屏就进入等待翻页状态。Paramiko 脚本要是没有做翻页处理就会在这里傻等。解决把screen-length disable放在所有巡检命令的第一个。这条命令只对当前会话有效所以脚本每次连接都要发一次plink 场景里就放在commands.txt第一行。老版本设备不支持这条命令的试screen-length 0再不行只能改用逐屏翻页的交互读取。5.2 光功率临界接口 UP、业务不丢包但错包在涨现象光口接口一直是 UP业务看起来没断但display interface counters errors里的 CRC 错包持续增长快照对比时增量明显。这种问题最玄学因为接口状态根本不给你任何提示。原因光模块接收光功率掉到接收灵敏度附近信号质量差但还没到完全失步的程度。接头脏了、光纤打弯过、跳线老化都会导致这种状态。解决用display transceiver interface GigabitEthernet1/0/1查接收光功率连续两次巡检对比数值。接收功率接近灵敏度且持续下行直接安排现场清端面、更换跳线或光模块别等它彻底 down 了再去处理。5.3 堆叠分裂看似两台主设备其实已经各玩各的现象业务间歇性不通但每台设备单独看都没有硬件故障display irf显示两台设备全是 Master。原因IRF 堆叠链路中断后设备之间的心跳丢失如果没有配置 MAD 检测各设备会同时对外宣称自己是主设备形成“双主”分裂。此时两台设备同时承载网关或同网段业务广播和未知单播会在链路里反复传送。解决巡检时重点看display irf里的 Role 字段Master 只能有一个。更可靠的做法是配置 IRF MAD 检测分裂发生后备机自动关闭自身业务口。要注意的是看到备机接口被 shutdown 不一定就是故障可能是 MAD 保护在起作用先恢复堆叠链路再看接口状态。5.4 日志溢出logbuffer 装不下历史日志被挤掉现象现场告警说设备几点几分断过网但登上设备执行display logbuffer记录窗口只有最近十几分钟故障时间点完全对不上。原因logbuffer 是内存缓冲区容量有限日志量大时旧日志会被新日志顶掉缓冲区里只留下最近的内容。解决巡检时除了看display logbuffer还要确认信息中心有没有把日志落到文件里。常见做法是启用 logfile设备会把日志持续写入 Flash 中的日志文件display logbuffer只做快速查看真正的完整记录要从日志文件里找。配置命令是info-center enable info-center logfile enable日志文件有容量上限但比内存缓冲区大得多至少能覆盖更长的排障窗口。5.5 模拟器与真机差异命令敲得通不代表真机也认现象先在 H3C 模拟器里把命令敲通、验证了思路到真机上执行却报Unrecognized command或者命令存在但行为表现和在模拟器里不一样。原因模拟器的软件版本和真机实际运行的版本有差异不同版本的命令集、参数格式、显示字段都可能不一致。模拟器里敲着顺手的命令真机上可能被改成别的写法或者根本不存在。解决把模拟器当成记忆命令和熟悉逻辑的工具不要当成配置兼容性验证平台。真机操作前用display version确认软件版本以该版本实际支持的命令集为准。另外 H3C 模拟器设备启动失败的问题多半不是命令问题而是宿主机虚拟化环境版本不匹配或内存不足先解决运行环境再谈命令验证。6. 让巡检结果越攒越有用两次快照对比法6.1 增量对比错误包、CPU 峰值才能反应趋势单次巡检能发现当下故障发现不了正在酝酿的故障。错误包计数是累计值今天 100 个明天 100 个没有意义只有两次巡检间隔中多出来的那部分才是风险信号。我的做法是把每次巡检输出存成带日期的文件分析时只对比增量。用第 4 章脚本保存的文件可以直接做关键字过滤和对比grep -E CRC|input error|output error|discard core-sw-01_20250601.txt err_day1.txt grep -E CRC|input error|output error|discard core-sw-01_20250630.txt err_day2.txt diff err_day1.txt err_day2.txtdiff对两边的行做逐条比较新增的行就是这一个月里冒出来的错误记录。如果只是少量新行且数值小属于正常波动如果是某个接口的错误计数大幅增长就直接定位到了问题端口。这种方法要求两次巡检的命令必须完全一样同一个命令今天用全称明天用缩写输出格式对不上diff 结果就没有参考价值这也是我把命令清单写死成模板的原因。6.2 巡检记录模板一张表把设备归档下来增量对比做的是数据还有一件事是文档。我习惯每月巡检后按下面的格式把每台设备的关键信息填进一张表长期积累下来就是每台设备的历史档案区块核心命令关键指标判定标准设备信息display version软件版本、Uptime版本符合预期长时间未重启硬件健康display cpu-usage / memory / environmentCPU 1 分钟峰值、内存使用率、温度CPU 小于 70%内存小于 90%温度低于 70 摄氏度接口链路display interface counters errorsCRC、error、discard 增量与上次快照相比无异常增长二层协议display vlan brief / stp briefVLAN 放通、端口角色、端口状态无异常 Discarding无角色震荡三层网关display arp / vrrpIP-MAC 对应、Master 数量无 IP 冲突每 VRRP 组仅一个 Master堆叠聚合display irf / link-aggregation summaryMaster 数量、Selected 端口数仅一个 Master聚合组成员全部 Selected表格里的命令都是第 3 章讲过的那几条阈值按我前面写的经验值如果你所在网络对接入质量要求更严格可以把 CPU 阈值从 70% 压到 50%这个完全取决于业务容忍度。我现在的习惯是每个月第一周跑一次批量巡检把输出文件归档把关键字段填进这张表遇到设备翻车时直接翻出前三个月的记录对比三分钟就能判断出问题是突发的还是积累的。这个习惯帮我解决过不少“以前好好的怎么突然不行了”的争议。希望帮到你。本文还有配套的精品资源点击获取