SeigRobotics说实话，M-LAG这个概念我刚接触的时候也绕了一阵子。堆叠、链路聚合、跨设备链路聚合，这些名词放在一起，不看配置真容易混。后来在HCL模拟器里一步步把实验做通，设备起来了、状态正常了、链路拔了业务不丢包，那一刻才是真的理解。这篇文章我把我自己从零开始学习HCL M-LAG配置的全过程整理出来，包括原理、拓扑设计、完整命令、验证方法和几个很容易踩的坑，希望能帮你少走点弯路。适合刚接触M-LAG的人，也适合想在模拟器里复现一遍的人。
1. 为什么我不堆叠，选M-LAG
先聊一个最根本的问题：都有堆叠了，为什么还要搞M-LAG？
我最早学高可用的时候，思路很简单——两台交换机做成堆叠，逻辑上变成一台设备，聚合口一横一竖，既冗余又方便管理。这个思路本身没问题，但真到生产环境里你会发现堆叠有几个让人头大的地方：
第一，升级和维护影响面太大。堆叠系统是统一控制平面，升级往往需要整堆重启，业务连续性直接受影响。哪怕有的厂商支持分批升级，操作复杂度也高。第二，堆叠分裂的故障域太大。一旦堆叠分裂，如果分裂检测做得不好，可能出现双主，两边都在转发，网络里全是广播风暴，这个事故我见过不止一次。第三，堆叠对设备的软件版本、硬件型号要求比较苛刻，混合组网受限。
M-LAG（Multi-Chassis Link Aggregation Group）的思路完全不同。它不追求“让两台设备变成一台”，而是让两台独立的设备对外表现成一台。下层设备（服务器、接入交换机）把两台M-LAG设备看成同一个聚合对端，通过标准的链路聚合协议（LACP或静态聚合）把链路分别连到两台设备上。两台M-LAG设备之间的控制面是独立的，通过专门的协议协商状态、同步表项。
这样做的好处非常明显：
- 升级可以逐台做。先升级一台，流量切到另一台，再升级另一台，业务不断。
- 故障域被隔离了。一台设备挂了，另一台能正常接管，不会出现“脑裂”级别的双双转发。
- 兼容性好。对端设备不用识别M-LAG，它就是普通链路聚合，完全透明。
所以H3C在高端交换机上力推M-LAG，而不是传统堆叠。模拟器里实验M-LAG并不是纸上谈兵，它对应的是真实网络的刚需场景。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. M-LAG的几个核心概念，搞不懂后面必翻车
2.1 Peer-link、Keepalive、M-LAG接口到底各干什么
我见过很多配置文档，一上来就是命令，但看完也不知道为什么要配三个东西。我把这三个角色用大白话拆一下。
Peer-link：两台M-LAG设备之间的数据和控制通道。它承担两件事：第一，同步MAC表项、ARP表项等控制信息；第二，当某台设备的M-LAG接口收到要去对端侧MAC的流量时，通过它转发过去。Peer-link必须是聚合口，不能用单根物理线直接当peer-link，否则没有冗余。配置里要把它设成trunk并放通相关VLAN。
Keepalive：用于检测对端设备是否存活的“心跳线”。Peer-link断了但设备还活着，这种情况靠peer-link本身无法感知，必须靠独立的keepalive链路探测。Keepalive要求三层互通，通常用单独的VLAN接口或带外管理口，绝不能和peer-link走同一条物理路径。
M-LAG接口：这是真正面向业务的聚合接口。两台设备上各有一个聚合组，配置相同的M-LAG编号，对端设备（如接入交换机）把这两条链路当成一个聚合组看待。M-LAG接口背后有DRCP（Distributed Relay Control Protocol）协议在跑，负责两台设备之间的协商和状态同步。
打个比方：Peer-link像两个人之间的“对讲机+快递通道”，Keepalive像“手环监测心跳”，M-LAG接口是“两个人同时握住同一根绳子的一端”。
2.2 主备、双活、双主检测，这些状态怎么理解
M-LAG设备之间并不是简单的“主备”关系。正常工作时，两台设备都转发流量，这叫双活。但两台设备又确实有主备之分——DRCP协商会选出一个主设备，主要作用是处理某些需要唯一决策的协议行为（比如M-LAG接口的LACP协商结果），不代表备设备不转发数据。
真正要重点理解的是双主检测。故障场景是这样的：peer-link断了，但两台设备都还活着。如果没有keepalive，两台设备都会认为对端挂了，都把自己M-LAG接口置为转发状态，结果就是同一批M-LAG接口在两边同时“活着”，对端交换机学到的是两个MAC源，广播帧在双归链路上打环，这就是脑裂。
Keepalive的作用就是在这种场景下“报平安”。当peer-link断开但keepalive仍然正常时，两台设备能通过心跳感知对端存活，然后优先级高的一方保留M-LAG接口，优先级低的一方主动关闭自己的M-LAG接口，保证全网只有一条路径在转发。这就是所谓的双主检测机制。
2.3 流量转发的一个关键原则：本地优先
M-LAG还有一个容易被忽略但很重要的特性：本地优先转发。举个例子，接入交换机SW3双归到SW1和SW2，SW3发过来的流量如果从SW1的M-LAG口进来，且目的MAC在SW1上已经学到，那SW1直接本地转发，不把流量再绕到peer-link上发给SW2。
这个设计的实际意义太大了。如果不做本地优先，打个比方，流量从SW1进来，明明去SW2下挂的服务器，它绕一圈peer-link再出去，浪费了peer-link带宽，还增加转发时延。M-LAG通过MAC表项同步和本地优先规则，保证绝大多数流量走最优路径，peer-link只在跨设备流量（比如目的设备接在另一台M-LAG设备上）时才被用到。
3. HCL环境准备和拓扑设计
3.1 HCL模拟器环境准备，先把设备跑起来
HCL（H3C Cloud Lab）是H3C官方的网络模拟工具，底层靠VirtualBox跑虚拟机镜像。很多人第一步就卡在“设备启动失败”，我拆开来说。
HCL设备启动失败，90%的原因是电脑没有开CPU虚拟化。HCL里的设备镜像都是完整的Comware系统，没有CPU虚拟化支持，虚拟机起不来。解决办法是进BIOS开启Intel VT-x或AMD-V，具体路径各品牌主板不一样，一般是Advanced -> CPU Configuration -> Intel Virtualization Technology，设为Enabled。开完以后，可以在任务管理器“性能”标签里看到“虚拟化：已启用”字样。
第二个常见坑是HCL和EnSP共存时的VirtualBox版本冲突。这两个模拟器对VirtualBox版本的要求不一样，装完EnSP再装HCL，常常出现HCL设备启动时报错。我的经验是：先装HCL，再装EnSP，两个都能用；如果已经冲突了，可以手动升级或降级VirtualBox到HCL要求的版本，别让EnSP覆盖掉HCL需要的VirtualBox核心文件。
第三个坑是HCL软件本身版本太老。老版本HCL里设备型号有限，有些甚至没有M-LAG命令。推荐用HCL 3.0以上版本，里面的S6850交换机默认支持M-LAG，配置命令也全。设备选型上，尽量选S6850而不是S5820V2，前者的模拟器支持更完整。
3.2 实验拓扑和规划
我设计的拓扑是两台M-LAG设备加一台双归接入设备，再加两台PC：
code复制PC1 -- SW3 -- SW1 -- SW2 -- PC2
| |
+--+---+
Peer-link
具体连接关系：
- SW1和SW2：M-LAG对端设备，型号S6850
- SW1的Ten-GigabitEthernet1/0/1 <-> SW2的Ten-GigabitEthernet1/0/1：Peer-link链路，做聚合口Bridge-Aggregation 1
- SW1的GigabitEthernet1/0/1 <-> SW2的GigabitEthernet1/0/1：Keepalive链路，用于三层心跳，VLAN 4000
- SW3：接入交换机，双归连接到SW1和SW2的Ten-GigabitEthernet1/0/2，构成M-LAG聚合组
- PC1 接到SW3的GigabitEthernet1/0/1，PC2 接到SW2的Ten-GigabitEthernet1/0/3
VLAN和IP规划：
| 项目 | 值 | 说明 |
|---|---|---|
| 业务VLAN | VLAN 10 | PC1和PC2都在此VLAN |
| Keepalive VLAN | VLAN 4000 | 仅用于SW1/SW2心跳 |
| SW1 Keepalive IP | 10.0.0.1/30 | Vlan-interface 4000 |
| SW2 Keepalive IP | 10.0.0.2/30 | Vlan-interface 4000 |
| Peer-link聚合口 | Bridge-Aggregation 1 | Trunk，放通VLAN 10 |
| M-LAG聚合口 | Bridge-Aggregation 10 | Trunk，放通VLAN 10，M-LAG ID 1 |
| PC1 IP | 192.168.10.1/24 | 网关不用配（二层实验） |
| PC2 IP | 192.168.10.2/24 | 网关不用配（二层实验） |
这个拓扑覆盖了M-LAG最核心的场景：SW3作为双归接入设备，链路聚合到两台M-LAG设备，PC1到PC2的流量会经过M-LAG转发，拔任意一条上行链路都能验证切换。
4. 配置实操：从SW1到SW3完整命令
4.1 SW1的完整配置
先登录SW1，配置设备名称、VLAN、Keepalive地址、Peer-link聚合口、M-LAG接口，最后把物理口加进对应聚合组。
code复制system-view
sysname SW1
vlan 10
vlan 4000
interface Vlan-interface 4000
ip address 10.0.0.1 255.255.255.252
quit
interface Bridge-Aggregation 1
port link-type trunk
port trunk permit vlan all
m-lag peer-link
quit
interface Bridge-Aggregation 10
port link-type trunk
port trunk permit vlan 10
m-lag 1
quit
interface Ten-GigabitEthernet1/0/1
port link-aggregation group 1
quit
interface Ten-GigabitEthernet1/0/2
port link-aggregation group 10
quit
interface GigabitEthernet1/0/1
port access vlan 4000
quit
m-lag keepalive ip address 10.0.0.2 10.0.0.1
重点解释几个命令：
m-lag peer-link 是加在Bridge-Aggregation 1上的，告诉设备这个聚合口是M-LAG的Peer-link链路。Peer-link必须是聚合口，不能是物理口直接配。这一段我踩过坑，后面会细说。
m-lag 1 是加在Bridge-Aggregation 10上的，这是M-LAG接口编号。两台设备上M-LAG ID必须一致，SW1配1，SW2也要配1，否则DRCP协商不起来。
m-lag keepalive ip address 10.0.0.2 10.0.0.1 这条命令的语法在不同Comware版本上略有差异。我实验用的HCL 3.0+S6850版本，第一个IP是对端地址，第二个IP是本端源地址。如果你在设备上敲命令时提示语法不对，用m-lag keepalive ?看在线帮助，不同版本参数顺序确实变过。
4.2 SW2的完整配置
SW2和SW1大体相同，只是Keepalive地址对调，另外多一个接PC2的接口。
code复制system-view
sysname SW2
vlan 10
vlan 4000
interface Vlan-interface 4000
ip address 10.0.0.2 255.255.255.252
quit
interface Bridge-Aggregation 1
port link-type trunk
port trunk permit vlan all
m-lag peer-link
quit
interface Bridge-Aggregation 10
port link-type trunk
port trunk permit vlan 10
m-lag 1
quit
interface Ten-GigabitEthernet1/0/1
port link-aggregation group 1
quit
interface Ten-GigabitEthernet1/0/2
port link-aggregation group 10
quit
interface Ten-GigabitEthernet1/0/3
port access vlan 10
quit
interface GigabitEthernet1/0/1
port access vlan 4000
quit
m-lag keepalive ip address 10.0.0.1 10.0.0.2
SW2的Ten-GigabitEthernet1/0/3我用来接PC2，这里用了一个普通access口，不属于M-LAG聚合组。这个设计的目的是让PC2的MAC地址在SW2上学习，再通过M-LAG机制同步到SW1，这样就能验证跨设备MAC同步。
4.3 SW3的配置
SW3是普通的接入交换机，双归到SW1和SW2。它本身不感知M-LAG，只需要正常配置链路聚合，把Ten-GigabitEthernet1/0/1和Ten-GigabitEthernet1/0/2做成一个聚合口。这就是M-LAG“透明”特性的体现。
code复制system-view
sysname SW3
vlan 10
interface Bridge-Aggregation 10
port link-type trunk
port trunk permit vlan 10
quit
interface Ten-GigabitEthernet1/0/1
port link-aggregation group 10
quit
interface Ten-GigabitEthernet1/0/2
port link-aggregation group 10
quit
interface GigabitEthernet1/0/1
port access vlan 10
quit
SW3上不需要配任何M-LAG命令。它看到的就是一个普通的聚合口，两条上行链路分别是到SW1和SW2的物理链路，聚合口协议协商正常后，SW3就认为对端是一个完整的聚合系统。这正是M-LAG对下游设备友好的核心原因。
4.4 配置时的几个关键检查点
配置完先不要急着做验证，先自查几个地方：
- Peer-link聚合口必须放通所有需要的VLAN，我直接用了
port trunk permit vlan all，实验环境无所谓，生产环境建议按需放通。 - M-LAG接口（Bridge-Aggregation 10）两端的M-LAG ID要一致，配成
m-lag 1。 - Keepalive的VLAN、IP、路由要通，最简单的确认方式是SW1能ping通10.0.0.2，SW2能ping通10.0.0.1。如果ping不通，后面DRCP协商可能正常但双主检测是失效的，相当于埋雷。
- 两台设备的系统MAC不能一样，模拟器里不同设备默认不同，不用额外改。
5. 验证和故障模拟：看它到底好使不好使
5.1 状态查看命令
配置完成后，用display命令确认M-LAG状态：
display m-lag summary：看M-LAG的总体状态，包括Peer-link是否up、Keepalive是否正常、M-LAG接口是否激活。display m-lag verbose：看详细的DRCP协商信息，包括主备角色、peer-link状态、keepalive状态。display m-lag keepalive：只看keepalive的详细信息，比如最近一次心跳时间、收到的报文数。display link-aggregation verbose：看聚合口成员状态、对端系统ID。SW3上看到的两台M-LAG设备对外一致，就是一个系统ID（DRCP系统ID）。
我自己实验时，SW1上执行display m-lag summary的输出关键信息大致是：
code复制M-LAG group information:
ID Interface Status
1 Bridge-Aggregation 10 Active
Peer-link:
Interface Status
Bridge-Aggregation 1 Up
Keepalive:
Status: Up
看到Status为Active和Up，说明M-LAG已经正常建起来了。
5.2 连通性测试和拔线验证
先给PC1和PC2配好IP：PC1设192.168.10.1/24，PC2设192.168.10.2/24。在PC1上持续ping PC2：
code复制ping 192.168.10.2 -t
正常情况下延时稳定，不丢包。然后开始拔线。
拔掉SW3与SW1之间的物理链路。此时SW3的聚合口里只剩SW2一条链路，所有双归流量从SW2走。观察PC1的ping，理论上会有极短暂的丢包（聚合组感知链路变化的时间），之后恢复，最终能ping通。这个验证的核心点是：两台M-LAG设备对外是一条逻辑链路，断了一条物理链路，剩下的链路继续工作。
恢复SW3与SW1的链路，拔掉SW3与SW2的链路。重复上面的操作，结果类似。
更狠一点的测试：直接在SW1上执行interface Bridge-Aggregation 10 shutdown。这相当于SW1把整个M-LAG接口关掉，SW3会感知到SW1侧的聚合成员down，把所有流量发给SW2。PC1 ping PC2同样应该基本不丢包。这个测试模拟的是一台M-LAG设备本地故障，比单纯拔线更彻底。
MAC同步的验证：在SW1上执行display mac-address vlan 10，正常情况下能看到PC2的MAC地址。如果PC2的MAC只是在SW2上学到，SW1上通过M-LAG同步机制也能学到，这条表项会标记为M-LAG同步类型。这就是前面说的跨设备MAC同步。
5.3 脑裂场景模拟：拔掉Peer-link但Keepalive正常
这条操作比较刺激，建议在理解清楚原理后再做。
在SW1上把Peer-link的物理口shutdown，即interface Ten-GigabitEthernet1/0/1 shutdown，此时peer-link断了，但keepalive链路（GE口）还正常。
观察SW1和SW2上的状态，你会看到双主检测机制触发：两台设备通过keepalive感知到对端还活着，于是优先级高的一方（默认按系统MAC和优先级比较）保留M-LAG接口为Active，另一方把自己的M-LAG接口置为Inactive。这样整个网络不会出现两边同时发流量的脑裂状态。
我在实验里看到的现象是，SW1的M-LAG接口状态变为Inactive，display m-lag summary里能看到状态变化，同时日志里有双主检测的告警。恢复物理链路后，DRCP重新协商，M-LAG接口恢复Active。
这个实验非常有价值，它解释了为什么M-LAG必须同时保留两条物理通道——peer-link传数据，keepalive报心跳，缺一不可。
6. 我踩过的坑和排查思路
6.1 HCL设备和M-LAG状态常见的“不工作”原因
配置照着文档敲完了，M-LAG状态起不来，这种情况我遇到最多次，几乎都是以下几类原因：
Peer-link没起。 如果Peer-link聚合口没起来，M-LAG是绝对协商不成功的。确认方法是display link-aggregation verbose看Bridge-Aggregation 1的成员口是否有Selected端口。如果成员口状态是Unselected，先查物理口是否真的up，再查两端的trunk配置是否一致（permit的VLAN必须匹配）。
Keepalive地址不通。 有两次我以为配置对了，结果display m-lag keepalive显示状态异常，排查后发现是VLAN 4000的access口配置漏了，或者Vlan-interface 4000的IP配错了。Keepalive必须三层互通，最简单的测试是在SW1上ping SW2的10.0.0.2，通了再继续。
两台设备M-LAG ID不一致。 我自己就犯过这个错，SW1上配了m-lag 1，SW2上顺手配了m-lag 2，结果DRCP一直在那协商但状态起不来。排查了半天才发现是这种低级错误。记住：M-LAG ID是两台设备之间的约定，不是本端唯一的编号，两端必须一模一样。
HCL设备型号不支持。 如果你用的是HCL老版本或者选了不支持的设备型号，命令可能都敲不进去。建议直接选S6850，HCL 3.0官方明确支持。
6.2 故障排查的完整思路
我在调试时习惯按下面这个顺序排查：
先看M-LAG的整体状态，display m-lag summary。如果Peer-link显示Down，先查聚合口物理链路和trunk配置；如果Keepalive显示异常，先ping对端keepalive地址；如果M-LAG接口显示Inactive，看日志里有没有双主检测的记录。
再往下查明细，display m-lag verbose看DRCP协商信息。重点看M-LAG接口两端的状态和角色，如果一直处于协商状态，多半是两台设备之间的版本不一致或者M-LAG ID不匹配。
最后看底层链路，display link-aggregation verbose确认聚合口成员状态。M-LAG接口对下游设备相当于一个聚合组，如果聚合组里有成员口不是Selected，链路聚合本身就有问题，M-LAG当然跑不起来。
6.3 配置自查清单
把所有容易出错的地方整理成清单，复盘用：
| 检查项 | 正确配置 |
|---|---|
| Peer-link物理口 | 已加入Bridge-Aggregation 1 |
| Peer-link聚合口 | 已配置m-lag peer-link，trunk放通VLAN |
| Keepalive地址 | SW1 10.0.0.1/30，SW2 10.0.0.2/30，三层互通 |
| Keepalive物理口 | GE口加入VLAN 4000 |
| M-LAG ID | 两台设备均为m-lag 1 |
| M-LAG聚合口 | Bridge-Aggregation 10放通VLAN 10 |
| 下游设备聚合 | SW3聚合口正常，成员口为Selected |
7. 写在最后的一点经验
M-LAG我学了几轮才算真正吃透，最大的体会是：不要急着敲命令，先把Peer-link、Keepalive、M-LAG接口这三个角色的关系搞明白，配置只是最后一步的动作。模拟器里不用怕故障模拟，放心大胆拔线、shutdown接口，只有亲眼看到流量切换和双主检测的过程，你才能真正理解M-LAG设计时的良苦用心。这个实验做完以后，我建议你可以再往上叠加一层VRRP或者三层网关场景，让整个双活网关的链路更完整。我后续在HCL里继续折腾三层M-LAG网关的时候，再回来更新一篇。