MCLAG双活接入技术详解：原理、配置与故障排错实践

1. 两台交换机只能跑STP吗——接入双归的带宽困境

我在一次汇聚层设备割接中碰上了这个经典难题：核心下挂的两台汇聚交换机要升级，但业务完全不能断。最常规的方案无非两种，一是靠STP（生成树协议）做冗余，备链路平时就堵着；二是两台设备做堆叠，变成一个逻辑设备。两种方案我都不太想选，因为我既想要设备级的独立冗余，又不想把一半的互联带宽白白浪费掉。

先说STP这条路。很多网络里到现在还在用STP家族做二层冗余，它的逻辑很简单：物理上造环，逻辑上破环，通过阻塞某个冗余端口来防止广播风暴。代价很直观——那根被阻塞的链路平时完全闲着，带宽在那摆着却不走流量，只有主链路断了才会切换过去。更麻烦的是收敛时间，虽然RSTP（快速生成树协议）能把收敛压到秒级以内，但在一堆依赖视频流、语音会议的业务面前，哪怕一两秒的中断都足以让用户开始抱怨。你说可以调参数优化？能调，但STP的收敛本质上就是重新计算拓扑、重新选举根桥、重新迁移端口状态这一套流程，再怎么加速也有它自己的物理天花板。

再说堆叠这条路。堆叠确实能解决STP浪费带宽的问题，两台设备通过堆叠口变成一台逻辑设备，下行链路可以跨框做聚合，两条链路同时转发，一台设备宕了另一台还能扛住。但是堆叠的痛点在于控制面耦合太强——两台设备共用一份控制面状态，主设备挂了，备设备要接管，中间有一个系统重启级别的切换过程，不是所有厂商都能做到完全无感的。更让我顾虑的是升级场景，堆叠系统升级往往要求整堆重启，这对核心业务来说几乎是不可接受的。而且堆叠一旦出现分裂，两个框都以为自己是主，很容易把整张网络搞出大问题。

两种方案都不完美，所以我把目光放在了MCLAG（Multi-Chassis Link Aggregation Group，多机架链路聚合组）上。简单说，这是一种跨设备链路聚合技术，让两台独立的交换机像一个双活系统一样，把下行链路跨接到两台设备上，对外呈现成一条逻辑聚合链路。控制面各自独立，转发面却能共用，设备级故障有冗余，链路级带宽也不浪费。这篇文章我就围绕MCLAG完整过一遍——它解决了什么、原理怎么走、故障怎么扛、配置怎么做、排错怎么查，把我实测中踩过的坑一并讲清楚。

MCLAG适合谁看？如果你在维护数据中心接入、园区汇聚，或者任何需要"双归接入"但又不想引入堆叠控制面耦合的场景，这篇内容可以直接作为你的选型参考和配置手册。我说的双归接入，就是服务器、交换机或者防火墙用两根线分别接到两台上游设备上，平时两条链路同时转发，任何一台上游设备挂了流量都不中断。这个需求听着简单，真正实现得漂亮，底层牵扯的控制面、数据面、故障状态机，每一层都有不少讲究。

2. MCLAG的组件拆解：peer-link、keepalive、domain和成员口

MCLAG在大方向上解决了两个核心问题：控制面解耦和转发面共享。控制面解耦意味着两台设备各自跑各自的协议栈，路由协议、MAC学习、ARP表项都是独立维护的，不搞"一台主另一台备"那套强依赖；转发面共享意味着上行流量可以同时从两台设备走，任何一台宕了，流量自动落到另一台，不依赖STP那种"先堵后切"的笨办法。

但要让两个独立控制面的设备协同转发，光靠意愿不够，必须有一个成熟的组件体系把两台设备"缝"起来。我把MCLAG的核心组件按功能拆开，一个个讲。

2.1 peer-link：双机之间的数据通道

peer-link是两台MCLAG设备之间的互联链路，它的作用有两个：一是承载需要跨设备转发的已知单播流量，二是同步必要的控制信息。举个例子，服务器S双归到A、B两台交换机，A上接入了一台终端T，B上接入了一台主机H。H发出的流量经过哈希被送到了B，但目标T在A的接入侧，这时候B就需要通过peer-link把流量转发给A，再由A送到T。没有peer-link，这部分流量就断了。

