3. 网络故障诊断：一般流程与工具
说实话，干了这么多年网络运维，我最大的体会就是——出故障不可怕，可怕的是不知道从哪下手。很多新手一上来就抓包，或者直接重置端口，这其实是在碰运气。今天咱们就把网络诊断这事，拆成一套标准动作。
3.1 诊断前的三层脑图
我个人习惯，不管接到什么告警，先在脑子里过一遍网络的三层结构。你想想看，所有网络故障，跑不出下面这三类问题：
- 数据平面问题：报文转发路径上出了问题。比如接口Down、CRC错误、丢包、带宽打满。
- 控制平面问题：路由协议、STP、ARP等控制协议出了问题。比如路由表错误、环路、邻居震荡。
- 管理平面问题：SNMP、SSH、Syslog等管理通道不可达。比如管理口Down、ACL误封。
关键点：数据平面问题是MAC计数器最擅长的战场。丢包、错包、CRC错误，计数器上一目了然。但如果是控制平面问题，计数器往往只能看到表象，需要配合日志和抓包定位。
3.2 标准诊断流程：六步走
标准诊断流程一般分为六个阶段。我做故障处理规范化项目时，用过很多套流程，这套最顺手。大家可以直接套用。
| 阶段 | 做什么 | 常用工具 | 输出 |
|---|---|---|---|
| ① 确定问题范围 | 谁受影响？何时开始？影响面多大？ | 工单系统、人员反馈 | 问题单初筛结果 |
| ② 收集基础信息 | 采集告警、日志、计数器快照 | 网管平台、CLI、Syslog | 三张快照：告警+日志+计数 |
| ③ 故障隔离 | 缩小范围到某个接口、某台设备 | ping/tracert、MAC计数器 | 疑似故障点列表 |
| ④ 根因分析 | 钻进去看具体原因：是错包还是丢包？ | 抓包工具、流表分析 | 根因结论 |
| ⑤ 制定解决方案 | 明确修复动作（重启、换线、改配置等） | 变更管理工具 | 变更方案文档 |
| ⑥ 验证与复盘 | 确认恢复，生成一份事故报告 | 计数器对比、长ping | 故障复盘报告 |
我的经验：第②步“收集基础信息”是最容易被跳过的。很多人上来就猜，结果折腾半天才发现问题早被日志记录过。我的习惯：收到告警后，前5分钟只收集，不做任何操作。
3.3 常用诊断工具一览
工具不在多，会用才灵。我把常用工具按功能分了四类，你对照看看自己哪些用得熟。
3.3.1 连通性测试工具
- ping：检查IP层是否可达。我个人习惯先用连续ping（ping -t / ping 192.168.1.1 -c 100），看有没有间歇性丢包。
- traceroute / tracert：看路径走到哪断了。遇到大延迟，能看出是哪跳跳变异常。
- telnet / ssh：测试端口通不通。记得用telnet IP PORT的方式，比抓包快多了。
3.3.2 二层诊断工具
- MAC地址表：看报文从哪个端口学习到的。我遇到过一个环路问题，就是靠MAC地址反复横跳发现的。
- ARP表：看邻居的IP和MAC对应关系。ARP表错乱，就等着丢包吧。
- MAC计数器：查看接口的错包、丢包、CRC错误等。这是咱们这门课的核心，后面会花几讲专门讲它。
3.3.3 三层诊断工具
- 路由表：看报文下一跳是谁。路由黑洞是最坑的，路由表里明明有条，但下一跳可达性已经没了一半。
- ACL匹配测试：有些设备支持traffic-filter test，可以模拟一个报文，看被哪条ACL匹配上了。排查策略丢包时特别好用。
- NetFlow / sFlow：看应用层流量分布。我记得有一次核心链路利用率冲到95%，网管说是广播风暴，结果sFlow一查，是某台服务器在刷视频。
3.3.4 高级诊断工具
- Wireshark / tcpdump：抓包分析。不到万不得已不用，因为数据量太大。但真到了查协议层面的Bug，缺它不行。
- SNMP + MIB浏览器：批量采集设备状态。我建议把关键的MAC计数器MIB节点都查出来，在监控平台里引进去。
- 诊断命令（debug）：慎用。我一朋友在生产环境用debug ip packet，把CPU打满了，差点酿成事故。
3.4 如何结合MAC计数器做故障隔离
说了这么多工具，我们来串一下。MAC计数器在故障隔离阶段，是效率最高的工具之一。为什么这么说？因为它不产生额外流量，不侵入设备，你只需要一条show命令。
我遇到丢包投诉时，操作流程是这样的：
- 先看接口状态和错误计数器：show interfaces。重点关注CRC、runts、giants、input errors、output errors。
- 对比正常基线：如果平时CRC约等于0，现在每分钟涨几百个，那基本上就是物理层的问题了。换线换光模块，大概率能解决。
- 区分方向：入口丢包和出口丢包，根因完全不同。入口丢包多半是物理问题或流量突增；出口丢包则要看队列调度。
- 用计数器验证恢复：做完修复动作后，马上再看一遍计数器。如果计数器不再增加，说明物理问题解了；如果还涨，说明思路不对。
避坑指南：我曾经处理过一个丢包案例，CRCS一直在涨，我换了两根线、一个光模块、一块板卡。折腾了两小时，最后发现是光模块插反了——发送端和接收端接错了。大家一定要先检查线缆和模块的物理兼容性。
3.5 本章知识：一张图串起来
下面这张图把本章的知识体系画成了故障诊断的决策流。你可以把它贴在工位上。
图中箭头方向就是标准的故障处理顺序。大家注意到没——MAC计数器在第二步就登场了，并且在验证阶段又出现一次。这就是“基于MAC计数器的诊断”的本意：用计数器做快速筛查，用计数器做恢复验证。
3.6 本节重点回顾
- 网络故障分三层：数据平面、控制平面、管理平面。计数器最擅长处理前两种。
- 标准流程六步走：范围→采集→隔离→分析→解决→验证。每一层都有对应的工具。
- 工具按功能分四类：连通性测试、二层诊断、三层诊断、高级分析。结合使用效率最高。
- MAC计数器是隔离阶段的“第一把刀”，快且不侵扰设备。
- 记住：先收集，后操作。前5分钟只收集信息，不动配置。