假如有两条 VPN 线路：

R1 ===== R3 ===== R4  
       PRIMARY （成本可接受,低延迟,大宽带,假设 100Mbps ） 

R1 ----- R2 ----- R4  
       BACKUP （成本超高按流量计费,更稳定,主要做备份）

我希望能保障 R1-R4 的链路高可用

故障

假如今天：
R1 ───────── R3
      100M

未来某天：
R1 ───────── R3
       ↓
      20M
       ↓
      丢包/延迟暴涨

根据链路质量快速切换

     正常
R1 ─────── R3 ────── R4
    100M

   ↓ 质量恶化

R1 ─────── R2 ────── R4
    BACKUP

目标

R1-R3 正常
    ↓
所有业务走 R3

R1-R3 拥塞，丢包 > 5%｜ RTT 大于 50ms （只是举例，可能有其他判断办法）
    ↓
优先走 R1-R2

R1-R3 恢复
    ↓
再切回 R1-R3

我发现普通的多 wan 路由器做的很差
大多只能负载均衡（类似 ECMP ）
或者主备（类似 ospf ），主链路“断线”才切，丢包很高也不认为是异常

我在几个节点之间做了 ospf ，确实能做到切换
不过因为“断线”才切换，实际体验很差

感觉这个需求非常常见，一直不到合理而且主流的方案

SAGAN

1 小时 6 分钟前

我试过 bgp (Linux bird) over wireguard 。能用。但是本质上也是断线才切，做不到根据链路质量自动切换线路。

可以自己用脚本动态改变各个线路的路由 priority / metric ，其实都不用上动态路由协议。但是难点在于 vpn 链路质量很难准确检测:

- 简单的主动 ping / tcp ping 测试的延迟和丢包无法真实反映线路质量。特别是如果测试的线路现在是闲置状态，你把流量负载切过去后的真实质量可能完全是另一回事。
- 被动检测 vpn 里跑的 tcp 连接的延迟、重传等指标判断链路状态：理论上可行，但是找到的几个开源项目都比较老，都没有用 eBPF 。而且最关键的是这种方式不 future proof ，因为未来的趋势是 quic 这种全加密，网络层根本拿不到可以检测的元信息。
- 用脚本定期跑 iperf 测试：这个我觉得甚至可能是实际效果最准确的链路质量检测方式。但是不优雅。而且会占用较多网络带宽。

有什么路由器/协议/方案能做到基于链路质量的故障切换

假如有两条 VPN 线路：

故障

目标