企业官网建设流程全解析

数据中心里聊高可靠性，绕不开M-LAG。做了这么多年网络，从早期的VRRP+双上行，到后来的堆叠，再到现在大规模铺开的M-LAG，我最大的感受是：M-LAG不是某个厂商的炫技功能，而是数据中心网络在发展过程中被业务逼出来的一个"必然答案"。这篇我把M-LAG从诞生背景、核心机制、故障场景到配置落地、排障经验，尽量往细了写，配合主页的实验视频，希望能帮你把这块彻底吃透。

1. 为什么要有M-LAG：传统堆叠的痛点和数据中心的需求转变

1.1 一次升级割接把堆叠问题暴露干净了

大概在七八年前，我负责一个中型数据中心的接入层改造，核心用的是当时很主流的堆叠方案。堆叠这东西平时用着挺顺手，管理面合一，控制面统一，一条命令管所有框，但真正出问题的时候极其难受。

记得有一次给核心交换机做版本升级，就两台框堆在一起。升级流程本身不算复杂：备框先升，主框后升，中间涉及重启、版本回退检查、配置同步确认。结果备框重启之后，堆叠口协商失败，备框直接脱离堆叠系统，变成了一台独立的孤儿设备。转发面倒是没中断，但整个管理面全乱了：原来通过堆叠虚IP管理的业务全部失联，二层的MAC表、三层的主机路由在两边各学一半，接入交换机上联的口开始出现瞬间的大量丢包，因为去往部分网段的流量被hash到了那台掉线的设备上，而它根本没有对应的表项。那一次割接，我们花了比预期多三倍的时间才恢复，全靠紧急重启和手工刷表硬拉回来。

从那次之后，我对堆叠这类"强耦合、单管理面"的方案产生了很大的戒心。堆叠的最大问题不在于日常功能，而在于故障域太大：一次不成功的成员加入、一次版本不匹配、一次堆叠口闪断，都有可能把整个组网拖下水，而且排查链路特别长。

后来M-LAG类技术开始成熟，我才逐渐把数据中心的关键节点全部迁移过去。M-LAG解决的核心问题，不是"让两台设备变得像一台"，而是"让两台设备在逻辑上协同工作，但物理上各自独立"。

1.2 M-LAG的核心理念：控制面独立、转发面协同

M-LAG，全称Multi-Chassis Link Aggregation Group，跨设备链路聚合组。字面上看，它就是把传统的"两台设备+两根线分别接服务器"这种情况，变成"两台设备组成一个逻辑的聚合组，服务器或者交换机双归上来，像接入一台设备一样"。

但它的精髓在于控制面。传统堆叠是"一个控制面，多台转发设备"；M-LAG是"两个控制面，通过协商机制对外表现为一个逻辑设备"。两台设备各自跑各自的路由协议、各自维护各自的转发表项，但在接入侧、在二层MAC层面、在三层网关层面，通过M-LAG机制保持数据的一致性，让下游看起来就是一台设备。

这种设计的直接好处有几个：

• 单台设备故障时，另一台完全独立可用，不存在控制面同步失败导致的连锁故障。
• 软件版本升级可以逐台进行，业务不中断，这在堆叠时代几乎不敢想。
• 扩容、替换设备时，新设备可以先独立上线，再通过M-LAG并入，风险可控。

说白了，M-LAG是用一点控制面的复杂度，换取了极大的故障隔离性和运维灵活性。

1.3 它解决了哪些堆叠解决不了的问题

我梳理了几个典型的对比场景，都是实际工作中会遇到的。

还有一点容易被忽略：堆叠是把两台设备的资源"绑定"起来，但物理上它们还是两台独立的硬件。堆叠口一旦出问题，两台设备各自以为自己还是整个系统的一部分，就容易出现"双主"的灾难场景。M-LAG在设计之初就把"双主检测"作为一等公民来对待，后面我会专门用一节来讲。

所以，如果你的网络里已经用堆叠用得战战兢兢，或者你正在为一个要求"高可用、好维护、可平滑演进"的数据中心做设计，M-LAG是你必须优先考虑的方案。

2. M-LAG的三根"命脉"：peer-link、keepalive和DFS

M-LAG能跑起来，依赖三个关键组件。很多人配置M-LAG时，命令抄上去了，功能也通了，但压根不知道这个系统是靠什么维持运转的。一旦出故障，全凭试错。这一节我把三个组件掰开揉碎讲清楚。

