基本概念

M-LAG（Multichassis Link Aggregation Group）即跨设备链路聚合组，是一种实现跨设备链路聚合的机制，如图所示，将SwitchA和SwitchB通过peer-link链路连接并以同一个状态和Switch进行链路聚合协商，从而把链路可靠性从单板级提高到了设备级。

看起来，M-LAG和堆叠很相似，但其实他们大有不同：

M-LAG建立

华为M-LAG的建立过程：

1. DFS Group配对

   当设备完成M-LAG配置后，设备首先通过peer-link链路发送DFS Group的Hello报文。当设备收到对端的Hello报文后，会判断报文中携带的DFS Group编号是否和本端相同，如果两台设备的DFS Group编号相同，则两台设备DFS Group配对成功。

2. DFS Group协商主备

   配对成功后，两台设备会向对端发送DFS Group的设备信息报文，设备根据报文中携带的DFS Group优先级以及系统MAC地址确定出DFS Group的主备状态。

   以SwitchB为例，当SwitchB收到SwitchA发送的报文时，SwitchB会查看并记录对端信息，然后比较DFS Group的优先级，如果SwitchA的DFS Group优先级高于本端的DFS Group优先级，则确定SwitchA为DFS主设备，SwitchB为DFS备设备。如果SwitchA和SwitchB的DFS Group优先级相同，比较两台设备的MAC地址，确定MAC地址小的一端为DFS主设备。

   • DFS Group的角色区分为主和备，正常情况下，主设备和备设备同时进行业务流量的转发，转发行为没有区别，仅在故障场景下，主备设备的行为会有差别。

3. M-LAG成员接口协商主备

   在DFS Group协商出主备状态后，M-LAG的两台设备会通过peer-link链路发送M-LAG设备信息报文，报文中携带了M-LAG成员接口的配置信息。在成员口信息同步完成后，确定M-LAG成员接口的主备状态。

   与对端同步成员口信息时，状态由Down先变为Up的M-LAG成员接口成为主M-LAG成员口，对端对应的M-LAG成员口为备，且主备状态默认不回切，即：当M-LAG成员接口状态为主的设备故障恢复后，先前由备状态升级为主状态的接口仍保持主状态，恢复故障的M-LAG成员接口状态为备，此处与DFS Group协商主备状态不一致。

   • 仅在M-LAG接入组播场景下，M-LAG成员接口的主备角色存在转发行为差异。

4. 双主检测

   协商出M-LAG主备后，两台设备之间会通过双主检测链路每1s发送一个M-LAG双主检测报文，15s为一个周期，若三个周期内两台设备均能够收到对端发送的双主检测报文，双活系统即开始正常的工作；若三个周期内未收到双主检测报文则心跳超时。一旦设备感知到peer-link故障，设备会按照每100ms发送三个双主检测链路报文，加速检测。

   在DFS Group配对失败或者peer-link故障场景下，双主检测链路用于检查是否出现双主的情况。双主检测链路可以通过外部网络承载（比如，如果M-LAG上行接入IP网络，那么两台双归设备通过IP网络可以互通，那么互通的链路就可以作为双主检测链路）。也可以单独配置一条三层可达的链路来作为双主检测链路（比如通过管理口）。

   • 双主检测链路通过管理网口互通，DFS Group绑定的管理网口IP地址要保证可以相互通信，管理网口下绑定VPN实例，保证双主检测报文与业务流量隔离。
   • 双主检测链路通过业务网络互通，DFS Group绑定的IP地址要保证可以三层互通。如果peer-link接口之间建立路由邻居关系，则业务网络双主检测报文会直接通过最优路由经peer-link链路传输。一旦peer-link故障，路由收敛期间，双主检测报文通过次优路径传输到对端，双主检测时间会慢0.5秒或者1秒的时间。
   • 两台设备在心跳链路Up之后即会按照周期发送双主检测报文。若DFS Group绑定了本端和对端的IP地址，则在二次故障恢复场景下（设备已使能二次故障增强功能），即原DFS主设备或备设备故障恢复且peer-link链路仍然故障时，M-LAG设备根据双主检测报文中携带的DFS信息协商出HB DFS主备状态，触发HB DFS状态为备的设备相应端口Error-Down，从而避免双主场景下的流量异常。

