SD-WAN 网络故障排查：按现象定位链路、隧道与策略问题
简答：先不要急着重启或修改策略：记录故障时间、受影响站点和业务，先旁路或单链路建立基线，再按 Underlay、控制平面、Overlay、策略四层验证。完全中断优先查接口、网关、DNS和路由；控制器离线优先查证书、时间、组织信息与控制连接历史；延迟丢包则先隔离WAN链路并复测。
定义：SD-WAN 网络故障排查，是把故障按底层承载网络（Underlay）、控制连接、覆盖隧道（Overlay）和业务策略分层验证，并用可复现证据定位根因的过程。
先用这张表分流：不要一上来改策略
本站与任何 SD-WAN 厂商、设备厂商或控制器品牌无关联。以下步骤按跨厂商思路整理；具体命令、字段名和界面会因产品型号与软件版本不同而变化，生产环境执行命令前应先确认影响范围并保留回滚方案。
| 现象 | 先查层级 | 先做的验证 | 异常时的下一步 |
|---|---|---|---|
| 整个站点完全中断 | Underlay | 看电源、物理接口、接口状态、IP、网关和默认路由；从设备侧向网关或控制器地址发起连通性测试 | 若接口或网关不可达，先修复底层链路；若底层可达，再查控制连接和隧道状态 |
| 控制器显示离线 | 控制平面 | 核对系统时间、DNS、组织信息、证书有效期和控制连接历史 | 根据错误码区分证书、DNS、超时、注册或底层丢包问题，不要直接反复重注册 |
| 站点可达但延迟、抖动或丢包升高 | Underlay与SLA | 逐条隔离 WAN 链路，记录 ping、traceroute 和 iPerf 结果；检查探针和切换阈值 | 单链路异常时联系链路提供方或修正接口参数；多链路都异常时再查策略、拥塞和服务端路径 |
| 只有一个应用不可达 | 策略与业务层 | 确认应用识别、路由前缀、ACL、防火墙、NAT、服务链和下一跳 | 使用单一测试流量验证规则命中，避免通过扩大放行范围来“试修复” |
| 隧道反复上下线 | Overlay与控制平面 | 查看隧道、BFD或 Virtual Path 状态，并对照链路质量时间线 | 先判断是底层丢包导致探测失败，还是路由、TLOC或策略变化导致重选路 |
这类分层方法与官方排障资料的组织方式一致：控制连接和数据平面应分别核对，Underlay 问题需要结合抓包或底层链路证据判断；相关方法可参考 控制平面与数据平面故障排查文档。
第一步：确认影响范围并保存现场
- 记录时间线：写下首次异常时间、恢复时间、是否自动恢复，以及故障期间是否发生线路、设备、策略或证书变更。
- 缩小影响范围：区分单站点、单链路、单用户、单应用还是全局异常；同时记录受影响的源地址、目的地址、协议和端口。
- 保存原始证据：导出控制器事件、设备日志、接口计数器、路由表、隧道状态、BFD或链路质量统计。不要只保存截图，最好保留带时间戳的文本或诊断包。
- 先制定回滚：任何涉及路由、ACL、NAT、MTU、QoS或路径策略的变更，都应先记录当前配置和恢复命令；生产环境不要连续执行不理解影响的调试命令。
官方资料也提醒，实验环境中的命令不等于生产环境可直接执行；若网络正在承载业务，应先评估命令影响。对于支持相关工单，部分平台还提供统一诊断文件或 Admin-Tech 类信息收集方式，可先按对应厂商文档生成。
建议使用下面的记录模板：
故障时间：
受影响站点/用户/应用：
现象：完全中断 / 延迟升高 / 丢包 / 频繁切换 / 控制器离线
变更记录：
Underlay：接口、IP、网关、DNS、路由
控制平面：注册、证书、时间、控制连接历史
Overlay：隧道、BFD、Virtual Path、路由传播
策略：命中规则、ACL、NAT、QoS、服务链
已执行动作：
动作前后结果：
回滚方式：
第二步：检查 Underlay 底层链路
Underlay 指承载 SD-WAN 控制连接和隧道的基础网络，包括物理接口、运营商链路、IP 地址、网关、路由、DNS、NAT、防火墙和 MTU。只要 Underlay 不稳定，Overlay 的隧道和业务策略就可能表现为间歇性故障。
- 看接口：确认接口是否 up、是否出现错误包、丢弃、协商速率或双工异常；对照设备和交换机两端的时间戳。
- 看地址与网关：核对接口 IP、掩码、默认网关和静态路由是否与当前链路一致。Cisco 的官方示例要求设备具备用于建立控制连接的路由，并建议查看路由表。
- 看 DNS：如果控制器使用域名，确认设备实际使用的 DNS 服务器和解析结果；不要只在管理员电脑上解析成功就判定设备侧正常。
- 看 NAT 与防火墙：确认出口地址、端口映射、会话保持和安全策略没有阻断控制连接、探针或隧道流量。具体端口和协议必须以产品文档为准。
- 验证 MTU：先以不改变生产配置为前提做分段测试，比较不同包长下的成功率和是否需要分片；若要修改 MTU，应同时检查隧道封装、路径 MTU、TCP MSS和对端配置。这里的具体数值属于设备与链路相关参数，不能用一组通用值替代。
如果怀疑 WAN 链路质量，先旁路 SD-WAN 或只保留一条 WAN 链路建立基线，再恢复其他链路逐条比较。相关官方排障建议包括旁路验证、使用 iPerf 检查带宽与丢包、逐条启用 WAN 链路，并核对链路速度、类型、网段、路由、网关和 Virtual Path 状态，可参考 WAN 链路质量排查说明。
基础连通性：
ping <网关地址>
ping <控制器地址或解析后的地址>
traceroute <目标地址>
链路质量：
记录测试时间、源链路、目标地址、包长、次数、平均延迟、最大延迟、丢包率
若使用 iPerf：确认客户端与服务端版本匹配，并按设备文档选择协议、端口和测试方向
第三步：检查控制平面、证书与系统时间
控制平面负责设备注册、控制器连接、路由或策略分发。控制器离线并不一定代表业务隧道全部中断，但它通常意味着设备无法正常获得新配置或重新计算路径。
- 核对基础身份：检查系统 IP、站点 ID、组织名称、控制器地址或域名是否正确，确认设备在 Overlay 中没有重复身份。Cisco 文档将系统配置、接口配置、证书和控制连接状态列为基础排查项目。
- 核对时间：确认设备时钟、时区和 NTP 状态。时间明显不正确时，证书可能被判定为尚未生效或已过期，控制连接也可能因握手失败而反复重试。
- 核对证书链：查看设备证书是否已安装、是否在有效期内、根证书或企业 CA 链是否存在；组织名称不匹配、证书无法验证和证书过期应分别处理。
- 看控制连接状态：先看当前控制连接，再看连接历史。连接历史中的本地错误、远端错误和重复次数能帮助区分本地配置问题、控制器拒绝和 Underlay 丢包。
- 看 DNS 与 NAT：若使用控制器 FQDN，确认设备侧能解析；若设备位于 NAT 后，确认返回流量、会话保持和端口映射没有被中途改写。
以 Cisco Catalyst SD-WAN 为例，官方资料列出证书、控制连接状态和控制连接历史等检查项，并说明可通过控制连接历史中的错误代码定位握手、证书、超时和注册问题。下面命令仅适用于相应产品，不应当作通用 SD-WAN 命令：
show ip route
show run | in ip name-server
show sdwan certificate installed
show sdwan certificate root-ca-cert
show sdwan control local-properties
show sdwan control connections
show sdwan control connection-history
这些命令及其字段应以 对应产品官方文档为准。其他厂商应在自己的控制器和设备文档中寻找等价的“设备注册、证书状态、控制连接、连接历史”入口。
第四步：验证 Overlay、BFD与路径选择
Overlay 是建立在 Underlay 之上的逻辑连接。底层 ping 通，并不代表隧道、BFD、Virtual Path、TLOC 或业务路由已经正常。应把“底层可达”和“覆盖路径可用”分开验证。
- 确认隧道是否建立：查看站点对端、隧道状态、封装方式和本地出口；如果隧道没有建立，先回到控制连接和 Underlay，不要先调 QoS。
- 确认 BFD 或质量探针：记录探针目标、发送方向、时延、抖动、丢包和最近一次状态变化。探针失败可能来自真实链路问题，也可能来自 ACL、服务允许列表或探针目标不可达。
- 确认路由传播：检查目标前缀是否被学习、下一跳是否存在、是否被更具体路由覆盖，以及策略是否让路由进入了错误的 VPN、VRF 或服务链。
- 确认路径选择：对照实际流量命中的路径与策略要求，检查是否因为 SLA 阈值、链路颜色、优先级或故障切换逻辑发生了重选路。
- 做单路径隔离：在维护窗口内逐条禁用或物理隔离其他 WAN 链路，确认某一条链路单独工作时的隧道和业务结果；完成后按原顺序恢复并验证。
如果故障只在特定方向出现，应分别从两端记录测试结果；单向丢包、返回路径不一致和 NAT 状态差异，不能用一次双向 ping 代替。需要进一步确认时，可使用设备支持的抓包、嵌入式抓包或流量跟踪工具，但应设置过滤条件和时间范围，避免在生产设备上造成额外负担。
第五步：排查策略、应用和服务链
当接口、控制连接、隧道和路由都正常，而某个应用仍失败，重点转向策略与业务层。常见对象包括应用识别、ACL、防火墙、NAT、QoS、服务链、域名解析和目的端口。
- 确认是否命中预期规则：查看策略命中次数、匹配的源和目的、应用识别结果以及实际出接口；不要只看策略文本。
- 区分 IP 问题与域名问题：使用已知 IP 做对照测试，再单独检查 DNS 返回、缓存和解析路径。若 IP 可达而域名不可达，优先查 DNS 或安全策略。
- 检查 NAT 前后地址：确认转换后的地址和端口是否被对端允许，是否存在端口冲突、回程路径不一致或会话超时。
- 检查 QoS 与拥塞：比较业务队列丢弃、带宽使用和策略优先级；不要把所有业务都临时设为最高优先级，这可能掩盖根因。
- 检查服务链：确认流量是否被引向防火墙、入侵防护或其他中间服务，以及中间设备是否有对应路由、策略和回程。
修复后应使用同一源、同一目的、同一协议和相近时间窗口重新测试，并记录“变更前—变更后”结果。若只有策略改变后恢复，仍需确认底层和控制平面没有同时自动恢复，避免把时间相关的偶然恢复误判为策略修复。
抓包、日志和诊断文件怎么选
| 工具或证据 | 适合回答的问题 | 限制 |
|---|---|---|
| Ping | 目标是否基本可达，是否出现明显丢包或延迟变化 | 不能证明应用端口、隧道状态或真实业务质量正常 |
| Traceroute | 路径是否变化、是否在某一跳开始无响应 | 中间设备可能限速或不回应探测，结果不能单独证明某一跳就是根因 |
| iPerf | 在受控测试条件下比较吞吐、丢包和方向差异 | 需要匹配客户端与服务端版本，并确认测试流量不会影响生产业务 |
| 控制连接历史 | 连接失败发生在哪个控制器、何时发生、重复多少次、对应什么错误 | 字段和错误码是厂商相关，必须查对应版本文档 |
| 抓包或嵌入式抓包 | 确认报文是否发出、到达、被修改或在返回方向丢失 | 需要明确过滤条件、采集窗口和隐私保护范围 |
| 诊断文件 | 向厂商支持提交设备、日志、状态和配置摘要 | 可能包含地址、拓扑和身份信息，提交前应按组织政策脱敏 |
Cisco 的官方排障目录同时覆盖测速、抓包、统一调试条件和 Admin-Tech 文件；这说明证据采集应围绕具体问题选择工具，而不是无差别收集所有日志，可参考 Cisco Catalyst SD-WAN 故障排查指南。
恢复后的验收、回滚与升级支持
- 重复原始测试：使用故障发生时的同一业务、同一方向、相近时间段复测，并记录延迟、丢包、吞吐、隧道状态和应用结果。
- 验证备用路径：在维护窗口内确认主链路异常时是否按预期切换，恢复主链路后是否回切，以及回切是否造成短暂中断。
- 核对控制平面：确认设备注册、证书、控制连接、路由和策略版本均处于预期状态；不要只以业务恢复作为唯一结论。
- 清理临时改动：恢复临时放行、调试、旁路、静态路由、MTU、QoS或探针设置，并保存最终配置。
- 准备升级材料：整理拓扑、设备型号与软件版本、故障时间线、影响范围、变更记录、原始日志、控制连接历史、链路测试结果、抓包摘要和已执行回滚动作。
如果设备文档没有覆盖当前版本，或需要厂商专属命令，应以该厂商支持门户和对应版本手册为准。部分厂商文档按设备上线、隧道下发、应用实例、链路质量和控制器状态分别组织故障处理，可参考 H3C SeerEngine-SDWAN 故障处理手册。遵守所在地法律与服务条款。
常见问题
SD-WAN 完全断网，应该先重启设备吗？
不建议把重启作为第一步。先记录接口、网关、路由、DNS、控制连接和隧道状态；重启可能清除对定位有帮助的现场信息。只有确认设备进程或硬件状态异常，并且已有维护窗口和回滚安排时，才考虑重启。
设备能解析控制器域名，为什么控制连接仍然离线？
DNS 解析成功只说明名称解析链路基本可用，还需要检查到控制器的路由、NAT、防火墙、证书链、系统时间、组织信息和控制连接历史。解析测试应在设备侧执行，而不是只在管理员电脑上执行。
底层 ping 正常，为什么 SD-WAN 隧道仍然不通？
Ping 只能说明某个测试目标基本可达，不能证明隧道封装、控制连接、BFD、Virtual Path、路由传播或服务允许列表正常。应分别检查控制平面和 Overlay 状态，并确认探针或隧道报文是否被策略拦截。
延迟变高但没有明显丢包，如何判断是链路还是策略？
先按单链路建立基线，再逐条恢复其他链路，比较同一目标和同一测试方向的延迟、抖动与路径。若单链路也变慢，优先查运营商链路、拥塞和接口；若只有选定策略路径变慢，再检查 SLA 阈值、QoS、队列和路径选择。
什么时候需要抓包？
当状态页面只能显示“失败”而无法判断报文是否到达时，或需要区分防火墙丢弃、NAT 改写、底层丢包和握手失败时，可以在明确过滤条件和采集窗口后抓包。生产环境应控制采集范围，并避免把完整业务内容直接发送给外部人员。
多个站点同时出现控制器离线，应先查每台设备吗？
不应只逐台排查。多个站点同时异常时，先检查共同依赖：控制器可达性、DNS、证书或时间服务、共享防火墙策略、运营商公共链路和集中策略发布状态，再抽取一个站点做端到端验证。
没有独立数据时，如何判断故障是否已经彻底解决？
不要仅凭一次成功访问下结论。至少保存恢复前后的同条件测试，覆盖主路径、备用路径、关键应用、控制连接、隧道和链路质量；如果要评估稳定性，应在业务高峰与低峰分别多次记录，而不是编造统一阈值或可用性保证。
常见问题
SD-WAN 故障排查需要先看控制器还是先看线路？
完全中断或多站点同时异常时先看共同的 Underlay 与控制器可达性；单站点单链路异常时先看该站点接口、网关和线路。控制器离线则并行核对证书、时间、DNS和连接历史。
MTU 问题有哪些典型迹象？
常见迹象包括小包测试正常、大包或特定应用失败，或隧道建立但部分业务超时。应先做分段测试并对照封装开销，再决定是否调整 MTU 或 TCP MSS，具体数值以设备和链路文档为准。
BFD 状态反复变化一定是运营商线路故障吗？
不一定。还可能是探针目标、ACL、服务允许列表、设备负载、策略阈值或封装路径问题。应把 BFD 时间线与接口错误、链路质量和隧道状态对照后再判断。
为什么恢复后还要验证备用链路？
因为业务恢复只证明当前路径可用，不证明故障切换、回切和备用路径正常。恢复后应在受控窗口验证主备路径，确认切换不会触发新的路由或策略问题。
向厂商升级工单时最重要的材料是什么？
优先提供拓扑、设备型号和软件版本、影响范围、精确时间线、变更记录、控制连接历史、路由和隧道状态、分链路测试结果、抓包摘要及已执行的回滚动作。
相关阅读
- SD-WAN 如何提高网络稳定性：多链路、智能选路与验收方法
- SD-WAN 多线路融合怎么实现？带宽叠加与验收方法
- SD-WAN组网方案：拓扑、链路选择与上线验收指南
- SD-WAN 和 VPN 区别：安全、性能与选型对比