链路聚合负载不均导致部分链路拥塞
问题描述
核心交换机之间通过一条4*10G Eth-Trunk（链路聚合组）互联。监控发现，该聚合组的总流量并未超载，但网络中存在周期性延迟抖动，用户反映访问部分应用时快时慢。
处理过程
1.发现问题：发现4个成员链路中，有两条链路流量很高（接近10G），另一条链路流量中等，最后一条链路流量几乎为0。负载极度不均衡。
2.检查配置：使用 display eth-trunk <编号> 查看负载均衡配置（load-balance模式）。发现当前配置为基于src-dst-ip（源目的IP）的负载分担模式。
3.流量分析：分析网络中的主要流量，发现存在多条“大象流”（Big Flow），即少数几对IP地址之间的大流量数据传送（如服务器备份流量）。由于这些大流的源和目的IP不变，它们始终被哈希到同一条物理链路上，导致该链路拥塞，而其他链路闲置。
4.解决方案：将负载均衡模式修改为更复杂的哈希算法，例如基于src-dst-ip和l4-port（四层端口）的模式：load-balance src-dst-ip l4-port。这样，即使同一对IP间的不同应用流量（不同端口）也会被分配到不同链路上。
根因
Eth-Trunk的负载均衡算法过于简单（仅基于IP地址），无法有效分散网络中存在的“大象流”，导致聚合组内部分物理链路拥塞，而其他链路利用不足，从而引发网络延迟和抖动。
解决方案
根据实际流量模型，优化Eth-Trunk的负载分担模式。通常增加传输层端口（l4-port）作为哈希因子能取得更好的均衡效果。
建议与总结
1.负载均衡策略：Eth-Trunk的默认负载均衡模式可能不适用于所有场景，需要根据现网主流流量类型（是IP多还是端口多）进行调优。
2.定期评估：网络流量模式会变化，应定期检查关键聚合链路的负载均衡情况。
3.监控粒度：监控系统应能监控到聚合组内每个成员接口的流量，而不仅仅是整个逻辑接口的流量。
