从交换机原理看网络广播风暴的几种原因
越来越多网络出现广播风暴，那到什么引起广播风暴呢？？那就来看看这个帖子，给你简单说一下。。。。 看了，叫我想起起了一个参与过的移动的故障会诊：移动的网络突然出现丢包现象，用户召集了所有设备和服务商开诊断会，后来每个厂商都排出了自己设备的问题。最后发现是一台二层交换机出了故障，将其卸掉故障解决。
发现的原因是抓到了摩托罗拉芯片的一个广播包，才怀疑到是使用摩托罗拉芯片的交换机出了问题。 [quote]原帖由 [i]mzwa[/i] 于 2006-2-9 09:28 发表
看了，叫我想起起了一个参与过的移动的故障会诊：
移动的网络突然出现丢包现象，用户召集了所有设备和服务商开诊断会，后来每个厂商都排出了自己设备的问题。最后发现是一台二层交换机出了故障，将其卸掉故障解决 ... [/quote]
移动的排场这么大啊！ 网卡损坏引起网络问题已经遇见好几次了
至于环路的问题STP就能解决 [quote]原帖由 [i]finger[/i] 于 2006-2-9 13:02 发表
网卡损坏引起网络问题已经遇见好几次了
至于环路的问题STP就能解决 [/quote]
STP不是万能的。。。;) 是啊，我在处理故障上就遇到很多次都是交换机引起的网络故障 以前看过了 好看。。。。 设备和设备之间的兼容问题，错误的端口汇聚也可能导致Loop的产生。。。 [quote]原帖由 [i]DragonGo[/i] 于 2006-3-10 22:02 发表
设备和设备之间的兼容问题，错误的端口汇聚也可能导致Loop的产生。。。 [/quote]
有机会应该写个详细的，呵呵，这样大家都受益 好好看看，广播风暴很有意思！ 广播风暴只要去出就安全了 太好了 我刚好需要这样的东西啊 感谢 很有实用价值。支持。 好东西,大家分享呀
就lz提到的网络环路,我也提供点我自己的经验供大家参考
关于广播风暴的问题,这里我也总结了一个问题.供大家参考.我这里讲到的主要还是环路造成的问题.
记得我还在川大网管中心的时候,曾经遇到过这样的一个故障.
拓扑图如下:
+-------------+
| L3 Switch |
+-------------+
|
|
+-------------+
| L2 Switch |-------------------------+
+-------------+ |
| |
| |
+-------------+ +-----------------+
| L2 Switch 1 | . . . . . . . . | L2 Switch N |
+-------------+ ( Many ) +------------------+
|
+------------+
| Switch |
+------------+
L3 Switch 为 某园区的核心交换机, L2 Switch 为某宿舍楼的主交换机,
L2 Switch 1 - N 为该宿舍楼的楼层交换机. Switch 为某楼层交换机
L2 Switch N 下连的某寝室的小交换机.
当该寝室的A同学不小心将一根长网线的两头都接到了Switch上,由于这种
家用小交换机是MDI/MDI-X自适应的,所以直通线也可以将这个小交换机的
两个接口连通了. 这样的后果就是，当小交换机收到一个广播数据包
（例如ARP请求），它就开始对它的接受这个包的源端口以外的端口进行洪泛。
这时候，被回环的端口1和2就会收到来自对方的广播包，就会产生二次洪泛，
在二此洪泛的时候,由于源端口是1和2,所以同时也会对这个广播包原来的端口
也进行洪泛, 相应也会产生三次洪泛,四次洪泛等等。这样,上联的交换机就会
收到来自这台小交换机大量的数据包，造成严重的拥塞以及资源消耗。
对于这台小交换机未建立CAM表的时候，单播包也会产生同样的结果。
记得当时这个小小的环路,影响到了该园区的核心交换机,后果是很严重的.
所以当时开玩笑说,在川大,当黑客太简单了.拿根网线,两头往交换机上一插,
网络就得瘫痪半天.
当时觉得和生成树(STP)协议有关, Huawei的交换机采用的是RSTP协议,并且默认
不启用,所以认为开启生成树协议应该可以解决这个问题,但是开启生成树后
同样还是遇到了这种问题, 就归于Huawei VRP的BUG了.
其实这不是VRP的BUG, 仅仅靠默认的STP并不能解决这种自回环的环路问题,
我们还需要STP的一个扩展功能, BPDU GUARD(BPDU 防护). Huawei叫做
BPDU Protection (BPDU 保护) 呵呵,换汤不换药啦.
BPDU GUARD的功能是当这个端口收到任何的BPDU就马上设为Error-Disabled状态.
我们知道,当交换机STP功能启用的时候,默认所有端口都会参与STP,并发送和
接受BPDU. 当BPDU GUARD开启后,在正常情况下,一个下联寝室的端口是不会收到
任何BPDU的,因为PC和小交换机都不支持STP,所以不会收发BPDU. 当这个端口下
如果有自回环的环路,那么它发出去的BPDU在小交换机上回环后就会被自己接收到,
这个时候BPDU GUARD就会把它立刻设为Error-Disabled状态,这个端口就相当于被
关闭了,不会转发任何数据,也就切断了环路,保护了整个网络.
Cisco的交换机上的配置方法是:
Switch(config)# interface FastEthernet0/1
Switch(config-if)# spanning-tree bpduguard enable
或者
Switch(config-if)# spanning-tree bpdu-guard enable
(根据IOS版本不同,有的是bpduguard,有的是bpdu-guard)
对于Huawei交换机上配置稍有不同. Huawei交换机默认没有启用生成树协议.
(Huawei用的是RSTP),所以首先要在系统视图下启用STP
[Quidway] stp enable
然后Huawei的BPDU Protection和Cisco不一样,Cisco是既可在全局下配置,
也可在单独的端口下配置, Huawei则是只能在系统视图(即全局模式)下.
因为Huawei是在系统视图下启用 BPDU Guard后,会在所有的边缘口(Edge Port)
下生效. 边缘口的意思是这个接口只用于连接主机(PC),不用于连接其它交换机
(当然,小交换机不算真正的交换机,因为小交换机不支持STP.)
默认所有的端口都是非边缘口. 所以需要将连接寝室的那些端口设为边缘口,
然后在系统视图下启用BPDU Protection.
[Quidway-Ethernet0/2] stp edge-port enable
[Quidway] stp bpdu-protection
建议对所有寝室的端口都这样做,这样就可以避免这个问题再发生了.
这里再多说几句,其实当时想到的一个方法是做[b]广播抑制[/b].
Huawei只支持针对广播的抑制,Cisco是风暴抑制,支持单播,组播和广播.
但是当时做了以后发现完全没有效果,而且CPU还是100%.
这次我在Cisco的3750上测试风暴抑制发现效果很好,我设定的是广播风暴超过
20%开始抑制, 而且CPU在 6% - 7% 左右.
测试结果:
[font=Courier New]Switch#sh storm-control
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Fa1/0/1 Blocking 20.00% 20.00% 50.06%
Switch#sh storm-control
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Fa1/0/1 Blocking 20.00% 20.00% 49.99%
Switch#sh storm-control
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Fa1/0/1 Blocking 20.00% 20.00% 36.97%
Switch#sh storm-control
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Fa1/0/1 Forwarding 20.00% 20.00% 0.00% [/font]
[font=Courier New]Switch#sh proc cpu
CPU utilization for five seconds: 6%/0%; one minute: 7%; five minutes: 7%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 0 5 0 0.00% 0.00% 0.00% 0 Chunk Manager
2 0 2351 0 0.00% 0.00% 0.00% 0 Load Meter
3 0 11662 0 0.00% 0.00% 0.00% 0 MDFS LC Download
4 9042 1248 7245 0.00% 0.04% 0.05% 0 Check heaps
5 9 2 4500 0.00% 0.00% 0.00% 0 Pool Manager
6 0 2 0 0.00% 0.00% 0.00% 0 Timers
7 67689 23267 2909 0.00% 0.00% 0.10% 0 ARP Input
8 0 1 0 0.00% 0.00% 0.00% 0 AAA_SERVER_DEADT
9 0 2 0 0.00% 0.00% 0.00% 0 AAA high-capacit
10 0 1 0 0.00% 0.00% 0.00% 0 Policy Manager
11 17 4 4250 0.00% 0.00% 0.00% 0 Entity MIB API
12 0 1 0 0.00% 0.00% 0.00% 0 IFS Agent Manage
13 0 198 0 0.00% 0.00% 0.00% 0 IPC Dynamic Cach
14 0 1 0 0.00% 0.00% 0.00% 0 IPC Zone Manager
15 8 11751 0 0.00% 0.00% 0.00% 0 IPC Periodic Tim
16 0 11751 0 0.00% 0.00% 0.00% 0 IPC Deferred Por
17 0 1 0 0.00% 0.00% 0.00% 0 IPC Seat Manager
18 0 2943 0 0.00% 0.00% 0.00% 0 HC Counter Timer
19 0 1 0 0.00% 0.00% 0.00% 0 HRPC asic-stats
20 8 11752 0 0.00% 0.00% 0.00% 0 Dynamic ARP Insp
21 0 2 0 0.00% 0.00% 0.00% 0 XML Proxy Client
--More-- [/font]
这说明Huawei的这个功能确实存在问题,呵呵, 国货当自强啊.
[[i] 本帖最后由 phanx 于 2006-4-18 10:23 编辑 [/i]] [quote]原帖由 [i]DragonGo[/i] 于 2006-2-9 13:05 发表
STP不是万能的。。。;) [/quote]
对的,昨天还在net130上看到了一篇讨论:
[url=http://bbs.net130.com/showthread.php?t=142081]请问以下两种环路现象STP是否能够BLOCKING相应的端口??? [/url]
孙嘻嘻的说法我认为就是错误的.
看来这个问题是广泛存在的.应该引起注意. 看完，受益非浅，但是没有看出广播风暴和交换机本身有什么关联！
[code]1、网络设备原因：我们经常会有这样一个误区，交换机是点对点转发，不会产生广播风暴。在我们购买网络设置时，购买的交换机，通常是智能型的Hub，却被奸商当做交换机来卖。这样，在网络稍微繁忙的时候，肯定会产生广播风暴了。 [/code]
只看到这一点！ 大多数IT服务都存在广播的数据包。 看过,谢谢 看看,学学.谢谢楼主 phanx 环路这块写的非常好 谢谢分享，宝贵的经验啊 好。。。。
为什么不做pppoe, VLAN 来抑制lai 很有实用价值。支持。 华为的广播抑制到底有没有用.
一般我都设置为50％
默认是100％ 16楼的写的不错.我工作在一个比较知名的二级运营商,那用的设备就实在是太杂了,早期的,新的,什么牌子型号都有,你说的那些功能,在用到的交换机上都看得到,不过,真的,设备太杂了,用起来的时间,通常都是什么功能都不开,唉,有什么办法类,开了,大家都互不兼容.你说的情况,经常遇到,我说一个自己的经验,通常可以根据报障范围确定大概的故障点,然后找到相关的节点,直接用眼睛看吧,有问题的那个端口很有特点的,通常是,就他一个拼命的闪,其它的,端口基本不闪,一拔了他,别的就闪到正常了.哈哈,~~~原始哦,可是在你熟悉设备情况时,这是最快的恢复网络的方法了.有一次,到了故障点,我才发现本本在公交车上,压坏了屏,没法用了,没办法,只好用这个办法,然后找个用户的电脑测试,网络恢复了,唉~~,这也是逼出来的~~ 看了楼主的东西 ,其实在交换机中,怎么会有风暴,唉,这跟交换机有什么关系类,对,交换机点到点,独享带宽,可是风暴是基于IP的,同一个网段,风暴是发到同一网段上的每个IP的,不关你的是交换机还是集线器的事 二层设备,不能隔离广播的 谢谢分享！ 不错啊,学习到了. 太深奥了，没看懂什么意思 很受启发，学习了。 :) :) :) 看看，学习下
好东西
好东西。下了。说得很 简单明了。:handshake 网络故障频繁出现。在网吧的网络故障中，由于网络广播风暴引起的网络故障，占网吧网络故障的九成以上！！头疼的问题，一定要彻底摆平页:
[1]