5. M-LAG同步信息

   正常工作后，两台设备之间会通过peer-link链路发送M-LAG同步报文实时同步对端的信息，M-LAG同步报文中主要包括MAC表项、ARP以及STP等，并发送M-LAG成员端口的状态，这样任意一台设备故障都不会影响流量的转发，保证正常的业务不会中断。

华三M-LAG的建立过程

与华为的M-LAG类似，只是协议报文不同。 M-LAG设备间通过交互DRCP（Distributed Relay Control Protocol，分布式聚合控制协议，相当于华为的DFS Group报文）报文和Keepalive报文（相当于华为的双主检测报文）建立和维护M-LAG系统。在M-LAG系统正常工作时，M-LAG系统的主备设备负载分担共同进行流量转发。如果M-LAG系统中出现故障（无论是接口故障、链路故障还是设备故障），M-LAG系统都可以保证正常的业务不受影响。

DRCP协议

M-LAG通过在peer-link链路上运行DRCP来交互分布式聚合的相关信息，以确定两台设备是否可以组成M-LAG系统。运行该协议的设备之间通过互发DRCPDU（Distributed Relay Control Protocol Data Unit，分布式聚合控制协议数据单元）来交互分布式聚合的相关信息。

1. DRCPDU的交互 两端M-LAG设备通过peer-link链路定期交互DRCP报文。当本端M-LAG设备收到对端M-LAG设备的DRCP协商报文后，会判断DRCP协商报文中的M-LAG系统配置是否和本端相同。如果两端的M-LAG系统配置均相同，则这两台设备可以组成M-LAG系统。

2. DRCP超时时间 DRCP超时时间是指peer-link接口等待接收DRCPDU的超时时间。在DRCP超时时间之前，如果本端peer-link未收到来自对端M-LAG设备的DRCPDU，则认为对端M-LAG设备peer-link接口已经失效。

DRCP超时时间同时也决定了对端M-LAG设备发送DRCPDU的速率。DRCP超时有短超时（3秒）和长超时（90秒）两种：

• 若本端DRCP超时时间为短超时，则对端M-LAG设备将快速发送DRCPDU（每1秒发送1个DRCPDU）。
• 若本端DRCP超时时间为长超时，则对端M-LAG设备将慢速发送DRCPDU（每30秒发送1个DRCPDU）。

主从协商

与华为类似，在peerlink或keepalive链路（peerlink链路down时）上进行协商具体规则如下：

1. 比较计算前角色，若有一端为Primary，另一端为None，则Primary端优；
2. 比较M-LAG MAD DOWN状态，若一端存在处于M-LAG MAD DOWN状态的接口，另一端不存在处于M-LAG MAD DOWN状态的接口，则不存在处于M-LAG MAD DOWN状态的接口的一端优；
3. 比较设备健康状况，健康值越小越优；
4. 比较设备角色优先级，数值越小越优；
5. 比较设备桥MAC，越小越优。 上述因素按顺序比较，结果为优的一端角色计算为Primary，另一端为Secondary

MAD机制

• peer-link链路故障后，为了防止从设备继续转发流量，M-LAG提供MAD机制，将从设备上除M-LAG保留接口和系统保留接口以外的接口置于M-LAG MAD DOWN状态；（部分设备的最新版本会在通过健康度检查后再进行MAD Down）
• 当peer-link链路故障恢复后，为了防止丢包，完成角色选举后，Primary角色的设备M-LAG接口配对成功后即可工作，立即转发流量，Secondary角色设备由于M-LAG MAD机制，要等待M-LAG MAD延迟恢复时间（默认30s）后才能工作。该延迟恢复时间主要用来设备之间同步相关表项。
  保留接口说明

  当peerlink链路down，keepalive链路存活时，触发mad down，此时选举出来的备设备会将除保留接口外的所有接口置于mad down状态。保留接口分为系统保留口及强制up口，以及用户手动配置的保留口 系统保留口及强制up口：管理口，peer-link接口及其成员，M-LAG聚合口（M-LAG成员口不保留），强制UP接口； 用户配置保留口： 1、keepalive接口（部分设备最新版本已设为了系统保留口），避免keepalive链路down，导致 二次故障 2、M-LAG接口和peerlink接口所在VLAN对应的VLAN虚接口需要配置为保留接口，为了避免后续peerlink链路恢复时，设备之间由于VLAN虚接口处于down状态无法同步相关表项 3、需要参与计算的Loopback口，evpn group ip等 4、当使用vxlan隧道作为peerlink链路时，需要将这些VSI接口进行保留

  此外，当接口处于mad down状态时，此时如果将其配置为保留接口，其不会接触down状态。

