由于各种原因，以太网经常会产生各种二层事件，此时，交换机就必须做相应的处理。交换机对二层事件处理是否得当，处理响应的速度是否及时，将直接影响到网络的可靠性和快速收敛性。
一、二层事件描述
二层事件通常有两类：一类是普通二层事件；另外一类是环路中的链路改变事件。
1．普通的二层事件
普通的二层事件都是基本的事件，一般只会对网络造成局部的影响。普通二层事件具体包括：端口UP/DOWN事件；端口INCLUDE/EXCLUDE事件，当端口加入到某个VLAN中时就会产生INCLUDE事件，反之，EXCLUDE事件则是指端口离开某个VLAN时产生；VLANDOWN/UP事件，如果将VLAN也看成一个端口，则VLANDOWN/UP事件与端口UP/DOWN事件没有本质区别，当一个VLAN中所有端口都变成DOWN时，该VLAN也就会变成DOWN；VLANDELETE事件，删除VLAN时产生VLAN DELETE事件；端口DELETE事件，删除端口时产生端口DELETE事件，当带电拔出单板时，就会产生端口DELETE事件。
2．环路中的链路改变事件
环路可以增加网络的可靠性，但同时也有可能形成网络风暴。当网络中有多条冗余路径时，数据流过环选择路径时必须有所取舍。当发生了普通的二层事件时，数据流往往会选择不同的路径过环，这时就称为发生了链路改变事件。
二、以太网组播中对普通二层事件处理的分析与设计
1．组播转发概述
组播是一种单点发送多点接收的数据包传输方式，当有多台主机同时成为一个数据包的接收者时，出于对带宽和CPU负担的考虑，组播成为了一种最佳选择。组播只会将数据包转发给对数据包感兴趣的接收者，这样能够节约网络带宽，降低网络负载。交换机转发组播数据，以组播转发表为依据，转发表的正确与否直接关系到组播数据能否到达正确的接收者手中。组播转发表的一般格式如图1所示。
图1
由图1可知，组播转发表中每一个转发表项由三部分组成：VLANID、组地址与出端口。由于组播数据不能跨越VLAN传输，因此每一个表项第一部分是VLANID，当交换机收到组播数据包时，数据包只能在数据包入端口所在的VLAN内转发。然后根据数据包中的组地址检索组播转发表，最后将数据包转发到检索结果中的所有出端口上。
2．对端口UP/DOWN事件的处理
交换机是根据组播转发表来转发组播数据的，正是由于组播转发表的存在，才得以实现对组播数据的按需转发。图2为组播转发网络示意图，为了简化分析，我们假定只有一个VLAN，而且只有一个组播组（组播组对应多个出端口）。
图2
由图2知，若只有与端口p1、p3相连的主机才对组播组的数据感兴趣，则交换机只会将组播数据转发到端口p1与p3上。假设交换机上所有的端口都属于VLAN1，并且与端口p1、p3相连的主机对组地址为226.0.0.1的组播组的数据感兴趣，此时组播转发表如图3所示。
图3
当端口P1的状态变DOWN时（如果交换机不做任何处理），当有组播数据来时，交换机仍会向端口P1转发。而由于端口P1物理层面上已经DOWN掉，组播数据流根本无法达到与端口P1相连的主机，这样无形中给CPU增加了无谓的负担。因此当端口P1的状态变成DOWN时，应该在组播转发表中删除掉与端口P1相关的转发表项，处理之后的转发表如图4所示。由于端口P3的状态没有变化，所以端口P3仍然在出端口列表中。
图4
假定与端口P4相连的主机也对组播组的数据感兴趣，但由于端口P4的状态一直是DOWN，所以端口P4不在出端口列表中。现假定端口P4的状态突然变成UP，如果交换机不响应UP事件，那么即使与端口P4相连的主机对组播组的数据感兴趣，它也收不到组播数据。此时，组播转发表就没有能反应出真实的转发需求。因此当端口P4的状态变成UP时，应该在组播转发表中相应组播组的出端口列表中增加端口P4，处理之后的转发表如图5所示。
图5
以上只是对最简单的情况进行分析与设计，当遇到非常复杂的组播转发表时，处理原理也是一样的：当端口状态变DOWN时，应该在组播转发表中删除与该端口相关的转发表项，以防止增加CPU的负担；反之，当端口状态变UP并且与该端口相连的主机对组播组数据感兴趣时，应该在组播转发表相应表项的出端口列表中增加该端口。另外，如果对端口UP/DOWN事件处理不及时，可能会造成丢包或者CPU超负荷的情况发生，因此，系统对二层事件的响应速度将直接影响网络的可靠性。
3．对其它普通二层事件的处理
对其它普通二层事件的处理与对端口UP/DOWN事件的处理原理上是一致的。
当发生端口INCLUDE事件并且与端口相连的主机对组播组数据感兴趣时，则需要在端口加入的VLAN内增加相应的表项；反之，当发生端口EXCLUDE事件时，则需要在端口离开的VLAN内删除相应的出端口或表项。
当发生VLANDOWN时，删除VLAN内的所有转发表项；反之，当发生VLANUP时，则添加VLAN内所有端口相应的表项。对于VLANDELETE、端口DELETE，处理方式分别与VLAN DOWN、端口DOWN相同，但级别应该要更高一些，也就是应该优先处理VLAN DELETE和端口DELETE，因为这两个事件造成的影响在一般情况下比别的事件要大。
三、以太网组播中对环路事件处理的分析与设计
1．网络环路以及环路事件概述
网络环路是为交换网络提供冗余链路时形成的，现代化的网络要求交换网络中必须具备冗余链路，以避免单点故障引起的网络中断。由于环路的存在，导致了交换网络中产生广播风暴的可能。为了防止产生广播风暴，必然要阻塞一些冗余链路上的端口，即只允许数据从其中一条链路上通行，当允许通行的链路发生故障时，为了保证数据不中断，应能立即恢复阻塞端口的通行能力。
在交换网络的环路中，有三种环路事件：端口BLOCK事件，即阻塞数据从该端口通过，以防止产生网络风暴；端口UNBLOCK事件，解除阻塞状态；LINKCHANGE事件，即链路改变事件，当一条链路上发生故障时，选择另一条冗余的链路通行。
2．对环路事件的处理
对端口BLOCK/UNBLOCK事件的处理与对端口DOWN/UP事件的处理方式相同。当某个端口BLOCK时，除了一些特定的环路协议包之外，一般的组播包不允许通过。这时如果仍向该端口转发组播数据，只会给CPU增加无谓负担。所以当端口BLOCK时，应该删除该端口对应的转发表项或出端口，反之，当端口UNBLOCK时，则应该增加相应的出端口或表项信息。
当一个端口BLOCK，而另一个端口UNBLOCK时，自然就发生了LINKCHANGE事件。发生LINKCHANGE事件时，需要根据IGMP请求报文重新学习转发表项，而且还要更新路由器端口信息。为了简化起见，以图6所示的简单环路情况为例进行分析。
图6
图6所示的环路中，由于端口P1的状态是BLOCK，所以组播流从端口P2转发下来，协议报文（IGMP报文）也是走右侧的路径。当最下面的交换机接收到从上游下来的IGMP查询报文时，便认为端口P4是路由器端口，以后有主机发出IGMP请求报文时，交换机便会从端口P4将报文发往上游。如果发生LINKCHANGE事件，可用链路切换到左侧，但是在链路收敛之前，组播数据仍然会从发往端口P2通过，而且主机发送的IGMP请求报文仍然会发往端口P4，由于右侧链路已经不通，所以IGMP请求报文无法达到最终路由器。等到上游路由器发出通用IGMP查询报文时，最下游的交换机才能学会新的路由器端口，主机发送的IGMP请求报文才开始从左侧上传，继而学会新的表项。
由此可见，当发生LINKCHANGE事件时，在上游路由器发出通用IGMP查询报文前（严格来说，应该是学会新的表项前），组播数据无法正确到达下游主机。为了保证链路快速收敛，也就是为了组B播数据能迅速切换到左侧链路，当发生LINKCHANGE事件时，最上游的交换机应该模拟路由器发出一个通用IGMP查询报文，使下游交换机能迅速学会新的路由器端口，从而保证主机发送的IGMP请求报文能顺利到达上游交换机与路由器，最终快速更新组播转发表项。
