RED韵做了快十年的网络运维，我被问得最多的问题其实很朴素：服务器明明插了两根千兆网线，为什么拷贝文件的速度始终越不过一千兆；核心和汇聚之间明明不止一条物理链路，坏掉一根后业务还是会中断。这些问题背后基本都是同一个技术方向——链路聚合和链路备份技术。简单说，链路聚合是把多条物理链路捆绑成一条逻辑链路，让带宽可以叠加，也让某条成员链路失效时流量能自动被其他链路接管；链路备份技术则是在这个基础之上，把部分成员链路定义为活动、部分定义为备份，用协议和策略保证关键业务不因单条链路故障而中断。这篇文章我会按“原理—配置—验证—避坑—架构定位”的顺序，把聚合链路讲透，新手能照着做实验，老手也能从排障经验里找到一些共鸣。
1. 为什么单条物理链路让人又爱又恨：带宽瓶颈与单点故障并存
1.1 单链路在大流量场景下的真实困境
咱们先把问题落到实际场景里。假设你维护一个视频监控存储平台，1000路摄像头同时在往存储服务器写数据，每路码流按4Mbps算，总流量就是4Gbps。就算存储服务器上只插一个万兆口，其实也已经到了极限。更常见的尴尬是：服务器只有千兆网口，存储阵列也只有千兆网口，但业务要求稳定跑1.5Gbps。这时候如果你只会跟业务方说“升级万兆网卡”，人家大概率会反问：机房布线全是六类线，万兆电口能不能跑得稳？就算能跑，交换机上的万兆板卡、光模块采购周期又是多久？
我在实际项目里见过不少单位为了规避这个采购周期，直接在服务器上插三四根网线，然后天真地以为流量会自动分散。结果是：只有一根网线在跑，其他几根一点流量都没有，交换机侧甚至出现大量广播风暴。原因很简单，一台物理服务器如果没有做网卡绑定，多个网口各自拥有独立IP，操作系统根本不会把一条TCP连接劈成好几份往不同网口发。TCP是有序字节流，它依赖五元组做连接标识，除非上层应用专门做多路径传输，否则单条流只会固定在某个网口上。
真正能解决这个问题的，必须是在交换机端和服务器端同时配置链路聚合。交换机把两个物理口绑成一个Eth-Trunk逻辑口，服务器把两块物理网卡绑定成一个bond口。两者协商成功后，二层转发逻辑就把这个聚合口当作一个普通端口来用，流量才会按哈希算法分散到各条物理链路上。链路聚合的核心价值首先就是“把N条链路从逻辑上变成一条用”，而不是让设备傻乎乎地自己轮流发。
1.2 简单堆叠多根网线能不能解决问题
有些入门者会觉得，我不做任何聚合，直接把两台交换机用两根网线连起来，不就多了一条备份吗？这句话只对了一半。两台交换机之间只用多根普通线直连，不跑聚合协议，生成树协议STP会立刻介入，它会Block掉其中一条物理链路，只保留一条作为转发链路。换句话说，你物理上接了两根线，逻辑上还是只有一条通。这样确实避免了环路，但带来的结果不是带宽翻倍，也不是自动备份，而是另一条链路被当成“废口”一样闲置。
如果这时候你把STP关掉，两台交换机之间又是普通二层互联，那么一旦收到广播帧，就会在网络里形成广播风暴，两台交换机之间的帧会反复泛洪，整个广播域都废掉。STP能解决环路，但不能把链路用好；链路聚合能解决环路和带宽问题，因为它把多条物理链路抽象成一个逻辑口，从生成树的角度看只有一条逻辑链路，没有环路需要Block。这两者之间的区别，是所有做链路聚合实验的人必须想明白的第一课。
所以链路聚合并不仅是“多插几根线”这种物理动作，它是一套协商机制：交换机和交换机之间要认可能够把哪些口放进同一个聚合组，以什么样的模式协商，数据帧到了聚合口之后应该按什么规则选择成员口出去。只有这些问题都由协议和数据平面逻辑处理好了，多根网线才会真正变成可用资源。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 链路聚合到底聚合了什么：从协商机制到数据转发逻辑
2.1 聚合组、成员端口、聚合接口的三层关系
如果你打开华为交换机的配置界面，会看到“Eth-Trunk”这个逻辑接口；如果看思科设备，对应叫Port-Channel；H3C里叫Bridge-Aggregation；服务器网卡绑定则通常叫Bond、Team或Link Aggregation Group。名字五花八门，本质都一样。
这里面有三个层级需要理清：
- 物理成员端口：比如GigabitEthernet0/0/1和GigabitEthernet0/0/2，它们是真实存在的接口。
- 逻辑聚合接口：比如Eth-Trunk 1，它代表一组物理成员端口的集合，对上层协议（VLAN、三层路由、ACL）只暴露这一个逻辑口。
- 聚合组成员关系：物理口加入Eth-Trunk之后，不能再单独配置IP、VLAN、ACL等业务参数，这些参数只能在Eth-Trunk接口上统一配置，成员口必须继承聚合口属性。
有个最容易犯的错：在新手实验里，有人先在两台交换机上分别配置好物理口，比如在GE0/0/1下面配了access vlan 10，然后才想起来要做聚合，把GE0/0/1加入Eth-Trunk 1，结果发现配置冲突，或者加入后之前配的业务属性全部失效。原因正是逻辑聚合口才是业务配置唯一入口，物理口在加入聚合组之前，单独配置的接口属性必须清干净，或者先shutdown再操作。
为什么要设计成这种“对上统一、对下隐藏”的结构？因为交换机希望把聚合口当做一个整体来参与各种协议计算。无论成员口有两条还是八条，生成树只会看到这个逻辑口，MAC地址表也只会记录这个逻辑口所对应的出接口，这样就不会出现同一个MAC地址从多个物理口学习到的冲突。
2.2 数据平面里的负载分担哈希：不是轮流发送那么简单
聚合链路的带宽叠加是大家最关注的卖点，但你得知道它并不是简单的“第1个包走口1，第2个包走口2”这种轮流策略。交换机内部使用哈希算法来决定某个数据帧从哪个成员口转发。
常见哈希因子包括源MAC、目的MAC、源IP、目的IP、源端口、目的端口等。一个典型的二层接口聚合口可能采用“源MAC+目的MAC”计算哈希，三层聚合口则可能采用“源IP+目的IP”或“源IP+目的IP+四层端口”。每次需要转发数据帧时，交换机把帧里的这些字段提取出来，做一个CRC或类似运算，得到一个哈希值，再对组成员数量取模，最终落定到某个具体成员口。
这种机制决定了三条铁律：
第一，同一数据流（比如同一条TCP连接）只会走同一个成员口，不会乱序。TCP一旦乱序，性能会雪崩，所以哈希算法必须保证流保序。
第二，不同数据流会尽量分散到不同成员口，但“尽量”不等于“均匀”。如果流量特征很单一，比如只有一台服务器通过NFS挂载一大文件，源IP和目的IP固定，那么无论你怎么哈希，大概率都会命中同一个成员口，其他链路闲着，只有一条链路被跑满。
第三，要增加聚合链路的利用率，最好让业务流量具备更多的IP或者四层端口多样性。如果业务就是单点到单点的巨型流，物理上就只有通过提高单链路速率来解决，链路聚合帮不了你。
在华为设备上可以用 load-balance 命令调整哈希因子。比如三层链路，你想兼顾IP和端口，可以配置：
code复制interface Eth-Trunk 1
load-balance src-dst-ip
但要注意，不同型号交换机支持的哈希因子集合不一样。有的老款只能支持src-mac、dst-mac、src-ip、dst-ip这种粗粒度选项，新款可能支持src-dst-ip-l4port、tuple1/tuple2这种高级选项。选型之前最好先查一下硬件芯片的哈希能力，否则配置敲上去不生效，还以为自己命令记错了。
2.3 一条成员链路断开之后，流量怎么接管
链路聚合之所以能承担“备份”职责，依靠的是成员链路状态的快速感知。当某个物理端口因网线断开、光模块故障或对端设备掉电而变成Down，交换机的驱动会立刻感知到端口状态变化，并从聚合组中摘除这个成员口。
这里的关键是：聚合口并不会因为一个成员口Down了就整体Down掉，除非你把最小活动成员数设置成了聚合组全部成员数。正常情况下，聚合口继续保持Up，数据转发引擎会重新计算剩余活动成员口对应的哈希表，把原本哈希到故障成员口的流量重新分发给其他存活成员口。
从效果上说，TCP长连接可能会感受到短暂的重传，但连接本身大概率不会断开。切换时间取决于设备实现，一般硬件级别检测在几十毫秒以内，软件轮询则会慢一些，但绝大多数聚合实现都能做到秒级以下。如果你用连续ping来测试，丢包数量通常是一个或两个，不会出现长时间中断。
还有一个重要细节：聚合链路故障恢复后，成员口重新协商加入聚合组，也需要一定时间。在LACP模式下，端口需要经过协商、同步、收集分散等几个状态历史，才可能被置为Up；在手工聚合模式下，只要物理口Up，驱动会直接尝试把它加回聚合组。恢复速度比LACP快，但牺牲了协议校验能力。这两种模式的选择，本身就是备份粒度设计的一部分。
3. 链路备份的常见形态：手工聚合、LACP与联动保护
3.1 手工静态聚合：配置简单但备份能力有限
手工静态聚合，也叫手动负载分担模式，是指管理员在两端交换机上手工创建Eth-Trunk，然后把成员物理口一个一个加进去。由于没有协商协议，链路两端无法通过报文确认对方是否同样把对应端口加进了聚合组，完全依赖人工配置一致性。
这种模式的优势是配置直观、不依赖协议报文，在某些纯二层设备或跨厂商设备互联时特别好使。只要两台交换机都老老实实地把物理口放进聚合口，配置一致，转发就能正常。坏处也很明显：如果对端某个口没有加入聚合组，或者两端物理口速率不一致，本端并不知道，照样往外发帧，结果可能造成丢包、错序甚至二层环路。
举个例子：你在本端把GE0/0/1和GE0/0/2都放进了Eth-Trunk 1，但对端只把GE0/0/1放进了自己的聚合组，GE0/0/2还保留为普通口。本端发往对端的数据会从两个口出去，但对端收到从GE0/0/2进来的帧时，发现这个口不是聚合成员，就会按普通二层口处理。如果这个普通口也属于相同VLAN，可能形成环路；如果VLAN不通，则直接丢弃。这种“假聚合”故障排查起来很隐蔽，因为它不报错，只是链路利用率异常或者某类流量不通。
所以我个人的建议是：只要两端设备都支持LACP，就尽量别选手工静态聚合。手工模式更适合设备太老、协议栈有Bug或者需要跟某些服务器网卡绑定兼容的特殊场景。
3.2 LACP动态聚合：用协议协商代替人工判断
LACP是IEEE 802.3ad标准里的链路聚合控制协议，后来被802.1AX继续维护。它在两端设备之间周期性地发送LACPDU报文，互相通告自己的系统优先级、系统MAC、端口优先级、端口编号等信息，然后通过算法确定哪些端口可以成为活动成员，哪些端口只能作为备份成员。
LACP把端口身份拆成三层逻辑：
- 系统优先级高低决定哪一端可以主动控制聚合端口选择。
- 端口优先级决定在活动成员数量受限时，优先使用哪些端口。
- 成员口通过LACPDU里的Actor和Partner状态机，确认双方协商一致后才能进入聚合状态。
这样一来，LACP动态聚合比手工聚合多了两个关键能力：一是自动检测两端配置是否匹配，不匹配时端口不会进入转发状态；二是可以显式设置活动成员数上限，把多余端口作为备份端口。后者就是“链路备份技术”最典型的一种落地：假设设备之间接了4根光纤，但你只想让2根同时工作，另外2根热备。LACP可以做到这一点。
以华为设备为例，配置一个4成员口、最大活动数为2、最小活动数为2的LACP聚合：
code复制interface Eth-Trunk 1
mode lacp-static
lacp max active-linknumber 2
lacp min active-linknumber 2
quit
interface GigabitEthernet0/0/1
eth-trunk 1
quit
interface GigabitEthernet0/0/2
eth-trunk 1
quit
interface GigabitEthernet0/0/3
eth-trunk 1
quit
interface GigabitEthernet0/0/4
eth-trunk 1
quit
此时两端会先协商出系统优先级较高的一端作为主动端，由主动端决定哪两个端口作为活动成员，其余端口进入Standby状态。当某一个活动成员Down掉，Standby端口会自动顶上来。这里最大的价值在于：备份链路平时是不转发数据的，但一旦主链路故障，切换是协议自动完成的，不需要人工拔线重插。
你再想想刚才说的“只插两根线不配聚合”的问题，还有“接四根线只能走两根”的问题。LACP模式就在物理冗余之上增加了一层逻辑冗余，它才是真正的“链路备份技术”，而普通手工聚合只是把多条链路做成带宽池，不做主备角色区分。
3.3 接口备份和Monitor Link：链路聚合之外的另一种“保险”
链路聚合解决的是多链路之间的负载和备份，但有些场景下，你根本没法把上下游端口聚合在一起。典型例子是：核心交换机只有单条光纤接到运营商的出口路由器，你想再加一条光纤作为备份，但运营商侧设备不支持链路聚合，或者出口路由器的两个端口无法绑定。
这时候可以做接口备份。所谓接口备份，就是在设备上指定主接口和备份接口，当主接口Down掉，备份接口自动接管业务；主接口恢复后，流量再回到主接口。它跟链路聚合完全是两种思路：链路聚合是多个口同时工作互为备份；接口备份是“一主一备、平时备口不干活”，更节省逻辑资源，但切换速度可能不如聚合快。
华为设备上可以在接口视图下用类似配置实现：
code复制interface GigabitEthernet0/0/1
standby interface GigabitEthernet0/0/2
当GE0/0/1物理状态Down后，GE0/0/2自动被启用。这种方式简单粗暴，适合专线、NAT出口等场景。不过它通常只检测物理层状态，如果链路物理Up但协议层异常，比如对端光模块故障导致收光异常但发光正常，可能不会触发切换。生产环境里需要结合BFD或NQA做上层探测，否则备份形同虚设。
另外还有一种叫Monitor Link的技术，用于跨设备联动端口状态。比如接入交换机A的上行口连接汇聚交换机C，下行口连接服务器。当上行口Down掉，接入交换机希望通过下联口也进入Down状态，好让服务器的网卡bond感知到链路故障并触发切换。Monitor Link本质上就是把上行口状态映射到下行口，让故障传播得更快、更可控。它不直接参与链路聚合，但经常和链路聚合、网卡绑定配合使用，属于联动保护方案。
4. 一次能复现的链路聚合实验：从拓扑规划到故障切换验证
4.1 实验设备与拓扑规划
说到链路聚合实验，很多人在模拟器里点两下就完事了，但真实网络里的坑往往在模拟器里根本出不來。我建议有条件的人最好拿真机或至少用eNSP、GNS3做一次完整练习。
实验拓扑可以做成这样：
- SW-A和SW-B是两台二层交换机，之间用GE0/0/1、GE0/0/2两根线互联。
- 两台交换机创建一个VLAN 10，用于业务互通。
- PC-A接SW-A的GE0/0/10，PC-B接SW-B的GE0/0/10，两台PC配置同一网段地址，例如192.168.10.1/24和192.168.10.2/24。
- SW-A和SW-B之间的Eth-Trunk 1作为trunk口，放行VLAN 10。
这个拓扑虽然简单，但足够验证两个核心问题：带宽是否叠加、故障时是否无缝切换。
规划时注意一个细节：做链路聚合的两台交换机，系统MAC、系统优先级这些参数要保持合理设计。在LACP模式下，两端系统优先级如果都相同，就靠系统MAC比较大小决定主动端。对于实验来说无所谓，但生产环境里最好手动指定主备优先级，保证主动端是你能控制的那台。
4.2 静态聚合配置实例与操作要点
先做手工静态聚合。在SW-A上：
code复制system-view
sysname SW-A
vlan batch 10
interface Eth-Trunk 1
port link-type trunk
port trunk allow-pass vlan 10
quit
interface GigabitEthernet0/0/1
eth-trunk 1
quit
interface GigabitEthernet0/0/2
eth-trunk 1
quit
interface GigabitEthernet0/0/10
port link-type access
port default vlan 10
quit
SW-B上做相同配置，只是主机名不同。关键点在于：Eth-Trunk接口必须先创建并配置好二层属性，再把物理口加入。如果你先把物理口加入聚合口，再去配置Eth-Trunk的VLAN属性，物理口也会同步继承，这是一样的效果。但如果物理口已经是access口且划到了其他VLAN，加入Eth-Trunk时会提示接口属性冲突，需要先把物理口恢复成默认配置。
配置完成后，用 display eth-trunk 1 查看。如果你看到两个成员口状态都是Up，且Total Ports数量为2，说明聚合成功了。这时候你在PC-A上持续ping PC-B，同时断开任意一根互联线，正常情况下只会丢一个包或者完全不丢包，这个测试放在后面的故障验证里一起做。
4.3 LACP模式配置实例与关键参数说明
手工聚合验证通过后，可以把两台交换机的Eth-Trunk 1删掉，改成LACP动态聚合模式，看看协议协商带来的状态变化。
在SW-A和SW-B上统一做：
code复制interface Eth-Trunk 1
undo portswitch
undo port link-type trunk
undo port trunk allow-pass vlan 10
mode lacp-static
port link-type trunk
port trunk allow-pass vlan 10
lacp max active-linknumber 2
lacp min active-linknumber 2
quit
注意：mode lacp-static 在华为VRP里不是指“静态手工聚合”，而是指“静态LACP聚合”，即LACP协议报文虽然是动态协商，但没有启用LACP快速切换的增强功能。所谓Fast Switchover在部分设备上需要额外开启。两条链路都up时，它们都会成为活动成员，同时转发流量。如果只有一条链路Up，Eth-Trunk依然能正常工作，因为最小活动链路数设置为了2，这里要小心。
lacp min active-linknumber 2 的意思是：当活动成员数小于2时，Eth-Trunk逻辑口会Down掉。这个参数在做“链路备份”时特别重要。比如两端之间接了4根线，你希望任何情况下至少保证2根在工作。但如果网络里正好有一根光模块不稳定，拔掉后只剩1根活动链路，逻辑口直接Down掉，而不是继续以1根链路的降级模式转发。这样设计的好处是：避免流量进入带宽不足乃至黑洞的状态，配合上层路由协议或服务器bond，可以更快触发备路径切换。
如果你想做“2活动+2备份”的4线拓扑，可以再加两条物理口，并保持 lacp max active-linknumber 2 不变，其他两个口就会自动进入Standby状态。通过 display eth-trunk 1 能看到“Standby”标记，这就是备份链路在待命。
4.4 验证链路备份效果：拔线之后到底丢多少包
实验做完配置后，不是看一眼Up就收工，验证才是真正有价值的部分。我习惯用三组测试来验证链路备份效果。
第一组是长ping测试。在PC-A上执行：
code复制ping 192.168.10.2 -t
这里-t是Windows连续ping的参数，Linux下应该用ping 192.168.10.2，它会一直发。在ping持续期间，拔掉SW-A和SW-B之间的一根网线。看ping的统计结果，丢包个数通常为0到1个。如果丢包很多，比如十几个甚至断流几秒，说明聚合链路没有起到预期的备份作用，要从成员口状态、STP、对端协商几个方向查。
第二组是带宽测试。在PC-A上跑iperf客户端，PC-B上跑iperf服务端：
code复制iperf3 -s
iperf3 -c 192.168.10.2 -P 8 -t 30
-P 8是并发8条TCP流，目的是制造多流哈希，让流量尽量分散到两根物理链路上。如果聚合配置正确，测试结果会更接近2Gbps而不是1Gbps。如果只有单流或并发数很少，带宽跑不高是正常的，因为哈希保证的是“流级负载分担”而不是“帧级负载均衡”。
第三组是状态检查。拔线后马上在SW-A上执行 display eth-trunk 1，你会看到一个成员口状态变成Down，另一个仍然Up。重新插回网线后，端口会重新协商进入活动状态。这里顺便说一下，恢复后流量并不会瞬间全部回切，哈希表会逐步更新，但如果设备支持快速收敛，你基本感觉不到异常。
5. 生产环境中的链路聚合避坑指南
5.1 生成树协议与聚合口的博弈
很多新人在配置完聚合链路后发现，明明两个物理口都加入Eth-Trunk了，数据流量却完全不经过其中某一条链路。打开display stp brief一看，某个成员口仍然处于Discarding或Blocking状态，这就说明生成树并没有把聚合口当整体看待。
正常来说，Eth-Trunk作为逻辑口参与生成树计算，成员口不应再独立参与STP。但在一些老版本设备或配置顺序不对的情况下，可能出现成员口残留STP状态不同步。解决方法是先确认Eth-Trunk上是否执行了类似 stp enable，再把物理口从Eth-Trunk删除并重新加入，让STP重新计算。
更常见的坑是：一端设备配了Eth-Trunk，另一端设备没有配Eth-Trunk，而是把两条物理线直接接到对端交换机的两个普通口上。本端看Eth-Trunk是Up的，但对端交换机认为收到了两个物理连接的BPDU，会阻塞其中一个物理口。结果就是，你以为自己是双链路备份，实际只有一条链路在转发，另一条链路永远在Blocking状态。这种故障非常隐蔽，因为链路状态显示Up，但流量特征一测就知道不对。
所以在跨设备互联之前，一定要确认两端都把聚合配置做对。如果对端是第三方设备，也要确认它的LACP模式兼容性。有些厂商默认LACP模式是Passive，不会主动发LACPDU，两端都是Passive的时候，聚合永远协商不起来，需至少有一端是Active。
5.2 两端模式不一致引发的“假聚合”
我再举一个真实排障案例。某个客户反馈，两台交换机互联做了Eth-Trunk后，VLAN 10能通，VLAN 20不通，而且时通时断。排查下来发现：SW-A上Eth-Trunk模式是手工聚合，SW-B上Eth-Trunk模式是LACP静态聚合。SW-A发出的帧不从LACP报文里协商，直接就从两个物理口转发；SW-B却认为需要收到LACPDU才把端口加进聚合组。结果SW-B只有一个端口被协商加入聚合口，另一个端口作为普通口处理，VLAN 20的广播帧从那个普通口进来后又在SW-A上产生回路效应。
解决办法也很典型：统一两端聚合模式，清空两端聚合口配置后重新建。这里我必须强调，聚合配置一旦有问题，不要在一个口上反复调来调去，而是要把所有成员口从Eth-Trunk里移出，然后在两端同时重建。否则旧配置残留可能让端口进入ERR-Disable状态，反而把问题扩大。
与此类似的还有双工模式、速率不一致的问题。LACP协商时能够发现速率不一致，但手工聚合模式对速率和双工的一致性不校验。当一条链路是千兆全双工、另一条链路是百兆半双工时，聚合后转发就经常出错，表现为大量CRC错误和丢包。因为流量被哈希到百兆口时，会形成严重的带宽瓶颈和背压。生产环境里，聚合组里所有成员口必须保持相同的速率、双工、VLAN配置，这是铁律。
5.3 哈希不均与链路利用率失衡的调优思路
配置都正确，STP也正常，LACP协议状态也Up，但流量始终集中在一条链路上，这是另一个高频问题。原因前面讲过：哈希因子和业务流量特征不匹配。
比如在一台三层交换机上，Eth-Trunk默认哈希因子可能是基于源MAC和目的MAC。如果聚合口接了路由器，路由器发出的帧MAC地址固定，那么所有跨路由流量都只有一对MAC，哈希结果恒定，必然全走同一个成员口。这时候需要把哈希因子调整成基于IP的：
code复制interface Eth-Trunk 1
load-balance src-dst-ip
如果业务是大量四层端口会话，比如Web访问、数据库连接，可以考虑基于IP+端口的哈希：
code复制interface Eth-Trunk 1
load-balance src-dst-ip-l4port
但哈希因子越细，硬件计算开销越大，在低端盒式交换机上可能影响转发吞吐。所以不要一味追求细粒度，要结合业务流量模型来选择。
除了哈希因子，还可以通过调整业务部署来改善链路利用率。比如让不同业务走不同VLAN、不同源IP段，从而让哈希结果更分散。你也可以用display eth-trunk traffic这类命令查看每个成员口的实际流量统计，判断到底是不是负载不均。如果某条成员口长期跑满而其他成员口长期空闲，就要优先查哈希因子，而不是怀疑硬件故障。
6. 链路聚合和链路备份在整体架构中的定位
6.1 聚合链路解决不了故障域隔离问题
虽然链路聚合和链路备份技术能在单条链路故障时保住业务，但一定要明确它的故障域边界。聚合链路只解决“物理链路/端口故障”，解决不了“整台设备故障”和“设备内部单点故障”。
假设核心交换机只有一台，上面所有聚合链路都连接在同一台核心设备上。这台核心设备如果因为电源模块故障整体宕机，所有聚合链路同时失效，链路备份技术再强也没有意义。所以生产环境里真正的核心节点必须引入设备级冗余，比如双核心交换机、堆叠、M-LAG或者VRRP网关冗余。
跨设备链路聚合是这几年数据中心里很常见的需求。两台物理交换机组成一个堆叠系统后，对外可以看作一台逻辑设备，下行服务器网卡做链路聚合，分别连接到堆叠系统的两台物理成员上。这样当其中一台交换机整机Down掉，服务器聚合链路仍然能和另一台成员设备通信。注意，这种“跨设备聚合”必须依赖堆叠或M-LAG技术，不能直接用标准LACP在两台独立交换机上实现，因为标准LACP认为聚合口必须落在同一台设备上。
6.2 需要与路由冗余协议配合的场景
链路聚合负责的是二层链路层面的冗余。但对三层网络来说，光有二层链路冗余还不够。举一个典型场景：交换机A通过聚合链路上联核心交换机B，同时通过另一条物理链路上联核心交换机C。如果A和B之间的聚合链路全部断了，二层聚合已经无法感知上层路由，但三层网关如果还指向B，流量就会丢。此时必须有VRRP或等价路由这样的三层冗余协议配合。
- 汇聚交换机作为终端网关时，可以用VRRP让两台汇聚设备提供同一个虚拟IP，形成网关冗余。
- 三层互联接口上可以使用等价路由ECMP，让流量从两条不同路径负载均衡。
- 配合BFD检测链路质量，一旦聚合链路出现物理层正常但链路质量恶化的情况，BFD能快速切换到备用路径。
链路聚合只是在纵向路径上做了冗余加固，路由冗余是在横向拓扑上提供逃生通道。两者不是替代关系，而是互补关系。我的组网习惯是：设备之间先用聚合链路把带宽做大、把链路备份做好；再在更高层级部署VRRP/ECMP/BFD，把设备节点和路径级的故障也纳入冗余范围。
6.3 我的组网设计经验总结
最后聊点我个人的实务心得。做链路聚合和链路备份设计，建议按以下顺序思考：
先想清楚你要防的是哪一层故障。如果只想防一根线/一个光模块坏掉，链路聚合的成员冗余就够了；如果想防一台交换机宕机，必须引入堆叠、M-LAG或双设备冗余架构；如果想防对端设备上联链路坏掉，必须配合接口备份或者路由探测。
再想清楚你要备份的粒度。同样一个Eth-Trunk，既可以全部成员同时转发、互为备份，也可以让一部分成员活动、一部分成员Standby。LACP的最大活动端口数和最小活动端口数就是做这个粒度控制的关键。生产环境里，最小活动端口数不要盲目设成2，如果实际只有1根主链路可用，你让逻辑口直接Down掉，可能比让1根链路继续转发造成的影响更可控。
最后一定要做故障演练。链路聚合配置完后，我不建议只看状态为Up就认为高枕无忧。最好在业务低峰期做一次拔线测试，记录切换时间和丢包数，同时观察日志。这样等真正出现故障时，你心里已经有底了：这个聚合是能扛住一根线故障的，还是只是表面上Up、实际上流量已经全走了另一根线。多演一次，后面排障的时候就少一分焦虑。