1. 下层设备环路对核心设备的影响
半夜一IDC的哥们打电话求助, 说机房整体出问题了,很多IP是时通时不通, 根据分析网络问题的一般逻辑:
1.首先在网关上ping 服务器IP, 发现不通的IP在网关也ping不通, 首先排除路由问题了,因为在网关上是直连路由, 网关和服务器就是二层通信.
2.既然是二层通信, 就要看ARP表和MAC地址表, 结果发现不通的IP没有ARP记录, 好, 症结可以确定是ARP/二层问题了.
3.那么是服务器没发ARP Request还是网关没收到ARP Request,还是收到 ARP Request 之后没reply呢?
(1). 服务器肯定发ARP Request了,因为如果单台服务器网关配错可能不会发ARP Request, 但是那么多正常的服务器同时出故障, 不会是服务器的问题.
(2).网关有没有收到ARP Request呢? 机房网关用的是Juniper 8208 , Juniper是可以在设备上直接用tcpdump抓包的, 看起来很奇葩吧, 不过如果你知道junos是基于freebsd的, 就明白这也是情理之中的了. 看抓包结果:
看起来都是网关在请求服务器的请求, 服务器肯定会回应arp请求的, 但是为什么最终没有形成最终的ARP记录呢?
再看另一个端口的抓包记录:
一看很明显异常呀,一个口上全是一个IP的ARP Request , 哥们儿说那是因为那个口下面就挂了一个空的交换机 H3C S5000, 157/158是那个交换机的互联地址, 只出现这一个IP的ARP请求很正常, 好吧, 这可以解释. 但是, 且慢! 请注意下这个细节, :
这是tcpdump的时间戳, 我们可以看到每次arp请求之间的间隔是0.00005s , 就意味这每秒有2万个arp包, 这是这么高的频率极其不正常的. 而且基本可以确定就是这个口的问题了.
首先怀疑的就是有广播风暴, 哥们儿说不可能呀, 这个口下面就连了那个空交换机 H3C 的 S5000,而且S5000就这一根线和juniper相连, 一根线怎么可能环路呢? 一根线不会打环但是不一定不受环路的影响, 原来S5000上虽然没有带其他设备,但是自己有2个光口用光纤直连了. 如下图:
网关发的arp请求是广播包,所以会到达打环的2个端口, 形成广播风暴, 而由于广播包会广播到同LAN的所有端口,所以风暴会到达上层的juniper, 打环的2个端口就像风暴的引擎, 而上联口会直接受到风暴的影响.
那为什么juniper在大量的ARP请求"攻击"的情况下会学习不到新的ARP记录呢, 因为Juniper和华为一样, 都是有CPU保护的, ARP 报文是会上升到CPU, 由CPU处理的, 会消耗CPU资源. 为了避免CPU被大量的ARP报文挤爆, 就做了限速,限制到达CPU的ARP报文数量:
For DAI, all ARP packets are trapped to the packet forwarding engine.. To prevent CPU overloading, ARP packets destined for the Routing Engine arerate-limited.
http://www.juniper.net/techpubs/en_US/junos14.1/topics/concept/port-security-dynamic-arp-inspection.html
这样超过限速的报文会被丢弃, 到达CPU的机会被大量广播风暴的ARP占用, 所以正常的ARP请求很难得到处理, 有时候被处理了就会通一会儿, 等ARP超时之后又会不通.
原因搞清楚了, 去掉那根导致环路的线, 网络随即恢复正常.
可关键是, 怎么会把S5000的2个口直连呢? 这是网络操作的大忌呀, 机房工程师不应该不清楚这点, 答复是这根光纤下联设备撤掉了, 怕弄脏光纤头就插到另一个口了, 反正这个设备没带任何业务. 好吧... ... 我不淡定了, 这网络基础一定是体育老师教的
血泪教训:下层设备环路也可能会影响上层!
2.虚拟设备也会造成环路
处理完这件事让我联想到我以前遇到的另一个环路事件. 一台VMware 里面的虚拟机的网关是在上层设备,我做了个ROS 的虚拟机做网桥, 来做限速和firewall , 但是当时操作失误, 把ROS 网桥2个网口连接到同一个LAN了, 结果导致整个Lan的网络异常, 包括物理网络里面的服务器. 开始想不到是虚拟机的问题, 因为我感觉虚拟网络怎么会影响物理网络呢, 其实虚拟网络和物理网络联通之后, 就和物理网络没有差别,同样会影响到物理网络的. 所以操作虚拟网络的时候也万不可掉以轻心.