2.1 peer-link：跨设备的控制面走廊，但不是普通的数据转发通道

peer-link，也叫peer-link接口，是两台M-LAG设备之间的一条专门链路，通常用一个独立的聚合口来承载。

它干的活主要有三件：

• 传递DFS（Distributed Forwarding System）控制报文，包括角色选举、状态同步、配置协商等。
• 跨设备的聚合成员口状态同步，比如一台设备的M-LAG成员口down了，需要让对端感知并调整流量。
• 在特定场景下，承担少量跨设备流量转发，但这里必须强调：正常情况下，它不应该成为数据中心业务流量的主力转发通道。

这点特别关键，也是很多初学者最容易误解的地方。M-LAG设计了一个重要原则叫"本地优先转发"（local preference）。意思是，流量从接入设备上来，能走本地出就尽量走本地出，不要绕到peer-link上去。peer-link的带宽是用来传控制报文和兜底流量的，不是用来承载南北向大流量的。如果你发现peer-link口流量爆满，说明你的设计有问题，流量模型被破坏了。

为什么一定要做本地优先转发？很简单：peer-link带宽再大，也就是一根或几根线，而业务流量往下行、往上行都是海量的。如果所有流量都绕行peer-link，它不仅会成为带宽瓶颈，还会变成一个巨大的故障点。peer-link断了，全网就瘫了。

2.2 keepalive链路：双主检测的"心跳线"

keepalive链路是M-LAG系统里最容易配置错，也最容易被忽略的一条链路。

它的作用是做双主检测，也就是判断对端设备是"活着但peer-link断了"，还是"整台设备挂了"。这个判断的输入，就是keepalive链路是否还能收到对端的报文。

keepalive通常是走独立的三层链路，可以用专门的VLAN、专用接口，也可以用带外管理网络，但绝对不能和peer-link绑在一条物理链路上。网上很多人配置的时候，图省事把keepalive和peer-link放在同一个聚合组里，或者放在同一条物理链路的不同VLAN里，这等于把两个生命体征监测器放在同一根血管上——血管一断，两个监测器同时失效。

实际中，peer-link断了但keepalive还通，说明对端设备还活着，两台设备会进入分裂模式（split mode）；如果keepalive也断了，那就很危险了，系统可能认为对端整机故障，两台设备同时进入主状态，这就是"双主"。

2.3 DFS group和成员口的角色

DFS group是M-LAG的逻辑管理域，两台设备必须属于同一个DFS group才能互相协商。它负责维护成员设备的编号、优先级、状态机，以及各种一致性表项的同步。

成员口就是接入侧真正和下游设备对接的接口。在M-LAG里，成员口一般以聚合口的形式存在，两台设备各自出一个聚合口，两边的聚合口再通过DFS机制"粘"成一个逻辑上的跨设备聚合组。

有一个概念必须搞清楚：M-LAG成员口有时候也叫M-LAG接口/IPL（Inter Peer Link）扩展口，它和普通聚合口的关键区别在于：普通聚合口的所有成员都在一台设备上，M-LAG的成员口分布在不同设备上。下游服务器或交换机看到的是"两个物理口、一个聚合组"，但它并不知道这两根线连着的是两台不同的设备。

这就带来一个好处：下游设备不再需要依赖VRRP之类的协议来做网关冗余。两条线都是活跃成员口，流量可以同时从两条线上走，链路利用率从50%直接提升到接近100%，这对于带宽敏感的数据中心业务意义巨大。

3. 转发与控制面怎么协同：选举、一致性检查和流量模型

3.1 角色选举与优先级

M-LAG系统里，两台设备在协商阶段选出主备角色。这个角色不叫"主设备/备设备"，业内更准确的叫法是"主节点/备节点"或者"主系统/备系统"。

选主的原则不复杂，优先级（priority）小的优先，优先级相同再看MAC地址，MAC小的优先。选主完成后，主节点负责：

• 生成并维护DFS group的系统MAC、系统ID等全局参数。
• 域名、配置参数的下发与同步。
• 部分跨设备表项的汇总处理。

备节点则保持对主节点的状态跟踪，接收主节点的同步信息。需要注意的是，M-LAG的主备和堆叠的主备有本质区别：堆叠的主备是"管理面集中"，M-LAG的主备更多是"协商出来的对外代表"。两台设备在转发层面都是活的，都能转发流量，不存在备机只有备份功能这种情况。

