目录
为什么会出现M-LAG
M-LAG基本概念
M-LAG建立过程
M-LAG的协议兼容性
M-LAG的防环机制
M-LAG正常工作流量转发
单播流量转发
组播流量转发
广播流量转发
M-LAG故障场景流量转发
上行链路故障
下行链路故障
M-LAG主设备故障
Peer-link故障
M-LAG二次故障（Peer-Link故障+M-LAG设备故障）
V-STP
V-STP方式（推荐方式）
根桥方式
M-LAG技术的应用
M-LAG（Muntichassis Link Aggregation Group）跨设备链路聚合组，将不同设备上的不同端口组成一个聚合组，达到跟普通LAG一样的功能，主要应用场景是“双归接入”场景，即用户侧双归接入到两台设备上
对于下游设备来说，认为上游设备是一台设备
为什么会出现M-LAG
实现双归接入的传统技术有：堆叠、Smart-Link等技术
堆叠的多台设备使用同一个控制面，单点故障可能影响到整个系统
Smart-Link等技术使用的是主备方式接入，链路利用率不搞
M-LAG和堆叠的区别
堆叠是设备级别的多虚一，管理平面共用一个
MC-LAG协议级别的多虚一，管理平面是独立的
什么是协议级别的多虚一
即仅仅是在LACP这个协议上，将多个设备的接口认为是一台设备的接口，只有LACP协议这样认为，除此之外，这两台设备都是独立工作的
M-LAG基本概念
DFS-Group（Dynamic Fabric Service Group）动态交换服务组
通过DFS-Group对部署了M-LAG的设备进行配对，实现多台设备间的链路聚合
动态交换服务组的ID只能为1，绑定M-LAG的ID可以是1~2048
主备设备之间要确保M-LAG的ID是一致的
M-LAG双归设备之间的接口状态、表项等信息的同步需要依赖DFS Group协议进行同步
DFS 主/备设备
部署了M-LAG 并且状态为主/备的设备（也称为M-LAG主/备设备）
通过DFS Group协议协商
此处的主备交换机都会转发数据
正常情况下，主/备设备转发行为没有区别，其主备接口都可以进行负载分担转发
仅在故障场景下，主备设备的行为会有差别
双主检测链路（心跳链路-Keepalive链路）
是一条三层互通链路，用于在M-LAG主备设备之间发送双主检测报文
正常情况下双主检测链路不会参与M-LAG的任何转发行为
只有在故障发生的情况下用于检查是否出现双主的情况
链路配置的两种方式
- 可以单独配置配置一条三层链路
- 也可以通过现有IP网络互通，互通的链路就作为双主检测链路
HB DFS主/备设备
通过心跳链路报文协商的状态为主/备的设备（在心跳口上发送DFS报文进行主备协商）
正常情况下，对M-LAG的转发行为不会产生影响，仅用于二次故障场景
Peer-link链路
Peer-link链路是部署MC-LAG的两台设备之间必须存在的一条直连二层链路
此链路必须做链路聚合，此链路用于协商报文以及传输部分流量
Peer-link接口
peer-link链路两端直连的接口均为peer-link接口（Peer-Link接口默认放行所有Vlan）
接口配置为peer-link接口后，该接口上不能再配置其它业务。
Peer-Link接口ID只能为1
M-LAG成员口：
DFS主/备设备上连接用户侧的Eth-Trunk接口
M-LAG成员接口也分主备（接口的主备主要在组播场景下的转发行为有区别）
用户侧Switch
可以是交换机，也可以是主机
使用ETH-trunk（标准的LACP协议）接入双活系统，组成双归接入
M-LAG主/备设备同时转发用户侧流量
双活网关
在DFS主备设备上配置网关，作为用户侧的网关
主备设备上的网关配置相同的IP地址和MAC地址，实现双活网关
此双活网关也可以通过VRRP来实现
VRRP用来选举主备，此时需要双网关，为什么还要做VRRP
因为Peer-link默认拒绝放行VRRP的报文
并且对于设备来说，M-LAG的成员接口是一个逻辑接口，从本接口收到的VRRP报文不会再发送出去，即成员口不会将收到的VRRP报文在转发出去
此时主备都互相收不到对方的VRRP报文，不会进行VRRP主备协商
当将DFS主备交换机的VRRP的虚拟地址配置为一样时，由于主备之间不会选举主从
即两个都是主，也可以达到双活网关的效果
最早是通过VRRP来做双活的，但是现在更推荐配置相同IP、MAC的方式来实现双活网关的效果
M-LAG建立过程
4步建立M-LAG+1步双主检测
DFS Group Hello报文（设备信息报文）
携带自己的DFS Group ID、协议版本号、系统MAC等信息
DFS Group ID相同的设备配对成功
DFS Group设备信息报文
携带DFS Group优先级（优先级默认为100）、系统MAC等信息
确定DFS主、备设备
M-LAG设备信息报文
携带了M-LAG成员接口的配置信息
确定M-LAG成员接口的主备状态
M-LAG同步报文
同步的信息包括设备名、系统MAC、软件版本、M-LAG成员端口状态、STP BPDU信息、MAC表项、ARP表项、IGMP表项等
保证任意一台设备故障都不影响流量的转发，保证正常的业务不中断
注意事项
同步的MAC地址表和ARP表等其它表项时不是直接将表项同步过去，而是将生成表项的报文传递给对端（将生成表项的源报文封装在M-LAG的同步报文中传递给对方，对方根据源报文生成表项）
例如：
主/备设备通过端口收到的ARP生成表项后，将此ARP报文封装在DFS-Group同步报文通过Peer-link链路传递给备/主设备
备/主设备解封装DFSS-Group同步报文，得到ARP报文信息，根据此ARP报文信息再生成表项
此做法更容易实现版本之间的兼容性（即传递的是因）
双主检测
正常情况1s发送一次DAD报文进行检测
一旦感知故障100ms发送3次DAD报文进行检测（加速检测）
除了DAD报文，其余报文都在二层的Peer-Link链路上传输
M-LAG的协议兼容性
前提须知
M-LAG协议报文携带的DATA部分是按照TLV格式封装的，方便扩展
协议不兼容问题
M-LAG升级一般都是逐台升级（保证业务不中断）
在设备进行M-LAG升级过程中必然会出现版本不一致的情况
在设备升级过程中，备用设备升级到了新版，主设备还在旧版
如何解决兼容性问题，使其尽少丢包
解决的工作原理
如图所示，SWA和SWB组成一个M-LAG系统。
版本均为V1R5C10，现在要将两台设备升级为V2R1C00版本。
假设V2R1C00版本新增了一个同步LACP SystemID的功能
在V1R5C10版本，两端设备LACP System ID必须手动配置为一致
而在V2R1C00版本中，主设备会将自己的LACP SystemID封装在同步报文中，备设备收到后，会使用该System ID替换自己的SystemID，防止了手动配置错误的情况发生
那么升级过程如下：
1.SWB换包重启，M-LAG由双归变成单归，SWA独立承担报文转发
2.SWB升级完成后，以V2R1C00版本启动，发送HELLO报文重新配对
由于新增了一个功能，SWB发送的HELLO报文中新增了TLV（这里以新增TLV为例，实际新增功能并不一定会在HELLO报文中新增TLV）
3.SWA收到SWB的报文后，只处理可以识别的TLV，并向SWB发送Hello报文
4.SWB收到SWA发送的HELLO报文后，发现HELLO报文中携带的版本号比自己低
于是不会校验是否有该新增的TLV，两者可以正常协商（新增的TLV功能暂时不生效）
5.协商完成后，SWB开始发送LACP System ID的同步报文，这是一个新增的报文类型
SWA是仍然是老版本，不会处理，直接忽略
6.SWB接收不到SWA发送的同步LACP SystemID的报文，也不会有任何处理。
两设备继续保持手动配置System ID状态，LACP功能也就继续保持以前的工作状态
7.开始升级SWA，同之前类似，双归切换为单归，SWB独立承担报文转发
8.SWA升级完，最终两边版本一致
此时两台设备可以交互LACP System ID的同步报文
此时可以将之前手工配置的System ID删除，全部切换完自动协商形式
M-LAG的防环机制
对于广播流量
对广播泛洪流量进行单向隔离（类似堆叠的单向隔离机制）
单向隔离机制生效的前提
当协商出主备后，通过M-LAG同步报文来判断接入设备是否已经双活接入
如果设备已经双活接入，则M-LAG两台设备下发对应M-LAG成员口的单向隔离配置
如果成员端口已经断了一边，变为单归接入，此时就不用去下发单向隔离配置了
M-LAG同步报文是如何具体判断出接入设备是双活接入的呢？
M-LAG同步报文携带了成员端口状态，通过Peer-Link互发M-LAG报文
当感受到同一个M-LAG的成员口在不同的设备上Up起来了
M-LAG设备就知道这个M-LAG组是双活接入
注意事项
单向隔离机制主备都会隔离（看广播流量从那边上来，从备用上来，主就会隔离，从主上来，备就会隔离）
上图是广播流量从主设备上来，备设备被单向隔离了
单向隔离机制实现原理
检测到双活接入后，会下发全局ACL配置（配置如下）
允许通过 源端口为Peer-link接口，目的端口为M-LAG成员口的三层单播报文
拒绝通过 源端口为Peer-link接口，目的端口为M-LAG成员口的所有报文
即：通过匹配ACL规则，隔离由Peer-Link接口发往M-LAG成员口的广播等泛洪流量
当检测到为单归时，会撤销ACL全局配置
M-LAG正常工作流量转发
单播流量转发
自用户侧发往网络侧的已知单播流量由M-LAG主备设备形成逐流负载分担，共同进行流量的转发；自网络侧发往用户侧的已知单播流量同样由M-LAG主备设备形成逐流负载分担，共同进行流量的转发。
在用户侧通过Eth-Trunk负载分担算法将流量分到DFS主、备设备，实现负载分担
组播流量转发
组播接入二层网络——通过单向隔离机制来防止接收重复的组播流量
接入二层网络故障，单向隔离机制就会取消掉
组播接入三层网络——通过PIM协议来获取组播流量
三层网络中，对于组播接收者，要保证组播接收者只能收到一份组播流量（同组播源、组播组的流量只能是一份）
如何解决组播组成员收到重复流量的问题
按照以下规则由M-LAG主备设备在本地查找组播表后将流量负载分担给组播组成员
若组播组地址最后一位为奇数（例如225.1.1.1或FF1E::B），则由M-LAG成员端口状态为主的设备转发至组播组成员
若组播组地址最后一位为偶数（例如225.1.1.2或FF1E::A），则由M-LAG成员端口状态为备的设备转发至组播组成员
注意事项：
M-LAG主备设备不会发送剪枝报文，对于组播流量主备设备都收的到，只是转发给组成员是会进行筛选
一般主设备的成员端口状态也为主，但是不一定一直为主（正常情况下是主，发生障后就不一定为主了）
组播三层组网中，当上行链路故障，一部分组播成员收不到组播流量，如何解决
通过在主备之间加入三层链路，运行PIM，可以避免单上行
独立三层PIM链路的其它作用
当DFS主设备（端口状态为主）上行链路故障后，当下发奇数组播流量时，DFS主设备是收不到的
DFS备设备收到了此奇数组播流量，但是由于其端口状态为备，不转发奇数组播流量
此时就需要通过PIM独立三层口将奇数组播流量转发给DFS主，然后再由其下发给组播组成员
所以对于组播三层网络，建议加上独立的三层PIM链路，增强其可靠性
广播流量转发
网络上的的广播流量，单向隔离
M-LAG故障场景流量转发
M-LAG作为一种跨设备链路聚合的技术，把链路可靠性从单板级提高到了设备级。如果出现故障（不管是链路故障、设备故障还是peer-link故障），M-LAG都能够保证正常的业务不受影响
上行链路故障
若主/备上行链路故障，不会影响双主检测（双主检测还是1s一次）
主备设备能够正常转发数据
只不过下游通过主/备设备的流量均经过Peer-Link链路进行转发
下行链路故障
M-LAG主备状态不会发生变化，不会引发双主检测，但是成员端口状态可能会发生变化
如果M-LAG成员端口状态为主的链路出现故障
发生故障的M-LAG成员口所在的链路状态变为Down，双归场景变为单归场景
故障M-LAG成员口的MAC地址指向peer-link接口（将成员端口的MAC表项复制到Peer-Link口），将流量通过Peer-Link引到M-LAG备用设备
成员端口状态为备端口其状态转为主，流量切换到该链路上进行转发
对于组播源在网络侧，组播成员在接入侧的组播流量
当M-LAG主设备的M-LAG成员口故障时
通过M-LAG同步报文通知对端设备进行组播表项刷新
M-LAG主备设备不再按照组播地址奇偶进行负载分担
而是所有组播流量都由端口状态Up的M-LAG备设备进行转发，反之亦然
在故障M-LAG成员口恢复后
M-LAG成员口状态不再回切
由备升主的M-LAG成员口状态仍为主
原主M-LAG成员口在故障恢复后状态为备
M-LAG主设备故障
如果是M-LAG主设备故障
M-LAG主设备侧Eth-Trunk链路状态变为Down，M-LAG的主备状态会发生变化
M-LAG备设备将升级为主，其设备侧Eth-Trunk链路状态仍为Up，流量转发状态不变，继续转发流量，双归场景变为单归场景。
如果是M-LAG备设备发生故障
M-LAG备设备侧Eth-Trunk链路状态变为Down，M-LAG的主备状态不会发生变化
M-LAG主设备侧Eth-Trunk链路状态仍为Up，流量转发状态不变，继续转发流量，双归场景变为单归场景。
当M-LAG设备故障恢复时
peer-link先UP，DFS状态重新协商，M-LAG成员口恢复UP，流量恢复负载分担
M-LAG主设备恢复后设备状态仍然为主，M-LAG备设备恢复后设备状态仍然为备。
Peer-link故障
peer-link故障会引发双主现象
双归设备一旦感知peer-link口down，即立刻发起一次双主检测过程（100ms发3次DAD）
M-LAG应用在普通以太网络、VXLAN网络或IP网络的双归接入
peer-link故障但双主检测心跳状态正常时
会触发M-LAG备设备上除逻辑端口、管理网口、peer-link接口和堆叠口以外的其他接口处于Error-Down状态。
M-LAG应用在TRILL网络的双归接入
peer-link故障但双主检测心跳状态正常时，会触发M-LAG备设备上的M-LAG接口处于Error-Down状态。
Peer-Link故障恢复时
处于Error Down状态的其它接口将立即自动恢复为Up状态。
处于Error Down状态的M-LAG接口默认将在240s后自动恢复为Up状态
M-LAG二次故障（Peer-Link故障+M-LAG设备故障）
当Peer-link链路故障后，如果M-LAG备设备再次发生故障，此时不会对流量转发行为产生影响，仍由DFS状态为主的设备进行流量转发。
当Peer-link链路故障后，如果M-LAG主设备再次发生故障，将导致系统无法转发流量
此时需要通过二次故障增强功能来解决
若M-LAG已使能二次故障增强功能
则DFS状态为备的设备会借助M-LAG双主检测机制感知到DFS主设备故障（在一定周期内接收不到任何的M-LAG双主检测心跳报文会认为主故障）
此时DFS备设备将升级为DFS主设备并恢复设备上处于ERROR DOWN状态的端口为Up状态，继续转发流量。
若原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两台设备双主的情况，可能导致流量异常。
此时，可以借助心跳链路报文中携带必要的DFS Group协商主备的必要信息（如DFS Group优先级、系统MAC等）来协商M-LAG两台设备的HB DFS主备信息
触发HB DFS状态为备的设备上某些端口处于ERROR DOWN状态，HB DFS状态为主的设备继续工作。
V-STP
V-STP方式（推荐方式）
V-STP（Virtua Spannning Tree Protocol）是二层拓扑管理特性，可以将两台设备的STP虚拟成一台设备的STP协议，对外呈现为一台设备进行STP协议计算
为什么要使用V-STP
需要给下游交换机营造出是一台设备的感觉，如果DFS主备设备都发各自的BPDU
下游交换机就会从一个逻辑接口上收到两份不同的BPDU，会认为自己连接了两台设备
正常情况下，一个物理接口收到的BPDU就是上游设备的那一个BPDU
V-STP具体实现原理
M-LAG主备设备配置了V-STP使能之后，在M-LAG主备协商成功后
STP同步M-LAG主备的桥MAC信息和实例优先级信息
M-LAG备设备使用M-LAG主设备同步过来的桥MAC信息和实例优先级信息进行STP计算和收发报文，保证虚拟化成一台设备后的STP计算参数。
主要应用场景
V-STP只能用于M-LAG组网
可以解决多级M-LAG互联场景和组成M-LAG的设备作为非根桥场景的需求。
注意事项
配置V-STP功能时，需要保证组成M-LAG的两台设备上STP/RSTP定时器配置一致
否则可能导致网络拓扑震荡。
根桥方式
通过配置根桥（V-STP出现之前使用此种方式）的方式也可以实现V-STP的功能
根桥方式如何具体实现
M-LAG主设备和备设备均作为STP网络中的根桥且配置相同的桥ID
将两台设备模拟成同一个根桥，M-LAG主备设备在二层网络中不受其他组网变化的影响，保证正常的工作（保证了主备交换机的端口不被阻塞）
注意事项
如果M-LAG设备是在接入层的，我们一般不会把接入层设备设置为根桥
如果上层网络是纯三层网络，此时把主备交换机是否设置为根桥意义也不大
以上两种情况我们会使用V-STP方式，现网中也是推荐使用V-STP方式
例如：现在Vxlan追求的是纯三层网络，使用V-STP效果更好
M-LAG技术的应用
N-LAG双归接入二层网络
M-LAG双归接入Vxlan网络
在DFS主备设备上配置Vxlan隧道（通过Eth-Trunk子接口配置）
多级M-LAG
在网络规模较大场景下， 可以通过配置多级M-LAG来保证链路可靠性
多级M-LAG应用场景，不能使用手动配置根桥的方式来进行STP破环，需要通过VSTP协议来同步M-LAG双归设备的STP协议状态信息。
