在园区网络出口带宽不断攀升、多运营商接入成为常态的今天，单条物理链路的带宽瓶颈和可靠性问题越来越突出。很多网络管理员发现，即便升级了千兆甚至万兆出口，高峰时段依然卡顿，链路故障时切换也不够丝滑。这时候，链路聚合器的价值就体现出来了。它不只是简单地把两条线绑在一起，而是涉及流量分配、会话保持、故障切换等一系列工程细节。

链路聚合器到底在做什么

链路聚合器（Link Aggregation）的核心逻辑，是把多条物理链路捆绑成一条逻辑链路，从而在不改变现有布线的前提下提升总吞吐量。园区网络中常见的部署位置是出口路由器和核心交换机之间，或者防火墙与上行设备之间。它遵循IEEE 802.3ad（LACP）标准，通过协商机制动态维护成员端口状态。

但实际工程中，聚合器的算法选择比协议本身更关键。常见的哈希因子包括源IP、目的IP、源MAC、目的MAC以及四层端口号。如果只按源IP做哈希，当大量用户访问同一目标服务器时，流量仍然会集中到某一条成员链路上，聚合效果大打折扣。因此，流量控制设备和链路聚合器往往需要联动配置，建议采用“源IP+目的IP+端口号”的组合哈希，才能让流量分布更均匀。

园区网络中的典型部署方式

以一所高校或中型企业园区为例，出口通常有两条运营商线路，一条电信、一条联通。传统做法是用策略路由做分流，但配置复杂且故障切换慢。引入链路聚合器后，可以将两条线路聚合为一条逻辑链路，配合负载均衡器实现按会话分发。具体步骤大致如下：

1. 在聚合器上创建聚合组，将两条物理WAN口加入同一组，模式设为LACP主动模式；
2. 配置哈希算法为“源IP+目的IP+源端口+目的端口”，避免单会话多路径乱序；
3. 在聚合器上启用健康检查，对每条成员链路做ICMP或HTTP探测，探测周期建议不超过3秒；
4. 将聚合口作为应用交付设备的上行接口，由应用交付层做七层业务识别和调度。

这样做的收益很明显：总出口带宽从200M提升到400M，且单条链路中断时业务无感知。需要注意的是，聚合后的逻辑链路带宽并不等于各成员带宽之和乘以效率，实际有效吞吐通常在85%到92%之间，因为哈希碰撞和协议开销不可避免。

和上网行为管理如何配合

很多园区在出口部署了上网行为管理设备，用来做URL过滤、应用识别和带宽配额。如果链路聚合器部署在行为管理设备的外侧，聚合后的流量会以单一逻辑链路进入行为管理设备，这时候行为管理设备的吞吐能力就成了新瓶颈。建议的做法是：链路聚合器部署在行为管理设备内侧，先聚合再送行为管理做七层处理；或者选择支持多链路旁路部署的行为管理方案，避免单点性能瓶颈。

部署时的几个易踩坑点

链路聚合看起来简单，实际调试中容易出现以下问题：

• 成员端口速率不一致：一条千兆、一条百兆聚合，整体速率会被拉低到百兆水平，建议成员链路速率和双工模式保持一致；
• 哈希算法与业务不匹配：以视频会议为主的园区，UDP流量多，按端口哈希效果较好；以网页浏览为主，按IP哈希更合适；
• 未启用LACP超时短模式：默认长超时（90秒）故障感知太慢，建议改为短超时（3秒），配合BFD可以做到毫秒级切换；
• 聚合器与对端设备协商失败：部分运营商光猫不支持LACP，此时只能改用静态聚合，但静态聚合没有握手报文，故障切换依赖物理层检测，可靠性略低。

常见问题速查

Q：聚合后为什么测速还是单条链路的速率？
大概率是哈希算法只用了源IP，单台测试机只有一个源IP，自然只能走一条链路。换多台机器同时测，或者改用基于流的哈希即可。

Q：链路聚合器能替代负载均衡器吗？
不能。聚合器解决的是链路层带宽叠加和冗余，负载均衡器解决的是应用层请求分发和服务器健康检查，两者层次不同，在园区网络中通常是配合使用。

园区网络的出口设计正在从“堆设备”转向“重调度”。链路聚合器作为链路层的基础设施，和流量控制设备、负载均衡器、应用交付设备一起，构成了一个分层的出口流量治理体系。选型时不要只看端口数量和聚合带宽，哈希算法灵活性、故障切换时间、与现有行为管理设备的兼容性，才是真正影响日常运维体验的指标。