网络链路备份与高可用技术详解：从 Dual-WAN、LACP 到 SD-WAN 与 MPTCP

一台设备有两个 WAN 口、插了两张 SIM，或者接了两根光纤，并不等于系统已经具备高可用。真正的链路高可用至少要形成一条完整闭环：发现故障 → 确认故障 → 撤销或降级故障路径 → 选择可用路径 → 恢复隧道与业务 → 稳定后决定是否回切。任何一环缺失，都可能出现"设备显示已切换，业务仍然中断"的情况。

本文从物理介质、二层、三层、WAN、隧道、设备和应用七个层级解释常用技术，特别澄清 Failover、Load Balancing、LACP、VRRP、ECMP、PBR、SD-WAN、MPTCP 等容易混淆的概念。文中的 IP 地址均为示例；公网地址使用 RFC 5737 文档保留地址。

图 0　高可用不是单点功能，而是从物理介质到应用恢复的多层协同。

目录

• [1. 先建立正确的概念边界](#1. 先建立正确的概念边界 "#1-%E5%85%88%E5%BB%BA%E7%AB%8B%E6%AD%A3%E7%A1%AE%E7%9A%84%E6%A6%82%E5%BF%B5%E8%BE%B9%E7%95%8C")
• [2. 什么才是真正的链路备份](#2. 什么才是真正的链路备份 "#2-%E4%BB%80%E4%B9%88%E6%89%8D%E6%98%AF%E7%9C%9F%E6%AD%A3%E7%9A%84%E9%93%BE%E8%B7%AF%E5%A4%87%E4%BB%BD")
• [3. 故障检测：Link Up 不等于 Internet 可用](#3. 故障检测：Link Up 不等于 Internet 可用 "#3-%E6%95%85%E9%9A%9C%E6%A3%80%E6%B5%8Blink-up-%E4%B8%8D%E7%AD%89%E4%BA%8E-internet-%E5%8F%AF%E7%94%A8")
• [4. Failover、Failback 与防抖](#4. Failover、Failback 与防抖 "#4-failoverfailback-%E4%B8%8E%E9%98%B2%E6%8A%96")
• [5. 会话、NAT、DNS 与非对称路由](#5. 会话、NAT、DNS 与非对称路由 "#5-%E4%BC%9A%E8%AF%9Dnatdns-%E4%B8%8E%E9%9D%9E%E5%AF%B9%E7%A7%B0%E8%B7%AF%E7%94%B1")
• [6. Multi-WAN 负载均衡及其算法](#6. Multi-WAN 负载均衡及其算法 "#6-multi-wan-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E5%8F%8A%E5%85%B6%E7%AE%97%E6%B3%95")
• [7. 链路聚合、LACP 与 Linux Bonding](#7. 链路聚合、LACP 与 Linux Bonding "#7-%E9%93%BE%E8%B7%AF%E8%81%9A%E5%90%88lacp-%E4%B8%8E-linux-bonding")
• [8. STP、RSTP、MSTP 与工业环网](#8. STP、RSTP、MSTP 与工业环网 "#8-stprstpmstp-%E4%B8%8E%E5%B7%A5%E4%B8%9A%E7%8E%AF%E7%BD%91")
• [9. VRRP 与设备级高可用](#9. VRRP 与设备级高可用 "#9-vrrp-%E4%B8%8E%E8%AE%BE%E5%A4%87%E7%BA%A7%E9%AB%98%E5%8F%AF%E7%94%A8")
• [10. 静态路由、动态路由、ECMP 与 PBR](#10. 静态路由、动态路由、ECMP 与 PBR "#10-%E9%9D%99%E6%80%81%E8%B7%AF%E7%94%B1%E5%8A%A8%E6%80%81%E8%B7%AF%E7%94%B1ecmp-%E4%B8%8E-pbr")
• [11. 4G/5G、双 SIM、双 Modem 与双运营商](#11. 4G/5G、双 SIM、双 Modem 与双运营商 "#11-4g5g%E5%8F%8C-sim%E5%8F%8C-modem-%E4%B8%8E%E5%8F%8C%E8%BF%90%E8%90%A5%E5%95%86")
• [12. VPN 多链路冗余](#12. VPN 多链路冗余 "#12-vpn-%E5%A4%9A%E9%93%BE%E8%B7%AF%E5%86%97%E4%BD%99")
• [13. SD-WAN、Packet Duplication 与 FEC](#13. SD-WAN、Packet Duplication 与 FEC "#13-sd-wanpacket-duplication-%E4%B8%8E-fec")
• [14. MPTCP、Multipath QUIC 与 WAN Bonding](#14. MPTCP、Multipath QUIC 与 WAN Bonding "#14-mptcpmultipath-quic-%E4%B8%8E-wan-bonding")
• [15. A--J 十种工程方案](#15. A–J 十种工程方案 "#15-aj-%E5%8D%81%E7%A7%8D%E5%B7%A5%E7%A8%8B%E6%96%B9%E6%A1%88")
• [16. 十二类故障场景与检测矩阵](#16. 十二类故障场景与检测矩阵 "#16-%E5%8D%81%E4%BA%8C%E7%B1%BB%E6%95%85%E9%9A%9C%E5%9C%BA%E6%99%AF%E4%B8%8E%E6%A3%80%E6%B5%8B%E7%9F%A9%E9%98%B5")
• [17. 测试方法、工具与验收指标](#17. 测试方法、工具与验收指标 "#17-%E6%B5%8B%E8%AF%95%E6%96%B9%E6%B3%95%E5%B7%A5%E5%85%B7%E4%B8%8E%E9%AA%8C%E6%94%B6%E6%8C%87%E6%A0%87")
• [18. 故障排查方法论](#18. 故障排查方法论 "#18-%E6%95%85%E9%9A%9C%E6%8E%92%E6%9F%A5%E6%96%B9%E6%B3%95%E8%AE%BA")
• [19. 横向比较、选型与常见误区](#19. 横向比较、选型与常见误区 "#19-%E6%A8%AA%E5%90%91%E6%AF%94%E8%BE%83%E9%80%89%E5%9E%8B%E4%B8%8E%E5%B8%B8%E8%A7%81%E8%AF%AF%E5%8C%BA")
• [20. 核心问题速答、总结与参考资料](#20. 核心问题速答、总结与参考资料 "#20-%E6%A0%B8%E5%BF%83%E9%97%AE%E9%A2%98%E9%80%9F%E7%AD%94%E6%80%BB%E7%BB%93%E4%B8%8E%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99")

1. 先建立正确的概念边界

网络高可用最常见的问题不是"不懂命令"，而是把不同层级的机制当成同一种能力。

概念	主要目标	典型工作层级	不能天然保证什么
Failover（故障切换）	主路径故障后启用备用路径	L2、L3、WAN、隧道	负载分担、会话无损
Load Balancing（负载均衡）	把多个流或会话分散到多条可用路径	L3/WAN/应用	单连接带宽相加、故障检测完整性
Link Aggregation（链路聚合）	把同一对逻辑端点间的并行以太网成员组成一条逻辑链路	L2，部分设备支持 L3 Port-Channel	跨两个独立 ISP 的 Multi-WAN
LACP	动态协商、维护聚合成员	IEEE 802.1AX	Internet 路由、NAT、应用恢复
STP/RSTP/MSTP	消除二层环路并启用备用拓扑	L2	链路聚合、WAN 出口切换
VRRP	为终端提供冗余默认网关	L3 首跳	WAN 端到端健康、状态同步
ECMP	对等成本路由同时参与转发	L3	按业务语义选路、跨路径保持 NAT 状态
PBR（策略路由）	按源、目的、协议或业务策略选下一跳/路由表	L3/策略层	自动健康检查；必须显式联动探测或递归路由
Multi-WAN	管理多个独立 WAN 出口	WAN/L3	单流聚合；普通 TCP 不会自动变成多路径 TCP
MPTCP	一个逻辑 TCP 连接使用多个 TCP Subflow	传输层	对不支持 MPTCP 的两端自动生效
SD-WAN	在多个 Underlay 上建立受策略控制的 Overlay，并按质量/应用动态选路	WAN Overlay	所有产品都包含复制、FEC 或"零丢包"
Dual SIM	两张运营商身份卡可选	蜂窝接入	两条蜂窝链路同时在线；单 Modem 通常仍需切换
Dual Modem	两套无线基带可分别建立蜂窝链路	蜂窝接入	完全独立故障域；天线、电源、基站、回传仍可能共享

必须始终记住以下不等式：

Failover ≠ Load Balancing；Load Balancing ≠ Link Aggregation；LACP ≠ Dual-WAN；VRRP ≠ WAN Failover；STP ≠ LACP；ECMP ≠ PBR；Dual SIM ≠ Dual Modem；Multi-WAN ≠ MPTCP；SD-WAN ≠ VPN；链路切换 ≠ 业务无感切换；接口 UP ≠ Internet 可用；总体带宽增加 ≠ 单连接带宽增加。

1.1 单 WAN、多 WAN 与常见组合

• 单 WAN（Single-WAN）：只有一个有效出口。结构简单，但链路、运营商、接入设备任一故障都可能中断业务。
• Dual-WAN / Multi-WAN：两个或更多独立出口，例如双光纤、双运营商、有线 + 5G、Ethernet + Cellular、Wi-Fi WAN + Ethernet WAN、卫星 + 地面网络。
• 异构链路：介质与运营商不同，可降低同类故障相关性，但时延、MTU、费用和带宽差异更大。
• 逻辑多链路：MPLS + Internet、专线 + Internet、在不同 WAN 上建立多个 IPsec/OpenVPN/WireGuard 隧道。物理链路和逻辑隧道必须分别监控。

1.2 Active/Standby、Active/Active、冷备与热备

• Active/Standby：正常只有主链路承载业务，备用链路待命。易于保持路径稳定，带宽利用率较低。
• Active/Active：多条链路同时承载不同流量。需要流量分配、会话粘性、对称路由和容量规划。
• 冷备：备用路径或设备平时未建立完整状态，启用时可能包含拨号、注册、隧道协商和路由收敛。
• 热备：备用链路已在线，必要的邻居、隧道或状态已建立，可缩短恢复路径，但成本、流量费和维护复杂度更高。

链路冗余与设备冗余也不是一回事。两条 WAN 都接在同一台路由器上，仍然存在整机、电源、软件和配置单点；两台路由器若共用同一上联、同一配电或同一运营商接入节点，也仍有共同故障域。

2. 什么才是真正的链路备份

一个可验收的链路备份系统需要回答六个问题：

1. 检测什么：接口、网关、Internet、DNS、VPN 对端，还是具体业务？
2. 如何确认：失败阈值、探测间隔、超时和多目标判定是什么？
3. 切换什么：默认路由、PBR 下一跳、隧道、NAT 规则还是应用连接？
4. 备用路径是否已准备好：地址、DNS、认证、MTU、防火墙和回程路由是否完整？
5. 业务怎样恢复：原会话继续、协议重连、客户端重试，还是人工介入？
6. 何时回切：立即抢占、稳定后回切、不回切，还是只让新连接回主链路？

典型主备过程如下。

图 1　Failover 的关键不是"有 WAN2"，而是探测、路由撤销、备用路径验证和业务恢复形成闭环。

正常时，WAN1 是 Primary。达到故障判定条件后，控制平面撤销 WAN1 路由或降低其可用性，WAN2 成为有效路径；新流量按 WAN2 的 NAT、防火墙与 DNS 策略转发。WAN1 恢复后，还要经过恢复阈值和稳定等待，才决定是否 Failback。

2.1 优先级、Metric、Distance 与 Preference

这些词常被混用，但含义取决于协议和平台：

• Priority：某个机制内部的优先级，例如 VRRP 优先级或产品的 WAN 优先级，数值方向要以该实现为准。
• Metric / Cost：同一协议或路由来源内部比较路径优劣，例如 OSPF Cost、静态路由 Metric。
• Administrative Distance（管理距离）：部分平台用于比较不同路由来源的本地可信度；通常较小者优先，但默认值是厂商实现，不可跨厂商照抄。
• Route Preference：另一些平台使用的本地路由偏好概念，数值方向和默认值同样以平台文档为准。

因此，"主路由 Metric 10、备路由 Metric 100"只能作为原理示例，不能替代对具体操作系统 RIB/FIB 选路规则的核对。

2.2 切换策略可以是多维的

常见策略包括优先级、路由成本、SLA、实时质量、链路带宽、业务类型、时间、流量费用、运营商和网络类型。例如：专线 → 宽带 → 5G。5G 常作为最终备份，是因为它部署快、与固定接入介质不同；但流量费、无线波动、CGNAT、公网入站能力、天线与覆盖使它不一定适合长期承载全部业务。

3. 故障检测：Link Up 不等于 Internet 可用

故障检测必须与要保护的业务路径相匹配。越靠近应用的探测越能证明业务可用，但代价和误报风险也越高。

图 2　从物理状态到业务请求逐层证明可用性；只验证某一层，不能替代更高层结论。

层次	常见信号/探测	能发现	主要盲区
物理层	Carrier Detect、PHY Link、光模块 LOS、Modem 注册状态	断线、端口/光信号丢失、无线脱网	上游路由、DNS、应用故障
二层	ARP、IPv6 NDP/Neighbor Reachability	本地下一跳不可达、邻居异常	网关之后的故障
三层	ICMP 到网关、运营商节点、多个公网目标	IP 可达性、部分路径故障	端口被阻断、DNS/应用故障；ICMP 可能被限速
四层	TCP Connect 到 53/80/443 或业务端口	目标端口和三次握手可达	TLS、认证、请求处理、数据正确性
应用层	DNS Query、HTTP(S) 请求、自定义事务	接近真实业务的端到端可用性	探测服务自身故障可能触发误切
路由协议	BFD、OSPF/BGP 邻居状态	邻接或双向转发路径异常	邻居正常不等于远端应用正常

3.1 为什么只 Ping 默认网关会"假正常"

运营商接入网关就在用户附近。即使运营商上游 Internet 出口、DNS 或远端路由已经故障，本地网关仍可能响应 ICMP：

路由器 WAN PHY：UP
        ├─ ISP Gateway：可 Ping
        └─ ISP Internet：DOWN

所以 Ping Gateway = 成功 只能说明到网关的这一小段路径可达，不能推出 Internet 或业务可用。反过来，单个公网目标不响应 ICMP，也不能直接推出 Internet 故障，因为对方可能过滤或限速 ICMP。

3.2 更可靠的联合探测

推荐把检测拆为"快速本地信号"和"端到端证据"：

• 本地：接口状态、下一跳 ARP/NDP；用于快速发现明确断线。
• 外部：经指定 WAN 到至少两个独立目标的 ICMP/TCP 探测；目标应跨服务和故障域。
• 服务：真实 DNS Query、HTTPS 轻量请求或业务心跳；验证必需服务。
• 路由：必要时增加 BFD 或动态路由邻居状态；它们不能替代应用探测。

判定逻辑不宜把所有目标简单绑定为"任一失败即切换"。可以按业务定义 Any/All、权重或分层条件，例如"网关失败立即告警；两个外部目标均连续失败且 DNS/HTTPS 也失败才撤路由"。目标本身必须稳定、允许探测并具备容量，不能把公共服务当作无限制监测端点。

3.3 探测参数与检测时间

参数包括 Interval、Timeout、Retry Count、Failure Threshold、Recovery Threshold、Dead Interval、Hold Time、Link Down Delay 和 Link Up Delay。粗略估算可写为：

T_detect ≈ 探测间隔 × 失败阈值 + 单次超时相关开销

实际值取决于探测是否串行、超时是否重叠、控制进程调度及硬件事件。BFD 的检测时间也由双方协商的发送间隔和 Detect Mult 等参数共同决定，不能脱离实现直接宣称固定"毫秒级"。

4. Failover、Failback 与防抖

Failover 是故障后离开当前路径，Failback 是主路径恢复后返回。两者面对的风险不同：故障需要尽快隔离，而恢复可能只是短暂抖动。

图 3　故障侧使用连续失败确认，恢复侧使用更长的稳定窗口；新建连接和既有连接可采用不同回切策略。

4.1 为什么不能失败一次就立即切换

一次丢包可能来自瞬时拥塞、无线重传、ICMP 限速、CPU 忙或探测目标短暂异常。一次失败立即切换会造成：

• WAN1 与 WAN2 反复切换，即 Route Flapping；
• NAT 和防火墙会话不断重建；
• VPN 反复协商；
• DNS 来源、出口公网 IP 频繁变化；
• 实际业务恢复时间反而更长。

工程上通常组合使用：

• Debounce（去抖）：连续 N 次失败/成功才改变状态。
• Hold-down：切换后在一段时间内禁止立即返回。
• Dampening：对频繁状态变化施加惩罚或延长等待。
• Down/Up Delay：分别延迟宣告故障和恢复；恢复阈值通常更保守。

4.2 回切策略

1. 立即抢占：主链路一恢复即回切。适合主备成本差距极大且业务可容忍二次扰动的场景。
2. 稳定后抢占：连续健康一段时间后回切，是最常见设计。
3. 非抢占：备用链路继续承载，等待维护窗口或下一次故障。适合长连接敏感场景。
4. 仅新连接回主链路：既有连接保持原出口，直到自然结束；需要设备支持会话保持和双路径并存。

4.3 "毫秒级切换"应拆开验收

实际服务恢复时间可表示为：

T_total = T_detect + T_decision + T_route + T_tunnel + T_application

图 4　设备所报的路由切换时间只覆盖总恢复链的一部分。

• T_detect：发现链路或路径故障；
• T_decision：达到阈值并执行策略；
• T_route：RIB/FIB、PBR 或邻居完成更新；
• T_tunnel：VPN 重协商、重新选端点或恢复路由；
• T_application：TCP/MQTT/OPC UA 等超时、重连、认证和数据恢复。

供应商给出的收敛数字只有在明确拓扑、设备数量、定时器、报文负载、故障类型和测量点时才有意义。应同时记录丢包数、路径变化、首个成功业务事务以及既有会话是否保留。

5. 会话、NAT、DNS 与非对称路由

5.1 为什么 WAN 切换后 TCP 经常中断

TCP 连接由两端套接字标识，即源/目的 IP 与端口组合。客户端 192.168.10.100:50000 经 WAN1 做 NAPT 后，服务端看到的可能是 203.0.113.10:41000；切到 WAN2 后，新映射变成 198.51.100.20:52000。服务端不会把它自动视为原 TCP 连接。

图 5　出口公网地址或端口变化后，普通 TCP 的连接标识和 NAT 状态已经不同。

Conntrack、NAT State、Stateful Firewall 的状态通常与接口、五元组、方向和超时绑定。即使主备防火墙支持 Session Synchronization，也要核对哪些协议、NAT 类型、加密会话和辅助状态可以同步；"状态同步"不是所有会话无损的同义词。

5.2 常见业务在切换后的表现

业务/协议	既有会话典型表现	恢复关键点
TCP、HTTPS、SSH、Modbus TCP	公网源地址/路径变化时通常断开	应用超时与重连、幂等请求、断点续传
WebSocket	建立在 TCP 上，通常需要重新连接	心跳、指数退避、状态恢复
MQTT	TCP 连接断开；Broker 会话可按 MQTT 5 的 Clean Start/Session Expiry 等机制保留	客户端重连、QoS、订阅与离线队列；不是传输无缝迁移
OPC UA	SecureChannel/Transport 可能中断	在服务器 Session/Subscription 生命周期内，客户端可尝试重新激活 Session、TransferSubscriptions/Republish；取决于双方实现
UDP	无 TCP 握手，但 NAT/防火墙/服务端仍可能维护五元组状态	重新注册、心跳、序列号、去重、应用是否接受新源地址
SIP/音视频	信令、RTP 媒体和 NAT 映射可能分别受影响	ICE、重新协商、re-INVITE、缓冲、FEC 和产品实现
VPN	外层地址变化可能使隧道或 SA 失效	DPD/Keepalive、MOBIKE/漫游能力、备用隧道和路由
数据采集长连接	连接通常中断，但本地采集可继续	Store-and-Forward、断点续传、时间戳和去重

网络层完成切换，只意味着新路径可用于新报文；应用是否"无感"取决于连接标识是否保持、两端是否支持迁移、状态是否同步、重连策略及业务容错。

5.3 DNS 不能遗漏

常见故障是默认路由已经切到 WAN2，但客户端仍使用只能经 WAN1 到达的 ISP DNS、失效的 VPN DNS 或错误的 Split DNS。设计时应核对：

• WAN2 上 DNS 服务器是否可达，是否允许跨运营商查询；
• 路由器自身和 LAN 客户端获得的 DNS 是否随链路正确更新；
• 内部域名是否必须经 VPN DNS，备用隧道恢复前如何处理；
• 缓存、负缓存和 TTL 是否掩盖或延长故障；
• 健康检查应做真实查询并验证响应语义，而不只是 TCP/UDP 53 可达。

5.4 非对称路由（Asymmetric Routing）与会话粘性

请求经 WAN1 发出、响应却经 WAN2 返回，可能因为上游路由、ECMP、PBR 或双机设计不一致。Stateful Firewall 找不到反向会话，NAT 映射也不匹配，于是丢包。对策包括：

• 使用源地址和连接跟踪保持回程对称；
• PBR 与健康检查联动，失败时允许递归到备用路径；
• 在 HA 对等设备间同步必要状态，并验证同步边界；
• 对 Internet 入站服务使用 BGP/Anycast、负载均衡器或应用层方案，而不是仅靠出站 NAT；
• 为一个会话固定出口，即 Session Persistence/Sticky Session。

会话粘性并不等于永久绑定失效链路：正常时同一五元组保持路径一致，链路故障时仍需清理或迁移状态，并由应用重连。

6. Multi-WAN 负载均衡及其算法

Failover 正常时只用主路径；Load Balancing 正常时就让多条路径承载流量。一个系统可以同时具备两者：健康链路之间负载分担，某条失败后把新流重映射到其余路径。

图 6　70/30 是大量新会话上的统计目标，不代表每个时刻或每个小样本都精确分配。

6.1 常见算法

算法	分配对象	优点	风险/限制
Round Robin	依次分配连接或流	简单	忽略链路带宽与流量大小；若逐包会乱序
Weighted Round Robin	按权重分配连接	可匹配 70/30 等容量差异	大流与小流差异会使短期流量偏斜
Source IP Hash	同源客户端固定路径	会话稳定、便于审计	少量大客户可能失衡
Destination IP Hash	同一目标固定路径	目标路径稳定	热点目标可造成偏斜
Source + Destination Hash	按通信对固定	比单字段更均匀	端口变化不参与熵
5-Tuple Hash	源/目的 IP、源/目的端口、协议	常见且粒度细，利于避免乱序	单流仍只走一条路径；字段支持取决于平台
Per-Connection / Per-Flow	每个连接或流选一次	最常见，兼容有状态 NAT/防火墙	不能让单连接叠加带宽
Per-Packet	每个包重新选择	理论上可细分流量	路径时延不同会乱序，伤害 TCP；需受控环境和接收端机制
Least Connection	选活动连接较少路径	应用代理/负载均衡器常见	WAN 路由器未必知道业务负载，连接大小不等

实际路由器通常采用按连接或哈希，而非简单逐包轮询，原因是需要保持包序、NAT 状态、防火墙状态和路径 MTU 一致。哈希只保证映射规则，不保证少量流时精确均分。

6.2 两条 100 Mbps 是否等于单下载 200 Mbps

普通 Multi-WAN 通常只能提高多会话总体吞吐。单个 TCP Flow 在建立时被映射到 WAN1 或 WAN2，仍受该链路容量限制。

图 7　两条 100 Mbps 普通 WAN 可让多个流合计接近 200 Mbps 的链路容量，但单流通常仍不超过所选链路。协议开销、服务端、终端和拥塞会使实测更低。

只有在端点支持 MPTCP/Multipath QUIC，或两端部署具有分片、排序、重传和聚合能力的隧道网关时，单个逻辑业务才可能同时使用多条路径。即便如此，吞吐也不是简单算术相加，还受最慢路径、乱序、重传、加密开销和聚合端出口限制。

7. 链路聚合、LACP 与 Linux Bonding

7.1 标准和术语

Link Aggregation（链路聚合）把同一对逻辑系统间的多条全双工点到点以太网链路组成一条逻辑链路。历史上动态链路聚合曾位于 IEEE 802.3ad；现行独立标准是 IEEE 802.1AX-2020。LAG、Port-Channel、EtherChannel、Bond 等名称常指逻辑聚合接口，但命令和能力取决于平台。

• Static LAG：双方静态指定成员，不交换 LACP 状态。
• Dynamic LACP：通过 Link Aggregation Control Protocol 协商成员、系统身份和聚合状态。
• Active LACP：主动发送 LACPDU。
• Passive LACP：响应对端；双方都 Passive 时通常不会形成聚合，至少一侧应主动。

成员链路通常需要兼容的速率、双工、VLAN/Trunk 和聚合配置。跨两台物理交换机组成一个 LAG，必须由堆叠、虚拟机框、MLAG/MC-LAG 等机制让其表现为合适的逻辑对端；不能把两根线随意接到两台独立交换机后直接启用 LACP。

图 8　跨双交换机聚合依赖堆叠或多机箱聚合能力；否则应采用独立链路加 STP、路由或 Active/Backup。

7.2 LACP 不是 Multi-WAN

图 9　LACP 聚合同一逻辑两端之间的以太网成员；Multi-WAN 面对的是独立 ISP、独立寻址、路由和 NAT。

维度	LACP/LAG	Multi-WAN Load Balancing
对端关系	同一对逻辑系统	多个独立 ISP/接入网络
地址与路由	一个逻辑接口，常共享 L2/L3 配置	各 WAN 独立地址、网关、DNS、NAT
控制机制	IEEE 802.1AX/LACP	路由、PBR、健康检查、NAT、SD-WAN 等
故障范围	成员链路/聚合对端	接入、ISP、Internet、隧道和业务
单流	通常哈希到一个成员	通常固定到一个 WAN
能否直接跨两家 ISP	否	是，但需正确设计故障域

7.3 聚合容量不等于单流容量

2 × 1 Gbps LAG 的聚合容量可在多个流量上接近 2 Gbps，但单流通常由哈希固定到一个 1 Gbps 成员。哈希字段可能是源/目的 MAC、IP、TCP/UDP 端口或其组合；实际支持由交换芯片和软件决定。少数流或哈希碰撞会导致成员不均衡，不能用一个 iperf3 默认单流证明聚合总容量。

7.4 Linux Bonding 七种模式

Linux 内核文档定义的常见模式如下；网卡驱动、交换芯片、发行版网络管理器和交换机配置仍会影响结果。

模式	名称	发送方式	交换机要求与关键边界
0	balance-rr	依次在从接口发送包	可负载分担和容错，但易乱序；交换机侧必须正确处理并行端口
1	active-backup	只有一个接口活动	一般不要求交换机聚合；重点是故障检测、主接口和 MAC 通告
2	balance-xor	按配置哈希选择接口	需要交换机侧匹配的静态聚合/转发设计
3	broadcast	每个包从所有接口发送	提高冗余但耗费成倍带宽，接收侧和环路风险须评估
4	802.3ad	动态 LACP 聚合，按哈希发送	交换机必须支持并配置 LACP；成员速率/双工等需兼容；单连接通常不跨成员
5	balance-tlb	自适应发送负载均衡，接收在当前接口	一般不要求交换机聚合；依赖驱动能力
6	balance-alb	在 TLB 基础上以 ARP 协商实现 IPv4 接收分担	一般不要求交换机聚合；IPv4/ARP 与驱动限制明显

mode 1 active-backup 的目标是简单、可预测的冗余；mode 4 802.3ad 的目标是在标准聚合中同时使用成员并容错，必须与交换机协商。miimon 可监测物理链路，ARP 目标监测能看到更远的路径；updelay、downdelay、primary_reselect 等用于抑制抖动。不要只复制参数，必须按故障模型实测。

8. STP、RSTP、MSTP 与工业环网

冗余二层链路如果全部无条件转发，会形成环路。广播、未知单播和部分组播可被反复复制，导致 Broadcast Storm；交换机从不同端口反复学习同一源 MAC，导致 MAC Table Flapping；终端还可能收到重复帧。

• STP（Spanning Tree Protocol）：历史上由 IEEE 802.1D 定义，计算无环生成树并阻塞冗余路径。
• RSTP（Rapid Spanning Tree Protocol）：历史上是 IEEE 802.1w，改进角色、状态机和握手机制；现已并入 IEEE 802.1Q。
• MSTP（Multiple Spanning Tree Protocol）：历史上是 IEEE 802.1s，可把多个 VLAN 映射到不同生成树实例；现也并入 IEEE 802.1Q。

当前桥接网络的基础标准应引用 IEEE 802.1Q-2022，而不应把已经并入的 802.1w/802.1s 当成独立现行基准。实际收敛取决于拓扑、端口类型、设备实现和定时器；边缘端口误接交换机、根桥漂移、单向链路及未统一的 MST 区域参数都会破坏预期。

图 10　正常时 RSTP 阻塞一条冗余链路以消除环路；工作路径故障后重新计算并启用备用路径。

8.1 STP 与 LACP 解决的问题不同

• STP/RSTP/MSTP 在多条逻辑路径构成环路时选出无环拓扑，部分路径可能被阻塞。
• LACP 把同一对逻辑系统间的并行成员链路组成一个逻辑接口，成员可以同时转发不同流。
• 两者可在同一网络共存，但不能互相替代。LAG 对 STP 通常表现为一个逻辑端口。

8.2 工业环网：开放标准与私有协议

• ERPS（Ethernet Ring Protection Switching）：ITU-T G.8032/Y.1344 定义的以太网环保护机制，包含环保护链路、控制消息、恢复与回切行为。当前基准为 G.8032 (03/2020)，另有勘误；具体恢复时间必须结合标准条件或产品实测说明。
• MRP（Media Redundancy Protocol）：IEC 62439-2:2021 面向基于以太网的高可用自动化环网，由专用 Media Redundancy Manager 控制，对单个环内链路或交换机故障进行确定性恢复。
• RSTP/MSTP：通用、互通性好，但工业控制是否满足时延与抖动要求必须实测。
• 厂商私有快速环网：可能针对自家芯片和拓扑优化。使用时需确认许可、设备混用、环规模、故障类型、升级兼容和锁定风险。

不要仅凭"环网"二字推断快速恢复，也不要把不同协议同时启用在同一环上而不明确控制边界。环网只能解决其覆盖范围内的故障，环外上联、路由器、应用服务器和电源仍需独立冗余。

9. VRRP 与设备级高可用

VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）让多个路由器共同提供一个虚拟默认网关。当前 IPv4/IPv6 基准是 RFC 9568（2024） ，它取代 RFC 5798，并使用 Active Router / Backup Router 术语；大量现有产品界面仍沿用 Master/Backup，阅读配置时要做术语映射。

图 11　终端始终使用虚拟 IP 作为默认网关；VRRP 只解决 LAN 首跳，WAN 探测、路由和状态同步需另外设计。

示例：

• Router A：192.168.10.2
• Router B：192.168.10.3
• Virtual IP：192.168.10.1
• LAN 终端默认网关：192.168.10.1

Active Router 使用虚拟 IP/虚拟 MAC 转发，Backup 监听 VRRP 通告。优先级、地址所有者与 Preempt_Mode 决定接管和抢占行为。IPv4 与 IPv6 使用独立 VRRP 实例。VRRP 本身不会：

• 判断某个 Internet 应用是否健康；
• 在防火墙之间复制 NAT/会话表；
• 自动同步配置；
• 解决双路由器共同连接的一台交换机、一个电源或一条 ISP 线路的单点。

9.1 设备级 HA 的完整组成

双路由器或双防火墙的高可用通常还需要：

• Heartbeat/Control Link：检测对端状态、交换角色信息；要避免与业务链路共故障。
• Configuration Synchronization：同步规则、对象、证书、路由和接口策略，并核对不同步项。
• Session Synchronization / Stateful Failover：同步可支持的会话、NAT 与序列状态；不同厂商和会话类型限制不同。
• Link/Path Monitoring：设备还活着不代表其 WAN 或上游可用，应能触发优先级变化或节点切换。
• Split-brain 防护：心跳丢失时避免两台同时宣告 Active；常使用多条心跳、仲裁或接口监视。
• 容量冗余：任一节点故障后，剩余节点必须能承载完整峰值，而非只按平时一半负载配置。

Active/Active 不必然等于流量均衡；是否并发转发、如何分片、状态如何所有权划分均取决于产品架构。链路坏与整机坏属于不同故障域，应分别测试。

10. 静态路由、动态路由、ECMP 与 PBR

10.1 Floating Static Route

最简单的三层主备是主默认路由和更低偏好的备用默认路由。备用路由平时保留在控制平面，主路由因接口、递归下一跳或路径监测失效而撤销时才进入有效转发。它被称为 Floating Static Route。

注意：只把两个默认路由写成不同 Metric，并不会自动发现"网关之后的 Internet 故障"。必须让路由可用性与 IP SLA、Path Monitoring、脚本/守护进程或动态路由状态联动。

10.2 OSPF、BGP 与 BFD

• OSPF：链路状态 IGP，通过 Hello/Dead 等机制维护邻居并计算最短路径；可安装多个等价下一跳。邻居正常不代表 Internet 应用正常。
• BGP：用于自治系统间或大型策略路由。基础 BGP 通过 KEEPALIVE/UPDATE 等维持会话，Hold Timer 到期会关闭连接；其目标不是天然"瞬时"收敛。
• BFD（Bidirectional Forwarding Detection）：与介质和路由协议相对独立的双向转发检测，可为 OSPF/BGP/静态路由等提供更快故障信号。必须为真实转发路径建立会话，并按设备能力、CPU、链路质量和误报风险配置。

动态路由擅长传播可达性，应用探测擅长证明服务。大型系统常把两者组合，而不是让 BGP 或 BFD 独自代表业务健康。

10.3 ECMP：等价路径并发转发

ECMP（Equal-Cost Multi-Path）是多条相同成本路由同时存在于转发表。多数实现用 Per-Flow Hash 选择下一跳，避免同一流逐包跨路径造成乱序。

图 12　多个五元组经哈希映射到等成本下一跳；链路故障会触发重映射，既有有状态会话仍可能中断。

ECMP 与 Multi-WAN 负载均衡相似之处是都可按流分散路径；差异在于 ECMP 是路由表中等价下一跳的转发行为，而 Multi-WAN 往往还包含健康检查、非等带宽权重、NAT、DNS、费用和应用策略。跨 ISP 使用 ECMP 时还要解决源地址、回程、BGP 宣告和有状态防火墙。

10.4 PBR：按业务而非最优目的路由选路

PBR（Policy-Based Routing，策略路由）可按源网段、目的、协议、端口、DSCP 或应用标签选择下一跳/路由表。例如办公网走 WAN1、视频走 WAN2、IoT 走 5G、内部 ERP 走专线。

图 13　PBR 先按业务类别选择路径；每条策略都必须定义所选路径失败后的回退。

PBR 通常在普通目的路由查找之前或通过独立规则链选择路由表，具体顺序依平台而异。常见陷阱是：

• PBR 仍指向失效下一跳，默认路由已切换却无法接管；
• 只对正向流做策略，回程不对称；
• NAT 和防火墙没有为每个出口建立一致规则；
• 路由器本机流量与转发流量经过不同策略链；
• VPN "感兴趣流量"与 PBR 互相抢先匹配；
• 策略按 IP 固定，却忽略 CDN 地址、DNS 变化和 IPv6。

10.5 Linux 多 WAN 原理示例

以下命令只用于说明路由策略；接口、网关和表号要按环境替换，并注意 NetworkManager、systemd-networkd 等可能接管持久化配置。

# 查看主表与规则
ip route show
ip rule show

# 两条示例默认路由：优先级语义需按本机实现验证
ip route add default via 192.0.2.1 dev wan1 metric 10
ip route add default via 198.51.100.1 dev wan2 metric 100

# 为 192.168.10.0/24 选择独立路由表 100
ip rule add priority 100 from 192.168.10.0/24 table 100
ip route add table 100 192.168.10.0/24 dev lan0
ip route add table 100 default via 192.0.2.1 dev wan1

# 监听路由与邻居变化
ip monitor route neigh

如果表 100 中 WAN1 的默认路由不随健康状态撤销，这条 PBR 规则会把流量困在故障路径。因此生产实现必须把探测、路由更新、conntrack 清理策略和回退路径作为一个整体。

11. 4G/5G、双 SIM、双 Modem 与双运营商

11.1 Dual SIM 不等于 Dual Modem

图 14　双 SIM 单 Modem 通常在两个身份之间切换；双 Modem 才具备两条蜂窝链路同时在线的硬件基础。

项目	Dual SIM + Single Modem	Dual Modem
无线基带数	1	2
两张卡同时注册/承载	通常不能；按策略切卡	可以具备同时在线能力
切换组成	断开/切换 SIM、注册、PDP/PDN 会话、地址与路由更新	可预先保持第二链路在线，缩短路径准备时间
负载均衡	通常不具备真正双蜂窝并发	可能支持，仍取决于固件与授权
成本/功耗/天线	较低	更高，天线隔离、散热和射频规划更复杂

"通常"很重要：eSIM、多 profile、双待与多基带架构各有差异，必须核对具体 SKU 的 Modem 数、并发承载能力、SIM 到 Modem 的映射、频段组合、天线和软件功能。

11.2 两张不同运营商 SIM 是否完全独立

不同运营商通常比同运营商两张 SIM 更能隔离核心网、认证、地址池和运营商骨干故障，但仍可能共享：

• 同一铁塔、机房、站点电源或本地光纤回传；
• 同一设备、天线、供电和安装位置；
• 同一区域自然灾害、干扰或施工风险；
• 同一云出口、VPN 网关、DNS 或应用单点；
• 漫游/虚拟运营商背后的同一承载网络。

冗余应按"故障域"评估，而不是按 SIM 数量评估。现场勘测还应分别测试两家运营商的 RSRP/RSRQ/SINR、时延、丢包、拥塞时段、CGNAT、IPv6、固定地址和上行覆盖。

11.3 工业现场的有线 + 5G

图 15　PLC/HMI/IPC 经工业路由器接入；有线为主、5G 为备，云/SCADA 业务的隧道、DNS 和重连策略必须同时验证。

有线与 5G 的介质差异能降低同一种接入故障的相关性，但工业现场仍应提供独立天线位置、浪涌/接地、可靠供电、SIM 资费告警、弱覆盖监测、本地缓存和远程回滚。若远程管理仅允许从固定公网 IP 入站，5G CGNAT 下应改用设备主动发起的 VPN/管理隧道。

12. VPN 多链路冗余

物理 WAN 可用不代表隧道可用；反过来，接口故障也不一定要重建所有 VPN，取决于协议和实现是否能迁移外层地址。VPN 冗余可采用：

1. WAN1 上 Tunnel 1、WAN2 上 Tunnel 2，两个隧道预建并用静态/动态路由选路；
2. 一个隧道配置多个远端或本地地址，失败后重新连接；
3. IKEv2 MOBIKE、WireGuard endpoint roaming 等支持地址变化的机制；
4. 在 SD-WAN Overlay 中把多个加密隧道统一纳管。

12.1 IPsec

IKE SA 与 Child/IPsec SA 包含安全参数和外层地址状态。WAN 切换导致公网地址或 NAT 映射变化时，普通实现可能需要重新协商。应核对：

• IKEv2 liveness、重传与 DPD 行为；IKEv2 本身可用空 INFORMATIONAL 检查存活，RFC 3706 是较早的 IKEv1 DPD 扩展，二者不要混写；
• NAT-T 通常使用 UDP 4500，但策略、防火墙与运营商 CGNAT 必须允许；
• 双 WAN 是否分别建立 Tunnel 1/Tunnel 2，路由是否指向对应隧道；
• MOBIKE（RFC 4555） 可更新 IKEv2 与隧道模式 IPsec SA 的外层地址，使支持的端点在地址变化时迁移；它不是所有 IPsec 产品的默认能力，也有 NAT 和双方移动等限制；
• MTU/MSS：备用 Internet + IPsec 的额外封装可能比 MPLS 路径更小，需用 PMTUD、MSS Clamp 或明确 MTU 设计并测试。

12.2 OpenVPN

OpenVPN 2.7 官方手册中的 remote 可配置多个远端，客户端按顺序尝试；remote-random 只随机化远端列表的初始顺序，能做基础分散但不是链路聚合；keepalive 是 ping/ping-restart 的便捷写法。WAN 变化后是否重新解析、重连、保留虚拟地址和恢复路由，受客户端模式、拓扑、认证和服务端配置影响。

12.3 WireGuard

WireGuard 的 PersistentKeepalive 可在 NAT/防火墙后维持映射；有效认证报文可以让对端更新 endpoint，体现"漫游"能力。但它不会自动把普通流量同时条带化到多个 WAN，也不会替代外部健康检查、路由策略和冗余 peer 设计。

12.4 专线 + Internet/IPsec 的切换链

图 16　备用链路恢复包含 Internet 可用、IPsec 状态、路由、MTU/NAT 和应用重连多个阶段。

正常业务经 MPLS；专线故障后，路由转到已建立或新建立的 Internet/IPsec 隧道。若备用隧道平时不在线，T_tunnel 会显著增加；若两条隧道同时在线，应防止路由递归让 Tunnel 2 的外层流量错误走入 Tunnel 1。

13. SD-WAN、Packet Duplication 与 FEC

SD-WAN 把多个 Underlay（MPLS、Internet、5G、卫星等）上的加密 Overlay、集中策略、应用识别和性能监控组合起来。MEF 70.2 定义了外部可见的 SD-WAN 服务属性和框架，但每个厂商的探测、分类、控制器、FEC、复制和故障恢复能力不同。

图 17　实时业务可按时延/抖动/丢包选路，批量数据可按带宽/成本选路；策略在多个加密 Overlay 路径间动态调整。

传统 Dual-WAN 通常侧重接口健康、默认路由和基础按流分配；SD-WAN 通常进一步提供：

• 多 Underlay 上的统一 Overlay；
• 连续 SLA 测量：Latency、Jitter、Packet Loss、Availability；
• 应用/业务分类和分段；
• Dynamic Path Selection、Traffic Steering 和集中策略；
• 可选的加密、FEC、Packet Duplication、路径调节和可观测性。

SD-WAN 不只是普通 VPN：VPN 主要提供隧道与安全关联；SD-WAN 把路径测量、策略编排、应用识别和多站点运维叠加在隧道之上。但也不能把某一厂商的可选功能写成 SD-WAN 的普遍必备能力。

13.1 基于质量与业务的选路

假设 WAN1 RTT 20 ms、丢包 0.1%，WAN2 RTT 80 ms、丢包 0%。视频会议可能优先低时延 WAN1，并在抖动或丢包越阈值时转移；大文件下载可能优先无丢包且带宽高的 WAN2。阈值要设置进入/退出滞回，否则质量在边界附近波动会引发 Path Flapping。

13.2 Packet Duplication

图 18　同一关键数据包经两条路径发送，聚合端接收最先到达的有效副本并丢弃重复副本。

Packet Duplication 需要两端或聚合端能够标识、排序和去重。它可降低单路径随机丢包或抖动对关键控制/实时业务的影响，但复制流量的数据量大致翻倍，还会增加封装和聚合端负担。它适合少量关键流，不应默认施加于所有普通下载。

13.3 FEC

FEC（Forward Error Correction，前向纠错）发送修复数据，使接收端在一定丢包范围内恢复原始数据。FEC 常用于弱网、蜂窝、实时音视频和部分 SD-WAN Overlay；代价是带宽、编码延迟和计算量。保护比例应根据观测丢包调整。FEC 处理的是丢包恢复，不是传统主备链路切换，也无法修复持续超过冗余能力的长时间断链。

14. MPTCP、Multipath QUIC 与 WAN Bonding

14.1 MPTCP

MPTCP（Multipath TCP，RFC 8684）在一个逻辑 MPTCP 连接内建立多个 TCP Subflow，例如 Wi-Fi 与 5G 各一个。它可以在路径间调度数据并在单路径失效时继续使用其他 Subflow。

图 19　MPTCP 需要通信端点支持，或由两端聚合网关/代理终止多路径；普通 Multi-WAN 中间路由器无法单方面改造既有 TCP。

MPTCP 的成立条件：

• 客户端与服务端都支持并启用 MPTCP；或者使用支持 MPTCP 的代理/聚合网关；
• NAT、防火墙和地址管理允许建立多个 Subflow；
• 调度、拥塞控制、乱序缓冲和链路质量适配正确；
• 应用或代理架构能接受连接终止位置与加密边界。

14.2 Multipath QUIC

基础 QUIC v1（RFC 9000）使用 Connection ID 支持 NAT Rebinding 和连接迁移，但同一时刻只在一条路径上传输应用数据；它不等于同时多路径聚合。截至本文核对日期 2026-08-31，IETF draft-ietf-quic-multipath-21 已进入 RFC Editor 流程但仍是 Internet-Draft，目标是让一个 QUIC 连接同时使用多个路径。工程选型必须核对最终发布状态、客户端/服务端实现、调度算法与互通性，不能把草案能力当作现网普遍能力。

14.3 Tunnel/WAN Bonding

WAN Bonding 或 Packet-level Bonding 通常在站点边缘和云/数据中心聚合网关之间建立多条隧道，把一个业务流拆分、编号、经不同 WAN 发送，并在远端重排、去重和重传。它可能提升单个逻辑业务的可用带宽，但需要：

• 两端聚合节点，而不是只改本地路由器；
• 足够的远端出口带宽和可用性；
• 处理路径时延差、乱序、丢包和 MTU；
• 评估加密、许可、云流量与单点聚合端成本。

MPTCP、Multipath QUIC 与隧道 Bonding 都是"真正多路径"的候选，但层级、端点、加密可见性和部署成本完全不同。

15. A--J 十种工程方案

以下方案是设计模板，不是可以原样复制的配置。每个项目都应先画出物理、电源、运营商、路由、隧道、DNS 和应用依赖，再按故障域做演练。

15.1 方案 A：有线主链路 + 5G 备用

拓扑见图 15。

验收项	设计要点
正常路径	PLC/HMI/IPC → 工业路由器 → Ethernet WAN → Cloud/SCADA
故障路径	有线端到端健康失败后，经已注册的 5G → 移动网 → VPN/Cloud
健康检查	接口/网关用于快速信号，跨运营商公网目标 + DNS/HTTPS/业务心跳用于确认；5G 同时监测注册和数据会话
路由逻辑	有线默认路由优先；5G 为浮动路由。PBR 必须允许主路径失败时回退
NAT 影响	公网源地址改变，既有 TCP/MQTT/Modbus TCP 通常重连；5G 可能处于 CGNAT
VPN 影响	最好预建 5G 隧道，或明确 IKE/OpenVPN/WireGuard 重连时间与 DNS 解析
业务影响	本地采集不中断不等于上云不中断；使用 Store-and-Forward、时间戳、去重和指数退避
优点	部署快、介质异构、适合偏远站点
缺点	无线波动、资费、覆盖、CGNAT、天线/基站共享风险
适用	水务、能源、制造、环境监测、无人站点远程运维

15.2 方案 B：双运营商宽带负载均衡

拓扑与按流分配见图 6。

验收项	设计要点
正常路径	新会话按 5-tuple/源地址哈希或权重分配到 ISP1、ISP2
故障路径	失效 ISP 从可选池和路由中移除，新连接映射到健康 ISP
健康检查	每个 WAN 强制绑定源接口，使用跨故障域多目标和 DNS/HTTPS；避免探测被另一条 WAN 代答
路由逻辑	可用等价/加权路由或产品 Multi-WAN 策略；入站服务另需 BGP、DNS/负载均衡器等设计
NAT 影响	每个出口单独 SNAT；既有连接不能简单改用另一公网地址
VPN 影响	隧道需固定外层 WAN 或建立双隧道，避免哈希改变外层路径
业务影响	多会话总吞吐提高，单 TCP 不会天然叠加；链路失败时既有会话多需重连
优点	利用两条带宽，隔离部分运营商故障
缺点	NAT、回程、DNS、会话粘性与入站发布复杂
适用	园区上网、门店、分支、访客与办公流量并发

15.3 方案 C：专线主链路 + Internet IPsec 备用

拓扑见图 16。

验收项	设计要点
正常路径	分支/工业站点经 MPLS/专线访问总部或数据中心
故障路径	专线不可达后，经宽带建立的 IPsec Tunnel 2 转发内部网段
健康检查	专线 PE 邻居、BFD/路由状态加远端业务前缀探测；备用 Internet 与隧道单独探测
路由逻辑	专线路由优先，IPsec 路由为浮动或动态路由次优；防止隧道外层递归入隧道
NAT 影响	内网到内网通常 NAT Exemption；Internet 外层可能 NAT-T
VPN 影响	热备隧道可减少 T_tunnel；冷备需计算 IKE、认证和路由建立时间
业务影响	路径时延、带宽、MTU 变化可能使实时控制和大包受影响；既有连接仍需测试
优点	专线稳定性与 Internet 覆盖/成本互补
缺点	策略、加密、MTU、路由收敛和安全域更复杂
适用	分支互联、OT/IT 数据上送、ERP、远程运维

15.4 方案 D：双交换机 + LACP

拓扑见图 8。

验收项	设计要点
正常路径	服务器/路由器的 LAG 成员接入逻辑上统一的双交换系统（堆叠/MLAG/MC-LAG）
故障路径	一个成员或一台成员交换机故障后，哈希流量重映射到剩余成员
健康检查	LACP 成员状态、物理链路、对端一致性；必要时增加 BFD/上层探测
路由逻辑	上层看到一个逻辑接口；若两台交换机不能形成同一逻辑对端，应改用双三层链路或 Active/Backup
NAT 影响	L2 聚合本身通常不改变 NAT，但重映射期间可能有少量丢包
VPN 影响	不改变隧道外层地址，通常无需重协商
业务影响	多流聚合容量提升；单流仍通常受单成员限制
优点	标准聚合、成员利用率高、链路容错
缺点	多机箱一致性、Peer Link/Keepalive、分裂脑与哈希不均衡需管理
适用	服务器上联、交换机互联、路由器/防火墙到园区核心

15.5 方案 E：RSTP 工业环网

拓扑见图 10。

验收项	设计要点
正常路径	环中一条冗余端口处于 Discarding，形成无环工作树
故障路径	工作链路或交换机故障后重新计算，备用端口进入转发
健康检查	RSTP BPDU、端口/链路状态；应测试单向故障而不只拔线
路由逻辑	主要为二层拓扑变化，上层 ARP/MAC 学习和组播恢复也影响业务
NAT 影响	环内通常无 NAT；上联路由器仍是单点时需另行冗余
VPN 影响	环内短时丢包可能触发 VPN/业务超时，取决于收敛与定时器
业务影响	控制周期越短，对丢包、乱序和收敛越敏感，必须用真实负载验收
优点	开放标准、设备选择广
缺点	错误根桥/边缘端口、规模、混合协议和定时器可能造成不确定性
适用	工厂产线、变电站辅助网、交通与楼宇控制；严苛场景可评估 MRP/ERPS

15.6 方案 F：双路由器 + VRRP + 双 WAN

拓扑见图 11。

验收项	设计要点
正常路径	LAN 以 VIP 192.168.10.1 为网关，Router A Active，按策略使用 WAN1/WAN2
故障路径	路由器 A 整机或关键路径失败后降低 VRRP 优先级，Router B 接管 VIP/虚拟 MAC
健康检查	VRRP 通告 + 多心跳 + WAN/上游路径监测，避免"活着但出不去"的节点保持 Active
路由逻辑	两台路由器的静态/动态路由、PBR 和对象必须一致；对外路由也要收敛
NAT 影响	若要保留会话需同步支持的 NAT/Session 状态；不同公网地址仍可能中断
VPN 影响	VPN SA 是否同步、对端是否接受浮动地址、隧道由谁拥有均取决于产品
业务影响	VIP 接管可保持默认网关地址，但不保证已有 TCP/VPN 无损
优点	同时覆盖 LAN 首跳与设备故障，可叠加 WAN 冗余
缺点	状态同步、分裂脑、双机软件一致性和全负载容量成本高
适用	园区出口、工业核心、数据中心边界、重要分支

15.7 方案 G：双 5G Modem + 双运营商

拓扑差异见图 14 右侧。

验收项	设计要点
正常路径	Modem 1 → Operator A，Modem 2 → Operator B，同时在线；按流、业务或主备使用
故障路径	单运营商/单 Modem 异常后，流量转到另一链路
健康检查	注册与数据会话状态、真实公网/业务探测、无线质量和持续高丢包阈值
路由逻辑	不同网关/地址池独立，策略需考虑 CGNAT、IPv6、费用和带宽变化
NAT 影响	两个公网/CGNAT 映射不同，既有会话通常重建
VPN 影响	推荐每个 Modem 独立 Overlay 隧道，或采用支持迁移的客户端
业务影响	可提高蜂窝总体并发和冗余；不能消除共享塔站、电源、天线位置故障
优点	无固定线时也能构建双接入，部署灵活
缺点	硬件、流量费、功耗、热设计和射频复杂度高
适用	移动装备、临时工地、应急通信、难以铺设光纤的站点

15.8 方案 H：SD-WAN 多链路动态选路

拓扑见图 17。

验收项	设计要点
正常路径	Edge 在 MPLS、Internet、5G 上建立 Overlay；应用按 SLA 与业务策略选路
故障路径	某路径越过损失/时延/抖动阈值后，新流或指定业务转到合格路径
健康检查	双向主动探测加被动性能；阈值需有滞回、测量窗口和目标故障隔离
路由逻辑	Underlay 可达性与 Overlay 路由分离；控制器不可达时必须有本地降级策略
NAT 影响	Overlay 可稳定内部地址，但外层 NAT 和云聚合出口仍需设计
VPN 影响	通常内置加密隧道，密钥轮换、证书和双 Hub 可用性需验证
业务影响	可按应用动态选择；是否保留既有会话、是否支持 sub-second 由产品与协议决定
优点	可观测、集中编排、多链路质量感知和分段能力强
缺点	控制器/许可证/云 Hub 依赖、策略复杂、厂商差异与锁定
适用	多分支、跨区域、混合云、SaaS、复杂 SLA

15.9 方案 I：关键业务 Packet Duplication

原理见图 18。

验收项	设计要点
正常路径	关键包带序号后同时经 WAN1/WAN2 发送，远端聚合器接收最快有效副本
故障路径	任一路径完全失败时，另一副本仍可能到达，无需等待传统切换完成
健康检查	仍需监测两条路径，失效路径应退出复制以节省资源
路由逻辑	由 Overlay/应用复制和去重，不是普通 ECMP/逐包轮询
NAT 影响	两条外层映射不同，由聚合端以隧道会话/序号统一识别
VPN 影响	常在加密 Overlay 内实现；两端必须支持相同封装与密钥
业务影响	降低单路径随机丢包/抖动，但不能保证绝对零丢包；复制窗口和乱序仍需处理
优点	对少量实时关键流恢复快
缺点	约双倍传输量、聚合端依赖、成本高
适用	远程控制、实时媒体、低码率高价值遥测；不适合全部大流量

15.10 方案 J：MPTCP / WAN Bonding 多链路聚合

端点条件见图 19。

验收项	设计要点
正常路径	一个逻辑业务由多个 MPTCP Subflow，或由站点/云聚合器拆分到多条隧道
故障路径	单 Subflow/隧道失败后由其他路径继续传输，调度器重算
健康检查	传输层确认、路径验证、RTT/丢包/拥塞状态；不只看接口
路由逻辑	每个 Subflow/隧道需被源地址策略稳定引到指定 WAN
NAT 影响	多个 Subflow 可有不同 NAT 映射；中间盒兼容性需验证
VPN 影响	Bonding 可在 VPN 内或外；加密终止位置决定可见性、MTU 与安全边界
业务影响	具备提高单逻辑业务吞吐和连续性的条件，但异质路径乱序可能降低收益
优点	真正利用多路径、可同时做聚合与容错
缺点	需要端点/聚合器、调度与缓冲复杂，远端服务和费用增加
适用	移动终端、直播回传、应急通信、大文件上行、聚合型 SD-WAN

16. 十二类故障场景与检测矩阵

"是否能发现"取决于探测位置和判定逻辑。下表中的"通常"需要用本设备实测确认。

故障场景	物理/本地状态	Ping 网关	公网多目标	DNS/HTTP/业务探测	路由/隧道协议	关键动作
1. 网线拔掉	能	失败	失败	失败	邻居/会话可能 Down	快速链路事件 + 防抖
2. WAN 仍 UP、运营商断网	不能	可能成功	通常失败	失败	对外邻居可能失败	端到端多目标撤路由
3. 网关可达、Internet 不可达	不能	成功	失败	失败	本地邻居正常	不把网关 Ping 当充分条件
4. DNS 故障	不能	成功	IP 探测成功	DNS Query 失败	路由正常	切 DNS、修 Split/VPN DNS；未必换 WAN
5. 公网路由异常	不能	成功	视目的而异	相关业务失败	BGP/路径可能异常	多前缀/业务目标判定，防止全局误切
6. VPN 服务器不可达	不能	成功	Internet 可成功	隧道业务失败	DPD/Keepalive/SA 异常	切换 peer/隧道，而非盲目判 WAN 坏
7. 高丢包未断网	UP	间歇成功	可测损失	业务质量下降	邻居可能仍 Up	滑动窗口、进入/退出阈值、按业务降级
8. 高延迟/抖动	UP	可达但慢	可测 RTT/Jitter	实时业务受损	邻居通常 Up	质量选路，批量与实时流采用不同策略
9. 蜂窝网络掉线	Modem/数据会话可见	失败	失败	失败	隧道 Down	重新注册/换运营商并限制重试风暴
10. SIM 注册失败	Modem 报错	不可探测	不可探测	不可探测	无地址/邻居	检查 SIM、PIN、APN、资费、信号、漫游
11. 主路由器整机故障	本机无响应	终端网关失败	失败	失败	VRRP/HA 心跳丢失	设备级 HA/VIP 接管；链路备份单独不够
12. 交换机上联故障	端口或协议可见	可能仍通本地	视路径而异	视业务而异	STP/LACP/BFD 变化	L2/L3 收敛并验证 MAC/ARP/组播恢复

此外还应测试"探测目标自身故障""防火墙规则只缺 WAN2""主备 DNS 不一致""双 WAN 共用同一 ONT/配电""双 SIM 实际同承载"等隐藏共同单点。

17. 测试方法、工具与验收指标

17.1 先定义测量点

至少在四个时间轴上留证：

1. 路由器接口/健康检查日志；
2. RIB/FIB、PBR 和隧道状态；
3. LAN 与 WAN 抓包；
4. 真实业务客户端/服务端日志。

所有设备先同步 NTP/PTP 或使用同一采集器，否则无法把 T_detect、T_route、T_tunnel 和 T_application 对齐。验收指标应包含：故障发生时刻、首次判 Down、路由变化、备用路径首包、DNS 成功、VPN 恢复、首个成功业务事务、丢包/重复/乱序数量、既有会话结果和 Failback 二次扰动。

17.2 单流、并发流与聚合容量

iperf3 默认通常建立一个数据流；-P 创建多个并行客户端流，-R 测反向，--bidir 测双向。测试目的不同，方法也不同：

# 单 TCP 流：观察一个 Flow 的路径与上限
iperf3 -c 198.51.100.50 -t 60

# 8 个并行流：观察 LAG/Multi-WAN 的总体分配与容量
iperf3 -c 198.51.100.50 -P 8 -t 60

# 反向与双向；服务端、CPU、加密和接入也必须能承载
iperf3 -c 198.51.100.50 -R -t 60
iperf3 -c 198.51.100.50 --bidir -t 60

不要只看合计数字。还应按接口查看每个成员/WAN 的字节、丢包、重传和队列，并用多客户端/多目的增加哈希熵。测试 LACP 单流边界与测试聚合总容量不是同一个实验；测试普通 Multi-WAN 也不能用一个下载就断言负载均衡无效。

17.3 故障切换实验流程

1. 记录正常接口、地址、默认/策略路由、ARP/NDP、NAT、VPN 和 DNS。
2. 持续运行 ICMP、DNS Query、TCP Connect、HTTP 请求和真实业务长连接。
3. 同时抓取 LAN、WAN1、WAN2；标记统一时间。
4. 先执行"拔掉 WAN1"这种明确物理故障，记录完整时间链。
5. 再保持 Link Up，只阻断网关之后的上游路径，验证端到端检测。
6. 分别注入 DNS 故障、单目标故障、高丢包、高延迟、VPN 对端故障、MTU 黑洞。
7. 恢复 WAN1，记录连续成功阈值、Hold-down、Failback 和会话归属。
8. 重复多次，计算最小/平均/95 分位/最大，而不是只展示最好一次。
9. 在空载、峰值、多流、加密和真实业务条件下分别测试。
10. 将预期、实际和证据写入验收表；任何"无感"必须由业务端证据支持。

17.4 工具与用途

工具	适合检查	使用提醒
ping / fping	连续可达、RTT、多个目标	ICMP 可能限速；固定源接口/地址，避免绕另一 WAN
traceroute / mtr	路径变化、逐跳时延/丢包线索	中间节点不响应不等于转发失败；以端到端为准
curl	指定接口执行 HTTP(S)、状态码、DNS/TLS/请求时间	可用 --interface，并记录状态码与内容语义
dig / nslookup	指定 DNS 查询、超时、响应码、Split DNS	分别测路由器和终端实际使用的解析器
ss / netstat	TCP/UDP 套接字、状态、重传线索	将进程/端口与业务日志对齐
conntrack	NAT/连接跟踪项与状态变化	生产设备上谨慎清表；先只读观察
ip route / ip rule	主/策略路由、选路结果	同时查看具体目的的 ip route get 和所有路由表
ip monitor	实时路由、地址、邻居变化	适合给切换时间戳
tcpdump / Wireshark	ARP、LACP、VRRP、BFD、TCP、DNS、IKE/ESP 证据	多接口同时抓包，注意 snaplen、环形文件与隐私
iperf3	单流与多流吞吐、反向/双向	它测路径容量，不代表真实应用一定恢复

示例只读排查命令：

ip -br link
ip -br address
ip rule show
ip route show table all
ip route get 203.0.113.50 from 192.168.10.100
ip monitor route neigh
ss -tnop
conntrack -L
curl --interface wan1 --connect-timeout 3 https://example.invalid/health
tcpdump -ni any '(arp or icmp or port 53 or port 500 or port 4500)'

example.invalid 是保留的无效域名，实际 HTTPS 探测应替换为自有稳定端点；不要把不存在的示例直接投入生产。

17.5 "毫秒级"宣传的核验清单

• 测的是物理链路事件、二层转发、路由 FIB、隧道还是业务事务？
• 故障是端口 Down，还是 Link Up 的黑洞、高丢包、上游路由故障？
• 拓扑规模、设备数量、流量负载和定时器是什么？
• 备用链路/隧道是否已热备？
• 测量从哪一包开始，到哪一包结束？是否包含检测阈值？
• 既有 TCP/NAT/VPN 会话是否保留，还是只有新 Ping 恢复？
• 最大值与 95/99 分位是多少？是否只报告最佳样本？
• 该数字来自标准边界、厂商特定条件，还是本项目实测？

只有完整回答这些问题，"切换时间"才对业务有意义。

18. 故障排查方法论

图 20　从业务症状向下验证接口、健康、路由、NAT、防火墙、DNS、VPN和应用，并用抓包闭环。

18.1 "已切到备用 WAN，但业务仍不通"十步法

1. 定义症状：所有业务还是一个域名/端口？新连接还是既有长连接？IPv4 还是 IPv6？
2. 接口与地址：WAN2 是否真的获得地址、网关、DNS和蜂窝数据会话？物理 Up 是否稳定？
3. 健康状态：哪个目标失败、判定是 Any 还是 All、探测是否固定从 WAN2 发出？
4. 有效路由 ：检查 RIB/FIB 和 route get，不能只看配置页面；递归下一跳是否仍指向 WAN1？
5. PBR：源网段/端口的策略是否优先命中失效 WAN1？是否定义了 fallback？
6. NAT：WAN2 是否有正确 SNAT、NAT Exemption、回程和 conntrack？旧状态是否阻止新映射？
7. Firewall：WAN2 zone、出入方向、IPv6、ICMP/PTB 和 VPN 控制流量是否放行？
8. DNS：IP 可达但域名失败时，核对实际解析器、Split DNS、VPN DNS 和缓存。
9. VPN/MTU：IKE/SA、OpenVPN/WireGuard handshake、隧道路由是否恢复？小包通大包不通时查 PMTUD、MTU/MSS。
10. 应用与抓包：客户端是否仍等待旧 TCP 超时？在 LAN/WAN2/对端同时抓包，确认包在哪一跳消失及返回路径。

18.2 证据优先，而不是反复重启

重启可能清掉 conntrack、重建地址和隧道，从而掩盖根因。先保存：配置快照、接口计数、健康检查历史、路由表、策略命中计数、NAT/会话、VPN 日志和双向抓包。只有证据表明状态卡死或变更步骤要求时再重启，并记录前后差异。

18.3 安全与运维注意事项

• 不允许未受控的公网目标决定关键 OT 路由；自建探测端点并限制频率、认证和数据量。
• 不要为"切换方便"在备用 WAN 开放比主链路更宽的防火墙规则。
• 备链路也要更新证书、密钥、路由过滤、固件和监控；长期不演练的备份通常最不可靠。
• PBR/BGP/SD-WAN 变更需有回滚和 Out-of-Band 管理，避免把远程管理流量切断。
• 数据复制、FEC 和云聚合会增加流量与数据跨域，应评估合规、隐私和成本。

19. 横向比较、选型与常见误区

19.1 能力边界对比

"是"只代表具备技术条件，不代表无需额外设计；"条件"表示依赖模式、端点或厂商实现。

方案	工作层级	需两端支持	提高可用性	提高总体吞吐	提升单连接带宽	跨运营商	适用 Internet
Dual-WAN Failover	L3/WAN	否	是	否（主备）	否	是	是
Multi-WAN Load Balance	L3/WAN	否	条件：需健康检查	是，多流	否	是	是
LACP/LAG	L2	是，同一逻辑对端	是，成员故障	是，多流	通常否	否	只作为接入段
Linux Bonding	L2/主机	依模式	是，依模式	依模式	通常否	通常否	不是独立 Multi-WAN
STP/RSTP	L2	同一二层域设备	是，备用拓扑	通常否	否	否	只作为接入段
VRRP	L3 首跳	多路由器	是，网关	否	否	间接	是，但须另做 WAN
ECMP	L3	路由可达性需配合	是，路径	是，多流	通常否	条件	是
PBR	L3/策略	否	条件：须联动探测	可分流	否	是	是
BGP 多出口	L3 控制平面	ISP/对等支持	是	可多流	通常否	是	是
SD-WAN	Overlay/WAN	Edge/Hub 或服务端	是	是，多流；可选聚合	条件：产品 Bonding	是	是
MPTCP	传输层	是，或代理	是，Subflow	是	是，条件成立时	是	是
WAN/Tunnel Bonding	Overlay	两端聚合器	是	是	是，条件成立时	是	是
Dual SIM 单 Modem	蜂窝接入	否	是，SIM/运营商切换	通常否	否	可	是
Dual Modem	蜂窝接入/WAN	否	是	可，多流	普通路由下否	可	是

19.2 会话与工程代价对比

方案	无感切换	NAT 影响	VPN 影响	收敛/恢复	复杂度	成本	典型场景
Dual-WAN Failover	不天然	出口地址改变，旧会话常断	可能重建	由探测+路由+应用决定	低---中	低---中	门店、工业 CPE
Multi-WAN Load Balance	失败时不天然	每 WAN 独立映射、需粘性	隧道需固定路径	由探测和重映射决定	中	中	园区上网、多用户
LACP/LAG	成员故障可较平滑，仍需实测	通常无	通常无	LACP/硬件和上层共同决定	中	中	交换机/服务器上联
Linux Bonding	依模式与上层	作为 WAN 时仍受 NAT	依外层地址	由 miimon/ARP/LACP 等决定	中	低---中	Linux 服务器/网关
STP/RSTP	可能丢包，不保证会话无损	通常无	短暂丢包可能触发超时	拓扑/实现/定时器决定	中	低---中	园区/工业环网
VRRP	VIP 可保持，状态未必	需 HA 同步才可能保留	SA 同步依产品	通告、监视和状态恢复共同决定	中	中	双网关
ECMP	路径重映射会影响状态	对称与 NAT 关键	外层路径改变可能影响	路由收敛+BFD/协议定时器	中---高	中	核心网、多出口
PBR	不天然	每策略/出口需匹配	易与隧道策略冲突	探测联动决定	中---高	低---中	业务分流
BGP 多出口	不天然	入/出站地址策略复杂	可承载多隧道	BGP+BFD+上游策略决定	高	高	自有 ASN/地址的大型站点
SD-WAN	条件，依产品与协议	Overlay 可缓解，外层仍存在	通常内置，迁移边界依产品	SLA 窗口+策略+应用决定	高	中---高	多分支/混合云
MPTCP	可在剩余 Subflow 继续，非绝对无损	多 Subflow 映射需兼容	与 VPN 叠加需设计 MTU/端点	传输层路径检测与调度	高	中---高	支持端点/代理的移动与聚合
WAN Bonding	条件，聚合器可隐藏路径变化	外层多映射，内层可稳定	常与隧道一体	调度/重排/重传决定	高	高	直播、应急、关键上行
Dual SIM 单 Modem	通常不无感	地址改变	常需重连	SIM 切换+注册+数据会话+业务	低---中	低	低成本蜂窝备份
Dual Modem	普通会话仍可能断	两套地址/映射	可预建双隧道	探测+选路+应用决定	中---高	高	双蜂窝关键站点

任何表格中的"快/慢"都不能代替项目数据。应使用第 17 节的方法在目标固件、真实拓扑、业务负载和最差无线/拥塞条件下获得分位值。

19.3 场景化选型

工业现场： 首先保证本地控制闭环不依赖 WAN；对上云/运维采用有线 + 异运营商 5G、主动 VPN、Store-and-Forward。二层环按互通与控制周期选择 RSTP、MRP 或 ERPS。关键站点再叠加双路由器、电源与交换机冗余。

企业园区： 服务器/交换机上联用 LACP，二层环用 RSTP/MSTP，默认网关用 VRRP/设备 HA，Internet 多出口用 Multi-WAN 或 BGP/SD-WAN。不要让一个 LACP 设计承担 ISP 冗余。

多分支与 SaaS： 链路少、策略简单时 Dual-WAN 足够；需要按应用 SLA、集中编排、分段和多 Hub 时评估 SD-WAN。先证明 Underlay 独立，再评估 Overlay 功能。

远程运维： 设备主动建立双 VPN，保留 Out-of-Band 通道；管理流量的 PBR、DNS、证书与 ACL 必须在备用路径独立可用。CGNAT 下不要依赖公网入站。

单连接聚合： 只有明确需要一个逻辑连接跨多路径时，才考虑 MPTCP 或两端 WAN Bonding；普通网页、多用户上网通常用按流负载均衡更简单。

19.4 常见错误配置

1. 只检测接口 Link；
2. 只 Ping 默认网关；
3. 两个探测地址处于同一服务/运营商故障域；
4. 探测没有绑定 WAN，失败探测经另一出口绕行；
5. Failure/Recovery Threshold 太低，Failback 太快；
6. 没有 Session Stickiness，或逐包分流造成乱序；
7. 忽略 NAT、公网源地址和 Conntrack；
8. 忽略 ISP DNS、Split DNS 与 VPN DNS；
9. 忽略 VPN 重建、密钥、认证和对端多地址；
10. PBR 固定指向故障 WAN，与默认路由 Failover 冲突；
11. ECMP/双机导致非对称回程，有状态防火墙丢包；
12. WAN2 防火墙、NAT、IPv6、对象或证书不完整；
13. 备用 VPN 的 MTU/MSS 与主路径不同；
14. Backup Route 的 Metric/Distance/Preference 方向配错；
15. 双线路共用 ONT、上联光缆、机房电源或云 VPN Hub；
16. 双 SIM 实为单 Modem，或两卡共享同一承载运营商；
17. 跨两台独立交换机错误配置 LACP，却没有堆叠/MLAG；
18. 长期不演练备用路径，资费、证书或固件早已失效。

19.5 十个必须澄清的误区

1. "两条 100M 后任何下载都是 200M。" 错。普通按流 Multi-WAN 提升多会话总容量，单流通常只走一条。
2. "LACP 就是双 WAN。" 错。LACP 面向同一逻辑对端的以太网成员，双 WAN 面向独立 ISP 和路由/NAT。
3. "插两张 SIM 就是双 5G 在线。" 错。单 Modem 通常只能在 SIM 间切换。
4. "WAN Link Up 就表示网络正常。" 错。它只证明本地物理层。
5. "网关能 Ping 就表示 Internet 正常。" 错。网关之后仍可黑洞。
6. "切换成功后 TCP 不会断。" 错。源公网 IP/NAT 状态改变时普通 TCP 通常断开。
7. "VRRP 解决所有冗余。" 错。它主要解决 LAN 默认网关首跳。
8. "STP 和 LACP 是同一技术。" 错。前者消除二层环路，后者聚合并行成员。
9. "SD-WAN 只是 VPN。" 错。它还包含路径测量、策略、应用识别与多站点编排。
10. "有两个 WAN 口就没有单点。" 错。设备、电源、上联、运营商、DNS、VPN Hub 和应用都可能仍是单点。

20. 核心问题速答、总结与参考资料

20.1 二十七个核心问题速答

1. 什么是真正的链路备份？ 能端到端检测、可靠判故、自动切换、验证备用路径、恢复业务，并在稳定策略下回切的闭环。
2. Failover 与 Load Balancing 有何区别？ 前者在故障后换路径；后者在正常时就把多个流分散到多路径。
3. Load Balancing 与 Link Aggregation 有何区别？ 前者可跨独立 WAN 做路由/NAT 分流；后者聚合同一逻辑对端间的链路。
4. LACP 能否实现双 WAN？ 不能把两个独立 ISP 直接变成一个 LACP；运营商若提供同一逻辑以太网服务是另一种特定场景。
5. 两条 100 Mbps 是否一定得到 200 Mbps？ 不一定。多流合计可能接近聚合容量，单流、协议开销和瓶颈会限制实测。
6. 为什么单 TCP 通常不能用两个普通 WAN？ 按流哈希和有状态 NAT 会把连接固定到一个出口，防止乱序和状态不一致。
7. 什么技术可实现单连接多路径？ MPTCP、支持多路径的 QUIC 实现、或两端 Tunnel/WAN Bonding；都需要端点或聚合网关条件。
8. Link Up 为什么不能代表 Internet 正常？ 它只说明本地物理载波，网关之后的路由、DNS、隧道和应用仍可能失败。
9. 应 Ping 网关还是公网地址？ 两者用途不同；网关看本地接入，多个公网/业务目标看端到端，最好联合并分层判定。
10. 如何设计可靠健康检查？ 绑定源 WAN，多目标跨故障域，组合物理、IP、DNS/HTTP/业务探测，设置连续阈值、超时和滞回。
11. 如何避免频繁切换？ 使用 Debounce、Hold-down、Dampening、不同的失败/恢复阈值和最小驻留时间。
12. Failover 与 Failback 怎样设计？ 故障侧及时隔离，恢复侧更保守；可稳定后抢占、非抢占或仅让新连接回主路。
13. 为什么切 WAN 后 TCP 常断？ 外层源 IP/端口和 NAT 映射变化，服务端看到的是不同套接字。
14. NAT 为什么影响无感切换？ NAT 是有状态映射；换出口会换公网地址/端口，反向包无法匹配旧状态。
15. VPN 在 WAN 切换后怎样？ 可能迁移、重建或切备用隧道；取决于 IKEv2 MOBIKE、OpenVPN/WireGuard 行为和产品实现。
16. VRRP 解决什么？ 多路由器之间的 LAN 默认网关冗余，不直接证明 WAN 或应用健康。
17. STP、RSTP、LACP 分别做什么？ STP/RSTP 消除二层环路并恢复备用拓扑；LACP 协商聚合成员。
18. ECMP 如何多路径？ 多个等价下一跳同时安装，通常用五元组或其他字段按流哈希。
19. PBR 如何分业务走 WAN？ 按源、目的、端口或应用命中策略并选择下一跳/路由表，同时必须定义健康回退和回程。
20. SD-WAN 比 Dual-WAN 多什么？ 多 Underlay Overlay、连续 SLA、应用识别、集中编排、动态路径和可选 FEC/复制等。
21. Dual SIM 与 Dual Modem 的区别？ 前者是两个身份/卡槽；后者有两套基带，才具备双蜂窝同时在线的硬件基础。
22. 不同运营商 SIM 一定完全冗余吗？ 不一定，仍可共享塔站、回传、电源、位置、设备、云端和漫游承载。
23. 工业路由器如何做有线 + 5G？ 有线主用、5G 热备或冷备，分层探测，独立 VPN/DNS/NAT，配合本地缓存、可靠电源和定期演练。
24. 如何测试真正切换时间？ 同步时间，在接口、路由、隧道和应用四处采证，记录 T_detect + T_decision + T_route + T_tunnel + T_application。
25. 如何判断"毫秒级"是否有意义？ 查故障类型、起止测点、拓扑/负载/定时器、是否热备、是否包含业务与会话，并看分位值而非最佳样本。
26. 备用 WAN 已生效但业务不通怎样查？ 依次查接口/地址、健康、有效路由、PBR、NAT、Firewall、DNS、VPN/MTU、应用重连，最后双向抓包闭环。
27. 怎样按场景选型？ 先列业务 RTO/丢包容忍和故障域，再从物理、L2、L3、WAN、隧道、设备、应用逐层补齐最小必要机制。

20.2 多层高可用模型

Layer 1：物理介质、光纤、蜂窝、供电、设备位置冗余
   ↓
Layer 2：LACP / STP / RSTP / MSTP / ERPS / MRP
   ↓
Layer 3：Floating Static / ECMP / OSPF / BGP / BFD / VRRP / PBR
   ↓
WAN：Dual-WAN / Multi-WAN / 双运营商 / Cellular / 卫星
   ↓
Tunnel：IPsec / OpenVPN / WireGuard / 双 Hub
   ↓
SD-WAN：SLA / Application Steering / 可选 FEC 与 Duplication
   ↓
Application：重连、幂等、缓存、队列、Cluster、数据去重

可靠系统通常不是购买一个"高可用"功能，而是让这些层级的故障检测、状态、控制和恢复目标一致。设计的终点也不是"备用接口亮了"，而是关键业务在明确的 RTO、数据完整性和安全边界内恢复。

---

最终结论： 多链路高可用的价值，不在于接口数量，而在于故障域是否独立、探测是否覆盖真实业务、切换是否联动路由/NAT/VPN，以及应用是否具备可验证的恢复机制。先定义故障和业务目标，再选择协议；先做最坏场景实验，再相信"高可用"。