交换机组播风暴_广播风暴的成因以及解决办法有哪些？

广播风暴就是因为以太网中出现了明环或暗环，引起广播包被指数涨速递增，整个网络流量被广播包占据，其他的转发业务不能进行。

以太交换机对广播包的处理，是不管从哪个端口收到广播包，都完整地复制一份转发到其他端口(除接收到的端口外)。交换机对广播报文的处理。来自端口1的广播报文做端口2，3，4上各自复制一份发送

一个简单的环就是同一个交换机上的两个端口直连。比如3口和4口连上。交换机成环路，同一个交换机的3，4口相通

那么当交换机收到来自1口的广播包，会在3和4口上各自复制转发一份。注意，收到一个包广播包，发出去N-1个广播包。这一轮结束后，3和4分别发送了一个广播包。

但是从3口发出的广播包会被4口收到，从4口发出的会被3口收到。

交换机会把从4口收到的广播包在1，2，3口上复制转发一份。同样的也会转发从3收到的广播包(来自端口4的直连线)到端口1，2，4。

从3发出的广播报文被4口接收到，复制到1，2，3端口再发送出去。

同样的不幸故事又发生在刚刚转发的3发4收和3收4发的广播包上。3和4口会不停地接收到对方发的广播包，交换机会不停地转发到所有端口。以前图为例，step4和step5会陷入死循环。注意，每次循环的时候，1，2，都会把广播报文广播到网络中去。

每发生一轮，广播包就在所有端口复制转发一份。这个故事永远不会停止，直到交换机被撑死。如此循环往复很快就爆炸了。

这个是最简单的明环。如果有两个或多个交换机的转发路径上有了类似的结果，也就是说同一个广播包被同一个交换机处理2次的时候，这个交换机就对广播包进行了不可逆转的爆炸。长环(暗环)中，A3-B1-B2-A4形成一个环路，Step 4～7会循环往复不停歇

有空慢慢写一下怎么防护，先留坑

浅浅地补个坑。

业界对于防止网络风暴的主要思路，还在“防止出现环路”的思路上。这个思想是这样的：

在以太网的组网过程中，假定有一个无环的小网(这个很容易做到，例如，打开一个交换机只开一个端口，再例如，已经运行很正常的以太网)，然后接下来要往这个网络中添加一个端口(或者连接另一个网络)前，先确定一下拓扑结构，只有确认好了拓扑结构中没有环路，才正式开启向这个端口或网络发送数据。确认拓扑结构有特殊的处理协议，这个协议的运行不属于前面说的“开启”。

广泛应用的协议是STP(Spanning Tree Protocol)，生成树协议。我觉得英语spanning比中文的“生成”更形象。改进的协议是“快速生成树” RSTP(rapid)协议。具体协议我就不班门弄斧了。