简介一份面向网络运维人员的H3C交换机日常巡检命令整理文档聚焦设备状态监控与隐患排查适合网络管理员与H3C设备维护人员参考。文档以H3C S5500系列为示例系统梳理8条高频巡检指令包括查看CPU使用率display cpu-usage、内存占用display memory、设备温度display environment、设备汇总信息display device verbose、风扇状态display fan、电源状态display power、系统时间display clock以及接口简要信息display interface brief。每条命令均提供实际输出示例并解释关键字段如CPU 5秒/1分钟/5分钟平均使用率、内存总容量与已用量、入风口与热点温度、设备型号与运行时间、风扇及电源Normal/Fault状态、接口Link/Protocol状态等方便管理员快速判断设备健康度并定位故障。整个资源为1个doc文件压缩包仅21KB内容精炼实用适合作为日常巡检速查手册。目前已有588人学习下载适合需要快速掌握H3C交换机巡检要领的网络工程师。1. H3C交换机巡检命令不是背命令是建立一条能救命的检查链H3C交换机巡检命令说白了就是十来个display命令但真正把巡检当回事的人都明白命令敲一遍十分钟把设备状态看明白才是一整天的事。这张命令清单不是给新手背的是给那些网络出过事的人用的——交换机动不动跑一两年不重启风扇堵灰、电源掉压、单核CPU打满这些都不会主动上报到网管只有巡检时看到了才能救回来。我见过太多“巡检做了但没发现问题”的翻车现场原因从来不是命令没敲而是没按顺序敲、没把输出留下来、没和上次的记录做对比。2. 巡检顺序怎么定按「硬件—系统—接口—日志」四层过先看命再看病2.1 硬件层风扇、电源、温度这三样先查再谈性能H3C的网络操作系统从Comware V5到V7巡检命令变化不大硬件层我一般固定敲这一组display device display environment display fan display powerdisplay device看的是单板、电源模块的在线状态和状态字段。输出里每一行都有Slot、Status、Type信息Slot 0是主控板Status必须是Normal。如果看到Fault或者Absent基本可以判定硬件故障这种属于必须当天处理的级别。display environment一条命令能把温度、风扇转速都拉出来。H3C交换机在V7版本里温度告警阈值一般是高温告警在65℃左右但真正需要关注的不是绝对值而是趋势。我巡检时习惯把历史温度记录翻出来比比如上次38℃、这次52℃哪怕没到告警阈值十几度的涨幅也说明散热通道在恶化。常见原因是设备间积灰、风扇转速下降或者机柜气流被堵这类问题靠一次display环境看不出来必须留记录。display fan和display power在盒式设备上基本上就是确认Present和Normal。这里有一个容易被忽略的细节部分风扇模块是支持调速的输出里能看到转速档位如果长时间跑在高档位说明设备自己在被动散热环境温度可能已经偏高。电源模块则要关注是否处于冗余状态如果两个电源里有一个Failed但设备还在运行巡检时必须马上安排更换因为当前是单电源撑着再坏一个就整机断电。2.2 系统层与NTP版本、时间、堆叠状态时间不对全盘皆错系统层看四条命令就够display version、display clock、display irf、display ntp-status。但恰恰是最便宜的一条命令埋了很多坑。display version要看的其实不是版本号本身而是设备的运行时间。输出末尾有“H3C Comware Software, Version 7.1.064”和系统启动时间uptime只有几天说明设备最近重启过。注意重点是异常重启还是人为重启这个需要对照日志确认。常见认知是交换机uptime都很长如果某台设备的uptime只有三天那大概率发生过掉电或死机这种设备在跑核心业务时要高度警惕必要时安排窗口期重启一次。display clock看的是设备本地时间。这里有一个绝大多数人都会踩的坑H3C交换机的本地时间如果不做NTP同步跑几个月就会慢几分钟甚至十几分钟。时间不准的直接后果是日志时间戳错乱排障时把事件顺序完全颠倒。很多盒式设备比如H3C S1850系列默认通过DHCP获取地址时可以从Option 4拿到NTP服务器地址或者通过在Web界面配置NTP。命令行下可以这样检查display ntp-status输出里看Clock source是NTP还是LOCAL。如果是LOCAL说明设备在用本地时钟这个必须处理。命令行配置NTP的常见做法是ntp-service unicast-server 192.168.10.1设备侧配置完NTP后还有一个细节display ntp-status里看到的Clock offset要小于100ms才算正常否则即使同步了时间线也还是对不齐。2.3 接口与链路层聚合口、物理口、光模块状态对不上就是事故前兆接口层是巡检里信息量最大的一块但大多数人只敲一条display interface brief就完事了。这条命令看的是所有接口的物理状态和链路协议状态第三列Physical和第四列Link的状态组合是关键Physical down, Link down物理不通查光模块、网线、对端设备Physical up, Link down物理层通了但协议起不来查配置、VLAN、链路协商实际环境里最容易出问题的不是普通物理口而是聚合口。H3C的聚合命令在V7里叫display link-aggregation summary在V5里叫display link-aggregation verbose。巡检时要核对聚合组里的成员口是不是和设计一致。很多事故是这样的聚合口两端都正常但成员口全Down了流量实际上在走透传或者已经断掉只看聚合接口状态根本发现不了。光模块是另一个巡检盲区。display transceiver interface Ten-GigabitEthernet 1/0/1能看光模块的收发光功率一般模块接收功率在-20dBm以上、发送功率在-3到-8dBm之间算正常。但更关键的是看趋势接收功率从-15dBm掉到-19dBm虽然还在阈值内但光链路在劣化。巡检时把重要链路的光功率记录下来做对比比看任何告警都管用。有些老模块还会出现温度偏高的问题display transceiver diagnosis可以看模块内部温度超过70℃就要警惕了。2.4 日志层display logbuffer 不看等于白巡日志是最后一道关卡也是最容易被忽略的。display logbuffer默认显示的是最新的一部分日志很多人敲完看到没有ERROR就跳过了。实际上要看的是三类东西接口反复Up/Down、CPU冲击记录、协议状态机异常。接口反复Up/Down在日志里的表现是大量“Ten-GigabitEthernet1/0/5 link state change to DOWN”和“UP”交替出现这种问题在日志里刷屏但网管软件往往显示为“当前正常”因为它只看最后状态。巡检时遇到这类日志要顺着光纤去找原因大概率是对端设备重启或光模块不稳定。CPU冲击记录要看的是“Task ran too long”或“CPU usage is high”这一类信息。Comware V7会在CPU持续超过80%时周期性输出日志日志里会带出具体的任务名。如果是“VIDL”任务占用高一般是硬件转发异常如果是某些协议任务占用高比如BFD、OSPF通常是网络内有震荡。这些信息在网管软件里不一定有但日志里看得清清楚楚。3. 落一条可复现的巡检命令链从登录方式到批量抓取按这套流程走3.1 登录准备Console线连接参数和会话初始化三条命令做巡检第一件事不是敲display而是把登录环境准备好。H3C交换机的Console口线序是固定的RJ45口的第3脚是TX、第6脚是RX用标准Console线连接时不需要管交叉不交叉设备端会自动翻转。串口参数固定为9600波特率、8位数据位、1位停止位、无校验、无流控。CRT或Xshell里新建串口会话时按这个填填错最典型的症状是屏幕出现乱码不是连不上。登录成功后先敲三条命令这也是很多老工程师的习惯screen-length disable temporary undo terminal monitorscreen-length disable temporary是关掉分页显示。默认情况下设备输出超过一屏会停下来等交互巡检时这种交互会打断脚本自动抓取。加上temporary参数只对当前会话有效不写入配置不影响其他登录用户。undo terminal monitor是关闭日志输出到当前终端否则巡检过程中设备产生的实时日志会混进命令输出里机器抓取时容易被干扰。有一个小细节如果通过SSH登录而非Console关掉分页之后建议顺手做一次display clock确认设备时间因为SSH登录的设备如果没有NTP时间偏差可能很大后续所有日志排查都建立在错误的时间线上。3.2 核心巡检命令串十一个命令按顺序执行每个输出都有明确目的下面这一段是我在实际环境里固定使用的巡检命令串适用于Comware V5和V7盒式和框式都通用screen-length disable temporary display device display environment display version display clock display irf display interface brief display link-aggregation summary display cpu display memory display logbuffer reverse save force逐条说明执行后看什么display device所有单板Status为Normal如果有Fault直接进入故障流程。display environment温度和风扇状态。框式设备能看到每个槽位的温度重点看与上次巡检对比的差值温差超过10℃就要查散热。display version确认运行时间。uptime超过300天属于正常少于30天要回头查日志看重启原因。display clock确认当前时间。和你的电脑时间或NTP服务器时间相差超过1分钟记为待整改项。display irf只有堆叠设备需要执行。看IRF的Role是Master还是Standby再看Member数量是否和实际设备数一致。堆叠分裂是重大事故巡检时看到Master和Standby不在同一个框里就要立刻处理。display interface brief扫一眼所有接口状态正常情况管理口Up、业务口按设计状态存在其余接口基本是DOWN状态。display link-aggregation summary核对聚合组状态。Selected成员数量必须大于1如果看到只有1个Selected或者0个Selected聚合组已经是单链路承载或完全故障了。display cpuV5设备看CPU占用率V7设备看各核占用率。单核100%时总占用率可能只有20%这种也要标记为异常。display memory看内存使用率。盒式设备内存占用超过70%要留意超过85%基本可以认定存在内存泄漏需要计划重启或升级版本。display logbuffer reverse用reverse参数让最新的日志显示在最前面。重点看First Time和Last Time之间有没有严重级别以上日志以及有没有接口翻动记录。save force这条不是查看命令是保存配置。很多工程师巡检查完不保存结果下次设备重启回滚到两个月前的配置所有巡检期间的临时改动全没了。save force会将当前配置写入下次启动配置文件这个动作要有意识地养成习惯。3.3 三条高危命令单独说CPU、内存、日志缓冲区的输出怎么读display cpu在V7版本里的输出会细分为Total CPU使用率、每个核的使用率和任务级占用列表。读的时候先看总占用率是否超过70%再看有没有单核跑满——V7设备上单核跑满但整体不高的情况很常见通常是某个协议任务如OSPF的IPC任务出现异常循环导致。接着看任务列表里占用率最高的几个任务名正常的最高任务一般是“VIDL”空闲任务如果“VIDL”排不进前三说明系统负载异常。display memory要看两行Memory Used和Memory Free。注意Comware V5显示的是“System Total Memory Bytes”和“Total Memory Used Low/LowWater”这类字符串V7里变成百分比显示。读的时候关键是看Used比例的变化趋势因为我见过内存使用率缓慢爬升直到85%后整机重启的案例。如果两次巡检之间内存使用率涨了超过10%要当作内存异常增长处理不能等它涨到告警阈值。display logbuffer有一个容易混淆的参数问题设备默认只输出最近的一部分日志缓冲区本身有容量上限默认256条级别以上日志。想完整导出得用display logbuffer reverse或者加| include做过滤。最实用的做法是抓全部日志存到本地后再用文本工具做二次筛选。因为巡检当时人眼扫一遍只能看到最后一屏历史日志里往往藏着重要线索比如一周前某接口抖动了五次而网管系统没有告警。4. 常见问题与避坑五个真实翻车场景每个都有后悔药4.1 display logbuffer刷屏会话卡到敲命令没反应现象执行display logbuffer后终端输出持续滚动命令完全无法中断等了几分钟还在刷。原因设备日志缓冲区里积累了数千条日志其中大部分是接口翻动或合规审计类的低级别日志。默认分页被关闭后所有内容一次性输出串口带宽只有9600bps刷完整个缓冲区需要很长时间。解决登录后不要直接执行display logbuffer先执行display logbuffer summary看日志总量。如果条数超过500条先过滤再抓取比如用display logbuffer | include link state只抓接口状态变化记录或者指定时间范围display logbuffer log-buffer size 200。抓取前也可以通过info-center loghost把日志转发到日志服务器减轻设备侧缓冲区压力。4.2 聚合口状态明明是Up流量却断断续续现象某业务网段的流量时通时不通查看display link-aggregation summary看到聚合口状态是Up但实际转发异常。原因聚合组成员口状态和聚合口状态不一致。成员口中部分接口物理Down或协商失败但聚合组仍处于Loaded状态流量被哈希到失效的成员口上导致部分会话丢包。解决巡检时不仅要看聚合口还要逐成员核对。常见做法是执行display link-aggregation member-port display interface Ten-GigabitEthernet 1/0/1逐一确认成员口的Last 300 seconds input/output速率如果某个成员口速率接近0而其他口有流量说明哈希不均匀或成员口异常。另外V7里可以执行display link-aggregation load-sharing查看是否启用了增强负载均衡默认按报文五元组取模哈希如果流数量较少很容易出现流量集中在单成员口的情况这种不算故障但需要调整负载均衡模式。4.3 堆叠设备只看了主框备框的告警全瞎现象IRF堆叠环境里巡检时只在当前登录的框上敲了一遍display命令没有切到备框查看结果备框单板Fault一直没有被发现。原因IRF堆叠后通过任意一个成员框登录命令默认只作用于当前框。很多命令不带slot参数时只显示当前框的信息特别是display device不同版本行为不一致有的显示全量有的只显示本框。解决巡检IRF堆叠时养成带irf参数的暴力习惯display irf display device irf display environment irfdisplay device irf会列出所有成员框的单板状态。如果只想看某个成员框用display device slot 1或display device slot 2分别查看。另外要注意文本框和备框的版本一致性display version的输出里如果看到两个成员框的软件版本不同要立刻安排升级否则堆叠系统在角色切换时会出现兼容性问题。4.4 save force把上线配置覆盖了回滚不了现象巡检时执行了save force第二天发现设备重启后配置变成了旧版本某些业务VLAN的接口配置缺失业务中断。原因save force保存的是当前运行配置到下次启动配置。如果巡检前有人调试过配置但没有确认正确性运行配置里可能残留错误或中间态配置此时保存就把坏配置写死了。更常见的是巡检人员登录后什么都不改直接save但之前另一位工程师已经改了运行配置且还没保存save操作把半成品配置固化。解决save 前先执行一次display current-configuration | include vlan和display startup确认下次启动配置文件的修改时间与当前配置一致。最稳妥的做法是保存前先备份现有启动配置copy startup.cfg backup_20240601.cfg然后才执行save force。这样即使保存出错还能用startup saved-configuration backup_20240601.cfg回滚。巡检命令串联里save force必须排在所有检查命令之后并且保存前确认无人正在设备上调试这是血的教训。4.5 设备时间没同步日志对不上网管时间线现象网络出故障后回溯日志设备日志时间比网管系统时间慢了一个多小时事件顺序错乱无法定位真正的故障起点。原因设备没有正确配置NTP或者NTP服务指向的服务器不可达。很多H3C盒式设备比如S1850默认开启DHCP时自动从Option 4获取NTP服务器但如果使用静态IPNTP服务就是空的设备时间靠手动设置跑几天就会漂移。解决巡检时把display ntp-status作为必查项看到Clock source为LOCAL就是问题。命令行配置NTP的完整做法ntp-service unicast-server 192.168.10.1 ntp-service enable配置完成后等待几分钟再执行display ntp-status确认Clock source变成NTP、Clock offset降到100ms以下。如果NTP服务器不可达至少也要保证每月手动校准一次否则时间漂移到小时级后日志排查完全失效。这个问题在巡检命令里特别容易被忽略但它是最便宜、收益最高的一个动作。4.6 光模块功率是负的但链路正常三个月的趋势线才见分晓现象某条链路偶尔出现丢包每次持续几分钟后自动恢复。检查光模块接收功率在-20dBm边缘但接口状态一直是Up设备没有告警。原因光模块接收功率处于灵敏度和饱和点之间的边缘区域。多数光模块的告警阈值设得很宽从-30dBm到-3dBm都不告警但实际链路质量已经在劣化偶发误码导致丢包。解决巡检时对重要链路执行display transceiver interface记录收发光功率。我的做法是把功率数据写进巡检表每次巡检后对比上一次的值如果接收功率下降超过3dB就列入观察名单再降3dB就该换模块或清洗光纤接头。这种方法比等设备告警可靠得多因为光模块故障从来不是突变的都是慢慢劣化而网管软件不会给你画功率趋势线。5. 进阶一点把巡检命令固化成脚本跑完自动留痕对比基线巡检不能永远靠人肉敲命令。到了这一步我的做法是把整套命令写进Python脚本借助paramiko库批量SSH登录设备执行并抓取输出然后存储为带日期的文本文件再和上次的基线做diff。一个最小可用的脚本长这样import paramiko import datetime # 定义设备清单按实际环境修改IP、账号、密码 devices [ {host: 192.168.10.1, username: admin, password: passwd}, {host: 192.168.10.2, username: admin, password: passwd}, ] # 巡检命令串每条命令之间留一点间隔等待输出 commands [ screen-length disable temporary, display device, display environment, display clock, display interface brief, display cpu, display memory, display logbuffer reverse, ] 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) # 通过invoke_shell进入交互式shell逐条执行命令 shell ssh.invoke_shell() output for cmd in commands: shell.send(cmd \n) time.sleep(2) # 等待设备输出可根据设备性能调整 # 读取全部回显 while shell.recv_ready(): output shell.recv(65535).decode(utf-8, errorsignore) # 保存为带日期的文件文件名格式IP_YYYYMMDD.txt date_str datetime.datetime.now().strftime(%Y%m%d) filename f{dev[host]}_{date_str}.txt with open(filename, w, encodingutf-8) as f: f.write(output) ssh.close()这个脚本里的每个参数都值得说明shell.send每次发一个命令加换行符发送后sleep 2秒是因为H3C设备执行display命令需要时间sleep太短会导致输出和下一屏内容拼接在一起抓到的文本就对不上号了。shell.recv_ready()循环读取回显是一次性把缓冲区内容取空避免部分输出残留到下一个设备。脚本跑完后的关键动作是留痕和对比。我习惯把巡检文本按设备分目录存放然后每周用diff工具和上周的记录比一遍。重点看的是设备重启时间变化、CPU使用率波动、日志缓冲区里有没有新的严重告警。有条件的团队还可以再进一步把巡检脚本挂到计划任务里每周固定时间跑一次输出文件自动归档到共享盘。设备超过十条以后人肉巡检本质上已经不可靠了定期巡检的收益并不在于每条命令的执行而在于那根横跨两周时间、爬升了10℃的温度曲线或者一条悄悄从-15dBm掉到-19dBm的光路功率。我自己现在的习惯是每次巡检完顺手用display save存一份配置快照哪怕不改任何配置也存。三个月后设备出了问题拿着当时的配置文件和日志对着查比现场翻设备省力十倍。希望这份命令清单和脚本思路帮到你少踩几个我当年踩过的坑。本文还有配套的精品资源点击获取 H3C交换机巡检命令实战：从硬件、日志到脚本化检查链
简介一份面向网络运维人员的H3C交换机日常巡检命令整理文档聚焦设备状态监控与隐患排查适合网络管理员与H3C设备维护人员参考。文档以H3C S5500系列为示例系统梳理8条高频巡检指令包括查看CPU使用率display cpu-usage、内存占用display memory、设备温度display environment、设备汇总信息display device verbose、风扇状态display fan、电源状态display power、系统时间display clock以及接口简要信息display interface brief。每条命令均提供实际输出示例并解释关键字段如CPU 5秒/1分钟/5分钟平均使用率、内存总容量与已用量、入风口与热点温度、设备型号与运行时间、风扇及电源Normal/Fault状态、接口Link/Protocol状态等方便管理员快速判断设备健康度并定位故障。整个资源为1个doc文件压缩包仅21KB内容精炼实用适合作为日常巡检速查手册。目前已有588人学习下载适合需要快速掌握H3C交换机巡检要领的网络工程师。1. H3C交换机巡检命令不是背命令是建立一条能救命的检查链H3C交换机巡检命令说白了就是十来个display命令但真正把巡检当回事的人都明白命令敲一遍十分钟把设备状态看明白才是一整天的事。这张命令清单不是给新手背的是给那些网络出过事的人用的——交换机动不动跑一两年不重启风扇堵灰、电源掉压、单核CPU打满这些都不会主动上报到网管只有巡检时看到了才能救回来。我见过太多“巡检做了但没发现问题”的翻车现场原因从来不是命令没敲而是没按顺序敲、没把输出留下来、没和上次的记录做对比。2. 巡检顺序怎么定按「硬件—系统—接口—日志」四层过先看命再看病2.1 硬件层风扇、电源、温度这三样先查再谈性能H3C的网络操作系统从Comware V5到V7巡检命令变化不大硬件层我一般固定敲这一组display device display environment display fan display powerdisplay device看的是单板、电源模块的在线状态和状态字段。输出里每一行都有Slot、Status、Type信息Slot 0是主控板Status必须是Normal。如果看到Fault或者Absent基本可以判定硬件故障这种属于必须当天处理的级别。display environment一条命令能把温度、风扇转速都拉出来。H3C交换机在V7版本里温度告警阈值一般是高温告警在65℃左右但真正需要关注的不是绝对值而是趋势。我巡检时习惯把历史温度记录翻出来比比如上次38℃、这次52℃哪怕没到告警阈值十几度的涨幅也说明散热通道在恶化。常见原因是设备间积灰、风扇转速下降或者机柜气流被堵这类问题靠一次display环境看不出来必须留记录。display fan和display power在盒式设备上基本上就是确认Present和Normal。这里有一个容易被忽略的细节部分风扇模块是支持调速的输出里能看到转速档位如果长时间跑在高档位说明设备自己在被动散热环境温度可能已经偏高。电源模块则要关注是否处于冗余状态如果两个电源里有一个Failed但设备还在运行巡检时必须马上安排更换因为当前是单电源撑着再坏一个就整机断电。2.2 系统层与NTP版本、时间、堆叠状态时间不对全盘皆错系统层看四条命令就够display version、display clock、display irf、display ntp-status。但恰恰是最便宜的一条命令埋了很多坑。display version要看的其实不是版本号本身而是设备的运行时间。输出末尾有“H3C Comware Software, Version 7.1.064”和系统启动时间uptime只有几天说明设备最近重启过。注意重点是异常重启还是人为重启这个需要对照日志确认。常见认知是交换机uptime都很长如果某台设备的uptime只有三天那大概率发生过掉电或死机这种设备在跑核心业务时要高度警惕必要时安排窗口期重启一次。display clock看的是设备本地时间。这里有一个绝大多数人都会踩的坑H3C交换机的本地时间如果不做NTP同步跑几个月就会慢几分钟甚至十几分钟。时间不准的直接后果是日志时间戳错乱排障时把事件顺序完全颠倒。很多盒式设备比如H3C S1850系列默认通过DHCP获取地址时可以从Option 4拿到NTP服务器地址或者通过在Web界面配置NTP。命令行下可以这样检查display ntp-status输出里看Clock source是NTP还是LOCAL。如果是LOCAL说明设备在用本地时钟这个必须处理。命令行配置NTP的常见做法是ntp-service unicast-server 192.168.10.1设备侧配置完NTP后还有一个细节display ntp-status里看到的Clock offset要小于100ms才算正常否则即使同步了时间线也还是对不齐。2.3 接口与链路层聚合口、物理口、光模块状态对不上就是事故前兆接口层是巡检里信息量最大的一块但大多数人只敲一条display interface brief就完事了。这条命令看的是所有接口的物理状态和链路协议状态第三列Physical和第四列Link的状态组合是关键Physical down, Link down物理不通查光模块、网线、对端设备Physical up, Link down物理层通了但协议起不来查配置、VLAN、链路协商实际环境里最容易出问题的不是普通物理口而是聚合口。H3C的聚合命令在V7里叫display link-aggregation summary在V5里叫display link-aggregation verbose。巡检时要核对聚合组里的成员口是不是和设计一致。很多事故是这样的聚合口两端都正常但成员口全Down了流量实际上在走透传或者已经断掉只看聚合接口状态根本发现不了。光模块是另一个巡检盲区。display transceiver interface Ten-GigabitEthernet 1/0/1能看光模块的收发光功率一般模块接收功率在-20dBm以上、发送功率在-3到-8dBm之间算正常。但更关键的是看趋势接收功率从-15dBm掉到-19dBm虽然还在阈值内但光链路在劣化。巡检时把重要链路的光功率记录下来做对比比看任何告警都管用。有些老模块还会出现温度偏高的问题display transceiver diagnosis可以看模块内部温度超过70℃就要警惕了。2.4 日志层display logbuffer 不看等于白巡日志是最后一道关卡也是最容易被忽略的。display logbuffer默认显示的是最新的一部分日志很多人敲完看到没有ERROR就跳过了。实际上要看的是三类东西接口反复Up/Down、CPU冲击记录、协议状态机异常。接口反复Up/Down在日志里的表现是大量“Ten-GigabitEthernet1/0/5 link state change to DOWN”和“UP”交替出现这种问题在日志里刷屏但网管软件往往显示为“当前正常”因为它只看最后状态。巡检时遇到这类日志要顺着光纤去找原因大概率是对端设备重启或光模块不稳定。CPU冲击记录要看的是“Task ran too long”或“CPU usage is high”这一类信息。Comware V7会在CPU持续超过80%时周期性输出日志日志里会带出具体的任务名。如果是“VIDL”任务占用高一般是硬件转发异常如果是某些协议任务占用高比如BFD、OSPF通常是网络内有震荡。这些信息在网管软件里不一定有但日志里看得清清楚楚。3. 落一条可复现的巡检命令链从登录方式到批量抓取按这套流程走3.1 登录准备Console线连接参数和会话初始化三条命令做巡检第一件事不是敲display而是把登录环境准备好。H3C交换机的Console口线序是固定的RJ45口的第3脚是TX、第6脚是RX用标准Console线连接时不需要管交叉不交叉设备端会自动翻转。串口参数固定为9600波特率、8位数据位、1位停止位、无校验、无流控。CRT或Xshell里新建串口会话时按这个填填错最典型的症状是屏幕出现乱码不是连不上。登录成功后先敲三条命令这也是很多老工程师的习惯screen-length disable temporary undo terminal monitorscreen-length disable temporary是关掉分页显示。默认情况下设备输出超过一屏会停下来等交互巡检时这种交互会打断脚本自动抓取。加上temporary参数只对当前会话有效不写入配置不影响其他登录用户。undo terminal monitor是关闭日志输出到当前终端否则巡检过程中设备产生的实时日志会混进命令输出里机器抓取时容易被干扰。有一个小细节如果通过SSH登录而非Console关掉分页之后建议顺手做一次display clock确认设备时间因为SSH登录的设备如果没有NTP时间偏差可能很大后续所有日志排查都建立在错误的时间线上。3.2 核心巡检命令串十一个命令按顺序执行每个输出都有明确目的下面这一段是我在实际环境里固定使用的巡检命令串适用于Comware V5和V7盒式和框式都通用screen-length disable temporary display device display environment display version display clock display irf display interface brief display link-aggregation summary display cpu display memory display logbuffer reverse save force逐条说明执行后看什么display device所有单板Status为Normal如果有Fault直接进入故障流程。display environment温度和风扇状态。框式设备能看到每个槽位的温度重点看与上次巡检对比的差值温差超过10℃就要查散热。display version确认运行时间。uptime超过300天属于正常少于30天要回头查日志看重启原因。display clock确认当前时间。和你的电脑时间或NTP服务器时间相差超过1分钟记为待整改项。display irf只有堆叠设备需要执行。看IRF的Role是Master还是Standby再看Member数量是否和实际设备数一致。堆叠分裂是重大事故巡检时看到Master和Standby不在同一个框里就要立刻处理。display interface brief扫一眼所有接口状态正常情况管理口Up、业务口按设计状态存在其余接口基本是DOWN状态。display link-aggregation summary核对聚合组状态。Selected成员数量必须大于1如果看到只有1个Selected或者0个Selected聚合组已经是单链路承载或完全故障了。display cpuV5设备看CPU占用率V7设备看各核占用率。单核100%时总占用率可能只有20%这种也要标记为异常。display memory看内存使用率。盒式设备内存占用超过70%要留意超过85%基本可以认定存在内存泄漏需要计划重启或升级版本。display logbuffer reverse用reverse参数让最新的日志显示在最前面。重点看First Time和Last Time之间有没有严重级别以上日志以及有没有接口翻动记录。save force这条不是查看命令是保存配置。很多工程师巡检查完不保存结果下次设备重启回滚到两个月前的配置所有巡检期间的临时改动全没了。save force会将当前配置写入下次启动配置文件这个动作要有意识地养成习惯。3.3 三条高危命令单独说CPU、内存、日志缓冲区的输出怎么读display cpu在V7版本里的输出会细分为Total CPU使用率、每个核的使用率和任务级占用列表。读的时候先看总占用率是否超过70%再看有没有单核跑满——V7设备上单核跑满但整体不高的情况很常见通常是某个协议任务如OSPF的IPC任务出现异常循环导致。接着看任务列表里占用率最高的几个任务名正常的最高任务一般是“VIDL”空闲任务如果“VIDL”排不进前三说明系统负载异常。display memory要看两行Memory Used和Memory Free。注意Comware V5显示的是“System Total Memory Bytes”和“Total Memory Used Low/LowWater”这类字符串V7里变成百分比显示。读的时候关键是看Used比例的变化趋势因为我见过内存使用率缓慢爬升直到85%后整机重启的案例。如果两次巡检之间内存使用率涨了超过10%要当作内存异常增长处理不能等它涨到告警阈值。display logbuffer有一个容易混淆的参数问题设备默认只输出最近的一部分日志缓冲区本身有容量上限默认256条级别以上日志。想完整导出得用display logbuffer reverse或者加| include做过滤。最实用的做法是抓全部日志存到本地后再用文本工具做二次筛选。因为巡检当时人眼扫一遍只能看到最后一屏历史日志里往往藏着重要线索比如一周前某接口抖动了五次而网管系统没有告警。4. 常见问题与避坑五个真实翻车场景每个都有后悔药4.1 display logbuffer刷屏会话卡到敲命令没反应现象执行display logbuffer后终端输出持续滚动命令完全无法中断等了几分钟还在刷。原因设备日志缓冲区里积累了数千条日志其中大部分是接口翻动或合规审计类的低级别日志。默认分页被关闭后所有内容一次性输出串口带宽只有9600bps刷完整个缓冲区需要很长时间。解决登录后不要直接执行display logbuffer先执行display logbuffer summary看日志总量。如果条数超过500条先过滤再抓取比如用display logbuffer | include link state只抓接口状态变化记录或者指定时间范围display logbuffer log-buffer size 200。抓取前也可以通过info-center loghost把日志转发到日志服务器减轻设备侧缓冲区压力。4.2 聚合口状态明明是Up流量却断断续续现象某业务网段的流量时通时不通查看display link-aggregation summary看到聚合口状态是Up但实际转发异常。原因聚合组成员口状态和聚合口状态不一致。成员口中部分接口物理Down或协商失败但聚合组仍处于Loaded状态流量被哈希到失效的成员口上导致部分会话丢包。解决巡检时不仅要看聚合口还要逐成员核对。常见做法是执行display link-aggregation member-port display interface Ten-GigabitEthernet 1/0/1逐一确认成员口的Last 300 seconds input/output速率如果某个成员口速率接近0而其他口有流量说明哈希不均匀或成员口异常。另外V7里可以执行display link-aggregation load-sharing查看是否启用了增强负载均衡默认按报文五元组取模哈希如果流数量较少很容易出现流量集中在单成员口的情况这种不算故障但需要调整负载均衡模式。4.3 堆叠设备只看了主框备框的告警全瞎现象IRF堆叠环境里巡检时只在当前登录的框上敲了一遍display命令没有切到备框查看结果备框单板Fault一直没有被发现。原因IRF堆叠后通过任意一个成员框登录命令默认只作用于当前框。很多命令不带slot参数时只显示当前框的信息特别是display device不同版本行为不一致有的显示全量有的只显示本框。解决巡检IRF堆叠时养成带irf参数的暴力习惯display irf display device irf display environment irfdisplay device irf会列出所有成员框的单板状态。如果只想看某个成员框用display device slot 1或display device slot 2分别查看。另外要注意文本框和备框的版本一致性display version的输出里如果看到两个成员框的软件版本不同要立刻安排升级否则堆叠系统在角色切换时会出现兼容性问题。4.4 save force把上线配置覆盖了回滚不了现象巡检时执行了save force第二天发现设备重启后配置变成了旧版本某些业务VLAN的接口配置缺失业务中断。原因save force保存的是当前运行配置到下次启动配置。如果巡检前有人调试过配置但没有确认正确性运行配置里可能残留错误或中间态配置此时保存就把坏配置写死了。更常见的是巡检人员登录后什么都不改直接save但之前另一位工程师已经改了运行配置且还没保存save操作把半成品配置固化。解决save 前先执行一次display current-configuration | include vlan和display startup确认下次启动配置文件的修改时间与当前配置一致。最稳妥的做法是保存前先备份现有启动配置copy startup.cfg backup_20240601.cfg然后才执行save force。这样即使保存出错还能用startup saved-configuration backup_20240601.cfg回滚。巡检命令串联里save force必须排在所有检查命令之后并且保存前确认无人正在设备上调试这是血的教训。4.5 设备时间没同步日志对不上网管时间线现象网络出故障后回溯日志设备日志时间比网管系统时间慢了一个多小时事件顺序错乱无法定位真正的故障起点。原因设备没有正确配置NTP或者NTP服务指向的服务器不可达。很多H3C盒式设备比如S1850默认开启DHCP时自动从Option 4获取NTP服务器但如果使用静态IPNTP服务就是空的设备时间靠手动设置跑几天就会漂移。解决巡检时把display ntp-status作为必查项看到Clock source为LOCAL就是问题。命令行配置NTP的完整做法ntp-service unicast-server 192.168.10.1 ntp-service enable配置完成后等待几分钟再执行display ntp-status确认Clock source变成NTP、Clock offset降到100ms以下。如果NTP服务器不可达至少也要保证每月手动校准一次否则时间漂移到小时级后日志排查完全失效。这个问题在巡检命令里特别容易被忽略但它是最便宜、收益最高的一个动作。4.6 光模块功率是负的但链路正常三个月的趋势线才见分晓现象某条链路偶尔出现丢包每次持续几分钟后自动恢复。检查光模块接收功率在-20dBm边缘但接口状态一直是Up设备没有告警。原因光模块接收功率处于灵敏度和饱和点之间的边缘区域。多数光模块的告警阈值设得很宽从-30dBm到-3dBm都不告警但实际链路质量已经在劣化偶发误码导致丢包。解决巡检时对重要链路执行display transceiver interface记录收发光功率。我的做法是把功率数据写进巡检表每次巡检后对比上一次的值如果接收功率下降超过3dB就列入观察名单再降3dB就该换模块或清洗光纤接头。这种方法比等设备告警可靠得多因为光模块故障从来不是突变的都是慢慢劣化而网管软件不会给你画功率趋势线。5. 进阶一点把巡检命令固化成脚本跑完自动留痕对比基线巡检不能永远靠人肉敲命令。到了这一步我的做法是把整套命令写进Python脚本借助paramiko库批量SSH登录设备执行并抓取输出然后存储为带日期的文本文件再和上次的基线做diff。一个最小可用的脚本长这样import paramiko import datetime # 定义设备清单按实际环境修改IP、账号、密码 devices [ {host: 192.168.10.1, username: admin, password: passwd}, {host: 192.168.10.2, username: admin, password: passwd}, ] # 巡检命令串每条命令之间留一点间隔等待输出 commands [ screen-length disable temporary, display device, display environment, display clock, display interface brief, display cpu, display memory, display logbuffer reverse, ] 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) # 通过invoke_shell进入交互式shell逐条执行命令 shell ssh.invoke_shell() output for cmd in commands: shell.send(cmd \n) time.sleep(2) # 等待设备输出可根据设备性能调整 # 读取全部回显 while shell.recv_ready(): output shell.recv(65535).decode(utf-8, errorsignore) # 保存为带日期的文件文件名格式IP_YYYYMMDD.txt date_str datetime.datetime.now().strftime(%Y%m%d) filename f{dev[host]}_{date_str}.txt with open(filename, w, encodingutf-8) as f: f.write(output) ssh.close()这个脚本里的每个参数都值得说明shell.send每次发一个命令加换行符发送后sleep 2秒是因为H3C设备执行display命令需要时间sleep太短会导致输出和下一屏内容拼接在一起抓到的文本就对不上号了。shell.recv_ready()循环读取回显是一次性把缓冲区内容取空避免部分输出残留到下一个设备。脚本跑完后的关键动作是留痕和对比。我习惯把巡检文本按设备分目录存放然后每周用diff工具和上周的记录比一遍。重点看的是设备重启时间变化、CPU使用率波动、日志缓冲区里有没有新的严重告警。有条件的团队还可以再进一步把巡检脚本挂到计划任务里每周固定时间跑一次输出文件自动归档到共享盘。设备超过十条以后人肉巡检本质上已经不可靠了定期巡检的收益并不在于每条命令的执行而在于那根横跨两周时间、爬升了10℃的温度曲线或者一条悄悄从-15dBm掉到-19dBm的光路功率。我自己现在的习惯是每次巡检完顺手用display save存一份配置快照哪怕不改任何配置也存。三个月后设备出了问题拿着当时的配置文件和日志对着查比现场翻设备省力十倍。希望这份命令清单和脚本思路帮到你少踩几个我当年踩过的坑。本文还有配套的精品资源点击获取