1. 网络故障排查概述

做网络运维这些年，我处理过上千起故障。从交换机端口闪断到数据中心级联中断，从DNS解析慢到BGP路由黑洞——说白了，网络故障千奇百怪，但排查思路是有章可循的。这一章，我们先搭个框架。

1.1 网络故障的常见分类

我个人习惯把故障分成三类。这样分类不是为了好看，而是为了快速定位排查方向。

故障类型	典型表现	常见原因
连通性故障	ping不通、丢包、延迟高	物理链路、配置错误、路由缺失
性能故障	带宽跑不满、应用卡顿、TCP重传	拥塞、MTU问题、硬件瓶颈
应用层故障	DNS解析失败、HTTP 502、SSL握手失败	配置错误、证书过期、后端异常

我在项目中遇到过一种情况：用户反馈“网页打不开”，但ping网关和DNS都正常。这就是典型的应用层故障，如果按连通性去排查，会浪费大量时间。所以，先分类，再动手。

1.2 排查思路：从现象到根因

很多新手一上来就抓包，或者直接重启设备。嗯，这其实不太对。我建议遵循一个基本流程：

1. 确认现象——用户说“上不了网”，你得问清楚：是全部上不了，还是某个网站？有线还是无线？
2. 缩小范围——影响面有多大？单台设备、一个楼层、还是整个园区？
3. 分层排查——从物理层开始，逐层往上。物理层没问题，再看数据链路层、网络层……
4. 日志定位——这是我们的核心。设备日志、系统日志、应用日志，能告诉你发生了什么。
5. 验证修复——改完配置后，确认故障是否消失，并且没有引入新问题。

你想想看，如果物理光纤都被挖断了，你在交换机上配再多VLAN也没用。所以，排查顺序很重要。

1.3 日志的重要性

为什么单独把日志拿出来讲？因为它是故障排查的“黑匣子”。

我记得有一次，某核心交换机半夜出现间歇性丢包。现场值班人员重启了设备，问题暂时消失。但第二天又复现了。后来我调出那段时间的日志，发现设备在丢包前几秒，有一条 %LINEPROTO-5-UPDOWN 的告警——某个光模块的收光功率在临界值附近抖动。说白了，是光模块快挂了，而不是设备本身的问题。

如果没有日志，你只能靠猜。有了日志，你就有证据。

日志能告诉我们什么？

• 时间线——故障什么时候开始，什么时候结束。
• 事件序列——故障前后发生了什么，有没有关联事件。
• 错误码——设备或系统给出的明确错误信息。
• 趋势数据——比如接口流量、CPU利用率的变化曲线。

1.4 故障排查知识体系

下面这张图，是我自己总结的排查知识体系。你可以把它当作一张地图，遇到故障时，先看自己在哪个位置。

1.5 避坑指南