1. 从“救火队员”到“福尔摩斯”网络故障排除的思维跃迁干了这么多年网络运维我越来越觉得处理网络故障这事儿和侦探破案有异曲同工之妙。新手网工接到告警第一反应往往是“重启试试”或者对着命令行一通乱敲像极了无头苍蝇。而老手呢他们更像福尔摩斯接到“案子”故障后先不急着动手而是冷静地观察现场网络拓扑、设备状态、收集线索日志、告警、用户描述然后基于对网络协议和架构的深刻理解提出假设再通过一系列有逻辑的测试去验证最终精准定位“元凶”。今天我想分享的这9个案例不是什么高深莫测的黑科技而是我们这些“网络侦探”在日常工作中最常遇到的经典“案件”。它们覆盖了从接入层到核心层从物理线路到协议协商从配置错误到隐性环路。掌握它们不仅能让你在面试时从容应对技术拷问更重要的是能让你在实际工作中从被故障牵着鼻子走的“救火队员”蜕变为掌控全局、高效排障的“网络福尔摩斯”。2. 案例一用户抱怨“网络时好时坏”但设备指示灯一切正常这是最让人头疼的一类问题。用户反馈上网卡顿、丢包ping网关时延忽高忽低但你登录交换机一看端口UP光功率正常CPU/内存利用率也不高。新手很容易在这里陷入僵局怀疑是用户终端问题或者上层网络波动。2.1 排查第一步超越设备面板深入流量层面设备指示灯正常只代表物理链路和链路层协议如以太网是通的。问题可能出在更高层。我的第一反应是在用户接入的交换机端口上做流量镜像或者直接使用交换机的端口统计功能如show interface counters。关键看两个指标输入错误Input Errors和输出错误Output Errors特别是CRC、Frame、Giants、Runts这类错误。有一次我们遇到一个办公室间歇性丢包检查端口统计发现CRC错误计数在缓慢但持续地增长。这直接指向了物理层问题——数据帧在传输过程中因干扰发生了畸变。2.2 物理层“软”故障的定位艺术CRC错误增长但光模块收发光功率又在正常范围内这往往意味着链路存在“软”损伤。可能的原因包括光纤弯曲半径过小特别是跳线在机柜内被过度弯折虽然光能通过但模式失真导致误码。光纤接头污染灰尘、油污会导致光信号散射引入误码。这是最高发的原因之一。光模块或光纤老化性能劣化余量不足在温度变化或轻微振动时误码率升高。电磁干扰对于铜缆网线途经强电环境导致信号质量下降。处理心得对于这类问题不要怕麻烦。最直接有效的方法是“替换法”。按影响面从小到大的顺序进行先清洁或更换光纤跳线→更换光模块→更换设备端口→最后考虑更换整段光纤。在操作时务必在更换前后观察端口错误计数是否清零并停止增长。那次办公室故障我们就是通过更换一根看似完好的LC-LC跳线后CRC错误立刻消失网络恢复稳定。这个案例教会我设备指示灯是“及格线”而端口错误计数才是诊断物理层健康的“体检报告”。3. 案例二新配置的静态路由不生效数据包有去无回静态路由配置简单但排障时若思路不清也很容易绕晕。典型场景你在核心交换机上配了一条指向下一跳的静态路由但测试发现目的网络不可达。show ip route明明显示路由表里有这条路由为什么不通3.1 逐跳追踪理清数据包的“旅行地图”静态路由不生效核心是“有路由没路径”。你需要化身数据包走一遍它该走的路。排查遵循一个经典顺序本设备路由表 → 本设备ARP表 → 下一跳设备可达性 → 下一跳设备返回路径。查本设备路由表确认你配置的静态路由确实存在于路由表中且是活跃的管理距离和度量值最优。使用show ip route [destination]仔细核对。查本设备ARP解析这是最容易被忽略的一步路由指出下一跳是10.1.1.254但你的设备需要知道10.1.1.254的MAC地址才能封装数据帧。执行show arp | include 10.1.1.254如果这里没有条目或者条目不完整只有IP没有MAC说明ARP解析失败。可能原因包括下一跳地址本身不可达接口down、中间有防火墙拦截了ARP请求、或是在VLAN环境下本机接口不在下一跳IP所在的VLAN中。测试下一跳可达性从本机ping下一跳IP地址。如果不通回到链路层和物理层排查。确认对称路径有状态设备存在时数据包能过去还要能回来。如果路径中存在防火墙、NAT设备必须确保回程路由也正确。很多时候A点能ping通B点但B点ping不通A点问题就出在非对称路由或被状态设备拦截了返回流量。3.2 一个由VLAN配置引发的“血案”我曾处理过一个案例在三层交换机上配置了去往服务器网段的静态路由下一跳是防火墙的内网口地址。路由学习正常但就是不通。按照上述步骤排查路由表有。ping下一跳防火墙内网口通。ARP表空的没有解析到防火墙内网口的MAC。 这就奇怪了能ping通说明三层可达为什么没有ARP仔细检查接口配置发现那个ping通的源IP地址来自于交换机上一个用于管理的VLAN接口SVI而配置静态路由时数据包实际是从连接防火墙的物理端口出去的。这个物理端口属于另一个VLAN比如VLAN 10。问题来了交换机用管理VLAN的IP去ping防火墙得到了回应。但当它想为路由下一跳防火墙内网口IP发送ARP请求时这个请求是从VLAN 10的接口广播出去的。如果防火墙内网口不属于VLAN 10它根本收不到这个ARP请求自然不会回应。解决方案是要么在VLAN 10的SVI上配置一个IP作为与防火墙通信的源要么确保防火墙内网口也属于VLAN 10通常通过子接口或Trunk允许该VLAN实现。这个案例的教训是在多层交换环境中务必明确“源IP”和“出口VLAN”的对应关系ARP是二层广播它只在同一个广播域VLAN内生效。4. 案例三OSPF邻居关系反复震荡日志显示“状态机错误”动态路由协议故障是中级网工的试金石。OSPF邻居关系建立不起来或者建立后频繁断开日志里满是状态机变化的告警。面对海量日志从哪里入手4.1 构建OSPF邻接关系的“四要素”检查清单OSPF邻居关系建立必须满足四个基础条件我习惯称之为“四要素匹配”区域IDArea ID一致直连接口所属的OSPF区域必须相同。这是最常见的人为配置错误之一。认证类型和密钥匹配如果启用了认证无论是明文认证还是MD5类型和密码必须完全一致。注意密码是区分大小写的。Hello/Dead计时器一致默认的Hello时间为10秒广播/NBMA网络或30秒点对点/点对多点Dead时间是Hello时间的4倍。这些计时器必须在邻居间相同才能建立邻接。在跨厂商设备互联时尤其要注意检查。MTU值匹配这是一个隐蔽的杀手。在ExStart交换DD报文阶段双方会比较MTU。如果MTU不匹配邻居关系会卡在ExStart或Exchange状态。使用命令show ip ospf interface查看接口MTU并使用ip ospf mtu-ignore如果设备支持来忽略MTU检查作为临时排查手段。4.2 深挖底层当“四要素”都正常时如果以上四点都确认无误但问题依旧就需要向更底层挖掘底层链路稳定性OSPF依赖IP层连通性。如果底层链路如以太网本身存在频繁的闪断flappingOSPF邻居自然会跟着震荡。检查物理端口和链路协议是否有频繁的up/down日志。单播连通性OSPF使用组播地址224.0.0.5和224.0.0.6通信。确保组播报文没有被中间的ACL或者防火墙策略意外过滤。一个验证方法是暂时在接口上禁用OSPF然后从一台设备ping另一台设备的接口单播IP地址进行长ping测试ping -t或ping加大量次数观察是否有丢包或中断。资源耗尽在大型OSPF网络中如果LSDB过大而设备内存或CPU不足可能导致协议计算超时引发邻居重置。检查设备的CPU和内存利用率历史。实操技巧面对震荡问题不要只看OSPF日志。同时打开两个终端窗口一个持续ping对端接口IP另一个持续tail系统日志或OSPF调试日志谨慎使用debug建议在维护窗口。当ping中断时立刻观察日志输出往往能发现关联的底层链路事件或协议状态变化这是定位间歇性故障的黄金方法。5. 案例四VLAN间通信失败但各自网关都能ping通这是园区网经典故障。用户属于VLAN 10服务器属于VLAN 20它们都在同一台三层交换机上。从用户电脑能ping通自己的网关VLAN 10的SVI也能ping通服务器网关VLAN 20的SVI但就是ping不通服务器本身。问题出在哪5.1 排查思路聚焦于“三层交换机本身”既然能ping通两个VLAN的SVI说明三层交换机的路由功能是工作的IP层是通的。问题大概率出在数据包转发路径上。我们需要检查服务器的ARP表在服务器上执行arp -a查看它是否学习到了用户电脑的MAC地址或者它学习到的MAC地址是否正确如果服务器上没有用户电脑的ARP条目或者ARP条目中的MAC地址不是三层交换机VLAN 10的SVI MAC地址那么服务器回包时可能把应答包发给了错误的设备。三层交换机的代理ARP在某些配置下三层交换机可能没有正确执行代理ARP功能。当服务器要回包给用户电脑不同网段时它会先发送ARP请求询问用户电脑IP的MAC地址。理想情况下三层交换机应该用自己的VLAN 10 SVI接口MAC地址来应答这个ARP请求即代理ARP。如果代理ARP未启用或失效服务器就无法获取下一跳MAC通信失败。服务器的默认网关确认服务器的默认网关确实设置为VLAN 20的SVI地址。如果设错了它可能会尝试通过其他路径比如错误的网卡回复导致数据包被丢弃。主机防火墙/安全策略这是最容易被网工忽略但实际上是最高发的原因用户能ping通服务器网关只代表数据包到达了服务器所在的网段。但服务器本机的防火墙如Windows防火墙、iptables可能设置了规则阻止了来自用户网段或特定IP的ICMP回显请求ping或其他业务端口访问。务必在服务器上临时关闭防火墙进行测试这是关键的一步。5.2 真实案例被遗忘的服务器网关我遇到过一个典型案例现象完全符合上述描述。排查过程如下用户PC网关正确能ping通 VLAN 10和VLAN 20的SVI。三层交换机路由表正常show ip arp显示有用户PC和服务器的ARP条目。服务器能ping通自己的网关VLAN 20 SVI。但检查其网络配置时发现默认网关被错误地配置成了核心交换机的另一个管理地址而这个地址并不在服务器直连的VLAN 20网段。 这就导致了诡异的现象服务器ping自己真正的网关VLAN 20 SVI是通的因为这是二层通信。但当它要回复用户PC属于VLAN 10时它查询路由表实际上只有一条默认路由决定将数据包发给那个错误配置的网关。这个错误的网关可能存在于网络中但它没有回到用户PC的路由或者直接丢弃了数据包。解决方法就是修正服务器的默认网关。这个案例提醒我们排障时不仅要检查网络设备终端主机的网络配置永远是排查清单上的重要一项。6. 案例五STP网络中出现“神秘”的广播风暴生成树协议STP/RSTP/MSTP本是为了防环但配置不当或意外情况反而可能引发问题。一个典型的迹象是网络间歇性变慢交换机CPU利用率飙升抓包发现同一广播域内存在大量未知单播、广播或组播帧的复制泛洪。6.1 风暴的根源未被STP阻断的环路广播风暴的本质是二层环路。STP正常工作下应逻辑阻塞一个端口来破环。如果风暴依然发生意味着STP失效可能由于配置错误如所有交换机优先级相同导致根桥震荡、版本不兼容、或BPDU被过滤如在端口误配置了bpdufilter或bpduguard的违规场景。环路出现在STP域外例如两个端口被一根网线意外短接而这两个端口恰好都禁用了STP比如连接服务器的端口为了快速收敛而配置了portfast但未启用bpduguard这就形成了一个STP管不到的物理环路。单向链路故障这是非常隐蔽的一种情况。链路一端能发数据另一端能收数据但反向不通。这会导致STP的BPDU无法双向传递两台交换机都认为对方宕机从而同时将端口转为转发状态形成环路。6.2 排查与应急定位风暴源端口当风暴发生时网络可能已经半瘫痪登录设备都困难。此时需要冷静应急处理如果条件允许最快速的方法是分段隔离。从网络边缘开始逐台交换机、逐个端口拔线同时观察网络流量。当拔掉某根线后风暴停止那么这根线连接的两端端口就是可疑的环路点。定位风暴源在交换机上使用show interface counters或类似命令查看哪个端口的广播包Broadcast或输入包Input计数异常飙升远高于正常水平。这个端口很可能就是环路数据涌入的源头。检查STP状态风暴平息后立即检查相关交换机的STP状态。使用show spanning-tree查看各个端口角色。重点寻找是否存在两个或多个“指定端口”Designated Port连接在同一网段这通常意味着根桥选举异常。本应被阻塞Blocking的端口是否处于转发Forwarding状态查看端口是否收到了BPDU如果某个配置为access的端口收到了BPDU很可能下面违规接了一台交换机。经验之谈预防胜于治疗。对于所有连接终端PC、服务器、打印机的接入端口我强烈建议启用spanning-tree portfast并结合spanning-tree bpduguard enable。portfast让端口快速进入转发状态避免终端开机时网络等待超时而bpduguard则是一把安全锁一旦该端口收到任何BPDU意味着下面可能违规接了交换机立即将其置为err-disable状态从而杜绝了在接入层形成环路的可能性。这个组合是接入层端口的标准安全配置。7. 案例六DHCP获取不到地址但手动配置静态IP可以上网这个故障现象清晰地指向了DHCP服务过程出了问题。手动配置IP能通证明从客户端到网关、再到外网的基础网络路径是完好的。问题局限在DHCP协议的四个交互阶段Discover, Offer, Request, Ack中。7.1 扮演DHCP数据包梳理四步交互的断点我们需要模拟一个DHCP请求看它倒在哪一步。最有效的工具是在客户端和DHCP服务器所在的网络中进行抓包分析。客户端是否有发出Discover广播包在客户端网卡抓包查看是否能看到源MAC为客户机、目的IP为255.255.255.255、目的端口为67的DHCP Discover报文。如果没有问题在客户端可能是网卡驱动、防火墙、或客户端DHCP服务未开启。服务器是否收到并回应了Offer在DHCP服务器端或客户端所在VLAN的中间设备如网关交换机上做镜像抓包。查看服务器是否收到了Discover并回复了DHCP Offer报文目的IP为255.255.255.255目的端口68。如果服务器没收到Discover可能是DHCP中继Relay Agent配置问题。如果跨网段获取IP客户端广播的Discover报文无法直接到达服务器需要依靠网关三层交换机或路由器充当DHCP中继将广播包以单播形式转发到指定的DHCP服务器地址。检查中继设备的配置ip helper-addressCisco或dhcp relay server-ipHuawei等命令是否正确指向了DHCP服务器IP。Offer和Request是否被过滤如果服务器发出了Offer但客户端没收到或者客户端发出了Request服务器没收到Ack。需要检查路径上的ACL访问控制列表或防火墙策略是否意外拦截了UDP 67/68端口的流量。特别注意DHCP Offer和Ack报文是广播回复的除非之前已有中继介入防火墙规则需要允许广播流量。地址池耗尽或冲突服务器收到了请求但地址池中已无可分配的IP地址或者服务器检测到要分配的IP地址已在网络中存在通过ping检测则会拒绝分配。检查DHCP服务器的地址池使用率和租约情况。7.2 中继场景下的特殊“坑”giaddr字段在DHCP中继场景中有一个关键字段叫giaddr网关IP地址。中继设备在转发Discover报文时会将自己收到广播的接口IP填入这个字段。DHCP服务器根据giaddr来判断客户端属于哪个子网从而从对应的地址池中分配IP。如果中继设备的接口IP配置错误例如配置了一个不在客户端网段的IP或者有多个中继设备导致giaddr被意外修改服务器就会选错地址池分配一个错误的网段IP给客户端导致客户端无法通信。排查时务必在抓包中查看DHCP报文里的giaddr字段值是否符合预期。8. 案例七ACL应用后部分流量被意外阻断访问控制列表是网络安全的基石但配置不当也会成为故障之源。常见情况是你配置了一条ACL意图阻断A到B的某个端口结果发现A到C的正常业务也被阻断了。8.1 理解ACL的“隐式拒绝”与匹配顺序ACL故障排查首先要吃透两个核心规则隐式拒绝所有Implicit Deny Any在任何ACL的末尾都有一条看不见的规则deny ip any any。这意味着如果一个数据包没有匹配上ACL中任何一条明确的permit规则它将被默认拒绝。很多故障源于只配置了permit规则却忘了在末尾添加一条permit ip any any来放行其他流量。自上而下的匹配顺序ACL像一道检查关卡数据包从第一条规则开始比对一旦匹配就立刻执行动作允许或拒绝并停止继续向下匹配。规则的顺序至关重要。一个常见的错误是把一条范围较广的deny规则放在了前面而后面针对特定IP的permit规则就永远没有机会被匹配到。8.2 精准定位是ACL写错了还是应用错了排障时要分两步走第一步检查ACL内容本身。使用show access-lists [ACL-number/name]查看。仔细核对源/目的IP、通配符掩码、协议和端口号。一个高频错误是通配符掩码Wildcard Mask使用错误。它和子网掩码相反0表示需要匹配1表示忽略。例如要匹配192.168.1.0/24这个网段正确的写法是192.168.1.0 0.0.0.255。如果写成0.0.0.255 192.168.1.0就完全错了。第二步检查ACL的应用位置和方向。ACL必须被应用到接口的特定方向入方向in或出方向out才会生效。使用show ip interface [interface-name]查看接口上应用的ACL。方向错误会导致完全不同的效果在入口in应用是过滤进入该接口的流量在出口out应用是过滤从该接口出去的流量。此外还要确认ACL是否应用在了正确的接口上。避坑指南在编写复杂的ACL时我习惯先用permit ip any any log作为最后一条规则并应用到一个测试接口。这样所有被前面规则拒绝的流量都会因为匹配这条日志规则而生成系统日志。通过查看日志我可以清晰地看到哪些流量被“隐式拒绝”了从而反向推敲出需要补充的permit规则。这是一个非常高效的调试方法。完成调试后记得移除这条带日志的规则因为它会影响性能。9. 案例八NAT转换失败内网用户无法访问互联网NAT网络地址转换是现代企业网络出口的标配。故障现象通常是内网用户无法打开网页但能ping通出口网关防火墙或路由器的内网口。9.1 建立NAT会话的“三重检查”NAT转换是一个有状态的过程。一个内网IP访问外网需要成功创建一条NAT会话。排查时在出口设备上检查这三个点路由可达性出口设备是否有默认路由指向互联网下一跳执行show ip route或ping外网地址测试。NAT策略匹配检查NAT配置如ACL定义的内网地址范围、NAT地址池或接口。确认发起访问的内网IP地址是否被NAT策略所覆盖。例如策略只转换192.168.1.0/24而故障用户IP是192.168.2.10那么他的流量就不会被转换。会话表Session Table查看这是最关键的一步。在防火墙或路由器上使用show nat translationsCisco或display session table华为等命令查看是否有该内网IP发起的NAT会话条目。如果没有条目说明流量没有匹配NAT策略或在前序环节被丢弃。如果有条目但状态异常则可能是后续问题。9.2 超越NAT防火墙策略与ALG的考量很多时候NAT本身配置正确但流量依然不通问题出在NAT的“伙伴”——防火墙上。出口防火墙策略NAT转换后的流量在离开设备前还需要经过出口方向的防火墙安全策略检查。必须确保有一条策略允许从内网区域Trust到外网区域Untrust使用转换后的公网IP或直接允许源地址为NAT地址池的流量通过。这是一个经典的遗漏点工程师配好了NAT却忘了在防火墙上“开墙洞”。应用层网关ALG对于一些特殊协议如FTP、SIP、H.323等它们会在协议的控制信道中携带IP地址和端口信息。普通的NAT只转换IP包头无法修改这些嵌入在数据载荷里的地址会导致协议交互失败。这就需要启用ALG功能。例如FTP协议在主动模式下客户端会告诉服务器“请连接我的IP:端口”如果这个IP是内网地址外网服务器根本无法连接。FTP ALG会动态监控FTP会话修改这些载荷中的地址信息并为此临时开放所需的数据端口。如果遇到FTP无法传输文件、视频会议无法建立等问题在排除基础网络和NAT后应检查相应协议的ALG功能是否已启用。10. 案例九链路聚合LACP一端Active一端Passive聚合口却起不来链路聚合EtherChannel/LAG用于增加带宽和冗余。配置好后物理端口灯亮了但聚合逻辑口就是down的或者只有部分物理链路被加入。10.1 LACP协商的“握手”逻辑LACP模式分为active主动和passive被动。active模式会主动发送LACP报文发起协商passive模式则只响应收到的LACP报文自己不主动发起。成功组合两端都是active或者一端active一端passive。因为只要有一方主动发起另一方即使是passive也会回应协商就能进行。失败组合两端都是passive。双方都在等对方先开口结果永远沉默聚合组无法建立。所以理论上“一端Active一端Passive”是标准且推荐的配置不应该起不来。如果起不来问题通常不在模式本身而在其他参数不匹配。10.2 聚合组建立的“一致性”检查清单当聚合口无法up时请按顺序核对以下清单物理条件参与聚合的端口必须物理up速率、双工模式必须一致最好都配置为自协商。VLAN成员关系所有聚合成员端口必须属于相同的VLAN如果是Access口或者拥有相同的Trunk允许VLAN列表和原生VLANNative VLAN。聚合组编号与模式两端设备上将物理端口加入的聚合组编号如Channel-group 1可以不同这取决于厂商。但聚合模式必须兼容。例如一端配置为mode activeLACP另一端也必须配置为LACP模式active或passive不能一端是LACP另一端是静态on模式。关键端口配置必须一致这是最深的水坑。在将端口加入聚合组之前所有二层、三层的配置必须只在聚合逻辑接口Port-channel/Bridge-aggregation上配置而不是在物理成员端口上配置。如果在物理端口上配置了IP地址、STP参数、端口安全等在加入聚合组时会产生冲突导致聚合失败。正确的做法是先创建聚合逻辑接口并做好所有配置然后将物理端口以“空配置”状态加入该聚合组。排查命令在交换机上使用show etherchannel summary来查看聚合组状态。你会看到每个成员端口的状态标志常见的如P端口在聚合组中且物理层up。D端口被配置为聚合成员但因为某些不一致如速率、VLAN而处于down状态。I端口被配置为聚合成员但未检测到对端聚合信息检查对端配置和线缆。s端口处于standalone模式即它被配置为聚合成员但未能成功聚合仍作为独立端口工作。看到D或I状态就根据上述清单逐一排查。一个黄金法则是聚合组的配置是“自上而下”的所有策略应用于逻辑口物理口只负责搬运数据。遵循这个原则能避免绝大多数聚合配置故障。