M-LAG配置一致性检查

主从协商后，设备之间通过DRCP报文进行一致性检查。

一致性检查分为一类和二类：

• Type 1类型配置：影响M-LAG系统转发的配置。如果Type 1类型配置不匹配，则将从设备上M-LAG接口置为down状态。
• Type 2类型配置：仅影响业务模块的配置。如果Type 2类型配置不匹配，从设备上M-LAG接口依然为up状态，不影响M-LAG系统正常工作。由Type 2类型配置对应的业务模块决定是否关闭该业务功能，其他业务模块不受影响。
• 一类和二类又分为全局下的配置和M-LAG接口下的配置 其中，华为和华三的一致性检查具体内容不同，各个设备的检查内容也有细微差别，具体型号可以查看官网配置手册，基本内容见下表：

Keepalive协议

M-LAG设备间通过Keepalive链路检测邻居状态，即通过交互Keepalive报文（UDP）来进行peer-link链路故障时的双主检测。

如果在指定时间内，本端M-LAG设备收到对端M-LAG设备发送的Keepalive报文：

• 如果peer-link链路状态为down，则本端和对端M-LAG设备根据收到的Keepalive报文选举主从设备，保证M-LAG系统中仅一台M-LAG设备转发流量，避免两台M-LAG设备均升级为主设备。
• 如果peer-link链路状态为up，则M-LAG系统正常工作。 如果在指定时间内，本端M-LAG设备未收到对端M-LAG设备发送的Keepalive报文时：
• 如果peer-link链路状态为down，则认为对端M-LAG设备状态为down：
  • 本端设备为主设备时，如果本端设备上存在处于up状态的M-LAG接口，则本端仍为主设备；否则，本端设备角色变为None角色。
  • 本端设备为从设备时，则升级为主设备。此后，只要本端设备上存在处于up状态的M-LAG接口，则保持为主设备，否则本端设备角色变为None角色。

当设备为None角色时，设备不能收发Keepalive报文，Keepalive链路处于down状态。

• 如果peer-link链路状态为up，则认为Keepalive链路状态为down。此时主从设备正常工作，同时设备打印日志信息，提醒用户检查Keepalive链路。

数据同步

M-LAG系统正式工作后，两设备之间会实时同步对端信息，如MAC、ARP表项，保证任意一台设备故障不影响流量转发，保证业务正常进行。具体同步细节见 表项同步过程探究

M-LAG防环机制

从接入设备或网络侧到达M-LAG配对设备的单播流量，会优先从本地转发出去，peer-link链路一般情况下不用来转发数据流量。当流量通过peer-link链路广播到对端M-LAG设备，在peer-link链路与M-LAG成员口之间设置单方向的流量隔离，即从peer-link口进来的流量不会再从M-LAG口转发出去，所以不会形成环路，这就是M-LAG单向隔离机制。

单向隔离

当M-LAG两台设备协商出M-LAG主备后，系统通过M-LAG同步报文判断接入设备是否双活接入

• 若接入设备双活接入M-LAG系统，则M-LAG两台设备下发对应M-LAG成员口的单向隔离配置，来隔离由peer-link口发往M-LAG成员口的流量。
  • M-LAG防环机制中的单向隔离对二层(包括单播、组播、广播)流量生效，三层组播流量生效，三层单播流量不生效。
• 若接入设备单归接入M-LAG系统，则M-LAG系统不会下发对应M-LAG成员口的单向隔离配置

实现原理：

在设备双活接入M-LAG场景下，设备会默认按下列顺序下发全局ACL配置：

• Rule1：允许通过源端口为peer-link接口，目的端口为M-LAG成员口的三层单播报文；
• Rule2：拒绝通过源端口为peer-link接口，目的端口为M-LAG成员口的所有报文；

设备通过匹配ACL规则组来实现peer-link接口与M-LAG成员口之间的单向隔离，隔离由peer-link接口发往M-LAG成员口的广播等泛洪流量。当M-LAG设备感知到本端的M-LAG成员口状态为Down时，会通过peer-link发送M-LAG同步报文，通知对端设备撤销自动下发的相应的M-LAG成员端口的单向隔离ACL规则组。

流量转发

M-LAG双活系统建立成功后即进入正常的工作，M-LAG主备设备负载分担共同进行流 量的转发，转发行为没有区别