所以peer-link不是一个普通的二层互联口，它需要足够的带宽来承载跨设备流量。我见过有人在部署时把peer-link做成了两根万兆，结果业务一上来就发现跨设备流量把peer-link打满了，业务表现为间歇性丢包。经验做法是：peer-link带宽至少要为"最坏情况下跨设备流量比例"留出余量，比如整网流量的30%到50%都可能要跨peer走，那peer-link带宽就不能比下行总带宽低太多。

peer-link还有一个容易被忽略的点：它上面跑的协议报文、控制报文也需要一个独立的VLAN来承载。不同厂商叫法不一样，有的叫control VLAN，有的叫peer-link VLAN，本质都一样——专门划一个VLAN给MCLAG控制面通信使用，这个VLAN不向下游业务放行，避免用户流量误入。

2.2 keepalive：双机心跳还是脑裂仲裁

keepalive是一条独立于peer-link的三层可达链路，通常走带外管理网或者独立路由接口，用来在两台设备之间传递心跳报文。它的核心价值不是转发数据，而是判断对端是否存活。

这里有个关键逻辑：peer-link断了，不代表设备宕了，两台设备可能都还在正常运行，只是它们之间的数据通道断了。如果此时两台设备同时认为自己是"双活主角色"，继续从各自的MCLAG成员口转发流量，下游交换机会同时从两条链路收到来自"同一台逻辑设备"的报文，广播风暴、MAC漂移就会接踵而至。这就是典型的脑裂（split-brain）场景。

keepalive就是用来解决这个问题的。当下联的MCLAG成员口正常但peer-link中断时，设备会借助keepalive探测对端是否还活着。如果keepalive能通，说明对端没宕，只是peer-link断了，此时需要进入一种降级状态，通过协商机制或优先级决定哪台设备继续转发业务流量，另外一台把MCLAG成员口阻塞掉。如果keepalive也不通，那判断对端可能已经宕机，本机要接过全部转发任务。

这里要特别提醒一句：keepalive和peer-link绝不能走同一条链路，否则peer-link一断，keepalive大概率也断了，设备根本无法区分"对端宕机"还是"链路中断"，脑裂仲裁就失去了意义。我在实际部署中习惯把keepalive放在独立的带外管理VRF里，物理上完全隔离，管理网出问题也不至于牵连业务判断。

2.3 MCLAG domain与成员口：双活的"缝合点"

MCLAG domain可以把两台物理设备定义成同一个MCLAG域，域ID要一致，这是两台设备互相识别并协同工作的前提。域内可以包含多个MCLAG接口，每个MCLAG接口在A、B两台设备上使用相同的编号，对外就体现为一个统一的逻辑聚合口。

成员口的概念要和普通链路聚合区分清楚。普通LACP（链路聚合控制协议）是在一台设备内部把多个物理口捆成一个聚合口；MCLAG则是把两台设备上的成员口各自捆成一个聚合口，再通过MCLAG机制让这两个聚合口对外表现为同一个逻辑聚合口。下游设备——比如服务器上的网卡bond或者下联交换机——看到的是两条物理链路在做一个跨设备的LACP协商，仿佛对面是一台设备一样。

为了把这层关系说清楚，我把MCLAG和常见替代方案的关键差异整理成一个表格：

从这个表能看出来，MCLAG最突出的价值就是既保留了设备独立性，又实现了高带宽利用。代价是概念和配置比传统方案多了一层，需要运维人员真正理解它的工作原理，而不是照抄配置。

3. 双活不环路的底层逻辑：LACP视角、MAC同步与BUM流量抑制

MCLAG表面上看着像链路聚合，实际上它最精妙的地方在于：两台设备的控制面是独立跑的，但数据面要协同工作且不能成环。下游设备把MCLAG接口当作"一台设备"来发流量，流量哈希到A或者B之后，转发行为必须和"单台聚合交换机"保持一致。要做到这一点，底层有三大机制：LACP双归协商、MAC地址同步、BUM流量抑制。我分别拆开讲。

3.1 下游设备视角：LACP如何把两台设备看成一台

