简介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、CH340Windows 10以上的系统偶发把驱动识别成“其他设备”重新装一下对应芯片的驱动就好。第二确认选的COM口号和实际一致多插拔几次COM号会变。第三数据位、停止位、校验位别乱调默认值就是H3C的出厂值。终端工具推荐SecureCRT或MobaXterm自带串口会话类型不需要额外配置。参数取值说明波特率9600H3C出厂默认数据位8保持默认停止位1保持默认流控None开了流控反而可能挂起新设备首次通过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 Admin123 [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-sha1Host 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 0idle-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 environmentdisplay 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 briefH3C 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输出里的关键参数按这个表理解参数含义关注点Temp模块温度超过60度持续运行容易加速老化70度以上必查Voltage模块供电电压正常范围在3.13~3.46V之间越界超过5%即告警Bias Current激光器偏置电流同型号模块偏置电流通常在一个大致区间明显偏离说明发射部分劣化TX Power发射光功率单位dBm在模块规格范围内即正常RX Power接收光功率低于灵敏度阈值会出现误码越低越危险对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|FLAPPINGlogbuffer里反复出现端口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: Admin123}, {host: 192.168.10.2, user: admin, password: Admin123}, ] 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_okTrue) cli paramiko.SSHClient() cli.set_missing_host_key_policy(paramiko.AutoAddPolicy()) cli.connect(dev[host], port22, usernamedev[user], passworddev[password], timeout10) 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(), fromfilebaseline, tofilelatest, 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整整拖了一个月。后来在基线对比阶段快速定位到那个端口换模块后问题消失。设备是个黑匣子不持续记录就没有“后悔药”而基线对比就是那味药。希望帮到你。本文还有配套的精品资源点击获取