单播流量转发

• 对于南北向的单播流量，在M-LAG接入侧，M-LAG设备接收到接入设备通过聚合链路负载分担发送的流量后，按本地转发优先原则，共同进行流量转发。发往Network侧的流量到达M-LAG设备后将根据路由表转发流量。
• 对于东西向的单播流量，二层流量通过M-LAG本地优先转发，三层流量通过双活网关转发，都不经过peer-link链路，直接由M-LAG设备转发。

未知单播/广播流量转发

当M-LAG系统接入二层网络时，假设右侧M-LAG上行接口被STP协议阻塞，M-LAG主设备收到广播流量后向各个下 一跳转发，当流量到达M-LAG备设备时，由于peer-link与M-LAG成员接口存在单向隔离机制，到达备设备的流量不会向S-1转发。

当M-LAG系统接入三层网络时，M-LAG备设备收到广播流量后 向各个下一跳转发，当流量到达M-LAG主设备时，由于peer-link与M-LAG成员接 口存在单向隔离机制，到达主设备的流量不会向S-1转发。

组播流量转发

二层组播流量

分为两种情况，组播源接入M-LAG系统和组播接收者接入M-LAG系统

组播源接入M-LAG

表项建立：

1. Device C发送的IGMP/MLD查询报文，通过Device C的聚合口进行负载分担，分别到达Device A和Device B的M-LAG接口。

2. Device A和Device B分别将各自的M-LAG接口添加到路由器端口列表中，并通过peer-link链路互相发送给对端设备。Device A和Device B从peer-link接口收到的对端发送的查询报文，不会再向各自的M-LAG接口转发。

3. Device A收到来自下游接收者的IGMP/MLD Report报文后，从Report报文中解析出主机要加入的组播组地址G，生成二层组播转发表项（*，G），将接收端口作为成员端口添加到出端口列表。同时，将IGMP/MLD Report报文通过peer-link链路发送给Device B。

4. Device B收到Report报文后，同样生成二层组播转发表项（*，G），同时将peer-link接口作为成员端口添加到出端口列表中。但是，Device B并不会将该报文从自己的路由器端口（M-LAG接口）转发出去。

数据转发：

1. 组播源发送的组播流量，通过负载分担方式到达Device A和Device B。

2. Device A和Device B，通过peer-link链路互相发送各自接收到的组播数据流量给对方。这样，保证Device A和Device B上都能收到完整的组播数据流量。

3. Device A将完整的组播数据流量发送给下游接收者。

组播接收者接入M-LAG

表项建立：

1. Device A收到上游二层网络发送的IGMP/MLD查询报文后，将接收报文的端口添加到动态路由器端口列表中，并通过peer-link链路发送给Device B。

2. Device B收到查询报文后，将peer-link接口添加到路由器端口列表中。

3. Device A或者Device B中的任意一台设备，收到下游设备Device C发送的IGMP/MLD Report报文后，从Report报文中解析出主机要加入的组播组地址G1和G2，分别在各自设备上生成二层组播转发表项（，G1）和（，G2），出端口分别为各自的M-LAG接口。

   假设Device A收到的为加入组播组G1的Report报文，Device B收到的为加入组播组G2的Report报文。

4. Device A和Device B分别将Report报文通过peer-link链路透传给对端设备。以Device A为例，Device A收到Device B发送的Report报文后，在生成二层组播转发表项（，G2），同时将Device A上的M-LAG接口添加到出端口列表中。Device B的处理过程类似，将在本地生成（，G1）的二层组播转发表项。

数据转发：

1. 组播源发送的组播流量，通过二层网络到达Device A。

2. Device A通过peer-link链路将收到的组播数据流量发送给Device B。此时，只有Device A会向下游Device C转发组播流量，而Device B上虽然生成了二层组播转发表项，但不会向下游Device C转发组播流量。

3. Device C收到后，将流量转发给接收者。

三层组播流量

组播源接入M-LAG

表项建立：

1. Device A收到PIM/IPv6 PIM加入报文后，不会将报文通过peer-link链路同步给Device B，而是在获取了组播组的接收者信息后，生成了（*，G）表项。

2. 组播源发送给接收者的组播数据报文，会通过负载分担的方式分别到达Device A和Device B的M-LAG接口。Device A和Device B会通过peer-link链路将各自接收到的报文发送给对端，从而使两台设备上都能收到完整的组播流量。Device A上根据收到的组播数据流量建立（S，G）表项。

