华为CE交换机级联M-LAG配置实战：从原理到故障排查

搞数据中心网络的都知道，M-LAG这名字天天都能听到，但"级联M-LAG"这个玩法，真到配置的时候还是有不少细节容易翻车。前阵子我刚好给一个互联网公司做了一套华为CE系列交换机的数据中心网络改造，核心需求就是：两台CE做主备双活，下面还要级联接入层，整网做到链路冗余、故障不倒换，业务零感知。这篇文章把这次项目的完整配置示例、设计思路、踩坑过程和验证手段全部整理出来，给正在搞华为CE交换机M-LAG的朋友一个可以直接抄作业的参考。适合刚接触M-LAG的网络工程师、数据中心运维，以及从传统STP+VRRP组网想切到M-LAG架构的同行。

1. 先搞懂级联M-LAG到底是什么

1.1 一次把M-LAG的核心组件说清楚

M-LAG全称是Multi-Chassis Link Aggregation，翻译过来就是跨设备链路聚合。它解决的核心问题很朴素：传统链路聚合（Eth-Trunk）只能把同一台交换机上的多个物理口捆绑成一个逻辑口，一旦这台交换机整机挂了，聚合链路就全废了。M-LAG允许你把两台独立的交换机虚拟成一台"逻辑设备"，服务器的双网卡可以跨在两台交换机上做绑定，任何一台交换机挂了，流量自动从另一台走，服务器根本感知不到链路变化。

在华为CE系列上，M-LAG体系里有三个关键角色：

• DFS Group：分布式转发集群，负责在两台设备之间同步M-LAG状态、MAC表项、ARP表项。你可以把它理解成两台设备的"大脑连接线"，所有M-LAG成员口的状态都要靠它在设备间对齐。
• Peer-link：设备间的互联链路，承载两台设备之间的数据流量转发和DFS控制报文。这条链路必须用Eth-Trunk承载，不能是单根物理线，并且带宽要留足，否则故障切换时跨设备流量会把这条链路打爆。
• Keepalive心跳检测：双主检测链路，用普通三层接口（建议用管理口）互联，走独立IP。它不传数据，只传心跳报文。一旦peer-link挂了，两台设备靠keepalive判断对端是不是还活着，如果心跳也断了，系统就会认为发生了双主故障，自动把备设备的M-LAG成员口shutdown，防止两台设备同时往外发流量造成广播风暴。

这三个组件缺一不可，配置顺序也很有讲究，后面实操部分我会详细说。

1.2 什么叫"级联"，它解决什么场景

"级联M-LAG"其实不是华为官方文档里的标准术语，而是我们做项目时对一种常见组网架构的俗称。我理解的核心意思是：上层两台CE交换机组成一套M-LAG系统，下层接入交换机（可以是一台普通交换机，也可以再组成一套M-LAG）通过跨设备聚合链路接到上层M-LAG上，形成一种层级化的双活接入架构。

这里有个容易迷糊的点：级联和普通的"M-LAG下挂交换机"不一样。普通M-LAG场景是两台交换机上联核心、下挂服务器的标准接入层组网；级联M-LAG则是把M-LAG当作中间汇聚层，上面再接核心层，下面再接接入层，上下都要做跨设备链路聚合。这种架构在中等规模数据中心很常见，因为服务器数量多、接入交换机数量也多，不可能让所有服务器都直接接到核心M-LAG上，必须把接入层也做双活，形成"核心-汇聚-接入"三级架构。

我这次的项目就是这种模式：两台核心CE交换机组成M-LAG，两台汇聚CE交换机再组成另一套M-LAG，汇聚层向上和核心层级联做跨设备Eth-Trunk，向下接机架顶交换机（TOR），TOR通过双上联分别接到两台汇聚交换机。这样任意一台汇聚交换机故障、任意一条上联链路故障，服务器侧的网络都不中断。

1.3 为什么选M-LAG而不是堆叠

很多朋友第一反应是：华为CE不是支持堆叠（iStack）吗？做成一台堆叠设备不是更省事？确实，堆叠在中小网络里很常见，但数据中心核心层我强烈不建议用堆叠，原因有三个：

