简介面向网络运维人员与H3C设备管理员这份H3C交换机巡检命令文档系统梳理了日常设备巡检中最关键的八类检查项CPU使用率、内存占用、设备温度、硬件汇总信息、风扇运行状态、电源健康状态、系统时钟准确性以及接口链路状态。每个命令都配有作用说明、具体执行方式与典型输出示例并对关键输出字段进行了解读如内存使用率百分比、温度传感器的入风与热点阈值、风扇和电源的Normal/Fault状态标识、设备型号与运行时间、接口的Link/Protocol状态等。通过对照这些信息运维人员可以快速识别设备潜在风险并采取修复措施有效避免因资源耗尽、高温或硬件故障导致的业务中断。资源为单个doc文档体积仅21KB内容紧凑实用适合打印或在终端旁快速查阅。目前已有588人学习下载可作为H3C交换机日常维护与故障排查的入门参考。1. 先把H3C交换机巡检命令.doc这件事说清楚它解决什么、适合谁每天早上到客户机房我习惯先把核心交换机登录上去看一眼CPU、光衰、日志有没有异常确认昨晚没出幺蛾子才敢开始动配置。H3C交换机巡检命令.doc就是这个动作的物化把散在官方手册里的display命令挑出十几条排成一张固定顺序的检查清单让任何接手的人都能在半小时内完成一次“不漏项、结果可对比”的设备体检。它不是网管系统的替代品但对刚接手H3C设备、没有统一监控平台、或者要替客户做例行巡检的工程师来说比翻手册高效得多。这篇文章就围绕命令怎么选、执行顺序怎么排、输出怎么判读来讲。2. 巡检前先处理三件事登录方式、会话设置和配置基线2.1 登录方式怎么选Console、Telnet、SSH各有各的脾气巡检第一步是登录设备但登录方式选不对后面全白搭。常见做法是优先走SSH因为它加密远程改配置不会明文暴露Console口留给设备失联或SSH登录不了时的最后手段Telnet能用但明文传输我在生产环境基本不碰除非客户内网隔离得足够干净。如果你用的是SecureCRT或者MobaXtermConsole登录就是选Serial波特率9600数据位8无校验。MobaXterm的Session面板里直接选Serial端口会自动识别USB转串口的那个COM号连上后回车就能看到H3C的提示符。这里有个容易被忽略的点H3C设备默认不一定开启SSH服务很多新拿到的设备只配了Telnet或者Console你直接用CRT去SSH连接会卡在“Connection failed”上——这不是密码错了是设备压根没开这个服务。在设备上按下面方式开启SSH以Comware V7为主V5大体类似system-view ssh server enable # 创建一个本地用户并让它能通过SSH登录 local-user admin class manage password simple YourPassword service-type ssh authorization-attribute user-role network-admin quit这段配置的关键在于local-user admin class manage里的service-type ssh。很多踩坑的人只开了ssh server enable忘了给本地用户加SSH服务类型结果就是“密码正确但登录被拒”。V5设备上不用写class manage直接local-user admin即可。巡检建议不要用超级管理员账号做日常登录能用一个只读级别账号最好但现实是客户给的往往是admin所以至少要做到巡检时不乱敲配置命令。2.2 会话设置关闭分页和日志回显让命令输出不被截断登录之后先别急着敲巡检命令把会话环境调好。H3C默认开启分屏显示输出长一点就会停在---- More ----等你按空格。巡检时如果你用的是CRT或MobaXterm这一屏一屏翻过去既慢又容易漏而且脚本批量操作时会直接卡死。我的习惯是登录后先执行下面两条screen-length disable undo terminal monitorscreen-length disable在用户视图下执行只对当前会话生效作用是临时关闭分屏让display输出一次性完整滚出来不会卡在More上。注意它是“临时”的重登就恢复默认所以不用担心影响其他运维同事。undo terminal monitor是关掉终端的日志回显——设备上有接口up/down、OSPF邻居抖动之类的信息时会往终端刷屏把命令输出和日志混在一起影响判断。巡检时把它关掉输出干净巡检完建议重新登录或者直接不管因为会话结束就恢复。还有一条容易被忽略但很重要先执行display clock确认设备时间。日志里的事件时间全靠这个时钟如果时间不对后面所有告警分析全是错的。display clock这一步我一般放在会话设置之后、正式巡检之前几秒钟的事但能避免后面分析日志时发现时间基准是歪的。常见做法是把display clock作为巡检命令模板的第一条固定命令。2.3 巡检前的基线备份先留后路再动手巡检不只是“看状态”还要和上次的状态做对比所以巡检前把当前配置备份下来是铁律。很多刚入行的工程师习惯最后才备份但巡检过程中可能会因为误操作改到配置或者发现某个配置不对劲顺手调了一下这时如果已经备份过至少有个后悔药。display current-configuration save cfg-backup-YYYYMMDD.cfgdisplay current-configuration是查看运行配置输出很长建议配合前面的screen-length disable一起用输出重定向到本地保存。save命令是把运行配置保存到下次启动的配置文件里文件名里带上日期比如cfg-backup-20250611.cfg。需要注意save会覆盖设备默认的启动配置。如果只是巡检、没有改动需求不要随便save如果确实改了配置需要保存先display current-configuration看一眼改动是否合理再执行save。我见过有人巡检时顺手save结果把之前临时调试用的interface shutdown配置固化了设备重启后端口起不来——这就是典型的“巡检变事故”。3. 日常巡检命令组从硬件到日志一路查过来3.1 系统和硬件状态版本、序列号、风扇、电源和温度巡检命令不是乱敲的我按“从底层到上层”的顺序来。第一组关注设备本身能不能稳定运行。display version display device display fan display power display environmentdisplay version看软件版本和系统运行时间重点看版本是否已知有Bug以及设备是否刚重启过。display device看板卡状态重点看State是不是Normal如果有Fault就要留意了。display fan和display power分别看风扇和电源Status字段为Normal才算正常。display environment看温度H3C设备一般有当前温度、上下限阈值温度接近上限说明机房通风有问题需要处理。这几个命令都比较短输出也不长适合巡检模板开头先打出来。如果设备是堆叠环境再加一条display irf看堆叠成员是否齐全、角色是否正常。堆叠设备巡检漏掉IRF状态是常见失误——单台设备看着正常但堆叠分裂了业务其实已经出问题了。3.2 接口与光模块光衰怎么看、什么范围算健康接口是交换机最核心的资源。巡检时我通常先看接口概览再重点查光模块收发光。display interface brief display transceiver diagnosis interface Ten-GigabitEthernet 1/0/1display interface brief列出所有接口的Link状态和Protocol状态一眼就能看出哪些端口down了。如果某个关键业务端口down可能只是对端设备关机也可能是光缆断了需要进一步排查。光模块是另一个高频问题点。display transceiver diagnosis interface会输出光模块的收发光功率、温度、电压等数字诊断信息。注意这个命令需要光模块支持DDM数字诊断监控功能原厂模块基本都支持有些第三方模块会显示--这是模块不带监控或兼容性问题不代表光路正常。紫光等国产设备命令风格与H3C相近也适用这个思路。光衰的参数解释需要单独说清楚收发光功率的单位是dBm数值越小表示功率越低。常见阈值是接收光功率在-3dBm到-14dBm之间属于正常低于-20dBm就要警惕可能出现误码低于-27dBm基本会闪断甚至完全不通。发送光功率一般比接收高不同模块差异大但关键是看它是否稳定不要忽高忽低。如果这条命令不支持退一步用display transceiver interface Ten-GigabitEthernet 1/0/0看模块基础信息至少能确认模块是否被识别、温度是否异常。3.3 CPU、内存与日志系统是否在“带病运行”CPU和内存代表设备当前的负载日志则记录它过去发生过什么。三者一起看才能判断设备是健康还是“带病运行”。display cpu-usage display memory display logbufferComware V7用display cpu-usageV5上是display cpu注意区分。CPU使用率看两个值当前值和5秒内峰值。H3C交换机转发主要靠芯片CPU高不一定影响转发但如果长期超过50%要查是不是有大量控制报文冲击比如ARP攻击、路由震荡。display memory看内存使用率长期超过70%就要关注是否有内存泄漏常见诱因是开启了过多NetStream采样或大量ACL统计。display logbuffer看的是设备内存里的日志缓冲区重点看有没有反复出现的告警比如接口频繁up/down、光模块告警、协议邻居震荡。日志缓冲区容量有限如果设备长时间未重启老日志会被覆盖所以巡检发现重要日志时建议用display logbuffer看完后关键内容截取保存。有一条命令容易被忽略display ntp-status。设备时间如果通过NTP同步这里能看到同步状态。没有NTP的设备日志时间会慢慢漂移出现问题后回溯时对不上时间点。巡检时发现NTP未同步可以在后续整改时把NTP配置补上。3.4 链路与冗余聚合口、STP状态看一眼更安心如果设备承担着核心或汇聚角色链路冗余状态必须纳入巡检范围。display link-aggregation summary display stp brief display mac-addressdisplay link-aggregation summary看聚合口成员是否都在Selected状态如果成员口是Unselected说明链路有问题或者对端配置不一致。display stp brief看STP端口状态正常应该是FORWARDING出现BLOCKING不一定有问题——可能是冗余路径故意阻塞但如果是应该转发的端口在Blocking就要检查配置了。display mac-address看MAC表项数量是否正常数量异常波动可能意味着环路或MAC漂移。这一组命令通常不用每次巡检都完整执行。我一般每周做一次完整巡检时跑一遍每日快速巡检只跑接口和CPU。4. 把命令固化成doc模板脚本采集和判读标准一起落地4.1 doc模板怎么排先结构后命令别让巡检变成碰运气“H3C交换机巡检命令.doc”这个标题的关键在“doc”也就是巡检模板本身。模板的价值在于固定顺序、固定项目、留出判读空间。我见过不少人把命令直接堆在一个文档里巡检时照着敲但输出没有对齐过几天就忘了上次结果是什么。我习惯的模板结构分六块设备基本信息、硬件状态、接口状态、光模块、CPU内存、日志告警。每块列出对应的命令、预期输出字段、以及“正常/异常”判读标准。设备基本信息用display version和display clock开头记录巡检日期让每次巡检都有时间锚点。模板里给每条命令留一个“判读”列不写死结果而是写阈值比如“CPU使用率50%峰值80%”这样巡检人有据可依。表格在doc里有独特价值。比如光模块判读表参数正常范围关注范围异常范围接收光功率-3dBm ~ -14dBm-14dBm ~ -20dBm低于-20dBm发送光功率稳定在模块标称范围波动超过3dB明显衰减或无输出模块温度低于报警阈值接近阈值超过阈值电压标准值±5%偏差较大严重偏差这个表格我每次都会放进巡检doc里比单纯列命令有用得多。华为、思科、锐捷的命令与H3C有相似之处尤其华为和H3C同源display风格接近思科更偏show体系。做巡检模板时如果团队同时管多种设备建议按设备品牌分sheet命令不要混在一个模板里容易敲串。4.2 用Python批量采集命令输出解放双手但别盲目自动化手动逐条敲命令适合少数几台设备设备一多就容易漏。我自己会用Python的paramiko库写一个批量巡检脚本把命令输出按设备存档。脚本逻辑很简单连接设备→执行命令列表→把输出写入txt文件。import paramiko import datetime devices [ {host: 192.168.1.10, username: admin, password: YourPass}, ] commands [ display clock, display version, display device, display interface brief, display transceiver diagnosis interface, display cpu-usage, display memory, display logbuffer, ] today datetime.datetime.now().strftime(%Y%m%d) for dev in devices: ssh paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect(dev[host], port22, usernamedev[username], passworddev[password], timeout10) output_lines [] for cmd in commands: stdin, stdout, stderr ssh.exec_command(cmd \n, timeout30) output stdout.read().decode(utf-8, errorsignore) output_lines.append(f {cmd} ) output_lines.append(output) ssh.close() filename fh3c_{dev[host]}_{today}.txt with open(filename, w, encodingutf-8) as f: f.write(\n.join(output_lines)) print(f已保存 {filename})脚本里要注意几个参数paramiko本身需要pip install paramiko安装exec_command每执行一条命令都是独立的SSH会话命令之间不保留上下文所以screen-length disable这类会话级设置要放进每条命令之前或者在命令列表里把每条display命令后面加上分页关闭参数。更稳妥的方式是连接后先执行screen-length disable但exec_command之间的会话不共享这确实是个坑。我一般会改成用ssh.invoke_shell()创建交互式shell先发screen-length disable再逐条发送命令这样能模拟手动操作时的完整会话。timeout参数建议设30秒以上某些命令如display current-configuration在设备繁忙时会很慢超时太短会导致输出截断。4.3 判读标准要写在doc里输出不等于结论采集完输出最关键的是怎么判读。很多巡检表格只记了输出原文没有判读结论这就失去了巡检的意义。我建议doc模板里加一列“结论”用“正常/关注/异常”三档来标记。判读的基本原则CPU和内存看是否超过基线接口看有没有非预期down口光模块看收发光是否在正常范围日志看有没有重复告警。基线数据从哪来来自设备稳定运行期间的多次巡检平均值。没有基线单看一次输出很难判断CPU 40%是高还是低。如果发现异常doc模板里应该留“排查行动”栏写下一步要做什么。比如光衰低于-20dBm行动是检查尾纤是否弯折、法兰是否松动、对端模块是否正常。没有行动项的巡检报告客户看了也不知道该怎么办最后只能变成一张没意义的表格。5. 巡检避坑5个最常见的问题与排查思路5.1 现象CRT的SSH连不上H3C设备提示连接失败或被拒绝原因H3C设备默认没有开启SSH服务或者本地用户没有SSH服务类型只开了Telnet。很多新交付的设备配置里只有Console和Telnet访问远程SSH 22端口并不存在。解决登录Console口在系统视图下执行ssh server enable然后local-user admin class manage里加service-type ssh。检查是否还有其他限制比如ACL限制了管理网段。排查时按顺序看display ssh server status和display local-user确认服务开启和用户绑定都正确。5.2 现象执行display命令输出卡在More脚本或粘贴的命令被吞掉原因H3C默认开启分屏输出长度超过一屏就暂停等待输入此时粘贴的后续命令会被当作翻页操作吞掉导致命令不完整或误操作。解决用户视图下执行screen-length disable临时关闭当前会话分屏。需要写脚本批量巡检时注意在每条命令前确保分页已关闭如果是CRT手动操作登录后第一件事就执行这条命令。不要试图用CRT的“自动发送空格”去翻页那样既慢又容易漏。5.3 现象光模块收发光显示--查询不到任何数值原因光模块不支持DDM数字诊断功能或者模块与设备兼容性不佳导致设备读取不到诊断数据。常见于第三方模块。解决用display transceiver interface查看模块基础信息确认模块是否被识别。如果基础信息正常但无DDM数据只能更换支持DDM的原厂模块否则光衰判断无依据。巡检模板里要特别标注哪些口是这类模块避免每次巡检都误判为异常。5.4 现象日志里的时间与当前时间相差数小时告警分析对不上原因设备没有配置NTP也没有设置时区或者时区设置错误。Comware设备默认使用UTC时间国内环境需要手动设置UTC8时区。解决配置clock timezone Beijing add 8再配置NTP同步ntp-service enable、ntp-service unicast-server指向NTP服务器。巡检时执行display ntp-status确认同步状态如果NTP服务器不可达至少手动校准clock datetime。不解决时间问题日志分析基本等于猜。5.5 现象巡检时随手save重启后配置与预期不符原因save会把运行配置写入启动配置覆盖原有配置文件。如果巡检前设备上有临时改动比如测试接口shutdown或临时加了一条ACLsave会把它们固化导致重启后行为改变。解决巡检前用display current-configuration查看完整配置确认没有临时调试配置再执行save。异常存储时使用save cfg-backup-YYYYMMDD.cfg不要直接覆盖默认启动配置。设备多台批量巡检时尤其要注意别在脚本里自动save——脚本操作没有人在现场确认配置状态。6. 巡检结果归档一张时间线表加一条救命习惯巡检做完结果不能只留在终端里。我现在的习惯是每台设备一个文件夹按日期命名里面放巡检输出txt、告警截图、配置备份。文件夹里额外放一张归档说明表记录巡检日期、设备IP、关键判读结论。日期设备CPU峰值内存峰值接收光衰最差日志告警结论2025-06-11核心-S7006X35%42%-13.5dBm无正常2025-06-04核心-S7006X42%45%-15.2dBm接口抖动1次观察这张时间线表是判断设备“是否在恶化”的核心依据。单次巡检只能反映当下状态多次巡检拉出趋势才能发现光衰在逐周下降、内存缓慢增长这类问题。没有归档巡检就只是重复劳动。还有一个习惯值得分享每次巡检前先执行display clock和display version这两条命令的输出是后续所有判读的时间锚点和版本锚点。版本变了要知会变更流程时间不对要先校准再谈日志分析。这个习惯帮我发现过两次设备在夜间自动重启的隐患重启日志在logbuffer里被覆盖了但版本运行时间出卖了它。日志集中化也是值得做的延伸网管平台上用syslog-ng搭建一个日志服务把交换机日志实时收到服务器上巡检时就多了一个历史日志回溯的渠道。设备本地日志缓冲区再大也会被覆盖集中化日志才是长期可追溯的方案。巡检这件事本身不产生价值产生价值的是持续的对比和及时的行动。希望对你有帮助。本文还有配套的精品资源点击获取 
长河君 · 2026/10/4 2:13:17 · 阅读 1.2k H3C交换机巡检命令详解：从SSH登录到光模块判读
简介面向网络运维人员与H3C设备管理员这份H3C交换机巡检命令文档系统梳理了日常设备巡检中最关键的八类检查项CPU使用率、内存占用、设备温度、硬件汇总信息、风扇运行状态、电源健康状态、系统时钟准确性以及接口链路状态。每个命令都配有作用说明、具体执行方式与典型输出示例并对关键输出字段进行了解读如内存使用率百分比、温度传感器的入风与热点阈值、风扇和电源的Normal/Fault状态标识、设备型号与运行时间、接口的Link/Protocol状态等。通过对照这些信息运维人员可以快速识别设备潜在风险并采取修复措施有效避免因资源耗尽、高温或硬件故障导致的业务中断。资源为单个doc文档体积仅21KB内容紧凑实用适合打印或在终端旁快速查阅。目前已有588人学习下载可作为H3C交换机日常维护与故障排查的入门参考。1. 先把H3C交换机巡检命令.doc这件事说清楚它解决什么、适合谁每天早上到客户机房我习惯先把核心交换机登录上去看一眼CPU、光衰、日志有没有异常确认昨晚没出幺蛾子才敢开始动配置。H3C交换机巡检命令.doc就是这个动作的物化把散在官方手册里的display命令挑出十几条排成一张固定顺序的检查清单让任何接手的人都能在半小时内完成一次“不漏项、结果可对比”的设备体检。它不是网管系统的替代品但对刚接手H3C设备、没有统一监控平台、或者要替客户做例行巡检的工程师来说比翻手册高效得多。这篇文章就围绕命令怎么选、执行顺序怎么排、输出怎么判读来讲。2. 巡检前先处理三件事登录方式、会话设置和配置基线2.1 登录方式怎么选Console、Telnet、SSH各有各的脾气巡检第一步是登录设备但登录方式选不对后面全白搭。常见做法是优先走SSH因为它加密远程改配置不会明文暴露Console口留给设备失联或SSH登录不了时的最后手段Telnet能用但明文传输我在生产环境基本不碰除非客户内网隔离得足够干净。如果你用的是SecureCRT或者MobaXtermConsole登录就是选Serial波特率9600数据位8无校验。MobaXterm的Session面板里直接选Serial端口会自动识别USB转串口的那个COM号连上后回车就能看到H3C的提示符。这里有个容易被忽略的点H3C设备默认不一定开启SSH服务很多新拿到的设备只配了Telnet或者Console你直接用CRT去SSH连接会卡在“Connection failed”上——这不是密码错了是设备压根没开这个服务。在设备上按下面方式开启SSH以Comware V7为主V5大体类似system-view ssh server enable # 创建一个本地用户并让它能通过SSH登录 local-user admin class manage password simple YourPassword service-type ssh authorization-attribute user-role network-admin quit这段配置的关键在于local-user admin class manage里的service-type ssh。很多踩坑的人只开了ssh server enable忘了给本地用户加SSH服务类型结果就是“密码正确但登录被拒”。V5设备上不用写class manage直接local-user admin即可。巡检建议不要用超级管理员账号做日常登录能用一个只读级别账号最好但现实是客户给的往往是admin所以至少要做到巡检时不乱敲配置命令。2.2 会话设置关闭分页和日志回显让命令输出不被截断登录之后先别急着敲巡检命令把会话环境调好。H3C默认开启分屏显示输出长一点就会停在---- More ----等你按空格。巡检时如果你用的是CRT或MobaXterm这一屏一屏翻过去既慢又容易漏而且脚本批量操作时会直接卡死。我的习惯是登录后先执行下面两条screen-length disable undo terminal monitorscreen-length disable在用户视图下执行只对当前会话生效作用是临时关闭分屏让display输出一次性完整滚出来不会卡在More上。注意它是“临时”的重登就恢复默认所以不用担心影响其他运维同事。undo terminal monitor是关掉终端的日志回显——设备上有接口up/down、OSPF邻居抖动之类的信息时会往终端刷屏把命令输出和日志混在一起影响判断。巡检时把它关掉输出干净巡检完建议重新登录或者直接不管因为会话结束就恢复。还有一条容易被忽略但很重要先执行display clock确认设备时间。日志里的事件时间全靠这个时钟如果时间不对后面所有告警分析全是错的。display clock这一步我一般放在会话设置之后、正式巡检之前几秒钟的事但能避免后面分析日志时发现时间基准是歪的。常见做法是把display clock作为巡检命令模板的第一条固定命令。2.3 巡检前的基线备份先留后路再动手巡检不只是“看状态”还要和上次的状态做对比所以巡检前把当前配置备份下来是铁律。很多刚入行的工程师习惯最后才备份但巡检过程中可能会因为误操作改到配置或者发现某个配置不对劲顺手调了一下这时如果已经备份过至少有个后悔药。display current-configuration save cfg-backup-YYYYMMDD.cfgdisplay current-configuration是查看运行配置输出很长建议配合前面的screen-length disable一起用输出重定向到本地保存。save命令是把运行配置保存到下次启动的配置文件里文件名里带上日期比如cfg-backup-20250611.cfg。需要注意save会覆盖设备默认的启动配置。如果只是巡检、没有改动需求不要随便save如果确实改了配置需要保存先display current-configuration看一眼改动是否合理再执行save。我见过有人巡检时顺手save结果把之前临时调试用的interface shutdown配置固化了设备重启后端口起不来——这就是典型的“巡检变事故”。3. 日常巡检命令组从硬件到日志一路查过来3.1 系统和硬件状态版本、序列号、风扇、电源和温度巡检命令不是乱敲的我按“从底层到上层”的顺序来。第一组关注设备本身能不能稳定运行。display version display device display fan display power display environmentdisplay version看软件版本和系统运行时间重点看版本是否已知有Bug以及设备是否刚重启过。display device看板卡状态重点看State是不是Normal如果有Fault就要留意了。display fan和display power分别看风扇和电源Status字段为Normal才算正常。display environment看温度H3C设备一般有当前温度、上下限阈值温度接近上限说明机房通风有问题需要处理。这几个命令都比较短输出也不长适合巡检模板开头先打出来。如果设备是堆叠环境再加一条display irf看堆叠成员是否齐全、角色是否正常。堆叠设备巡检漏掉IRF状态是常见失误——单台设备看着正常但堆叠分裂了业务其实已经出问题了。3.2 接口与光模块光衰怎么看、什么范围算健康接口是交换机最核心的资源。巡检时我通常先看接口概览再重点查光模块收发光。display interface brief display transceiver diagnosis interface Ten-GigabitEthernet 1/0/1display interface brief列出所有接口的Link状态和Protocol状态一眼就能看出哪些端口down了。如果某个关键业务端口down可能只是对端设备关机也可能是光缆断了需要进一步排查。光模块是另一个高频问题点。display transceiver diagnosis interface会输出光模块的收发光功率、温度、电压等数字诊断信息。注意这个命令需要光模块支持DDM数字诊断监控功能原厂模块基本都支持有些第三方模块会显示--这是模块不带监控或兼容性问题不代表光路正常。紫光等国产设备命令风格与H3C相近也适用这个思路。光衰的参数解释需要单独说清楚收发光功率的单位是dBm数值越小表示功率越低。常见阈值是接收光功率在-3dBm到-14dBm之间属于正常低于-20dBm就要警惕可能出现误码低于-27dBm基本会闪断甚至完全不通。发送光功率一般比接收高不同模块差异大但关键是看它是否稳定不要忽高忽低。如果这条命令不支持退一步用display transceiver interface Ten-GigabitEthernet 1/0/0看模块基础信息至少能确认模块是否被识别、温度是否异常。3.3 CPU、内存与日志系统是否在“带病运行”CPU和内存代表设备当前的负载日志则记录它过去发生过什么。三者一起看才能判断设备是健康还是“带病运行”。display cpu-usage display memory display logbufferComware V7用display cpu-usageV5上是display cpu注意区分。CPU使用率看两个值当前值和5秒内峰值。H3C交换机转发主要靠芯片CPU高不一定影响转发但如果长期超过50%要查是不是有大量控制报文冲击比如ARP攻击、路由震荡。display memory看内存使用率长期超过70%就要关注是否有内存泄漏常见诱因是开启了过多NetStream采样或大量ACL统计。display logbuffer看的是设备内存里的日志缓冲区重点看有没有反复出现的告警比如接口频繁up/down、光模块告警、协议邻居震荡。日志缓冲区容量有限如果设备长时间未重启老日志会被覆盖所以巡检发现重要日志时建议用display logbuffer看完后关键内容截取保存。有一条命令容易被忽略display ntp-status。设备时间如果通过NTP同步这里能看到同步状态。没有NTP的设备日志时间会慢慢漂移出现问题后回溯时对不上时间点。巡检时发现NTP未同步可以在后续整改时把NTP配置补上。3.4 链路与冗余聚合口、STP状态看一眼更安心如果设备承担着核心或汇聚角色链路冗余状态必须纳入巡检范围。display link-aggregation summary display stp brief display mac-addressdisplay link-aggregation summary看聚合口成员是否都在Selected状态如果成员口是Unselected说明链路有问题或者对端配置不一致。display stp brief看STP端口状态正常应该是FORWARDING出现BLOCKING不一定有问题——可能是冗余路径故意阻塞但如果是应该转发的端口在Blocking就要检查配置了。display mac-address看MAC表项数量是否正常数量异常波动可能意味着环路或MAC漂移。这一组命令通常不用每次巡检都完整执行。我一般每周做一次完整巡检时跑一遍每日快速巡检只跑接口和CPU。4. 把命令固化成doc模板脚本采集和判读标准一起落地4.1 doc模板怎么排先结构后命令别让巡检变成碰运气“H3C交换机巡检命令.doc”这个标题的关键在“doc”也就是巡检模板本身。模板的价值在于固定顺序、固定项目、留出判读空间。我见过不少人把命令直接堆在一个文档里巡检时照着敲但输出没有对齐过几天就忘了上次结果是什么。我习惯的模板结构分六块设备基本信息、硬件状态、接口状态、光模块、CPU内存、日志告警。每块列出对应的命令、预期输出字段、以及“正常/异常”判读标准。设备基本信息用display version和display clock开头记录巡检日期让每次巡检都有时间锚点。模板里给每条命令留一个“判读”列不写死结果而是写阈值比如“CPU使用率50%峰值80%”这样巡检人有据可依。表格在doc里有独特价值。比如光模块判读表参数正常范围关注范围异常范围接收光功率-3dBm ~ -14dBm-14dBm ~ -20dBm低于-20dBm发送光功率稳定在模块标称范围波动超过3dB明显衰减或无输出模块温度低于报警阈值接近阈值超过阈值电压标准值±5%偏差较大严重偏差这个表格我每次都会放进巡检doc里比单纯列命令有用得多。华为、思科、锐捷的命令与H3C有相似之处尤其华为和H3C同源display风格接近思科更偏show体系。做巡检模板时如果团队同时管多种设备建议按设备品牌分sheet命令不要混在一个模板里容易敲串。4.2 用Python批量采集命令输出解放双手但别盲目自动化手动逐条敲命令适合少数几台设备设备一多就容易漏。我自己会用Python的paramiko库写一个批量巡检脚本把命令输出按设备存档。脚本逻辑很简单连接设备→执行命令列表→把输出写入txt文件。import paramiko import datetime devices [ {host: 192.168.1.10, username: admin, password: YourPass}, ] commands [ display clock, display version, display device, display interface brief, display transceiver diagnosis interface, display cpu-usage, display memory, display logbuffer, ] today datetime.datetime.now().strftime(%Y%m%d) for dev in devices: ssh paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect(dev[host], port22, usernamedev[username], passworddev[password], timeout10) output_lines [] for cmd in commands: stdin, stdout, stderr ssh.exec_command(cmd \n, timeout30) output stdout.read().decode(utf-8, errorsignore) output_lines.append(f {cmd} ) output_lines.append(output) ssh.close() filename fh3c_{dev[host]}_{today}.txt with open(filename, w, encodingutf-8) as f: f.write(\n.join(output_lines)) print(f已保存 {filename})脚本里要注意几个参数paramiko本身需要pip install paramiko安装exec_command每执行一条命令都是独立的SSH会话命令之间不保留上下文所以screen-length disable这类会话级设置要放进每条命令之前或者在命令列表里把每条display命令后面加上分页关闭参数。更稳妥的方式是连接后先执行screen-length disable但exec_command之间的会话不共享这确实是个坑。我一般会改成用ssh.invoke_shell()创建交互式shell先发screen-length disable再逐条发送命令这样能模拟手动操作时的完整会话。timeout参数建议设30秒以上某些命令如display current-configuration在设备繁忙时会很慢超时太短会导致输出截断。4.3 判读标准要写在doc里输出不等于结论采集完输出最关键的是怎么判读。很多巡检表格只记了输出原文没有判读结论这就失去了巡检的意义。我建议doc模板里加一列“结论”用“正常/关注/异常”三档来标记。判读的基本原则CPU和内存看是否超过基线接口看有没有非预期down口光模块看收发光是否在正常范围日志看有没有重复告警。基线数据从哪来来自设备稳定运行期间的多次巡检平均值。没有基线单看一次输出很难判断CPU 40%是高还是低。如果发现异常doc模板里应该留“排查行动”栏写下一步要做什么。比如光衰低于-20dBm行动是检查尾纤是否弯折、法兰是否松动、对端模块是否正常。没有行动项的巡检报告客户看了也不知道该怎么办最后只能变成一张没意义的表格。5. 巡检避坑5个最常见的问题与排查思路5.1 现象CRT的SSH连不上H3C设备提示连接失败或被拒绝原因H3C设备默认没有开启SSH服务或者本地用户没有SSH服务类型只开了Telnet。很多新交付的设备配置里只有Console和Telnet访问远程SSH 22端口并不存在。解决登录Console口在系统视图下执行ssh server enable然后local-user admin class manage里加service-type ssh。检查是否还有其他限制比如ACL限制了管理网段。排查时按顺序看display ssh server status和display local-user确认服务开启和用户绑定都正确。5.2 现象执行display命令输出卡在More脚本或粘贴的命令被吞掉原因H3C默认开启分屏输出长度超过一屏就暂停等待输入此时粘贴的后续命令会被当作翻页操作吞掉导致命令不完整或误操作。解决用户视图下执行screen-length disable临时关闭当前会话分屏。需要写脚本批量巡检时注意在每条命令前确保分页已关闭如果是CRT手动操作登录后第一件事就执行这条命令。不要试图用CRT的“自动发送空格”去翻页那样既慢又容易漏。5.3 现象光模块收发光显示--查询不到任何数值原因光模块不支持DDM数字诊断功能或者模块与设备兼容性不佳导致设备读取不到诊断数据。常见于第三方模块。解决用display transceiver interface查看模块基础信息确认模块是否被识别。如果基础信息正常但无DDM数据只能更换支持DDM的原厂模块否则光衰判断无依据。巡检模板里要特别标注哪些口是这类模块避免每次巡检都误判为异常。5.4 现象日志里的时间与当前时间相差数小时告警分析对不上原因设备没有配置NTP也没有设置时区或者时区设置错误。Comware设备默认使用UTC时间国内环境需要手动设置UTC8时区。解决配置clock timezone Beijing add 8再配置NTP同步ntp-service enable、ntp-service unicast-server指向NTP服务器。巡检时执行display ntp-status确认同步状态如果NTP服务器不可达至少手动校准clock datetime。不解决时间问题日志分析基本等于猜。5.5 现象巡检时随手save重启后配置与预期不符原因save会把运行配置写入启动配置覆盖原有配置文件。如果巡检前设备上有临时改动比如测试接口shutdown或临时加了一条ACLsave会把它们固化导致重启后行为改变。解决巡检前用display current-configuration查看完整配置确认没有临时调试配置再执行save。异常存储时使用save cfg-backup-YYYYMMDD.cfg不要直接覆盖默认启动配置。设备多台批量巡检时尤其要注意别在脚本里自动save——脚本操作没有人在现场确认配置状态。6. 巡检结果归档一张时间线表加一条救命习惯巡检做完结果不能只留在终端里。我现在的习惯是每台设备一个文件夹按日期命名里面放巡检输出txt、告警截图、配置备份。文件夹里额外放一张归档说明表记录巡检日期、设备IP、关键判读结论。日期设备CPU峰值内存峰值接收光衰最差日志告警结论2025-06-11核心-S7006X35%42%-13.5dBm无正常2025-06-04核心-S7006X42%45%-15.2dBm接口抖动1次观察这张时间线表是判断设备“是否在恶化”的核心依据。单次巡检只能反映当下状态多次巡检拉出趋势才能发现光衰在逐周下降、内存缓慢增长这类问题。没有归档巡检就只是重复劳动。还有一个习惯值得分享每次巡检前先执行display clock和display version这两条命令的输出是后续所有判读的时间锚点和版本锚点。版本变了要知会变更流程时间不对要先校准再谈日志分析。这个习惯帮我发现过两次设备在夜间自动重启的隐患重启日志在logbuffer里被覆盖了但版本运行时间出卖了它。日志集中化也是值得做的延伸网管平台上用syslog-ng搭建一个日志服务把交换机日志实时收到服务器上巡检时就多了一个历史日志回溯的渠道。设备本地日志缓冲区再大也会被覆盖集中化日志才是长期可追溯的方案。巡检这件事本身不产生价值产生价值的是持续的对比和及时的行动。希望对你有帮助。本文还有配套的精品资源点击获取