LACP协议本身是一种端口协商机制，聚合链路两端的设备通过交换LACPDU（链路聚合控制协议数据单元）来确认哪些成员口可以加入同一个聚合组。普通场景里，一个聚合组的所有成员口都在同一台交换机上，所以LACP协商只发生在两台直连设备之间。

MCLAG场景里，服务器上做了网卡bond（通常配成LACP模式），两根线分别插到A、B两台交换机上。服务器发出的LACPDU，A收到一份，B也收到一份。如果A、B都独立应答，服务器会认为自己在和两台不同的设备做LACP协商，根本无法形成一个聚合组。MCLAG的解决方法是：A、B两台设备在LACP协商中用同一个系统ID（System ID）来应答。这样服务器看到的就是一个逻辑上的"聚合交换机"，所有成员口都归属同一系统，自然就聚合成一条逻辑链路。

这个系统ID就是MCLAG domain的核心体现。A、B上配置同一个domain ID之后，系统会据此生成一致的LACP System ID、一致的操作Key，成员口才能真正对外表现为统一设备。这也是为什么MCLAG配置中domain ID必须严格一致，不一致的话LACP协商直接失败，MCLAG成员口根本起不来。

3.2 MAC表同步：两台设备如何"共享"二层转发表

LACP协商解决的是链路层的"看起来像一台"，MAC表同步解决的是转发面的"转发得像一台"。普通场景下，A设备通过某个端口学到MAC地址，就只存在于A的MAC表里；B设备不知道这个MAC在哪。但在MCLAG双活系统里，下游设备可能哈希到A，也可能哈希到B，如果两台设备各自只知道一部分MAC信息，流量就可能被错误转发到peer-link上盲目泛洪，甚至导致丢包。

所以MCLAG要求A、B之间通过peer-link同步MAC表项和ARP表项。A学到一台终端的MAC，会立即同步给B；同理B学到的也会同步给A。这样两台设备都维护一份全局的二层转发表。这个同步过程越实时越好，否则跨设备转发就会出现大量miss。

这里有一个性能细节值得展开：MAC表同步是双向的，但同步开销和表项数量成正比。在大型接入网络里，如果MAC表有几万条，同步的频率和收敛时间是必须考虑的因素。我实测的经验是，MCLAG设备对MAC同步的时效要求比普通二层网络高得多，尤其是在终端频繁上下线的场景，一旦表项同步滞后，容易出现"流量绕远路"的临时转发问题。好在这类问题大多是瞬时的，通过抓包或者查MAC表时间戳能定位到。

3.3 BUM流量抑制：广播、未知单播、组播如何在双活中不成环

BUM流量就是广播（Broadcast）、未知单播（Unknown Unicast）、组播（Multicast）这三类必须泛洪的流量。普通STP网络中，破环靠阻塞端口；但MCLAG里两个成员口都是转发状态，物理上是有环的，不能靠阻塞避免环路，而是靠选举机制。

MCLAG会在peer-link上运行一种指定转发者（Designated Forwarder，DF）选举机制。简单说，对于任何一个MCLAG VLAN，经过选举后只有一台设备是该VLAN的"转发者"，由它负责把BUM流量向MCLAG成员口转发；另一台设备虽然是双活的，但在BUM流量上会主动抑制，避免同一份广播报文从两条物理链路同时送出去。这样既保证了广播报文能到达所有终端，又避免了环路。成员口物理上是通的，逻辑上对BUM流量做了"单发"限制，这就是它和STP堵塞端口最大的不同。

不过要小心，DF选举依赖的是正常的peer-link和keepalive通信。一旦peer-link中断且DF角色协商失败，两台设备同时泛洪，环路风险立刻暴露，这也是MCLAG故障场景里最需要盯防的一个点。后面讲排错时我会专门说这个问题。

3.4 local-bias本地优先转发：减少peer-link压力的杀手锏

还有一个很容易被忽略的机制是local-bias，也就是本地优先转发。我的理解是：当流量从某台设备的本地成员口进入时，如果目的MAC也存在本机的接入侧，那这台设备应该优先直接从本机的出接口转发出去，而不是把流量扔到peer-link上让对端处理。