• 升级爆炸半径大。堆叠系统里两台设备是一体的，升级固件时整个堆叠系统要一起重启，核心设备一重启，全网都受影响。M-LAG是控制面各自独立的，可以一台一台升级，备机顶住流量，业务零中断。
• 跨设备链路利用率低。堆叠虽然可以把两台设备的接口聚合成一个Eth-Trunk，但同一时刻数据转发路径是确定的，流量往往集中在主设备上，做不到真正的负载分担。M-LAG通过哈希算法让两台设备都能转发流量，利用率更高。
• 排障困难。堆叠系统里两台设备状态强耦合，出了问题分不清是哪台设备导致的；M-LAG两台设备状态清晰，通过一条display dfs-group就能看到主备状态和同步情况，定位快得多。

所以在数据中心这种对可用性要求极高的场景，我个人的习惯是：优先M-LAG，能不堆叠就不堆叠。

2. 组网拓扑与设计方案拆解

2.1 典型两级M-LAG拓扑

先看我这次项目最终落地的拓扑，我画成文字描述，大家理解一下：

code复制核心层：CE-A ---------- peer-link ---------- CE-B
              \              /                  /
               \            /                  /
汇聚层：CE-C ---------- peer-link ---------- CE-D
              \        /        \         /
               \      /          \       /
接入层：TOR-1               TOR-2
           |   \              /   |
        服务器-1          服务器-2

具体细节是：

• 核心层：两台CE6851（A、B）组成M-LAG系统，向上通过OSPF连接上层防火墙/出口路由器，向下和汇聚层级联。
• 汇聚层：另外两台CE6851（C、D）组成独立的M-LAG系统，向上分别接到核心的CE-A和CE-B，向下接TOR。
• 接入层：两台TOR交换机不做M-LAG，但每台TOR分别双上联到汇聚的CE-C和CE-D，形成普通链路聚合与M-LAG对接。
• 服务器：双网卡做bonding，分别接到两台TOR上。

这里最关键的是汇聚层和核心层之间的级联链路：汇聚CE-C上联核心CE-A的链路、CE-D上联核心CE-B的链路，各自都做成Eth-Trunk，但这两条Eth-Trunk分别作为各自M-LAG系统的成员口。注意，这不是把汇聚的两条上联捆绑成一个Eth-Trunk，而是两个M-LAG系统的成员口分别对接，通过LACP协商形成跨设备链路。

2.2 VLAN与IP规划

规划做得好，后面配置能省一半的时间。我这次项目的VLAN和IP规划如下：

网关放在汇聚层，这是数据中心很经典的做法：服务器网关离服务器近，二层广播域只在接入和汇聚之间，核心层全部跑三层路由，避免了二层网络过大带来的广播风暴和MAC表膨胀。

2.3 关键设计取舍：peer-link带宽、keepalive链路、网关位置

这块是我每次做M-LAG都要反复跟客户强调的，因为设计阶段不重视，后期多花三倍精力都补不回来。

• Peer-link带宽往大里给。M-LAG的peer-link不仅传控制报文，还承载跨设备流量。比如服务器A挂在TOR-1上，TOR-1单归到汇聚CE-C，但服务器A的流量要发往网关（在汇聚层），而网关的MAC地址可能学习在CE-D上，这时候报文就要经过peer-link从CE-C转发到CE-D。所以Peer-link建议至少用40GE，两台设备之间至少两根捆绑，我这次项目直接用4根40GE。
• Keepalive链路物理隔离，别省口子。Keepalive用的是IP报文，逻辑上完全独立于peer-link。很多人在测试环境把keepalive的源地址配在业务VLANIF下，或者跟peer-link共用物理链路，实战中peer-link一断，keepalive也断，M-LAG直接判定双主故障，把备机所有M-LAG成员口都给shutdown，业务大面积中断。正确做法是用管理口（MEth0/0/0）或者独立的物理接口，直连两台设备。
• 网关位置决定三层转发效率。这次项目把服务器网关放在汇聚层，核心只跑路由。这样服务器之间的互访流量在汇聚层就能完成三层转发，不需要绕到核心；如果网关放在核心层，二层域就要扩展到汇聚和接入，peer-link的流量会成倍增加，排查问题也更难。

3. 配置实操：从接口到完整业务下发

3.1 安装前的公共配置

华为CE系列交换机配置M-LAG，核心是让两台设备之间建立起信任关系。第一步先把系统参数、接口基础配置搞定。

以核心层CE-A为例，登录设备后先刷基础配置：

code复制<CE-A> system-view
[CE-A] sysname CE-A
[CE-A] vlan batch 100 200 4000
[CE-A] interface Eth-Trunk 10
[CE-A-Eth-Trunk10] mode lacp-static
[CE-A-Eth-Trunk10] trunkport 40GE1/0/1
[CE-A-Eth-Trunk10] trunkport 40GE1/0/2
[CE-A-Eth-Trunk10] quit

