作者：网络之路一天  首发公众号：网络之路博客（ID：NetworkBlog）

二层环路是什么？

在之前我们以这个拓扑把VLAN间互通已经全部讲解完毕了，但是该网络的IT遇到了一个问题，办公区一上行的线路偶尔出现问题，导致办公区一访问办公区三的资源失败，这个时候IT想着从办公区一到办公区三交换机之间加一根线路，实现，不管哪边出现问题都有一个冗余备份的线路存在，这样来解决线路故障导致业务不通的情况，但是奇怪的事情发生了，只要把这根线路接上个去，原本好的线路都访问不了业务了。

看看怎么回事

把环境简化下，办公区二暂时不看，中间接了一根线路（注意，配置还是引用的之前VLAN间互通的，注意，server记得开启服务）

办公区一交换机配置
interface  Ethernet0/0/4
 port link-type trunk
 port trunk allow-pass vlan 10 30
 
 办公区一交换机配置
interface  Ethernet0/0/4
 port link-type trunk
 port trunk allow-pass vlan 10 30

重现环境的时候，发现没有这个问题，这是因为华为、华三（主流版本）默认情况下开启了一个功能，STP防止环路的，那我们先关闭它，在来是怎么回事？（这也是实际中容易遇到的一种情况，不同的设备，版本不一样，某些功能默认开启与没有开启都不一样，导致结果完全不一样。）

[Core]undo stp enable
Warning: The global  STP state will be changed. Continue? [Y/N]y
Info: This operation  may take a few seconds. Please wait for a moment...done.
 
[bg1]undo stp enable
Warning: The global  STP state will be changed. Continue? [Y/N]y
Info: This operation  may take a few seconds. Please wait for a moment...done.
 
 
[bg3]undo stp enable
Warning: The global  STP state will be changed. Continue? [Y/N]y
//关闭STP功能

准备工作做好了（重启客户端，开启抓包）

确实如那IT所说把线路接上去后业务不通了，是不是很奇怪。

会发现PC2的ARP包一直在网络中重复的发送，服务器也会回应了ARP，但是最终没有到达过PC2，而是永无休止的在网络中发送着，一直在打环一样，这就是环路。

环路是如何产生的（该环境记得保存，下一篇要用）

（1）PC2发起对服务器的访问，发现ARP表项里面没有缓存，于是发起ARP请求。

（2）办公区1交换机收到以后，执行二层转发，先记录PC2的MAC地址、VLAN、接口信息，然后读取目的MAC发现是全F，于是开始对该VLAN内除源接口以外的所有接口开始泛红，会从E0/0/1与E0/0/4发送出去，这2个接口是Trunk，所以会透传VLAN 10。

（3）此时核心交换机与办公区三交换机都会收到这个ARP请求，它们会跟办公区一的转发机制一样，记录学习源MAC地址、接口、VLAN信息，发现目的MAC是全F，于是开始对该VLAN内除源接口以外的所有接口开始泛洪，核心交换机会从G0/0/3发送出去，办公区三会从E0/0/3与E0/0/1发出，其中Trunk链路保持VLAN透传，去往服务器的口access剥离标签。

目前三台交换机的MAC表记录信息

（4）这里情况就比较复杂了

服务器收到ARP请求后回应（从办公区一过来的）

办公区三交换机又从核心交换机方向E0/0/1口收到PC2的ARP请求包，这个时候办公区三交换机不会丢弃，它继续执行二层转发操作，把原有MAC表中PC2的记录，从原来的E0/0/4改成E0/0/1，并且发现目的MAC是全F，又泛洪，从除了该VLAN内的除源接口以外所有接口发出，这个时候E0/0/3接的服务器又会收到ARP请求，同时E0/0/4也会发出去，该接口属于trunk，透传。

核心交换机也会从G0/0/3 办公区三方向传过来PC2的ARP请求包，同样做二层转发操作，把原有的MAC表中PC2的记录，从原来的G0/0/1改成G0/0/3，同时泛洪操作，又从G0/0/1发出去，由于接口是trunk，所以透传。

目前三台交换机的MAC表记录信息

（5）更复杂的情况

服务器收到新的ARP请求，继续回应ARP

之前的ARP响应经过办公区三交换机打上VLAN 10的Tag，并且执行二层转发，学习记录服务器的MAC地址、VLAN、接口，同时查找目的MAC，从MAC表中找发现PC2的MAC从E0/0/1发出，由于是trunk保持透传。

办公区一从核心方向的E0/0/1口收到了一个ARP请求，通过二层转发机制，更新MAC记录信息，原本从E0/0/2，改成E0/0/1，然后目的MAC是全F，开始泛洪，从除了该VLAN内的除源接口以外所有接口发出，又从E0/0/2与E0/0/4发出。

同时又从办公区三交换机方向的E0/0/4收到，与上操作一样。

• 广播风暴：一个终端发出去的包在网络里面无休止的传递着，如果终端一多，那整个网络资源都被广播报文给占用完毕 ，最终链路与设备性能被消耗完毕。
• 重复帧：服务器会不断的收到ARP的请求，然后进行回应，对于服务器来说这就是一种无形的消耗，服务器必须去处理它，另外PC2也会收到自己的ARP请求，需要去解封装读取，然后发现不是就丢弃，这样的情况波及整个VLAN内的终·端，也会造成资源耗尽的情况。
• MAC地址表震荡（漂移）：从上面的MAC表分析的情况里看，PC2的MAC，主要在从不同接口收到包后，就会改版记录，而且最关键的PC2在办公区一交换机的E0/0/2口的，也变成了其他接口，这样来会的漂移导致地址表震动，消耗CPU的资源。

环路有什么样的现象（真实环境）

从上面可以看到，环路产生后，一个终端就能产生无数的数据包，如果多个终端在发送数据包，那整个网络环境的资源就会被这些环路产生的包，无休止的消耗完毕，严重的直接导致死机。

上面只是抓包感受不到什么现象，那来感受真实环境环路带来的冲击感。

这是一台有年代的华为设备，型号是3328-TP，目前是关掉了STP功能，我们来模拟下环路，看看会发生什么事情

现在访问外网没任何问题的

制造一个环路，14口跟16口的线路串接，打成了一个环路。

立马延迟变大，甚至开始丢包

设备CPU飙升至41%

2个接口之间的流量，占用34%

这台交换机下面的无线用户，卡的图片都发不出去。

拔掉以后，立马恢复。抓包还可以发现，不到几分钟就有500多万的包产生了，如果终端一多，这个数据包数量更加惊人！！

“承上启下”

可以看到这交换机并没有接多少终端用户，如果接满了，又出现环路的话，那整个网络就会被这种重复的广播、单播帧给把链路资源、设备CPU资源占满，最终导致瘫痪，所以二层环路的危害力是非常大的，也非常致命，影响整个网络的稳定性。下一篇来进入如何避免二层环路，使用到的技术。

作者：网络之路一天，公众号：网络之路博客（ID：NetworkBlog）。让你的网络之路不在孤单，一起学习，一起成长。