在配置时，"动态角色抢占"通常要关掉。因为M-LAG的备节点工作得好好的，主节点重启恢复后，如果触发角色抢占，会导致DFS系统重新收敛，表项重新同步，对业务可能产生不必要的冲击。

3.2 CSPC一致性检查：防止两台设备"各想各的"

CSPC（Consistent State Propagated Check），一致性检查。这是M-LAG里一个容易被忽略但极其重要的机制。

为什么需要一致性检查？因为M-LAG的两台设备控制面是独立的。如果一边配置了某个VLAN、某条策略，另一边没配，那么对外看来，这个逻辑设备的行为就是"漂移"的。服务器发一个广播帧，可能只有一台设备响应；下行流量走过来，可能只在一边有出口。

CSPC做的事情，就是周期性地比对两台设备的关键配置和表项，发现不一致时上报告警，严重时会阻断M-LAG接口的协商。常见的检查内容包括：

• 聚合组的成员口配置是否一致
• VLAN配置是否一致
• 接口类型、端口隔离配置是否一致
• STP配置、QoS策略等是否一致

这里分享一个真实案例。有一次客户报障，说M-LAG下挂的服务器间歇性网络中断。查了半天，发现是两台设备上的某个接口VLAN划分不一致：一台把VLAN 10放到了M-LAG成员口里，另一台忘记放。MAC地址漂移告警刷屏，流量走到没有VLAN的那台设备时直接丢弃。这就是CSPC没配置或者没及时处理的典型后果。

所以我在做M-LAG项目时，落地检查清单里永远有一条：把CSPC检查打开，定期查看一致性检查日志。别嫌它啰嗦，它是M-LAG系统的"仪表盘"。

3.3 实际转发模型：本地优先转发与MAC同步

讲了这么多机制，最后落到转发。一个典型的M-LAG接入场景是这样的：两台M-LAG交换机上联核心，下联服务器，服务器双网卡绑定成一个聚合组，分别接到两台交换机上。

服务器发出上行流量时，根据网卡绑定的hash算法，流量会分布在两个物理口上。这没问题，两边都是活跃口。

下行流量的场景稍微复杂一点。假设外部有个流量要发给服务器，到达了M-LAG的两台设备之一。这台设备在自己的MAC表或ARP表里查服务器MAC，发现它学习到了自己本地的M-LAG成员口上，就直接从本地口转发出去，这是"本地优先"；如果发现服务器MAC只在对端的M-LAG成员口上，就会通过peer-link把流量跨设备送过去。

所以，M-LAG系统内部有一个"MAC地址同步"的机制：一台设备学到的MAC，通过DFS同步给对端。这个同步不是让对端也"当作本地直连"，而是让对端知道"这台服务器可以通过peer-link到达"。这样，流量落地后，无论落到哪台设备，都能找到正确的出口。

这里就回到了我前面强调的问题：如果你把peer-link当成主力转发通道，跨设备流量大量发生，不仅浪费带宽，还会导致MAC同步表项频繁抖动。正确的设计思路是：尽量让"同一台服务器的出入流量"落在同一台M-LAG设备上，或者至少让共享流量保持在可控范围。这也是为什么很多高端设计里，M-LAG会配合业务划分、虚拟化编排一起来做，而不是单靠一个功能硬扛。

4. 故障场景逐个拆解：脑裂、单机宕机、上行掉线分别会发生什么

M-LAG的价值，不在正常情况下，而在故障时。这一节我结合实际巡检和排障中遇到的情况，把常见的故障场景逐个拆解。

4.1 单台整机宕机

这个场景最简单，也最能体现M-LAG的价值。

假设M-LAG主节点设备突然掉电。此时：keepalive报文停止，peer-link断掉。备节点设备在超时后，将自己升级为主节点，接管DFS group的控制权。原有的M-LAG成员口状态、MAC表项、ARP表项在备节点上已经通过同步机制提前准备好了，所以服务器感知不到网关变化。

下行的接入设备原本双归到两台M-LAG设备上，主节点挂掉后，流量全部从备节点的聚合成员口走。聚合组里只剩一根线活跃，链路利用率降为一半，但业务不中断。

这里有个细节：备节点升级为主节点后，不需要重新学习MAC和ARP，因为这些表项之前就已经同步过了。这也是为什么M-LAG能够在故障场景下做到"无感知切换"的原因。

