1. 两台交换机只能跑STP吗——接入双归的带宽困境我在一次汇聚层设备割接中碰上了这个经典难题核心下挂的两台汇聚交换机要升级但业务完全不能断。最常规的方案无非两种一是靠STP生成树协议做冗余备链路平时就堵着二是两台设备做堆叠变成一个逻辑设备。两种方案我都不太想选因为我既想要设备级的独立冗余又不想把一半的互联带宽白白浪费掉。先说STP这条路。很多网络里到现在还在用STP家族做二层冗余它的逻辑很简单物理上造环逻辑上破环通过阻塞某个冗余端口来防止广播风暴。代价很直观——那根被阻塞的链路平时完全闲着带宽在那摆着却不走流量只有主链路断了才会切换过去。更麻烦的是收敛时间虽然RSTP快速生成树协议能把收敛压到秒级以内但在一堆依赖视频流、语音会议的业务面前哪怕一两秒的中断都足以让用户开始抱怨。你说可以调参数优化能调但STP的收敛本质上就是重新计算拓扑、重新选举根桥、重新迁移端口状态这一套流程再怎么加速也有它自己的物理天花板。再说堆叠这条路。堆叠确实能解决STP浪费带宽的问题两台设备通过堆叠口变成一台逻辑设备下行链路可以跨框做聚合两条链路同时转发一台设备宕了另一台还能扛住。但是堆叠的痛点在于控制面耦合太强——两台设备共用一份控制面状态主设备挂了备设备要接管中间有一个系统重启级别的切换过程不是所有厂商都能做到完全无感的。更让我顾虑的是升级场景堆叠系统升级往往要求整堆重启这对核心业务来说几乎是不可接受的。而且堆叠一旦出现分裂两个框都以为自己是主很容易把整张网络搞出大问题。两种方案都不完美所以我把目光放在了MCLAGMulti-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上接入了一台终端TB上接入了一台主机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和常见替代方案的关键差异整理成一个表格对比维度STP/RSTP方案堆叠方案MCLAG方案冗余链路利用率低备链路被阻塞高跨框聚合后全用高跨设备聚合后全用控制面两台各自独立统一控制面主备耦合两台各自独立设备故障切换依赖STP收敛有中断主备切换有短暂中断数据链路自动重哈希几乎无感升级维护可单台操作但切换有代价通常需要整堆重启或逐台升级风险高可单台隔离升级业务影响小故障域单台设备独立控制面共享一台异常可能波及整堆单台设备独立故障隔离性好配置复杂度低中中高从这个表能看出来MCLAG最突出的价值就是既保留了设备独立性又实现了高带宽利用。代价是概念和配置比传统方案多了一层需要运维人员真正理解它的工作原理而不是照抄配置。3. 双活不环路的底层逻辑LACP视角、MAC同步与BUM流量抑制MCLAG表面上看着像链路聚合实际上它最精妙的地方在于两台设备的控制面是独立跑的但数据面要协同工作且不能成环。下游设备把MCLAG接口当作一台设备来发流量流量哈希到A或者B之后转发行为必须和单台聚合交换机保持一致。要做到这一点底层有三大机制LACP双归协商、MAC地址同步、BUM流量抑制。我分别拆开讲。3.1 下游设备视角LACP如何把两台设备看成一台LACP协议本身是一种端口协商机制聚合链路两端的设备通过交换LACPDU链路聚合控制协议数据单元来确认哪些成员口可以加入同一个聚合组。普通场景里一个聚合组的所有成员口都在同一台交换机上所以LACP协商只发生在两台直连设备之间。MCLAG场景里服务器上做了网卡bond通常配成LACP模式两根线分别插到A、B两台交换机上。服务器发出的LACPDUA收到一份B也收到一份。如果A、B都独立应答服务器会认为自己在和两台不同的设备做LACP协商根本无法形成一个聚合组。MCLAG的解决方法是A、B两台设备在LACP协商中用同一个系统IDSystem 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 ForwarderDF选举机制。简单说对于任何一个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的流量全部转移到BB的下行带宽可能瞬间翻倍。如果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地址第一步先把规划做好这是整个部署里最不能省的一环。我习惯先把下面这张表填清楚再动手配置规划项A机取值B机取值说明peer-link接口10GE1/0/1、10GE1/0/210GE1/0/1、10GE1/0/2两台之间跨接建议至少2条物理链路做聚合keepalive接口管理口/独立三层口管理口/独立三层口必须与peer-link物理隔离互联IP10.0.0.1/2410.0.0.2/24keepalive链路使用的地址MCLAG domain ID11两台必须一致业务VLANVLAN 100-200VLAN 100-200放行范围必须一致MCLAG接口编号MCLAG 10MCLAG 10两台必须一致对应同一个逻辑聚合口这张表里最容易出问题的是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 4090keepalive走独立通道时需要注意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状态聚合成功两个成员口都UPSTP状态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系统我排过错之后发现高概率问题集中在下面这几个方向我用一个表格把现象、原因、排查路径列出来现象可能原因排查路径MCLAG接口Down或单边Activepeer-link状态异常、domain ID不一致、成员口配置不对称先查peer-link是否UP再看domain ID两边是否一致最后比对成员口VLAN配置服务器bond聚合成两条独立链路LACP System ID不一致核对MCLAG domain ID是否一致确认设备是否正确启用了MCLAG模式广播风暴/环路告警peer-link中断后出现脑裂DF选举失败立即检查keepalive是否正常确认是否有中断记录必要时人工阻塞非主设备MCLAG成员口跨设备流量丢包peer-link带宽被打满、local-bias未开启查看peer-link带宽利用率检查local-bias机制是否生效分析流量哈希是否严重倾斜MAC表项不稳定MAC同步异常或表项超时查看MAC表同步计数确认MAC表项是否有异常抖动配合抓包看MAC漂移情况排错时我的个人经验是永远先看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替换掉原来的堆叠方案之后网络设备升级再也没让业务背过锅单台设备故障的爆炸半径也被压缩到最小这种设备独立、转发共享的思路对于追求高可用的接入和汇聚网络来说是一条值得走的路。