注意这里的Eth-Trunk 10是给peer-link用的，先创建聚合口、把物理口加进来、指定LACP模式。按华为CE的标准要求，peer-link必须是LACP模式，不能是手工模式，原因在于手工模式Eth-Trunk不带LACP报文，两台设备无法通过协议协商来同步成员口状态。

CE-B上的配置完全对称，只是接口编号对应各自的物理口。

3.2 DFS Group配置：让两台设备建立信任

这是M-LAG配置里最核心的一步，顺序绝对不能乱。我的实际操作顺序是：先配置DFS Group，再配置M-LAG绑定，最后配置Keepalive的IP。

code复制[CE-A] dfs-group 1
[CE-A-dfs-group-1] m-lag peer-link interface Eth-Trunk 10
[CE-A-dfs-group-1] m-lag bind interface Eth-Trunk 1
[CE-A-dfs-group-1] dual-active detection source ip 10.10.255.1 peer ip 10.10.255.2
[CE-A-dfs-group-1] quit

这里解释一下每条命令的作用：

• dfs-group 1创建DFS组，两台设备的DFS组编号必须一致，否则无法协商。
• m-lag peer-link interface Eth-Trunk 10把刚才创建的Eth-Trunk 10指定为peer-link接口，务必在创建M-LAG成员口之前先指定。
• m-lag bind interface Eth-Trunk 1把自己设备上的Eth-Trunk 1（这个接口暂时还没有任何物理口，只是个空壳）绑定为M-LAG成员口。

这里有个重要概念：Eth-Trunk 1在M-LAG架构里是逻辑M-LAG成员口，它里面的物理口可以分布在两台设备上，但对端（汇聚交换机或TOR）看到的是一根逻辑链路。所以CE-A和CE-B的Eth-Trunk 1编号必须一致，并且通过DFS组协商后，两个设备上的Eth-Trunk 1会被虚拟成一个Eth-Trunk。

• dual-active detection source ip 10.10.255.1 peer ip 10.10.255.2，这是我用管理口互联的keepalive地址。注意源地址是本机管理口地址，对端地址是对端管理口地址。

如果设备版本较旧，DFS Group视图下的命令可能有差异，例如部分是peer-link Eth-Trunk 10和bind M-LAG Eth-Trunk 1写法，具体以当时版本的命令参考为准，功能一样。

CE-B上的DFS Group配置对称，但源IP和对端IP要反过来：

code复制[CE-B] dfs-group 1
[CE-B-dfs-group-1] m-lag peer-link interface Eth-Trunk 10
[CE-B-dfs-group-1] m-lag bind interface Eth-Trunk 1
[CE-B-dfs-group-1] dual-active detection source ip 10.10.255.2 peer ip 10.10.255.1
[CE-B-dfs-group-1] quit

3.3 M-LAG成员口配置与业务VLAN下发

DFS组建立之后，开始配置M-LAG成员口，也就是面向汇聚层设备的跨设备聚合口。

在CE-A上把物理口加入Eth-Trunk 1，并指定M-LAG属性：

code复制[CE-A] interface Eth-Trunk 1
[CE-A-Eth-Trunk1] mode lacp-static
[CE-A-Eth-Trunk1] lacp m-lag 1
[CE-A-Eth-Trunk1] trunkport 10GE1/0/1
[CE-A-Eth-Trunk1] trunkport 10GE1/0/2
[CE-A-Eth-Trunk1] port link-type trunk
[CE-A-Eth-Trunk1] port trunk allow-pass vlan 100 200 4000
[CE-A-Eth-Trunk1] quit

仔细看，lacp m-lag 1就是Eth-Trunk 1作为M-LAG成员口的核心命令。这个1是M-LAG ID，两台设备上同一个M-LAG组对应的ID必须一致，并且要和DFS Group里m-lag bind interface Eth-Trunk 1的Eth-Trunk号对应。

很多人初次配置时容易漏了lacp m-lag 1，结果Eth-Trunk 1还是普通聚合口，两台设备各自独立发LACP报文，对端设备看到的却是两个不同的邻居系统，根本协商不起来。这里我再强调一次：M-LAG成员口的Eth-Trunk上必须配置lacp m-lag，普通Eth-Trunk不允许。

