SD-WAN 自动故障切换怎么验证？
简答：验证 SD-WAN 自动故障切换，不能只看备用链路是否变为“在线”，而要同时记录故障注入、健康检查判定、路由变化、实际出口、业务恢复和主链路回切。最短流程是：先做正常基线，再分别模拟断链、丢包、时延或抖动，最后用持续 Ping、TCP、HTTP 和真实业务流量交叉确认。
定义：SD-WAN 自动故障切换，是主链路不满足健康检查或策略条件时，系统自动把符合规则的流量转移到备用链路，并在条件恢复后按策略回切或保持备用路径的过程。
先试这一步：用一张记录表确认切换是否真的发生
开始前不要直接拔线。先为主链路和备用链路建立正常状态基线，并准备一个能持续产生流量的终端或探针。记录以下时间点：故障注入时间、健康检查变为失败的时间、成员或隧道状态变化时间、路由或策略变化时间、业务恢复时间、主链路恢复时间和回切完成时间。
| 项目 | 正常状态 | 故障期间 | 恢复后 | 判定依据 |
|---|---|---|---|---|
| 主链路 | 在线、优先级正常 | 断开或质量下降 | 恢复或保持备用 | 设备事件、接口和成员状态 |
| 健康检查 | 探测目标可达 | alive、dead 或质量超限 | 重新通过检查 | 健康检查明细和时间戳 |
| 实际出口 | 主链路地址或接口 | 备用链路地址或接口 | 按回切策略判断 | 路由、会话、NAT、流量路径 |
| 业务流量 | 持续可用 | 允许短暂丢包或重连 | 恢复且无持续错误 | Ping、TCP、HTTP、SaaS 或业务日志 |
| 切换质量 | 无异常 | 统计丢包、连接重置和恢复时间 | 检查是否抖动 | 监控时间线与抓包结果 |
验收重点：切换成功不等于所有连接都无感。新建连接是否走备用链路、已有 TCP 会话是否重建、NAT 是否变化，都要分别记录。不同厂商、软件版本和业务类型的切换表现并不相同，本文不把某个厂商的秒数或阈值当作统一标准。
测试前准备：先确认策略、健康检查和回滚条件
- 确认至少两条可用链路。检查接口、默认路由、网关、隧道或 SD-WAN 成员状态。若备用链路没有地址、网关或必要隧道，故障注入后不会形成有效切换。
- 确认业务匹配规则。记录重要业务的源地址、目的地址、协议、端口、应用识别、优先级和候选成员。手动固定出口的规则可能不会按性能 SLA 自动选路；Fortinet 文档也说明，固定成员规则通常要等链路 DOWN、健康检查失败或相关路由消失后才可能失效并转移。
- 确认健康检查对象。检查探测使用的是 ICMP、DNS、HTTP、ARP、BFD 或厂商自定义探针。探测目标必须能代表实际业务，否则可能出现“探测成功但业务不可达”。Meraki 的官方说明展示了 DNS、ICMP、HTTP 和 ARP 等不同检查方式，且 DNS 或 HTTP 的判定过程可能具有独立的时间窗口。
- 准备变更保护。安排维护窗口，保留控制台或带外管理入口，提前保存配置和当前状态，设置停止测试的条件，例如核心业务持续中断、控制面失联、路由环路或设备 CPU 异常。
- 通知业务使用者。测试期间不要只观察 Ping；如果要验证办公系统、语音、视频、站点到站点连接或 SaaS，应提前确认可接受的重连方式和业务影响。
厂商文档通常会要求先确认控制面、底层路由和设备配置。Cisco 的排障资料特别强调，生产环境执行诊断命令前应理解命令影响，并同时收集路由表、底层连通性、抓包和控制连接信息，可参考 Cisco SD-WAN 控制面与数据面排障文档。
最短执行流程：基线、注入、计时、验证、回切
- 建立基线。在没有故障时持续运行以下测试，并记录出口地址或接口。Windows 可执行
ping -t 目标地址，macOS 或 Linux 可执行ping 目标地址；Windows 还可使用Test-NetConnection 目标地址 -Port 443检查 TCP 端口，macOS 或 Linux 可使用curl -I --connect-timeout 5 https://目标域名。将“目标地址”和“目标域名”替换为实际可控的业务探针，不要把某个公共站点的结果直接当作所有业务的结论。 - 记录故障注入时间。使用设备提供的禁用成员、断开接口、拔除线路或暂停隧道方式。优先使用可回滚的管理操作；如果必须拔线，应确保带外管理和备用路径可用。
- 模拟硬故障。先测试接口断开、网关不可达或承载线路中断。观察健康检查、成员状态、默认路由、策略命中、隧道状态和事件日志是否按时间顺序变化。
- 模拟软故障。再测试链路仍显示在线、但丢包升高、时延或抖动超过配置条件、DNS 可用但业务 HTTP 不可达等情况。软故障往往比物理断链更容易暴露健康检查目标不合适的问题。
- 同时观察多种流量。持续 Ping 用于观察基础连通性；TCP 443 用于观察端口可建立性；HTTP 请求用于观察应用层返回；站点到站点、文件传输、语音视频或办公系统用于观察真实业务。至少记录新建连接和已有连接两类结果。
- 验证备用出口。不要只看仪表盘颜色。通过路由表、会话表、NAT 映射、接口计数器、流量路径或业务端看到的出口地址确认流量实际经过备用链路。
- 恢复主链路。解除故障后继续观察健康检查恢复时间、是否自动回切、是否保持备用链路、是否出现来回切换，以及已有连接是否被重置。
- 执行回滚。若路由未恢复、会话大量重置、健康检查反复变化或控制面异常，立即恢复原配置，重新启用主链路，停止进一步故障注入，并保存事件日志和抓包。
Meraki 的官方说明明确区分了主链路失效、备用链路接管以及主链路恢复后的回切行为，并提醒链路恢复后可能存在等待时间以避免频繁抖动。具体等待时间应以当前设备型号、固件和配置页面为准，不应直接套用到其他厂商。
按故障类型分流：每种故障都要验证什么
| 故障场景 | 怎么注入 | 重点观察 | 失败时优先检查 |
|---|---|---|---|
| 接口或线路完全中断 | 禁用接口、拔除线路或关闭上联 | 成员是否失效、路由是否撤销、流量是否转移 | 默认路由、成员优先级、策略是否固定出口 |
| 网关不可达 | 在维护窗口阻断网关或上游路径 | 接口可能仍在线，但健康检查是否失败 | 网关探测、ARP、下一跳和静态路由 |
| 丢包升高 | 使用链路或实验设备制造可控丢包 | 质量指标是否超过配置条件，业务是否切换 | SLA 阈值、采样周期、探测目标和统计窗口 |
| 时延或抖动升高 | 使用可控网络仿真或测试链路 | 实时业务是否降级，路径是否变化 | 指标采集、策略优先级、业务分类 |
| DNS 可用但业务不可达 | 保留 DNS，阻断目标应用或 HTTP 路径 | 健康检查是否误判为在线 | 是否仅依赖 DNS 或 ICMP，是否有应用层探测 |
| 隧道或控制连接中断 | 暂停隧道、阻断必要控制流量 | 控制面、数据面和业务路径是否分别恢复 | 证书、控制器可达性、底层路由和隧道参数 |
如果健康检查显示失败，但实际业务没有切换，优先检查 SD-WAN 规则是否使用了固定成员；如果链路状态已切换但业务仍失败，则检查策略路由、NAT、会话状态、DNS 和返回路径。Fortinet 文档中的手动选路示例说明，固定成员规则与性能 SLA 规则的行为不同，不能把两者混为一谈。
如何判断验收通过：至少满足四层证据一致
- 状态层一致：健康检查、成员、接口或隧道状态反映故障和恢复。
- 路由层一致：路由表、策略命中或 SD-WAN 服务状态显示候选路径已变化。
- 转发层一致：接口计数器、会话、NAT、抓包或流量路径证明实际数据已经从备用链路通过。
- 业务层一致：持续 Ping、TCP、HTTP 和真实应用分别达到预先约定的可接受结果。
建议将结果写成时间线，而不是只写“切换成功”：故障注入 10:00:00 → 健康检查失败 10:00:xx → 路由变化 10:00:xx → 备用流量出现 10:00:xx → 业务恢复 10:00:xx → 主链路恢复 10:05:00 → 回切或保持备用。其中 xx 必须填入实际观测值，不能用估计值。
验收阈值应由业务重要性、链路类型、设备版本和会话特征共同确定。例如，语音视频更关注连续丢包、抖动和重连；文件传输更关注吞吐和最终完整性；办公系统更关注新建连接成功率和已有会话重建时间。不要把单一厂商的默认检查周期直接当成统一行业标准。
切换失败或结果异常时，按这个顺序排查
- 没有发生切换：确认主链路是否真的被判定为失败，检查健康检查目标、采样周期、失败次数、SLA 阈值和规则优先级。
- 状态切换但流量未切换：检查策略是否绑定固定接口、默认路由是否仍指向主链路、策略路由是否覆盖了 SD-WAN 规则。
- 新连接成功但已有连接中断：检查 NAT 地址是否变化、会话是否绑定原接口、设备是否支持会话迁移；这类现象不一定表示故障切换失败，而可能是连接需要重建。
- Ping 成功但应用失败：增加 TCP 和 HTTP 层探测，检查 DNS、TLS、代理、应用端口和返回路径。
- 主链路恢复后反复切换：检查链路质量是否仍不稳定、回切等待时间、滞回设置和健康检查目标是否频繁变化。
- 控制面异常：分别确认设备到控制器的路由、DNS、证书、隧道和允许的服务。Cisco 的排障文档建议结合路由表、TCP Dump、嵌入式抓包和 FIA Trace 等数据定位控制面与数据面问题。
每次只改变一个变量，并保留故障前、故障中、恢复后的配置和日志。不要在生产环境连续拔线测试多个成员，否则很难判断是哪一个条件触发了切换，也可能把临时问题扩大成控制面故障。
常见问题
SD-WAN 只显示备用链路在线，能算自动切换成功吗？
不能。至少还要证明实际业务流量已改走备用链路，并检查路由、会话、NAT 或接口计数器。只看链路状态，无法排除策略固定出口、返回路径错误或业务端口被阻断。
拔线测试和丢包测试必须都做吗？
建议都做。拔线主要验证硬故障；丢包、时延、抖动和应用不可达属于软故障，可能触发不同的健康检查逻辑。只做拔线测试，容易漏掉“链路在线但不可用”的问题。
已有 TCP 连接中断，是不是说明故障切换失败？
不一定。链路切换可能带来出口地址、NAT 或会话路径变化，已有连接可能重置，而新建连接可以正常通过备用链路。应分别记录已有会话、重新建立的 TCP 连接和应用恢复时间。
主链路恢复后一定要自动切回吗？
不一定。回切行为由优先级、滞回、等待时间和厂商策略决定，可能自动回切，也可能保持备用链路以避免抖动。验收前应明确预期，并以设备当前配置和事件日志为准。
健康检查使用公共 DNS 或公共 IP 可以吗？
可以作为基础连通性参考，但不应单独代表所有业务。更稳妥的做法是同时使用运营商或企业可控的探针、站点到站点目标和应用层检查，并确认探针不会因为自身故障导致错误切换。
常见问题
SD-WAN 只显示备用链路在线，能算自动切换成功吗？
不能。还要通过路由、接口计数器、会话、NAT 或抓包确认实际业务流量已经经过备用链路。
拔线测试和丢包测试必须都做吗？
建议都做。拔线验证硬故障，丢包、时延、抖动和应用不可达验证软故障，两者可能触发不同的健康检查逻辑。
已有 TCP 连接中断，是不是说明切换失败？
不一定。出口或 NAT 变化可能导致已有连接重置，但新建连接可以正常走备用链路。应分别统计已有会话和新建连接。
主链路恢复后一定要自动切回吗？
不一定。回切取决于优先级、滞回、等待时间和厂商策略。应以当前配置和事件日志判断是否符合预期。
健康检查只使用公共 DNS 或公共 IP 可以吗？
可以作为基础连通性参考，但不能单独代表所有业务。最好增加企业可控探针、站点到站点目标和应用层检查。