业务不一样会的啊

结论先行

一、先讲：你这样配置理论上会不会有问题？

1. 优先级相同 60 → 交换机视为 ECMP 等价路由，自动负载分担、链路冗余
2. 带 Track → 探测失败自动把对应路由撤销
3. 机制本身是标准合法用法，不是配置错误

二、你现场为什么会：不定期一个不通、甚至两个都不通？

问题 1：Track 探测方式不合理（最常见元凶）

• 直连链路探测（只看接口物理 UP）
• NQA/ICMP 探测（ping 下一跳或公网 IP）

• 接口网线没断、物理 UP，但上联设备死机 / 三层宕机
• Track 还认为正常，路由还在，流量还往坏链路发
• 表现：接口看着 UP，实际不通

问题 2：ECMP 负载分担哈希调度导致业务异常

• 部分业务流固定走一条链路
• 这条链路中间有环路、端口错包、光模块衰耗、拥塞
• 就会出现一部分用户时通时断，另一部分正常

问题 3：两个下一跳在同一台上行设备 / 同运营商同链路

• 上联设备一挂 → 两条 Track 同时失效 → 两口都断
• 起不到真正冗余

问题 4：中间二层环路、STP 震荡、MAC 漂移

三、正确改造方案（立刻解决你故障）

1. Track 必须改成 NQA ICMP 探测（不要只检测接口）

• 分别 ping 两条下一跳网关，或 ping 公网可靠 IP（223.5.5.5）
• 探测失败立刻撤销对应默认路由，流量自动切另一条

2. 两条上联必须物理分离、设备分离

• 一条走 A 设备，一条走 B 设备
• 不要都接到同一台汇聚 / 路由器上，否则冗余无效

3. 如果你不需要负载分担，改成主备模式

4. 排查二层

• 清理二层环路、确认 STP 无震荡
• 检查上联端口光模块 / 收光 / 错包计数

四、一句话总结

1. 配置两条同优先级带 Track 默认等价路由，语法和机制本身没问题；
2. 你现场不定期单口 / 双口不通，99% 是 Track 只检测物理接口、没做三层 ICMP 探测，加上 ECMP 哈希分流、上联同设备导致；
3. 要么改成 NQA+ICMP 精准探测，要么直接改成 主备不同优先级，立马稳定。

这个问题的根源很可能在于 Track 联动机制的局限性，导致网络无法有效检测到链路故障并进行切换。两个接口同时不通，更像是故障链路影响了整体转发。

 问题根源分析：Track 链路检测机制存在缺陷

你的配置在逻辑上是可行的，通过 Track 1 和 Track 2 分别监控两条链路，并关联到两条优先级相同的等价默认路由。

故障的核心在于，你使用的链路检测机制可能无法准确判断链路的真实可用性。常见的 Track 配置主要包含以下三种，它们各自的不足是导致本次故障的核心原因：

 逐步排查与收敛故障范围

为了避免盲目操作，建议先按照以下步骤排查，缩小故障范围：

1. 核实故障现场：

   • 在故障发生时，立即登录交换机，这是获取第一手信息的关键。

   • 使用 display interface brief | include g1/0/23|g1/0/24 命令，确认接口的物理状态（Link）和协议状态（Stp/Protocol）。

   • 使用 display track 1 和 display track 2 命令，查看 Track 项的当前状态（State）。

2. 根据状态，分路排查：

   • 若接口物理 Down：排查物理链路问题。检查模块、光纤等，并使用 display logbuffer 查看相关日志。

   • 若接口 Up 但协议 Down：常见于 STP 阻塞或协商问题。可使用 display stp brief 查看 STP 状态。如果 STP 状态正常，则需要排查常见的协商问题：检查双工/速率是否匹配；在物理链路可靠的前提下，检查光模块是否为H3C认证（display transceiver manuinfo）；或检查MTU配置是否与对端匹配（display interface）。

   • 若接口和协议均 Up，但 Ping 不通：问题很可能出在逻辑层面。

     • 检查 ARP：使用 display arp 查看下一跳 IP 的 ARP 是否学习正常。

     • 检查路由表：使用 display ip routing-table 查看等价路由是否存在。

     • 检查 Track 联动：确认 Track 关联的监测方式（NQA、BFD等）是否生效，探测包是否走对链路。

 解决方案：实施更可靠的链路检测

为彻底解决问题，建议对链路检测方案进行以下改造：

注意：以上方案均需先移除旧的等价路由和 Track 配置，然后根据选择的方案重新部署。配置完成后，建议模拟故障进行验证，确保链路检测和切换功能正常。