网络环路故障解决分析

网络环路故障解决分析

以太网中的交换机之间存在不恰当的端口相连会造成网络环路，假如相关的交换机没有打开STP功能，这种环路会引发数据包的无休止重复转发，形成广播风暴，从而造成网络故障。我们在校园网的维护过程中多次碰到过这种故障，其中有一次排除故障的过程令我们印象深刻。

故障描述

一天，我们在校园网的网络运行性能监控平台上发现某栋搂的VLAN有问题——其接入交换机和校园网的连接中断。检查放置在网络中央的汇聚交换机，测得和之相连的100BASE －FX端口有大量的入流量，而出流量却很少，显得很不正常。然而这台汇聚交换机的性能似乎还行，感觉不到有什么问题。于是，我们在这台汇聚交换机上映像这个异常端口，用协议分析工具Sniffer来抓包，最多时每秒钟居然能抓到10万多个。对这些数据包进行简单分析，我们发现其中一些一起特征（如图1）。

图1 抓包数据

1、绝大部分的包长为62个字节（加上4字节的差错检测FCS域即为66个字节），TCP状态为SYN；

2、源IP为其他网段的IP、目的IP均为该楼网段的IP；

3、尽管源IP地址不同，但源MAC地址却是相同的；

4、目的IP地址和目的MAC地址和在这台汇聚交换机上绑定该楼VLAN的IP—MAC参数一致；

5、实际的数据流向（流入）和这些数据包中的源IP地址和目的IP地址所确定的流向（流出）相反。

当时，我们急于尽快抢修网络，没去深究这些数据包的特征，只看到第1点就以为网络受到不明来历的Syn Flood攻击，估计是由一种新网络病毒引起，马上把这台汇聚交换机上该端口禁用掉，以免造成网络性能的下降。

故障排除

为了能在现场测试网络的连通性，在网络中央，我们把连接那栋大楼接入交换机的多模尾纤经光电转换器用双绞线连到一台PC上，并将其模拟成那个问题VLAN的网关。然

后，到现场找来大楼网管员，想让他协助我们尽快把感染了未知病毒的主机查到并隔离。据大楼网管员反映，昨天网络还算正常，但是，当时本大楼某部门正在做网络调整，今天上班就发现网络不行了，不知跟他们有没有关系。我们认为调整网络应该跟感染病毒关系不大。

在大楼主配线间，我们把该接入交换机上的网线都拔掉，接上手提电脑，能连通网络中央的测试主机。我们确认链路没问题后，每次将剩余网线数量的一半插回该交换机，经测试没问题则如是继续下去，否则换插另一半，逐渐缩小怀疑有问题网线的数量。我们最终找到一条会引起问题的网线，只要插上这根网线，该大楼网络就会和模拟网关中断连接。经大楼网管员辨认，这条网线是连接昨天在做网络调整的那个部门的。他还说以前该部们拉了一主一备两条网线，应该更有一条，并亲自在那台交换机上把另一条找了出来。随意插上这两条网线中的一条，网络没问题，但只要同时插上，就有问题，哪有在一台交换机上同时插上两条网线才会激活网络病毒的SYN Flood攻击的？这时我们倒是觉得这种现象更像是网络中有环路。

我们到了那个部门发现有三台非管理型交换机，都是串在一起的，然而其中两台又分别通过那两条网线和接入交换机相连，从而导致了网络环路（如图2）。显然是施工人员对网络拓扑不清楚，当时大楼网管员有事外出，就自以为是地把线接错了，从而造成了这起网络事故。原因找到就好办了，只需拔掉其中一条上连网线（例如，图2的虚线）即可恢复网络连通。

图2 接入上联线

经过一番周折，网络恢复了正常，但我们还一直在想，是什么干扰了我们的判断呢？故障分析

一起典型的网络环路故障，用协议分析工具Sniffer抓了这么多的数据包，经过一番分析却没看出问题来。显然，第一眼看到大量的SYN包让我们产生了错觉，想当然地就以为是SYN Flood攻击。事后，我们就这起网络环路故障排除过程做了检讨，重新仔细地分析抓回来的这些数据包，据此解释一下前面提到这些数据包所具备的5个一起特征，以便今后碰到同类问题时能及时作出正确的反应。

