1. 巡检这件事真的不能只靠“感觉”华为设备在国内机房里的占比不用多说运营商、政企、教育、金融随便进一个机房大概率看到的就是华为的机架式交换机或者AR系列路由器。很多网工朋友日常巡检的方式其实就是一个“ping”走天下网关能通、核心能通、外网能通就认为设备没问题。说实话这种巡检方式在故障发生之前基本没用等到你发现ping不通了业务往往已经挂了十几分钟甚至更久。网络设备巡检的核心目的不是“确认设备现在活着”而是“提前发现设备未来可能出问题的征兆”。高温、光模块劣化、CPU间歇性飙高、日志里反复出现的错误计数、STP拓扑反复震荡这些东西都不会让你立刻断网但它们都写在设备的内部状态里。你要做的就是通过命令把这些状态读出来判断设备是健康、亚健康还是已经亮红灯了。我平时巡检华为设备基于VRP系统用的命令体系核心就一个字display。这个命令相当于设备的“体检报告生成器”后面跟不同的参数拿到不同维度的状态。很多刚入行的网工手里也有一堆display命令但问题是不知道每条命令看什么、什么数值算正常、什么情况必须马上处理。这篇文章我就把日常巡检里最常用、最能说明问题的华为命令逐条拆开讲每一类命令对应什么问题、输出怎么看、阈值大概是多少都给你捋清楚。2. 系统级巡检设备本身是不是处于健康状态2.1 看家底版本、序列号、运行时间每次巡检我习惯先摸设备底细。登录设备后第一条命令通常是display version这条命令会带出VRP操作系统的版本号、设备型号、启动时间、持续运行时间等信息。别小看这几个字段很多麻烦都是从这些基础信息里发现的。比如运行时间uptime这个字段如果一台核心交换机显示运行了300多天本身不算异常但我心里会立刻拉响一个警报这台设备很久没有重启过了。长时间运行的设备内存碎片会比刚启动时严重得多偶尔就会出现某些进程无法申请内存的情况。尤其是老版本VRP跑个两三百天以后内存泄漏的现象挺常见典型特征就是display memory看到Memory utilization一天比一天高。所以巡检时看到超长uptime我的习惯是翻一下变更记录找机会在维护窗口做一次计划性重启别等它自己出故障。display version还会显示补丁信息。生产环境的华为设备一定要关注补丁版本。VRP系统不像Windows那样三天两头打补丁但华为会针对一些已知问题发布补丁包涉及转发异常、协议栈缺陷的补丁尤其重要。如果发现当前补丁版本明显落后应该列入整改计划。紧接着我会再看一下设备序列号和ESN码display esn这条命令在华为设备上可以直接查到设备的电子序列号用于在华为技术支持网站上核对维保信息。有些公司设备维保到期了自己都不知道等设备坏了找华为开Case才发现过保了只能按高价买服务。巡检时顺便过一遍序列号把维保到期时间记进台账这个是网工很容易忽略但商业上很重要的事。2.2 CPU和内存设备的“血压”和“血糖”设备和人类似CPU和内存就是核心生命体征。华为设备的CPU查看命令是display cpu-usage输出会分成两大部分一个是整个设备的整体CPU占用率另一个是每个进程的CPU占用明细。这里要注意一个很多人容易踩的坑华为交换机尤其是盒式交换机的CPU占用率和你PC的CPU占用率不是一个概念。交换机的控制平面CPU负责处理协议报文、登录管理、SNMP轮询这类事情数据转发是交给硬件芯片完成的不占CPU。所以一台交换机即使跑着满端口的10G流量CPU占用率也可能只有百分之几这是正常的不要被吓到。反过来如果CPU占用率持续超过70%就要警惕了。常见原因包括广播风暴、环路导致协议报文泛滥、被扫描攻击、SNMP轮询频率过高、或者某条策略路由配置异常导致软转发。看CPU输出时我习惯重点看两个地方第一CPU utilization最近5秒和最近1分钟的值第二占用率排前几名的进程是什么。如果排第一的是BMS基础管理系统那大概率是正常的如果排第一的是某个你不认识的进程比如XXX这种那就要去查一下这个进程对应什么功能。很多故障定位的第一步就是从进程异常开始的。内存检查命令display memory重点看Memory utilization这个百分比。华为设备不同的单板、不同的软件版本内存水位线的表现不太一样但经验上持续占用超过80%就要警惕了。尤其要注意设备在正常运行状态下内存占用率是否有缓慢爬升的趋势。今天巡检看到60%下个月65%再下个月70%这种“缓慢但持续”的增长就是内存泄漏的典型信号。检查CPU和内存的时候还有一个非常实用的小技巧连着取几次值不要只取一次。比如隔10秒刷一次display cpu-usage连续5到6次看峰值和均值。很多瞬时的CPU飙高问题单次巡检刚好错过而通过多次采样更容易抓到异常毛刺。2.3 设备温度高温是硬件的头号杀手华为设备查看温度的典型命令display temperature all这个命令在不同型号上输出格式略有差异但核心信息是一样的当前温度、高温告警阈值、低温告警阈值。如果设备温度已经超过高温告警阈值日志里大概率已经出现TEMPERATURE相关告警了这时候不能只记录要立刻检查机房空调状况、设备风扇是否停转、机柜通风是否顺畅。机房温度本身正常但不代表设备温度正常这个坑我踩过很多次。比如某台交换机上面正好有其他设备的热风出口对着吹或者机柜后排线太密堵住了散热风道机房整体温度没问题但某台特定设备就是温度偏高。所以巡检时不仅要看设备温度数值还要留意同一机柜内不同设备的温度差异。如果同一排的几台交换机别台都是40多度某台到了60度那物理位置上一定有特殊原因很可能就是散热风道被堵了。风扇状态也是温度检查的一部分display fan重点看每台风扇的转速和状态。华为盒式交换机一般有两到四个风扇如果有一个风扇故障设备还能靠剩余风扇顶着跑但散热能力大幅下降。尤其是夏天一个风扇坏了如果不及时处理设备会在高负载时温度快速爬升最终触发高温保护直接下电。高温保护是硬性的不给你多少缓冲时间。3. 接口与链路巡检90%的故障都藏在这里3.1 接口状态和流量先分清“up”和“up”的区别接口是网络设备最前线的工作岗位大部分网络故障最终都会体现在接口状态上。华为设备查看接口状态的命令display interface brief这个命令会把所有接口的物理状态、协议状态、入方向/出方向流量、错误包数全部列出来。这里最重要的一点是区分物理状态和协议状态Physical这一列表示链路底层是否握手成功Protocol这一列表示链路层协议是否正常协商。对于以太网接口来说正常情况下两列都应该是up。如果出现物理up但协议down的情况通常意味着协商出了问题比如两端双工模式不匹配、光模块收发异常、或者中间链路上有其他设备介入。光口和电口要区别对待。华为交换机上常见的电口RJ45如果显示down大概率是物理上没插线、对端设备没开机或者线缆坏了。光口SFP/SFP的情况要复杂得多光模块本身会老化尤其是用了三年以上的多模模块发射光功率会逐渐下降直到低于接收端的灵敏度链路就开始间歇性丢包甚至直接down。所以光口的巡检不能只看up/down状态还要看光模块的收发光功率display transceiver interface gigabitethernet 0/0/1 verbose重点看输出里的Tx Power发射光功率和Rx Power接收光功率。华为设备通常会给一个范围参考值比如Tx Power范围是-3.0 ~ -9.0 dBmRx Power范围是-3.0 ~ -19.0 dBm。如果Rx Power已经接近下限甚至低于下限链路虽然还能通但余量已经非常小了随时可能因为光模块进一步劣化或者光缆接头被轻微污染而丢链。我在巡检时看到接收光功率低于-17dBm左右对千兆多模来说就会列入预警清单安排更换或排查光纤。接口流量也是重要指标display interface gigabitethernet 0/0/1完整输出里会包含Input和Output方向的速率统计。这里有个需要理解的细节华为显示的是“平均速率”而且有时间窗口所以不要只取一次值最好隔几秒再看一次。理论上千兆口跑到900Mbps也不一定就是问题但如果一个接入端口常年跑在带宽上限附近就要考虑链路的容量规划问题了临时来看可能没问题但一旦出现突发流量就会丢包。3.2 错误计数最容易被忽略的故障前兆接口错误计数是巡检中含金量最高的信息之一但很多人看interface brief时完全不看错误计数那几列。华为查看接口错误详情的命令display interface gigabitethernet 0/0/1在输出尾部会看到Input error counters和Output error counters。重点关注这几种错误CRC errors数据帧在传输过程中出现了循环冗余校验错误通常意味着物理层有问题比如光纤质量差、光模块劣化、网线过长或质量差。如果CRC错误数量持续增加链路基本处于亚健康状态今天不丢包不代表明天不丢包。Runts/Giants小于64字节或大于1518字节或按MTU设置的帧。出现这种情况大概率是硬件故障或链路干扰。Late collisions冲突发生在帧发送后期一般和链路距离过长、双工模式不匹配有关。看到错误计数不等于立刻就要断网但必须判断这个计数是持续增长还是历史遗留。怎么判断很简单现在取一次值过10分钟再来取一次如果数字变了说明当前就有错误在发生。如果两个时间点的数字完全一样那说明是历史累积可以暂时不处理但要在台账里记录基线下次巡检对比。接口层面的巡检我自己的体会是不要只看fei口或者gi口Trunk口和Access口的巡检密度应该一样。尤其是Trunk口承载多个VLAN的流量一旦它出问题影响范围是跨VLAN的排查起来也更麻烦。3.3 链路聚合与堆叠冗余方案本身的健康检查现在的网络设计里链路聚合Eth-Trunk已经是标配了。华为的链路聚合检查命令display eth-trunk 1重点关注两项Port Status这一列每个成员口是否都是Selected状态以及Flapped Count是不是在持续增长。如果某个成员口频繁在Selected和Unselected之间切换说明这条成员链路质量不稳定会导致哈希重分布引发少量丢包和延迟抖动。这种抖动的隐蔽性很强业务方会反馈“网络卡”但ping大包不丢、ping小包也不丢只有跑UDP大流量的时候才会有感知。这时候翻一下Flapped Count基本就能定位。堆叠场景华为的CSS和堆叠需要额外检查display stack configuration display stack status检查堆叠成员是否都在位、堆叠带宽是否正常、主备倒换历史记录有没有异常。堆叠环境里有一个经典故障堆叠线缆接触不良导致分裂两台设备各自认为自己是主交换机于是出现双主场景。华为针对这个场景有DADDual-Active Detection机制但前提是配置要正确。巡检堆叠时我会专门确认DAD检测链路的状态如果DAD链路本身down了那堆叠分裂基本上就无法自动检测了这是重大隐患。4. 协议和业务巡检网络“通不通”和“好不好”是两回事4.1 VLAN与接口归属接入层的照妖镜VLAN配置错误是接入层高频故障尤其是交接班或者多人维护同一个网络的时候经常有人改了接口的VLAN没做记录等出了问题谁也说不清。巡检命令display vlan能看到VLAN ID、VLAN名称、以及该VLAN下绑定的接口。重点检查两件事是否有接口被误加进了VLAN但实际不该在VLAN的接口列表和拓扑图是否一致。更细的接口VLAN归属检查display port vlan或者对单个接口display interface gigabitethernet 0/0/1这条能看到该接口的PVID、允许通过的VLAN列表、Trunk口还带VLAN tagging信息。巡检时发现接口允许通过的VLAN比设计文档多就要留个心眼可能是历史配置遗留也可能是误操作导致。多放行的VLAN不一定马上出问题但一旦那个VLAN里有广播风暴或者被蠕虫病毒感染的主机影响面就会无谓地扩大。4.2 STP网络防环的最后一道防线STP生成树协议状态是交换机巡检绕不开的内容。华为设备默认开启了STP或RSTP/MSTP但很多网工把它当成“默认配置就放着”的东西从来不检查。直到有一天环路发生了才想起来看STP。查看STP状态的命令display stp brief这个命令列出所有接口的STP角色和状态。正常情况下的关键认知根桥Root Bridge所在的位置应该在网络核心层。如果你发现根桥跑到了某台接入交换机上说明STP优先级配置有问题这会导致整网的生成树拓扑偏离设计流量走向和冗余路径全部和预期不符。display stp可以看本设备的STP信息包括桥ID、根桥ID、优先级以及TCTopology Change计数。TC计数是重点短时间内TC计数暴涨说明网络拓扑在频繁变化。常见原因是某个接口在up/down之间反复抖动或者某个主机的网卡异常导致交换机接口反复重新学习MAC地址。TC风暴会导致所有交换机的MAC地址表频繁刷新转发性能会严重下降而且这种问题往往没有专门的告警只能通过STP状态观察发现。RSTP边缘端口配置也是巡检重点。连接终端主机的端口应该配置为stp edged-port enable这样终端开关机不会触发STP计算端口能快速进入转发状态。如果终端端口没有配边缘端口每次有电脑开机交换机都要等30秒甚至50秒的STP收敛用户就会感知为“网口插上以后要等半天才能上网”。4.3 路由协议核心网络的“任督二脉”对于三层设备华为AR路由器、S5720/S5730等三层交换机路由协议巡检是重中之重。display ip routing-table查看路由表概要重点确认核心网段和回程路由都在。南向流量通了但回程路由丢了这种“单向通”的故障特别坑人。看着像链路问题实际是路由问题排查绕一大圈。OSPF环境看邻居状态display ospf peer所有邻居状态应该是Full。如果出现ExStart、Exchange、Loading这些中间状态说明邻居关系正在建立中但如果持续停留在这个状态就要检查MTU匹配、区域ID配置、认证配置。还有一个容易被忽略的OSPF邻居反复震荡。display ospf peer只能看到当前状态看不到历史震荡。要查历史需要用display ospf error查看协议报文错误计数。如果NbrStateChange计数不断增长基本可以判定邻居关系在频繁重建原因通常是链路质量差导致Hello报文丢失。BGP场景的命令display bgp peer关注BGP邻居的State列应该是Established。还需要关注MsgRcvd和MsgSent报文计数是否持续增长如果长时间不增长说明邻居之间没有数据交互可能处于半死状态也要注意Up/Down时间频繁变化的问题。4.4 VRRP与网关冗余主备切换的“演练”华为的VRRP虚拟路由冗余协议配置在核心和汇聚层很常见。查看VRRP状态的命令display vrrp正常情况下主设备状态为Master备设备状态为Backup。这里需要关注的是一个很多人忽略的点当主备切换发生时VRRP状态切换本身是正常的但你要确认切换原因是不是符合预期的。比如因为主设备要维护重启主动切换这是正常的。但如果没有任何操作的情况下发生了切换就要查日志看切换原因可能是心跳链路质量差导致备机误判主设备故障。此外display vrrp看到的状态是当前时刻的无法反映历史切换次数。有经验的做法是把display vrrp的Up Time和Virtual IP对应起来如果主设备的Up Time经常重置说明发生过多次切换需要关注链路稳定性。5. 日志、时间与配置备份看不见的防线5.1 日志里的“暗号”怎么解华为设备所有的重要事件都会写入日志。查看日志的命令display logbuffer日志缓冲区默认只保留最近的几百条到上千条记录所以巡检时看到的信息只是“最近发生的事”不是完整历史。这里有个关键经验设备本地日志缓冲区是易失的设备重启后日志会清空。所以重要的日志信息一定要通过info-center loghost配置实时发送到日志服务器。没有日志服务器的环境至少也要定期把display logbuffer的输出保存到本地文件中形成历史归档。巡检日志时重点看这几类关键字Fault、Error硬件故障或者系统错误Down、Up接口状态变化大量接口短时间内反复up/down说明有物理层问题OID相关的Alarm光模块这类硬件告警STP关键字生成树变化Memory、CPU资源告警看到日志里的告警内容不能只记录不处理。比如日志里出现光模块的Alarm链路可能还是up的但光模块已经进了劣化状态这时候不处理过几天可能就起不来了。5.2 NTP同步日志分析的前提条件NTP网络时间协议看似是边缘配置实际影响非常大。各设备时间如果不一致出故障后排查日志时多个设备的事件顺序完全对不上可能本来2小时能定位的问题因为时间线对不上要花一整天。NTP状态检查命令display ntp status主要看Clock Synchronized字段是否为yes以及当前时间偏差。如果有偏差通过display ntp sessions查看对端NTP服务器是否正常响应。我见过不少网络环境NTP服务器本身是好的但中间防火墙放行了123端口管理员改策略的时候不小心给NTP流量加了QoS限制导致终端设备时间同步周期被拉长。这种问题不仔细看很难发现。所以NTP巡检不光看设备本身配置还要确认从设备到NTP服务器之间的连通性以及同步偏差是否在合理范围内。5.3 配置备份你永远不知道什么时候需要它配置备份虽然不是一条命令能搞定的但它是巡检流程中绝对不能少的一环。每次巡检做完必须把配置导出来存档。登录华为设备后执行display current-configuration这会输出设备的当前生效配置。我通常还要执行display saved-configuration对比一下当前配置和保存配置。如果两者不一致说明有人改了配置但没有保存。这可能是有意的临时操作改完测试发现不对直接回退也可能是无意的误操作忘记保存就离开了。无论是哪种情况一旦设备重启所有未保存的修改都会丢失这个事实必须在台账里记录清楚。配置备份文件里我还会额外加上一条命令的输出display clock把设备当前时间也归档。这样如果未来排查问题时需要核对时间不用再登录设备查。6. 常见故障信号与排查实录6.1 广播风暴接口流量异常的经典场景广播风暴的典型症状是网络整体变慢、CPU飙升、某些接口的流量统计达到带宽上限。用display interface brief流量列能快速发现流量异常的端口但判断风暴来源需要借助一个更细的命令display mac-address查看MAC地址表。正常情况下一个接口下应该能看到多个MAC地址对接到交换机或集线器。如果某个接口的MAC地址表数量异常庞大且不断有新的MAC地址在学习这个接口下面极有可能接了导致环路的设备——比如一台开启了STP转发但实际两端都插线的傻瓜交换机或者终端上开启了网络共享功能导致二层环路。发现后先把该接口shutdown网络恢复后再沿链路排查具体原因。6.2 光模块光功率偏低提前发现链路隐患比较典型的场景某条办公网链路用户反馈网络间歇性卡顿但ping外网IP丢包率并不高。查看接口统计后发现CRC错误计数在持续增长进一步执行display transceiver interface后确认Rx Power已经接近下限。这种情况下光模块本身还能工作但不稳定更换光模块后问题消失。这个案例说明巡检时多看收发功率和错误计数这两项很多隐性故障是可以提前避开的。6.3 设备频繁重启注意电源和内存遇到过一台接入交换机在一个月内重启了三次业务影响不大但每次都造成该区域网络短暂中断。查看display version发现uptime清零同时display logbuffer里能看到重启记录但没有硬件告警。通过display power检查电源状态发现两个电源模块中有一个没有输出另一个负载偏高。更换故障电源模块后设备运行稳定。硬件问题有时候表现得很隐蔽不检查电源模块状态的话很难定位。7. 把巡检命令串成一套可落地的日常流程命令本身不复杂难点在于把命令组织成流程并坚持执行。我个人的习惯是把巡检分成日检、周检、月检三个频率层级各有侧重不一定每天都是一套全量命令。日常巡检日检针对核心设备和关键链路命令精简为display version看uptime、display cpu-usage、display memory、display interface brief看端口状态、display logbuffer看是否有新增告警。这5条命令跑一遍5分钟内能判断一台设备整体健康度。周检在日检基础上补充display temperature all、display fan、display stp brief、display eth-trunk、display transceiver interface针对光口。这些命令用于发现硬件劣化和链路状态变化。月检则是全量巡检所有之前提到的命令全部跑一遍加上配置备份、NTP状态核对、路由协议状态核对。月检还要做一件事把本月巡检数据和上月做对比重点看错误计数、光功率、接口流量这些数值的增量变化。针对不同设备型号华为的命令体系基本一致但个别参数有差异。比如S5720系列和S12700系列在display transceiver的输出格式上略有不同AR路由器和交换机在接口命名方式上也有一些差异GigabitEthernetvsGE。遇到不确定的命令时在设备上敲一个?就能看到所有子命令或者直接使用display不加任何参数设备会列出所有可用的display子命令这是最笨但最有效的自学方式。对于设备数量较多的环境手动逐台登录执行命令效率太低可以考虑用Python的Paramiko或Netmiko库写一个批量巡检脚本自动登录设备、执行命令、抓取输出并保存到文件。脚本逻辑不复杂核心就是连接设备、发送命令、保存结果但对批量运维效率的提升非常明显。关于脚本部分我会在另一篇文章里详细写这里先给一个基本思路。8. 写在最后巡检的价值在“基线”而不在“快照”做了这么多年网络运维我最大的体会是巡检本身并不神秘难的也不是记命令而是建立“基线意识”。单次巡检拿到的一堆数字意义非常有限真正的价值在于持续记录、持续对比知道这台设备“正常时候长什么样”才能在异常出现的第一时间发现问题。哪怕只是每周花半小时把几个核心指标记录下来坚持两个月你就能发现很多规律比如某台设备每天固定时间CPU会小涨一次可能是定时备份任务、某个光口的接收功率在缓慢下降可能光纤接头在劣化、某条链路的错误计数每周都在增长需要约个时间更换模块。这些信息比任何监控系统输出的告警都更早、更准确。还有一个小建议每次巡检完把当次发现的问题按紧急程度分成三类——“需要立即处理”“安排本周处理”“列入月度整改”并发给相关同事或领导。巡检发现问题不算本事发现问题后能让问题被解决才是本事。很多网工巡检报告写得很规范但后续跟踪没有闭环问题还是那些问题巡检就变成了走过场。华为设备的display命令体系是很强大的只要你认真用好它设备的大部分状态对你来说是透明的。希望这篇关于华为网络设备巡检命令的文章能给各位网工朋友一些实际帮助。如果你有自己的独门巡检技巧也欢迎交流干这行就是在不断交换经验中成长的。