搞网络的朋友应该都有同感链路聚合Link Aggregation这个技术入门简单但真到生产环境里总有一层窗户纸捅不破。单台设备上的链路聚合虽然能解决链路级冗余但设备本身挂了业务照样全断。MC-LAGMulti-Chassis Link Aggregation跨设备链路聚合就是专门补这个短板的方案让两台独立设备“手拉手”对外呈现成一个逻辑设备下联设备的一条聚合链路可以跨两台设备落地。这篇文章我会把MC-LAG的由来、三个核心机制、一套可落地的配置过程以及我在现网里踩过的坑一起拆开讲适合数据中心运维、园区网工程师还有正在考虑用MC-LAG替代堆叠或双机方案的朋友。先说实话我最早听到MC-LAG这名字时心里想的是“这不就是把两台设备的端口绑一起吗”真到配置的时候才发现两台设备要想像一台设备一样对外转发流量背后涉及到表项同步、双主检测、水平分割这些机制任何一个环节没想明白割接现场就会给你颜色看。这篇文章就从“为什么需要它”开始一步步讲到怎么用它。1. 为什么网络里需要MC-LAG这个“双活”方案1.1 普通链路聚合最多只能防链路防不了设备先看最常用的场景。两台服务器各带双网卡做绑定分别接到同一台交换机上交换机上做一个链路聚合组这在很多机房是标准配置。但你想过没有如果这台交换机本身宕机了服务器双网卡绑定的链路再多也都落在同一台设备上所有成员口一起DOWN掉业务照样全断。这里的核心问题不是链路不够多而是设备的“单点”没有被解决。有人会说那就上两台交换机服务器一块网卡接A交换机另一块网卡接B交换机这不就双设备冗余了吗如果你直接把两块物理网卡绑成一个逻辑口分别接到两台不同的交换机上标准LACP是不同意的。LACP要求聚合组成员口必须在同一台设备上否则协商出来的状态是异常的。强行跨设备做普通聚合轻则链路报错重则出现MAC漂移、环路广播风暴网络直接被打挂。所以在这类场景里传统链路聚合的应用边界非常清楚它解决的是链路带宽和链路冗余不解决设备冗余。1.2 MC-LAG让两台设备变成一个逻辑节点MC-LAG要解决的就是上面这个“设备级冗余”的缺口。两台独立的交换机或路由器通过一条专用的互联链路通常叫Peer-link连接起来再通过Keepalive通道互相监测状态对外把两台设备模拟成一台逻辑设备。下联的服务器、接入交换机、安全设备等只需要配置一个标准的链路聚合组就能把成员口扩散到两台设备上。这种架构的好处非常多。首先是两台设备都处于转发状态不是传统主备模式那种“一台闲着等故障”利用率拉满。其次两台设备的控制平面互相独立OSPF、BGP这些协议各自运行避免了堆叠架构里整个系统共享控制平面、一台抖动全家遭殃的问题。第三升级维护时可以逐台操作把其中一台的设备流量切换走升级完再切回来业务中断窗口可以压得很小。我在实际项目中接触过的场景主要有三类数据中心里服务器双网卡接入到两台汇聚交换机、园区网里接入交换机双上联到两台核心/汇聚设备、还有不少政企内网在防火墙上做双机透明接入时也会用到类似机制。从网络架构演进的角度讲MC-LAG可以看作是对“堆叠跨设备链路聚合”的一种更稳的替代方案。这里顺便做个对比方便大家选型时心里有数维度单机链路聚合堆叠 跨设备聚合MC-LAG链路级冗余支持支持支持设备级冗余无设备仍是单点支持支持控制平面单设备独立多设备共享存在整体故障面各设备独立故障隔离性好升级影响面只影响本机整个堆叠系统一起受影响可逐台升级业务影响可控配置复杂度低中高中高典型故障风险设备宕机全断堆叠分裂、脑裂处理复杂双主检测、表项同步需要关注堆叠不是不能用在很多中小网络里它依然高效但堆叠最怕的是分裂。两台设备之间一旦互联缆线松动或故障堆叠系统会拆成两台配置相同、IP相同的“双胞胎”同时在线转发地址冲突和环路问题瞬间爆发。MC-LAG在设计上把“双主检测”作为一等公民来对待这也是它适合在生产环境长期运行的重要原因。2. 拆开MC-LAG看三个核心机制2.1 Peer-link两台设备之间的数据高速公路Peer-link是两台MC-LAG设备之间的专用互联链路它的作用有两个一是传输跨设备流量二是同步控制面表项。比如某台服务器的流量从A设备进来但目的MAC地址在B设备下面A设备就需要通过Peer-link把报文送过去。没有Peer-link这台服务器打算访问外部网络的数据就会直接“找不到门”。所以Peer-link的带宽不能拍脑袋定。我一般会按“单台设备全部业务口带宽之和的一定比例”来做规划至少不能低于单台设备上最重的业务流量比例。举个例子如果两台设备各接了8个10GE业务口总带宽80GPeer-link用两条10GE做聚合就是20G带宽那么一旦出现大规模的跨设备转发这20G很容易成为瓶颈。比较稳妥的做法是Peer-link的容量至少按单台设备业务带宽的40%到50%起步资金允许的话建议直接上万兆或100GE。Peer-link建议至少由两条物理链路做聚合并且把聚合模式设成LACP。这样做的好处很明显某一条物理链路或光模块故障时另一条还能继续工作不会因为Peer-link单链路闪断导致整个MC-LAG系统重新收敛。我见过很多现网事故都是因为Peer-link只有一根线某次光纤被误拔后整个网络大范围振荡这个“低成本省下来”的细节往往要付出高成本的代价。2.2 Keepalive与双主检测防止“脑子分家”在传统堆叠里堆叠线缆断了两台设备可能同时以同一身份工作这就是“脑裂”。MC-LAG专门设计了Keepalive机制来应对这种情况。Keepalive是一条独立于Peer-link的物理链路或带外管理通道两台设备通过周期性发送心跳报文来确认对端是否还活着。这里有个非常容易犯错的地方Keepalive不能和Peer-link共用同一根物理链路也不能走同一条逻辑路径。为什么因为Keepalive的意义就是在Peer-link出问题时还能互相通信。如果两者共享物理链路Peer-link断掉时Keepalive大概率也断了双主检测就成了瞎子。Keepalive一般建议用独立的三层接口配一个专门的互联网段甚至可以走管理网口只要管理网本身足够可靠就行。地址规划上我通常会选用一个不参与业务路由的独立网段比如169.254.x.x的开销网段避免和现网动态路由条目互相干扰。双主检测的判定逻辑也很值得理解当Peer-link故障但Keepalive仍能收到对端心跳时两台设备就会进入双主冲突处理流程。这时候设备会根据一个预先配置好的优先级或系统MAC来选举出谁是主设备主设备保持所有MC-LAG业务口正常工作备设备则会把自己的MC-LAG业务口全部置为DOWN从而保证同一时间只有一个“大脑”在转发流量避免环路和地址冲突。这个机制是MC-LAG相对于单纯堆叠最明显的安全优势。2.3 表项同步与本地优先转发要让两台设备对外看起来像一台光有链路还不够设备上学习到的MAC地址表、ARP表甚至部分路由信息都要通过Peer-link实时同步到对端。这样从A设备接入的东西向流量如果目的端在B设备下面A设备也能知道从Peer-link转发过去可以到达。不过如果所有流量都必须跑Peer-link绕一圈网络效率会很差。因此MC-LAG里普遍还有一个“本地优先转发”原则流量进入某台设备后如果目的MAC对应本机的下行端口就直接本机转发不绕对端。这个特性对降低Peer-link压力、降低转发时延非常关键。我自己在做方案规划时如果下联设备侧流量呈现明显的“南北向为主”会尽量让服务器和接入设备合理分布让流量尽量落到同一台设备上Peer-link只承担必要的灾难兜底和跨机流量。水平分割机制也需要特别留意。为了避免环路MC-LAG规定从某个MC-LAG业务口收到的报文不会再从另一个MC-LAG业务口发出去只能通过Peer-link转发给对端设备由对端决定是否从它的业务口发出。这样做保证了整个MC-LAG系统在二层拓扑中不会形成环这也是为什么MC-LAG在工作正常时可以不依赖STP阻塞端口的根本原因。理解这条规则后你在排查“明明业务口都是UP、但转发就是不通”的问题时方向会清晰很多。3. 实操演练把一套MC-LAG从规划到落地跑通3.1 先规划再动手拓扑、IP与带宽怎么定纸上谈兵讲完机制接下来做一套典型配置。假设场景是两台汇聚交换机分别命名为SW-A和SW-B下面接一台接入交换机或一台服务器接入侧需要双归到这两台汇聚设备要求任意一台汇聚设备宕机业务不中断。规划时先做四件事第一确定Peer-link使用聚合口里面放两条万兆物理口第二确定Keepalive使用两个独立三层接口规划一段专用地址比如SW-A是10.254.1.1/30SW-B是10.254.1.2/30第三确定MC-LAG系统MAC地址这个MAC在两台设备上必须保持完全一致对外它代表“整个MC-LAG系统”第四规划业务侧的接入方式接入交换机或服务器侧也要做链路聚合模式建议LACP动态聚合。我一般会把MC-LAG的系统MAC统一定成我们自己规划的固定值而不是让两台设备自动协商这样出故障时排查起来更好辨认。很多主流设备默认会自动生成一个系统MAC两台设备协商后对外保持一致但手动规划一个更容易记忆也方便跨厂商排查。3.2 配置步骤以主流商用设备的命令行过程为例下面这组命令以业界常见的配置风格为例不同厂商的关键字会有差异但配置逻辑完全一致。配置之前建议先给两台设备对好时间做好配置备份再逐台操作。先配置Peer-link。在SW-A和SW-B上分别创建聚合口把两条物理光口加进去允许必要的VLAN通过并绑定为MC-LAG的Peer-link。# SW-A 和 SW-B 都需要配置这里以SW-A为例 interface Eth-Trunk 1 description MCLAG-Peer-Link port link-type trunk port trunk allow-pass vlan all link-aggregation mode lacp mclag peer-link 1然后配置Keepalive。在SW-A上创建一个专用的三层VLAN接口配置IP为10.254.1.1/30在SW-B上配置为10.254.1.2/30。Keepalive报文一般走UDP设备之间能互相Ping通即可。# SW-A interface Vlan 4094 description MCLAG-Keepalive ip address 10.254.1.1 255.255.255.252 # SW-B interface Vlan 4094 description MCLAG-Keepalive ip address 10.254.1.2 255.255.255.252接着创建MC-LAG域绑定Peer-link和Keepalive。这个域就是“两台设备协同工作”的总开关同时配置前面规划好的系统MAC。# SW-A 和 SW-B 都需要配置 mclag domain 1 peer-link 1 keepalive vlan 4094 peer-ip 10.254.1.2 source-ip 10.254.1.1 mclag system-mac 0000-5e00-0101注意SW-B上的source-ip要改成10.254.1.2peer-ip改成10.254.1.1。这是最容易看错的地方我在现场配置时就在这上面栽过跟头两台设备Keepalive的源和目的填反结果双向心跳都不通。业务口配置。把两台设备上接向下联设备的物理口加入同一个Eth-Trunk并绑定到MC-LAG域下的同一个MC-LAG组ID。# SW-A 和 SW-B 都需要配置组ID必须一致 interface Eth-Trunk 10 description MCLAG-Business-To-Access port link-type trunk port trunk allow-pass vlan 10 20 link-aggregation mode lacp mclag 1如果你之前只配置过单机链路聚合看到这段命令会有一种“这不就是普通Eth-Trunk嘛”的感觉。区别就在最后的“mclag 1”这条它把本机的Eth-Trunk 10标记为MC-LAG组1的成员同时告诉设备这个聚合口允许跨设备协同工作。下联设备上也同样做链路聚合把两个物理口绑定成一个逻辑口并启用LACP。这样从下联设备看过去它是在跟“一台”汇聚设备建立聚合关系而这台“聚合设备”其实由SW-A和SW-B共同组成。最后是辅助配置。如果MC-LAG设备需要作为网关通常会在两台设备上配置相同的VRRP虚拟IP如果跑二层注意STP配置也要配合避免不必要的阻塞。这些属于场景化配置按实际需求来。3.3 配置完必须做的事验证和观察配置完成后不能急着切业务。先做一轮状态检查看MC-LAG域是否协商成功、Peer-link是否正常、Keepalive是否双向可达、两个成员口是否都在MC-LAG组里正确挂载。不同设备查看命令有差异但通常会有类似display mclag summary、display mclag peer-link这样的查询入口。我每次配置完都会手动做两个测试。第一个是断一台设备的业务口看下联设备聚合成员口会不会自动切换业务丢包控制在几秒内第二个是直接拔掉两台设备之间的Peer-link光纤观察Keepalive是否能在极短时间内检测到Peer-link故障并进入双主冲突处理。这两项测试做完MC-LAG的基本可靠性才算真正被验证过。还有一点值得注意配置顺序会影响业务中断窗口。如果先配SW-A再配SW-B在SW-B还没配置完成时两台设备的MC-LAG状态不对齐下联聚合口可能出现短暂DOWN。所以我在割接窗口里通常先把两台设备上的配置全部下发完再最后把下联设备切换成M-LAG模式尽量把对业务的影响集中在一个可控的切换点上。4. 常见故障速查与实战避坑4.1 命中的典型故障与排查方式MC-LAG上线后不是一劳永逸的真正考验人的是运行期的故障处理。我整理了几个最常遇到的问题按症状、可能原因、处理办法列成一张速查表。故障现象可能原因排查与处理办法两台设备同时转发出现IP/MAC冲突Peer-link中断Keepalive未正确检测到双主检查Peer-link物理链路检查Keepalive是否使用独立链路核对双主检测优先级配置MC-LAG业务口状态不一致一端UP一端DOWN两台设备上MC-LAG组ID不一致或业务口配置不同逐项比对两端业务口配置确认组ID、VLAN配置完全一致下联聚合口协商不起来下联设备未配置LACP或LACP系统优先级不一致在下联设备上配置动态LACP模式检查两端聚合参数跨设备流量丢包严重Peer-link带宽不足或跨设备流量过大查看Peer-link端口统计评估是否需要扩容尽量优化本地优先转发MAC地址频繁漂移表项同步异常或存在环路路径检查Peer-link状态和表项同步日志确认水平分割机制生效这里最需要重视的是第一行“双主”问题。一旦发生双主两台设备同时转发相同网段的流量下联设备的MAC表会在两台设备之间来回震荡交换机CPU可能直接被打满。排查时要先确认Peer-link和Keepalive这两条通路到底谁出了问题再确认优先级选举是否正常。不要急着拔线先看状态输出再决定隔离哪一台。4.2 我踩过的几个坑和修复过程第一个坑是Keepalive和业务路由串网段。当时图省事Keepalive地址直接用了业务VLAN里的一个空闲IP结果动态路由协议把到对端Keepalive地址的路由也学习进来了导致心跳报文绕了外层网络一圈Peer-link断掉后心跳竟然还在设备判断对端存活但实际上数据面已经断了故障表现非常诡异。后来我把Keepalive独立到一个专门的VLAN并且不参与业务路由问题再没出现过。第二个坑是Peer-link带宽规划不足。一套汇聚设备下挂了大量接入交换机东西向流量很大Peer-link只有两条万兆高峰期打满跨设备时延飙升业务侧投诉“网络时快时慢”。查了很久才发现Peer-link端口拥塞严重。后来我在规划阶段就把“跨设备流量占比”这个变量考虑进去Peer-link按业务峰值估算后做冗余才彻底解决。第三个坑是升级操作顺序不对。有次给其中一台设备升级按习惯先升级备设备准备切主备时发现业务口全部DOWN掉了。原因是升级过程中设备重启后MC-LAG表项还没同步完成优先级判断出现了短暂紊乱。后来我的升级流程固定为先检查两台设备版本兼容性再逐台执行“关闭MC-LAG组成员口 - 升级 - 确认表项同步完成 - 重新开启成员口”保证任何时刻都有一台设备承载业务。第四个坑比较隐蔽也和下联设备有关。接入交换机的LACP模式有很多种有静态聚合、动态聚合、强制聚合等等。MC-LAG下联场景通常要求动态LACP但部分老交换机默认跑静态聚合两边协商不一致聚合口反复UP/DOWN。这个问题在对接不同厂商下联设备时经常出现排查时记得先看下联设备聚合口的工作模式和协商报文统计。还有一个小细节提醒一下有的设备MC-LAG和STP同时开启时默认会把Peer-link视为一种特殊端口或者把MC-LAG体系内的业务口强制放开阻塞状态。这是因为设备内部有相应的防环逻辑。如果你在现网里强制改了STP优先级或端口角色可能会破坏这些保护机制。建议在没完全搞懂设备内部防环逻辑之前先保持MC-LAG相关的STP默认行为不变。我在实际部署中还有一条“不能省”的底线MC-LAG的Keepalive链路无论如何都建议走独立物理路径最好连光模块、板卡、电源都尽量分开。信道分离做得越彻底双主检测的可靠性就越高。网上很多案例里MC-LAG翻车就是翻在Keepalive这条“救命通道”上。最后再分享一个习惯我每次新上一套MC-LAG都会在验收阶段主动做一次“破坏性演练”。把Peer-link拔了记录业务中断多少秒Keepalive多久触发双主处理把一台设备直接重启记录另一台是否无缝接管。这些数据记录下来后续真正出了故障心里就有底。网络高可用从来不是靠设备参数堆出来的而是靠把故障场景一个个提前演练出来的。