不过要注意，如果宕机的是"备节点"，那就更简单了：主节点继续工作，备节点恢复后自动重新加入DFS group，做一次表项重新同步，就完事了。整个过程对业务几乎没有影响。

4.2 peer-link故障但keepalive还通：分裂模式

这个场景比较微妙，也是M-LAG调试里最常需要深入处理的。

peer-link断了，但keepalive还通。这意味着两台设备都还活着，只是它们之间的控制通道断了。系统判断为"链路故障"而非"节点故障"，进入分裂模式。

分裂模式下的处理逻辑是：

• 两台设备仍然各自转发流量。
• 但为了保证接入侧不出现环路，系统会根据角色让"备节点"把M-LAG成员口置为DOWN，或者保持一种特殊的阻塞状态。也就是说，备节点主动放弃接入侧转发，避免和主节点出现双点接入的环。
• 主节点继续正常转发。

你可能会问：既然备节点把成员口关了，那这个场景业务不还是有影响吗？是的，有短暂影响，但相比堆叠脑裂的"全网泛洪 + MAC漂移 + 业务完全中断"，这种处理已经是非常克制的。

为什么备节点要主动关成员口？想象一下：如果peer-link断了，两台设备还都继续往同一个服务器双归口上转发流量，服务器侧的聚合组会把这两台设备当成一个逻辑设备的两条成员链路。但它们的MAC表、ARP表已经无法互相同步了，转发表就分叉了。更严重的是，接入交换机如果跑STP，会发现"两台设备"之间出现了环路。所以，分裂模式下"关备机成员口"是防止环路和流量异常的必要动作。

什么时候能恢复？还是看keepalive。当peer-link恢复后，分裂模式解除，备节点重新开始接收同步信息，逐步恢复成员口转发。整个过程设计要求是"秒级收敛"。

4.3 双主：最可怕的场景

接下来是最危险的场景：peer-link也断，keepalive也断。

这种情况下，两台设备都无法确认对端的状态。它们会各自认为"对端挂了，我应该成为主节点"。于是，两台设备同时进入主节点状态，都开始转发流量，都维护自己的MAC表和ARP表。这就是双主。

双主为什么可怕？因为它不仅仅是"两台设备都在转发"这么简单。服务器侧看来，它的两条聚合链路都是活跃的，流量会在两条链路上负载分担。但两台设备的表项已经不一致了。举个例子：服务器的MAC地址可能在主节点A上学习到，同时又在主节点B上学习到。接入交换机向服务器方向发送流量时，会根据hash把流量同时发到两台设备上，其中到达B的流量，B查询MAC表发现这个MAC应该通过peer-link送走（但peer-link已经断了），或者发现MAC表项在本地（但本地成员口可能已经逻辑失效），最终丢包。同时，ARP请求、广播报文可能在两台设备之间反复震荡，导致MAC地址漂移告警疯狂刷屏，网络状态接近雪崩。

M-LAG系统在检测到双主时，会启动一种保护策略：MAD（Multi-Active Detection）。保护的核心思想是"保留一个主节点，惩罚另一个"。具体实现方式各厂商有差异，比如有的通过关闭备选主节点的成员口、关闭它的业务接口，或者让整个备选主节点进入一种"恢复模式"，直到确认对端故障解除或人工介入。

这个场景也解释了为什么keepalive链路要做得足够独立、足够可靠。很多生产环境在部署时，会把keepalive独立接在带外管理网络或者专门的物理链路上，绝不走业务网络。因为如果keepalive报文混在业务网里传输，一旦业务网络拥塞或者链路闪断，keepalive就可能误判，把"网络故障"误当成"对端设备故障"，引发双主。

4.4 上行或下行链路故障：联动处理

除了节点级故障，M-LAG还经常面临链路级故障。

比如，下行服务器的一条物理链路断了。M-LAG系统的处理是：本端成员口状态变为DOWN，DFS同步给对端，对端更新聚合组的成员口状态。服务器内核里的绑定驱动会感知到这个变化，把流量重新hash到剩下的活跃链路上。这个过程不会引发环路，收敛也很快。

上行链路故障稍微复杂。假设M-LAG设备A的上联链路全部断开，但设备B上联正常。此时，A仍然通过peer-link与B通信，A依然持有M-LAG成员口的活跃状态。如果服务器或接入交换机仍有流量通过A上行，这部分流量就只能通过peer-link绕到B再出公网。这就会大量占用peer-link带宽，而且可能不符合你的流量设计预期。

