前阵子给一个数据中心做接入-汇聚冗余改造业务模型很普通服务器双网卡bondVLAN网关收敛在汇聚层要求任一台交换机故障都不能断网。客户一开始倾向堆叠我直接劝退。数据中心这个场景堆叠的脑裂风险、升级窗口和跨机柜的堆叠线缆限制都挺麻烦用STP又意味着收敛时间长、链路利用率低。最后用了华为CE系列交换机的级联M-LAG方案接入层两台CE6881做成一组M-LAG汇聚层两台CE6881做成另一组M-LAG两层之间走四条物理链路构成口字型。配完之后做了故障演练单台设备掉电、单链路闪断都验证过业务无感知。这篇文章想把几件事讲透什么场景适合级联M-LAG、级联组网的底层原理、完整的配置示例以及我在配置和排障过程中踩过的坑。适合正要上M-LAG的数据中心网络工程师或者准备把现网堆叠平滑改造成M-LAG的运维同学参考。1. 为什么数据中心要做两级M-LAG堆叠和STP在这里都不够用1.1 传统冗余方案的两个死穴大多数数据中心接入-汇聚组网冗余方案翻来覆去就三种思路STP/RSTP、堆叠、M-LAG。前两种在数据中心场景各有硬伤。STP的问题是收敛和利用率。RSTP在链路故障时收敛需要秒级对服务器和数据库业务来说断网超过一两秒就可能触发上层应用重连、超时核心业务根本扛不住。而且STP天然会阻塞一条冗余链路两条上行链路一条转发一条blocking链路利用率只有50%花了钱买了两条带宽却只能用一半。这在一个机柜几十台服务器的场景下非常肉疼。堆叠的问题更隐蔽。堆叠把两台设备变成一个控制面听起来很美好但它有个绕不开的敌人叫脑裂。堆叠线缆一旦松动或故障两台设备同时以为自己是主设备两台都开始转发广播、MAC表项冲突会直接把网络打崩。数据中心里物理设备分散在多个机柜堆叠线缆距离受限升级维护时经常需要整堆叠重启窗口也很难约。很多客户一提堆叠我都得先问一句你接受脑裂预案吗大部分人听完就沉默了。1.2 级联M-LAG到底长什么样M-LAGMulti-Chassis Link Aggregation跨设备链路聚合思路是两台设备各自独立运行控制面但对外通过协商伪装成一台逻辑设备。服务器双归到这两台设备时对端看到的是一个虚拟交换机普通链路聚合直接就能跑不需要服务器感知任何特殊协议。所谓级联M-LAG本质上就是按层级把M-LAG叠起来接入层两台交换机组成一组M-LAG汇聚层两台交换机组成另一组M-LAG。两组M-LAG之间不是传统的主备关系而是通过四条物理链路互联形成口字型双活拓扑。我在这个项目里用的拓扑非常典型接入层SW-A1和SW-A2组成M-LAG域1汇聚层SW-C1和SW-C2组成M-LAG域2。SW-A1分别连SW-C1和SW-C2SW-A2也分别连SW-C1和SW-C2加上接入层两台之间的peer-link和汇聚层两台之间的peer-link整个拓扑就像一个大写的口字。任何一条链路、任何一台设备故障业务都有备用路径而且切换对服务器完全透明。1.3 和堆叠比M-LAG强在哪很多运维第一次听说M-LAG都会问这不就是堆叠吗还真不是。堆叠是一台设备拆成两台外壳控制面共用故障域大M-LAG是两台独立设备协同工作控制面各跑各的通过协议同步表项故障域被限制在单台设备内。维度堆叠M-LAG控制面共用一套主备倒换影响全局各自独立一台故障另一台不受影响脑裂风险堆叠线缆故障容易引发脑裂双主检测机制完善MAD可自动关闭冲突端口升级维护通常需要整堆叠重启或专用升级流程单台隔离升级业务无感物理距离堆叠线缆距离受限peer-link和keepalive可按需设计故障域两台设备共享一个故障域故障被隔离在单台设备级联M-LAG在接入-汇聚两层都用了这种双活但不共用脑子的设计每一层的两台设备都是独立运行的不会出现堆叠那种一台出问题拖着另一台陪葬的情况。这个特性在数据中心里尤其值钱——故障爆炸半径越小越好。2. 级联M-LAG的底细DFS域、统一系统ID和双主检测怎么配合2.1 两台设备如何伪装成一台设备先说一个很多人刚接触M-LAG时容易绕晕的点两台独立设备凭什么让对端觉得是同一台关键在于LACP的系统ID。链路聚合协商时对端交换机会根据LACP报文里的System ID判断成员口是不是属于同一台设备。普通场景下两台交换机各有各的System ID所以A1-C1这条链路和A2-C1这条链路永远聚合不到一起去。M-LAG解决这个问题的办法是两台设备通过DFSDistributed Forwarding Service分布式转发服务协议协商选出一个主设备然后两台设备对外使用同一个System ID。对端交换机一看哦这几个成员口来自同一个逻辑设备于是放心地把四条物理链路聚合成一个Eth-Trunk。这也是级联M-LAG能成立的核心。接入层M-LAG对外统一System ID汇聚层交换机才能把下行的口字型链路聚合成一个Eth-Trunk汇聚层M-LAG同样对外统一System ID接入层交换机才能把上行的口字型链路聚合起来。两层都伪装好了整个口字型拓扑才能正常工作。2.2 peer-link、keepalive和DFS域的三角关系M-LAG设备之间有三条逻辑上的绳子很多人配置时只关注业务口结果栽在这三条绳子上。第一条是peer-link也就是M-LAG设备间的互联链路。它承担两个任务一是同步MAC表、ARP表、路由表等控制面信息二是承载跨设备转发流量。比如服务器双归接入A1和A2流量哈希到了A1但目的MAC的出接口在A2A1就得通过peer-link把报文转给A2。所以peer-link不是普通互联口它相当于两台设备之间的内部总线带宽规划得按业务流量认真算。第二条是keepalive链路用于双主检测。peer-link负责数据同步keepalive负责探活。两条链路职责不同互为补充。第三条是DFS域本身。两台设备必须在同一个域内domain id一致才能建立邻居关系域内运行的DFS协议负责把两台设备的表项同步起来。级联场景下接入层一个域、汇聚层一个域域ID必须区分开否则邻居关系会乱。2.3 双主检测机制MAD是怎么工作的M-LAG最让人安心的是MADMulti-Active Detection多主检测机制。正常情况下两台M-LAG设备一台是master一台是backup当peer-link故障时两台设备之间失去控制面同步都会觉得自己应该接管业务这就出现了类似堆叠脑裂的双主状态。MAD的处理逻辑是peer-link故障后两台设备立刻通过keepalive链路确认对端是否存活。如果keepalive正常说明对端还在运行优先级低的设备会把自己除peer-link和keepalive外的所有业务口置为MAD Down状态也就是自动缴械保证只有主设备在转发避免双主冲突。当peer-link恢复后MAD Down的接口自动恢复。但如果keepalive和peer-link同时故障MAD就检测不到对端了两台设备都以为自己是唯一存活的主设备双主风险就会出现。这也是keepalive链路必须跟peer-link完全独立的原因后面踩坑部分我再详细说。3. 级联M-LAG配置实操接入层与汇聚层两层M-LAG的完整示例3.1 组网规划与端口安排配置前先花十分钟把规划和端口梳理清楚。这次演示环境使用CE6881生产环境如果汇聚层流量压力大可以根据实际情况换成CE8860等更高性能的型号配置逻辑完全一致。设备角色互联对象接口规划用途SW-A1接入层M-LAG成员1SW-A240GE1/0/1-2peer-link Eth-Trunk 1SW-A1接入层M-LAG成员1SW-C1 / SW-C240GE1/0/3-4上联Eth-Trunk 11SW-A2接入层M-LAG成员2SW-A140GE1/0/1-2peer-link Eth-Trunk 1SW-A2接入层M-LAG成员2SW-C1 / SW-C240GE1/0/3-4上联Eth-Trunk 11SW-C1汇聚层M-LAG成员1SW-C240GE1/0/1-2peer-link Eth-Trunk 1SW-C1汇聚层M-LAG成员1SW-A1 / SW-A240GE1/0/3-4下行Eth-Trunk 20SW-C2汇聚层M-LAG成员2SW-C140GE1/0/1-2peer-link Eth-Trunk 1SW-C2汇聚层M-LAG成员2SW-A1 / SW-A240GE1/0/3-4下行Eth-Trunk 20业务VLAN规划为VLAN 10和VLAN 20网关在汇聚层。keepalive链路我习惯用管理口MEth0/0/0独立于业务转发面最省心如果设备管理口有其他用途也可以各拿一个独立物理口走专门的互联网段。VLAN和IP规划如下业务VLANVLAN 10、VLAN 20接入层keepalive网段10.255.1.0/30汇聚层keepalive网段10.255.2.0/30VLAN 10网关10.1.10.254/24VLAN 20网关10.1.20.254/243.2 接入层SW-A1/SW-A2配置接入层两台设备配置逻辑一致只列SW-A1的完整配置SW-A2照着改IP即可。代码里的中文注释是我加的解释实际设备上不要敲注释。# SW-A1 接入层设备配置 sysname SW-A1 # 业务VLAN vlan batch 10 20 # 创建peer-link的Eth-Trunk并放通业务VLAN interface Eth-Trunk 1 port link-type trunk port trunk allow-pass vlan 10 20 # 将成员口加入peer-link Eth-Trunk interface 40GE1/0/1 eth-trunk 1 interface 40GE1/0/2 eth-trunk 1 # 创建M-LAG域指定peer-link和keepalive m-lag domain 1 peer-link interface Eth-Trunk 1 keepalive interface MEth0/0/0 # 管理口作为keepalive通道配置互联IP interface MEth0/0/0 undo shutdown ip address 10.255.1.1 255.255.255.252 # 创建上联汇聚层的Eth-Trunk对接SW-C1和SW-C2 interface Eth-Trunk 11 mode lacp-static port link-type trunk port trunk allow-pass vlan 10 20 # 上联成员口一根去SW-C1一根去SW-C2 interface 40GE1/0/3 eth-trunk 11 interface 40GE1/0/4 eth-trunk 11 # 将上联Eth-Trunk加入M-LAG域成为M-LAG成员口 m-lag domain 1 m-lag interface Eth-Trunk 11SW-A2的配置把keepalive地址改成10.255.1.2其余完全一致。注意SW-A2的40GE1/0/3和40GE1/0/4也要分别对接SW-C1和SW-C2这样才能保证口字型拓扑对称。这里有个容易忽略的点上联Eth-Trunk 11用了mode lacp-static也就是LACP模式。M-LAG场景必须用LACP因为LACP协商依赖对端的System ID判断成员口归属静态手工聚合无法感知两端M-LAG统一后的系统ID聚合会出问题。3.3 汇聚层SW-C1/SW-C2配置接入层配置完成后再配汇聚层这里M-LAG域换成了域2避免与接入层混淆。# SW-C1 汇聚层设备配置 sysname SW-C1 vlan batch 10 20 # peer-link Eth-Trunk interface Eth-Trunk 1 port link-type trunk port trunk allow-pass vlan 10 20 interface 40GE1/0/1 eth-trunk 1 interface 40GE1/0/2 eth-trunk 1 # 汇聚层M-LAG域域ID为2 m-lag domain 2 peer-link interface Eth-Trunk 1 keepalive interface MEth0/0/0 interface MEth0/0/0 undo shutdown ip address 10.255.2.1 255.255.255.252 # 下行对接接入层一个Eth-Trunk同时包含去SW-A1和SW-A2的成员口 interface Eth-Trunk 20 mode lacp-static port link-type trunk port trunk allow-pass vlan 10 20 # 40GE1/0/3接SW-A140GE1/0/4接SW-A2 interface 40GE1/0/3 eth-trunk 20 interface 40GE1/0/4 eth-trunk 20 # 下行Eth-Trunk加入M-LAG域 m-lag domain 2 m-lag interface Eth-Trunk 20 # VLANIF网关配合VRRP实现网关双活 interface Vlanif10 ip address 10.1.10.251 255.255.255.0 vrrp vrid 10 virtual-ip 10.1.10.254 vrrp vrid 10 priority 120 interface Vlanif20 ip address 10.1.20.251 255.255.255.0 vrrp vrid 20 virtual-ip 10.1.20.254 vrrp vrid 20 priority 120SW-C2的差异同样在keepalive地址10.255.2.2VLANIF的VRRP优先级保持默认100即可作为backup。网关双活这一版的选型逻辑我单独拎出来说。3.4 网关选型VRRP叠加M-LAG汇聚层做网关华为CE有两种主流做法。一种是M-LAG双活网关两台设备VLANIF配置完全相同的IP依靠M-LAG的ARP/ND表项同步实现跨设备转发配置最精简另一种是VRRP叠加M-LAG每个VLANIF配置不同地址再通过VRRP虚拟IP做网关。我在生产项目里更推荐VRRP叠加M-LAG原因很简单运维对VRRP的认知成本低排障路径清晰而且可以和M-LAG主备角色做联动控制流量模型。M-LAG主设备通常也是VRRP master服务器上行的流量从主设备进下行的流量也尽量从主设备出跨设备绕行的概率降到最低。如果后续想更激进一点等设备软件版本稳定了再考虑迁移到双活网关。两种方式在CE上都能跑但双活网关对版本和功能license有要求建议先确认设备实际情况。3.5 配置顺序为什么这么重要M-LAG配置的顺序问题很多人栽过跟头。我的建议是先配物理接口和VLAN再建peer-link的Eth-Trunk然后配M-LAG域和keepalive最后才把业务口的Eth-Trunk声明为M-LAG成员口。原因不复杂。M-LAG域创建之后两个设备就开始通过peer-link协商和同步了如果peer-link还没起来DOMAIN下的配置可能会反复报错。另外业务口在加入M-LAG之前口字型拓扑里四根互联链路还没有被聚合收敛如果端口已经放通VLAN一旦有广播流量就可能形成临时环路。稳妥的操作是先shutdown所有互联口等M-LAG配置完成后统一undo shutdown让四根链路一次性进入聚合状态。这个细节在割接窗口比较紧张的晚上特别重要能帮你少经历一次配置到一半全网广播风暴的惊魂时刻。4. 验证与故障演练配完之后怎么确认它真的能抗单点4.1 第一轮体检状态检查命令配置完成后先别急着接业务把状态检查过一遍。我在现场的习惯是上设备先敲下面这些命令display m-lag verbose display m-lag interface eth-trunk 11 display eth-trunk 11 display eth-trunk 20 display vrrp brief重点看三件事M-LAG域状态是否正常、peer-link是否up、M-LAG成员口的角色是否已经协商好。display m-lag verbose里能看到主备角色、两端系统MAC是否一致、peer-link和keepalive的状态。如果两端系统MAC不一致说明M-LAG域协商失败大概率是域ID配错或者peer-link没起来。Eth-Trunk的状态也要确认成员口不能有处于Individual状态的端口。LACP聚合最怕出现成员口独立转发那说明对端系统ID没有协商成统一的M-LAG系统ID流量路径会出现意外绕行。4.2 三个故障场景的演练步骤与预期体检通过之后我习惯做三轮故障演练把单点风险逐个打掉。第一个场景是单链路故障。直接把SW-A1到SW-C1的那根光纤拔掉观察服务器到网关的ping是否中断。预期结果是Eth-Trunk 11里少了一个成员口流量从SW-A1到SW-C2的路径走或者经peer-link绕行业务无感。第二个场景是单设备掉电。把SW-A1直接断电模拟整机故障。服务器双网卡bond到A1和A2A1挂了之后所有流量走A2。汇聚侧Eth-Trunk 20里对应A1的成员口down掉剩余链路继续转发ping不掉包。第三个场景也是很多人最担心的——peer-link故障。这个不能直接拔线模拟最好在两台设备之间做物理隔离演练。把SW-C1和SW-C2之间的peer-link断开keepalive保持正常预期结果是优先级低的SW-C2触发MAD Down把除peer-link和keepalive外的业务口全部Error-Down。接入层上连SW-C2的成员口也会被连带down掉流量全部切换到SW-C1路径。这个场景故意制造最恶劣的双主候选条件验证MAD机制真的在干活。4.3 演练中容易发现的隐藏问题演练不是走过场真能在现场查出问题。我可以举一个之前项目里的例子配置完VLANIF和VRRP后第一轮体检发现SW-C1的VRRP状态是master但M-LAG域里SW-C1的角色却是backupM-LAG主备和VRRP主备不一致。这样会导致服务器上行的流量从SW-A1哈希到了SW-C2SW-C2作为VRRP backup收到之后又通过peer-link绕到SW-C1去三层转发白白浪费了peer-link带宽延迟也高。解决办法是调整M-LAG域的优先级强制让主设备和VRRP master落在同一台设备上流量模型就能收敛回来。这种问题不靠故障演练很难暴露业务跑起来也能工作但性能和延迟会在高负载时露出马脚。建议大家配置完务必看一眼主备角色是否对齐。5. 级联M-LAG的常见坑配置顺序、keepalive设计和peer-link带宽5.1 peer-link带宽被忽视的逃生通道peer-link在M-LAG里的角色我前面提过它既传控制面同步报文又承担跨设备业务流量。级联场景下这个问题会被放大接入层A1的流量如果哈希到了对端设备A2或者A1到C1的链路故障后流量绕经A2最终都要靠peer-link转出去。peer-link带宽怎么估一个朴素的经验不要让peer-link成为整条链路的短板建议带宽不小于本端所有业务口带宽总和的30%到50%。如果每个方向业务带宽2Gpeer-link最好按4G到10G准备留出绕行富余量。实际生产环境里peer-link上跑满导致丢包的案例不少问题往往出在流量模型比预期差、局部流量集中绕行。用40GE两根口做peer-link在这个项目里是够用的但如果你下挂的服务器特别多建议再做一次流量模型测算不要拍脑袋。5.2 keepalive和peer-link不能放在同一根绳子上这是M-LAG配置里最经典的一条红线。keepalive链路必须物理上独立于peer-link不能用同一块板卡、同一个中间交换机更不能走同一条光纤。原因就是前面双主检测那段说的peer-link和keepalive同时失效MAD就瞎了双主冲突直接出现。peer-link断了但keepalive还在backup设备会MAD Down缴械不会出大问题但如果两条链路在物理上绑在一起一断俱断两台设备各自为主广播风暴和表项冲突就来了。生产环境里我见过有人图省事把keepalive接口直接放在了peer-link所在的那块线卡上。板卡故障peer-link和keepalive一起没MAD形同虚设。这就是典型的省事省出大事故keepalive链路建议用管理口或独立业务口单独走线物理路径隔离。5.3 两台设备的配置不对称M-LAG要求两台设备对应配置严格对称VLAN、Eth-Trunk编号、链路聚合模式、放通VLAN列表、M-LAG域ID全部要对齐。不对称的配置在平时可能悄无声息但只要触发切换就会出问题。举一个实际遇到的例子接入层SW-A1的Eth-Trunk 11声明为M-LAG成员口了但SW-A2忘了做m-lag interface Eth-Trunk 11。结果平时流量不明显一旦SW-A1故障服务器流量全部hash到SW-A2SW-A2的上联Eth-Trunk 11没有M-LAG关联LACP聚合行为不一致业务直接中断。这种问题用display m-lag interface一眼就能看出两端状态不对称关键还是配置完要多看一眼两侧状态。5.4 STP、VRRP和M-LAG主备的联动M-LAG组网里要不要开STP很多人配置完直接全局关了我不太建议完全关闭。CE在M-LAG场景下对STP做了优化两台M-LAG成员设备对外是一个桥peer-link上的BPDU转发是特殊处理过的M-LAG成员口不会因为冗余链路被STP阻塞。建议的做法是保留STP并把汇聚层两台设备配置为根桥和备份根桥接入层保持默认这样既能防止意外环路又不会误伤M-LAG的双活转发。VRRP和M-LAG主备的联动我在演练那节已经提了核心思路就是让M-LAG master和VRRP master落到同一个设备上避免上下行流量不对称。CE的配置上可以调整M-LAG优先级强制指定master再配合VRRP优先级把主备关系钉死。5.5 升级维护的错峰操作级联M-LAG的维护最忌讳上下两层同时动。接入层和汇聚层各有两台设备A1、A2、C1、C2四台设备升级的时候一定要错峰先把SW-A2升级完确认业务正常再升级SW-A1接入层两台都稳了之后再按同样顺序操作汇聚层。如果上下层交叉升级比如A1和C1同时切到备用设备流量路径会变得很别扭绕行距离和peer-link压力都会异常升高风险不可控。M-LAG单台隔离升级是它的优势但这个优势要建立在严格的操作顺序上。我自己的操作习惯是升级前先display m-lag verbose记录主备角色升级时先升backup一次只动一台每动完一台立刻做一轮连通性测试全部通过才动下一台。最后再分享一个经验M-LAG这种双活架构能不能跑稳一半靠配置一半靠维护规范。配置完成后的第一周建议每天都看一眼display m-lag verbose和接口的错包计数观察有没有异常增长。等到业务跑起来、流量模型稳定之后M-LAG基本就是一个可以忘记它存在的底层能力了——这也是这套方案最迷人的地方。如果正在考虑数据中心网络的冗余改造希望这篇配置示例和排坑记录给你省点时间。