为什么这个机制重要？因为跨设备转发是有代价的——它既消耗peer-link带宽，又增加了报文转发时延。不考虑local-bias的话，假设所有流量都哈希到A，但一半目的主机在B的接入侧，那peer-link直接被打满，整个MCLAG系统的性能就被peer-link卡住了。local-bias让流量尽量在本地完成转发，只有确实目的地在对端接入侧时，才通过peer-link跨设备转发。

这个机制的默认状态在不同厂商设备上可能不一样，有些默认开，有些需要手动开启。部署完MCLAG之后，我建议重点看两个指标：peer-link的流量占用率和跨设备转发占比。如果peer-link带宽利用率长期偏高，就要排查是不是local-bias没有生效，或者哈希算法在某些流量模型下分配不均匀。

4. 故障场景逐一拆解：设备宕机、peer-link中断、单链路闪断

纸上谈兵不算真懂MCLAG，故障场景才是检验方案含金量的地方。下面我把部署和运维中最高频的几个故障挨个过一遍，分析现象、转发行为以及我应该怎么应对。这部分内容全部基于我在接入汇聚场景中的实测经验。

4.1 场景一：A机整机宕机，流量如何不中断

这是MCLAG最核心的卖点场景。服务器通过两根线分别接到A、B两台设备上，A机突然掉电或者系统崩溃。此时会发生什么？

服务器网卡bond的LACP协商立刻察觉到A方向的链路丢失，驱动会停止向A方向发送流量，所有流量自动落到B方向。这个感知是毫秒级的，因为LACP本身有快速检测机制（短超时模式可以做到3秒内，部分实现可以更快）。与此同时，B设备因为一直有同步MAC表，它知道自己接入侧所有终端的MAC，所以直接按本地转发处理，不需要询问A，也不需要重新学习。

真正需要关注的是：A机宕机后，原本哈希到A的流量全部转移到B，B的下行带宽可能瞬间翻倍。如果B的下行带宽本来就只有总需求的一半，这时候就会拥塞。所以做MCLAG规划时，单台设备的转发能力和接口带宽必须按"承担全部流量"来设计，而不是按"只承担一半流量"。双活系统是高可用架构，不是负载均衡，任何一台都要能扛住全部业务量。

我遇到过一次A机宕机，业务没有任何感知——用户那边视频会议没断、数据库连接没断，交换机上的告警日志刷了几条MCLAG状态变化的记录就完了。这是MCLAG相比堆叠方案一个很舒服的地方：非主控设备故障，不触发整系统切换，转发面本来就是分布式的。

4.2 场景二：peer-link中断，如何避免脑裂

这个场景是MCLAG系统最危险的时刻。peer-link一旦断了，A、B之间无法再同步MAC表，也无法互传跨设备流量。但keepalive如果是独立的，它大概率还通着，两台设备都能探测到对端仍在运行。

此时如果没有仲裁机制，两台设备都会认为自己是双活系统里唯一健康的那台，继续从MCLAG成员口转发BUM流量，环路立刻形成。正确的行为是：当peer-link中断但keepalive正常时，系统需要进入一个降级状态，根据优先级或者MAC地址大小等规则选出一台设备作为"主"设备，主设备继续转发MCLAG业务；另一台设备则把MCLAG成员口阻塞掉，只保留peer-link维持，直到peer-link恢复。

这里值得强调的是，不同厂商的规则在细节上可能有差异，但核心思想一致：peer-link本身的状态决定了双活能否成立，链路断了就必须有一台让位。我在割接演练时专门测过这个场景，关闭peer-link端口后，业务中断大概有几百毫秒到一秒左右，然后流量全部从主设备走，链路恢复后又能自动回到双活状态。从运维角度看，这次中断是合理且可接受的，但如果我在peer-link中断时没有正确配置keepalive或者仲裁参数，后果就是广播风暴直接打垮整张网络。

4.3 场景三：单条下行链路闪断

MCLAG系统最频繁遇到的故障其实是单链路闪断——比如服务器网卡短暂故障、光纤跳线被误碰、光模块瞬断。在这种场景下，MCLAG的处理方式就体现出聚合机制的优势了。

