监控交换机链路聚合怎么配：LACP 模式、负载分担与验收

交换机之间只有一条千兆链路，监控回传一多就丢包，想扩容直接再插一根网线，结果反而更糟：要么被生成树协议屏蔽、带宽没增加，要么广播风暴全网瘫痪。结论前置：多条物理链路必须做链路聚合，捆成一条逻辑链路同时解决带宽、冗余与环路三个问题；跨厂商设备与需要可靠协商的场景优先选 LACP（IEEE 802.3ad，两端至少一端配置为 Active）；聚合按流哈希分担流量，不是严格平分，监控大流量场景要调哈希策略并实测验证。

多插一根线为什么不行

二层交换机默认泛洪未知单播与广播帧，两根线直连不聚合会出现两种结局：

更严重的坑是：有人以为 STP 屏蔽的那条链路是冗余备份，其实多数情况下故障切换也不干脆。链路聚合把多个成员口捆成一个逻辑端口，STP 把它当单端口计算，才真正做到带宽叠加与无环共存。聚合口在 STP 计算中只以一个逻辑端口参与，收敛与切换都按逻辑链路处理；成员链路断了自动疏散流量，业务无感知切换。聚合的实际收益取决于成员口速率一致性与哈希均匀度，这两点会在后面的负载分担部分展开。

手工聚合与 LACP 怎么选

主流交换机提供手工负载均衡与 LACP 两种模式，取舍看协商能力：

跨厂商对接或核心链路建议直接上 LACP，标准协议兼容性最好。LACP 模式配置时确认两端角色，Active 端主动发 LACPDU，Passive 端被动响应，两端都配 Passive 协商不起来。同一厂商的小规模点对点链路用手工模式也能工作，但对端配置不一致时链路可能变成普通物理线，排障成本高于 LACP。

负载分担不是平均分

聚合链路对流量按流做哈希，同一条数据流只走一条物理链路，不同流分摊到不同成员口：

1. 按流哈希保证同会话报文不分散，避免乱序导致 TCP 重传率飙升。
2. 默认哈希常见基于源 MAC 与目的 MAC，可调为基于 IP 五元组等更细粒度。
3. 哈希不均匀时可能出现一条链路跑满、另一条闲置，聚合带宽白加了。
4. 监控场景典型风险：大量摄像头都指向同一台 NVR 或平台，目的 MAC 与 IP 相同，哈希容易集中到单条链路。

对策是把哈希策略调整为按源 IP 或五元组分担，前端摄像头地址各不相同，分担效果明显改善。哈希粒度的选择要在带宽利用与乱序风险之间平衡，流粒度过细会抬升交换机处理开销，过粗又分不散，按业务特征试配后再固化。

监控上联怎么配

监控网络的上联链路按五条原则配置：

1. NVR 与平台上行优先做链路聚合，双千兆起步，成员端口速率与双工一致。
2. 全线启用 LACP，聚合组内外一致，避免手工与动态混用。
3. 哈希策略选基于 IP 的细粒度算法，让不同摄像头流量分散到各成员口。
4. 成员端口加入聚合前清空独立配置，速率、双工、VLAN 属性保持一致。
5. LACP 超时参数两端对齐，超时阈值不一致会导致成员口震荡丢包。

监控场景的流量特征是大量小流并发、方向集中，前端与平台之间一对多。上联扩容时优先核对平台侧端口能力，NVR 网口若是千兆而聚合带宽做到 2G，平台侧也要配套更高速率上行，否则瓶颈会从链路转移到平台侧，聚合再多链路也白搭。

验收与排障

聚合配完不算完，按五步实测：

1. 拔掉一根成员链路，业务无感知切换，观察流量统计确认无长时间中断。
2. 满负载测吞吐，确认总带宽接近聚合带宽，而非集中到单条链路。
3. 观察各成员口流量分布是否均匀，集中明显的调整哈希策略。
4. 检查 LACP 状态与超时参数，两端协商一致再上业务。
5. 保留配置与测试记录，作为后期扩容与排障基线。

常见故障按根因定位：聚合协商失败先查两端 LACP 模式与优先级；成员口震荡先查 LACP 超时阈值两端是否一致；吞吐上不去先看哈希策略是否集中，再看成员口速率双工配置。逐条排除后再动业务，避免一边丢包一边改配置放大影响。

TL;DR 检查清单

• 多插一根线不聚合，要么被 STP 屏蔽要么广播风暴，必须做链路聚合。
• 跨厂商与骨干链路优先 LACP，两端至少一端 Active。
• 聚合按流哈希分担，不是严格平分，监控哈希易集中到 NVR 方向。
• 哈希策略按源 IP 或五元组调整，让不同摄像头分摊到各链路。
• 成员端口速率双工一致，LACP 超时参数两端对齐。
• 验收实测断线切换与满负载吞吐，观察成员口流量分布。

参考资料

• core-switch-redundancy-design
• surveillance-network-qos-config