企业官网建设流程全解析

搞网络的朋友应该都有同感：链路聚合（Link Aggregation）这个技术，入门简单，但真到生产环境里，总有一层窗户纸捅不破。单台设备上的链路聚合，虽然能解决链路级冗余，但设备本身挂了，业务照样全断。MC-LAG（Multi-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可以看作是对“堆叠+跨设备链路聚合”的一种更稳的替代方案。

这里顺便做个对比，方便大家选型时心里有数：

堆叠不是不能用，在很多中小网络里它依然高效，但堆叠最怕的是分裂。两台设备之间一旦互联缆线松动或故障，堆叠系统会拆成两台配置相同、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业务口，总带宽80G，Peer-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/30，SW-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.2，peer-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上线后不是一劳永逸的，真正考验人的是运行期的故障处理。我整理了几个最常遇到的问题，按症状、可能原因、处理办法列成一张速查表。

这里最需要重视的是第一行“双主”问题。一旦发生双主，两台设备同时转发相同网段的流量，下联设备的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多久触发双主处理；把一台设备直接重启，记录另一台是否无缝接管。这些数据记录下来，后续真正出了故障，心里就有底。网络高可用从来不是靠设备参数堆出来的，而是靠把故障场景一个个提前演练出来的。