为什么会出现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协议状态信息。