解决办法是配合"上行链路联动"（Monitor Link / Smart Link / track联动等方式）。当检测到上行链路全部DOWN时，主动将本端M-LAG成员口也置为DOWN。这样，流量提前绕开故障设备，全部从对端走，避免流量半路绕行peer-link。这个联动逻辑，在生产环境里强烈建议配置，否则上行单点故障可能导致peer-link拥塞甚至丢包。

5. 配置落地与实操注意点

理论讲完，来点能直接"抄作业"的。下面是一份贴近生产实践、可落地的M-LAG配置思路，以常见的命令风格为例。不同厂商命令有差异，但核心逻辑是一样的。

5.1 一份可参考的配置顺序

配置M-LAG有两个大原则：先建底层链路，再建逻辑协同；先保证keepalive，再谈peer-link。别一上来就建桥接聚合，否则中间步骤报错你会一头雾水。

我习惯的顺序如下：

1. 规划接口及VLAN，至少规划一个专门的VLAN给keepalive，一个VLAN给peer-link。
2. 配置keepalive链路：两端配置三层接口IPv4地址，保证能互相PING通。
3. 创建peer-link聚合组，将至少两条物理链路加入聚合组，并放通peer-link专用VLAN。
4. 创建DFS group，指定peer-link和keepalive参数。
5. 创建业务侧的跨设备聚合组（M-LAG聚合接口），配置VLAN和业务参数。
6. 将实际接入物理接口加入该聚合组。
7. 开启一致性检查（CSPC或等效机制）。
8. 验证：查看DFS状态、M-LAG状态、成员口状态是否正常。

伪配置大致长这样：

# 设备A interface Vlan-interface 4094 ip address 10.0.0.1 30 interface Bridge-Aggregation 1024 link-aggregation mode dynamic description M-LAG peer-link port link-type trunk port trunk permit vlan 4094 interface Bridge-Aggregation 1 link-aggregation mode dynamic description M-LAG member port link-type trunk port trunk permit vlan 10 20 dfs-group 1 peer-link interface Bridge-Aggregation 1024 keepalive ip destination 10.0.0.2 source 10.0.0.1

设备B对应地址改一下，业务聚合接口加入"m-lag group 1"之类的声明，表示这个聚合口属于M-LAG系统的一个逻辑成员。最终的M-LAG活跃口会分布在两台设备上，但对外表现是一个聚合组。

5.2 几个常见的配置坑

说几个我在实际排障中反复遇到的坑。

第一，peer-link的物理成员数量不要只配一根。peer-link是M-LAG的命脉，起码两根物理口做聚合，并且最好分布在不同的板卡甚至不同的电源域。只配一根，一旦这根线光模块老化了，或者光口被误操作shutdown，整个M-LAG系统就进入了分裂模式。

第二，keepalive和peer-link必须分开物理链路。我把这条放在第一位提醒，是因为真的见过生产环境把keepalive报文放进peer-link的同一个VLAN里，然后peer-link闪断时，keepalive跟着断，双主直接发生。keepalive这心跳线，独立性就是生命线。

第三，M-LAG成员口里，两台设备必须保证接入侧配置一致。VLAN、端口模式、端口隔离、限速配置，最好做到"配置模板化"。不一致不会立刻报错，但会以MAC漂移、流量闪断的形式反馈给你。

第四，STP配合必须做好。M-LAG系统在接入侧向外呈现一棵"逻辑树"，避免被STP判定成两台独立交换机构成环路。很多初学者在接入侧忘了启用一种叫"STP收敛增强/一致"的配合策略，导致M-LAG下的聚合链路在STP视角里出现blocking端口，业务流量白白被阻断。

5.3 三种冗余方案怎么选

很多朋友纠结：到底用堆叠、VRRP+双上行，还是M-LAG？我给一个务实的选择逻辑。

• 对可靠性要求一般、设备数量少、管理能力薄弱的小型网络：堆叠简单直接，能用，但要接受升级风险、故障域大的代价。
• 数据中心关键节点，双归接入，要求链路带宽高利用率：优先M-LAG。它是唯一能同时满足"控制面隔离"和"双活转发"的方案。
• 传统园区核心，网关冗余，流量模型以下行回归为主：VRRP+双上行仍然可用，但链路利用率只有50%，且主备切换有协议收敛时间。

