简介面向网络管理员与运维人员的华三交换机日常巡检速查文档聚焦设备运行状态的高频监控项。内容按巡检顺序整理中央处理器使用率、内存占用率、设备温度、设备汇总信息、风扇状态、电源状态、系统时间及接口详细信息共八类常用命令每条命令均给出输入示例与输出解读并提示高使用率、高温、风扇异常、电源故障等可能造成的性能影响方便日常维护与故障定位便于管理员对照真实设备输出判断运行状态快速发现隐患。资源为单个文档格式文件压缩包仅21KB轻量易存适合随身查阅或作为机房巡检操作清单。已有588人学习下载内容条理分明适合负责设备日常维护、故障排查及希望建立标准化巡检流程的读者参考。1. 巡检不是逛一圈H3C交换机每天到底该看什么很多运维手里都有一份H3C交换机巡检命令.doc但真正照着敲完、还能从输出里看出问题的少之又少。原因很简单命令谁都会复制但每条命令输出里的哪个字段代表“要出事了”才是这份文档里最值钱的部分。交换机不像服务器有图形界面也不像业务系统有日志平台它就是一个黑匣子大部分故障发生前其实是有预兆的——CPU利用率悄悄爬升、接口错包在涨、温度在逼近阈值只是没人去翻那些输出。这篇就是奔着解决这个问题去的把巡检从“敲命令打卡”变回“看数据找隐患”。适合刚接手公司网络的新人也适合被半夜告警折腾过、想建立一套固定巡检脚本的熟手。全文不聊理论只讲每周/每月该执行哪些命令、每个关键字段怎么看、哪些坑是必须避开的。2. 先核对身份登录设备后最先敲的5条基础命令巡检的第一步不是查接口而是确认“这台设备是不是你以为的那台”。很多网络事故的起点就是巡检时登错了设备或者设备被人改过配置而没人记录。我一般会在进入系统视图前先敲一组“身份核对”命令把设备的基本情况和当前状态钉死再往下查。system-view sysname CORP-CORE-01 quit display version display device display clock这段命令的逻辑很简单先进入系统视图把这台交换机的hostname设成明确的机房-角色-编号格式比如CORP-CORE-01就是“公司核心-核心交换机-01号”。然后退出系统视图用display version和display device分别看软件版本和硬件状态。display clock是确认设备时间这步很多人忽略但日志、告警、排障全靠时间戳对齐设备时间乱跳后面所有分析都是白做。参数上我通常关注display device输出的Status字段必须是Normal只要出现Fault哪怕板卡还在转发也要尽快联系厂家备件。display version里要记下软件版本号因为H3C的很多已知bug都跟特定版本绑定巡检时顺手记录版本后续排查“这个现象是不是已知问题”会快很多。display clock核对的是时区H3C设备默认是UTC国内机房要确认已经配了clock timezone Beijing add 08:00:00否则日志时间会比本地慢8小时。身份核对之后我还会顺手做一件“后悔药”性质的事备份当前配置。人脑记不住每一次变更但设备可以帮你记住。执行display current-configuration把输出重定向到本地文件这比啥都管用。实际操作中我是用SecureCRT或Xshell的日志功能每次登录自动记录全部输出半年后想查任何一次变更都有据可依。这步不做等出了故障想回滚配置才发现谁都不知道改了什么那才是真翻车。3. 硬件与系统状态温度、风扇、电源是巡检的第一道防线3.1 用display environment看设备“体温”三个字段决定要不要现场处置交换机是7x24小时通电的电子设备最容易先老化的就是电源模块和风扇。H3C的display environment命令把温度、风扇、电源三块信息一次性拉出来是我每次巡检必看的一页。很多人敲完这条命令只看一眼温度没超标就走这其实浪费了这条命令大半的价值。在输出里Temperature部分会列出设备当前温度、告警阈值和恢复阈值。核心逻辑是当前温度要低于Warning阈值如果进入了Warning甚至Alarm区间不是简单“注意散热”的问题而是要安排现场处理了。风扇部分看Status字段正常是Normal如果出现Absent或者Failed说明风扇已经不在位或者停转这种状态撑不过高温天气。电源部分同样看Status和Present字段双电源设备如果一路失效系统还能跑但已经没有冗余了属于“带病运行”。还有一种情况是温度曲线缓慢爬升比如从40度一点点涨到55度——单看某一次巡检可能没到告警线但连续几周的数据放在一起就能看出趋势。所以我会把每次巡检的温度、风扇转速记到表格里按月拉一条趋势线这样比只看单次数值靠谱得多。设备间空调故障、机柜风道被线缆堵住都是这么被发现的。3.2 日志是黑匣子display logbuffer怎么在几分钟内定位根因display logbuffer是H3C设备的内存日志缓冲区很多故障的前兆会在这里留下痕迹。巡检时不需要把几百条日志全看完那样效率太低我一般会用过滤参数直接抓关键内容。比如只看告警和错误级别或者看某个接口的历史记录这样能在几分钟内锁定近期有没有异常事件。display logbuffer buffer-size 512 display logbuffer level warnings display logbuffer | include UPDOWN第一行是把缓冲区大小临时调整为512条第二行是只看warnings及以上级别的日志第三行是过滤包含UPDOWN关键字的记录。UPDOWN日志代表接口状态在up和down之间切换这种日志如果短时间内反复出现基本可以断定物理链路有问题——可能是光模块光衰大、网线松动、对端设备重启。光靠人眼盯接口指示灯根本抓不到这种“闪断”。实际巡检中我发现一个规律很多“网络时不时卡一下”的故障业务侧感知是丢包网络侧看流量、CPU都正常最后都是靠logbuffer里大量UPDOWN记录破案的。所以我在巡检里给logbuffer留的时间比看流量还多因为流量只反映“现在”而日志反映“最近一段时间发生了什么”。3.3 CPU和内存不能只盯当前值要看峰值和趋势H3C的display cpu-usage能看到CPU利用率的当前值和历史峰值display memory看内存使用率。这两个指标是设备健康度的晴雨表每条命令都有几个字段需要重点核对。CPU部分我关注三个数当前值、最近5秒峰值、最近1分钟峰值。如果当前值不高但5秒峰值经常冲到80%以上说明设备在间歇性处理突发流量或某个协议在频繁计算这种状态下再叠加一个攻击或环路设备可能直接假死。内存部分看Used比率是否持续增长且不回落——如果每周巡检内存占用都涨几个百分点大概率是某个进程在泄漏比如ARP表项异常增长或者反复收发的协议报文。这里有个容易被忽略的点CPU和内存的采样是瞬时的单次巡检数值正常不代表设备健康。所以要结合display cpu-usage history看最近几小时的趋势这个命令会输出一个简单的字符画柱状图能直观看出CPU在哪些时段飙高。结合时间点去反推是什么业务引起的——比如每天上午9点准时飙高多半是上班后大量终端同时认证上线如果是凌晨飙高那就要怀疑有没有定时任务或攻击了。4. 接口与链路巡检流量、错包、光功率三个维度判断链路健康度4.1 用display interface brief速览全设备接口上下行方向都要看接口是整个网络里最忙的“工人”也是最容易出问题的地方。display interface brief会列出所有接口的物理状态、协议状态和收发流量。我看到太多人只盯着InUti和OutUti两个利用率数值其实这条命令里更该关注的是状态列——任何接口只要不是UP就得问一句为什么。display interface brief display interface GigabitEthernet1/0/1第一行是全设备接口概览第二行是看某个具体接口的详细计数。概览负责“发现异常”详细命令负责“定位原因”。比如看到GigabitEthernet1/0/1的物理状态是DOWN就直接用display interface GigabitEthernet1/0/1看详细信息里面会有DOWN的原因描述常见的有DOWN (Administratively down)被管理员手动关闭、DOWN (Not connected)物理链路不通、DOWN (Auto-negotiation failure)协商失败。不同原因对应不同的处理路径手动关闭的可能是备用的链路不通的就得查线和光模块了。流量利用率方面H3C的display interface brief显示的InUti和OutUti是瞬时值这个数值在千兆口上通常很低但别被它骗了——瞬时值看不出突发。真正要拉长时间看的是接口的累计字节数和累计错包数这两个字段是“体检报告”里的长期指标。4.2 错包增长是物理链路劣化的信号Input Errors不是小事接口详细输出里有Input和Output两个方向的错误计数这是判断物理链路质量的核心依据。很多巡检只看流量高不高、端口UP不UP把错误计数忽略了。我的习惯是每次巡检记录关键上联接口的错包数这次和上次对比如果持续增长或突然暴涨链路多半在劣化。错误计数里的几个字段含义不同CRC错误增多基本可以断定是物理层问题常见原因包括光模块光衰过大、光纤弯曲半径太小、网线质量差或水晶头接触不良Runts和Giants增多可能是两端接口MTU不一致或对端设备故障Input Errors总数如果秒级增长优先怀疑光模块用display transceiver interface看光功率是最直接的验证手段。这里有一个我在实际项目中踩过的坑某天核心交换机上联口CRC错误一直在涨但业务没有任何感知。查了一圈光模块光功率正常、光纤也换过最后发现是光纤跳线走线时和强电线缆绑在一起虽然没直接烧坏设备但电磁干扰导致信号质量下降。把跳线重新分开走线后CRC错误就停止了。所以错包问题不要只盯着线缆本身走线环境也很重要。4.3 光模块巡检光功率在正常范围不代表是好的要看余量光模块是交换机链路的“最后一厘米”也是最容易出莫名其妙问题的部件。display transceiver interface GigabitEthernet1/0/1能看到模块的收发光功率和温度输出里有几个关键字段模块温度、发送光功率、接收光功率、电压。这些数值都有各自的告警上下限在正常范围只能说明模块“活着”真正要评估健康度的是余量——当前值离告警线有多远。display transceiver interface GigabitEthernet1/0/1 display transceiver diagnosis interface GigabitEthernet1/0/1多模模块的接收光功率在-7dBm到-15dBm之间算正常但如果当前值是-14.5dBm离-15dBm的告警线只剩0.5dB这就是“带病运行”了。这时候即使暂时没告警也应该安排备用光模块到现场一旦劣化加剧可以马上更换。发送光功率偏低则说明模块本身的激光器在老化这种情况通常是模块寿命快到了提前更换比等它失效再换更稳妥。光模块温度也是一个被忽视的指标。很多SFP模块的工作温度上限是70度或85度如果在机柜里被其他设备的热风直吹模块温度会持续高压运行寿命大幅缩短。我曾经遇到过一台设备在夏天连续坏三个光模块排查后发现是上联设备的风道布局导致热风全吹在光模块上调整走线后问题才解决。所以光模块巡检不光是看数值还要结合设备的物理安装环境一起看。5. 核心协议与配置一致性堆叠、VLAN、路由巡检一半的时间应该花在这里5.1 堆叠状态检查两台设备做到“主备”才算真正冗余很多机房的核心层都做了堆叠H3C的IRF技术把两台设备虚拟成一台管理和转发上都简化了很多。但堆叠一旦出问题故障半径比单台设备宕机还大。巡检堆叠时我重点关注两个层面一是堆叠是否仍然完整二是主备设备的转发状态是否正常。display irf命令能看到堆叠的成员数量和角色。关键字段是Role——一台是Master另一台是Standby如果出现两个Master或者两个Standby说明堆叠脑裂了两台设备都在独立转发数据整个网络的ARP表、MAC表会乱成一锅粥。display irf topology则能看到堆叠链路的拓扑结构确认堆叠口之间的连接是否和预期一致。堆叠口本身的状态也是巡检重点用display irf-link能看到堆叠链路的工作状态和收发的Hello报文计数。堆叠链路如果出现丢包或错包哪怕不严重也预示着两台设备之间的同步可能延迟一旦主设备故障备用设备接管时可能因为配置或状态不同步而无法正常转发。这个风险比单台设备宕机还难排查因为平时业务正常只有真正切换时才暴雷。5.2 VLAN与接口归属一致性配置漂移是网络隐含故障的第一来源配置漂移是指设备的实际配置和基线配置不一致——有人手动改过、脚本改错、或者导入配置时出了问题。VLAN配置尤其容易出这种问题表现出来就是“某些用户突然不通了”或者“时通时断”。巡检时我会用display vlan和display interface交叉核对两个东西VLAN是否存在、接口是否在正确的VLAN里。display vlan display interface Ethernet1/0/1 display mac-address vlan 10第一条命令列出所有VLAN和对应的接口第二条看某个接口的PVID和允许通过的VLAN列表第三条看VLAN 10里已经学习到的MAC地址。这三条命令合起来能快速发现三类典型问题接口的PVID被误改、接口被意外加入了某个VLAN、某个VLAN里出现了预期之外的MAC地址。被误改的接口归属通常发生在有人“临时调试”之后忘记恢复。我见过一次故障某个监控系统的摄像头全部离线查到最后是前一天有人把一个端口从VLAN 20改成了VLAN 30给临时设备用结束后没改回来导致整个监控网段的终端全部失联。所以巡检不只是“看状态”还要有基线对照。我的习惯是把所有接口的VLAN归属保存成文件每次巡检用diff工具和基线对比有差异就查原因这样配置漂移基本当天就能发现。5.3 路由表与ARP表规模异常比个别条目错误更值得警惕路由表和ARP表是交换机转发决策的依据它们一旦异常影响的是整台设备的转发性能而不只是某条链路。巡检时display ip routing-table和display arp最值得关注的不是有没有具体某条路由而是整体条目数量是否符合预期。路由表条目数如果突然暴涨比如从几百条涨到几万条大概率是收到了路由攻击或某台设备配置了错误的路由通告。CPU会因为处理大量路由更新而飙高设备转发性能断崖式下降。ARP表异常更常见——ARP表项数量持续增长且不老化可能是某个网段内有设备在大量扫描或者有终端中了病毒在发ARP广播包。这时候用display arp | count看总条目数和上一周的数据对比涨幅超过20%就要开始查根源了。这里还要注意转发表项的“学习”速度。正常网络里新的MAC或ARP条目会不断学习、老化、再学习处于动态平衡。如果某些条目一直不老化可能是因为该IP或MAC一直有通信也可能是表项被静态绑定了。静态绑定本身是安全的但数量太多会占满表项空间导致新的终端无法学习。所以巡检时看表项总数、对比历史基线比逐条核对具体条目更高效。6. 避坑指南H3C交换机巡检中的常见误判与陷阱巡检命令本身不难难的是对输出的解读。我见过太多人因为误判巡检数据把正常设备当故障处理或者把隐患当正常现象放过去。这一章把我在实际运维中遇到的高频坑整理出来按“现象→原因→解决”的格式写清楚照着排错能少走很多弯路。坑一display interface brief里的利用率是瞬时值不能代表真实负载现象巡检时看到某个接口的InUti只有2%认为链路很空闲放松了警惕。但业务的真实情况是每天早晚高峰期这个接口的利用率能飙到80%以上只是因为巡检时间不在高峰期所以没看到。 原因display interface brief展示的是当前时刻的采样值存在极大的偶然性。设备不是每时每刻都在做全量统计瞬时值无法反映流量特征。 解决用display counter rate interface查看接口最近一段时间的流量速率统计或者用display interface的详细输出里累计字节数做差值计算。最靠谱的方式是在巡检脚本里记录每次的累计值下次巡检算出增量再除以间隔时间得到平均速率。结合定期抓取和趋势记录比单次瞬时值可靠得多。坑二接口CRC错误数一直存在但增长缓慢被认为不用管直到业务出现丢包才处理现象某接口CRC错误计数从设备上线就一直在涨但增长非常慢每次巡检对比涨了几百个认为在可接受范围内。直到某天业务侧反馈丢包严重再看错误计数已经涨了几十万。 原因CRC错误是物理层信号质量问题的直接体现哪怕增长缓慢也说明链路上一直存在干扰或光模块老化。等到错误大幅增长时链路质量已经严重劣化。 解决CRC错误数的“绝对大小”不重要“是否持续增长”才是关键。巡检时记录每次的错误计数如果连续两次都在增长就安排光功率测试和线路检查。另外注意光功率正常不代表CRC不会再涨因为干扰源可能来自电磁环境而非模块本身。坑三display logbuffer里看不到告警日志就认为设备近期没有异常现象巡检时打开logbuffer发现最近几百条都是正常的接口UP/DOWN信息或用户登录记录于是判定设备运行平稳。 原因logbuffer默认容量有限H3C设备一般只能存几百条到一千条日志如果设备近期有大量重复日志比如被扫描攻击触发的日志风暴重要的告警会被挤掉。 解决不要只看logbuffer的末尾用display logbuffer level warnings强制过滤出高等级日志再结合display logbuffer reverse从最新一条往前翻。如果怀疑日志风暴淹没了重要信息用display logbuffer | include %Apr这种带模块关键字的方式精确过滤特定类型的日志。还有个习惯是配置日志主机把日志实时发到独立的日志服务器这样即使设备本地日志被冲掉服务器上还有完整记录。坑四堆叠的主备状态正常但忽略堆叠链路质量切换时才发现问题现象display irf显示一台Master一台Standby角色正常于是认为堆叠没问题。直到某次主设备需要重启备用设备迟迟无法接管转发业务中断数分钟。 原因堆叠链路本身可能已经存在质量劣化比如丢包或延迟但设备没有达到触发堆叠分裂的阈值所以状态显示正常。主设备正常时状态同步的轻微延迟感知不到一旦主设备失效备用设备拿到的状态表不完整转发就会出问题。 解决每次巡检专门看display irf-link的收发统计关注是否有错包或丢包记录。堆叠链路的质量标准应该比普通业务链路更严格出现任何错误计数都要立即处理。堆叠口之间的线缆建议使用短距高速线缆不要用普通网线长距离连接距离越长受干扰的概率越大。坑五修改配置后忘记保存设备重启后配置回滚导致VLAN和接口配置漂移现象某天为了调试临时改了接口的VLAN归属业务恢复正常后没在意。第二天设备因为机房断电重启配置恢复成旧版本刚恢复的业务再次中断而且和上次故障现象完全一样。 原因H3C设备修改配置后运行配置和启动配置是分离的。save命令之前的所有修改重启后都会丢失。很多人改完配置不做save特别是临时调试时的改动最容易忘。 解决巡检时用display current-configuration和display saved-configuration做对比用diff命令直接查看差异。发现有不一致的配置先确认是否是近期有意变更如果是且需要保留就执行save如果确认是误操作产生的残留就及时清理。我个人的习惯是任何变更无论临时还是正式完成并验证后立刻执行save force把“后悔药”提前吃掉。坑六光功率在正常范围内就认为光模块是健康的忽略了余量不足的问题现象光模块接收光功率-13dBm告警阈值是-15dBm数值在正常范围巡检结论是“正常”。一周后该模块开始出现CRC错误并影响业务更换后恢复。 原因光模块的光功率在缓慢劣化当前值虽然还在正常范围但离告警线已经很近。光模块的老化不是线性的越接近寿命终点劣化越快等到跌破阈值再处理就已经影响业务了。 解决巡检时记录每个光模块的收发光功率建立历史趋势。正常范围只是及格线真正要关注的是“余量”——当前值距告警线的距离。余量低于20%就列入重点观察名单准备好备件余量低于10%就安排更换窗口。特别是核心链路的光模块宁可提前更换也不等它自然失效因为核心链路故障的影响范围太大了。本文还有配套的精品资源点击获取