一、正常场景下M-LAG的流量转发机制（双活模式）

M-LAG建立成功后，M-LAG主备设备负载分担共同进行流量的转发。下面介绍在正常工作情况下M-LAG的流量转发机制。

1.1、单播流量转发

如图1-1所示，M-LAG系统在设备双归接入场景下的已知单播流量转发：

对于南北向单播流量，在M-LAG接入侧，M-LAG的成员设备接收到接入设备通过链路捆绑负载分担发送的流量后，共同进行流量转发。流量到达M-LAG主备设备后，根据设备的路由表转发至网络侧。

对于东西向单播流量，在全部组建M-LAG，没有非M-LAG成员口的场景下，二层流量通过M-LAG本地优先转发，三层流量通过双活网关转发，都不经过peer-link链路，直接由M-LAG主备设备转发至对应成员口。

图1-1 M-LAG已知单播流量转发示意图

1.2、组播流量转发

M-LAG接入二层网络

M-LAG上行接入二层网络，那么二层网络必须要保证发往M-LAG的流量只有一份，否则会有成环的风险。组播源在网络侧的场景下，M-LAG成员口状态为主备的设备都可以转发组播流量，但由于peer-link与M-LAG成员接口存在单向隔离机制，所以组播组成员只会收到一份流量。

以M-LAG备设备的转发为例，如图1-2所示，假设左侧M-LAG上行接口被STP协议阻塞。M-LAG备设备收到组播流量后向各个下一跳转发，网络侧流量会转发给ServerA、M-LAG主设备。当组播流量通过peer-link到达M-LAG主设备时，由于peer-link与M-LAG成员接口存在单向隔离机制（即从peer-link口进来的流量不会再从M-LAG口转发出去），所以到达主设备的组播流量不会向ServerA转发。

组播源在接入侧的场景下，如图1-2所示，以M-LAG备设备的转发为例，假设左侧主设备上行接口被STP协议阻塞。在ServerA作为组播源、ServerB作为组播组成员，且M-LAG设备无下挂其他组播组成员时，组播源发出的流量负载分担到M-LAG系统主备设备。收到流量后，上行接口被STP协议阻塞的主设备组播出接口指向peer-link链路，流量汇总到备设备端口，统一上送给ServerB。备设备的流量虽然也会通过peer-link转发到左侧主设备，但由于peer-link与M-LAG成员接口存在单向隔离机制，主设备上行接口又被阻塞，因此这份流量无法转发到ServerA或ServerB。

图1-2 M-LAG接入二层网络组播流量转发示意图

M-LAG接入三层网络

M-LAG上行接入三层网络，M-LAG成员设备需要支持二三层组播混跑。如图1-3所示，M-LAG双活系统在接入设备双归接入场景下的组播流量转发：

组播源在网络侧的场景下，在ServerB作为组播源、ServerA作为组播组成员时，M-LAG主备设备都从组播源引流，且按照以下规则由M-LAG主备设备在本地查找组播表后将流量负载分担转发至组播组成员：

• 若组播组地址最后一位为奇数（例如225.1.1.1），则由M-LAG成员口状态为主的设备转发至组播组成员；

• 若组播组地址最后一位为偶数（例如225.1.1.2），则由M-LAG成员口状态为备的设备转发至组播组成员；

组播源在接入侧的场景下，在ServerA作为组播源、ServerB作为组播组成员，且M-LAG设备无下挂其他组播组成员时，组播源发出的流量负载分担到M-LAG系统主备设备，收到流量后在本地查找组播表将报文发送出去。接收者按单播路由选择一条链路发送IGMP加入报文，仅一台M-LAG设备收到加入报文，假设是左侧M-LAG设备。

图1-3 M-LAG接入三层网络组播流量转发示意图

区别于单播流量，由组播流量转发示意图可以看出，M-LAG系统在转发组播流量时需要在M-LAG两台设备间配置一条独立三层链路。因为在故障场景下，可能出现网络侧只有单链路上行，此时M-LAG主备设备间部署一条独立的单独三层链路可以用来传输组播报文。

