华为M-LAG实战解析：从双活组网到故障切换的深度指南

1. 为什么企业网络需要M-LAG从“主备”到“双活”的进化大家好我是老张在数据中心和企业网里摸爬滚打了十几年。今天想和大家深入聊聊华为的M-LAG技术。很多刚接触这个技术的朋友可能会问我们已经有堆叠、有VRRP、有各种链路捆绑技术了为什么还需要M-LAG这得从我们实际运维中最头疼的问题说起高可用和链路利用率。想象一下这样一个经典场景你的核心业务服务器需要高可靠地上联到网络。传统做法是服务器用两根网线一根接到核心交换机A一根接到核心交换机B。然后配置个Smart Link或者VRRP让A是主用B是备用。平时所有流量都走AB那根线就在那儿闲着“看戏”只有A挂了流量才切到B。这确实解决了设备级故障的问题但宝贵的链路带宽被白白浪费了50%心里总不是个滋味。而且主备切换那一下业务难免会抖一抖对于一些要求苛刻的业务这短暂的抖动可能就是一次事故。堆叠技术呢它把两台或多台设备虚拟成一台逻辑上简单了服务器可以做一个跨物理机的链路聚合实现负载分担和故障无缝切换。但堆叠是“一荣俱荣一损俱损”。它共享控制平面一旦主控板故障或者堆叠分裂很可能导致整个逻辑设备瘫痪风险比较集中。M-LAG就是为了解决这些痛点而生的。它的核心思想是“求同存异”。对于下游设备比如服务器或接入交换机来说它通过标准的LACP协议把分别连接到两台独立设备上的物理链路“骗”成是连接到同一台设备的一个逻辑聚合组。这样下游设备可以心安理得地进行负载分担两条链路都跑流量利用率上去了。而对于上游这两台设备来说它们依然是两台独立控制的设备各有各的大脑控制平面互不影响。一台设备重启升级流量可以无缝切换到另一台业务零中断。这种“协议级别的多虚一”正是M-LAG的精妙之处。所以M-LAG最适合的场景就是“双归接入”。无论是服务器双上联还是接入交换机双上联到核心它都能在提供设备级冗余保护的同时实现链路的负载分担把钱花在刀刃上。接下来我们就拆开看看这套系统是怎么搭建和工作的。2. 深入M-LAG核心组件不只是两条线那么简单要玩转M-LAG你得先理解它的几个关键“角色”。这不像配个简单的端口聚合它是一套小系统每个部分都有其不可替代的作用。配置时漏掉任何一个都可能埋下大坑。2.1 DFS-Group设备的“结婚证”DFS-Group全称动态交换服务组你可以把它理解为两台设备组成M-LAG关系的“结婚证”或者“配对协议”。没有这个Group两台设备就是陌路人谈不上协同工作。配置时你需要给这对设备指定一个相同的DFS Group ID。这里有个关键点这个ID在单对M-LAG设备中固定为1。是的你没看错通常就是配成1。那如果有第二对M-LAG设备呢另一对也用1吗这里容易混淆。实际上M-LAG的配对是基于DFS Group ID 系统MAC来唯一标识的。即使两对设备DFS Group ID都配1但只要它们的系统MAC不同就是不同的、互不干扰的M-LAG系统。所以一般情况下你每对设备都配dfs-group 1就行系统会自动用各自的MAC来区分。在DFS-Group内部两台设备会协商出一个主和一个备。这个主备选举基于两个因素优先级默认100数值越大越优先和系统MAC地址越小越优先。这里务必理解这个主备角色在正常转发时没有任何区别主设备不会多转发流量备设备也不会少干活。它们都同时、平等地转发数据。这个主备角色主要是为了在控制层面有一个决策者比如处理某些协议报文、管理状态同步等以及在某些特定故障场景下比如后面要讲的Peer-Link故障决定谁“活”下来继续服务。2.2 Peer-Link系统的“生命线”Peer-Link是M-LAG的“大动脉”是两台设备之间必须直连的一条二层链路。我强烈建议你用多条链路做一个Eth-Trunk来作为Peer-Link因为它的可靠性直接决定了整个M-LAG系统的健壮性。这条链路承担着至关重要的使命协议报文通道DFS-Group的Hello报文、心跳报文、同步报文都靠它传递。表项同步通道MAC地址表、ARP表等关键转发信息通过它实时同步确保任何一台设备故障另一台能立刻接盘。故障时的流量迂回通道当一台设备的上行链路故障时去往该设备的流量需要先通过对端设备再通过Peer-Link“绕”过来。配置Peer-Link接口时系统会自动将其加入所有VLAN默认放通以便传输所有需要的同步数据。记住一个铁律Peer-Link接口上不能再配置任何其他业务它就专职干同步和迂回这件事。2.3 双主检测链路心跳链路防止“脑裂”的保险丝这是M-LAG里一个非常巧妙且必要的设计。想象一下如果Peer-Link这条“生命线”断了两台设备无法通信但它们各自的下行链路都还通着会发生什么下游设备会觉得它还是连着一台“逻辑设备”继续向两边发送流量。而两台独立的设备都认为自己应该工作这就形成了“双主”或“脑裂”可能导致广播风暴、重复帧等严重问题。双主检测链路就是为了防止这种情况。它是一条三层IP可达的链路。注意它和Peer-Link有本质区别Peer-Link是二层直连而心跳链路可以走三层网络甚至可以绕很远只要IP能通就行。它的作用很单纯定期发送DAD双主检测报文。当Peer-Link故障时两台设备会立刻通过这条心跳链路疯狂互发DAD报文比如100ms内发3次询问对方“你还活着吗Peer-Link断了咱俩现在谁做主”如果通过心跳链路还能协商出主备那么备设备就会主动把自己除了管理口、Peer-Link口之外的所有业务端口或M-LAG成员口置为Error-Down状态从而避免双主。这根“保险丝”在关键时刻能保住整个网络不瘫痪。2.4 M-LAG成员口与双活网关M-LAG成员口就是两台设备上那些连接下游服务器的Eth-Trunk接口。它们配置了相同的M-LAG ID范围1-2048下游设备用标准LACP协议和这个聚合组协商。双活网关是另一个亮点。传统VRRP是“一主一备”网关流量只走主设备。在M-LAG组网里我们可以在两台设备上为同一个VLAN配置完全相同的IP和MAC地址作为网关。因为Peer-Link默认隔离VRRP报文且M-LAG成员口逻辑上属于同一个“设备”所以两台设备不会进行VRRP选举都认为自己是“主”。这样服务器发出的ARP请求两台设备都会回应这个相同的网关MAC流量就可以负载分担到两个网关上实现了真正的网关层面“双活”。3. M-LAG是如何建立并工作的一步步拆解了解了组件我们看看它们是如何协同工作让两台设备“伪装”成一台的。这个过程就像一场精密的舞蹈。3.1 四步握手建立M-LAG假设我们有设备A和设备B已经按要求连好了Peer-Link和心跳链路。第一步配对发现。设备A和设备B通过Peer-Link周期性地发送DFS Group Hello报文。这个报文里带着自己的DFS Group ID、系统MAC等信息。当A收到B的Hello报文发现里面的DFS Group ID和自己配置的一样比如都是1就会想“哦找到组织了你就是我要配对的那台设备。”配对成功。第二步选举老大。配对成功后它们开始交换DFS Group设备信息报文里面包含了优先级和系统MAC。按照我们前面说的规则先比优先级再比MAC选出一台作为DFS主设备另一台作为DFS备设备。再次强调这个“主”在正常转发时没特权。第三步接口角色分配。两台设备继续通过M-LAG设备信息报文协商每个M-LAG成员接口的“主备”状态。这个接口的主备状态主要影响组播流量的转发对单播和广播无影响。通常主设备上的成员口状态为主备设备上的为备。第四步心跳保活与表项同步。M-LAG系统开始正常工作后两台设备会通过Peer-Link周期性地发送M-LAG心跳报文也是DAD报文的一种用于Peer-Link正常时的保活。同时更为关键的是它们会通过M-LAG同步报文实时同步MAC表、ARP表、IGMP表等。这里有个细节很关键同步的不是加工后的“表项”而是生成这些表项的原始报文。比如设备A从成员口收到了一个ARP请求它除了自己学习ARP表项还会把这个ARP请求报文原封不动地封装在同步报文里通过Peer-Link发给设备B。设备B解封装后就像自己从那个接口收到一样也生成一份相同的ARP表项。这样做兼容性最好即使两台设备软件版本稍有差异也能保证基础转发信息同步。3.2 正常流量如何转发系统建立好后流量就开始快乐地负载分担了。对于单播流量已知目的MAC是最理想的状态。下游设备通过标准的Eth-Trunk负载分担算法如基于源目IP、MAC的哈希将流量分到两条链路上分别到达M-LAG主设备和备设备。两台设备都有完整的MAC/ARP表通过同步获得都能独立进行转发无论是上行的用户流量还是下行的回程流量都实现了完美的负载分担。对于广播和未知单播流量M-LAG有一套聪明的“单向隔离”防环机制。一旦系统通过同步报文感知到下游是“双活”接入即同一个M-LAG ID的两个成员口在两台设备上都Up了它就会在内部自动下发一个ACL规则。这个规则的核心是允许从Peer-Link接口发往M-LAG成员口的已知单播报文通过但禁止所有从Peer-Link接口发往M-LAG成员口的广播/未知单播报文。这是什么意思假设一个广播包从主设备的成员口进入主设备会将其从Peer-Link泛洪给备设备。备设备收到后由于上述ACL规则它不会把这个广播包再从自己的成员口发回给下游否则就环路了。这样就保证了广播流量只被下游设备接收一次完美防环。这个机制是双向的谁从成员口收到广播对端就被隔离。对于组播流量情况稍复杂。在二层网络中防环机制和广播类似。在三层组播网络中运行PIM为了保证组播接收者只收到一份流量M-LAG采用了一个“奇偶规则”根据组播组地址的最后一个字节是奇数还是偶数来决定由主设备还是备设备的成员口来转发。例如组播组224.1.1.1最后一位是奇数就由成员口状态为主的设备转发224.1.1.2偶数则由成员口状态为备的设备转发。两台设备都会收到组播流量但会根据这个规则决定是否从自己的成员口转发出去避免了重复。4. 实战关键各种故障场景下的切换逻辑配置好了不叫本事出了故障能快速定位、理解其行为才是真功夫。M-LAG的可靠性就体现在对各种故障的优雅处理上。4.1 上行链路故障假设主设备设备A连接核心网络的上行链路断了但Peer-Link和心跳链路都正常。这时会发生什么对于从下游发往网络侧的流量原本要经过设备A转发的流量其哈希路径可能指向A。由于A上行不通这些流量会被设备A通过Peer-Link链路转发给设备B再由设备B从其正常的上行链路送出。整个过程对下游设备完全透明它根本不知道A的上行挂了。对于从网络侧返回的流量核心网络侧的路由或三层转发可能会将部分流量目的IP指向设备A的网关双活网关IP。当报文到达设备A时A发现目的主机在自己的MAC表里但出接口是M-LAG成员口逻辑上指向下游。由于Peer-Link正常A可以通过Peer-Link将报文送给B再由B从它的成员口发给下游服务器。或者如果网络侧路由收敛将网关路由指向了设备B则流量直接由B处理。关键点只要Peer-Link正常M-LAG系统在逻辑上就还是完整的“一台设备”只是内部路径发生了迂回。所有流量转发不中断。4.2 下行链路M-LAG成员口故障假设连接服务器的主设备设备A的M-LAG成员口链路故障比如网线被拔了。单播流量设备A会立刻通过Peer-Link发送同步报文告知设备B“我这边这个成员口Down了”。设备B会更新状态。同时设备A会将自己MAC表中指向该故障成员口的表项重新指向Peer-Link接口。这样发往该服务器的流量到达设备A后会被引导通过Peer-Link发给设备B再由设备B从其正常的成员口发下去。服务器侧因为有一条链路Down了它的操作系统或网卡驱动会感知到所有流量切到剩下的那条链路上连接到设备B。这是一个双向配合的切换过程。组播流量如果故障的是主设备上的成员口状态为主那么按照“奇偶规则”原本由它转发的奇数组播流量就没人转了。这时M-LAG系统会触发组播转发角色切换。设备A会通知设备B之后所有组播流量不分奇偶都由状态仍为Up的备设备成员口转发。等故障恢复后这个角色不会自动切回而是继续保持由这个“备转主”的接口转发直到下一次故障发生。这避免了频繁切换。4.3 设备整机故障这是考验M-LAG可靠性的核心场景。备设备故障相对简单。备设备宕机其所有端口Down。主设备感知到Peer-Link对端中断、心跳丢失。主设备继续工作下游设备通过LACP协议会将其连接到备设备的那条链路标记为Down所有流量切到连接主设备的链路。M-LAG系统变为“单归”模式但业务不中断。主设备故障情况类似但涉及角色切换。主设备宕机备设备感知到心跳和Peer-Link中断。备设备会升级为新的DFS主设备。同时下游设备连接原主设备的链路因对端宕机而Down流量全部切到连接新主设备原备设备的链路。这里有个重要行为原主设备恢复后它会作为新的备设备加入系统不会抢回主角色。这保证了控制层面的稳定性避免不必要的震荡。4.4 Peer-Link故障最严峻的考验Peer-Link故障是M-LAG最危险的场景因为它直接分裂了“大脑”之间的连接。这时双主检测链路心跳链路就至关重要了。两台设备瞬间感知Peer-Link Down。它们立即通过心跳链路发起紧急双主检测快速发送DAD报文。通过DAD报文协商依然能决出一个HB DFS主和一个HB DFS备这个主备可能和原来的DFS主备不同它基于心跳链路协商。协商为HB DFS备的设备会主动Error-Down自己的M-LAG成员口在普通以太网络中可能会Error-Down所有业务口。这样下游设备只能通过HB DFS主设备的那条链路通信避免了双主冲突。流量全部切换到HB DFS主设备路径业务得以继续但失去了负载分担能力。关键配置建议务必确保心跳链路与Peer-Link的物理路径完全分离最好走不同的板卡、不同的线路。如果心跳和Peer-Link走同一条物理链路或设备一旦这条路径中断两者同时失效系统将无法进行双主检测真的可能形成“脑裂”后果严重。4.5 二次故障Peer-Link与设备同时故障这是更极端的场景。比如Peer-Link先故障触发了双主检测备设备假设成为HB DFS备Error-Down了自己的端口。接着主设备HB DFS主也故障了。这时网络会怎样 如果开启了二次故障增强功能那么HB DFS备设备在心跳超时感知到主设备故障后会将自己从Error-Down状态中恢复重新启用端口接替工作。这提供了最后一重保障。这个功能需要在配置时留意是否启用。5. 进阶话题V-STP与多级M-LAG组网在实际复杂组网中M-LAG还会遇到和其他协议交互的问题最典型的就是STP。5.1 为什么需要V-STP下游交换机如果运行STP它会从两条链路收到BPDU报文。在它看来这是两个不同的“桥”交换机这会导致STP计算阻塞其中一个端口破坏了M-LAG双活负载分担的设计初衷。我们需要让下游交换机认为它只连了一台设备。传统做法根桥方式手动将两台M-LAG设备的桥ID配置成完全相同并都设置为根桥。这样下游设备从两边收到的BPDU完全一样认为连接的是同一个根桥就不会阻塞端口。但这种方式不够灵活且在网络拓扑复杂时可能干扰全局STP树的计算。推荐做法V-STP方式V-STP是华为为M-LAG量身定制的特性。启用后M-LAG备设备在STP协议层面会“隐藏”自己它不再发送自己的BPDU而是使用从主设备同步过来的桥ID、优先级等信息来生成和发送BPDU。对于下游设备它从两条链路收到的BPDU完全一致真正实现了“两台设备虚拟成一台”的STP效果。配置V-STP时记得确保两台设备上的STP模式如RSTP和定时器配置一致否则可能引起震荡。5.2 多级M-LAG组网在大型数据中心可能会看到接入交换机通过M-LAG双归到汇聚交换机汇聚交换机再通过另一个M-LAG双归到核心交换机形成多级M-LAG。这种组网极大地增强了纵向可靠性。在这种多级场景下必须使用V-STP而不能用手动配置根桥的方式。因为手动配置相同桥ID在多级之间会冲突且无法处理复杂的拓扑变化。V-STP可以逐级虚拟化保证每一级的下游设备看到的都是一个逻辑上的单一设备STP计算清晰无环。6. 配置与排错心法我踩过的那些坑说了这么多理论最后分享点实战干货。配置M-LAG命令行并不复杂但细节决定成败。配置 checklist基础网络互通确保两台设备的管理IP、心跳链路IP能互通。创建DFS-Group两边配置相同的DFS Group ID通常为1。配置Peer-Link用至少两条链路创建Eth-Trunk并portswitch切换到二层模式然后在这个Eth-Trunk接口下执行peer-link命令。记得把这个Trunk口放行所有需要的业务VLAN。配置双主检测在DFS-Group视图下指定心跳链路的源IP和对端IP。确保路由可达。配置M-LAG成员口在连接下游的Eth-Trunk接口下配置m-lag groupID。两边的ID必须一致。配置双活网关在三层接口或VLANIF接口下配置相同的IP和MAC地址。启用V-STP如果需要在系统视图下v-stp enable。排错关键点状态查看多用display dfs-group和display m-lag命令。重点看DFS状态是否“Peer”、M-LAG接口状态是否“Up”。Peer-Link不通检查物理链路、光模块、Trunk配置、允许的VLAN。这是最常见的问题根源。心跳链路不通检查IP配置、路由、中间网络设备ACL是否放通了UDP端口默认是ETH-OAM端口。表项不同步检查Peer-Link是否正常确认没有ACL或防火墙策略阻塞了M-LAG同步报文目的MAC是特定的组播MAC。下游链路聚合不起来检查下游设备是否正确配置了LACP模式如mode active。检查两边的M-LAG ID是否一致。检查M-LAG成员口是否加入了正确的VLAN。我在早期部署时曾因为心跳链路走了管理网而管理网交换机做了端口隔离导致双主检测失败一次Peer-Link闪断就引发了业务端口Error-Down。还有一次忘记在Peer-Link的Trunk口放行某个业务VLAN结果那个VLAN的表项一直无法同步故障现象时好时坏排查了很久。所以理清逻辑检查细节M-LAG其实是一个非常稳定和强大的技术。希望这篇深度解析能帮你少走弯路在实际网络中用好这把高可用的利器。