Peer-link接口上也要放通业务VLAN，因为跨设备流量要经过peer-link转发：

code复制[CE-A] interface Eth-Trunk 10
[CE-A-Eth-Trunk10] port link-type trunk
[CE-A-Eth-Trunk10] port trunk allow-pass vlan 100 200
[CE-A-Eth-Trunk10] port trunk pvid vlan 4000
[CE-A-Eth-Trunk10] quit

这里我把peer-link的PVID设置为VLAN 4000，好处是如果某些报文不带VLAN标签进来，会被归类到互联VLAN，不会误入业务VLAN。

CE-B上的配置完全对称，但要注意CE-B的Eth-Trunk 1里的物理口编号是CE-B自己的接口，别写成CE-A的接口号。

3.4 汇聚层M-LAG的对称配置

汇聚层CE-C和CE-D的配置思路和核心层一模一样，只是设备编号、接口编号不同。我不重复贴命令，讲几个容易出错的地方。

• 汇聚层向上级联核心层时，CE-C上联核心CE-A的接口和CE-D上联核心CE-B的接口，分别加入自己设备的Eth-Trunk 1（M-LAG成员口）。因为CE-C和CE-D组成另一套M-LAG，所以对核心层的M-LAG来说，它看到的是汇聚层这个"虚拟设备"跟自己协商，两个M-LAG系统的peer-link完全独立，互不干扰。
• 汇聚层向下接TOR时，TOR是做普通Eth-Trunk还是也做M-LAG，取决于TOR是否支持M-LAG。如果TOR只是普通交换机，那就把TOR的双上联做成普通Eth-Trunk，汇聚侧的接口也做成普通Eth-Trunk，两边都是Eth-Trunk对接，物理上是两台汇聚设备分别出线，逻辑上却是一根Eth-Trunk。

这里我要提醒一下：服务器双网卡绑定（bonding）和TOR之间的配合也决定了级联M-LAG能不能真正实现双活。服务器bonding推荐用mode 4（LACP），TOR上做动态聚合，服务器发出的报文通过LACP协商分担到两个物理网卡上；TOR到汇聚层的链路再做跨设备聚合，这样任何一个环节故障都能自动收敛。

3.5 级联对接时的Trunk放通与STP避坑

级联M-LAG最容易出问题的就是VLAN放通不一致，以及STP（生成树）导致的阻塞。

我这次项目里，从核心到汇聚、从汇聚到TOR，所有Trunk链路都得放通业务VLAN，我习惯把需要用到的业务VLAN统一列出来，一次性写进所有涉及级联的Trunk接口：

code复制[CE-C] interface Eth-Trunk 1
[CE-C-Eth-Trunk1] port trunk allow-pass vlan 100 200
[CE-C-Eth-Trunk1] quit

至于STP，M-LAG设备之间建议关闭STP，或者在M-LAG成员口上直接配置边缘端口。原因很简单：M-LAG本身就是双活架构，它已经通过跨设备聚合消除了二层环路，再跑STP只会增加收敛时间。如果你在M-LAG环境下接入了一台新设备、不小心把两根线都接到了同一台M-LAG设备上，STP就可能把其中一条链路阻塞掉，导致实际只有一条链路在转发，与M-LAG的双活设计背道而驰。

如果一定要启用STP（比如级联之下还有老交换机组成环网），记得把M-LAG成员口配置为边缘端口并开启BPDU保护：

code复制[CE-A-Eth-Trunk1] stp edged-port enable
[CE-A-Eth-Trunk1] stp bpdu-protection

3.6 三层网关配置与上行路由

M-LAG二层配置完成后，服务器网关配置在汇聚层。这里有两个方案：VRRP和直接VLANIF。

我这次用的是VRRP+M-LAG的组合。汇聚CE-C和CE-D上分别配置VTEP?不，不涉及VXLAN，就是普通VRRP：

code复制[CE-C] interface Vlanif 100
[CE-C-Vlanif100] ip address 10.10.100.253 255.255.255.0
[CE-C-Vlanif100] vrrp vrid 100 virtual-ip 10.10.100.254
[CE-C-Vlanif100] vrrp vrid 100 priority 120
[CE-C-Vlanif100] quit

code复制[CE-D] interface Vlanif 100
[CE-D-Vlanif100] ip address 10.10.100.252 255.255.255.0
[CE-D-Vlanif100] vrrp vrid 100 virtual-ip 10.10.100.254
[CE-D-Vlanif100] vrrp vrid 100 priority 100
[CE-D-Vlanif100] quit