如图1-4所示，在网络侧设备连接到M-LAG备设备场景下，由peer-link接口转发的组播报文由于单向隔离无法转发至指定的M-LAG成员口，此时有两种方式将组播地址最后一位为奇数的组播报文转发至M-LAG成员口状态为主的设备：

• 组播报文通过独立三层链路转发至主设备。

• 采用peer-link作为逃生链路，配置VLAN及其对应的VLANIF接口，并且该VLAN只能包括peer-link接口，此时将会解除单向隔离机制，从而让组播报文通过peer-link链路转发至主设备。

图1-4 M-LAG接入三层网络（单链路上行）组播流量转发示意图

1.3、广播流量转发

M-LAG接入二层网络

M-LAG上行接入二层网络，那么二层网络必须要保证从M-LAG设备的Eth-Trunk接口发出的流量只有一份，即必须保证一份流量只能通过一个M-LAG成员口发送给双归接入M-LAG的接入侧设备，否则会造成发送双份流量的问题。此处以M-LAG主设备的转发为例，如图2-5所示，假设右侧M-LAG上行接口被STP协议阻塞，M-LAG主设备收到广播流量后向各个下一跳转发，网络侧广播流量会转发给DeviceA、M-LAG备设备，接入侧广播流量会转发给网络侧设备、M-LAG备设备，当流量通过peer-link到达M-LAG备设备时，由于peer-link与M-LAG成员接口存在单向隔离机制（即从peer-link口进来的流量不会再从M-LAG口转发出去），所以到达M-LAG备设备的流量不会向DeviceA转发。

图1-5 M-LAG接入二层网络广播流量转发示意图

M-LAG接入三层网络

此处以M-LAG备设备的转发为例，如图2-6所示，M-LAG备设备收到广播流量后向各个下一跳转发，当流量到达M-LAG主设备时，由于peer-link与M-LAG成员接口存在单向隔离机制，到达M-LAG主设备的流量不会向DeviceA转发。

图1-6 M-LAG接入三层网络广播流量转发示意图

二、故障场景下M-LAG的流量转发机制（双活模式）

M-LAG的故障场景包括上行链路故障、下行链路故障、M-LAG设备故障、心跳链路故障、peer-link故障和二次故障。下面介绍流量在M-LAG故障和故障恢复场景下的转发情况和处理机制。

2.1、上行链路故障

图2-1 上行链路故障组网示意图

如图3-1所示，M-LAG接入普通以太网场景，M-LAG主设备的上行链路故障，通过M-LAG主设备的流量经过peer-link链路进行转发。M-LAG主设备上行链路故障恢复后，流量也恢复从主设备转发到网络侧。

当故障的上行链路恰好为双主检测链路，此时对于M-LAG正常工作没有影响。一旦peer-link也发生故障，M-LAG出现双主冲突，双主检测又无法进行，则会出现丢包现象。

M-LAG接入三层网络场景下，需要在M-LAG主备设备之间配置三层逃生链路，使得到达Master设备的上行流量通过三层逃生链路到达Backup设备。

2.2、下行链路故障

图2-2 下行链路故障组网示意图

如图2-2所示，当主M-LAG成员口故障时，所在的链路状态变为Down，此时备M-LAG成员口状态由备升主，双归场景变为单归场景。在主M-LAG成员口故障的同时，主设备学习到的DeviceA侧MAC不会被清除，直接刷新MAC表的出端口指向peer-link口，实现流量快速切换，避免未知单播泛洪。

在故障M-LAG成员口恢复后，MAC表的出端口从peer-link指向M-LAG成员口，实现流量快速切换，避免未知单播泛洪。同时，为避免主备M-LAG成员口状态切换造成的某些协议振荡，设备支持M-LAG成员口状态不再回切，即由备升主的M-LAG成员口状态仍为主，原主M-LAG成员口在故障恢复后状态为备。

