提到M-LAG很多刚接触数据中心或园区网络的朋友第一反应是这不就是堆叠吗直接两台交换机捆成一个逻辑设备省心又省事。我在项目里见过不少同行这么理解结果真到割接和排障的时候被M-LAG和堆叠的差异折腾得够呛。今天想把M-LAG从头到尾捋一遍说清楚它到底是什么、能解决什么问题、实际组网怎么配、故障怎么处理。M-LAG全称是Multi-Chassis Link Aggregation中文一般叫跨设备链路聚合。它的核心能力是两台物理交换机组成一个系统对外看起来像一台交换机下游服务器、交换机或防火墙可以通过以太网链路聚合协议同时接入这两台设备所有链路都能转发流量而不是像传统STP方案那样只能留一条转发、其他全部Block浪费掉。适合谁看呢正在规划数据中心核心、园区汇聚高可用或者被堆叠“一锅端”故障搞怕了的网络工程师这篇文章里的配置思路和排错经验都用得上。1. 先搞清楚M-LAG到底解决什么问题1.1 没有M-LAG之前我们是怎么做的在没有M-LAG的年代想要让两台设备同时干活、又不想浪费链路带宽最主流的做法就是堆叠。堆叠通过专用的堆叠线缆把两台或者多台交换机变成一个逻辑设备配置同步、表项共享、转发面统一。优点是管理简单缺点也很明显控制面强耦合一台设备被异常流量打挂整个堆叠系统都要受影响版本要求严格一致升级时经常要整机重启业务中断时间不好控制。更头疼的是堆叠链路本身又成了单点一旦堆叠口抖动导致设备分裂两台设备都拿着同一份配置同时转发网络分分钟出现MAC漂移和广播风暴这就是业内经常说的“堆叠脑裂”。另一条路是STP/MSTP双上行。两台接入交换机分别上联到两台汇聚通过STP把其中一条链路Block掉等主链路故障再切换。这种方案确实隔离了故障域但代价是有一半的带宽常年闲置而且STP收敛要经历Listening、Learning再到Forwarding即使RSTP优化过秒级切换对关键业务来说也很难接受。于是出现了M-LAG这种“既要冗余、又要带宽、还要独立”的方案。1.2 M-LAG和堆叠到底差在哪很多朋友问我M-LAG和堆叠从使用体验上有什么区别我一般用一个比方堆叠是两个人合成一个大脑任何一个人出问题整个身体都受影响M-LAG是两个人各有一个大脑但对外用一个声音说话、一个动作做事一个人倒下了另一个人还能独立撑着。从技术维度看更直观对比项堆叠M-LAG设备管理一台逻辑设备统一登录两台独立设备分别管理控制面强耦合一台异常影响整体独立运行单台故障隔离版本要求严格一致升级风险大同一大版本基本可兼容跨设备链路聚合支持但绑定堆叠系统原生通过M-LAG成员口支持分裂故障可能双主风险高通过keepalive检测备设备自动关闭业务口故障域整个堆叠系统单台设备常见应用接入/汇聚简化管理数据中心核心、关键业务汇聚说白了堆叠适合“图省事”的场景M-LAG适合“图稳”的场景。做核心和汇聚的兄弟们我更推荐M-LAG因为网络核心节点最怕的就是“一死一大片”。2. M-LAG的关键组成部分与工作原理2.1 peer-link、keepalive和M-LAG成员口M-LAG有两个核心链路一个叫peer-link一个叫keepalive再加上业务口上创建的M-LAG成员口三样东西配合起来才能工作。peer-link是两台M-LAG交换机之间的互联链路负责传递DRCP等M-LAG控制报文同时也会承载一部分跨设备的数据流量。比如一台服务器单归挂在设备A上这时如果没有走设备A的路径流量需要到设备B去转发就得通过peer-link绕行。所以peer-link必须使用Eth-Trunk或者Port-Channel做聚合至少两个物理口起步条件允许的话建议做4个或者更多带宽规划要参考跨设备流量的峰值。这里有个很多人容易忽略的点peer-link不能拿来跑业务VLAN的普通三层接口或二层接口配置它是M-LAG专用链路必须单独规划。keepalive是双主检测的心跳链路只用来检测两台设备是否都还活着不转发业务流量。一旦peer-link因为某种原因断了两台设备无法通过peer-link互通M-LAG协商报文这时候就需要keepalive来判断对端到底是真的故障了还是只是链路断了。如果keepalive还通两台设备会做竞选优先级高的设备保留业务转发优先级低的设备自动关闭M-LAG成员口避免出现两台设备同时转发导致环路。keepalive一般建议使用独立的物理口或者专线直连两台设备中间不要跨三层网络设备因为一旦中间设备故障keepalive误判会非常麻烦。M-LAG成员口就是两台设备上加入同一个M-LAG域的物理口对下游设备来说这两台设备上对应成员口组成的聚合链路就像是一条普通Eth-Trunk里的两个成员口。下游设备在启LACP时看到的是同一个系统ID所以它认为对端就是一台逻辑交换机链路聚合协商能够正常完成。2.2 故障场景下的“脑裂”处理机制M-LAG最关键的机制是防脑裂。很多人第一次接触M-LAG时听到“双主检测”这个概念会有点绕我拆开说。第一种情况peer-link断了但keepalive正常。这时两台设备通过keepalive感知到对端还活着于是进入竞选流程。系统优先级高数值小的设备成为主设备继续转发业务优先级低的设备进入备用状态自动把M-LAG成员口置为Down或Error-down。这样从下游交换机或服务器看原本聚合的两条链路变成了一条流量全部走到主设备不会环也不会双发。第二种情况peer-link断了keepalive也断了。这是最危险的双主故障两台设备都认为自己是主设备都会转发业务。所以keepalive的规划特别重要直连独立链路是最稳妥的做法避免和peer-link共用物理路径。第三种情况一台设备整机掉电或重启。M-LAG系统通过LACP报文丢失能够快速感知存活设备接管所有业务收敛时间通常在秒级以内具体取决于设备的检测机制。这里面有个细节单条成员口失效的收敛是毫秒级到百毫秒级因为LACP重哈希很快而整机故障或者peer-link故障因为牵涉到双主检测和接口状态切换收敛时间会长一些。2.3 一致性检查为什么会阻塞你的接口M-LAG有个让新手很困惑的机制叫一致性检查。为什么两台设备配置必须一致因为从下游看两条物理链路属于同一个聚合口如果两台设备上的VLAN配置、链路类型、PVID不一致对端交换机通过LACP协商出的是一个聚合口但实际报文进去之后发现两边的VLAN行为完全不同转发就会出大问题。华为的M-LAG一致性检查分type 1和type 2。type 1是强相关检查比如M-LAG成员口所属的VLAN、链路类型、PVID等如果不一致设备会直接把M-LAG成员口Error-down属于“宁可不通不能错转”的策略。type 2是弱相关检查比如STP优先级等不一致时设备会告警提示但不会主动阻塞接口。实操中我的建议是两台设备上配置M-LAG业务口之前先规划一个统一的模板把所有可能影响转发的配置都拉齐比如VLAN列表、Trunk allowed vlan、PVID、链路类型、STP边缘配置。别图省事先在一台上配好再复制很容易漏掉某个字段。上线后如果真的看到成员口被Error-down第一反应就去看一致性检查结果而不是反复拔插光模块。3. 典型场景2台M-LAG交换机上联1台出口设备3.1 场景拓扑和为什么这么用标题里提到的场景——2台M-LAG交换机上联一台出口设备在园区网和中小数据中心里非常典型。一般拓扑是这样两台M-LAG交换机作为核心或汇聚下联服务器或接入交换机双归接入上联到一台出口路由器或防火墙形成“下联双活、上联也双活”的架构。这个组网的价值在两点。第一下联服务器可以用双网卡绑定LACP模式两条链路同时转发带宽翻倍单台交换机故障不影响服务器通信。第二上联出口设备虽然只有一台但出口设备的下行口可以做Eth-Trunk两个物理口分别接到两台M-LAG交换机上这样出口设备也不会因为某一台M-LAG交换机故障而丢失整条上行路径。如果出口设备本身支持双机两台出口设备之间再跑主备或者负载均衡整个链路的可用性就更高了。当然如果出口设备不支持跨设备链路聚合也不支持双机那老老实实让M-LAG交换机各出一条上联到出口设备靠路由或VRRP选路也行不过会浪费一条链路。我的经验是防火墙类设备现在很多都支持Eth-Trunk或者双机配置前先确认一下特性支持情况别等设备到现场再发现做不了跨设备聚合。拓扑的文字描述大概是出口设备路由器/防火墙 |-- link1 接到 M-LAG交换机A |-- link2 接到 M-LAG交换机B M-LAG交换机A --peer-link/keepalive-- M-LAG交换机B |-- 服务器/接入交换机双归3.2 详细配置步骤华为V200R系列风格不同厂商命令差别很大华为、H3C、锐捷、思科各有各的写法但核心配置思想是一样的。这里我用华为风格演示你把思路搞懂换到其他厂商看手册也能很快上手。配置前先规划好两台设备之间用10GE口做peer-link假设A、B两台设备互联物理口分别是10GE1/0/27和10GE1/0/28keepalive直连地址用10.10.10.0/24段的两个地址服务器接入用一个业务Eth-TrunkM-LAG ID是1。先配置peer-link两台设备都要做# 设备A interface Eth-Trunk10 m-lag mode peer-link trunkport 10GE1/0/27 trunkport 10GE1/0/28# 设备B interface Eth-Trunk10 m-lag mode peer-link trunkport 20GE1/0/27 trunkport 20GE1/0/28注意peer-link的两端接口类型不同没关系但必须是物理接口不能拿已经划进业务VLAN的口来复用。接着配置keepalive和M-LAG域# 设备A m-lag keepalive ip address 10.10.10.1 24 peer-link interface Eth-Trunk10 m-lag id 1# 设备B m-lag keepalive ip address 10.10.10.2 24 peer-link interface Eth-Trunk10 m-lag id 1这里要注意设备A和B的keepalive地址要配成对端可达的直连地址而且这个链路不要跟业务VLAN混在一起。然后创建业务Eth-Trunk指定M-LAG成员ID。以服务器接入为例A设备上用10GE1/0/1B设备上用20GE1/0/1# 设备A interface Eth-Trunk1 mode lacp-static m-lag member id 1 trunkport 10GE1/0/1 stp edge-port enable# 设备B interface Eth-Trunk1 mode lacp-static m-lag member id 1 trunkport 20GE1/0/1 stp edge-port enable接下来配置网关。M-LAG交换机上通常用VLANIF加VRRP做网关冗余# 设备A vlan batch 100 interface Vlanif100 ip address 192.168.100.1 24 vrrp vrid 100 virtual-ip 192.168.100.254 vrrp vrid 100 priority 120# 设备B vlan batch 100 interface Vlanif100 ip address 192.168.100.2 24 vrrp vrid 100 virtual-ip 192.168.100.254最后配置出口设备侧。出口设备的下行口做一个Eth-Trunk模式同样用LACP静态聚合# 出口设备以华为防火墙为例 interface Eth-Trunk1 mode lacp-static trunkport GE1/0/0 trunkport GE2/0/0配置完成后检查M-LAG状态确认peer-link up、keepalive正常、M-LAG成员口处于协商成功状态一致性检查没有异常整个配置就算落地了。实际项目中我一般还会手动把两台M-LAG交换机的LACP系统优先级配成一致且比下游设备小的值防止下游LACP选举出现意外的系统优先级冲突。3.3 转发路径和流量走向理解M-LAG的流量走向是排错的第一步。服务器要访问外部网络时发出带网关MAC的帧。如果流量哈希到了设备A设备A本机有VLANIF网关直接三层转发到上联口从出口设备出去。如果流量哈希到了设备B设备B同样可以走本机VLANIF三层转发不需要专门把流量通过peer-link绕回设备A。M-LAG场景下VRRP的主备只是提供网关冗余并不限制数据面转发这点和传统VRRP“主设备转发全部流量”的认知不一样。下行流量从出口设备发往服务器时出口设备根据LACP哈希把流量发到设备A或设备B。如果服务器是双归接入目标MAC对应的M-LAG成员口在当前设备上就直接从本机转发如果服务器是单归挂在设备B但哈希结果把流量送到了设备A那么设备A会通过peer-link把报文转发给设备B由设备B送达服务器。这就是为什么前面强调peer-link带宽不能拍脑袋定跨设备单归流量多的时候peer-link就是一条“隐性瓶颈”。4. 你可能踩过的坑常见问题与排查4.1 keepalive没通配置半天最后全断遇到过一次现场M-LAG配置看着全对peer-link也起得来但两台设备间的keepalive就是不通。排查下来发现keepalive地址虽然配了但两台设备之间的物理线路接在一个不能透传该VLAN的傻瓜交换机上导致心跳报文被丢弃。后来直接改成了两台设备之间的专用光纤直连问题秒解。排查keepalive问题时先看M-LAG域里的keepalive状态是不是Active再看两台设备能否互相ping通keepalive地址。如果ping不通优先查物理层、VLAN划分别急着怀疑M-LAG配置。另外要强调一点keepalive的源目地址不能配在peer-link同一个Eth-Trunk上必须走独立三层路径。4.2 peer-link带宽不够导致拥塞丢包有次在客户现场做性能测试跑着跑着发现跨设备流量丢包很严重但两台设备CPU、内存都不高。查了一圈最后定位到peer-link只有一条1GE物理链路而下联服务器都是10GE双归一旦流量哈希到非本机成员口就要跨peer-link绕行1GE根本扛不住。peer-link带宽规划我建议宁可冗余也不要卡着够用线华为官方定义里peer-link总带宽要大于所有M-LAG成员口总带宽实际项目里一两台设备互联我通常直接做4条10GE聚合虽然成本高一点但省得后期扩容和排障。没有预算的至少也要满足跨设备流量的峰值带宽并且留20%到30%冗余。4.3 一致性检查失败导致成员口被阻塞症状很典型两台设备上的M-LAG成员口一侧正常转发另一侧显示Error-down下游服务器bond只起来一个口流量全靠一条链路扛。登录备设备一看日志M-LAG一致性检查type 1失败。排查时用display m-lag consistency查看具体检查项。绝大多数情况是VLAN配置不一致比如设备A上Trunk放通了VLAN 100和200设备B上只放通了VLAN 100两边M-LAG成员口的allowed vlan对不上。也有的是PVID不同或者一边配置了边缘端口另一边没配。处理办法就是拉齐两台设备上的相关配置然后手动shutdown再undo shutdown恢复Error-down口。这里提醒一句改配置前先看下当前业务情况别把正在转发的流量给切了。4.4 设备升级和扩容的坑M-LAG相对堆叠的一大优势就是可以逐台升级但前提是操作顺序要对。我踩过的坑是直接在备设备上重启结果因为业务分布问题部分双归流量断了。正确做法是先把要升级的设备上的M-LAG成员口置为Down或者调低该设备的M-LAG优先级让流量切到对端再检查对端设备能不能扛住所有业务最后再重启升级。升级完成后先观察一段时间确认表项同步和一致性检查正常再恢复另一台。扩容成员口时也有讲究别一口气把新接入的几十个口全部加进M-LAG成员口。大批量接口同时UP瞬间泛洪和表项学习压力会冲击设备CPU。我习惯分批加口比如一次4到8个口等流量稳定了再继续加。4.5 与其他技术叠用时的冲突STP和M-LAG合用的坑非常经典。下游接入交换机明明启了STP但因为M-LAG成员口没有配置边缘端口收到BPDU后直接把成员口阻塞了导致服务器bond只有一个口工作。所以M-LAG成员口我几乎都会配STP边缘端口必要时加BPDU Filter。DHCP和组播场景也要注意双主问题。虽然M-LAG有防脑裂机制但任何机制都有边界如果两台设备因为某种原因处于双主状态DHCP服务器或者组播源在两端同时接入就可能导致双份响应。实际部署时建议在网关或者上联设备做防御同时在M-LAG域里把双主检测手段配全peer-link故障检测、keepalive检测、以及设备支持的数据平面双主检测一起上。我还整理了一个常见问题速查方便兄弟们现场排查现象可能原因排查命令/手段M-LAG成员口Error-down一致性检查type 1失败display m-lag consistency对比VLAN/PVID两台设备同时转发、MAC漂移keepalive失效或未配置display m-lag keepalive status检查直连链路下游聚合口只有一个成员UP对端设备LACP系统ID不一致核对两台M-LAG交换机的system-id和系统优先级跨设备流量丢包严重peer-link带宽不足看peer-link利用率、错误计数服务器bond协商不起来两台设备M-LAG ID不一致display m-lag verbose确认成员口绑定同一ID5. 选型建议与各厂商对应实现5.1 什么时候选M-LAG什么时候选堆叠回到文章开头的问题。M-LAG和堆叠怎么选我给一个比较务实的建议。如果你的网络节点是核心层或者承载了多个业务方、故障影响面很大那就别省事直接用M-LAG。M-LAG的独立故障域能保证单台设备出问题时另外一台还撑得住这对于“网络不能挂”来说是底线。如果只是接入层或者小规模汇聚设备数量多、运维人力少堆叠确实能省掉不少配置和排障成本。只要把堆叠链路的健康监控做好堆叠脑裂风险控制住问题也不大。不过很多朋友在实际项目里会发现一旦网络规模变大堆叠的升级风险会越来越难以接受这时候再往M-LAG迁移的代价就高了。我自己现在的原则很简单汇聚及以上节点优先M-LAG。5.2 各厂商对应技术名称和差异M-LAG不是一个厂商的专属技术各大厂商都有对应的实现但命名和部分细节有差异厂商技术名称核心组件华为M-LAGpeer-link、keepalive、M-LAG成员口H3CDRNIpeer-link、keepalive、DRNI成员口锐捷M-LAGpeer-link、keepalive、M-LAG成员口思科vPCpeer-link、keepalive、vPC成员口开源MCLAGpeer-link、keepalive、MCLAG成员口虽然叫法不同但逻辑上高度一致都需要一条控制通道、一条心跳检测通道、一组跨设备聚合成员口。区别主要体现在一致性检查的具体项、双主检测的算法、以及和VRRP/三层网关的配合方式上。跨厂商跳槽或者同时维护多厂商设备的朋友建议切换厂商后第一时间去翻对应的一致性检查和处理双主的手册不要想当然通用。5.3 我踩过几次坑之后的几点心得最后分享几个只有真正上线跑过M-LAG的人才会注意到的细节。第一上线前一定做故障演练。拔一根peer-link物理线、断掉keepalive、直接关掉一台设备电源分别观察业务切换时间和是否存在双主。演练中暴露的问题比上线后再去救火要值钱得多。我见过一个项目演练时发现备设备关闭成员口需要将近10秒后来调整了keepalive周期才把收敛时间压下来。第二keepalive周期不要图快。华为默认keepalive周期是10秒超时次数3次。有人为了追求快速检测把周期改成1秒结果网络抖动一次就误触发双主检测两台设备来回抢主业务反而闪断。我一般建议周期设置在3到5秒之间超时倍数保持默认或稍微调大兼顾速度和稳定性。第三LACP系统优先级一定要手动配并且两台M-LAG交换机要一致。如果让设备用默认的系统优先级一旦对端出口设备也参与LACP协商两边系统优先级相同就可能因为设备桥MAC的不同导致聚合协商异常。手动配成较小的、一致的系统优先级能省掉很多莫名其妙的“聚合口起不来”问题。M-LAG这个技术本身并不复杂复杂的是在实际组网中把它的机制和业务场景匹配起来。希望这篇梳理能帮你少走一些弯路也让那些还在M-LAG和堆叠之间纠结的朋友有一个更清晰的选型依据。