越来越多网络出现广播风暴，那到什么引起广播风暴呢？？那就来看看这个帖子，给你简单说一下。。。。

看了，叫我想起起了一个参与过的移动的故障会诊：
移动的网络突然出现丢包现象，用户召集了所有设备和服务商开诊断会，后来每个厂商都排出了自己设备的问题。最后发现是一台二层交换机出了故障，将其卸掉故障解决。
发现的原因是抓到了摩托罗拉芯片的一个广播包，才怀疑到是使用摩托罗拉芯片的交换机出了问题。

引用:

原帖由 mzwa 于 2006-2-9 09:28 发表
看了，叫我想起起了一个参与过的移动的故障会诊：
移动的网络突然出现丢包现象，用户召集了所有设备和服务商开诊断会，后来每个厂商都排出了自己设备的问题。最后发现是一台二层交换机出了故障，将其卸掉故障解决 ...

移动的排场这么大啊！

网卡损坏引起网络问题已经遇见好几次了
至于环路的问题STP就能解决

引用:

原帖由 finger 于 2006-2-9 13:02 发表
网卡损坏引起网络问题已经遇见好几次了
至于环路的问题STP就能解决

STP不是万能的。。。

是啊，我在处理故障上就遇到很多次都是交换机引起的网络故障

以前看过了

好看。。。。

设备和设备之间的兼容问题，错误的端口汇聚也可能导致Loop的产生。。。

引用:

原帖由 DragonGo 于 2006-3-10 22:02 发表
设备和设备之间的兼容问题，错误的端口汇聚也可能导致Loop的产生。。。

有机会应该写个详细的，呵呵，这样大家都受益

好好看看，广播风暴很有意思！

广播风暴只要去出就安全了

太好了  我刚好需要这样的东西啊  感谢

很有实用价值。支持。

好东西,大家分享呀

关于广播风暴的问题,这里我也总结了一个问题.供大家参考.
我这里讲到的主要还是环路造成的问题.


记得我还在川大网管中心的时候,曾经遇到过这样的一个故障.
拓扑图如下:


     +-------------+
     |  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


建议对所有寝室的端口都这样做,这样就可以避免这个问题再发生了.

这里再多说几句,其实当时想到的一个方法是做广播抑制.
Huawei只支持针对广播的抑制,Cisco是风暴抑制,支持单播,组播和广播.
但是当时做了以后发现完全没有效果,而且CPU还是100%.

这次我在Cisco的3750上测试风暴抑制发现效果很好,我设定的是广播风暴超过
20%开始抑制, 而且CPU在 6% - 7% 左右.

测试结果:

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%  


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--


这说明Huawei的这个功能确实存在问题,呵呵, 国货当自强啊.

[ 本帖最后由 phanx 于 2006-4-18 10:23 编辑 ]

引用:

原帖由 DragonGo 于 2006-2-9 13:05 发表

STP不是万能的。。。

对的,昨天还在net130上看到了一篇讨论:

请问以下两种环路现象STP是否能够BLOCKING相应的端口???

孙嘻嘻的说法我认为就是错误的.

看来这个问题是广泛存在的.应该引起注意.

看完，受益非浅，但是没有看出广播风暴和交换机本身有什么关联！

复制内容到剪贴板

代码:

1、网络设备原因：我们经常会有这样一个误区，交换机是点对点转发，不会产生广播风暴。在我们购买网络设置时，购买的交换机，通常是智能型的Hub，却被奸商当做交换机来卖。这样，在网络稍微繁忙的时候，肯定会产生广播风暴了。  

只看到这一点！

大多数IT服务都存在广播的数据包。

看过,谢谢