搞网络的人都知道华为路由器在设备维护和故障排查里出现频率极高而查看设备基本状态几乎是每次上手的第一件事。不管你是刚拿到一台AR路由器准备开局还是老设备跑着跑着业务出了状况都得先问一句这台设备现在到底什么状态版本对不对、接口通不通、CPU有没有被打满、日志里有没有报错这一套操作看似基础但很多人习惯只敲一两条命令就下结论结果漏掉了关键信息排查方向直接跑偏。这篇文章我按实际干活的路子把华为路由器查看基本状态的常用命令、输出含义、判断标准和容易踩的坑都过一遍。内容偏实操用的命令以VRP系统常见的display系列为主适合经常接触华为设备的网络工程师也适合刚入行、对着黑底白字界面还发怵的新人照着敲。涉及AR系列和部分盒式交换机通用的命令基本都覆盖了。1. 登录设备查看状态前的第一道门槛1.1 Console口登录与初始密码处理华为路由器拿到手第一件事是插Console线登录。Console口一般是设备前面板或后面板上的RJ45口用专门的console线连电脑的串口或USB转串口然后在终端软件里新建连接。常用参数是波特率9600、数据位8、停止位1、无校验、无流控这个组合在华为设备上是默认值不要乱改改了大概率花屏或乱码。登录后会遇到密码问题。新出厂的华为设备有的版本第一次登录会提示设置密码有的老版本默认空密码直接进用户视图。这里有个很多人问的点华为路由器console密码忘了怎么办。如果你还能进用户视图直接reset saved-configuration然后reboot设备重启后配置清空密码自然没了但这属于暴力做法会丢所有配置生产设备慎用。如果连用户视图都进不去只能通过BootROM菜单清除密码不同版本的进入方式略有差别一般是重启时按CtrlB进去之后选择清空密码的选项实在拿不准就先查对应型号的文档再操作。登录成功后会看到Huawei这种尖括号提示符这叫用户视图只能看不能改。要进入配置视图先敲system-view提示符会变成[Huawei]这时候才能改配置。我见过不少新手在用户视图里敲配置命令报错Unrecognized command还以为设备坏了其实就是没进对视图。1.2 Telnet/SSH远程登录准备生产环境里设备基本都在机房不可能每次都抱笔记本去Console口所以远程登录是常态。华为路由器默认没开Telnet和SSH服务需要先用Console口进设备配置VTY虚拟终端。配置远程登录的步骤不难核心是这几条system-view telnet server enable user-interface vty 0 4 authentication-mode aaa quit aaa local-user admin password cipher Admin123 local-user admin service-type telnet local-user admin privilege level 15 quitSSH类似但需要先生成密钥system-view rsa local-key-pair create stelnet server enable ssh user admin authentication-type password这里我提醒一句远程登录的密码复杂度别偷懒。设备暴露在办公室里还好如果nas上跳板机直连或者有公网映射弱密码就是引狼入室。配完记得用display telnet server status或display ssh server status确认服务真的起来了别配完以为行了远程怎么都连不上才发现服务没开。另外多说一句有些型号的老设备默认VTY只允许Console登录就算配了aaa也会连不上这时候检查user-interface vty 0 4下有没有protocol inbound相关配置必要时明确指定protocol inbound telnet或protocol inbound ssh。2. 设备级状态看版本、看硬件、看资源2.1 display version最简单的信息入口登录设备后我习惯第一条命令永远敲display version。这条命令输出设备型号、软件版本、启动文件、运行时长、设备序列号这些最基础的信息。别小看它判断设备是否异常重启、版本是否符合要求、补丁有没有打全靠它。命令输出里几个关键字段要注意Version: 软件版本号比如Version 8.180后面还有Release版本信息处理问题时报给华为支持就是报这个Startup time: 设备启动时间结合当前时间就能算出运行时长。如果显示设备刚启动几分钟而你没重启过那就要警惕是否异常重启了System uptime: 直接告诉你跑了多久我处理过一起案例客户反馈网络半夜断了一次早上看设备还能用但我一看display version里的启动时间发现设备在凌晨3点重启过再配合日志定位到是电源模块电压波动触发的重启。如果没有这一步光看接口状态根本发现不了问题。顺便说下有人分不清display version和display device前者偏软件和系统信息后者偏硬件健康两者结合看才算完整的设备体检。2.2 display device硬件健康检查display device这条命令列出设备各槽位的板卡型号、状态、在线/离线情况。对于AR系列这种一体化的设备输出相对简单主要看板卡状态是不是Normal。对于框式设备比如CE系列就要仔细看主控板、业务板的在位状态如果有板卡显示Offline或Fault那就是大问题了。这里我补充一个判断标准display device里Status字段为Normal或Present表示在位且正常如果出现Fault、Failed、Offline对应槽位的业务基本都会受影响。检查完板卡状态还可以配合display device power和display device fan看电源和风扇。很多人忽略了风扇和电源的检查但这两项恰恰是设备稳定运行的基石。机房空调坏了设备风扇狂转如果风扇转速异常或者干脆停转设备过热会降噪甚至保护性重启。我建议在巡检脚本里把这三条命令都加上display device、display device power、display device fan每次巡检扫一眼比事后救火强太多。2.3 CPU与内存资源占用要看清设备卡不卡、转发有没有受影响CPU和内存最直观。华为设备查看资源占用有两条常用命令display cpu-usage display memory-usagedisplay cpu-usage会输出CPU在5秒、1分钟、5分钟内的平均利用率还会列出占用CPU最高的几个进程。如果你发现CPU利用率长期超过80%甚至90%而且不是突发流量造成的就要看是哪个进程在吃CPU。常见CPU飙升的原因有几种路由协议频繁计算、日志量过大导致大量打印、遭受网络扫描或攻击、配置了过多的策略路由或ACL在软件转发路径上生效。定位思路是先看进程名再结合display logbuffer和接口流量确认诱因。display memory-usage则显示内存总容量、已用、可用和利用率。华为设备内存利用率长期高企不一定立刻出问题但如果伴随内存碎片或者内存泄漏设备会越来越卡最后可能连Console都登录不了。遇到内存居高不下的情况除了看当前占用还可以用display memory-usage verbose看细分内存池或者display process memory按进程排查。我自己的习惯是给CPU和内存设置一个心理红线CPU连续5分钟超过70%就要查原因内存超过85%就要规划重启窗口。当然不同型号硬件规格不一样这个阈值只能作为参考大规格设备和小规格设备的承受能力差别很大。3. 接口状态网络通不通的答案都在这3.1 display ip interface brief一眼扫完所有接口如果要快速判断所有接口的物理状态和协议状态display ip interface brief是效率最高的命令没有之一。display ip interface brief输出会列出接口名称、IP地址、物理状态Physical、协议状态Protocol。物理状态UP表示网线连接正常、对端设备也正常协议状态UP表示三层协议协商成功。两个状态要分开看Physical UP Protocol UP接口正常能收发路由协议报文Physical UP Protocol DOWN物理链路没问题但协议协商失败比如链路协议不匹配、对端没配置对应协议Physical DOWN Protocol DOWN物理链路断了查网线、光模块、对端设备我见过有人看到接口状态DOWN就急着换线结果查了半天发现是光模块型号不匹配或者光衰过大。所以接口DOWN不要只看状态还要用下面的display interface看错误计数和光模块信息。3.2 display interface接口细节全解析当display ip interface brief显示接口异常时就要深入到单接口去看细节了。display interface GigabitEthernet0/0/0输出信息很多我按排查优先级说几个重点。第一个是接口的物理状态和协议状态这里会给出更具体的说明。第二个是速率和双工模式注意看是不是协商到了预期速率比如千兆口只协商到百兆链路质量可能有问题。第三个是输入输出错误计数里面分CRC错误、 runt、giant、碰撞等。CRC错误如果持续增长基本可以断定链路质量差常见原因是网线不合格、距离过长、光模块光衰大、电磁干扰强。Runts和Giants则是报文长度异常可能对端配置了不同的MTU或是硬件故障。还有一个细节容易被忽略就是接口的Last physical up/down time它记录了接口最近一次状态变化的时间点。排查间歇性断网时这个字段非常有用配合日志能还原出故障发生的精确时刻。查看光模块的话用display transceiver interface GigabitEthernet0/0/0 verbose看光功率、温度、电压是不是在正常范围。光模块的光功率低于阈值虽然链路还通但随时可能断属于典型的隐患。我巡检时只要看到光功率接近警戒值就会通知客户准备更换这比断网后再处理从容得多。3.3 接口描述与连通性验证接口描述这个习惯我建议所有人都养成。给接口加上描述半年后再看配置你会感谢当初的自己。system-view interface GigabitEthernet0/0/0 description To-Core-SW-Core01描述尽量采用统一格式比如连接设备-位置-用途不要随便写link或test这种没信息量的词。查看所有接口描述用display interface description输出包括接口编号、状态和描述信息做文档核对时非常顺手。接口状态看完了还要验证实际转发是否正常。常用的是ping和tracertping -c 100 -s 1400 10.0.0.1带参数ping可以测试丢包率和时延。-c指定报文数量-s指定报文大小用1400字节的包测能提前发现MTU协商问题因为很多MTU故障在64字节小包ping时根本测不出来大包一打就现出原形。tracert则用于确认路径经过哪些节点定位是哪一个跳出了问题。4. 配置与运行状态确认设备实际在跑什么4.1 display current-configuration核对配置的正确姿势有时候设备看起来状态正常但业务就是不通这时候就要怀疑配置和实际预期不一致。查看当前生效配置用display current-configuration输出会很长纯看配置容易看花眼建议用display current-configuration | include做过滤。比如想确认ACL配置就执行display current-configuration | include acl想看接口IP就过滤ip address。华为设备支持|重定向和正则用好了效率翻倍。这里插一句很多人找ACL配置文件时会直接敲display acl all这也是一条有效命令能看到所有ACL的规则明细。查看配置时两种方式各有侧重display current-configuration | include acl快display acl all能看到规则的匹配计数后者更适合排查ACL是否生效。配置这块还有一个坑设备里可能存在配置了但没生效的情况原因可能是全局使能没打开也可能是display current-configuration里根本没有这条配置。比如你配了ACL但没在接口下调用ACL就是一堆废规则。调用关系要通过display traffic-filter applied-record或直接在接口下看display this确认。4.2 display logbuffer日志里藏着真相设备发生的问题几乎都会在日志里留下痕迹。查看日志缓冲区的命令是display logbuffer日志缓冲区记录了设备运行过程中的系统日志包括接口up/down、登录记录、配置变更、协议事件等。信息等级从Emergency到Debug日常排查重点关注Error及以上等级的日志。日志信息量大了之后要会过滤比如只看某个时间段或者某个模块的日志display logbuffer level error display logbuffer | include GigabitEthernet0/0/0遇到设备重启最优先查看的是日志里有没有记录重启原因。华为设备重启时一般会记录reboot相关日志或异常信息配合display version里的启动时间基本能还原重启是人为还是设备自身触发的。日志缓冲区容量有限老日志会被新日志覆盖所以发现重大问题后尽快导出日志别等缓冲满了才发现关键信息已经被冲掉。导出可以用save logfile命令把日志保存到存储介质里再通过FTP或TFTP拉出来。4.3 时间与启动信息容易被忽略的细节设备系统时间不对是个很隐蔽的问题会影响日志时间戳、证书有效期校验和周期任务的执行。查看当前时间display clock比较设备时间与标准时间如果偏差大要配置NTP同步。华为设备NTP配置不复杂system-view ntp-service unicast-server 192.168.1.10配置完用display ntp-service status确认同步状态看到synchronized就说明时间同步成功。没有NTP环境的话只能手动校准但手动校准治标不治本时间还会漂正规机房一定要有NTP源。启动信息也是容易被忽略的一项display startup这条命令输出设备本次启动用的系统软件、配置文件、补丁文件。重点看配置文件的路径和名称对不对如果配置文件名不对或者路径不存在设备启动时会加载不到配置等于裸奔。我遇到过设备重启后配置丢了大半查到最后就是启动配置文件路径错误导致的。5. 状态查看的常见误区和排障实录5.1 常见误判与规避状态查看看起来简单但我在实际工作里见过不少误判挑几个典型的说说。第一个误判把接口物理UP当成链路完全健康。物理UP只能说明网线或光路通但如果CRC错误在持续增长链路质量已经很差了报文在物理层就在丢。这时候业务表现为偶发卡顿、重传率高ping测试却往往通过。处理办法是定期查看display interface里的错误计数增长趋势比瞬时值更有说服力。第二个误判CPU高就直接扣帽子说被攻击。CPU高要先看进程华为设备的display cpu-usage会列出Top进程也许只是某一个路由协议在频繁计算或者大量日志打印占用了IO。我曾经遇到一台设备CPU飙到90%排查半天发现是日志量太大导致CPU忙于打印日志关掉调试日志后CPU立刻回落根本不是网络攻击。第三个误判配置看一半就下结论。排查ACL不放行问题时有人只看display acl all没看接口下是否调用了这个ACL也没看ACL规则的匹配顺序。ACL是顺序匹配的前面的deny规则可能已经把流量拦了后面的permit根本没机会执行。正确做法是规则、调用、匹配计数三个点全看完再下结论。5.2 排障场景实录讲一个我处理过的真实场景。某公司办公室反馈上网速度变慢部分终端频繁掉线。我先登录出口路由器执行display ip interface brief发现所有接口都是UP物理和协议状态正常。再看display interface发现接入侧接口Input CRC错误在不断增长一下子把方向定位到了链路质量上。顺着这个方向检查发现该接口连接的是楼层弱电间的接入交换机中间线路有一段是现场后接的网线线径不达标还跟强电线路捆扎在一起。重新敷设网线、分开强弱电走线后CRC错误停止增长网络恢复正常。整个过程里如果只看display ip interface brief根本定位不到问题就是靠深入接口细节才找到根因。另一个场景是设备突然重启客户一口咬定是设备质量问题。我登录后先看display version确认重启时间再看display logbuffer找重启前后日志结果发现重启前有电源模块的电压异常告警结合机房巡检记录确认是当天空调故障导致机房温度过高设备电源触发保护重启。这个案例说明设备基本状态的每一项信息都可能成为定位根因的钥匙别忽略任何一个字段。5.3 与ACL、MAC绑定等配置联动的检查思路有些朋友配置了ACL或MAC与IP绑定后发现业务异常第一反应就是重新配置其实先看状态就能定位大部分问题。ACL场景下查看基本状态时要关注规则匹配次数。用display acl 3000看到规则计数器在增长说明流量确实命中了该规则计数不增长则说明流量可能根本没走到这条ACL或者被更靠前的规则处理掉了。MAC与IP绑定场景也是类似思路。配置绑定后终端上不了网先查接口状态和ARP表项display arp | include 192.168.1.10看IP对应的MAC是否符合绑定配置。如果ARP表里MAC和实际终端MAC不一致说明存在非法设备抢占IP或者终端曾经更换过网卡。这类问题靠查看基本状态就能判断不需要动配置。5.4 状态查看命令汇总与巡检建议最后整理一份常用状态查看命令速查表方便大家在现场快速查阅查看目标命令关键输出软件版本与启动时间display versionVersion、Startup time硬件板卡状态display device板卡Status、Fan、PowerCPU利用率display cpu-usage5s/1min/5min平均利用率内存利用率display memory-usage已用、可用、利用率接口摘要状态display ip interface briefPhysical、Protocol单接口细节display interface GigabitEthernet0/0/0错误计数、速率、双工接口描述display interface description接口描述信息光模块状态display transceiver interface GigabitEthernet0/0/0 verbose光功率、温度当前配置display current-configuration全部生效配置日志缓冲区display logbuffer系统日志系统时间display clock当前时间启动信息display startup启动文件、配置文件ARP表项display arpIP与MAC对应关系ACL规则与计数display acl all规则命中计数按这个表逐项过一遍一台设备的基本状态就摸得八九不离十了。我个人建议把常用的几条命令封装成一个巡检脚本或者记忆模板每次巡检固定执行输出保存留档这样既能横向对比历史状态又能快速发现异常趋势。设备状态查看这件事本质上不是命令背得越多越好而是每一句命令的输出你都能读懂、能判断、知道下一步往哪查。把基础打牢后面配ACL、做MAC绑定、调路由策略心里才有底。