01

网络故障怎么分析？

一般来说，网络故障排除思路，你可以参考这张图：

1. 定位故障范围

①全网性网络故障：可定位故障源在出口或核心区域；

②小范围网络故障：可定位故障源在离故障源最近的相应设备或链路；

③单点性网络故障：可定位故障源在故障源自身。

2. 排除故障

①总体上思路为“链路”à“配置”。

②首先确认网络或相关设备是否出现人为变更；

③其次检查物理链路、设备是否正常；

④最后检查网络设备的相关属性或配置。

02

网络故障分析报告

怎么写合适？

网络故障分析报告，其实很多网上都有模板，你随意一搜，五花八门啥都有。

但从今以后，你写报告的时候，老杨希望你能思考2个问题：

1. 你在国企还是私企？

2. 你想应付还是真的想写的有点价值？

如果你在国企，你写报告更多是形式上的文件形式，你需要格外注重格式和措辞，这个时候，你能发挥的空间不大。

如果你在私企，想写的有点价值，在上级面前表现表现，也能在年终给自己复盘时找点看头，完全可以写的随意一些。

下面这份网络故障报告，就可以作为参考。写的很生动形象，也能给他人借鉴和学习。

01 故障描述及部署位置

周五上午去用户处了解故障现象，并询问网络基本情况，了解情况如下：

如上图，用户网络出口带宽为 20M，两台交换机下联 30 多个用户主机与服务器。从本周一开始出现网内用户访问互联网时出现时断时续的状态，打开页面速度非常缓慢，而且经常存在不能打开网页的情况。

于交换机 1 和交换机 2 分别配置镜像端口，部署科来网络分析系统，抓取上联接口的流量进行分析。

02 故障分析

交换机 1：在交换机 1 抓取了二十分钟，并未发现异常情况与流量突发，所以怀疑本次问题可能是由于交换机 2 下联主机存在问题所致。

交换机 2：抓取 10:55:28-10:55:38 的数据包，短短十秒钟我们就发现了网络中存在的问题，如下图：

不难看出，短短十秒钟的总流量达到了 272MB ，基本全部是 512-1023字节的数据包，并且 TCP 同步包达到了 50 余万个，没有收到任何的 TCP 同步确认包，存在明显的异常情况。

查看TC 会话，发现所有的TCP会话行为一致，全部是111.xx.xx.xx 向183.xx.xx.xx 的 80 端口发送TCP 数据包。

数据包的同步位置：

SYN数据包是 TCP/IP 建立连接时使用的握手请求数据包，不应存在任何应用层数据，但是在上图中看到该数据包中还有512字节的 HTTP 数据，并且数据内容全部为0，该数据包为明显的伪造数据包。

因为伪造数据包为互联网地址，所以会通过互联网出口向外发送。由于本网络互联网出口为 20Mbps ，而伪造数据包却达到了 261Mbps ，明显超过了最大处理能力。

此时内网主机在访问互联网时就会出现连接十分缓慢，甚至不能访问互联网的情况。

03 故障定位

如上图，通过查看MAC地址我们得知发送大量数据包的MAC地址为XX:XX:XX:XX:11:57，掌握了发起攻击的MAC 地址后，通过查看交换机MAC 地址表，找到相应端口，如下图：

该 MAC 地址对应的交换机 2 端口为 G1/0/18 口，通过断掉该接口的方式来排查，断掉该端口后网络恢复正常，能够正常流畅的浏览网页。

04 总结

通过排查，发现交换机 2 的 G1/0/18 接口发送大量互联网地址伪造数据报，通过大量发送此类数据包拥塞网络的互联网出口，达到 DOS 攻击作用。

通过排查发现 G1/0/18 口为邮件网关连接端口，建议用户联系邮件网关设备厂商，对设备进行问题排查。

最后想和你提提，要搞定网络故障，你需要掌握三个维度的技术：

1. 熟悉OSI七层模型与TCP/IP协议栈

2. 了解网络通信的基础设备和其对应的OSI层次

3. 清楚知道网络排错的一个重要原则-数据走向

像交换机、三层交换机、路由器、防火墙这些最基本的网络设备应该要有些了解，尤其是它们对应的OSI层次以及作用。这些都是基础和经验堆起来的。

内行人都知道，只要你的网络基础足够扎实，你才能更好的在网工生涯里提升和进步。

---END---