1. 查状态之前先搞明白“设备基本状态”到底包含什么接手一台华为路由器不管是刚上架的AR系列还是已经默默跑了两三年、突然被领导问一句“设备状态怎么样”的老家伙很多人的第一反应是ping两下网关、打开管理页面看一眼然后回一句“通着呢”。但“通着”只是业务层面能用离真正掌握设备基本状态还差得很远——CPU是不是已经悄悄爬到95%内存还剩多少单板的温度和风扇是否正常接口虽然UP但有没有在持续产生CRC错包这些信息统统不会出现在一次ping的结果里。这篇文章不聊复杂的业务配置只围绕一个核心问题如何在华为路由器上把设备基本状态彻底摸清楚。适用对象是日常维护华为AR系列等运行VRP系统的企业路由器的工程师以及刚入行、想把“查看状态”这组基本功打扎实的朋友。全文所有命令都基于命令行界面先讲思路再给命令最后给一份可以直接抄走的巡检清单。1.1 设备状态不是单一指标而是三层结构我的习惯是把“设备基本状态”拆成三层来看。第一层是硬件健康包括单板是否在线注册、电源模块是否正常、风扇转速和温度是否在合理范围这是设备的“身体指标”第二层是资源水位包括CPU使用率、内存使用率这是设备的“续航能力”第三层是链路与运行记录包括接口物理和协议状态、光模块收发光功率、日志和告警这是设备的“工作情况”。实际工作中绝大多数故障都能先归到这三层中的某一层。所以我平时巡检也按这个顺序来先看硬件会不会坏再看资源够不够用最后看链路和日志有没有异常。按这个顺序查下来的好处是思路不会乱一个环节一个环节排除最后总能定位到问题。1.2 命令作用范围先确认你手里的华为路由是哪种华为路由器大体分两类。一类是家用和中小办公的消费级路由器比如常见的AX系列、Q系列通过浏览器登录管理页面就能看到“运行状态”没有命令行界面本文不适用。另一类是企业级路由器像AR系列、NE系列以及部分运营商级设备运行的是VRP操作系统这也是绝大多数“华为路由器命令行怎么查状态”相关问题的真实场景。本文的命令以AR系列加VRP系统为主NE、CE等平台的命令名称略有差异但排查思路完全通用。如果你在某台设备上敲命令提示“未找到”别慌输入?或者display ?看看当前系统支持哪些相近命令基本都能找到对应项。另外下面所有命令在普通视图提示符是AR下直接输入即可不需要先进系统视图。2. 设备的“身份证”和服役时长display version先打底2.1 一次回显能读出多少信息无论遇到什么华为路由器我做的第一件事永远是执行display version。这条命令就像设备的身份证和体检封面页一次回显就能告诉你设备型号、VRP软件版本、补丁版本以及最关键的上电运行时长。典型回显大致长这样AR display version Huawei Versatile Routing Platform Software VRP (R) software, Version 8.180 (AR6000 V300R023C00SPC100) HUAWEI AR6280 uptime is 120 days, 3 hours, 45 minutes注意看两点。第一型号和软件版本。不同版本之间的命令集、默认行为和已知问题都不一样。有人遇到display transceiver没反应排查了半天才发现是设备软件版本太老、光模块相关命令集不完整。所以处理任何问题之前先把版本记录清楚这是后续所有排查的基准线。第二补丁版本信息。有些项目对补丁有严格管理要求版本号里带的SPC字段就是补丁版本标识判断设备是否“落后”全靠它。2.2 从uptime看异常重启一个太容易被忽略的细节uptime is 120 days这行很多人扫一眼就过去了但从排障角度它是特别重要的时间线索。假设你发现一台AR2220显示uptime is 3 days但设备理论上已经稳定运行了大半年这说明设备在3天前发生过一次重启。重启原因可能是机房掉电、设备热复位、软件异常自动重启甚至是被强制断电。这时候就应该立刻配合后面的display logbuffer查看重启前后有没有相关日志再检查电源供电是否稳定。如果确认最近没有人为操作但uptime突然变短那就要当成隐形故障来查而不是简单一句“能通就行”带过。我遇到过一台分支路由器频繁在凌晨重启uptime每次都重新计数业务断断续续。查了一圈才发现是楼层插排老化夜间电压波动导致设备反复下电上电。如果当时不看uptime这个问题可能永远会被当成“偶尔断网”。顺带说一下设备系统时间同样重要执行display clock看看当前时间是否准确。如果时间和真实世界差得远后面看日志、对告警时间线会全部错位这一点在第6节我会再展开。3. 硬件体检单板、温度、电源、风扇逐个过一遍3.1 display device先确认所有硬件都在位硬件层最先看的是单板状态命令是display device。回显会列出各槽位的单板信息包括槽位号、单板类型、是否在线Online、是否完成注册Register、工作状态Status以及主备角色Master/Slave。对多数AR路由器来说结果里应该只有一块主控板State为Normal、Role为Master。如果你看到Online状态异常、Register是Unregistered或者角色信息缺失基本可以断定硬件注册出了问题。这种设备往往连正常重启都做不完整需要尽快联系售后处理。另外如果要做售后或者固定资产盘点序列号也是必须的。VRP下看序列号的命令比较多常用的是display esn直接显示设备ESN部分版本还支持display device manuinfo查看更完整的生产信息。命令不存在时输入display ?找带esn或manuinfo的项即可。报修、换设备、申请授权时序列号都是必备素材平时养成记录习惯能少跑很多冤枉路。3.2 温度、电源、风扇用回显里的阈值说话硬件健康的老三样是温度、电源和风扇对应命令分别是display temperature、display power、display fan。有些型号是display temperature all敲一下display temperature ?就知道当前系统支持哪种写法部分平台还有display health汇总显示这些信息同样以设备实际支持为准。温度输出通常会显示当前温度和历史最高温度有的版本还会直接给出过温告警阈值。很多人看到“温度60多度”就紧张其实不用拿网上的“标准值”硬套——每款设备的传感器位置不同回显里自带阈值只要明确低于阈值并且温度没有出现持续单边上涨的趋势就属于可接受范围。真正要警惕的是“缓慢爬坡”的状态。比如温度从45度一周内慢慢涨到60度大概率是风扇堵灰、风道堵塞或者机房空调异常。电源和风扇主要看State字段正常应该是Normal。机房环境如果不干净风扇故障往往先于温度异常出现而且故障初期系统不一定马上告警。所以巡检时别只盯着温度风扇状态和转速也要一起扫一眼。3.3 硬件告警处理的实操建议如果display power或display fan里出现了Fault、Abnormal先不要急着下结论、更不要直接拔插硬件。我的建议分三步走第一步先确认当前所有电源模块和风扇确实在位排除误报第二步评估设备是否有宕机或重启风险如果温度已经接近阈值优先考虑降低负载或准备更换窗口第三步收集display logbuffer和display trapbuffer里的告警记录连同display version、display esn一起发给售后报修时这些信息缺一不可。这里有个容易踩的坑很多设备支持电源和风扇热插拔更换时一定要看面板指示灯和命令行状态不要凭感觉拔插。有一次同事在设备运行状态下更换风扇因为没有确认新旧风扇的型号和接口方向装回去之后风扇实际没转温度一路飙到接近阈值差点把整台设备带崩。更换类操作任何一次都要以状态回显确认到位不能只凭“装上了”来判断。4. CPU和内存资源水位决定设备“喘不喘得过气”4.1 display cpu-usage看趋势而不是看瞬间值资源层的两条核心命令是display cpu-usage和display memory-usage。CPU命令的典型输出会给出最近5秒、最近1分钟、最近5分钟的使用率有些版本还会附带每个CPU核的占用情况。看CPU一定要学会看趋势而不是看某一个瞬间值。业务高峰时段CPU短暂冲到70%、80%并不罕见只要1分钟和5分钟值能回落就不必恐慌但如果5秒值、1分钟值、5分钟值同时居高不下说明CPU已经长时间满负荷这时就要先看流量再往下查。瞬时高是一回事持续高是另一回事这两种状态的排查方向完全不同。4.2 CPU居高不下时往哪几个方向查CPU持续高的常见原因按我遇到的频率排序有四个接口大流量、日志刷屏、路由震荡、异常进程。接口大流量用display interface看各接口的速率就能定位是哪个口在大量收发日志刷屏则是系统持续输出相同日志、在设备日志缓冲区里滚动覆盖这种往往伴随软件或协议异常路由震荡表现为接口状态反复UP/DOWN路由表频繁变化异常进程在部分VRP版本上可以用display process cpu查看但不同型号支持情况不同命令不存在就用display cpu-usage配合display logbuffer判断是哪个模块在报错。CPU高本身不是故障CPU高背后的原因才是。曾经有一台AR设备CPU长期90%以上所有人盯着CPU查了很久最后发现是下联交换机有人手动敲错网段配置导致设备不断收到大量无法处理的报文CPU全消耗在处理无效流量上。改掉错误配置后CPU马上回落。所以CPU告警只是一个引子真正要做的是顺藤摸瓜找源头而不是在数值本身上面死磕。4.3 内存“涨上去没掉下来”才是问题内存使用率用display memory-usage查看会给出总内存、已用内存和使用率。内存问题的判断逻辑和CPU不太一样我比较关注的是“变化趋势是否稳定”而不是“数值是不是有点高”。VRP系统的内存使用率天然不低很多协议状态和转发表项都要驻留在内存里看到50%、60%的占用不用紧张。但如果连续几天记录下来发现使用率只涨不跌、缓慢持续爬升那就要警惕内存泄漏了。内存泄漏到一定程度设备会变得无法登录、无法保存配置最终只能重启恢复而重启之后如果问题依旧说明泄漏点一直存在必须通过版本升级或日志分析解决。这里分享一个很实用的核查习惯每周在同一时间执行一次display memory-usage并记录数值只记一个数字就行连记几周内存趋势就一目了然。另外顺便执行display users看一下当前登录会话确认没有异常账号长时间挂机这也是设备状态的一部分很多安全隐患恰恰是从登录会话状态开始暴露的。5. 接口链路从“通不通”看到“稳不稳”5.1 速览接口两条brief命令各有用处接口层我看两个速览命令。display interface brief侧重物理和协议状态重点关注PHY和Protocol两列display ip interface brief则把所有配置了IP的接口和IP地址列出来适合核对接口IP、检查哪些接口物理UP但协议DOWN或者哪些接口配了IP却没有启用。用这两条命令有个顺序上的经验先跑display interface brief排除物理层问题再跑display ip interface brief看三层配置是否和预期一致。如果物理UP、协议DOWN通常是协商方式、封装类型或Router-id等三层因素问题如果物理DOWN直接往线缆、光模块和对端设备方向查协议层面再怎么折腾也没用。这两条命令输出都很短适合作为接口排查的第一拳。5.2 详细查看误码和错包藏在哪里速览命令能看出通不通但看不出稳不稳。想了解链路质量就要对具体接口执行display interface GigabitEthernet0/0/0这类详细查看命令。回显里除了速率、双工模式、最近5分钟输入输出速率还有大量计数器信息输入输出的总字节数、包数、错误包数、CRC错误数、丢包数等。看这些计数器重点不是“现在有没有错包”。任何链路在长期运行中都有一定数量的错误包真正危险的是“错误包持续增长”。判断方法很简单间隔1分钟执行两次同样的命令对比CRC错误和error计数是否在增加。如果数字只增不减说明链路在持续产生错误常见原因包括光模块衰减、线路干扰、双工不匹配、网线老化。单纯一次看到几个错包就急着换线反而容易误判要让数据说话两次对比是最朴素的验证手段。5.3 光模块状态收光功率要跟阈值比接口如果走的是光模块状态查看里还有一个非常高频的动作看收发光功率。命令是display transceiver interface GigabitEthernet0/0/0输出会给出光模块类型、波长、温度、电压、偏置电流、TX发送光功率、RX接收光功率以及功率阈值等信息。在CE等部分平台上也可以用display optical-infoAR系列一般以display transceiver interface为准。看收发光功率的核心原则是不要拿网上流传的“收光-20dBm就是不行”这类通用标准硬套因为不同型号模块的接收灵敏度和阈值差异很大。正确做法是直接看回显里给出的最大最小阈值对比当前RX功率是否接近阈值下限。接近下限说明链路裕量已经很小一旦尾纤再脏一点、法兰盘再松动一点丢包就会开始出现。光模块状态查看的另一个价值是预判——它能在链路完全断掉之前提醒你风险。5.4 一个典型的“接口看着正常但业务丢包”案例说一个我处理过的比较典型的案例帮大家把上面几节串起来。某分支机构的设备外联接口PHY和Protocol都是UPping网关也通但业务侧反馈间歇性丢包。用display interface brief看一切正常直到对具体接口执行详细查看才发现CRC错误计数在持续增长再查光模块RX接收光功率已经非常接近阈值下限。最后排查下来是机房施工时尾纤被弯折加上法兰盘松动光损变大但还没完全断链所以物理状态始终显示UP。把尾纤重新布放、重新插紧法兰盘之后RX功率恢复了CRC计数也不再增长。这个案例的启示是接口UP、协议UP、ping通只是业务的及格线线上能查到误码和收光变化的痕迹才是链路真正健康的依据。6. 让设备自己开口日志、告警与全量诊断6.1 logbuffer与trapbuffer查异常的入口状态查看的最后一层是让设备自己“开口说话”这里有三条命令display logbuffer、display trapbuffer、display diagnostic-information。display logbuffer读取的是设备内存中的日志缓冲区包含启动信息、接口状态变化、协议事件、用户操作等。缓冲区大小有限默认条数比较浅过久的历史会被冲掉所以查日志要有时效意识。回显内容多的时候可以用管道过滤比如display logbuffer | include ERROR只查看带ERROR关键字的日志也可以按接口名过滤快速缩小范围。display trapbuffer读的是Trap告警缓冲区可以理解为设备主动上报的告警集合。部分平台还支持display alarm active查看当前活动的告警命令不存在就用display trapbuffer替代。这两条命令在故障排查和日常巡检中都非常实用很多隐蔽问题——比如风扇转速异常、光模块劣化、某协议状态反复切换——都会先在日志或告警里露出苗头。提醒一句如果设备时间没同步日志和告警的时间线就会失真甚至出现“告警时间在未来”的诡异现象。每次排查前先执行display clock确认时间有必要时配合NTP同步这是很多人容易漏掉的步骤。6.2 时间不同步会把排查带偏时间不同步这事我在第2节提过一次这里值得单独展开。曾经有台设备告警显示凌晨3点接口频繁UP/DOWN但现场人员坚称那时候没人动设备。后来查display clock才发现设备时间比真实时间慢了7个小时所谓凌晨3点的事件实际发生在上午10点那正是机房有正常业务调整的时间段。顺着这个思路重新翻日志问题立刻水落石出。如果当时盲目相信设备时间整个排查方向都会跑偏。所以我把display clock列在状态查看的固定动作里每次和display version一起执行。有人会问时间同步不是配置项吗确实是但配置是否生效必须靠查看命令确认配置和查看永远是两回事这一点在运维里怎么强调都不过分。6.3 display diagnostic-information一次打包所有状态最后一条命令按下去要慎重但也最实用display diagnostic-information。这条命令会把设备当前的配置、版本、单板状态、CPU内存、接口状态、路由表、日志等几乎所有信息一次性输出堪称“全量快照”。它适合三种场景一是向设备厂商技术支持开单报障时随工单提供全量诊断信息二是重大变更前给设备留底万一变更出问题可以对比变更前后差异三是故障发生时快速把现场完整保留下来而不是一条条命令零敲碎打地抓回显。不过它也有代价——输出内容非常多执行时对设备CPU有瞬时消耗所以生产设备尽量选业务低峰期执行。保存输出时可以使用终端软件的日志记录功能比如Xshell、SecureCRT的Logging也可以把回显直接复制到纯文本文件里。顺便提一句如果你都操作不进设备了“查看状态”就无从谈起先解决console口登录或远程登录的接入问题再回到这篇命令体系里来。7. 可以直接抄走的巡检命令清单7.1 一张表说清所有命令每次状态查看都是一次轻量巡检我习惯把命令按用途分成五组。为了让你直接抄作业我把本文提到的所有命令汇总成下表检查维度命令重点看什么身份版本display version型号、软件版本、补丁、运行时长时间校验display clock系统时间是否准确单板硬件display device单板Online、Register、Status、Role序列号display esn/display device manuinfo序列号售后与报修用硬件健康display temperature当前温度、历史最高温度、阈值硬件健康display power电源模块State是否Normal硬件健康display fan风扇State及转速是否正常资源水位display cpu-usage5秒/1分钟/5分钟使用率趋势资源水位display memory-usage总内存、已用、使用率关注趋势登录会话display users当前在线用户是否有异常占用接口链路display interface briefPHY、Protocol状态速览接口链路display ip interface brief接口IP配置与三层状态接口链路display interface 接口名速率、错误计数、CRC是否增长光模块display transceiver interface 接口名TX/RX功率、温度、阈值日志告警display logbuffer内存日志用include过滤日志告警display trapbufferTrap告警记录全量快照display diagnostic-information一次输出几乎全部状态7.2 我的固定巡检三步法有了命令还得有个执行节奏。我的固定做法是三步。第一步看“稳不稳”执行display version、display clock、display device、display temperature、display power、display fan确认硬件状态和时间没问题。第二步看“够不够”执行display cpu-usage、display memory-usage、display users确认资源水位健康和登录会话安全。第三步看“通不通、稳不稳”执行display interface brief、display ip interface brief再对重点接口和光模块做详细查看最后翻display logbuffer和display trapbuffer收尾。这个流程在什么时候用新设备上线、版本升级前、开故障工单前以及每周例行巡检我都会完整跑一遍。做ACL、MAC与IP绑定这类配置变更之前我同样会先花一分钟快速跑个状态确认CPU内存正常、接口状态稳定再动配置。因为配置变更本身就带风险如果设备已经带病运行这时候去动它只会把问题放大。说句实在话查状态这件事看着基础却是整个运维工作里最值钱的能力之一。扎实掌握这套命令不是让你在设备前面做个“人肉监控”而是让你在任何情况下都能快速回答三个问题设备身体怎么样、资源还够不够跑、链路和运行记录里有没有隐患。我自己的习惯是每次巡检后把几条关键回显留个档哪怕只是简单截屏存进文件夹积累一段时间后回看你会发现设备状态的趋势全都在你手里。下次不管谁问起“这台华为路由器状态怎么样”你都能理直气壮地给出一个完整的答案。