单条链路闪断时，LACP会重新协商这一端口的成员资格。对端（服务器bond）察觉该链路失效，停止向这条链路发送流量，所有流量暂时全部走另一条链路。由于另一台设备上的MAC表是完整的，转发不会中断。链路恢复后，LACP重新抡起，该成员口重新加入聚合组，流量重新哈希分摊。整个过程对业务几乎是无感的，我在服务器上用ping持续测过，单链路拔插时丢包为0。

但有个细节要留意：如果单条链路反复闪断，LACP的状态切换会非常频繁，可能导致该成员口在聚合组里反复上下线。严重的情况下还可能触发MCLAG一致性校验失败，把整个MCLAG接口变成Down状态。所以光模块、跳线的质量在这个场景下会被放大，建议接入侧全部使用工业级光模块，并且保持跳线弯曲半径合理。

4.4 场景四：peer-link被打满，转发性能掉链子

peer-link被打满不是物理故障，但它的破坏力不亚于故障。前面说过，跨设备流量是必须走peer-link的，如果某段时间流量模型发生变化，大量跨设备流量涌入peer-link，就会导致buffer拥塞、报文丢弃，表现为业务侧丢包和时延抖动。

这个问题的难点在于，它不像物理链路断开那么好发现。很多时候业务已经出现卡顿，但MCLAG状态显示正常，成员口也都是UP。我排查过一次视频业务卡顿的案例，折腾了半天最后发现是某台服务器的大流量备份任务触发哈希后，10个G的流量全部跨peer转发，把peer-link打满了。后来我养成了一个习惯：MCLAG部署后一定要在监控系统里给peer-link单独配置带宽利用率告警，阈值设在60%，超过就要重点看流量走向。

另外，如果peer-link经常被打满，除了扩容peer-link带宽，还有一个思路是优化哈希算法——调整成员口在聚合组里的权重，或者让流量尽量在本地完成转发（local-bias），都可以缓解跨peer的流量压力。

5. 接入层MCLAG部署实录：配置步骤全解析

理论说再多，最终要落到命令行上。我以最常见的接入双归场景为例，把MCLAG从零到一的配置流程完整走一遍。不同厂商（华为的M-LAG、锐捷的MCLAG、H3C的DRNI等）命令有差异，但核心逻辑一致，这里以通用逻辑为主，具体命令以你设备厂商的文档为准。

5.1 前期规划：接口、VLAN、IP地址

第一步先把规划做好，这是整个部署里最不能省的一环。我习惯先把下面这张表填清楚，再动手配置：

这张表里最容易出问题的是MCLAG接口编号和VLAN范围的一致性。任何一边配错，LACP协商或者VLAN转发就会表现异常，而且报错往往不直观，排查起来非常消耗时间。

5.2 配置peer-link和keepalive

先把两台设备之间的物理链路放进行，创建peer-link聚合口。以我常用的参考配置为例：

# A机 interface Ethernet1/0/1 port link-type trunk port trunk allow-pass vlan 4090 // 专门用于MCLAG控制报文的VLAN interface Ethernet1/0/2 port link-type trunk port trunk allow-pass vlan 4090 link-aggregation group 1 mode active // 普通链路聚合，用于peer-link interface Bridge-Aggregation1 port link-type trunk port trunk allow-pass vlan 4090 mclag peer-link // 指定该聚合口为peer-link # B机的配置与A机同理

这里有个细节：peer-link上只需要放行控制VLAN和需要的业务VLAN。有的工程师图省事，直接把peer-link配成trunk并且放行所有VLAN，这虽然不影响转发，但会让控制面暴露在不必要的广播域里，还可能在故障时放大环路风险。我建议peer-link只放行控制VLAN和跨设备确实需要传输的VLAN。

keepalive配置相对独立，通常是给一个三层接口配上IP地址，然后指定对端IP作为keepalive探测目标：

# A机 interface METH0/0/1 ip address 10.0.0.1 255.255.255.0 mclag keepalive destination 10.0.0.2 source 10.0.0.1 vlan 4090

keepalive走独立通道时需要注意：A、B的管理网段要能互相路由可达，防火墙规则要放行keepalive协议报文（通常是UDP特定端口）。我见过不止一次因为管理网防火墙策略太严，导致keepalive探测不通、MCLAG一直起不来甚至频繁振荡的情况。

