搞网络的人都知道，华为路由器在设备维护和故障排查里出现频率极高，而"查看设备基本状态"几乎是每次上手的第一件事。不管你是刚拿到一台AR路由器准备开局，还是老设备跑着跑着业务出了状况，都得先问一句：这台设备现在到底什么状态？版本对不对、接口通不通、CPU有没有被打满、日志里有没有报错？这一套操作看似基础，但很多人习惯只敲一两条命令就下结论，结果漏掉了关键信息，排查方向直接跑偏。
这篇文章我按实际干活的路子，把华为路由器查看基本状态的常用命令、输出含义、判断标准和容易踩的坑都过一遍。内容偏实操，用的命令以VRP系统常见的display系列为主，适合经常接触华为设备的网络工程师，也适合刚入行、对着黑底白字界面还发怵的新人照着敲。涉及AR系列和部分盒式交换机通用的命令，基本都覆盖了。
1. 登录设备：查看状态前的第一道门槛
1.1 Console口登录与初始密码处理
华为路由器拿到手，第一件事是插Console线登录。Console口一般是设备前面板或后面板上的RJ45口，用专门的console线连电脑的串口或USB转串口，然后在终端软件里新建连接。常用参数是波特率9600、数据位8、停止位1、无校验、无流控，这个组合在华为设备上是默认值，不要乱改，改了大概率花屏或乱码。
登录后会遇到密码问题。新出厂的华为设备，有的版本第一次登录会提示设置密码，有的老版本默认空密码直接进用户视图。这里有个很多人问的点：华为路由器console密码忘了怎么办。如果你还能进用户视图，直接reset saved-configuration然后reboot，设备重启后配置清空，密码自然没了，但这属于暴力做法，会丢所有配置，生产设备慎用。如果连用户视图都进不去，只能通过BootROM菜单清除密码，不同版本的进入方式略有差别，一般是重启时按Ctrl+B，进去之后选择清空密码的选项，实在拿不准就先查对应型号的文档再操作。
登录成功后会看到<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 Admin@123 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和tracert：
ping -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 version | Version、Startup time |
| 硬件板卡状态 | display device | 板卡Status、Fan、Power |
| CPU利用率 | display cpu-usage | 5s/1min/5min平均利用率 |
| 内存利用率 | display memory-usage | 已用、可用、利用率 |
| 接口摘要状态 | display ip interface brief | Physical、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 arp | IP与MAC对应关系 |
| ACL规则与计数 | display acl all | 规则命中计数 |
按这个表逐项过一遍，一台设备的基本状态就摸得八九不离十了。我个人建议把常用的几条命令封装成一个巡检脚本或者记忆模板，每次巡检固定执行，输出保存留档，这样既能横向对比历史状态，又能快速发现异常趋势。设备状态查看这件事，本质上不是命令背得越多越好，而是每一句命令的输出你都能读懂、能判断、知道下一步往哪查。把基础打牢，后面配ACL、做MAC绑定、调路由策略，心里才有底。
