嘿！兄弟们
身为网工，网络故障这事儿简直就像家常便饭。
要说处理方法，那真是各有各的招，没有标准答案。但要说能做好复盘、整理经验，让自己快速进步，这本事可就不是人人都具备的了。
很多人天天被工作追着跑，别说复盘了，连好好睡一觉的时间都挤不出来。可偏偏领导总免不了让你写个报告、做个总结、搞个汇报，这算是逼着你跟复盘来场深度交流了。
今天就想跟大伙聊聊：网络故障该怎么分析，分析报告又该怎么写才到位。
今日文章阅读福利：《网络故障分析报告合集》
扫添加小助理微信，备注【网络故障分析报告】，即可获取。
一般来说，排除网络故障可以参考这样的思路（具体可以看这张图）：
l定位故障范围
1. 全网性故障：大概率问题出在出口或核心区域；
2. 小范围故障：故障源可能在离问题点最近的设备或链路上；
3. 单点故障：基本可以锁定在故障设备自身。
l排查并解决故障
1. 总体思路是先查链路，再看配置。
2. 第一步，确认网络或相关设备近期有没有人为变更；
3. 第二步，检查物理链路、设备是否正常运行；
4. 第三步，排查网络设备的属性设置或配置是否有问题。
网上一搜，网络故障分析报告的模板五花八门，随便都能找出一堆。但从现在起，写报告前建议先琢磨两个问题：
1. 你所在的是国企还是私企？
2. 你是想随便应付一下，还是真想写份有价值的报告？
如果在国企，报告往往更注重形式和规范，格式、措辞都得格外讲究，能自由发挥的空间不大；
要是在私企，想写出点价值，既能在上级面前露一手，年底复盘时也能有料可查，那写法就能灵活不少。
下面这份网络故障报告就挺值得参考，内容生动，条理也清晰，能给大家提供不少思路。
1. 故障描述及部署位置
周五上午到用户现场了解情况，大致信息如下：
用户网络出口带宽20M，两台交换机下联30多台用户主机和服务器。从本周一开始，内网用户访问互联网时频繁断连，网页加载极慢，经常打不开。
随后在交换机1和交换机2上分别配置镜像端口，部署科来网络分析系统，抓取上联接口的流量进行分析。
2. 故障分析
交换机1：抓取了20分钟流量，未发现异常和流量突发，因此推测问题可能出在交换机2下联的主机上。
交换机2：在10:55:28-10:55:38这10秒内抓取的数据包中，很快发现了问题：
短短10秒内，总流量达272MB，几乎都是512-1023字节的数据包，其中TCP同步包超过50万个，却没有收到任何TCP同步确认包，明显存在异常。
查看TCP会话发现，所有会话行为一致，均为111.xx.xx.xx向183.xx.xx.xx的80端口发送TCP数据包。
进一步观察发现：
SYN数据包是TCP/IP建立连接时的握手请求包，本不应包含应用层数据，但这些数据包中却带有512字节的HTTP数据，且内容全为0，显然是伪造的数据包。
由于这些伪造数据包的目标是互联网地址，会通过出口向外发送。
而用户网络出口带宽仅20Mbps，伪造数据包的速率却高达261Mbps，远超出口处理能力，导致内网主机访问互联网时连接缓慢甚至失败。
3. 故障定位
通过MAC地址追踪，发现发送大量数据包的MAC地址为XX:XX:XX:XX:11:57。
查看交换机MAC地址表后，确定该MAC对应的是交换机2的G1/0/18端口。
断开该端口后，网络恢复正常，网页能流畅打开。
经排查，交换机2的G1/0/18接口发送了大量伪造的互联网地址数据包，因流量过大拥塞了网络出口，造成DOS攻击效果。
该端口连接的是邮件网关，建议用户联系设备厂商对邮件网关进行排查。