流量转发：

1. 组播源发送的组播流量，通过负载分担方式到达Device A和Device B。

2. Device A和Device B，通过peer-link链路互相发送接收到的组播数据流量。这样，保证Device A和Device B上都能收到完整的组播数据流量。

3. Device A将收到的完整的组播数据流量发送给下游接收者。

组播接收者接入M-LAG

作为M-LAG设备的Device A和Device B通过peer-link链路连接，Device C与组播接收者相连。Device A和Device B上与Device C相连的M-LAG接口上，均需要配置PIM/IPv6 PIM消极模式，保证Device A和Device B均能收到组播源发送的所有的组播数据流量。

表项建立

1. Device A或者Device B中的任意一台设备，收到下游设备Device C发送的IGMP/MLD Report报文。Device A或者Device B从Report报文中解析出主机要加入的组播组地址，分别生成（，G1）和（，G2）三层组播转发表项，将M-LAG接口添加到出端口列表中。

2. Device A和Device B分别将Report报文通过peer-link链路透传给对端设备。以Device A为例，Device A收到Device B发送的Report报文后，在生成三层组播转发表项（，G2），同时将Device A上的M-LAG接口添加到出端口列表中。Device B的处理过程类似，将在本地生成（，G1）的组播转发表项。

3. Device A和Device B上的组播组信息将保持同步，生成相同的（，G1）和（，G2）组播转发表项。

4. Device A和Device B根据网络中配置PIM模式工作机制，最终在设备上生成相同的PIM路由表项。此处，以网络配置的PIM模式为PIM-SM示例。

流量转发

1. 组播源发送的组播流量，通过三层网络分别到达Device A和Device B。

2. Device A和Device B向下游转发组播流量时，采用奇偶原则对组播流量进行负载分担。M-LAG系统编号为奇数的成员设备转发组播组地址为奇数的流量，M-LAG系统编号为偶数的成员设备转发组播组地址为偶数的流量。

表项同步

Rlink报文 H3C的M-LAG实现中，使用Rlink报文（在PeerLink链路上交互）进行协议控制报文的交互和表项的同步，如STP的根桥信息、一致性检查内容、ARP报文、MAC表项。 Rlink报文使用可靠传输，支持重传（承载于以太网），在Peerlink链路上进行点对点传输，仅一跳，无法泛洪。

ARP同步&ARP学习

VRRP组网

聚合接入的场景

在VRRP+M-LAG中，两台M-LAG设备均有虚拟IP的虚拟MAC，而仅在VRRP Master设备上有虚拟IP，即仅master设备会回应目的IP为虚拟IP的相关报文，如ARP请求、ICMP报文等。 以SW3ping虚ip(10.1.1.1–>10.1.1.254)为例子，分析一下ARP报文的同步过程

1. SW3发送ARP报文请求10.1.1.254的mac地址，在聚合口上，报文hash后，发送给了S2
2. S2收到该广播请求报文，由于从设备上不存在虚拟ip，因此不会应答，会将该报文继续泛洪到相关vlan口，如peerlink口，同时，由于是从M-LAG接口上收到的ARP报文，因此会将该报文封装到Rlink报文，发送给对端M-LAG设备
3. S1在peerlink链路上会收到两个ARP报文，一个是泛洪过来的普通ARP，另一个是在Rlink报文中的ARP报文，其中，对于Rlink发送过来的ARP报文，由于打上了Rlink标记，不会对该请求报文进行应答。同时，对于Rlink发送过来的ARP报文，会将其学习到M-LAG接口下，覆盖了学习到peerlink的表项，因此应答该报文时，会从M-LAG接口发送给SW3。
4. 最终，在各设备上查看ARP表，结果如下：

5. SW3具有arp表项后，封装icmp报文，在聚合口上发送时hash到了SW2链路上，此时SW2查看目的mac为自己（虚拟ip对应的虚拟mac），进行三层转发，查路由表和ARP表后通过peerlink发送给SW1，SW1直接发送回SW3，不通过peerlink链路。

为探究多种情况，此时切换一下VRPP的主备状态，拓扑如下 同样地，使用SW3 ping 10.1.1.254，查看ARP学习过程

