1. 华为路由器上手第一步先把这个设备的“户口本”翻一遍刚拿到一台华为路由器很多人第一反应就是赶紧把业务配置敲上去——VLAN、OSPF、NAT一顿操作猛如虎。但我在实际项目里栽过好几次跟头之后慢慢形成了一个改不掉的习惯不管这台设备是全新开箱的还是从仓库翻出来的二手机先别急着配业务把设备基本状态摸清楚再说。因为后面所有排障动作都要拿“设备正常时的状态”当参照物。你连设备是什么型号、跑了什么版本、开机多久了都不知道遇到问题就只能瞎猜。查看设备基本状态的第一步就是登进去之后先执行这条命令display version这是思科、华为、锐捷这些主流厂商都通用的习惯。华为设备上这条命令会返回一大堆信息但最关键的几个字段你得会读Huawei Versatile Routing Platform Software VRP (R) software, Version 8.180 (AR2220 V200R010C00SPC600) Copyright (C) 2011-2020 Huawei Technologies Co., Ltd. HUAWEI AR2220 Router uptime is 148 days, 3 hours, 12 minutes这里的信息量其实很大。Version 8.180是 VRP 平台的大版本号V200R010C00SPC600才是这个设备具体的软件版本。SPC 后面的数字表示补丁级别SPC600 意味着已经打了 600 个补丁这个信息在后续判断“设备是不是因为软件版本 bug 才出问题”时非常关键。开机时间uptime is 148 days能告诉你设备是不是最近重启过。比如某天下午网络闪断你怀疑是路由器重启导致的一看 uptime 只有 20 分钟那基本可以确定就是重启过接下来就去看重启原因而不是去排查链路。设备型号的确认也很重要。很多远程运维的场景里你人在办公室设备在几百公里外的机房单靠记忆你会把 AR2220 和 AR2220E 搞混这两个型号的接口规格和转发性能差异很大配置思路完全不同。display version跑一遍型号、序列号、软件版本一目了然。顺带说一句很多人在拿到设备后会顺手把系统时间校一遍但display version里的 uptime 计算是从设备启动那一刻开始的你改了系统时间不会影响它的准确性这一点可以放心用。再补一条命令display esn直接查看设备的序列号ESN。这个东西平时没用但等你联系厂商开 case 或者做资产盘点的时候ESN 就是设备的身份证号报错、换配件全靠它。不用翻机身上的贴纸——命令行里就能查尤其是设备挂在机柜高层人根本够不着机身标签的时候这条命令是救命稻草。如果你拿到的是一台已经跑过的设备不知道上次被谁改过什么可以配合display current-configuration看一眼当前生效的配置。虽然它不是“状态”查询命令但作为上手第一步的摸底动作它和display version搭配使用能让你在最短时间内建立起对这台设备的完整认知。2. 华为设备的核心状态指标CPU、内存、温度和硬件告警网络设备不像电脑没有显示器给你看任务管理器想知道它的“身体”状况全靠命令行去问。华为路由器上最常用的几把尺子我按使用频率排个序。2.1 CPU 占用率怎么看才算看明白了display cpu执行完你会看到类似这样的输出CPU utilization statistics at 2024-03-15 14:30:00 System CPU average utilization (%): 35 CPU utilization for five seconds: 30% CPU utilization for one minute: 35% CPU utilization for five minutes: 28%很多新手只看最上面的平均利用率觉得 35% 不高没问题。但这里的门道在于看趋势而不是看单点数值。你第一次登进去看 35%过五分钟再看一次如果五分钟平均值一路从 28% 涨到 40%、55%、78%那这设备大概率正在被什么事情拖住比如环路风暴、异常流量冲击或者某个进程在空转。华为设备还可以用下面这条命令查看具体是哪些进程在消耗 CPUdisplay cpu history这个命令输出的是 CPU 利用率的直方图能看到过去几分钟到几小时的变化曲线。排查“是不是夜间某个定时任务导致 CPU 飙高”这类问题时非常好用我在实际项目中靠它抓到过好几次罪魁祸首——都是下联交换机每隔一段时间发过来的大量协议报文。2.2 内存检查不只是看剩余量display memoryMemory utilization statistics at 2024-03-15 14:30:00 Memory utilization: 68% Total physical memory: 2048M Used memory: 1392M Free memory: 656M内存这条命令表面的门槛很低人人都能看到已用、未用。但实际中有两个坑要注意。第一个坑是内存利用率在设备运行一段时间后缓慢上涨并不一定代表泄漏。正常的路由器上路由表、ARP 表、会话表都在动态增长只要在合理范围内波动属于正常现象。真正需要警惕的是短时间内(比如一两个小时)内存从 30% 跳到 85%并且持续不回落这种情况基本可以判定有异常进程或表项异常增长。第二个坑是注意最后一栏的“临时内存”。华为设备上你能看到类似Memory temporary memory这样的字段这是进程动态申请的临时缓冲区。如果这个数值异常偏大说明有某个功能模块在做大量临时运算比如策略路由匹配逻辑出问题或者 ACL 规则数过多导致转发查表时频繁调用内存。2.3 温度、电源、风扇故障前的最后防线上面那几项是华为路由器的“软件健康”温度和电源就属于“硬件健康”了。设备过热轻则丢包重则直接宕机路由器的风扇损坏通常不会导致立即断网但会留下严重的隐患——尤其是夏天机房空调一停设备温度直逼告警线那画面我是亲眼见过的。温度用一条命令就能查display temperature all输出里会带各个单板的当前温度和上下限阈值。**重点不是看当前温度而是看两个指标距离上限还有多少余量以及温度曲线是不是在持续上涨。**如果当前温度 45 度上限 70 度但每隔几分钟涨一度你也要当回事。电源和风扇可以合并检查display device华为设备上这条命令会列出所有单板、电源模块、风扇的工作状态正常状态显示为Normal异常会直接显示Fault或Abnormal。我见过一排风扇里有一个转速异常显示屏上状态还是 Normal 的但如果进一步用display fan查看就能看到转速值明显偏离设定区间。这个经验非常重要巡检只看状态字段不看实际数值很容易漏掉早期故障。所有能显示数值的项目只要条件允许都建议把数值也记录存档拿到多天的数据你才能发现“数值正在悄悄恶化”这个趋势。3. 物理层到协议层接口和链路状态才是网络通不通的命根子设备自身健康没问题不代表网络就是通的。链路状态排查是运维里最日常也最多变的环节华为路由器上这块的命令非常成熟但真正会用的人不多——大多数人是等到出故障了才想到去查而我是建议在设备上线时就跑一遍全量接口状态检查留个底档。3.1 用 display interface 快速筛查所有接口最常用的命令是display interface brief这条命令会以表格形式列出所有接口的物理状态、协议状态和收发包计数摘要。输出大概是这样的Interface PHY Protocol InUti OutUti inErrors outErrors GigabitEthernet0/0/0 up up 0.01% 0.02% 0 0 GigabitEthernet0/0/1 down down 0% 0% 0 0 GigabitEthernet0/0/2 up down 0.01% 0% 0 0看这张表有个极其实用的顺序先把所有 PHY 为 down 的接口圈出来这是物理层问题大概率是网线、光模块、对端设备没通电再看 PHY up 但 Protocol down 的接口这是协议层问题比如 PPP 协商失败、接口被 shutdown、对端不配合。inErrors和outErrors这两个字段也很有价值。如果某个接口长期有输入错误计数说明物理链路上存在干扰或者光模块劣化这个信号比丢包率更早出现。3.2 单接口详细状态你能从计数器里读出故事当某条链路出现丢包或时延异常就要进入单接口视角了display interface GigabitEthernet0/0/0这条命令的输出里有几个计数器值得反复研究Input/Output bytes 和 packets总收发量看这个接口“累不累”。Input errors包含 CRC、Framing 等错误任何值持续增长都意味着物理层或数据链路层质量不行。Discarded被设备主动丢弃的报文数量。这个很关键——很多情况下报文被丢弃不是线路问题而是 QoS 策略、ACL、广播抑制导致排查时容易漏。Output queue drops出方向的队列丢包说明接口带宽已经到瓶颈或 QoS 队列调度不合理。我举个例子之前有次客户反馈某分支机构的视频会议卡顿。链路 ping 只有 1-2ms 延迟但视频就是花屏。我远程上去看接口的Discarded计数发现它在蹭蹭涨最后定位到是上联接口的入方向广播风暴触发了一个默认的广播抑制阈值。这种问题看 ping 永远看不出来只有查详细计数器才能找到根源。3.3 光模块状态光纤链路独有的排查维度凡是用到光口的场景强烈建议额外执行这条命令display transceiver interface GigabitEthernet0/0/0 verbose华为路由器会把光模块的收发光功率、温度、电压全部列出来。重点看Rx Power接收光功率和 Tx Power发送光功率不同光模块的阈值不同但一个通用的经验是接收光功率如果接近甚至低于模块标称的灵敏度下限通常在 -20dBm 到 -28dBm 之间链路虽然显示 up但随时可能开始丢包。我踩过一个典型的坑光功率在临界值附近设备状态显示一切正常但只要光纤接头稍微一动或者机房温度升高一点光功率就往下掉链路马上出现大量 CRC 错误和丢包。光功率这个指标必须记录多次数据看趋势不能只看达标与否。建议每月巡检时记录一次收发功率生成一条曲线比什么告警系统都敏感。4. 路由表、ARP 表和转发信息库确认设备“脑子”清醒接口都是 up 的底层链路没毛病业务还是不通怎么办那就要往上走一层看看设备的“大脑”——路由表——是否做出了正确的转发决策。4.1 display ip routing-table 的正确打开方式display ip routing-table华为路由器的路由表输出分为 Destination/Mask、Proto、Pre、Cost、NextHop、Interface 几个关键字段。这里的Proto协议来源和Pre优先级是两个最有看头的指标。比如一条直连路由的 Proto 是Direct优先级是 0静态路由是Static优先级是 60OSPF 内部路由是OSPF优先级是 10。优先级数字越小越优先这是路由器做选路决策的核心依据。很多“路由明明存在但流量不按预期走”的案例根源都是多条路由并存时优先级没有按预期区分导致设备选了一条你没注意到的路径。按协议类型过滤查看可以更聚焦display ip routing-table protocol static display ip routing-table protocol ospf排查时我会同时跑这几条命令把相同目的网段的几条路由放一起对比看每条路由的优先级和开销。如果你配置了静态默认路由又同时跑了 OSPF 注入默认路由ARP 表、设备日志里查不到但路由表里两条默认路由的 Pre 值会给出答案。4.2 别忘了一张更贴近转发平面的表FIB路由表是“大脑的判断”但设备转发报文时实际查的是 FIB转发信息库。很多情况下路由表看起来完全正常但转发就是不通这时候问题可能出在 FIB 和路由表没有同步上。用下面的命令查看display fibFIB 表结构和路由表类似但包含的信息更偏向“转发生效后的最终结果”。如果协议路由已经学到但 FIB 里没有对应条目基本可以判断设备的转发平面出现了状况多半需要重启路由协议进程或设备本身来恢复。这种情况不常见但一旦遇到排障路径很明确不至于让你绕大弯。4.3 三层通不通ARP 表是试金石display arpARP 表把 IP 地址和 MAC 地址关联起来虽然简单但在排障中地位极高。比如你 ping 不通对端设备先查 ARP 表里有没有对端 IP 的条目有条目二层已经通了问题大概率出在更高层路由选路、防火墙策略。没有条目二层可能不通或者对端没回应 ARP 请求问题大概率在物理层或接口配置。这个判断逻辑非常朴素但极其高效。我见过太多人一上来就抓包、查防火墙绕一大圈才发现是对端设备接口 down。最基础的排查手段往往是最快的。顺带提一下热搜词里出现的“华为路由器 mac 与 ip 绑定命令”。在实际运维中查 ARP 表是最常见的一个前置动作——你得先确认终端当前拿到的是什么 IP、对应什么 MAC然后才能决定是不是要做 IP 与 MAC 的静态绑定命令是arp static 192.168.1.100 00e0-fc12-3456 vid 10 interface GigabitEthernet0/0/1如果你用的是 DHCP 场景还可以通过display ip pool查看地址池的分配记录确认某个 IP 当前租给了哪个 MAC 地址。排查“终端频繁掉线、IP 冲突”这类问题这个组合拳非常管用。5. 系统日志与会话信息把故障发生前后的时间线拼完整状态查询做到这一步设备当前的情况你已经掌握了七八成。但很多故障不是“现在”发生的而是“某时某刻”发生过的。这时候日志就是你拼凑时间线的关键证据。5.1 日志缓冲区和 trap 缓冲区先读哪个华为设备的登录用户级别一般至少是 3 级以上才能看日志命令如下display logbuffer这条命令会显示设备内存中的日志缓冲区记录着系统启动以来各种级别的日志事件。看日志的关键不是从头到尾读一遍而是按时间线找第一跳异常。排查思路参考先找日志中最早的告警或错误级别记录。比如某条链路的接口状态日志Mar 15 10:22:31 2024 HUAWEI AR2220 %%01IFNET/4/LINK_STATE(l)[2]:The line protocol state of the link on GigabitEthernet0/0/1 turned to DOWN Mar 15 10:22:36 2024 HUAWEI AR2220 %%01IFNET/4/LINK_STATE(l)[3]:The line protocol state of the link on GigabitEthernet0/0/1 turned to UP这两条日志间隔 5 秒说明接口闪断了一次。如果业务侧反馈 10:20 左右出现中断这两条日志就能精准命中问题窗口。但日志缓冲区有一个硬伤——容量有限新日志会覆盖旧日志。设备运行时间越长越早的日志越可能被冲掉。如果关键时间段的日志被覆盖了试试display trapbuffer它记录的是 trap 告警当网络管理系统收到 trap 后本地 buffer 也会留存一份通常比 logbuffer 保留时间更长。5.2 会话与在线用户状态看看谁在占用设备资源display users这是一个很容易被忽略的命令。它列出当前所有登录设备的用户会话包括登录方式console、VTY、SSH、来源 IP、登录时长。从运维安全角度看这条命令的价值是确认这台设备除了你还有谁登着。之前遇到过一次很诡异的设备“卡顿”问题配置命令敲进去都要等好几秒才回显。排查到什么结论都没有直到执行了display users发现有一位同事的 SSH 会话已经在线 200 多天他的终端其实早就断了但会话没有正常关闭一直挂着占用了设备的并发会话资源。清掉这个僵尸会话之后设备操作立即恢复了顺畅。另外还有一个安全习惯巡检结束准备退出设备之前再跑一次display users确认没有留下自己误开的空闲会话。设备允许的并发会话数有限堆积太多僵尸会话等真正需要远程排障时你反而登不进去那才是最尴尬的。5.3 TCP 状态与会话表确认设备的“连接台账”路由器作为三层设备也会维护自身的 TCP 连接状态尤其是你启用了 SSH、HTTP、NTP 这些服务时。用下面的命令可以查看display tcp status这条命令平时用的少但排查“路由器自身服务异常”时非常有用。比如你发现从办公室 SSH 到路由器特别慢查看 TCP 状态发现大量连接的握手卡在 SYN_SENT说明设备上某个服务或 ACL 限制了连接建立。华为路由器也支持查看业务会话表命令是display session statistics。这不是接口流量而是设备 IP 层处理的每条业务流的会话记录。当你想知道“现在到底有多少条流量在穿过这台路由器”查会话统计比看接口带宽直观得多。6. 常见热搜场景串联console 密码、ACL 配置和绑定操作怎么与状态查看配合前面五个章节讲的都是“看状态”这个动作本身。但很多人在实际情况里会遇到更具体的问题——登录的时候密码进不去或者状态查完了发现异常流量需要管控这时候要把状态查看和配置操作串起来用才是一套完整的运维闭环。6.1 console 密码忘了状态无从看起怎么办设备都登不进去前面的命令都是空谈。华为路由器的 console 口默认配置一般在出厂状态下是无需认证的但如果之前有人配置过认证又没人记得密码就只能走恢复流程。最常用的恢复方式是设备重启在启动过程中按CtrlB进入 BootROM 菜单选择清除 console 密码的选项然后重启设备进入系统。这个操作会中断业务必须在维护窗口内进行。但这里有个非常关键的前提 ——如果你手里还有 SSH 或 Telnet 的登录途径就不要轻易重启。先尝试现有通道登录设备登录后用下面的命令直接查看或重置 console 用户认证方式display current-configuration | include user-interface如果看到user-interface console 0下面配置了authentication-mode password直接用reset saved-configuration之前先确认好备份避免越改越乱。我的实操建议是在任何密码恢复操作之前先确保配置备份已导出。拿不到当前配置恢复密码后设备配置全部丢失的情况我见过不少那种从头再配一遍的痛苦真的没必要体验。6.2 ACL 配置前用状态查询铺路热搜词里的“华为路由器配置 acl”也是个高频需求。我的建议是动手配置 ACL 之前先跑一轮状态查询明确到底要过滤什么、影响什么。至少要看三样东西display acl all display interface brief display ip routing-tabledisplay acl all能让你看到设备上已有的 ACL 规则及其应用位置避免新规则编号冲突或与旧规则叠加出意外。配置完成之后很多人直接“配完就忘”从不验证。我建议加一步验证动作检查 ACL 的实际命中情况display acl 3000华为设备的 ACL 输出会显示每条规则的匹配计数。配置完以后放一会儿回来查看计数是否在增长增长说明规则生效且被流量命中零增长说明规则要么没被正确调用要么匹配条件写得过严。这一步是 ACL 配置闭环里最容易被遗漏的环节却是确认配置有效性的唯一直接证据。6.3 IP 与 MAC 绑定先查状态再动手收紧最后一个热搜词“华为路由器 mac 与 ip 绑定命令”在实战中其实是一个完整的交互过程。你计划的绑定操作不是一上来就敲arp static而是先观察现状用display ip interface brief确认端口的 IP 配置。用display arp查看当前该网段下所有终端的 IP 和 MAC 对应关系。确认目标终端的 IP 与 MAC 是否稳定以及是否有其他终端盗用了同一个 IP。做完这三步状态查询再执行绑定命令并在绑定后再次用display arp验证是否生效。绑定之后还要注意设备上同时存在 DHCP 动态分配和静态绑定两套机制时要以静态绑定优先于动态分配的规则为准否则可能出现绑定了静态条目但 DHCP 又把同一 IP 分配给了别的终端网络依然冲突的情况。我个人在主备路由器的场景里还有一个特别提醒华为设备的arp static绑定条目在主备切换后不一定能自动同步切换完要主动到新主设备上重新核对 ARP 表。这个坑我踩过一次切换过程一切正常但切换后部分终端无法上网查了半天才发现是 ARP 静态条目没有跟着状态同步过去。设备的“基本状态”这个概念比大多数人想象的宽得多——它不只是 CPU 和内存还包括接口、路由、日志、会话甚至包括你登录设备的通道本身。把这些每一样都看懂了你对一台华为路由器的掌控力会远超那些只会敲配置命令的人。最后分享一个我自己的巡检习惯我把上面这些命令整理成了一个固定顺序每次巡检就按这个顺序执行把关键输出存成文本文件文件名带上日期。攒上两三个月你手里就有了一份设备全生命周期的状态档案后续任何故障排查都不是从零开始而是直接从“上次正常状态”出发做对比效率完全不一样。