先看前4个特征：汇聚交换机是网络层设备，该大楼所属VLAN的网络层接口就配置在这台汇聚交换机上，出于实施网络管理策略的需要，对已注册或没注册的IP地址都进行了MAC地址的绑定。TCP连接要经过3次握手才能建立起来，在这里发起连接的SYN包长度为28个字节，加上14个字节的以太帧头部和20个字节的IP报头，由Sniffer捕获到的帧长度共为62个字节（不包含4字节的差错检测FCS域）。恰巧当时访问该VLAN的单播帧是来自外网的TCP请求包，根据以太网桥的转发机制，通过CRC正确性检测后，因已做静态ARP配置，这台汇聚交换机会将该单播帧的源MAC地址转换成本机的MAC地址，其目的MAC

地址依据绑定参数来更换，并重新计算CRC值，更新FCS域，经过这样重新封装后，再转发到那栋楼的接入交换机。

再看最后1个特征：我们把图2所示的拓扑图抽象为如图3所示的由网桥A、B、C、D 构成的拓扑图。网桥是一种存储转发设备，用来连接相似的局域网。这些网桥在任何端口上监听着传送过来的每一个数据帧，利用桥接表作为该数据帧的转发依据。桥接表是MAC

地址和用于到达该地址的端口号的一个“MAC地址－端口号”列表，他利用数据帧的源MAC 地址和接收该帧的端口号来刷新。网桥是这样来使用桥接表的：当网桥从一个端口接收到一个数据帧时，会先刷新桥接表，再在其桥接表中查找该帧的目的MAC地址。假如找到，就会从对应这个MAC地址的端口转发该帧（假如这个转发端口和接收端口是相同，就会丢弃该帧）。假如很难找到，就会向除了接收端口以外的其他端口转发该帧，即广播该帧。这里假定在整个转发过程中，网桥A、B、 C和D都在其桥接表中查很难找到该数据帧的目的MAC 地址，即这些网桥都不知道应该从哪个端口转发该帧。当网桥A从上联端口接收到一个来自上游网络的单播帧时，会广播该帧，网桥B、C收到后也会广播该帧，网桥D收到分别来自网桥B、C的这个单播帧，并分别经网桥C、B传送回网桥A，到此网桥A收到了该单播帧的两个副本。在这样的循环转发过程中，网桥A不停地在不同端口（这时已不涉及上联端口了）接收到相同的帧，由于接收端口在改变，桥接表也在改变“源 MAC－端口号”的列表内容。前面已假定网桥的桥接表中没有该帧的目的MAC地址，网桥A在分别收到这两个单播帧后，都只能再次向除了接收端口以外的其他端口广播该帧，故该帧也会向上联端口转发。

图3 抽象后的拓扑图

就每个单播帧而言，网桥A重复前面提到的过程，理论上，广播一次会收到21个帧，广播两次就会收到22个帧，…，广播到第n次就会收到2n个帧。总之，网桥A照这样转发下去，很快就会形成广播风暴，这个单播帧的副本最终会消耗完100BASE-X端口带宽。尽管在这期间上联端口会有许多数据帧在相互碰撞而变的不完整，令Sniffer捕获不到，但能够想象得到这个单播帧的重复出现次数仍然会很多。我们再次检查那些抓回来的数据包，几乎都发现有当时没有注意到的重复标志（Retransmission of Frame n，这里的n是整数，表示接收到的第几个帧，见图1）。按64字节包长来计算，以太网交换机的100BASE-FX端口转发线速可达144000pps。在这种网络环路状态下，Sniffer完全有可能每秒抓到10万多个包长为66字节的数据包。

基于上述理由，由于当时那4台交换机（如图 2所示）的桥接表中都没有该包的目的MAC地址，处于上游网络的这台汇聚交换机向该大楼发送了一个TCP请求包后，就会不断地收到由该大楼接入交换机转发回来的该TCP包的副本，而且数量很地多（形成大流量），然而，他并不会把接收到的这些包重发回去；Internet的网络应用是基于请求/应答模式的，只有发送/接收两条信道都畅通，才能进行端到端的通信。一旦本次网络应用中有一条信道