1. 情况一样，SW3发送的ARP请求报文hash，发给了SW2，SW2作为虚拟ip的拥有者，直接回应ARP报文给SW3
2. 同时，尽管SW2回复了ARP报文，但仍会继续泛洪该ARP请求广播报文，通过peerlink发送给SW1，并且由于时从M-LAG接口收到的ARP报文，会复制一份进Rlink，发送给SW1，因此SW1会收到两份ARP请求报文，在Rlink收到ARP报文，会将其学习到M-LAG接口下，由于自己并不具有虚拟ip，因此并不会应答。并且由于单向隔离，因此不会将该广播报文继续泛洪回SW3
3. 最终三台设备的ARP表项情况和第一种场景一致
4. SW3拥有10.1.1.254的mac地址后，封装icmp报文，hash到了SW2链路上，SW2作为ip拥有者，直接应答icmp报文给SW3

单挂场景

以SW4 ping SW3为例，分析ARP报文同步过程

1. SW4发送ARP广播报文请求SW3的mac地址
2. SW2收到该报文后，按照正常的ARP报文进行泛洪，发送给SW1和SW3，但不学习该ARP，因为并不是在M-LAG接口上接收到请求报文(尽管SW2上有对应的虚接口)。
3. SW1收到该ARP报文后，由于单向隔离，因此ARP报文在该设备终结了，同时将该ARP（10.1.1.2）学习到peerlink接口上
4. SW3收到该请求报文，由于自己拥有请求的ip地址，因此会进行arp应答，发送给SW4
5. 至此，各设备的ARP表项如下

SW2上无arp表项

总结

1、VRRP的虚地址只存在于主设备上； 2、M-LAG设备之间同步的是ARP报文，而不是表项（MAC同步的是表项） 3、M-LAG接口收到ARP广播报文，会按照正常的逻辑从peer-link链路和其他接口泛洪转发；同时会Copy到CPU，封装到RLink报文中同步给另一台M-LAG设备；并且如果本地具有对应的VLAN虚接口，则会学习ARP到M-LAG接口下，对端设备也会学习到M-LAG接口下 4、单挂口收到的ARP广播报文，正常泛洪给，但不会通过Rlink发送给对端设备，即使本地有对应的VLAN虚接口 5、peerlink接口收到ARP广播报文，如果请求的不是自己，但具有对应的vlan虚接口，则会将该ARP学习到vlan虚接口下，出接口为peerlink接口(单挂下的设备) 6、从M-LAG接口与peer-link接口收到同一个源IP的ARP报文的处理遵循M-LAG接口优先原则，但peerlink接口收到的可以覆盖M-LAG接口收到的，当且仅当查询ARP对应的mac地址出接口也为peerlink接口时，才可以覆盖，如一台设备原本接在M-LAG接口下，接着在ARP老化时间内单挂在了M-LAG设备上，此时便会将原ARP覆盖。(MAC表项的同步规则见下一节) 7、VRRP+M-LAG组网中，两台设备均有虚拟IP对应的虚拟mac，因此可以实现本地转发。

VLAN双活组网

ARP表项的同步与学习和VRRP学习基本一致，唯一区别是，Device1和Device2均具有同一个IP地址和MAC地址(10.1.1.3)，因此均会回应ARP请求报文。该场景对于下联设备无问题，因为下联设备聚合接入，认为对端设备作为自己的网关，发出的三层流量负载分担到两台M-LAG设备，M-LAG设备根据FIB表进行三层转发。

但对于上行设备，需要建立路由邻居时，由于是分别单挂接入Device A，因此会发生地址冲突问题，解决方案有两个： 1、在网关接口上配置同网段的M-LAG虚拟IP地址，如图中的100.1.1.101和100.1.1.102，用这两个接口进行三层连接 2、另外创建一个VLAN虚接口，如图中的vlan101，用该vlan虚接口去与上行进行三层连接。并在peerlink链路上放通该vlan，保证当其中一台设备的上行链路down，下行流量可以绕行到另一台设备进行处理。

MAC表项同步

MAC地址的同步，不像ARP那么复杂，就是两台设备的所有MAC表项同步，同步的是表项，而不是报文。设备之间通过Rlink报文同步MAC表项，其中无论是M-LAG接口下还是单挂接口下的表项，均会同步给对端设备。 1、M-LAG系统中，peerlink接口不主动学习mac地址，而是通过同步 2、M-LAG中M-LAG接口学习的MAC表项同步到另一台设备的M-LAG接口； 3、M-LAG中单挂学习到的MAC表项会同步到另一台设备的peer-link接口；

