M LAG简介
基本概念
M-LAG（Multichassis Link Aggregation Group）即跨设备链路聚合组，是一种实现跨设备链路聚合的机制，如图所示，将SwitchA和SwitchB通过peer-link链路连接并以同一个状态和Switch进行链路聚合协商，从而把链路可靠性从单板级提高到了设备级。
| 概念 | 说明 |
|---|---|
| DFS Group | 动态交换服务组DFS Group（Dynamic Fabric Service Group），主要用于部署M-LAG设备之间的配对，M-LAG双归设备之间的接口状态，表项等信息同步需要依赖DFS Group协议进行同步。 |
| DFS主设备 | 部署M-LAG且状态为主的设备，通常也称为M-LAG主设备。 |
| DFS备设备 | 部署M-LAG且状态为备的设备，通常也称为M-LAG备设备。**说明：**DFS Group的角色区分为主和备，正常情况下，主设备和备设备同时进行业务流量的转发，转发行为没有区别，仅在故障场景下，主备设备的行为会有差别。 |
| 双主检测链路 | 双主检测链路，又称为心跳链路，是一条三层互通链路，用于M-LAG主备设备间发送双主检测报文。**说明：**正常情况下，双主检测链路不会参与M-LAG的任何转发行为，只在故障场景下，用于检查是否出现双主的情况。双主检测链路可以通过外部网络承载（比如，如果M-LAG上行接入IP网络，那么两台双归设备通过IP网络可以互通，那么互通的链路就可以作为双主检测链路）。也可以单独配置一条三层可达的链路来作为双主检测链路（比如通过管理口）。 |
| peer-link接口 | peer-link链路两端直连的接口均为peer-link接口。 |
| peer-link链路 | peer-link链路是一条直连链路且必须做链路聚合，用于交换协商报文及传输部分流量。接口配置为peer-link接口后，该接口上不能再配置其它业务。为了增加peer-link链路的可靠性，推荐采用多条链路做链路聚合。 |
| HB DFS主设备 | 通过心跳链路来协商的状态为主的设备。**说明：**通过心跳链路报文来协商的设备HB DFS主备状态在正常情况下，对M-LAG的转发行为不会产生影响，仅用于二次故障恢复场景下，在原DFS主设备或备设备故障恢复且peer-link链路仍然故障时，触发HB DFS状态为备的设备上相应端口Error-Down，避免M-LAG设备在双主情况下出现的流量异常。 |
| HB DFS备设备 | 通过心跳链路来协商的状态为备的设备。**说明：**通过心跳链路报文来协商的设备HB DFS主备状态在正常情况下，对M-LAG的转发行为不会产生影响，仅用于二次故障恢复场景下，在原DFS主设备或备设备故障恢复且peer-link链路仍然故障时，触发HB DFS状态为备的设备上相应端口Error-Down，避免M-LAG设备在双主情况下出现的流量异常。 |
| M-LAG成员接口 | M-LAG主备设备上连接用户侧主机（或交换设备）的Eth-Trunk接口。为了增加可靠性，推荐链路聚合配置为LACP模式。M-LAG成员接口角色也区分主和备，与对端同步成员口信息时，状态由Down先变为Up的M-LAG成员接口成为主M-LAG成员口，对端对应的M-LAG成员口为备。**说明：**仅在M-LAG接入组播场景下，M-LAG成员接口的主备角色存在转发行为差异。 |
看起来，M-LAG和堆叠很相似，但其实他们大有不同：
| 对比维度 | 堆叠 | M-LAG（推荐） |
|---|---|---|
| 可靠性 | 一般：控制面集中，故障可能在成员设备上扩散设备级、单板级、链路级等都具备高可靠性 | 更高：控制面独立，故障域隔离设备级、单板级、链路级等都具备高可靠性 |
| 配置复杂度 | 简单：逻辑上是一台设备 | 简单：两台设备独立配置 |
| 成本 | 一般：需要部署堆叠线缆 | 一般：需要部署Peer-link连线 |
| 性能 | 一般：主交换机控制面要控制所有堆叠成员的转发面，CPU负载加重 | 高：成员交换机独立转发，CPU负载保持不变 |
| 升级复杂度 | 高：通过堆叠快速升级可以降低业务中断时间，但升级操作时间变长，升级风险变高 | 低：两台设备可分别单独升级，升级操作简单，风险低 |
| 升级中断时间 | 相对较长：通过堆叠快速升级，典型配置组网下，业务中断时间在20秒~1分钟左右，与业务量强相关 | 短：流量秒级中断 |
| 网络设计 | 相对简单：堆叠设备逻辑上为一台设备，网络结构较简单 | 相对复杂：M-LAG设备逻辑上仍然是两台设备，网络结构较复杂 |
| 适用场景 | 对软件版本升级中断时间无要求希望网络维护简单 | 对软件版本升级时业务中断时间要求较高对网络可靠性要求更高可接受增加一定程度的维护复杂度 |
M-LAG建立
华为M-LAG的建立过程：
DFS Group配对
当设备完成M-LAG配置后，设备首先通过peer-link链路发送DFS Group的Hello报文。当设备收到对端的Hello报文后，会判断报文中携带的DFS Group编号是否和本端相同，如果两台设备的DFS Group编号相同，则两台设备DFS Group配对成功。
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的角色区分为主和备，正常情况下，主设备和备设备同时进行业务流量的转发，转发行为没有区别，仅在故障场景下，主备设备的行为会有差别。
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成员接口的主备角色存在转发行为差异。
双主检测
协商出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，从而避免双主场景下的流量异常。
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，分布式聚合控制协议数据单元）来交互分布式聚合的相关信息。
- 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）。
主从协商
角色计算触发条件包括：
- M-LAG设备在系统初始化时（包括新配置M-LAG或带M-LAG配置重启设备）。
- peer-link链路UP时，设备角色通过peer-link链路计算。
- peer-link链路故障，Keepalive正常工作，设备角色通过Keepalive链路计算。
- peer-link链路和Keepalive链路均故障，根据本端M-LAG设备上M-LAG接口状态决定设备角色。
与华为类似，在peerlink或keepalive链路（peerlink链路down时）上进行协商具体规则如下： 当通过peer-link链路或Keepalive链路交互报文计算设备角色时，依次比较如下因素：
- 比较设备所有M-LAG接口的状态，有可工作M-LAG接口的一端为优；
- 比较计算前角色，若有一端为Primary，另一端为None，则Primary端优；
- 比较M-LAG MAD DOWN状态，若一端存在处于M-LAG MAD DOWN状态的接口，另一端不存在处于M-LAG MAD DOWN状态的接口，则不存在处于M-LAG MAD DOWN状态的接口的一端优；
- 比较设备健康状况，健康值越小越优。设备的健康值可通过display system health命令查看，健康值越小设备越健康，设备无故障运行时，健康值为0。有关display system health命令的详细介绍，请参见“基础配置命令参考”中的“设备管理”；
- 比较设备角色优先级，越高越优；
- 比较设备桥MAC，越小越优。
上述因素按顺序比较，结果为优的一端角色计算为Primary，另一端为Secondary。 如果设备通过peer-link链路计算角色，则不比较设备所有M-LAG接口的状态。
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延迟恢复时间（默认300s）后才能工作。该延迟恢复时间主要用来设备之间同步相关表项，设备会在延迟恢复定时器一半时间之后进行配置一致性检查，为避免在延迟恢复时造成M-LAG接口震荡。
当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接口下的配置 其中，华为和华三的一致性检查具体内容不同，各个设备的检查内容也有细微差别，具体型号可以查看官网配置手册，基本内容见下表：
一类检查
| 全局下配置 | 一致性检查内容 |
|---|---|
| peer-link接口链路类型 | Access、Hybrid和Trunk |
| peer-link接口的PVID | peer-link接口的PVID |
| 生成树功能 | 全局生成树功能是否开启和VLAN内生成树功能是否开启仅当生成树模式为PVST时，才对VLAN内生成树功能进行一致性检查 |
| 生成树模式 | STP、RSTP、PVST和MSTP |
| MST域相关配置 | MST域的域名、MSTP的修订级别和MSTI与VLAN的映射关系 |
| M-LAG接口下的配置 | 一致性检查内容 |
|---|---|
| 聚合组的工作模式 | 静态聚合组和动态聚合组 |
| 接口生成树功能 | 接口上的生成树功能是否开启 |
| 接口的链路类型 | Access、Hybrid和Trunk |
| 接口的PVID | M-LAG接口的PVID |
二类检查
| 全局下配置 | 一致性检查内容 |
|---|---|
| 接口所属的VLAN | peer-link接口所属的VLAN先比较接口上携带Tag的VLAN，再比较接口上未携带Tag的VLAN |
| VLAN接口 | VLAN接口处于up状态，且peer-link接口加入该VLAN |
| VLAN接口状态 | VLAN接口是否被手工关闭 |
| VLAN接口的IPv4地址 | VLAN接口IPv4地址是否配置 |
| VLAN接口的IPv6地址 | VLAN接口IPv6地址是否配置 |
| VLAN接口的IPv4 VRRP备份组虚拟IP地址 | VLAN接口IPv4 VRRP备份组虚拟IP地址是否配置 |
| 全局BPDU保护 | 全局的BPDU保护功能是否配置 |
| MAC地址老化时间 | MAC地址老化时间 |
| 端口安全的M-LAG接口上用户认证的负载分担模式 | 端口安全的M-LAG接口上用户认证的负载分担模式：· Centralized：集中处理· Local：分布处理本地上送用户· Odd-MAC：分布处理奇MAC用户· Even-MAC：分布处理偶MAC用户 |
| 允许MAC迁移功能 | 允许MAC迁移功能是否开启 |
| 允许MAC迁移的方式 | 允许MAC迁移的方式：· Port：允许用户进行端口迁移· VLAN：允许用户进行VLAN迁移· All：允许用户进行端口和VLAN迁移 |
| 802.1x系统的认证方法 | 802.1x系统的认证方法：· Chap：启用EAP终结方式，并支持与RADIUS服务器之间采用CHAP类型的认证方法· Eap：启用EAP中继方式，并支持客户端与RADIUS服务器之间所有类型的EAP认证方法· Pap：启用EAP终结方式，并支持与RADIUS服务器之间采用PAP类型的认证方法 |
| MAC地址认证采用的认证方法 | MAC地址认证采用的认证方法：· Chap：采用CHAP类型的认证方法· Pap：采用PAP类型的认证方法 |
| VSI名称 | M-LAG接口上AC关联的VSI的名称 |
| VNI | VSI的VXLAN ID |
| 网关接口编号 | VSI关联的网关接口编号 |
| VSI虚接口编号 | VSI关联的VSI虚接口编号 |
| VSI虚接口的MAC地址 | VSI关联的VSI虚接口的MAC地址 |
| VSI虚接口的IPv4地址 | VSI关联的VSI虚接口的IPv4地址 |
| VSI虚接口的IPv6地址 | VSI关联的VSI虚接口的IPv6地址 |
| VSI虚接口物理状态 | VSI关联的VSI虚接口物理状态 |
| VSI虚接口协议状态 | VSI关联的VSI虚接口协议状态 |
| M-LAG接口下配置 | 一致性检查内容 |
|---|---|
| 接口所属的VLAN | M-LAG接口所属的VLAN先比较接口上携带Tag的VLAN，再比较接口上未携带Tag的VLAN |
| M-LAG接口上的端口速率作为优先选择参考端口功能 | M-LAG接口上的端口速率作为优先选择参考端口功能是否配置 |
| M-LAG接口上的选择选中端口时忽略端口速率功能 | M-LAG接口上的选择选中端口时忽略端口速率功能是否配置 |
| STP根保护功能 | STP根保护功能是否配置 |
| 端口安全模式 | 端口安全模式：· Autolearn· Mac-authentication· Mac-else-userlogin-secure· Mac-else-userlogin-secure-ext· Secure· Userlogin· Userlogin-secure· Userlogin-secure-ext· Userlogin-secure-or-mac· Userlogin-secure-or-mac-ext· Userlogin-withoui |
| 802.1x指定的Critical VSI名称 | 802.1x指定的Critical VSI名称 |
| 802.1x的在线用户握手功能 | 802.1x的在线用户握手功能是否开启 |
| 802.1x的组播触发功能 | 802.1x的组播触发功能是否开启 |
| 802.1x的单播触发功能 | 802.1x的单播触发功能是否开启 |
| MAC地址认证的Critical微分段ID | MAC地址认证的Critical微分段ID |
| MAC地址认证的Critical VSI名称 | MAC地址认证的Critical VSI名称 |
| 在添加第一个Critical微分段用户时，强制当前端口下授权了重定向URL的MAC地址认证的所有用户均下线功能 | 是否开启，在添加第一个Critical微分段用户时，强制当前端口下授权了重定向URL的MAC地址认证的所有用户均下线 |
| 端口MAC地址认证和802.1x认证并行处理功能 | 端口MAC地址认证和802.1x认证并行处理功能是否开启 |
| Web认证的Auth-Fail VLAN | Web认证的Auth-Fail VLAN |
一类检查
| 视图 | 检查内容 |
|---|---|
| 全局下 | STP功能是否使能 |
| STP工作模式配置 | |
| BPDU保护功能是否使能 | |
| STP多生成树实例与VLAN 的映射关系配置 说明： 设备默认仅检查ID为0的STP进程内多生成树实例与 VLAN的映射关系。 | |
| 接口下 | STP功能是否使能 |
| STP端口的Root保护功能 | |
| 是否使能 M-LAG成员接口的LACP模式配置 |
二类检查
| 视图 | 检查内容 |
|---|---|
| 全局下 | VLAN配置 |
| 静态MAC地址表项 ● 静态MAC地址表项指定 接口为M-LAG成员口 ● VXLAN隧道的静态 MAC地址表项 | |
| 动态MAC的老化时间 | |
| 静态ARP表项 | |
| 动态ARP的老化时间 | |
| VXLAN中的VBDIF相关配置，类似华三的VSI，包括VSI ID、VSI虚接口ipv4、v6地址、mac地址等 | |
| VLAN虚接口相关配置，类似华三 | |
| M-LAG接口下 | STP端口优先级配置 |
| 接口加入VLAN配置 | |
| M-LAG成员口参数配置 | |
| M-LAG成员口所属EthTrunk接口成员口个数 说明：仅比较Eth-Trunk接口的成员口数量，对于成员口物理状态Up/Down或者成员口带宽 不予检查。 |
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
表项建立：
Device C发送的IGMP/MLD查询报文，通过Device C的聚合口进行负载分担，分别到达Device A和Device B的M-LAG接口。
Device A和Device B分别将各自的M-LAG接口添加到路由器端口列表中，并通过peer-link链路互相发送给对端设备。Device A和Device B从peer-link接口收到的对端发送的查询报文，不会再向各自的M-LAG接口转发。
Device A收到来自下游接收者的IGMP/MLD Report报文后，从Report报文中解析出主机要加入的组播组地址G，生成二层组播转发表项（*，G），将接收端口作为成员端口添加到出端口列表。同时，将IGMP/MLD Report报文通过peer-link链路发送给Device B。
Device B收到Report报文后，同样生成二层组播转发表项（*，G），同时将peer-link接口作为成员端口添加到出端口列表中。但是，Device B并不会将该报文从自己的路由器端口（M-LAG接口）转发出去。
数据转发：
组播源发送的组播流量，通过负载分担方式到达Device A和Device B。
Device A和Device B，通过peer-link链路互相发送各自接收到的组播数据流量给对方。这样，保证Device A和Device B上都能收到完整的组播数据流量。
Device A将完整的组播数据流量发送给下游接收者。
组播接收者接入M-LAG
表项建立：
Device A收到上游二层网络发送的IGMP/MLD查询报文后，将接收报文的端口添加到动态路由器端口列表中，并通过peer-link链路发送给Device B。
Device B收到查询报文后，将peer-link接口添加到路由器端口列表中。
Device A或者Device B中的任意一台设备，收到下游设备Device C发送的IGMP/MLD Report报文后，从Report报文中解析出主机要加入的组播组地址G1和G2，分别在各自设备上生成二层组播转发表项（，G1）和（，G2），出端口分别为各自的M-LAG接口。
假设Device A收到的为加入组播组G1的Report报文，Device B收到的为加入组播组G2的Report报文。
Device A和Device B分别将Report报文通过peer-link链路透传给对端设备。以Device A为例，Device A收到Device B发送的Report报文后，在生成二层组播转发表项（，G2），同时将Device A上的M-LAG接口添加到出端口列表中。Device B的处理过程类似，将在本地生成（，G1）的二层组播转发表项。
数据转发：
组播源发送的组播流量，通过二层网络到达Device A。
Device A通过peer-link链路将收到的组播数据流量发送给Device B。此时，只有Device A会向下游Device C转发组播流量，而Device B上虽然生成了二层组播转发表项，但不会向下游Device C转发组播流量。
Device C收到后，将流量转发给接收者。
三层组播流量
组播源接入M-LAG
表项建立：
Device A收到PIM/IPv6 PIM加入报文后，不会将报文通过peer-link链路同步给Device B，而是在获取了组播组的接收者信息后，生成了（*，G）表项。
组播源发送给接收者的组播数据报文，会通过负载分担的方式分别到达Device A和Device B的M-LAG接口。Device A和Device B会通过peer-link链路将各自接收到的报文发送给对端，从而使两台设备上都能收到完整的组播流量。Device A上根据收到的组播数据流量建立（S，G）表项。
流量转发：
组播源发送的组播流量，通过负载分担方式到达Device A和Device B。
Device A和Device B，通过peer-link链路互相发送接收到的组播数据流量。这样，保证Device A和Device B上都能收到完整的组播数据流量。
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均能收到组播源发送的所有的组播数据流量。
表项建立
Device A或者Device B中的任意一台设备，收到下游设备Device C发送的IGMP/MLD Report报文。Device A或者Device B从Report报文中解析出主机要加入的组播组地址，分别生成（，G1）和（，G2）三层组播转发表项，将M-LAG接口添加到出端口列表中。
Device A和Device B分别将Report报文通过peer-link链路透传给对端设备。以Device A为例，Device A收到Device B发送的Report报文后，在生成三层组播转发表项（，G2），同时将Device A上的M-LAG接口添加到出端口列表中。Device B的处理过程类似，将在本地生成（，G1）的组播转发表项。
Device A和Device B上的组播组信息将保持同步，生成相同的（，G1）和（，G2）组播转发表项。
Device A和Device B根据网络中配置PIM模式工作机制，最终在设备上生成相同的PIM路由表项。此处，以网络配置的PIM模式为PIM-SM示例。
流量转发
组播源发送的组播流量，通过三层网络分别到达Device A和Device B。
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报文的同步过程
- SW3发送ARP报文请求10.1.1.254的mac地址，在聚合口上，报文hash后，发送给了S2
- S2收到该广播请求报文，由于从设备上不存在虚拟ip，因此不会应答，会将该报文继续泛洪到相关vlan口，如peerlink口，同时，由于是从M-LAG接口上收到的ARP报文，因此会将该报文封装到Rlink报文，发送给对端M-LAG设备
- S1在peerlink链路上会收到两个ARP报文，一个是泛洪过来的普通ARP，另一个是在Rlink报文中的ARP报文，其中，对于Rlink发送过来的ARP报文，由于打上了Rlink标记，不会对该请求报文进行应答。同时，对于Rlink发送过来的ARP报文，会将其学习到M-LAG接口下，覆盖了学习到peerlink的表项，因此应答该报文时，会从M-LAG接口发送给SW3。
- 最终，在各设备上查看ARP表，结果如下：
- SW3具有arp表项后，封装icmp报文，在聚合口上发送时hash到了SW2链路上，此时SW2查看目的mac为自己（虚拟ip对应的虚拟mac），进行三层转发，查路由表和ARP表后通过peerlink发送给SW1，SW1直接发送回SW3，不通过peerlink链路。
为探究多种情况，此时切换一下VRPP的主备状态，拓扑如下
同样地，使用SW3 ping 10.1.1.254，查看ARP学习过程
- 情况一样，SW3发送的ARP请求报文hash，发给了SW2，SW2作为虚拟ip的拥有者，直接回应ARP报文给SW3
- 同时，尽管SW2回复了ARP报文，但仍会继续泛洪该ARP请求广播报文，通过peerlink发送给SW1，并且由于时从M-LAG接口收到的ARP报文，会复制一份进Rlink，发送给SW1，因此SW1会收到两份ARP请求报文，在Rlink收到ARP报文，会将其学习到M-LAG接口下，由于自己并不具有虚拟ip，因此并不会应答。并且由于单向隔离，因此不会将该广播报文继续泛洪回SW3
- 最终三台设备的ARP表项情况和第一种场景一致
- SW3拥有10.1.1.254的mac地址后，封装icmp报文，hash到了SW2链路上，SW2作为ip拥有者，直接应答icmp报文给SW3
单挂场景
以SW4 ping SW3为例，分析ARP报文同步过程
- SW4发送ARP广播报文请求SW3的mac地址
- SW2收到该报文后，按照正常的ARP报文进行泛洪，发送给SW1和SW3，但不学习该ARP，因为并不是在M-LAG接口上接收到请求报文(尽管SW2上有对应的虚接口)。
- SW1收到该ARP报文后，由于单向隔离，因此ARP报文在该设备终结了，同时将该ARP（10.1.1.2）学习到peerlink接口上
- SW3收到该请求报文，由于自己拥有请求的ip地址，因此会进行arp应答，发送给SW4
- 至此，各设备的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设备转发，具体过程如下：
- Device B的某M-LAG接口故障，外网侧不感知，流量依然会发送给所有M-LAG设备。
- Device A的相同M-LAG接口正常，则Device B收到外网侧访问Device C的流量后，通过peer-link链路将流量交给Device A后转发给Device C。
- 故障恢复后，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状态。
mad-down不仅将物理接口mad down，还会将vlan接口mad-down。125-G-AF将vlan接口配置为系统保留接口，125X-AF则不会配置为系统保留接口。 当peerlink恢复，进入延迟恢复倒计时，若在此时，提前把物理接口手动打开，此时vlan接口仍是down的，因此业务转发将不通。
Keepalive链路up，IPP口变为down时，会导致从设备上DRNI保留接口和IRF保留接口以外的物理接口处于DRNI MAD DOWN状态。如果Keepalive链路的接口未配置为保留接口，该接口的状态将变为DRNI MAD DOWN，导致Keepalive链路down，造成错误检测，认为邻居不存在，所以Keepalive链路的接口需要配置为保留接口。（部分型号以及部分版本默认配置为系统保留接口）
设备故障
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链路故障时，无法同步表项，可能导致流量转发错误。
peer-link链路链路先发生故障业务影响说明 1、perin链路链路先发生故障，从设备被MAD Down，物理端口都被Down掉，此时vlan虚接口虽然配置保留接口了，但是没有up的物理接口，vlan虚接口也会出现down，对应的表项会消失； 2、keepalive链路再down的时候，设备变为主设备，接口UP，此时两台设备双主运行； 3、双主情况下，对于C设备是没有感知的，两台M-LAG设备还是使用M-LAG的系统参数发送lacp报文，C设备的聚合成员接口正常选中； 4、但是从设备没有同步的表项，C设备又不感知双主，流量发到从设备的话会出现转发不通
若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系统应该分开来看，因此单挂接入时，应该是各自计算。 因此，有以下几个定义(概念)
- 整个M-LAG系统是一个STP桥，STP桥ID中的桥MAC使用系统MAC
- 当M-LAG设备非根设备时，整个M-LAG系统具有唯一 一个根端口
- peer-link接口端口关闭拓扑协议
- 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独自计算了设备的生成树角色，且没有同步给对端设备。
原因：主备根各自发送以自己为根桥的BPDU报文，SW2收到后将1口选举为根端口，PA协商后进入转发状态，2口继续发送以SW1为根的BPDU报文，备根收到后，发现其中的桥mac与自己相同，因此不进行处理，继续认为自己是根桥，经过Forwarding delay后，备根的31口进入forwarding状态，此时SW3收到了处于Forwarding或Learning状态的指定端口发送的低优先级的BPDU报文，触发了dispute。单边接入
缺省情况下，不允许M-LAG接口单边接入，即仅一台M-LAG设备配置M-LAG接口。M-LAG接口单边接入时，将该M-LAG接口置为M-LAG DOWN状态。
当存在单归接入设备时，如果需要使用M-LAG接口转发流量，则需要配置允许M-LAG接口单边接入，不将该M-LAG接口置为M-LAG DOWN状态，保证流量正常转发。当允许M-LAG接口单边接入时，不对该M-LAG接口进行一致性检查。
interface bridge-aggregation interface-number port m-lag group group-id [ allow-single-member ]
12500X-AF（R28xx版本）做m-lag限制
配置M-LAG时，需要先设置MAC基地址，再根据MAC基地址设置M-LAG系统各MAC地址。其中，桥mac较大的主机需要设置为M-LAG主，但基地址是设置为较小的桥mac。
产品对于每台设备，需要预留96个连续的MAC地址作为系统保留使用。 配置的MAC基地址即保留MAC地址的起始值，用来限定保留MAC地址和三层接口MAC地址的高36位。
桥MAC的查看方式：在Probe视图执行debugging system bridgemac read命令，查看BridgeMac字段。例如，下面设备的桥MAC地址为542b-de0c-0200。
[Sysname-probe] debugging system bridgemac read The Bridge Macs are as follows: 542b-de0c-0200 Total reserved mac number: 256 SNID:23a6-db6c-d829-a93d BridgeMac:542b-de0c-0200 BaseInfMac:542b-de0c-0200 INTFMac:542b-de0c-0201 分布式网关VSI接口MAC高36位要与base-mac一致，低12位没要求。建议分布式网关VSI接口MAC和EVPN的全局MAC地址（evpn global-mac）配置一致。
如果原本是IRF状态，可以使用[probe]debug system bridgemac read chassis 1和
[probe]debug system bridgemac read chassis 2查看两个框的桥mac
此外，对于配置为m-lag接口的动态聚合口，lacp-system-id中的mac段，均为m-lag系统mac（以上图为例，542b-de0c-0200），而非m-lag接口的动态聚合口，lacp-system-id中的mac段，为自己本身桥mac（542b-de0c-0200和7057-bff9-aa00）。
M-LAG升级
步骤
先升级M-LAG系统中的一台设备，待M-LAG状态和业务都正常后，再进行另一台M-LAG设备的升级。两台M-LAG设备的升级顺序对业务的影响结果相同。如果选择先升级从设备，后升级主设备，升级完成后，设备的主备角色和升级前不同（这个后面梳理）
以先升级M-LAG-A为例
- 断开与控制器连接（如果有控制器），两台设备均需要断开
- 升级M-LAG-A，指定升级文件（bootloader）
- 隔离M-LAG-A设备。按照如下顺序关闭设备上的物理端口。只需要关闭物理端口，不需要关闭聚合接口、VLAN接口、Tunnel接口、VSI接口等逻辑接口。
- （1）关闭所有业务端口，先关闭下行端口，再关闭上行端口；
- （2）关闭keepalive链路物理端口；
- （3）关闭peer-link链路物理端口。
- 在待升级设备较多，业务中断时间不特别敏感的场景也可以使用接口批量配置方式（interface range）批量关闭所有物理接口或直接将设备下电。
- 重启M-LAG-A
- 验证设备是否升级成功
- 恢复M-LAG-A设备的物理连接
- （1）开启peer-link链路物理端口；
- （2）开启keepalive链路物理端口；
- （3）开启所有业务端口，先开启上行端口，再开启下行端口。
- 开启peer-link链路物理端口，M-LAG系统重新形成后，业务端口经过m-lag restore-delay（单位为秒）命令配置的延迟恢复时间之后才能UP。建议经过延迟恢复时间之后再进行开启端口的操作。
- 检查业务是否正常
接着升级M-LAG-B，步骤和M-LAG-A一样，不再赘述。
疑问
如果选择先升级从设备，后升级主设备，升级完成后，设备的主备角色和升级前不同 分析原因： 来看M-LAG的主从协商规则：
- 比较设备所有M-LAG接口的状态，有可工作M-LAG接口的一端为优；
- 比较计算前角色，若有一端为Primary，另一端为None，则Primary端优；
- 比较M-LAG MAD DOWN状态，若一端存在处于M-LAG MAD DOWN状态的接口，另一端不存在处于M-LAG MAD DOWN状态的接口，则不存在处于M-LAG MAD DOWN状态的接口的一端优；
- 比较设备健康状况，健康值越小越优。设备的健康值可通过display system health命令查看，健康值越小设备越健康，设备无故障运行时，健康值为0。有关display system health命令的详细介绍，请参见“基础配置命令参考”中的“设备管理”；
- 比较设备角色优先级，越高越优；
- 比较设备桥MAC，越小越优。
- 如果设备通过peer-link链路计算角色，则不比较设备所有M-LAG接口的状态。
再来看看keepalive机制中的描述，重点看加粗字体 M-LAG设备间通过Keepalive链路检测邻居状态，即通过交互Keepalive报文来进行peer-link链路故障时的双主检测。Keepalive报文为H3C私有报文。
如果在指定时间内，本端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升级过程中，如果M-LAG-A为原来的备机，重启完成后，由于此时A上的物理口为down状态（重启前手工shutdown），导致M-LAG接口为down，因此此时设备的角色为none；而此时B正在承载业务，设备角色为primary。A打开peerlink和keepalive后，使用peerlink链路计算角色，上述的第一条规则不适用，但第二条满足，因此A协商为secondary。同理，在重启升级完第二台M-LAG-B后，加入M-LAG系统时，协商为secondary，导致升级后和升级前的主备角色切换。
参考文章
https://e.huawei.com/cn/material/networking/dcswitch/b5cc12697eed491d8c1b1abf0b4b327a