在M-LAG成员口故障，设备双归变单归场景下，在开启M-LAG三层转发增强功能后，将对于报文出端口为M-LAG成员接口的所有ARP表项、ND表项、静态路由表项和动态路由表项申请备份的FRR资源，使得出接口指向peer-link口并形成主备路径下发，将表项的下一跳由M-LAG成员口切换为peer-link口，从而提升故障场景下的切换性能。

注意：

• M-LAG成员口故障场景和M-LAG成员口故障恢复场景，MAC表项、ARP表项、ND表项、静态路由表项和动态路由表项的快速切换与表项的数量无关。

• peer-link与M-LAG成员接口之间存在的单向隔离机制会在主M-LAG成员口故障的情况下放开，防止出现流量不通。

• 为静态ARP表项申请的FRR资源在M-LAG成员口状态为Down且对应的VLANIF接口仍为Up时将不会释放，导致FRR资源消耗增加。

2.3、M-LAG设备故障

图2-3 M-LAG主设备故障组网示意图

图2-4 M-LAG备设备故障组网示意图

如图2-3所示，M-LAG主设备故障，M-LAG备设备将升级为主。原主设备侧M-LAG成员口链路状态变为Down，双归场景变为单归场景。

如图2-4所示，M-LAG备设备故障，M-LAG的主备状态不会发生变化，M-LAG备设备侧成员口链路状态变为Down。M-LAG主设备侧成员口链路状态仍为Up，流量转发状态不变，双归场景变为单归场景。

M-LAG设备故障恢复时，peer-link先UP，DFS状态重新协商，M-LAG成员口恢复UP，流量恢复负载分担。M-LAG主设备恢复后设备状态仍然为主，M-LAG备设备恢复后设备状态仍然为备。

2.5、心跳链路故障

图2-5 心跳链路故障组网示意图

心跳链路是用来检测M-LAG系统是否是双主，若心跳链路承载三层网络的业务，心跳故障对设备流量转发会有影响。若心跳链路承载二层业务或不承载三层业务，心跳故障对设备流量转发无影响，如图2-5所示。两种情况都会产生心跳故障告警。心跳链路故障恢复后，产生心跳故障恢复告警。

2.6、peer-link故障

图2-6 peer-link故障组网示意图

当peer-link故障但双主检测心跳状态正常时，在双主检测延时时间（缺省值为3s）后，默认会触发一端M-LAG设备上除逻辑端口、管理网口和peer-link接口以外的其他接口处于Error-Down状态，只保证另一端M-LAG设备正常流量转发。M-LAG系统按照如下先后顺序判断触发哪一端M-LAG设备的接口Error-Down：

1. 是否存在Up状态的上行口：若一端M-LAG设备的上行口全部为Down状态，且另一端M-LAG设备存在Up状态的上行口，则对上行口全部为Down状态的M-LAG设备触发端口Error-Down操作。

2. 出现过Down状态的物理接口的数量多少：比较两端M-LAG设备上出现过Down状态的物理接口的数量（以2分钟作为一个统计周期，两端M-LAG设备均取2分钟内和上一个2分钟出现过Down状态的物理接口的数量的最大值与对端M-LAG设备进行比较），对出现过Down状态的物理接口的数量更多的那一端M-LAG设备触发端口Error-Down操作。

3. 处于Up状态的M-LAG成员口的数量多少：比较当前两端M-LAG设备上处于Up状态的M-LAG成员口数量，对处于Up状态的M-LAG成员口数量更少的那一端M-LAG设备触发端口Error-Down操作。

4. 处于Up状态的物理接口的数量多少：比较当前两端M-LAG设备上处于Up状态的物理接口的数量，对处于Up状态的物理接口数量更少的那一端M-LAG设备触发端口Error-Down操作。