VRRP的职责只是提供一个虚拟网关IP，不是决定数据转发路径。M-LAG架构下，CE-C和CE-D都是双活转发，VRRP主备不会影响二层报文的负载分担。我这边把CE-C设为VRRP主设备，并不代表所有流量都走CE-C，服务器发上来的二层报文会根据M-LAG的哈希算法负载分担到两台汇聚设备上。

汇聚到核心的三层互联，我直接用物理口子接口或者VLANIF，配一个/30的互联地址，然后跑OSPF：

code复制[CE-C] interface 10GE2/0/1
[CE-C-10GE2/0/1] undo portswitch
[CE-C-10GE2/0/1] ip address 10.10.254.1 255.255.255.252
[CE-C-10GE2/0/1] quit
[CE-C] ospf 1
[CE-C-ospf-1] area 0.0.0.0
[CE-C-ospf-1-area-0.0.0.0] network 10.10.0.0 0.0.255.255
[CE-C-ospf-1-area-0.0.0.0] quit

汇聚层的默认路由指向核心，核心上配置回程路由指向汇聚。如果希望汇聚层故障时路由能自动收敛，建议在汇聚和核心之间用OSPF，发布各自的业务网段和互联网段，这样无论哪台汇聚交换机故障，核心都能在秒级内切换到另一台的路径。

4. 关键验证命令与转发行为解读

4.1 从display命令看M-LAG工作状态

配置做完别急着验收，先把状态看一遍。我每次做M-LAG项目，验证命令是固定的三板斧。

第一板斧，看DFS组状态：

code复制display dfs-group 1

正常状态下，能看到两边的DFS组ID一样、状态是Stable或者Up，以及peer-link链路状态。如果状态是Error或者Down，说明peer-link没有协商成功，排查一下链路和接口。

第二板斧，看M-LAG整体汇总：

code复制display m-lag summary

这里能看到M-LAG ID、状态、绑定的Eth-Trunk号。重点关注Status列是不是Up。如果某个M-LAG成员口的状态是Down，说明这个接口对应的物理链路有问题，或者对端设备没有同步好M-LAG配置。

第三板斧，看Eth-Trunk的LACP协商结果：

code复制display eth-trunk 1

能看到Eth-Trunk 1里面有哪些成员口、每个成员口的状态是否是Selected。M-LAG环境下，两台设备的Eth-Trunk 1成员口最终会协商成一个逻辑口。如果看到某个口是Unselected，说明LACP协商有问题，优先检查两边的模式是否一致、M-LAG ID是否一致。

4.2 故障切换的几种场景演练

配置验证通过后，我习惯拉着现场同事一起做一轮故障演练，真刀真枪把链路拔了看切换效果。演练场景和预期结果大概是：

• 拔掉CE-C到核心的上联链路。预期：核心层CE-A继续正常工作，CE-D继续正常工作，汇聚层的跨设备链路会把流量引导到CE-D上，服务器业务无感知。
• 拔掉CE-C和CE-D之间的peer-link。预期：两台设备通过keepalive检测到peer-link故障，系统进入双主抑制状态，其中一台设备的M-LAG成员口被自动shutdown，业务全走健康设备，防止广播风暴。这个场景最能检验keepalive链路是否可靠。
• 直接给CE-C断电。预期：CE-D接管全部业务，服务器因为双网卡bonding，报文无缝切换到CE-D，业务中断时间在毫秒级。
• 插拔级联链路中一条物理线。预期：Eth-Trunk内成员口重新哈希，流量自动负载到其他成员口，不会产生丢包。

我这次项目做完这些演练后，把每轮的切换时间和丢包情况记录在案，作为验收报告的一部分。

5. 典型故障与排查实录

5.1 peer-link故障引发接口批量shutdown

这个故障我遇到过不止一次。客户报障说"M-LAG设备的接口全部down了"，登录设备一看，M-LAG成员口显示为Error-Down状态。

排查步骤很清晰：先看display dfs-group，看到peer-link状态Down；再看keepalive的连通性，发现管理口之间也ping不通。原因是客户把keepalive的管理口物理链路和peer-link绑在了同一根光纤的同一批接口下，一旦物理链路中断，peer-link和keepalive同时失效，M-LAG判定双主，直接把备机的M-LAG成员口全部shutdown来保护网络。

