简介这份文档资料聚焦计算机网络中路由器故障这一常见运维难题面向网络初学者、运维人员及备考相关认证的读者帮助其系统理解路由器硬件组成与故障排查思路。资源包共1个doc文件约34KB内容以文字讲解为主便于快速查阅与整理笔记。文档从处理器、DRAM、BootROM、NVRAM、Flash及系统软件等核心部件切入梳理硬故障与软故障两大类别并针对无法加电、部件损坏、拨号失败、网页无法打开、管理界面登录异常、上网掉线等典型场景给出具体处理措施同时涉及网络规划、DNS解析与DHCP配置等排错要点。已有90人学习适合作为日常网络维护的参考手册也可用于课程学习与故障排查思路训练。1. 路由器故障排查为什么你的第一反应往往是错的路由器出问题的时候绝大多数人的第一反应是重启。这个动作不能说错但它最大的问题是——你重启完问题大概率还会再来。因为你根本没搞清楚它为什么挂。我见过太多这样的场景某公司办公网每隔两三天就断一次IT 每次去机房拔电重启好了过两天又断。折腾了两个月最后发现是路由器 NAT 会话表被打满了根源是一台内网主机中了蠕虫在疯狂扫段。重启只是清了会话表病根一直在那儿。路由器故障排查的核心不是“让它通”而是“搞清楚它为什么不通”。这篇文章面向的是需要实际动手排查网络故障的从业者——你可能是一个人管着几十台设备的小团队网管也可能是刚入行的运维遇到路由器问题不想每次都靠重启和玄学。我会把常见的路由器故障类型、排查思路、具体命令和参数、以及那些只有踩过才知道的坑一条一条讲清楚。读完你至少能做到拿到一台出问题的路由器知道先看什么、再看什么、什么情况下该换思路。2. 先分清故障层次物理层、链路层还是网络层2.1 用分层模型快速缩小排查范围路由器故障排查最怕的就是没有章法东一榔头西一棒子。我的习惯是先用 TCP/IP 分层模型把问题定位到一个大致范围再往下钻。具体怎么分你拿到一台“有问题”的路由器先问三个问题第一物理连接正常吗看接口指示灯、看线缆、看光模块。这一步能过滤掉大概两成的“故障”——很多时候根本不是路由器的问题是网线松了或者光衰太大。第二链路能起来吗接口 up 了吗协商速率对不对PPP 拨号有没有拿到地址这一步过滤掉的是二层问题。第三路由通不通能 ping 通直连吗能 ping 通远端吗路由表里有没有你期望的路由DNS 解析正常吗这一步才是三层及以上的问题。这个顺序不能反。我见过有人一上来就查路由表查了半天发现接口根本没 up。分层排查的意义就在于用最低的成本排除最大范围的可能性。实际操作中我会在路由器上按这个顺序敲命令。以常见的网络设备 CLI 为例# 第一步看接口物理状态和协议状态 show interfaces status # 关注输出中的 Status 和 Protocol 两列 # Status: connected 表示物理层正常notconnect 表示物理层有问题 # Protocol: up 表示链路层正常down 表示链路层有问题 # 第二步看具体接口的详细信息和计数器 show interfaces GigabitEthernet0/1 # 关注 input errors、output errors、CRC、frame 等计数器 # 如果 CRC 持续增长基本可以判定物理层有问题线缆、光模块、接口硬件 # 第三步看路由表 show ip route # 关注是否有默认路由、是否有你期望的目标网段路由 # 如果路由表为空或者缺少关键路由问题就在路由层面这三个命令敲完基本能把问题锁定在某一层。注意show interfaces status和show interfaces的区别前者是概览快速看所有接口的状态后者是详情看具体接口的计数器、MTU、带宽等参数。排查时先用概览定位到可疑接口再用详情深入看。2.2 物理层和链路层的典型故障特征物理层故障的特征很好认接口指示灯不亮、show interfaces里 Status 显示 notconnect、input errors 和 CRC 计数器持续增长。遇到这些先换线、换端口、换光模块别急着怀疑配置。这里有个血泪经验CRC 错误增长不一定是线的问题也可能是两端速率双工不匹配。比如一端强制千兆全双工另一端自适应成了百兆半双工这时候 CRC 会疯狂增长。解决办法是把两端都设成自适应或者都强制成相同的速率和双工模式。链路层故障稍微隐蔽一些。接口物理层 up 了但协议层 down常见原因有PPP 认证失败查show interface里的 LCP 状态看是卡在认证阶段还是协商阶段以太网链路聚合协商失败查 LACP 状态看两端模式是否匹配VLAN 配置不一致trunk 口两端允许的 VLAN 列表不匹配# 查看接口的详细协议状态 show interfaces GigabitEthernet0/1 # 关注 line protocol is up/down # 如果显示 line protocol is down说明二层协议没起来 # 查看 PPP 认证状态以 PPPoE 为例 show pppoe session # 关注 State 字段UP 表示会话正常 # 如果卡在 PADI/PADO 阶段说明发现阶段就有问题 # 查看链路聚合状态 show etherchannel summary # 关注 Flags 字段SU 表示二层和三层都 up # 如果显示 D表示 down排查链路层问题关键是对比两端的状态。一端 up 一端 down那问题大概率在中间链路或者某一端的配置上。如果两端都 down那可能是物理链路本身有问题回到物理层去查。2.3 网络层故障的排查路径网络层故障是路由器排查中最常见的也是花样最多的。典型表现是接口 up、协议 up但就是 ping 不通。排查路径是这样的先看直连能不能通。如果直连都 ping 不通检查接口 IP 地址、子网掩码、ARP 表。ARP 表里有没有对方的 MAC如果没有说明二层没通或者对方没回 ARP。再看路由表里有没有目标网段的路由。如果没有检查路由协议配置、静态路由配置、或者上游路由器有没有通告过来。最后看有没有 ACL 或防火墙规则挡着。这个最容易被忽略因为 ACL 配下去之后平时不显山露水一出问题就是“明明路由都对但就是不通”。# 查看 ARP 表 show arp # 确认目标 IP 对应的 MAC 地址是否存在 # 查看路由表详情 show ip route 192.168.2.0 # 确认是否有精确匹配的路由条目 # 查看接口上应用的 ACL show ip interface GigabitEthernet0/1 # 关注 Outgoing access list 和 Incoming access list 字段 # 用扩展 ping 指定源地址测试 ping 192.168.2.1 source 192.168.1.1 # 指定源地址可以排除路由回程不对称的问题扩展 ping 是个好东西。很多时候你 ping 不通不是因为去程有问题而是因为回程路由不对。指定源地址就能验证这一点。如果指定源地址能通不指定就不通那基本可以确定是回程路由的问题。3. 配置类故障那些“明明配了却不生效”的场景3.1 路由协议邻居起不来的排查方法路由协议邻居起不来是配置类故障里最典型的一类。OSPF 邻居卡在 EXSTART、BGP 邻居卡在 Active、这些状态码背后都有明确的原因。OSPF 邻居状态机有七个状态Down、Init、2-Way、ExStart、Exchange、Loading、Full。每个状态卡住都对应不同的问题卡在 Init一端收到了 Hello但另一端没收到。检查单向连通性、ACL 是否挡了 OSPF 组播卡在 2-WayDR/BDR 选举中非 DR/BDR 之间停留在 2-Way 是正常的但如果所有邻居都卡在 2-Way检查网络类型和 DR 优先级卡在 ExStartMTU 不匹配是最常见的原因。两端接口 MTU 不一致DD 报文协商失败卡在 Exchange/LoadingLSA 传输有问题检查链路质量和 MTU# 查看 OSPF 邻居状态 show ip ospf neighbor # 关注 State 字段FULL 表示邻接关系正常 # 如果显示 EXSTART 或 EXCHANGE重点查 MTU # 查看接口 MTU show interfaces GigabitEthernet0/1 | include MTU # 对比两端 MTU 是否一致 # 查看 OSPF 接口参数 show ip ospf interface GigabitEthernet0/1 # 关注 Hello 间隔、Dead 间隔、网络类型、区域 ID # 两端这些参数必须匹配MTU 不匹配这个坑我踩过不止一次。表现就是 OSPF 邻居卡在 EXSTART 或者 Exchange怎么重启协议都不行。解决办法是把两端接口 MTU 改成一致或者用ip ospf mtu-ignore忽略 MTU 检查。但后者只是绕过问题不推荐作为长期方案。BGP 邻居起不来常见原因有AS 号配错、更新源地址不对、EBGP 多跳没配、认证密码不匹配。排查时先看show ip bgp summary看邻居状态是 Idle、Active 还是 Established。Idle 说明还没开始尝试Active 说明在尝试建立 TCP 连接但失败了Established 才是正常的。3.2 NAT 和 ACL 的隐蔽冲突NAT 和 ACL 的冲突是另一个高频翻车点。典型场景是你配了一条 NAT 规则内网用户能上网了但外网用户访问不了内网服务器。或者反过来服务器能访问了但内网用户上不了网。问题出在 NAT 和 ACL 的处理顺序上。不同厂商、不同型号的路由器NAT 和 ACL 的处理顺序可能不一样。有的先做 NAT 再做 ACL有的先做 ACL 再做 NAT。顺序不同ACL 里写的地址是 NAT 前的还是 NAT 后的就完全不一样了。# 查看 NAT 转换表 show ip nat translations # 确认内网地址是否被正确转换 # 查看 NAT 统计信息 show ip nat statistics # 关注 hits 和 misses判断 NAT 规则是否被命中 # 查看 ACL 命中计数 show ip access-lists # 关注每条规则的匹配计数判断流量是否被 ACL 匹配排查 NAT 和 ACL 冲突最有效的方法是做流量抓包或者开 debug。但 debug 在生产环境要慎用尤其是debug ip nat和debug ip packet这种流量大的时候能把路由器 CPU 打满。我一般会先用 ACL 的命中计数来判断流量走到哪一步了实在不行再在维护窗口开 debug。还有一个坑是 NAT 超时时间。TCP 会话的 NAT 超时默认一般是 86400 秒24 小时UDP 是 300 秒。如果内网有一台设备需要保持长连接但 NAT 超时时间设得太短连接就会被断开。表现就是“每隔一段时间就断一次”很有规律。解决办法是调整 NAT 超时时间或者在内网设备上开 keepalive。3.3 策略路由和路由策略的优先级陷阱策略路由PBR和路由策略Route-Policy是两种不同的东西但经常被混为一谈。策略路由是“基于策略转发”路由策略是“基于策略过滤路由”。前者影响数据包的转发路径后者影响路由表的生成。常见的坑是配了策略路由但发现不生效。原因通常是策略路由的优先级低于路由表查找。在大多数设备上策略路由的匹配顺序是先匹配策略路由如果匹配上了就按策略路由转发如果没匹配上再查路由表。但有些设备上策略路由和路由表的优先级是可以配置的如果配错了策略路由就被路由表覆盖了。# 查看策略路由配置 show route-map # 确认 match 和 set 语句是否正确 # 查看接口上应用的策略路由 show ip policy # 确认接口上是否应用了正确的 route-map # 查看策略路由的命中计数 show route-map interface GigabitEthernet0/1 # 关注匹配计数判断策略路由是否被命中策略路由还有一个坑是只对入方向流量生效。也就是说你在接口上配了策略路由它只影响从该接口进入的流量不影响从该接口出去的流量。如果你想让出去的流量也走策略路由需要在对应的入接口上配置。4. 性能类故障CPU 高、内存泄漏、会话表满4.1 CPU 和内存问题的定位手段路由器 CPU 高先别急着重启。重启能暂时缓解但过一会儿又高上去了。正确的做法是找到是谁在消耗 CPU。# 查看 CPU 利用率 show processes cpu sorted # 关注 5 秒、1 分钟、5 分钟的平均利用率 # 看哪个进程占用最高 # 查看 CPU 历史利用率 show processes cpu history # 可以看到过去 60 秒、60 分钟、72 小时的 CPU 曲线 # 判断是突发还是持续 # 查看内存使用情况 show processes memory sorted # 关注各进程的内存占用和增长趋势CPU 高的常见原因有路由震荡导致协议计算频繁、大量流量触发软件转发、ARP 攻击导致 ARP 表频繁更新、SNMP 轮询过于频繁。找到对应的进程基本就能定位到原因。内存泄漏的排查更麻烦一些。表现是内存使用率持续上升重启后降下来然后继续上升。排查方法是定期抓取show processes memory的输出对比各进程的内存增长情况。如果某个进程的内存持续增长且不释放基本可以判定是内存泄漏。这种情况通常需要升级固件或者联系厂商自己不太好解决。4.2 NAT 会话表和 ARP 表打满的应急处理NAT 会话表打满表现是内网用户突然大面积上不了网但路由器 CPU 和内存都正常。这时候查show ip nat statistics看 Total active translations 是不是接近或达到了最大值。# 查看 NAT 会话表使用情况 show ip nat statistics # 关注 Total active translations 和 Max translations # 查看 NAT 会话表详情 show ip nat translations # 看哪些内网地址占用了大量会话 # 查看 ARP 表使用情况 show arp # 看 ARP 表项数量是否接近上限应急处理可以临时调大 NAT 会话表上限或者清理超时的会话。但根本解决办法是找到谁在大量建立会话。常见的原因是内网有主机中了病毒或蠕虫在疯狂扫段或者有 P2P 下载占用了大量会话。ARP 表打满的表现类似但影响范围通常是某个网段。查show arp看表项数量如果接近上限可以调大 ARP 表容量或者缩短 ARP 老化时间。但同样根本原因是找到谁在发大量 ARP 请求。常见的是 ARP 攻击或者 IP 地址冲突。注意调大表项上限只是应急手段会消耗更多内存。如果内存本身就不够调大上限可能导致更严重的问题。应急之后一定要找到根源。5. 避坑指南路由器故障排查中的五个常见错误5.1 重启万能论为什么重启解决不了根因现象路由器出问题重启后恢复但过一段时间又出问题。原因重启只是清除了当前的异常状态比如会话表、ARP 表、内存碎片但没有解决导致异常的根本原因。如果根本原因是配置错误、流量攻击、或者硬件老化重启后问题一定会复现。解决重启后第一时间收集信息。看日志、看 CPU 和内存历史、看会话表变化趋势。在问题复现之前找到规律才能定位根因。我一般会在重启后立刻执行show logging、show processes cpu history、show processes memory把基线数据留下来。5.2 只看当前状态不看历史趋势现象排查时只看show interfaces的当前计数器发现都是 0就认为接口没问题。原因很多计数器是累计值如果中间重启过或者计数器被清过当前值可能都是 0。但历史趋势才能反映问题。解决用show interfaces的时候关注 error 计数器的增长速率而不是绝对值。可以间隔几秒连续执行两次对比差值。另外show logging里的日志、show processes cpu history里的历史曲线都是判断趋势的重要依据。5.3 忽略 MTU 和 MSS 导致的“能 ping 通但打不开网页”现象能 ping 通目标地址但网页打不开、文件传不了。ping 小包正常ping 大包比如 1500 字节就不通。原因路径 MTU 不匹配。中间某段链路的 MTU 小于两端接口的 MTU大包被丢弃但 ICMP 差错报文可能被 ACL 挡了导致两端不知道需要分片。解决用ping指定包大小和 DF 位来测试路径 MTU。比如ping 192.168.2.1 size 1500 df-bit如果不通就逐步减小 size找到能通的最大值。然后在接口上调整 MTU 或者 TCP MSS。# 测试路径 MTU ping 192.168.2.1 size 1500 df-bit # 如果显示需要分片但设置了 DF 位说明路径 MTU 小于 1500 # 调整接口 MTU interface GigabitEthernet0/1 mtu 1400 # 两端都要调整或者只调整一端并配合 TCP MSS 调整 # 调整 TCP MSS interface GigabitEthernet0/1 ip tcp adjust-mss 1360 # 1360 1400 - 20(IP头) - 20(TCP头)5.4 排查时改了多个变量导致无法定位现象排查过程中改了好几个配置问题解决了但不知道到底是哪个改动起的作用。下次遇到同样问题还是不知道怎么处理。原因没有遵循“一次只改一个变量”的原则。解决每次只改一个配置改完立刻验证。如果问题解决记录下这个改动如果没解决回滚这个改动再试下一个。这样做虽然慢但能积累经验。下次遇到类似问题直接就能定位到原因。5.5 生产环境开 debug 导致二次故障现象为了排查问题开了 debug结果 debug 输出把 CPU 打满路由器直接失联业务中断范围扩大。原因debug 会消耗大量 CPU 和内存资源尤其是debug ip packet、debug ip nat这种针对每个数据包都输出的 debug流量大的时候能把路由器打挂。解决生产环境开 debug 必须满足三个条件一是在维护窗口内二是提前配好 ACL 限制 debug 范围三是设好no debug all的定时任务或者准备好带外管理通道。我一般会先用 ACL 的命中计数、NetFlow、或者镜像抓包来替代 debug实在需要 debug 的时候也会用debug condition来限制范围。6. 用日志和 NetFlow 做故障回溯事后也能找到原因6.1 配置日志服务器和日志级别路由器故障排查最遗憾的事情是问题发生了但日志没开什么线索都没留下。所以我的习惯是任何一台路由器上线第一件事就是配日志服务器。# 配置日志服务器 logging host 192.168.1.100 # 指定日志服务器地址 logging trap informational # 设置日志级别为 informational # 级别从 0 到 7数字越小越严重 # 0-emergencies, 1-alerts, 2-critical, 3-errors, 4-warnings, 5-notifications, 6-informational, 7-debugging logging source-interface Loopback0 # 指定日志源接口方便在日志服务器上过滤 logging buffered 16384 # 本地日志缓冲区大小单位字节 # 根据路由器内存调整一般 16384 到 65536 够用 service timestamps log datetime msec localtime # 日志时间戳精确到毫秒方便和抓包对比日志级别设成 informational 是比较平衡的选择。debugging 级别太啰嗦会消耗大量资源warnings 级别又可能漏掉关键信息。informational 能记录接口 up/down、协议邻居变化、认证失败等关键事件。日志服务器上可以用 syslog-ng 或者 rsyslog 来接收和存储日志。关键是做好日志轮转和归档别让日志把磁盘写满。我一般会保留至少 30 天的日志方便回溯。6.2 用 NetFlow 定位流量异常NetFlow 是排查流量异常的神器。它能告诉你谁在什么时候、向谁、发了多少流量。当路由器 CPU 高或者带宽跑满的时候NetFlow 能快速定位到异常流量的来源。# 配置 NetFlow以 Cisco 为例 interface GigabitEthernet0/1 ip flow ingress ip flow egress # 在接口上开启 NetFlow 统计 ip flow-export destination 192.168.1.100 2055 # 指定 NetFlow 收集器地址和端口 ip flow-export version 9 # 使用 NetFlow v9支持更多字段 ip flow-export source Loopback0 # 指定导出源接口 ip flow-cache timeout active 1 # 活跃流超时时间单位分钟 # 设短一点可以更快看到流量变化 ip flow-cache timeout inactive 15 # 非活跃流超时时间单位秒NetFlow 收集器可以用 nfdump、Elasticsearch Logstash、或者商业工具。关键是能按源 IP、目的 IP、端口、协议做聚合和排序。当带宽异常的时候按流量大小排序排在最前面的基本就是嫌疑对象。有一次某公司办公网出口带宽跑满用 NetFlow 一看内网一台主机的 445 端口在向外网大量发包明显是中了蠕虫。从发现到定位到主机前后不到五分钟。如果没有 NetFlow可能得折腾半天。6.3 日志和 NetFlow 的联动分析日志和 NetFlow 结合使用效果更好。日志告诉你“发生了什么事件”NetFlow 告诉你“流量是什么样的”。两者时间戳对齐就能还原出故障发生时的完整场景。比如接口频繁 up/down日志里能看到 up/down 的时间点NetFlow 能看到 up/down 期间流量是否中断、中断了多久。如果接口 up/down 的同时流量也中断了说明是链路问题如果接口 up/down 但流量没断说明是接口震荡但路由收敛得快影响不大。我一般会在日志服务器上配一个简单的告警规则接口 up/down、协议邻居变化、CPU 超过阈值、内存超过阈值这些事件触发告警。收到告警后先去 NetFlow 上看对应时间点的流量情况基本就能判断影响范围和严重程度。排查路由器故障这件事说到底就是两个习惯一是分层排查从物理层往上逐层排除二是留好数据日志和 NetFlow 配好事后能回溯。我踩过的最大的坑就是早期不重视日志出了问题只能靠猜重启完就过去了下次再来一遍。后来把日志和 NetFlow 配齐了很多问题在发生之前就能看到苗头比如接口 CRC 缓慢增长、CPU 周期性升高、会话表持续上涨这些都是故障的前兆。提前处理比出了故障再救火要从容得多。希望帮到你。本文还有配套的精品资源点击获取 路由器故障排查实战：分层定位、配置冲突与性能瓶颈
简介这份文档资料聚焦计算机网络中路由器故障这一常见运维难题面向网络初学者、运维人员及备考相关认证的读者帮助其系统理解路由器硬件组成与故障排查思路。资源包共1个doc文件约34KB内容以文字讲解为主便于快速查阅与整理笔记。文档从处理器、DRAM、BootROM、NVRAM、Flash及系统软件等核心部件切入梳理硬故障与软故障两大类别并针对无法加电、部件损坏、拨号失败、网页无法打开、管理界面登录异常、上网掉线等典型场景给出具体处理措施同时涉及网络规划、DNS解析与DHCP配置等排错要点。已有90人学习适合作为日常网络维护的参考手册也可用于课程学习与故障排查思路训练。1. 路由器故障排查为什么你的第一反应往往是错的路由器出问题的时候绝大多数人的第一反应是重启。这个动作不能说错但它最大的问题是——你重启完问题大概率还会再来。因为你根本没搞清楚它为什么挂。我见过太多这样的场景某公司办公网每隔两三天就断一次IT 每次去机房拔电重启好了过两天又断。折腾了两个月最后发现是路由器 NAT 会话表被打满了根源是一台内网主机中了蠕虫在疯狂扫段。重启只是清了会话表病根一直在那儿。路由器故障排查的核心不是“让它通”而是“搞清楚它为什么不通”。这篇文章面向的是需要实际动手排查网络故障的从业者——你可能是一个人管着几十台设备的小团队网管也可能是刚入行的运维遇到路由器问题不想每次都靠重启和玄学。我会把常见的路由器故障类型、排查思路、具体命令和参数、以及那些只有踩过才知道的坑一条一条讲清楚。读完你至少能做到拿到一台出问题的路由器知道先看什么、再看什么、什么情况下该换思路。2. 先分清故障层次物理层、链路层还是网络层2.1 用分层模型快速缩小排查范围路由器故障排查最怕的就是没有章法东一榔头西一棒子。我的习惯是先用 TCP/IP 分层模型把问题定位到一个大致范围再往下钻。具体怎么分你拿到一台“有问题”的路由器先问三个问题第一物理连接正常吗看接口指示灯、看线缆、看光模块。这一步能过滤掉大概两成的“故障”——很多时候根本不是路由器的问题是网线松了或者光衰太大。第二链路能起来吗接口 up 了吗协商速率对不对PPP 拨号有没有拿到地址这一步过滤掉的是二层问题。第三路由通不通能 ping 通直连吗能 ping 通远端吗路由表里有没有你期望的路由DNS 解析正常吗这一步才是三层及以上的问题。这个顺序不能反。我见过有人一上来就查路由表查了半天发现接口根本没 up。分层排查的意义就在于用最低的成本排除最大范围的可能性。实际操作中我会在路由器上按这个顺序敲命令。以常见的网络设备 CLI 为例# 第一步看接口物理状态和协议状态 show interfaces status # 关注输出中的 Status 和 Protocol 两列 # Status: connected 表示物理层正常notconnect 表示物理层有问题 # Protocol: up 表示链路层正常down 表示链路层有问题 # 第二步看具体接口的详细信息和计数器 show interfaces GigabitEthernet0/1 # 关注 input errors、output errors、CRC、frame 等计数器 # 如果 CRC 持续增长基本可以判定物理层有问题线缆、光模块、接口硬件 # 第三步看路由表 show ip route # 关注是否有默认路由、是否有你期望的目标网段路由 # 如果路由表为空或者缺少关键路由问题就在路由层面这三个命令敲完基本能把问题锁定在某一层。注意show interfaces status和show interfaces的区别前者是概览快速看所有接口的状态后者是详情看具体接口的计数器、MTU、带宽等参数。排查时先用概览定位到可疑接口再用详情深入看。2.2 物理层和链路层的典型故障特征物理层故障的特征很好认接口指示灯不亮、show interfaces里 Status 显示 notconnect、input errors 和 CRC 计数器持续增长。遇到这些先换线、换端口、换光模块别急着怀疑配置。这里有个血泪经验CRC 错误增长不一定是线的问题也可能是两端速率双工不匹配。比如一端强制千兆全双工另一端自适应成了百兆半双工这时候 CRC 会疯狂增长。解决办法是把两端都设成自适应或者都强制成相同的速率和双工模式。链路层故障稍微隐蔽一些。接口物理层 up 了但协议层 down常见原因有PPP 认证失败查show interface里的 LCP 状态看是卡在认证阶段还是协商阶段以太网链路聚合协商失败查 LACP 状态看两端模式是否匹配VLAN 配置不一致trunk 口两端允许的 VLAN 列表不匹配# 查看接口的详细协议状态 show interfaces GigabitEthernet0/1 # 关注 line protocol is up/down # 如果显示 line protocol is down说明二层协议没起来 # 查看 PPP 认证状态以 PPPoE 为例 show pppoe session # 关注 State 字段UP 表示会话正常 # 如果卡在 PADI/PADO 阶段说明发现阶段就有问题 # 查看链路聚合状态 show etherchannel summary # 关注 Flags 字段SU 表示二层和三层都 up # 如果显示 D表示 down排查链路层问题关键是对比两端的状态。一端 up 一端 down那问题大概率在中间链路或者某一端的配置上。如果两端都 down那可能是物理链路本身有问题回到物理层去查。2.3 网络层故障的排查路径网络层故障是路由器排查中最常见的也是花样最多的。典型表现是接口 up、协议 up但就是 ping 不通。排查路径是这样的先看直连能不能通。如果直连都 ping 不通检查接口 IP 地址、子网掩码、ARP 表。ARP 表里有没有对方的 MAC如果没有说明二层没通或者对方没回 ARP。再看路由表里有没有目标网段的路由。如果没有检查路由协议配置、静态路由配置、或者上游路由器有没有通告过来。最后看有没有 ACL 或防火墙规则挡着。这个最容易被忽略因为 ACL 配下去之后平时不显山露水一出问题就是“明明路由都对但就是不通”。# 查看 ARP 表 show arp # 确认目标 IP 对应的 MAC 地址是否存在 # 查看路由表详情 show ip route 192.168.2.0 # 确认是否有精确匹配的路由条目 # 查看接口上应用的 ACL show ip interface GigabitEthernet0/1 # 关注 Outgoing access list 和 Incoming access list 字段 # 用扩展 ping 指定源地址测试 ping 192.168.2.1 source 192.168.1.1 # 指定源地址可以排除路由回程不对称的问题扩展 ping 是个好东西。很多时候你 ping 不通不是因为去程有问题而是因为回程路由不对。指定源地址就能验证这一点。如果指定源地址能通不指定就不通那基本可以确定是回程路由的问题。3. 配置类故障那些“明明配了却不生效”的场景3.1 路由协议邻居起不来的排查方法路由协议邻居起不来是配置类故障里最典型的一类。OSPF 邻居卡在 EXSTART、BGP 邻居卡在 Active、这些状态码背后都有明确的原因。OSPF 邻居状态机有七个状态Down、Init、2-Way、ExStart、Exchange、Loading、Full。每个状态卡住都对应不同的问题卡在 Init一端收到了 Hello但另一端没收到。检查单向连通性、ACL 是否挡了 OSPF 组播卡在 2-WayDR/BDR 选举中非 DR/BDR 之间停留在 2-Way 是正常的但如果所有邻居都卡在 2-Way检查网络类型和 DR 优先级卡在 ExStartMTU 不匹配是最常见的原因。两端接口 MTU 不一致DD 报文协商失败卡在 Exchange/LoadingLSA 传输有问题检查链路质量和 MTU# 查看 OSPF 邻居状态 show ip ospf neighbor # 关注 State 字段FULL 表示邻接关系正常 # 如果显示 EXSTART 或 EXCHANGE重点查 MTU # 查看接口 MTU show interfaces GigabitEthernet0/1 | include MTU # 对比两端 MTU 是否一致 # 查看 OSPF 接口参数 show ip ospf interface GigabitEthernet0/1 # 关注 Hello 间隔、Dead 间隔、网络类型、区域 ID # 两端这些参数必须匹配MTU 不匹配这个坑我踩过不止一次。表现就是 OSPF 邻居卡在 EXSTART 或者 Exchange怎么重启协议都不行。解决办法是把两端接口 MTU 改成一致或者用ip ospf mtu-ignore忽略 MTU 检查。但后者只是绕过问题不推荐作为长期方案。BGP 邻居起不来常见原因有AS 号配错、更新源地址不对、EBGP 多跳没配、认证密码不匹配。排查时先看show ip bgp summary看邻居状态是 Idle、Active 还是 Established。Idle 说明还没开始尝试Active 说明在尝试建立 TCP 连接但失败了Established 才是正常的。3.2 NAT 和 ACL 的隐蔽冲突NAT 和 ACL 的冲突是另一个高频翻车点。典型场景是你配了一条 NAT 规则内网用户能上网了但外网用户访问不了内网服务器。或者反过来服务器能访问了但内网用户上不了网。问题出在 NAT 和 ACL 的处理顺序上。不同厂商、不同型号的路由器NAT 和 ACL 的处理顺序可能不一样。有的先做 NAT 再做 ACL有的先做 ACL 再做 NAT。顺序不同ACL 里写的地址是 NAT 前的还是 NAT 后的就完全不一样了。# 查看 NAT 转换表 show ip nat translations # 确认内网地址是否被正确转换 # 查看 NAT 统计信息 show ip nat statistics # 关注 hits 和 misses判断 NAT 规则是否被命中 # 查看 ACL 命中计数 show ip access-lists # 关注每条规则的匹配计数判断流量是否被 ACL 匹配排查 NAT 和 ACL 冲突最有效的方法是做流量抓包或者开 debug。但 debug 在生产环境要慎用尤其是debug ip nat和debug ip packet这种流量大的时候能把路由器 CPU 打满。我一般会先用 ACL 的命中计数来判断流量走到哪一步了实在不行再在维护窗口开 debug。还有一个坑是 NAT 超时时间。TCP 会话的 NAT 超时默认一般是 86400 秒24 小时UDP 是 300 秒。如果内网有一台设备需要保持长连接但 NAT 超时时间设得太短连接就会被断开。表现就是“每隔一段时间就断一次”很有规律。解决办法是调整 NAT 超时时间或者在内网设备上开 keepalive。3.3 策略路由和路由策略的优先级陷阱策略路由PBR和路由策略Route-Policy是两种不同的东西但经常被混为一谈。策略路由是“基于策略转发”路由策略是“基于策略过滤路由”。前者影响数据包的转发路径后者影响路由表的生成。常见的坑是配了策略路由但发现不生效。原因通常是策略路由的优先级低于路由表查找。在大多数设备上策略路由的匹配顺序是先匹配策略路由如果匹配上了就按策略路由转发如果没匹配上再查路由表。但有些设备上策略路由和路由表的优先级是可以配置的如果配错了策略路由就被路由表覆盖了。# 查看策略路由配置 show route-map # 确认 match 和 set 语句是否正确 # 查看接口上应用的策略路由 show ip policy # 确认接口上是否应用了正确的 route-map # 查看策略路由的命中计数 show route-map interface GigabitEthernet0/1 # 关注匹配计数判断策略路由是否被命中策略路由还有一个坑是只对入方向流量生效。也就是说你在接口上配了策略路由它只影响从该接口进入的流量不影响从该接口出去的流量。如果你想让出去的流量也走策略路由需要在对应的入接口上配置。4. 性能类故障CPU 高、内存泄漏、会话表满4.1 CPU 和内存问题的定位手段路由器 CPU 高先别急着重启。重启能暂时缓解但过一会儿又高上去了。正确的做法是找到是谁在消耗 CPU。# 查看 CPU 利用率 show processes cpu sorted # 关注 5 秒、1 分钟、5 分钟的平均利用率 # 看哪个进程占用最高 # 查看 CPU 历史利用率 show processes cpu history # 可以看到过去 60 秒、60 分钟、72 小时的 CPU 曲线 # 判断是突发还是持续 # 查看内存使用情况 show processes memory sorted # 关注各进程的内存占用和增长趋势CPU 高的常见原因有路由震荡导致协议计算频繁、大量流量触发软件转发、ARP 攻击导致 ARP 表频繁更新、SNMP 轮询过于频繁。找到对应的进程基本就能定位到原因。内存泄漏的排查更麻烦一些。表现是内存使用率持续上升重启后降下来然后继续上升。排查方法是定期抓取show processes memory的输出对比各进程的内存增长情况。如果某个进程的内存持续增长且不释放基本可以判定是内存泄漏。这种情况通常需要升级固件或者联系厂商自己不太好解决。4.2 NAT 会话表和 ARP 表打满的应急处理NAT 会话表打满表现是内网用户突然大面积上不了网但路由器 CPU 和内存都正常。这时候查show ip nat statistics看 Total active translations 是不是接近或达到了最大值。# 查看 NAT 会话表使用情况 show ip nat statistics # 关注 Total active translations 和 Max translations # 查看 NAT 会话表详情 show ip nat translations # 看哪些内网地址占用了大量会话 # 查看 ARP 表使用情况 show arp # 看 ARP 表项数量是否接近上限应急处理可以临时调大 NAT 会话表上限或者清理超时的会话。但根本解决办法是找到谁在大量建立会话。常见的原因是内网有主机中了病毒或蠕虫在疯狂扫段或者有 P2P 下载占用了大量会话。ARP 表打满的表现类似但影响范围通常是某个网段。查show arp看表项数量如果接近上限可以调大 ARP 表容量或者缩短 ARP 老化时间。但同样根本原因是找到谁在发大量 ARP 请求。常见的是 ARP 攻击或者 IP 地址冲突。注意调大表项上限只是应急手段会消耗更多内存。如果内存本身就不够调大上限可能导致更严重的问题。应急之后一定要找到根源。5. 避坑指南路由器故障排查中的五个常见错误5.1 重启万能论为什么重启解决不了根因现象路由器出问题重启后恢复但过一段时间又出问题。原因重启只是清除了当前的异常状态比如会话表、ARP 表、内存碎片但没有解决导致异常的根本原因。如果根本原因是配置错误、流量攻击、或者硬件老化重启后问题一定会复现。解决重启后第一时间收集信息。看日志、看 CPU 和内存历史、看会话表变化趋势。在问题复现之前找到规律才能定位根因。我一般会在重启后立刻执行show logging、show processes cpu history、show processes memory把基线数据留下来。5.2 只看当前状态不看历史趋势现象排查时只看show interfaces的当前计数器发现都是 0就认为接口没问题。原因很多计数器是累计值如果中间重启过或者计数器被清过当前值可能都是 0。但历史趋势才能反映问题。解决用show interfaces的时候关注 error 计数器的增长速率而不是绝对值。可以间隔几秒连续执行两次对比差值。另外show logging里的日志、show processes cpu history里的历史曲线都是判断趋势的重要依据。5.3 忽略 MTU 和 MSS 导致的“能 ping 通但打不开网页”现象能 ping 通目标地址但网页打不开、文件传不了。ping 小包正常ping 大包比如 1500 字节就不通。原因路径 MTU 不匹配。中间某段链路的 MTU 小于两端接口的 MTU大包被丢弃但 ICMP 差错报文可能被 ACL 挡了导致两端不知道需要分片。解决用ping指定包大小和 DF 位来测试路径 MTU。比如ping 192.168.2.1 size 1500 df-bit如果不通就逐步减小 size找到能通的最大值。然后在接口上调整 MTU 或者 TCP MSS。# 测试路径 MTU ping 192.168.2.1 size 1500 df-bit # 如果显示需要分片但设置了 DF 位说明路径 MTU 小于 1500 # 调整接口 MTU interface GigabitEthernet0/1 mtu 1400 # 两端都要调整或者只调整一端并配合 TCP MSS 调整 # 调整 TCP MSS interface GigabitEthernet0/1 ip tcp adjust-mss 1360 # 1360 1400 - 20(IP头) - 20(TCP头)5.4 排查时改了多个变量导致无法定位现象排查过程中改了好几个配置问题解决了但不知道到底是哪个改动起的作用。下次遇到同样问题还是不知道怎么处理。原因没有遵循“一次只改一个变量”的原则。解决每次只改一个配置改完立刻验证。如果问题解决记录下这个改动如果没解决回滚这个改动再试下一个。这样做虽然慢但能积累经验。下次遇到类似问题直接就能定位到原因。5.5 生产环境开 debug 导致二次故障现象为了排查问题开了 debug结果 debug 输出把 CPU 打满路由器直接失联业务中断范围扩大。原因debug 会消耗大量 CPU 和内存资源尤其是debug ip packet、debug ip nat这种针对每个数据包都输出的 debug流量大的时候能把路由器打挂。解决生产环境开 debug 必须满足三个条件一是在维护窗口内二是提前配好 ACL 限制 debug 范围三是设好no debug all的定时任务或者准备好带外管理通道。我一般会先用 ACL 的命中计数、NetFlow、或者镜像抓包来替代 debug实在需要 debug 的时候也会用debug condition来限制范围。6. 用日志和 NetFlow 做故障回溯事后也能找到原因6.1 配置日志服务器和日志级别路由器故障排查最遗憾的事情是问题发生了但日志没开什么线索都没留下。所以我的习惯是任何一台路由器上线第一件事就是配日志服务器。# 配置日志服务器 logging host 192.168.1.100 # 指定日志服务器地址 logging trap informational # 设置日志级别为 informational # 级别从 0 到 7数字越小越严重 # 0-emergencies, 1-alerts, 2-critical, 3-errors, 4-warnings, 5-notifications, 6-informational, 7-debugging logging source-interface Loopback0 # 指定日志源接口方便在日志服务器上过滤 logging buffered 16384 # 本地日志缓冲区大小单位字节 # 根据路由器内存调整一般 16384 到 65536 够用 service timestamps log datetime msec localtime # 日志时间戳精确到毫秒方便和抓包对比日志级别设成 informational 是比较平衡的选择。debugging 级别太啰嗦会消耗大量资源warnings 级别又可能漏掉关键信息。informational 能记录接口 up/down、协议邻居变化、认证失败等关键事件。日志服务器上可以用 syslog-ng 或者 rsyslog 来接收和存储日志。关键是做好日志轮转和归档别让日志把磁盘写满。我一般会保留至少 30 天的日志方便回溯。6.2 用 NetFlow 定位流量异常NetFlow 是排查流量异常的神器。它能告诉你谁在什么时候、向谁、发了多少流量。当路由器 CPU 高或者带宽跑满的时候NetFlow 能快速定位到异常流量的来源。# 配置 NetFlow以 Cisco 为例 interface GigabitEthernet0/1 ip flow ingress ip flow egress # 在接口上开启 NetFlow 统计 ip flow-export destination 192.168.1.100 2055 # 指定 NetFlow 收集器地址和端口 ip flow-export version 9 # 使用 NetFlow v9支持更多字段 ip flow-export source Loopback0 # 指定导出源接口 ip flow-cache timeout active 1 # 活跃流超时时间单位分钟 # 设短一点可以更快看到流量变化 ip flow-cache timeout inactive 15 # 非活跃流超时时间单位秒NetFlow 收集器可以用 nfdump、Elasticsearch Logstash、或者商业工具。关键是能按源 IP、目的 IP、端口、协议做聚合和排序。当带宽异常的时候按流量大小排序排在最前面的基本就是嫌疑对象。有一次某公司办公网出口带宽跑满用 NetFlow 一看内网一台主机的 445 端口在向外网大量发包明显是中了蠕虫。从发现到定位到主机前后不到五分钟。如果没有 NetFlow可能得折腾半天。6.3 日志和 NetFlow 的联动分析日志和 NetFlow 结合使用效果更好。日志告诉你“发生了什么事件”NetFlow 告诉你“流量是什么样的”。两者时间戳对齐就能还原出故障发生时的完整场景。比如接口频繁 up/down日志里能看到 up/down 的时间点NetFlow 能看到 up/down 期间流量是否中断、中断了多久。如果接口 up/down 的同时流量也中断了说明是链路问题如果接口 up/down 但流量没断说明是接口震荡但路由收敛得快影响不大。我一般会在日志服务器上配一个简单的告警规则接口 up/down、协议邻居变化、CPU 超过阈值、内存超过阈值这些事件触发告警。收到告警后先去 NetFlow 上看对应时间点的流量情况基本就能判断影响范围和严重程度。排查路由器故障这件事说到底就是两个习惯一是分层排查从物理层往上逐层排除二是留好数据日志和 NetFlow 配好事后能回溯。我踩过的最大的坑就是早期不重视日志出了问题只能靠猜重启完就过去了下次再来一遍。后来把日志和 NetFlow 配齐了很多问题在发生之前就能看到苗头比如接口 CRC 缓慢增长、CPU 周期性升高、会话表持续上涨这些都是故障的前兆。提前处理比出了故障再救火要从容得多。希望帮到你。本文还有配套的精品资源点击获取