物理环路造成网络风暴，无法访问交换机故障处理过程

问题处理过程：

一天下午，突然工位的pc192.168.205.201无法ping通机柜汇聚交换机192.168.205.15，ping的结果是无法访问目标主机。

已知，公司组网如下图：

查看arp -a发现没有192.168.205.15的mac地址。长ping192.168.205.15，用cmd下的windump命令（类似tcpdump）跟踪执行windump -i 1 -nne arp[14:4]=0xc0a8cd0f or arp[24:4]=0xc0a0cd0f（跟踪arp响应消息源ip和arp请求的目的ip192.168.205.15），发现有如下打印：

发现pc发出的arp请求没有得到响应。

ping的若显示无法访问目的主机，应该是显示4次，每次3s钟，每秒发出一个arp请求消息。

难道机柜汇聚交换机离线了？登录到核心交换机，发现对应端口在线。奇怪了？

奇怪，镜像核心交换机到机柜汇聚交换机的接口发现有下面的打印：

看这个每包的时间间隔，发现几乎在0.000002秒，就是说每秒发送50000个包，而交换机设置最大接收arp是100个/秒，显然超出交换机的处理能力，怀疑谁的设备出了问题，在工作微信群里询问同事谁的这两个mac地址的设备？判断在不停的发送arp消息。

有同事反馈他在其他网段能登录机柜汇聚交换机，反馈这个00:ac:c9:00:00:02是在图中253交换机上，如图：

让他在机柜汇聚交换机上shutdown 1/1/9接口，并清除掉arp表和mac地址表后，用192.168.205.201pc进行ping，发现windump有下面的打印：

机柜汇聚交换机响应了arp请求，能够ping通。

检查253交换机上最近做了什么？有同事反馈，他有业务需求，用网线把253和251交换机的两个端口连接起来了，开始两个端口都是vlan1的access。怀疑有设备接在vlan1上，两个交换机形成环路，vlan1的消息在环路中形成了网络风暴，如图：

导致机柜汇聚交换机无法处理arp请求，撤掉这个连接后，访问正常。

• 判断为环路造成机柜汇聚交换机产生大量arp消息，造成205vlan子接口无法处理大arp请求消息，造成的故障。

仿真过程：

以前从没有了解到环路的现象和实现机理，为了搞清环路原理，搭建环境，模拟环路和vlan1传递数据的过程。没敢在公司网络上复现，搭个环境试一下。

环境参数：

准备一个交换机，连个pc，pc1,18.250.0.200，pc2,18.250.0.44，交换机配置四个接口，1接pc1,2接pc2,3,4用于自环。交换机上起vlan18，子接口ip是18.250.0.100/24。1-4是access口，属于vlan18。用windump进行抓包判断arp和icmp消息是否发送正常。

pc1的配置：

pc2的配置：

正常状态下，pc1去ping pc2：

如上图：arp请求和应答正常，ping包发送的请求和reply正常，mac地址正确。

3,4端口自环的情况：

执行windump -i 1 -nne arp or icmp >wj.txt，并用edit进行编辑此文件，发现ping的一般arp过程一个request，一个reply。竟然生成了7877包消息。

可以看到ping过程产生了7877包的arp广播request消息和单播reply消息。过程中3,4口灯狂闪。

过程中，原来ping的过程变成time out。

环路后的抓包表现，能看到大量的重复包，时间间隔在毫秒以下级别。

网上搜的关于access和trunk的收发包原则：

Access端口在收到一个报文（Access端口通常是从终端PC中接收报文）后，先判断该报文中是否有VLAN标记信息：如果没有VLAN标记，则打上该Access端口的PVID后继续转发（毕竟Access端口收到报文后是向其他端口发送的，可以识别带有VLAN标记的报文）；如果有VLAN标记（这个报文肯定是来自其他非Access端口和终端PC，因为Access端口和终端PC网卡不会发送带VLAN标记的报文），则默认直接丢弃。

Access端口上发送报文时，会先将报文中的VLAN信息去掉（因为Access端口发送报文一般是到终端PC，PC中的网卡是不能识别VLAN标记的。还有一种情况是发送到另一个同VLAN中的Access端口，因为Access端口也不接受带有VLAN标记的报文），然后再直接发送，所以Access端口发关出去的报文都是不带VLAN标记的。

Trunk端口的报文收发规则如下：

在Trunk端口上发送报文时，先会将要发送报文的VLAN标记与Trunk端口的PVID（没有修改默认是1）进行比较，如果与PVID相等，则从报文中去掉VLAN标记再发送；如果与PVID不相等，则检查是否允许通过，允许的话直接发送，不允许，丢弃。这样一来，如果将交换机级连端口都设置为Trunk，并允许所有VLAN通过后，默认情况下除VLAN 1外的所有来自其他VLAN中的报文将直接发送（因为这些VLAN不是Trunk端口的默认VLAN），而作为Trunk端口默认VLAN的VLAN 1，则需要通过去掉报文中的VLAN信息后再发送。

在Trunk端口收到一个报文时，会首先判断是否有VLAN信息：如果没有VLAN标记，则打上该Trunk端口的PVID，视同该帧是来自PVID所对应的VLAN转发到PVID所对应的VLAN接口上；如果有VLAN标记，判断该Trunk端口是否允许该VLAN的报文进入，如果允许则直接转发，否则丢弃。

故障过程分析:

VLAN 1 有2个默认属性（默认VLAN1不能被创建和删除，但是端口的native vlanid可以被更改其他值）

它是默认VLAN，即是你任何端口开启后，默认分配到VLAN1。

另一个属性是native VLAN为1，过TRUNK（native vlanid为1的端口）发出时默认不打tag，去掉tag。

就此案例中交换机253和251的trunk口端口，，没有修改native vlanid前，都是默认vlan1，而且vlan1的广播包可以通过没有设置native vlanid的trunk口进行送到测试汇接交换机，测试交换机的，而测试交换机的9口nativevlan是4094，9口收到的包被打上4094的vlan标记，如图：

所以，测试交换机中会show arp会查到这个mac地址会显示4094

而另一个交换机的端口在6端口

native vlan4094，而连接核心网的1端口既然能抓包包，估计当时的也是4094，这个过程，就是下面下面253,251交换机没有设置trunk口的native vlanid值，所以这个过程就，一个vlan1上接收的消息arp请求和应答消息，在253交换机的trunk口出去，去掉vlan标识，进入测试交换机的9口，就打上vlan4094标记，在交换机上的几个native为4094的接口上发送，从1口，6口去掉vlan标记4094进入相应的交换机，如进入251交换机，251trunk口收到后，就打上vlan1的标记，泛洪到所有vlan1接口上，结果通过物理自环接口，再次进入253交换机，这样在这个环里死循环，造成网络风暴。

端口默认是vlan1的二层广播消息在trunk口发包vlan1包去的tag，从另一个trunk口进去，打上这个端口tag，在对应tag的端口口泛洪，这样造成环路。

所以故障中，测试汇接交换机把这个把这个包发送到核心交换机上去，会被跟踪到。核心交换机对接测试交换机收到大量的arp消息，超出了arp阈值，导致丢弃一部分arp消息，导致不响应192.168.205.201的arp请求消息。

为了避免vlan1数据影响，把相关交换机的trunk口native vlanid都做了修改，达到阻断vlan1接入的消息乱发的可能性。