5.3 创建MCLAG domain并绑定peer-link

完成上述链路配置后，开始创建MCLAG domain。这个步骤通常把domain ID、keepalive参数、peer-link口都绑定到一起：

mclag domain 1 peer-link Bridge-Aggregation1 keepalive destination 10.0.0.2 source 10.0.0.1

配置完成后，通过查看命令确认domain状态为正常、peer-link为UP、keepalive为可达。到这里，MCLAG系统的"骨架"已经搭好，但还没有业务接口进来。

5.4 创建MCLAG接口并接入业务口

骨架搭好之后，接下来的任务就是把面向服务器的下行口加入MCLAG接口。这里有一个必须理解的概念：MCLAG接口本身是逻辑接口，真正承载流量的是加入了该MCLAG接口的物理成员口。

以服务器双归为例，A机的10GE1/0/10和B机的10GE1/0/10分别对应服务器的两个网卡口。在A机上：

interface Ethernet1/0/10 port link-type trunk port trunk allow-pass vlan 100 to 200 mclag 10 // 将该物理口绑定到MCLAG接口10

在B机上执行完全对称的操作。配置完成后，MCLAG接口10在两台设备上同时存在，系统会自动为它生成一个聚合组ID，并向服务器发送一致的LACP System ID，服务器就能把A、B两台设备的两个物理口聚合为一个逻辑链路。

配置时最容易踩的坑是成员口属性不一致——比如A机上端口是trunk而B机上是access，或者两边放行的VLAN不一致。MCLAG一致性校验虽然能在一定程度上发现问题，但有些厂商默认关掉严格校验，不一致的状态下接口也能UP，只是转发行为诡异。我建议配置完成后定期做一次双机配置比对，特别是成员口的VLAN配置，确保两边完全对称。

5.5 STP和MCLAG的协同配置

MCLAG系统本身就解决了环路问题，但接入侧往往还有其他二三层设备，整个网络仍然需要STP来做整体防环。这里的关键是：MCLAG的两台设备在STP域中需要表现为同一台桥，否则STP计算时会把对端当作环路的一部分，从而阻塞MCLAG成员口，让双活配置前功尽弃。

我习惯的做法是：调整A、B两台设备的STP优先级为相同值，比如都设为4096，然后在它们的互联口上关闭STP或配置为边沿端口，避免peer-link因为STP收敛被临时阻塞。具体参数因厂商而异，但思想一致：STP不能干预MCLAG域的成员口，MCLAG系统整体对外作为一个STP桥来参与生成树计算。

5.6 配置local-bias与最终核对

最后一步是检查并开启local-bias。不同厂商的默认行为不一样，有的默认开，有的需要手动配置。建议在完成基础配置后用文档核实一下当前设备是否启用了本地优先转发，如果没有就手动补开。然后做一轮完整核对：

• MCLAG domain状态：正常
• peer-link状态：UP，且控制VLAN互通
• keepalive状态：可达
• MCLAG接口状态：双活（两台设备上均为Active）
• 服务器网卡bond状态：聚合成功，两个成员口都UP
• STP状态：MCLAG成员口不在Blocking状态
• 用打流或持续ping验证业务转发

做完这些验证，一个基本可用的MCLAG双活系统就算落地上线了。

6. 状态查看、验证方法与排错清单

MCLAG部署完了，真正的考验才开始：日常怎么确认系统健康？出问题怎么快速定位？这一章把我平时最常用的状态查看命令、排查思路和容易踩的坑整理成清单。

6.1 常用的状态核对三件套

不管哪个厂商，MCLAG的日常巡检基本离不开三组命令：domain状态、peer-link状态、成员口/MCLAG接口状态。我习惯按下面步骤逐层往下查，每层都正常才认为整个系统是健康的：

# 第一层：查看MCLAG domain总体状态 show mclag domain # 预期输出：domain正常，keepalive可达，peer-link UP # 第二层：查看peer-link链路状态 show mclag peer-link # 预期输出：聚合口UP，成员口全部为Selected状态 # 第三层：查看MCLAG接口及成员口状态 show mclag interface show mclag verbose # 预期输出：MCLAG接口双活，物理口为UP且成员关系正常