顺便说一句，大型数据中心里，M-LAG之上往往会叠加BGP做路由发布。M-LAG两台设备共用虚拟网关，对外发布路由时需要注意"路由防环"和"下一跳一致性"，避免因为两台设备都发布相同网段路由造成外部流量分配不均。我们在线网里通过BGP的等价路由和精细的发布策略来控制南北向流量的分布，这个如果展开讲又是一篇文章，但这说明M-LAG不是孤立存在的，它和上层的路由设计、下层的接入策略是紧密联动的。

6. 从设计到运维的经验：物理布局、升级与排障技巧

最后这部分，我总结一下从设计到运维的一些经验和技巧。这些东西在官方文档里未必能看到，但对实际运维质量影响很大。

6.1 物理链路布局建议

M-LAG设备之间虽然逻辑上是一个整体，但物理上完全是两台独立设备。当你设计机柜和走线时，要注意让"一台设备的器件故障"不至于同时影响两台。

具体做法：

• M-LAG两台设备不要放在同一个电源PDU下，要分属不同电源域。
• peer-link的物理成员口，尽量分布在设备的不同槽位，避免单板卡故障导致peer-link全断。
• 如果机房条件允许，M-LAG两台设备最好跨机柜部署，减少单柜失火、单柜掉电之类的极端风险。
• keepalive链路建议走独立的物理路径，比如带外管理网，不要和设备的上行业务共享链路。

6.2 升级与排障的实用技巧

M-LAG最大的运维红利就是支持平滑升级。但"支持"不等于"无脑升"，升级前要做几件事：

• 先确认对端设备的版本兼容矩阵，确认M-LAG跨版本协商兼容性。
• 升级顺序通常是"备节点先行"。先升级备节点，备节点升级完成后自动重新加入DFS group，确认状态稳定后再升级主节点。
• 保留回退方案。保存原有版本文件，保留配置备份，确保升级失败能快速回滚。

排障的时候，我习惯三步走。

第一，看DFS状态。可以用"display dfs-group"或等效命令查看两台设备的DFS协商是否正常，角色是否稳定，是否有频繁的倒换记录。

第二，看M-LAG成员口的协商状态。重点看备节点的成员口是否处于活跃状态，是否被分裂模式或MAD保护误关了。

第三，查一致性检查日志。往往配置漂移、表项不一致的问题，在日志里早就有苗头了。

举一个我踩过的排障例子。有一次客户说M-LAG下服务器的ARP表学习不稳定，时通时断。我们先看了DFS状态，正常；看了成员口状态，也全部正常。后来打开一致性检查日志，发现两台设备的某个接入VLAN配置不一致：一台设备的VLAN接口启用了本地ARP通告，另一台设备没有。因为服务器和网关之间跨了两台设备，ARP响应有时候从A回，有时候从B回，行为就飘了。改完配置，问题立刻消失。

6.3 一份实用的M-LAG健康检查清单

运维值班时，可以按这个清单快速检查M-LAG的整体健康度：

• DFS group协商状态：主备角色是否稳定，有没有异常倒换。
• peer-link状态：聚合口up，成员口数量完整，无CRC错误、无错包。
• keepalive状态：报文收发正常，延迟和丢包为0。
• M-LAG成员口状态：活跃口数量、对端同步状态正常。
• 一致性检查：最近检查结果无重大不一致项。
• 跨设备MAC同步：关键服务器的MAC表项在两台设备上都有同步记录。
• 上行链路联动：上行故障时，M-LAG成员口联动是否按预期触发。

我自己做巡检时，还会顺带看一眼CPU和内存利用率。M-LAG设备虽然转发能力强，但如果DFS报文风暴（比如peer-link反复闪断），CPU可能会被大量控制报文打满。那种情况下，M-LAG的表现会非常诡异：状态一会儿正常一会儿异常。根本解法还是查物理链路、光模块、板卡日志，把闪断的根因找出来。

M-LAG这东西，初看学的是配置，再学学的是机制，最后真正拉开差距的是对故障场景的预判和物理链路的敬畏。你把前面那些故障场景自己在脑子里推演一遍，再在实验环境里故意制造一次peer-link中断、一次整机掉电，你会发现对它理解完全不一样。主页的实验视频我做了完整的过程演示，强烈建议跟着敲一遍，光看文章和真正拔一次线，记忆深度是两回事。