设为首页 收藏本站
查看: 2103|回复: 0

[经验分享] 下层设备以及虚拟设备造成的环路不容忽视

[复制链接]

尚未签到

发表于 2015-11-5 15:11:35 | 显示全部楼层 |阅读模式
  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的, 就明白这也是情理之中的了. 看抓包结果:
  

DSC0000.jpg

  看起来都是网关在请求服务器的请求, 服务器肯定会回应arp请求的, 但是为什么最终没有形成最终的ARP记录呢?
  再看另一个端口的抓包记录:
DSC0001.jpg

  一看很明显异常呀,一个口上全是一个IP的ARP Request , 哥们儿说那是因为那个口下面就挂了一个空的交换机 H3C S5000, 157/158是那个交换机的互联地址, 只出现这一个IP的ARP请求很正常, 好吧, 这可以解释. 但是, 且慢!  请注意下这个细节, :
DSC0002.jpg
  这是tcpdump的时间戳, 我们可以看到每次arp请求之间的间隔是0.00005s , 就意味这每秒有2万个arp包, 这是这么高的频率极其不正常的. 而且基本可以确定就是这个口的问题了.
  首先怀疑的就是有广播风暴, 哥们儿说不可能呀, 这个口下面就连了那个空交换机 H3C 的 S5000,而且S5000就这一根线和juniper相连, 一根线怎么可能环路呢?  一根线不会打环但是不一定不受环路的影响, 原来S5000上虽然没有带其他设备,但是自己有2个光口用光纤直连了. 如下图:
DSC0003.jpg
  网关发的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的网络异常, 包括物理网络里面的服务器. 开始想不到是虚拟机的问题, 因为我感觉虚拟网络怎么会影响物理网络呢, 其实虚拟网络和物理网络联通之后, 就和物理网络没有差别,同样会影响到物理网络的.  所以操作虚拟网络的时候也万不可掉以轻心.
  

DSC0004.jpg

  

  

  

         版权声明:本文为博主原创文章,未经博主允许不得转载。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-135537-1-1.html 上篇帖子: Network virtualization, management silos and missed opportunities 下篇帖子: MPLS Step2(RFC 3032: MPLS Label Stack Encoding)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表