单挂要同步MAC的原因：如果不同步，则另一台设备要去往该单挂设备的流量就需要泛洪发送，为了减少泛洪流量，进行mac同步

M-LAG故障场景

M-LAG接口故障

M-LAG接口故障，来自外网侧的流量会通过peer-link链路发送给另外一台设备，所有流量均由另外一台M-LAG设备转发，具体过程如下：

1. Device B的某M-LAG接口故障，外网侧不感知，流量依然会发送给所有M-LAG设备。
2. Device A的相同M-LAG接口正常，则Device B收到外网侧访问Device C的流量后，通过peer-link链路将流量交给Device A后转发给Device C。
3. 故障恢复后，Device B的该M-LAG接口up，流量正常转发。

peerlink链路故障

peer-link链路故障但Keepalive链路正常会导致备设备上除M-LAG保留接口以外的接口处于M-LAG MAD DOWN状态。主设备上的M-LAG接口所在聚合链路状态仍为up，备设备上的M-LAG接口所在聚合链路状态变为down，从而保证所有流量都通过主设备转发。一旦peer-link链路故障恢复，处于M-LAG MAD DOWN状态的接口经过延迟恢复时间自动恢复为up状态。

设备故障

Device A为主设备，Device B为备设备。当主设备故障后，主设备上的聚合链路状态变为down，不再转发流量。备设备将升级为主设备，该设备上的聚合链路状态为up，流量转发状态不变，继续转发流量。主设备故障恢复后，M-LAG系统中由从状态升级为主状态的设备仍保持主状态，故障恢复后的设备成为M-LAG系统的备设备。

如果是备设备发生故障，M-LAG系统的主备状态不会发生变化，备设备上的聚合链路状态变为down。主设备上的聚合链路状态为up，流量转发状态不变，继续转发流量。

上行链路故障

上行链路故障并不会影响M-LAG系统的转发。 Device A上行链路虽然故障，但是外网侧的转发相关表项由Device B通过peer-link链路同步给Device A，Device A会将访问外网侧的流量发送给Device B进行转发。而外网侧发送给Device C的流量由于接口故障，自然也不会发送给Device A处理。

上行链路故障时，如果通过Device A将访问外网侧的流量发送给Device B进行转发，会降低转发效率。此时用户可以配置Monitor Link功能，将M-LAG组成员端口和上行端口关联起来，一旦上行链路故障了，会联动M-LAG组成员端口状态，将其状态变为down，提高转发效率。

二次故障

M-LAG二次故障是指在peer-link发生故障后，Keepalive链路也发生故障，或者在Keepalive链路发生故障后，peer-link也发生故障。针对M-LAG设备上不同的配置情况，当发生二次故障时，处理方式不同。（这里主要介绍的是H3C的二次故障处理机制）

缺省情况的处理

若peer-link链路先发生故障，此时两端M-LAG设备会根据Keepalive链路进行设备角色选举，并依据MAD检测机制，将从设备上除M-LAG保留接口外的所有接口置为M-LAG MAD DOWN状态。 此后，若Keepalive链路也发生故障，从设备也会升为主设备，并解除设备上所有接口的M-LAG MAD DOWN状态，以双主双活的方式转发流量。由于peer-link链路故障时，无法同步表项，可能导致流量转发错误。

若Keepalive链路先发生故障，peer-link链路后发生故障，则M-LAG设备上的接口不会被置为M-LAG MAD DOWN状态，而是直接以双主双活的方式转发流量，可能导致流量转发错误（表项在peer-link链路 down之前有同步，对单挂业务和新上业务会有影响）

开启M-LAG MAD DOWN状态保持功能场景

使用M-LAG mad persistent命令开启MAD DOWN状态保持功能

peer-link链路先发生故障，依据MAD检测机制，将从设备上除M-LAG保留接口外的所有接口置为MAD DOWN状态。此后，若Keepalive链路也发生故障，从设备也会升为主设备；但由于M-LAG设备已开启MAD DOWN状态保持功能，将不会解除设备上所有接口的MAD DOWN状态，继续只从原来的主设备转发流量。这样将不会出现双主双活的情况，避免流量转发异常；

若Keepalive链路先发生故障，peer-link链路后发生故障，则M-LAG设备上的接口不会被置为M-LAG MAD DOWN状态，而是直接以双主双活的方式转发流量。M-LAG MAD DOWN状态保持功能不能解决Keepalive链路先故障，peer-link后故障导致的双主双活问题。