这种故障的恢复方法很简单，把物理链路修好，等peer-link恢复，再在设备上用undo shutdown把M-LAG成员口拉起即可。但治本的方法还是把keepalive链路物理隔离，别跟peer-link放在一起。

5.2 keepalive误判导致双主

还有一次，两台设备的keepalive配置没问题，管理口也通了，但M-LAG成员口还是经常被shutdown。后来一看，原因是管理口的IP地址配置在了业务网段里，网关指到了汇聚交换机上，汇聚交换机又把报文转发回了M-LAG设备，形成环路，keepalive报文在环路里反复绕，收发异常，导致误判。

这个问题的解决方法是：keepalive互联用一个私有的独立网段，比如30位掩码的/30地址，不上送到任何路由协议，也不在汇聚交换机上做转发。管理口本身就是带外管理口，完全不需要和业务平面有任何交集。

5.3 级联场景流量黑洞案例

这台网络改造接近尾声时，出现过一次"某些服务器通、某些服务器不通"的问题。排查了很久，最后发现是汇聚层两台设备的M-LAG成员口上放通的VLAN列表不一致。CE-C放通了VLAN 100和200，CE-D只放通了VLAN 100，结果VLAN 200的服务器流量哈希到CE-D时，直接被丢弃。

这个问题的排查技巧是：通过display interface Eth-Trunk 1分别查看两台设备的允许VLAN列表，逐项比对，不要想当然认为两台设备配一样的命令就行。配置脚本最好用相同的模板生成，避免手工敲命令时漏了某条。

5.4 常见问题速查表

我把M-LAG配置和运维中常见的坑整理成下面这个表，大家可以直接收藏备用：

6. 实操心得与避坑建议

6.1 配置顺序与版本选择

M-LAG配置的顺序我再说一遍，这个顺序是经过多次项目验证的：先创建Eth-Trunk并指定为LACP模式，再配置DFS Group，在DFS Group里指定peer-link，然后绑定M-LAG成员口，最后配置keepalive地址。这个顺序能避免很多莫名其妙的报错。

版本选择方面，华为CE系列交换机的M-LAG功能从V200R002开始就比较成熟，到V200R005以后命令体系基本稳定。我这次项目用的CE6851，固件版本是V200R005C20SPC607，整体很稳。如果设备型号较老，建议先升级到一个较新的V200R0xx版本再开局，老版本M-LAG的bug相对多一些，比如某些版本在特定场景下M-LAG成员口恢复慢。

6.2 上线前的检查清单

我每次M-LAG项目上线前，都会照着下面这个清单过一遍，避免漏项：

• 两台设备DFS Group编号一致
• Peer-link接口均为LACP模式，且放通所有业务VLAN
• Keepalive地址使用独立管理口，不通告给路由协议
• M-LAG成员口均配置lacp m-lag，且两台设备M-LAG ID一致
• 汇聚层向上级联、向下接入的所有Trunk放通VLAN一致
• 服务器bonding配置为LACP模式，且两端网卡都处于Active状态
• 实测拔掉一条物理链路、拔掉一台上联、断电一台设备三种场景，确认业务不中断

6.3 现场踢光缆演练记录

最后分享一个演练小技巧。验收M-LAG项目时，不要只在设备上做shutdown模拟，最好直接去机房踢光缆，尤其是peer-link和keepalive的那几根。因为shutdown只是把接口协议置down，物理链路本身还好好的；真踢光缆才能暴露物理线路、光模块、跳线架这些隐性故障。

我第一次做M-LAG项目时，就是在演练阶段发现keepalive用的光模块有一个老化，平时业务流量小没问题，故障切换时突然丢几个心跳报文，导致M-LAG进入保护状态。这种问题用设备命令很难查出来，只有物理层面的演练才能暴露。

踢完光缆后，记得看业务侧监控系统，确认丢包率和切换时间都在预期范围内。正常M-LAG切换时间应该在秒级以内，如果超过这个范围，优先排查STP收敛、peer-link带宽、汇聚层路由收敛这几个环节。

M-LAG这套架构本身并不复杂，真正考验人的是级联场景下两台设备、两条层级、多台TOR之间的协同配合。把peer-link、keepalive、M-LAG成员口这三个核心要素理解透了，把级联链路的VLAN放通和STP策略统一规划好，再配合严格的上线验证流程，这套网络会很稳。我这套配置思路在多个项目里都验证过，拿去做参考，大概率能少走不少弯路。