5. 其他场景，如图2-6所示，则对M-LAG备设备触发端口Error-Down操作。

注意：

建议将承载上行流量的接口配置为上行链路接口。如果设备没有配置上行链路接口，则按该设备上行口为Up状态处理。

如果用户需要主动隔离一端M-LAG设备，不能因手工操作（如shutdown peer-link接口）导致该M-LAG设备的peer-link接口处于Down状态，以避免该操作可能触发另一端M-LAG设备上端口Error-Down操作，从而导致两端M-LAG设备均无法转发流量，流量转发中断。

peer-link故障恢复时，处于Error Down状态的M-LAG成员口默认将在240s后自动恢复为Up状态，处于Error Down状态的其它接口将立即自动恢复为Up状态，流量恢复实现负载分担。

另外，通过在端口下配置命令可以灵活配置某个端口在peer-link故障但双主检测心跳状态正常时是否将端口Error-Down。peer-link故障但双主检测正常场景下设备端口Error-Down对应情况如表2-1所示。

表2-1设备在peer-link故障但双主检测正常时接口Error-Down情况

2.8、M-LAG二次故障（peer-link故障+M-LAG设备故障）

图2-7 M-LAG二次故障组网示意图

如图2-7所示，在M-LAG正常工作时，当peer-link故障但双主检测心跳状态正常会触发一端M-LAG设备上某些端口处于Error-Down状态，此时另一端M-LAG设备继续工作。在该场景的基础上，若另一端M-LAG设备又由于断电、整机故障重启等其他故障导致其不能工作时，此时M-LAG主备设备皆不能正常转发流量（图中以M-LAG备设备Error-Down为例）。

在该二次故障场景下，可以借助M-LAG二次故障增强来实现该故障场景下业务不中断的可靠性要求，下面通过M-LAG二次故障增强来说明不同的故障阶段和产生的行为（下文以M-LAG备设备Error-Down，M-LAG主设备又发生故障为例进行说明）：

1. 二次故障增强：在上述场景基础下，如果设备的二次故障增强功能已生效，则DFS状态为备的设备会借助M-LAG双主检测机制感知到DFS主设备故障（在一定周期内接收不到任何的M-LAG双主检测心跳报文）后，将升级为DFS主设备并恢复设备上处于Error-Down状态的端口为Up状态，继续转发流量。

   若配置了双主检测的peer-ip-address参数，则二次故障增强功能生效；若未配置双主检测的peer-ip-address参数，则二次故障增强功能不生效。

2. 设备故障恢复：若原DFS状态为主的设备故障恢复后但peer-link链路仍故障

   • 若配置LACP M-LAG的系统ID在一定时间内切换为本设备的LACP系统ID，则在LACP协商时接入侧仅选择上行链路中的一条链路为活动链路，实际流量转发正常。

   • 若配置LACP M-LAG的系统ID为缺省情况，即系统ID不回切，M-LAG两台设备均使用同一系统ID来与接入侧设备协商，链路均能被选中成为活动链路。该场景下，由于peer-link链路仍然故障，M-LAG两端无法同步对端的优先级、系统MAC等信息，形成M-LAG两台设备双主的情况，可能导致流量异常。此时，如图2-8所示，可以借助心跳链路报文中携带必要的DFS Group协商主备的必要信息（如DFS Group优先级、系统MAC等）来协商M-LAG两台设备的HB（HeartBeat） DFS主备信息，触发HB DFS状态为备的设备上某些端口处于Error-Down状态，HB DFS状态为主的设备继续工作。

     图2-8 M-LAG二次故障场景下设备故障恢复组网示意图

     

若在peer-link故障后，二次故障的设备为先前Error-Down的那一端M-LAG设备，则此时不会对流量转发行为产生影响，仍由另一端M-LAG设备进行流量转发。

注意：

如果设备配置了Monitor Link故障恢复下行口延时UP功能，但该功能在二次故障场景下不会生效，以减少业务中断时间。