ECMP 4 条链路只有 1 条跑到 92%：5 元组哈希极化与大象流的定位和解法

结论先行：ECMP 不是「负载均衡」，而是「按 5 元组把流映射到固定成员链路」——它均衡的是流的数量，不是流量。只要流量模型里出现少数几条占比过高的「大象流」，ECMP 组内就会出现单链路打满、其余链路空转的极化现象。这类故障 ping/traceroute 全绿、交换机端口无错包，唯一的线索是「同一条 ECMP 组，成员端口利用率差 10 倍以上」。

一、现象：4×10G ECMP 组，只有 1 条链路在干活

去年 Q3 我们把一个对象存储集群从 A 机房迁到 B 机房，链路侧拓扑是：

• ToR（A 机房存储侧）→ Spine，走 4 条 10G 成员链路组成一个 ECMP 组（交换机为某国产盒式，ECMP 按 5 元组哈希，成员数 4）；
• 迁移窗口 4 小时，总设计带宽 40Gbps，实际业务峰值 18Gbps——纸面上每条链路平均 4.5Gbps，利用率约 45%，非常健康；
• 但迁移开始后 40 分钟，ToR 侧 4 条成员端口实测利用率：1 条 92%（9.2Gbps）、其余 3 条分别 6%、8%、5%；
• 影响面：存储集群 12 台节点，跨机房的 multipart upload P99 从 80ms 涨到 2.4s，客户端侧超时率 3.7%，单小时失败请求约 4.1 万次；
• 迷惑点：所有端口 CRC errors = 0，ping RTT 稳定在 0.3ms，traceroute 路径正常——链路本身没有任何故障迹象。

二、根因：5 元组哈希 + 大象流 = 极化

机制拆开讲：

1. ECMP 的哈希输入是 5 元组（src IP, dst IP, src port, dst port, protocol），同一条流的每一帧走同一条成员链路。这是为了保序。
2. 哈希只保证「流」均匀分布，不保证「字节数」均匀分布。假设 100 条流均分 4 条链路，但其中 1 条流占总字节数的 70%，那这条流落在哪条链路，哪条链路就扛 70%。
3. 我们的流量模型恰好踩雷：对象存储的 12 台写入节点 → 少数几个大 bucket 的网关 VIP，5 条「大象流」合计占总字节数 81%，每条 10~20Gbps 量级。5 条流按 5 元组哈希到 4 条链路，按鸽巢原理至少有 2 条落到同一条链路上——实测就是 2 条（合计 9.2Gbps）撞在了 member-2 上。
4. 更隐蔽的一层：TCP 流一旦建立，5 元组就固定了。即使网关后端做 L4 均衡换了对端 IP，只要 src port / dst IP 组合落回同一个哈希桶，还是同一条链路。

一句话：这不是网络故障，是流量模型和哈希空间不匹配。ECMP 在「大量小流」场景下工作得很好（我们内网东西向流量 20 万条流、单流均 <20Mbps，利用率差 <5%），但对「少数大流」天然无解。

三、具体做法：先验证，再选解法

3.1 验证是不是极化（3 条命令，10 分钟）

# 1) 交换机侧：看 ECMP 组各成员端口的实时速率（以常见 CLI 为例）
display interface ethernet 1/0/1-4 | include traffic
# 输出里 TX/RX 速率差一个数量级 → 极化嫌疑

# 2) 服务器侧：抓 60s 包统计 5 元组流量占比（top talkers）
timeout 60 tcpdump -i eth0 -nn -s0 -w /tmp/x.pcap not icmp
tcpdump -nn -r /tmp/x.pcap | awk '{print $2, $4}' | sort | uniq -c | sort -rn | head

# 3) 直接对撞：把大象流的一端换 IP，观察链路利用率是否跟着「搬家」
#    如果换 IP 后流量从 member-2 跳到 member-3 → 极化实锤

3.2 解法按成本从低到高

| 方案 | 做法 | 适用 | |---|---|---| | ① 拆流 | 应用侧把大流拆成多条小流（如对象存储把 multipart 的 100MB part 降到 16MB，并发分片走不同源端口/源 IP） | 业务可改，成本最低 | | ② 多源 IP | ToR 侧给存储节点配 /30 多地址，流量按节点分散到不同 5 元组 | 拓扑可控 | | ③ 哈希因子调整 | 交换机把 ECMP 哈希输入从 5 元组改为 L2+L3 或加 IP ID（注意：会破坏部分设备保序，需评估） | 交换机支持 | | ④ 上 L4/L7 负载均衡 | 用 F5/HAProxy 做真正的字节级均衡，ECMP 只兜底 | 流量模型长期是大象流 | | ⑤ 加链路 | 4 条加到 8 条，降低单条流的「撞车」概率 | 治标不治本，只买时间 |

我们当时选了 ①+② 组合：multipart part 从 100MB 降到 16MB、并发度 8→32，同时给 12 台存储节点各加一个 /30 辅助地址轮询。改完后 4 条成员链路利用率 41% / 44% / 42% / 43%，P99 回到 85ms。

四、踩过的坑与反直觉点

1. 「链路利用率低」不是好事：3 条链路 5~8% 利用率看起来「容量充足」，实际上意味着哈希极化已经发生——低利用率本身就是信号，不是余量。
2. tcpdump 抓 10G 全量包会 OOM：60s 全量抓包约 75GB，我们第一次直接打满了磁盘。用 -s0 前务必先算 带宽 × 时长，或加 BPF 过滤只抓目标 5 元组。
3. 改哈希因子要双向验证：我们测试环境把 ECMP 哈希改成 L2+L3 后，单流保序没问题，但跨流乱序导致某批 TCP 窗口回退，吞吐反而降了 11%。生产环境改哈希因子必须先在旁路镜像流量上回放对比。
4. 大象流会「搬家」不会消失：拆流（方案①）之后，我们监控发现新的 top 流从 9.2Gbps 变成 4 条 2.4Gbps——拆流只是把极化概率摊薄，没有消灭问题本身，长期还是要靠 ④。

五、结论与可复用清单

• 结论：ECMP 均衡的是「流」不是「字节」。流量模型里只要单流占比 >25%（按成员数 4 算），极化就是概率事件而非小概率事件。网络设计阶段就应该问一句：「我们的 top 5 流占总字节数的多少？」——这个数字大于 30% 时，ECMP 不应该出现在关键路径上。
• 可复用清单：
  1. 新链路/新 ECMP 组上线前，用 tcpdump + uniq -c 统计 top 5 流的字节占比，>30% 就必须评估拆流或 L4 均衡；
  2. 交换机侧把 ECMP 组成员端口的速率曲线拉进监控（Prometheus + snmp walk，5min 粒度），成员间利用率差 >3 倍即告警；
  3. 排查顺序固定为：成员端口速率 → top talkers → 换 IP 搬家验证，10 分钟内可下结论；
  4. 应用侧设计大流量接口时，默认考虑「我这条流会被 ECMP 钉死在一条链路上」，主动拆流、控单流带宽；
  5. 改交换机哈希因子属于「动地基」操作，必须旁路回放 + 双向吞吐对比后再上生产。

（完）