我还记得自己刚入行那会儿第一次独立承担一个中型园区的网络巡检任务。当时领导丢给我一份华为设备巡检命令清单上面就写着display devicedisplay cpu-usage这几个命令让我照着敲一遍有问题记录一下。我老老实实敲完了也确实记录了但回头一看——全是瞬时数据根本没有参考价值。后来一位老网工点拨了我一句巡检不是敲命令是‘带着基线去看差异’。这句话说得特别透。华为网络设备巡检看着是一堆命令的堆砌实际背后是一套完整的设备健康度评估逻辑。真正的巡检动作是围绕设备是否处于稳定运行状态、是否存在隐患趋势、配置是否符合规范这三个问题展开的。今天这篇文章我就把这套思路和命令完整梳理一遍给刚接触华为设备或者正在准备系统化巡检的网工朋友做个参考。1. 巡检的底层逻辑先有基线再谈告警1.1 为什么单看命令输出没用很多朋友巡检时有个习惯登录设备后一口气敲完display version、display device、display interface brief看到无红色无异常就认为设备没问题。这里有个很大的误区设备当前显示正常只能说明此刻它没病发不代表它没有隐患。比如设备温度从 45°C 爬到 65°C中间经历了两周每次看都在正常范围上限内所以没问题——可等到 78°C 触发告警时板卡性能和寿命已经受到影响了。正确的巡检姿势是建立基线baseline。第一次巡检时记录各关键指标的正常值后续巡检时对比这些数值观察变化趋势。数值本身不是重点变化方向、变化速率和离基线多远才是需要关注的核心。1.2 华为设备巡检的三条主线做巡检前把思路理清比记命令重要得多。我个人习惯把巡检内容拆成三条主线硬件层设备整机运行状态、板卡、电源模块、风扇、温度传感器转发层接口状态、光模块收发光功率、错误计数、链路协商情况控制层CPU利用率、内存利用率、路由协议邻居状态、日志告警。三部分之间互相影响。比如光模块发光功率持续下降最后接口彻底 down这是转发层问题而广播报文过多导致 CPU 利用率升高则可能同时体现在转发层和控制层。巡检时最好按顺序逐层过一遍出问题时才能快速定位不会被单点表象迷惑。2. 硬件层巡检从开机信息到温度电压告警2.1 初检设备版本与启动信息拿到一台需要巡检的华为设备第一步先看它是什么型号、跑了多久、当前是什么版本。这组信息决定了后面所有命令的兼容性和判读标准。华为设备支持的命令行在 VRP 平台上高度统一不过不同产品交换机 S 系列、路由器 AR/NE 系列、防火墙 USG 系列的反馈内容和字段含义略有差异。先记录版本信息后续排查或者找研发沟通时这也是最原始的定位依据。常用命令如下Huaweidisplay version这是登录后的第一条命令。输出中包含设备的软件版本、补丁版本、系统启动时间和运行时长。其中 Up Time 字段很关键如果一台设备长时间未重启你又发现它最近行为异常那大概率是内存碎片或长期运行的隐性 bug 累积需要预约维护窗口重启验证。接着用Huaweidisplay device查看设备电源、风扇等关键模块状态。华为交换机上这台设备返回的信息基本能确认电源模块是否在位、是否正常工作风扇转速状态也能看到。完整的判断标准是设备的电源和风扇模块状态应该为 Normal如果出现 Fault 或者 Absent必须第一时间处理——缺电源的冗余在机房掉电时就是灾难风扇故障则是散热隐患会让设备温度在几个小时内飙升。2.2 环境监控温度、电压和风扇转速机房的人喜欢把设备堆在机柜里但盘点一下就知道散热条件往往没那么理想。有的机柜前后门紧闭设备贴着设备温度常年偏高。华为设备内部有完整的监控体系直接看传感器数据就行。Huaweidisplay environment这条命令会把设备各单板的温度、CPU 附近温度、系统电压、风扇转速全部列出来。注意不是所有型号的输出都能通过display environment看到所有信息老的 S5700 系列有时候要看Huaweidisplay temperature all Huaweidisplay fan Huaweidisplay powerS 系列和 CE 系列的命令体系稍有不同建议拿到设备先敲这些命令试试输出确认该设备实际支持哪些。温度判断上我给个参考接入层交换机温度在 40°C 到 55°C 属于正常范围核心交换机因业务量大温度可能会高一些但长期超过 60°C 就要留意。机柜内设备的进风温度如果高于 28°C单板温度很容易被推高建议从机房空调和机柜风道入手治理。电压项平时很少看但出现硬件类隐性故障时电压异常是很重要的排查入口。巡检时我不要求大家把每个电压值背下来只要大致了解当前输出与上次记录没有明显跳变即可。3. 转发层巡检接口状态、光模块与错误计数3.1 接口状态速览接口层的巡检任务最繁重因为一台接入交换机动辄 48 口每个口的物理状态、协议状态、流量、错误计数全查一遍工作量不小。好在华为设备提供了简明的汇总视图Huaweidisplay interface brief输出会列出所有接口的物理状态Physical、协议状态Protocol、入方向流量InUti、出方向流量OutUti、入方向错误InErrors和出方向错误OutErrors。**注意Physical up 和 Protocol up 是两回事。**物理 up 表示光/电链路通协议 up 表示链路层的协商也完成了。有些场景会出现物理 up 而协议 down——比如对端口被 shutdown、Trunk 端口和对端 Hybrid 端口 mismatch、或者 PPP 链路 LCP 没协商完成。巡检时遇到这类接口先别急着判断为故障看看是不是配置端本来就打算如此。另外看接口流量时别只盯着 up/down还要关注流量是否接近带宽上限。接入层百兆口长期跑在 95% 以上那问题就很尖锐了。display interface brief里的 InUti/OutUti 是最近 5 分钟的平均值作为快速筛子够用但要看更准的趋势建议后续拉取设备的性能统计数据。3.2 光模块健康收发光功率与诊断信息光纤链路是现代网络的主力承载光模块的状态往往决定了链路质量的底线。很多网工忽略光模块巡检觉得ping 通了就没事直到某天业务半夜中断才发现模块发光功率早就飘到临界值了。华为设备上查看光模块诊断信息的命令Huaweidisplay transceiver interface g0/0/1 verbose输出中会包含光模块的温度、电压、发送光功率TX Power、接收光功率RX Power以及各项阈值。注意不是所有模块都支持查询诊断信息——部分第三方兼容模块会返回 not support 或信息不完整这也是采购模块时需要注意的坑。判断标准核心看两件事收光功率不能太低否则接收灵敏度不足会丢包也不能过高否则接收端饱和也会产生误码。正常情况下接收光功率建议在 -15dBm 到 -1dBm 之间不同模块阈值不同发送光功率则看模块类型单模模块通常在 -3dBm 到 2dBm 左右。关键看数值是否在阈值范围内并且与上一次巡检记录相比没有快速衰减。3.3 接口错误计数别让隐藏问题积累面板状态全绿、光功率正常但网络偶尔还是卡去翻接口的错误计数。Huaweidisplay interface g0/0/1看输出末尾的 Input errors / Output errors 部分。CRC 错误计数持续增长基本可以判断物理链路质量有问题常见原因包括光模块老化、光纤弯曲半径过小、连接头污染、网线质量差电口场景。而 Output errors 过多则可能和对端设备的协商能力不匹配或者 buffer 不足有关。值得强调的是错误计数是累计值从设备启动开始一直累加。设备运行一年有几百个 CRC 错误并不罕见但关键是它是否在持续增长。建议巡检时记录错误计数基线两次巡检间比较增量。如果短时间内暴涨那就是真实故障的预警信号。干净的链路错误计数的增长速率应该非常平缓甚至停滞。4. 控制层巡检CPU、内存与日志里藏着的真相4.1 看得懂 CPU 和内存负载华为设备的 CPU 利用率不是简单一个数字就能概括的。display cpu-usage会显示整机 CPU 利用率和各任务的占用情况。Huaweidisplay cpu-usage查看输出时重点关注两个维度CPU 整机利用率是否持续高位运行。核心交换机平时 30%-50% 比较正常跑到 80% 以上并且持续数小时一定要查明原因是否有单个进程占用 CPU 过高。比如某个路由协议进程不停地收敛计算或者 SNMP 大量重复查询导致 CPU 被打满都是常见的异常场景。内存方面用Huaweidisplay memory-usage重点看内存利用率是否超阈值。华为 VRP 平台下内存碎片是长期运行设备的常见问题尤其某些产品版本存在内存越用越多的隐性泄漏。如果您发现设备的内存利用率在几个月内持续缓慢上升并且无法回落就要规划业务窗口重启验证了。这里有个实用小技巧巡检时不要只看当前内存利用率建议顺带命令Huaweidisplay memory-usage slot all多框设备或者模块化设备逐槽位查看内存使用能发现是哪块板卡在吃内存定位比整机视角快得多。4.2 日志复盘被大多数人忽略的黄金线索日志是整个巡检里最值得花时间看的内容但很多网工把display logbuffer当成出了问题再看的被动工具。其实日志里的很多信息反映的是早期的异常趋势。Huaweidisplay logbuffer这个命令默认显示最近保存的日志。比较实用的做法是结合时间范围过滤Huaweidisplay logbuffer level warning Huaweidisplay logbuffer | include Fault\|error\|down巡检时对日志内容的判读思路接口频繁 up/down日志里如果同一接口反复出现 Interface has turned to DOWN / UP 的记录说明链路存在不稳定因素。可能原因包括光模块漂移、对端设备重启、光纤收发器不稳定甚至是环路震荡引发的端口反复阻塞。认证失败记录出现 AAA 认证失败的日志要么有人密码输错要么存在暴力破解尝试属于安全类隐患需要关注。设备主动重启的记录如果日志中出现设备非计划重启的痕迹即使当前业务已经恢复正常也必须查明重启原因别让隐患带着走。日志的另外一个优势是它可以作为事后回溯的依据。日常巡检时把告警级和错误级的日志内容抄录归档写周报月报时这就是最有说服力的素材。4.3 全局告警概览如果是比较大的网络一台一台登录设备敲命令效率太低。此时可以用简洁的全局告警查询Huaweidisplay alarm active华为 VRP 系统会维护一个当前活动告警列表所有未消除的硬件和资源告警都会列在里面。通过这个命令能快速筛选出需要关注的设备。如果环境监控配置了 SNMP 告警推送配合网管平台会更高效但在没平台的环境里这条命令就是最直接的快速筛查工具。5. 路由与业务层面巡检邻居关系与路由表健康度5.1 OSPF 和 BGP 邻居网络稳定性的核心指标在中大型网络中路由协议的邻居关系状态是业务连续性的晴雨表。邻居关系一旦震荡整个业务平面都会抖三抖。巡检时我用得最多的是Huaweidisplay ospf peer Huaweidisplay bgp peerOSPF 邻居状态正常应该是 Full看到 2-Way 表示是 DR/BDR 关系下的正常状态广播网络中的非 DR 设备之间但如果有反复处于 Exstart/Exchange 状态的邻居那就是 MTU 不一致或 Hello 参数不匹配需要立即处理。BGP 邻居状态看 Established。如果看到 Connect、Active 或 Idle邻居关系没建立成功。BGP 邻居掉一次会引发大量路由撤销影响面可能很大所以日常巡检一定要盯住邻居状态的稳定性。我处理过一个大客户网络的故障就是由于光纤质量劣化导致 OSPF 邻居反复重建立每次重建立都带来一次路由震荡全网时延抖动持续飙升。如果当时巡检中早发现邻居状态记录里 Up/Down 次数在快速增加这个问题完全可以提前规避。5.2 路由表与 ARP 表异常排查路由条目的巡检并不需要把整张表都背下来重点是关注关键前缀和路由来源是否符合预期。Huaweidisplay ip routing-table建议重点关注是否有非预期路由窜入如多了一条指向不明下一跳的默认路由有可能是远端误配置注入核心业务网段的路由是否正常存在等价路由ECMP数量是否符合预期如果原来 2 条等价路由变成 1 条很可能是某条链路或协议邻居出了问题路由表条目总数与基线相比是否发生突变。一个路由表条目数量急剧增长可能是网络收到大量路由注入的早期信号。ARP 表在接入场景里也值得一看Huaweidisplay arp重点排查两类情况一是 ARP 表里出现大量未知名 MAC 地址可能与内网扫描或终端异常有关二是静态 ARP 条目被动态条目覆盖前提是设备上有静态 ARP 配置这通常意味着网络中出现了地址冲突或欺骗行为。6. 巡检报告的沉淀从命令输出到可执行的结论6.1 让每次巡检都有留痕我见过不少网工做巡检时信息全部停留在自己的脑子和记事本里设备一多时间一长全都忘了。其实巡检这件事不仅仅是为了当场发现问题更是为了积累数据、形成历史轨迹。没有历史数据的支撑后续做网络扩容、设备替换、故障回溯时都会缺了参照物。我的做法是每次巡检都按设备建立一份记录文件内容包括设备信息型号、版本、序列号、各硬件模块状态、关键接口状态、CPU/内存水位、告警日志摘要以及和上次巡检的差异对比。不用复杂的模板一个表格就能搞定。关键参数可以照着以下格式记录设备名上次巡检日期CPU 利用率内存利用率温度备注CORE-SW012025-12-0142%55%51°C无异常CORE-SW022025-12-0138%49%49°C电源模块正常6.2 关于命令行批量采集的一点经验如果你管理的华为设备数量比较多建议把常用巡检命令写到脚本里实现半自动采集。比如用 SecureCRT 或 Xshell 的日志功能配合 Python 的 netmiko / paramiko 库批量登录设备执行命令后统一收集输出。我自己的习惯是封装一层循环# 简单示例使用 netmiko 批量采集华为设备巡检信息 from netmiko import connect_handler device { device_type: huawei, ip: 192.168.10.1, username: netadmin, password: yourpassword, port: 22, } commands [ display version, display device, display cpu-usage, display memory-usage, display interface brief, display transceiver interface g0/0/1 verbose, ] conn connect_handler(**device) conn.enable() for cmd in commands: output conn.send_command(cmd) print(f {cmd} ) print(output) conn.disconnect()这段代码用于 SSH 连接华为设备并批量下发命令使用前需要安装 netmikopip install netmiko。安全起见建议代码里的密码等敏感信息通过环境变量或配置文件方式读取不要把明文密码直接写在脚本里。批量采集的产出是原始输出真正花时间的是解析和对比。我一般会把采集到的接口错误计数、光模块收光功率、CPU/内存使用率提取出来按设备维度做成趋势表。如果运维预算允许也可以搭一套简单的网管平台如华为 eSight 的轻量功能或开源 Zabbix 结合 SNMP把采集自动化巡检就变成每天自动出报告人工只需要关注告警项。6.3 巡检频率与巡检时机的建议频率没有一个万能答案取决于网络规模和设备的重要程度。我执行的节奏是这样的核心设备每天一次自动化采集SNMP 或脚本 每周一次人工深度巡检接入/汇聚设备每周一次自动化采集 每月一次人工巡检重大变更前后变更前必须做一次基线性巡检变更后做一次验证巡检确保没有引入新隐患。另外雷雨季节、夏季高温天气、机房空调维护期间建议加大温度、电源和告警日志的巡检频次。很多机房故障都发生在环境剧变的窗口期提前盯住环境指标能避开不少坑。7. 华为设备巡检中容易踩的坑最后集中聊几个我实际巡检过程中遇到的典型坑给大家做个参考。7.1 盲目执行命令导致业务割接现场翻车有些命令在巡检中看似无害但如果使用不当影响极大。比如display reset并不是巡检命令如果手误输入 reset华为设备通常会先让用户确认。但更危险的是在全局视图下敲了错误的undo命令。所以我个人的铁律是巡检时全部使用display开头的只读命令不带任何reset、clear、shutdown、undo这类可能改变设备状态的命令。就算是clear logbuffer这种看起来无害的操作也要经过业务窗口审批后再执行。7.2 看输出只看关键字忽略上下文比如查看接口错误计数时有些人只看有没有 error却忽略了对端口的协商模式是否从全双工变成了半双工。华为设备的接口出现大量 CRC 错误的同时往往伴随协商模式的改变只盯一个指标会漏判根因。巡检时要多个字段交叉印证单看有没有报错是远远不够的。7.3 对第三方模块的诊断数据过度信任华为设备查询光模块信息时第三方兼容模块的信息完整度参差不齐。有些模块的 DDM 数据温度、电压、收发光功率并不准确甚至完全不可读。这类模块一旦链路质量下降传感器读数是帮不上什么忙的只能靠错误计数和连通性测试辅助判断。因此采购光模块时优先选官方认证模块巡检负担会小很多。7.4 忽略设备时间同步巡检日志和告警判断都依赖设备时间的准确性。如果设备的系统时间和 NTP 服务器不同步那么日志的时间戳就会失真故障回溯时根本对不上号。每次巡检建议顺带确认Huaweidisplay clock如果发现时间偏差明显第一时间检查 NTP 配置Huaweidisplay ntp-service status这是一个特别容易被忽略的检查点但重要性完全不亚于硬件健康度——没有统一准确的时间跨设备分析故障就是在沙滩上盖楼。写在最后华为设备的巡检命令其实不难背真正的功夫在于理解每条命令输出的业务含义以及把当次数据和历史基线做对比的思维习惯。我现在巡检一台设备全程大概也就二十分钟但这二十分钟里看的每个字段、记录的每个数值都可能在未来的某次故障处理中派上大用场。我自己体会最深的一点是巡检这份工作做一次容易坚持做很难。但恰恰是这种重复且枯燥的动作把很多故障扼杀在爆发之前。如果你刚开始做网络运维建议从今天起为手头的每台设备建立一份巡检基线档案然后坚持执行至少一个季度你一定会感受到这套笨功夫带来的回报。
我还记得自己刚入行那会儿第一次独立承担一个中型园区的网络巡检任务。当时领导丢给我一份华为设备巡检命令清单上面就写着display devicedisplay cpu-usage这几个命令让我照着敲一遍有问题记录一下。我老老实实敲完了也确实记录了但回头一看——全是瞬时数据根本没有参考价值。后来一位老网工点拨了我一句巡检不是敲命令是‘带着基线去看差异’。这句话说得特别透。华为网络设备巡检看着是一堆命令的堆砌实际背后是一套完整的设备健康度评估逻辑。真正的巡检动作是围绕设备是否处于稳定运行状态、是否存在隐患趋势、配置是否符合规范这三个问题展开的。今天这篇文章我就把这套思路和命令完整梳理一遍给刚接触华为设备或者正在准备系统化巡检的网工朋友做个参考。1. 巡检的底层逻辑先有基线再谈告警1.1 为什么单看命令输出没用很多朋友巡检时有个习惯登录设备后一口气敲完display version、display device、display interface brief看到无红色无异常就认为设备没问题。这里有个很大的误区设备当前显示正常只能说明此刻它没病发不代表它没有隐患。比如设备温度从 45°C 爬到 65°C中间经历了两周每次看都在正常范围上限内所以没问题——可等到 78°C 触发告警时板卡性能和寿命已经受到影响了。正确的巡检姿势是建立基线baseline。第一次巡检时记录各关键指标的正常值后续巡检时对比这些数值观察变化趋势。数值本身不是重点变化方向、变化速率和离基线多远才是需要关注的核心。1.2 华为设备巡检的三条主线做巡检前把思路理清比记命令重要得多。我个人习惯把巡检内容拆成三条主线硬件层设备整机运行状态、板卡、电源模块、风扇、温度传感器转发层接口状态、光模块收发光功率、错误计数、链路协商情况控制层CPU利用率、内存利用率、路由协议邻居状态、日志告警。三部分之间互相影响。比如光模块发光功率持续下降最后接口彻底 down这是转发层问题而广播报文过多导致 CPU 利用率升高则可能同时体现在转发层和控制层。巡检时最好按顺序逐层过一遍出问题时才能快速定位不会被单点表象迷惑。2. 硬件层巡检从开机信息到温度电压告警2.1 初检设备版本与启动信息拿到一台需要巡检的华为设备第一步先看它是什么型号、跑了多久、当前是什么版本。这组信息决定了后面所有命令的兼容性和判读标准。华为设备支持的命令行在 VRP 平台上高度统一不过不同产品交换机 S 系列、路由器 AR/NE 系列、防火墙 USG 系列的反馈内容和字段含义略有差异。先记录版本信息后续排查或者找研发沟通时这也是最原始的定位依据。常用命令如下Huaweidisplay version这是登录后的第一条命令。输出中包含设备的软件版本、补丁版本、系统启动时间和运行时长。其中 Up Time 字段很关键如果一台设备长时间未重启你又发现它最近行为异常那大概率是内存碎片或长期运行的隐性 bug 累积需要预约维护窗口重启验证。接着用Huaweidisplay device查看设备电源、风扇等关键模块状态。华为交换机上这台设备返回的信息基本能确认电源模块是否在位、是否正常工作风扇转速状态也能看到。完整的判断标准是设备的电源和风扇模块状态应该为 Normal如果出现 Fault 或者 Absent必须第一时间处理——缺电源的冗余在机房掉电时就是灾难风扇故障则是散热隐患会让设备温度在几个小时内飙升。2.2 环境监控温度、电压和风扇转速机房的人喜欢把设备堆在机柜里但盘点一下就知道散热条件往往没那么理想。有的机柜前后门紧闭设备贴着设备温度常年偏高。华为设备内部有完整的监控体系直接看传感器数据就行。Huaweidisplay environment这条命令会把设备各单板的温度、CPU 附近温度、系统电压、风扇转速全部列出来。注意不是所有型号的输出都能通过display environment看到所有信息老的 S5700 系列有时候要看Huaweidisplay temperature all Huaweidisplay fan Huaweidisplay powerS 系列和 CE 系列的命令体系稍有不同建议拿到设备先敲这些命令试试输出确认该设备实际支持哪些。温度判断上我给个参考接入层交换机温度在 40°C 到 55°C 属于正常范围核心交换机因业务量大温度可能会高一些但长期超过 60°C 就要留意。机柜内设备的进风温度如果高于 28°C单板温度很容易被推高建议从机房空调和机柜风道入手治理。电压项平时很少看但出现硬件类隐性故障时电压异常是很重要的排查入口。巡检时我不要求大家把每个电压值背下来只要大致了解当前输出与上次记录没有明显跳变即可。3. 转发层巡检接口状态、光模块与错误计数3.1 接口状态速览接口层的巡检任务最繁重因为一台接入交换机动辄 48 口每个口的物理状态、协议状态、流量、错误计数全查一遍工作量不小。好在华为设备提供了简明的汇总视图Huaweidisplay interface brief输出会列出所有接口的物理状态Physical、协议状态Protocol、入方向流量InUti、出方向流量OutUti、入方向错误InErrors和出方向错误OutErrors。**注意Physical up 和 Protocol up 是两回事。**物理 up 表示光/电链路通协议 up 表示链路层的协商也完成了。有些场景会出现物理 up 而协议 down——比如对端口被 shutdown、Trunk 端口和对端 Hybrid 端口 mismatch、或者 PPP 链路 LCP 没协商完成。巡检时遇到这类接口先别急着判断为故障看看是不是配置端本来就打算如此。另外看接口流量时别只盯着 up/down还要关注流量是否接近带宽上限。接入层百兆口长期跑在 95% 以上那问题就很尖锐了。display interface brief里的 InUti/OutUti 是最近 5 分钟的平均值作为快速筛子够用但要看更准的趋势建议后续拉取设备的性能统计数据。3.2 光模块健康收发光功率与诊断信息光纤链路是现代网络的主力承载光模块的状态往往决定了链路质量的底线。很多网工忽略光模块巡检觉得ping 通了就没事直到某天业务半夜中断才发现模块发光功率早就飘到临界值了。华为设备上查看光模块诊断信息的命令Huaweidisplay transceiver interface g0/0/1 verbose输出中会包含光模块的温度、电压、发送光功率TX Power、接收光功率RX Power以及各项阈值。注意不是所有模块都支持查询诊断信息——部分第三方兼容模块会返回 not support 或信息不完整这也是采购模块时需要注意的坑。判断标准核心看两件事收光功率不能太低否则接收灵敏度不足会丢包也不能过高否则接收端饱和也会产生误码。正常情况下接收光功率建议在 -15dBm 到 -1dBm 之间不同模块阈值不同发送光功率则看模块类型单模模块通常在 -3dBm 到 2dBm 左右。关键看数值是否在阈值范围内并且与上一次巡检记录相比没有快速衰减。3.3 接口错误计数别让隐藏问题积累面板状态全绿、光功率正常但网络偶尔还是卡去翻接口的错误计数。Huaweidisplay interface g0/0/1看输出末尾的 Input errors / Output errors 部分。CRC 错误计数持续增长基本可以判断物理链路质量有问题常见原因包括光模块老化、光纤弯曲半径过小、连接头污染、网线质量差电口场景。而 Output errors 过多则可能和对端设备的协商能力不匹配或者 buffer 不足有关。值得强调的是错误计数是累计值从设备启动开始一直累加。设备运行一年有几百个 CRC 错误并不罕见但关键是它是否在持续增长。建议巡检时记录错误计数基线两次巡检间比较增量。如果短时间内暴涨那就是真实故障的预警信号。干净的链路错误计数的增长速率应该非常平缓甚至停滞。4. 控制层巡检CPU、内存与日志里藏着的真相4.1 看得懂 CPU 和内存负载华为设备的 CPU 利用率不是简单一个数字就能概括的。display cpu-usage会显示整机 CPU 利用率和各任务的占用情况。Huaweidisplay cpu-usage查看输出时重点关注两个维度CPU 整机利用率是否持续高位运行。核心交换机平时 30%-50% 比较正常跑到 80% 以上并且持续数小时一定要查明原因是否有单个进程占用 CPU 过高。比如某个路由协议进程不停地收敛计算或者 SNMP 大量重复查询导致 CPU 被打满都是常见的异常场景。内存方面用Huaweidisplay memory-usage重点看内存利用率是否超阈值。华为 VRP 平台下内存碎片是长期运行设备的常见问题尤其某些产品版本存在内存越用越多的隐性泄漏。如果您发现设备的内存利用率在几个月内持续缓慢上升并且无法回落就要规划业务窗口重启验证了。这里有个实用小技巧巡检时不要只看当前内存利用率建议顺带命令Huaweidisplay memory-usage slot all多框设备或者模块化设备逐槽位查看内存使用能发现是哪块板卡在吃内存定位比整机视角快得多。4.2 日志复盘被大多数人忽略的黄金线索日志是整个巡检里最值得花时间看的内容但很多网工把display logbuffer当成出了问题再看的被动工具。其实日志里的很多信息反映的是早期的异常趋势。Huaweidisplay logbuffer这个命令默认显示最近保存的日志。比较实用的做法是结合时间范围过滤Huaweidisplay logbuffer level warning Huaweidisplay logbuffer | include Fault\|error\|down巡检时对日志内容的判读思路接口频繁 up/down日志里如果同一接口反复出现 Interface has turned to DOWN / UP 的记录说明链路存在不稳定因素。可能原因包括光模块漂移、对端设备重启、光纤收发器不稳定甚至是环路震荡引发的端口反复阻塞。认证失败记录出现 AAA 认证失败的日志要么有人密码输错要么存在暴力破解尝试属于安全类隐患需要关注。设备主动重启的记录如果日志中出现设备非计划重启的痕迹即使当前业务已经恢复正常也必须查明重启原因别让隐患带着走。日志的另外一个优势是它可以作为事后回溯的依据。日常巡检时把告警级和错误级的日志内容抄录归档写周报月报时这就是最有说服力的素材。4.3 全局告警概览如果是比较大的网络一台一台登录设备敲命令效率太低。此时可以用简洁的全局告警查询Huaweidisplay alarm active华为 VRP 系统会维护一个当前活动告警列表所有未消除的硬件和资源告警都会列在里面。通过这个命令能快速筛选出需要关注的设备。如果环境监控配置了 SNMP 告警推送配合网管平台会更高效但在没平台的环境里这条命令就是最直接的快速筛查工具。5. 路由与业务层面巡检邻居关系与路由表健康度5.1 OSPF 和 BGP 邻居网络稳定性的核心指标在中大型网络中路由协议的邻居关系状态是业务连续性的晴雨表。邻居关系一旦震荡整个业务平面都会抖三抖。巡检时我用得最多的是Huaweidisplay ospf peer Huaweidisplay bgp peerOSPF 邻居状态正常应该是 Full看到 2-Way 表示是 DR/BDR 关系下的正常状态广播网络中的非 DR 设备之间但如果有反复处于 Exstart/Exchange 状态的邻居那就是 MTU 不一致或 Hello 参数不匹配需要立即处理。BGP 邻居状态看 Established。如果看到 Connect、Active 或 Idle邻居关系没建立成功。BGP 邻居掉一次会引发大量路由撤销影响面可能很大所以日常巡检一定要盯住邻居状态的稳定性。我处理过一个大客户网络的故障就是由于光纤质量劣化导致 OSPF 邻居反复重建立每次重建立都带来一次路由震荡全网时延抖动持续飙升。如果当时巡检中早发现邻居状态记录里 Up/Down 次数在快速增加这个问题完全可以提前规避。5.2 路由表与 ARP 表异常排查路由条目的巡检并不需要把整张表都背下来重点是关注关键前缀和路由来源是否符合预期。Huaweidisplay ip routing-table建议重点关注是否有非预期路由窜入如多了一条指向不明下一跳的默认路由有可能是远端误配置注入核心业务网段的路由是否正常存在等价路由ECMP数量是否符合预期如果原来 2 条等价路由变成 1 条很可能是某条链路或协议邻居出了问题路由表条目总数与基线相比是否发生突变。一个路由表条目数量急剧增长可能是网络收到大量路由注入的早期信号。ARP 表在接入场景里也值得一看Huaweidisplay arp重点排查两类情况一是 ARP 表里出现大量未知名 MAC 地址可能与内网扫描或终端异常有关二是静态 ARP 条目被动态条目覆盖前提是设备上有静态 ARP 配置这通常意味着网络中出现了地址冲突或欺骗行为。6. 巡检报告的沉淀从命令输出到可执行的结论6.1 让每次巡检都有留痕我见过不少网工做巡检时信息全部停留在自己的脑子和记事本里设备一多时间一长全都忘了。其实巡检这件事不仅仅是为了当场发现问题更是为了积累数据、形成历史轨迹。没有历史数据的支撑后续做网络扩容、设备替换、故障回溯时都会缺了参照物。我的做法是每次巡检都按设备建立一份记录文件内容包括设备信息型号、版本、序列号、各硬件模块状态、关键接口状态、CPU/内存水位、告警日志摘要以及和上次巡检的差异对比。不用复杂的模板一个表格就能搞定。关键参数可以照着以下格式记录设备名上次巡检日期CPU 利用率内存利用率温度备注CORE-SW012025-12-0142%55%51°C无异常CORE-SW022025-12-0138%49%49°C电源模块正常6.2 关于命令行批量采集的一点经验如果你管理的华为设备数量比较多建议把常用巡检命令写到脚本里实现半自动采集。比如用 SecureCRT 或 Xshell 的日志功能配合 Python 的 netmiko / paramiko 库批量登录设备执行命令后统一收集输出。我自己的习惯是封装一层循环# 简单示例使用 netmiko 批量采集华为设备巡检信息 from netmiko import connect_handler device { device_type: huawei, ip: 192.168.10.1, username: netadmin, password: yourpassword, port: 22, } commands [ display version, display device, display cpu-usage, display memory-usage, display interface brief, display transceiver interface g0/0/1 verbose, ] conn connect_handler(**device) conn.enable() for cmd in commands: output conn.send_command(cmd) print(f {cmd} ) print(output) conn.disconnect()这段代码用于 SSH 连接华为设备并批量下发命令使用前需要安装 netmikopip install netmiko。安全起见建议代码里的密码等敏感信息通过环境变量或配置文件方式读取不要把明文密码直接写在脚本里。批量采集的产出是原始输出真正花时间的是解析和对比。我一般会把采集到的接口错误计数、光模块收光功率、CPU/内存使用率提取出来按设备维度做成趋势表。如果运维预算允许也可以搭一套简单的网管平台如华为 eSight 的轻量功能或开源 Zabbix 结合 SNMP把采集自动化巡检就变成每天自动出报告人工只需要关注告警项。6.3 巡检频率与巡检时机的建议频率没有一个万能答案取决于网络规模和设备的重要程度。我执行的节奏是这样的核心设备每天一次自动化采集SNMP 或脚本 每周一次人工深度巡检接入/汇聚设备每周一次自动化采集 每月一次人工巡检重大变更前后变更前必须做一次基线性巡检变更后做一次验证巡检确保没有引入新隐患。另外雷雨季节、夏季高温天气、机房空调维护期间建议加大温度、电源和告警日志的巡检频次。很多机房故障都发生在环境剧变的窗口期提前盯住环境指标能避开不少坑。7. 华为设备巡检中容易踩的坑最后集中聊几个我实际巡检过程中遇到的典型坑给大家做个参考。7.1 盲目执行命令导致业务割接现场翻车有些命令在巡检中看似无害但如果使用不当影响极大。比如display reset并不是巡检命令如果手误输入 reset华为设备通常会先让用户确认。但更危险的是在全局视图下敲了错误的undo命令。所以我个人的铁律是巡检时全部使用display开头的只读命令不带任何reset、clear、shutdown、undo这类可能改变设备状态的命令。就算是clear logbuffer这种看起来无害的操作也要经过业务窗口审批后再执行。7.2 看输出只看关键字忽略上下文比如查看接口错误计数时有些人只看有没有 error却忽略了对端口的协商模式是否从全双工变成了半双工。华为设备的接口出现大量 CRC 错误的同时往往伴随协商模式的改变只盯一个指标会漏判根因。巡检时要多个字段交叉印证单看有没有报错是远远不够的。7.3 对第三方模块的诊断数据过度信任华为设备查询光模块信息时第三方兼容模块的信息完整度参差不齐。有些模块的 DDM 数据温度、电压、收发光功率并不准确甚至完全不可读。这类模块一旦链路质量下降传感器读数是帮不上什么忙的只能靠错误计数和连通性测试辅助判断。因此采购光模块时优先选官方认证模块巡检负担会小很多。7.4 忽略设备时间同步巡检日志和告警判断都依赖设备时间的准确性。如果设备的系统时间和 NTP 服务器不同步那么日志的时间戳就会失真故障回溯时根本对不上号。每次巡检建议顺带确认Huaweidisplay clock如果发现时间偏差明显第一时间检查 NTP 配置Huaweidisplay ntp-service status这是一个特别容易被忽略的检查点但重要性完全不亚于硬件健康度——没有统一准确的时间跨设备分析故障就是在沙滩上盖楼。写在最后华为设备的巡检命令其实不难背真正的功夫在于理解每条命令输出的业务含义以及把当次数据和历史基线做对比的思维习惯。我现在巡检一台设备全程大概也就二十分钟但这二十分钟里看的每个字段、记录的每个数值都可能在未来的某次故障处理中派上大用场。我自己体会最深的一点是巡检这份工作做一次容易坚持做很难。但恰恰是这种重复且枯燥的动作把很多故障扼杀在爆发之前。如果你刚开始做网络运维建议从今天起为手头的每台设备建立一份巡检基线档案然后坚持执行至少一个季度你一定会感受到这套笨功夫带来的回报。
