实例剖析：网络环路轻视不得(组图)

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

　　故障描述

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

　　

　　图1 抓包数据

　　绝大部分的包长为62字节(加上4字节的差错检测FCS域即为66字节)，TCP状态为SYN。

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

　　尽管源IP地址不同，但源MAC地址却是一样的。

　　目的IP地址和目的MAC地址与在这台汇聚交换机上绑定该楼VLAN的IP-MAC参数一致。

　　实际的数据流向(流入)与这些数据包中的源IP地址和目的IP地址所确定的流向(流出)相反。

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

　　故障排除

　　为了能在现场测试网络的连通性，在网络中心，我们把连接那栋大楼接入交换机的多模尾纤经光电转换器用双绞线连到一台PC上，并将其模拟成那个问题VLAN的网关。然后，到现场找来大楼网管员，想让他协助我们尽快把感染了未知病毒的主机查到并隔离。据大楼网管员反映，昨天网络还算正常，不过，当时本大楼某部门正在做网络调整，今天上班就发现网络不行了，不知跟他们有没有关系。我们认为调整网络应该跟感染病毒关系不大。

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

　　我们到了那个部门，发现有3台非管理型交换机都是串在一起的，然而其中两台又分别通过那两条网线与接入交换机相连，从而导致了网络环路(如图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的网络应用是基于请求/应答模式的，只有发送/接收两条信道都畅通，才能进行端到端的通信。一旦本次网络应用中有一条信道被堵塞了，就会使得该应用因无法进行而结束。网络应用结束后，一般来说，发起请求一方不会就本次应用再次自动发出请求包。于是，在网络环路状态中普遍会有一条信道有大流量，另一条信道几乎没有流量的现象。因为VLAN有隔离广播域的功能，这些大流量不会穿越网络层，所以不会对汇聚交换机造成很大压力。

　　事实上，由于这种网络环路是数据链路层上的故障，只涉及到源MAC地址和目的MAC地址，不管高层封装的是什么类型的包都有可能引起广播风暴。也就是说，当时用Sniffer抓到各种各样的数据包都是有可能的。

　　故障预防

　　校园网的接入层是面向用户的网络界面，有许多不可控的成分，情况很复杂，应由专人管理，也应在设备上给予可靠性保证。本楼接入交换机是可管理型的，有STP功能，其他交换机都是非管理型交换机，没有STP功能。本来事先在该接入交换机上配置了STP功能，这起网络事故是完全可以避免的，但不知何故没有这样做，事后再做只能权当“亡羊补牢”了。从图2可见，即使接入交换机打开了STP功能，下游网络也会因某种原因构成环路，产生广播风暴，造成对上游网络本VLAN的冲击，故该接入交换机还应有广播包抑制功能，以便能将影响限制在局部范围内。对于下游网络的交换机同样有这些需求，只是成本问题而已。一句话，在网络故障排除时，技术和经验固然重要，但在平时就要注意维护网络的规范连接，落实基本的防范措施更为重要。