ECMP 多上联下个别大象流打满单链路、其余成员空闲，如何调熵与观测手段定位哈希极化？

【背景】 我负责一个数据中心出口：两台核心（Cisco N9K，IOS-XR）做 eBGP 双活，下行 4 条 100G 上联走 ECMP（等价多路径，哈希键默认含五元组 + VLAN）。业务是对象存储网关，流量特征很"肥"：少数几条大对象下载流单条能跑到 20–40Gbps，大量小对象请求则很碎。整体利用率我们看的是 4 条链路的均值，常年 30%–50%，看起来很健康。

【现象】 近两个月反复出现"均值不高、但个别接口 util 瞬时打到 92%+"的告警，伴随该链路 P99 明显抬升、其他 3 条链路 util 却只有 20% 左右。也就是说流量没有被摊平，疑似哈希极化（hash polarization）——某些大象流（elephant flow）因为五元组组合恰好落到了同一条成员上，把单条链路打满，而其他链路在"空转"。由于均值监控正常，这种问题非常隐蔽，往往等业务侧投诉超时才被发现。

【已尝试的排查】

1. 用 show interface 看瞬时速率，确认确实是个别成员 92%、其余 20% 的不均衡，排除了整体过载；
2. 抓包 + netflow 导出，想按五元组聚合出 top-N 大象流，但导出的采样粒度较粗，没法可靠还原"哪些流被哈希到了哪条成员"，也看不到 ECMP 成员级的分发结果；
3. 试过把哈希键从五元组改成去掉内层头 / 调 hash 种子，但没做对照实验，不确定到底改的是哪一段、影响面多大，也没有基线数据，不敢在生产直接动。

【期望得到的答案形态】 希望有同类经验的朋友具体说说：

1. 在 ECMP 下，业界是怎么判断"是哈希极化"而不是"链路本身容量不足"的？有没有可复现的观测方法（比如 netflow / sFlow 按成员端口聚合、show 命令看 ECMP 成员级计数、eBPF 在主机侧看实际出接口）能把"流 → 成员"的映射还原出来？
2. 调熵（hash seed / 哈希键选择 / 分层 ECMP / LAG 与 ECMP 关系）时，你们是怎么做灰度对照的？改之前需要采集哪些基线指标，改之后用什么指标证明不均衡度确实降下来了（比如各成员 util 的标准差 / 极差）？
3. 对"大象流"本身，除了调哈希，还有哪些更根本的手段（流级限速、限速策略、把大象流单独拉出去走专属链路、应用侧多连接打散）？分别的代价和适用场景是什么？ 能给具体命令、配置片段或观测指标的更好。