这三层输出的组合，就能覆盖MCLAG系统的大部分健康度信息。我每天上班第一件事就是看一眼这三条命令的输出，确认没有异常状态变化。

另外推荐把所有关键状态都接入监控告警。peer-link的状态变化、keepalive的连通性、MCLAG接口的活性切换，这些一定要有告警，而且告警阈值要尽量敏感，宁多勿少。因为MCLAG的很多故障不是突然暴毙，是状态变化的累积，早期发现能避免很多后续事故。

6.2 针对常见故障的排错思路

MCLAG系统我排过错之后，发现高概率问题集中在下面这几个方向，我用一个表格把现象、原因、排查路径列出来：

排错时我的个人经验是：永远先看peer-link状态，再看keepalive状态，最后才看业务侧。因为MCLAG几乎所有的异常，归根结底都是"双活状态被破坏"或者"协同机制失效"，而这两个问题都直接反映在peer-link和keepalive上。

6.3 一个有代表性的实战排错案例

我遇到过一次印象很深的故障：某接入交换机突然出现大量广播报文，查看CPU占用率从百分之十几飙到百分之九十多。第一反应就是MCLAG可能出现了脑裂。我立刻登到A、B两台设备上查MCLAG状态，发现peer-link确实已经Down了，但keepalive还显示正常。继续看MCLAG接口，两台设备居然都处于Active状态，BUM流量的DF选举也出现了冲突——也就是说，两个设备同时认为自己应该转发广播帧，环路就这么形成了。

故障本身不复杂，但暴露了一个问题：为什么MCLAG状态机没有及时把一个设备上MCLAG成员口阻塞掉？排查配置后发现，peer-link中断之后，因为keepalive还通，系统理应进入降级阻塞流程，但这条路径上的状态切换被某些参数影响了，导致双活状态没有及时收敛。我当时的处理方式是手动把其中一台设备的MCLAG成员口shutdown，广播风暴立刻消失，然后去查peer-link恢复方案，链路恢复后再把成员口重新打开，MCLAG自动回到双活状态。

这个案例给我两个教训：第一，MCLAG防脑裂不能只靠设备默认行为，建议在实际组网里验证一次peer-link中断后的状态机走向，确认哪台设备会被阻塞，做到心里有数；第二，广播风暴发生时，先物理阻断环路再排查原因，一步一步来，不要试图一次性在界面上做太多操作。

6.4 日常运维中容易忽略的细节

最后说几个我从踩坑中总结的运维细节。

第一个是配置变更要谨慎。MCLAG的两台设备配置必须保持对称，任何一边单独变更都有可能打破一致性校验，导致成员口异常。所以做配置变更前，先看一眼对端是否有同样配置，最好用脚本比对两边配置，而不是凭记忆。

第二个是升级维护要讲究顺序。如果需要升级其中一台MCLAG设备，不要直接断电重启，建议先把该设备上的MCLAG成员口全部shutdown，让流量全部切到对端，再执行升级。这样对业务的影响最小，升级完成后重新打开成员口，MCLAG自动恢复。如果厂商支持维护模式，直接开启维护模式更方便，它能自动完成流量切换。

第三个是要关注光纤模块和跳线的质量。MCLAG系统依赖多条物理链路协同工作，任何一条链路的不稳定都会被聚合机制放大。我建议接入侧的光模块型号保持一致，不建议混用不同厂牌，物理链路抖动会导致LACP频繁协商，成员口反复上下线，严重时会把MCLAG系统的状态机搅乱。

实际上MCLAG这套技术用熟了之后，你会发现它并不神秘，核心就是"两台设备，一套逻辑"，所有的配置和故障处理都是围绕这六个字展开的。只要抓住peer-link、keepalive、MCLAG接口这三个核心组件，保持配置对称，日常巡检盯住状态变化，这套双活系统会非常稳定。我用MCLAG替换掉原来的堆叠方案之后，网络设备升级再也没让业务背过锅，单台设备故障的爆炸半径也被压缩到最小，这种"设备独立、转发共享"的思路，对于追求高可用的接入和汇聚网络来说，是一条值得走的路。