那么还有一个问题，如果开启了MAD DOWN功能，但在二次故障场景下，主设备此时down了，那么由于备设备保持了MAD DOWN，M-LAG系统无法转发流量，如何解决？ 解决方案：通过M-LAG mad restore立刻解除从设备上所有接口的MAD DOWN状态，以保证流量正常转发，减少流量中断时间

开启设备独立工作功能场景

通过M-LAG standalone enable命令开启独立工作模式

peer-link链路先发生故障，依据MAD检测机制，将从设备上除M-LAG保留接口外的所有接口置为MAD DOWN状态。此后，若Keepalive链路也发生故障，从设备也会升为主设备，解除所有接口的MAD DOWN状态。设备已开启立即或延迟切换到设备独立工作状态功能，两台M-LAG设备将切换到独立工作状态，切换后M-LAG接口对应的聚合接口发送的LACP报文将还原为聚合接口的LACP系统MAC地址和LACP系统优先级；这样只有一边聚合接口的成员端口可以被选中，通过被选中的设备转发业务流量。若选中的成员端口也发生故障，则将选中另外一台设备上聚合接口的成员端口，通过该聚合接口继续转发流量

若Keepalive链路先发生故障，peer-link链路后发生故障，则M-LAG设备上的接口不会被置为M-LAG MAD DOWN状态，将立即或延迟一段时间切换到设备独立工作模式。

M-LAG的STP计算

M-LAG作为一个跨设备链路聚合技术，在逻辑拓扑中，两台设备是作为一台设备与外部进行连接的，因此在STP计算中，两台设备统一作为一个STP桥参与生成树的计算。而要进行统一计算，则交给M-LAG系统的主设备进行计算。但对于单挂接入的设备，此时逻辑拓扑中M-LAG系统应该分开来看，因此单挂接入时，应该是各自计算。 因此，有以下几个定义(概念)

1. 整个M-LAG系统是一个STP桥，STP桥ID中的桥MAC使用系统MAC
2. 当M-LAG设备非根设备时，整个M-LAG系统具有唯一 一个根端口
3. peer-link接口端口关闭拓扑协议
4. STP对M-LAG接口集中式计算，单挂口独立计算；

其中，无论对于聚合接入还是单挂接入，只要M-LAG系统未进入独立工作模式，BPDU报文中携带的桥mac均未配置的system mac

第二，当系统为非根桥时，设备通过Rlink报文同步根端口信息，保证整个系统拥有唯一一个根端口。如下图，根端口在SW1上，则在SW2上查看根端口时，显示在M-LAG对端设备上。

第三，peerlink链路上默认关闭了stp功能，设备之间通过Rlink报文交互STP报文。通过将Rlink报文认为是一台设备内部交互的报文，也就可以理解为什么peerlink不需要收发STP报文了。

第四，M-LAG接口下收到的BPDU报文，会通过Rlink报文发送给主设备，交给主设备进行生成树角色的计算以及同步

可以看到，两台设备上的M-LAG接口的端口角色和状态均一致。

而单挂接入时，是由设备本身进行计算得到的

可以看到，在SW2上并没有显示相关的STP端口信息，即SW1独自计算了设备的生成树角色，且没有同步给对端设备。

配置注意事项

由于M-LAG系统作为一个统一的STP桥设备，因此在两台设备上的生成树配置需要保持一致，当配置不一致时，在某些场景会出现一些问题。如配置了主备根桥，且一台设备同时单挂接入M-LAG系统时，会触发dispute 原因：主备根各自发送以自己为根桥的BPDU报文，SW2收到后将1口选举为根端口，PA协商后进入转发状态，2口继续发送以SW1为根的BPDU报文，备根收到后，发现其中的桥mac与自己相同，因此不进行处理，继续认为自己是根桥，经过Forwarding delay后，备根的31口进入forwarding状态，此时SW3收到了处于Forwarding或Learning状态的指定端口发送的低优先级的BPDU报文，触发了dispute。

参考文章

https://e.huawei.com/cn/material/networking/dcswitch/b5cc12697eed491d8c1b1abf0b4b327a

https://www.h3c.com/cn/Service/Document_Software/Document_Center/Home/Public/00-Public/Learn_Technologies/White_Paper/M-LAG_White_Paper-Long/?CHID=713453#_Toc139465288