SD-WAN 断网怎么排查？
简答：SD-WAN 断网应先确认是单终端、单站点、单链路、单应用还是全网故障，再按“物理接口与本地网关 → Underlay → 控制连接 → Overlay 隧道 → 路由与策略”顺序检查。先做最短验证：确认设备和 WAN 接口在线，测试默认网关、DNS 与控制器地址；若接口正常但隧道或控制连接异常，再检查系统时间、证书、组织标识、NAT、防火墙和路由。
定义：SD-WAN 断网排查，是把业务不可达问题拆分为终端/LAN、物理链路、Underlay、控制平面、Overlay 数据平面和业务策略六个层级，并用可复现的测试结果确定故障边界。
先用 3 分钟判断：到底是哪一层断了
不要一上来重启整套设备。先记录故障开始时间、受影响的站点、用户、应用和链路，随后用下面的对照表确定最短排查路径。厂商界面和命令名称会因平台、软件版本而不同，表中的设备命令只适用于对应厂商环境，不能直接当作所有 SD-WAN 产品的通用命令。
| 现象 | 优先检查 | 成功标准 | 失败时的下一步 |
|---|---|---|---|
| 整个站点都无法访问 | 设备电源、LAN/WAN 接口、默认网关、ISP 链路 | 接口为管理启用且链路已连接，终端可到达本地网关 | 检查线缆、光模块、端口协商、上联设备和运营商状态 |
| 只有一个站点无法访问总部或云资源 | Underlay 可达性、控制连接、Overlay 隧道 | 设备可解析并访问控制器，隧道和对端路由已建立 | 检查 DNS、NAT、防火墙、证书、系统时间和控制器路由 |
| 只有一个应用或网段不可用 | 路由发布、应用识别、业务策略、访问控制 | 目标前缀存在，策略允许，转发路径与预期一致 | 核对策略优先级、匹配条件、下一跳、BGP 或静态路由 |
| 连接频繁中断或自动切换 | 丢包、时延、抖动、接口错误和链路质量阈值 | 连续观测期间链路质量稳定，切换原因可解释 | 分开测试每条 WAN 链路，检查线路、MTU、双工和设备日志 |
| 切换到备用链路后仍然断网 | 备用链路本身、NAT、控制连接和策略 | 备用接口能到达网关、DNS、控制器及业务目标 | 确认备用链路不是仅“接口 Up”，并核对路由和防火墙放行 |
设备侧排查通常要同时观察接口、路由、控制平面和数据平面。Cisco 的排障资料也将控制连接、Underlay、数据平面和抓包分开处理；Palo Alto Networks 的事件文档则建议先按事件类型执行设备、接口、网关、路由或策略检查。可参考 Cisco 控制平面与数据平面排查文档 和 Palo Alto Networks 事件排查文档。
按层排查：从本地连接到 SD-WAN 隧道
1. 先确认影响范围并冻结变更
- 记录站点名称、设备名称、受影响网段、应用、用户数量和故障开始时间。
- 暂停与故障无关的配置变更，保留最近一次成功配置或变更记录。
- 确认是全站点、单条线路、单个方向，还是只有特定应用不可用。
成功标准：你能用一句话描述影响范围，例如“分支 LAN 正常，但访问总部网段失败”，而不是笼统地写“SD-WAN 断网”。
2. 检查设备、电源和物理接口
- 确认设备电源、状态灯、管理面和串口或 SSH 访问是否正常。
- 检查 LAN、WAN 接口是否管理启用、链路已连接、速率和双工符合预期。
- 查看接口错误、丢帧、CRC、输入输出丢弃、频繁 Up/Down 和光模块告警。
- 若存在接口错误，依次更换线缆、光模块、配线架端口或设备端口，并记录每次变化。
Palo Alto Networks 的官方排查文档将接口 Down、线缆、SFP、端口和半双工列为独立检查项；因此“接口显示 Up”并不等于链路质量正常。可参考 接口状态与硬件事件排查步骤。
3. 验证 LAN、默认网关和 Underlay
- 从终端测试默认网关，确认终端到本地网关之间没有 VLAN、DHCP、ARP 或交换机问题。
- 从 SD-WAN 设备测试运营商网关、公共 DNS 或已知控制器地址；测试时要指定正确的 WAN 接口或源地址。
- 分别记录 Ping 的时延、丢包和变化趋势，不要只看一次成功或失败。
- 检查 DNS 是否能解析控制器或业务域名；若使用 FQDN，确认设备配置了可用 DNS 服务器。
Windows 可使用 ipconfig /all 查看地址、网关和 DNS，使用 ping <网关地址>、nslookup <域名> 和 tracert <目标地址>；macOS 可使用 ifconfig、route -n get default、ping、dig 和 traceroute。这些命令只能说明终端或操作系统看到的路径，不能替代设备侧的链路和隧道状态。
4. 检查控制平面连接
如果 Underlay 能访问网关和外部目标，但设备无法建立控制连接，应重点检查：
- 系统时间是否准确，并与控制器时间保持一致。
- System-IP、Site-ID、组织名称、控制器或引导节点地址是否填写正确且在站点间保持唯一。
- 设备证书、根证书、证书有效期和设备授权状态是否正常。
- 控制器地址是否能通过 DNS 解析，路由表是否存在到控制器的可用路径。
- 防火墙、NAT、端口过滤或运营商策略是否丢弃控制连接。
Cisco 官方文档明确把证书、System-IP、Site-ID、组织名称、引导节点地址、VPN 0 传输接口和系统时钟列为控制连接前置检查项，并建议查看本地 TLOC 属性；具体命令可参阅 Cisco SD-WAN 控制连接排查文档。在 Cisco IOS XE SD-WAN 环境中，部分命令需要使用 sdwan 关键字；其他厂商请使用本厂商等价状态页或命令。
5. 检查 Overlay 隧道、BFD、TLOC 和路由
- 确认目标站点的 Overlay 隧道是否建立，且不是只有控制连接在线。
- 检查 BFD 或等价链路探测状态，区分“隧道不存在”和“隧道存在但质量不达标”。
- 检查目标网段是否被正确学习、发布和安装到转发表。
- 核对路径选择策略是否将流量导向不可用链路，或因为质量阈值触发了持续切换。
- 对单向故障分别测试双向路径；能从分支到总部不代表总部到分支也正常。
判断重点：控制连接正常，只能说明设备与控制系统之间的管理关系可用，不等于业务 Overlay 一定可用。若控制平面在线而业务不通，应把重点转向隧道、BFD、路由、NAT 和业务策略。
6. 检查策略、应用识别和变更回滚
- 核对最近是否修改了流量策略、访问控制、应用识别、路由发布或链路质量阈值。
- 确认策略匹配的是正确的源网段、目标网段、应用、端口和方向。
- 检查是否存在更高优先级规则、策略冲突、默认丢弃或错误的服务链转发。
- 如果有明确的最近变更，先保存当前配置和日志，再按变更流程回滚，不要直接覆盖现场证据。
若只剩单个应用或单个网段不可用，优先检查策略和路由，而不是重复重启 WAN 设备。Palo Alto Networks 的事件处理页面也将应用自定义规则冲突、接口、网关、BGP 和策略事件分别列出，适合用来建立责任边界。
可复制的检查命令与证据留存清单
命令必须绑定平台和版本。下面的终端命令适合 Windows 或 macOS 的基础验证；设备命令示例以 Cisco SD-WAN 为例，使用前应确认设备型号、软件版本和生产影响。Cisco 官方资料提醒，实时网络中执行命令前应了解其影响；抓包、调试和追踪类操作尤其需要审批。
| 检查对象 | Windows/macOS 终端 | 设备侧或厂商等价检查 | 记录什么 |
|---|---|---|---|
| 地址与网关 | ipconfig /all；macOS 使用 ifconfig 与 route -n get default | 接口地址、VLAN、DHCP、ARP | 地址、掩码、网关、DNS、接口名称 |
| DNS | nslookup <域名>；macOS 可用 dig <域名> | 设备配置的 DNS 和解析结果 | 解析服务器、返回地址、失败时间 |
| 基础可达性 | ping <网关>、ping <目标> | 按 WAN 源地址或接口测试 | 连续测试时长、丢包、最小/最大/平均时延 |
| 路径 | Windows 使用 tracert <目标>；macOS 使用 traceroute <目标> | 路由表、下一跳、策略路由 | 首次异常跳点、方向和测试源 |
| 控制连接 | 不建议仅用终端 Ping 判断 | Cisco 示例：show sdwan control connections、show sdwan control local-properties | 控制器、状态、错误码、最后变化时间 |
| 路由与隧道 | 通过业务目标进行双向测试 | 厂商等价的隧道、BFD、TLOC、路由和转发表状态 | 对端、隧道状态、路径、路由前缀 |
| 接口错误 | 终端网卡状态和协商信息 | 接口计数器、CRC、丢弃、双工和光模块信息 | 计数器起始值、结束值和变化速率 |
建议建立一条时间线：故障开始 → 第一次告警 → 接口状态变化 → 控制连接变化 → 隧道变化 → 测试结果 → 配置变更 → 恢复时间。不要把账号密码、私钥、完整配置中的敏感字段或客户数据直接贴到工单；导出日志前先脱敏。
若需要抓包或调试，先确认抓包点、过滤条件、持续时间、磁盘空间和业务影响。Cisco 官方排障资料列出了 TCP Dump、嵌入式抓包、FIA Trace 和技术支持数据收集等方法，但这些工具并非所有平台通用，不能把 Cisco 命令直接用于其他设备。
恢复动作、失败回退与升级条件
优先使用低风险恢复动作
- 若只有主链路故障，确认备用链路状态后再执行受控切换，并观察业务是否恢复。
- 若接口被人为关闭，核对变更记录后恢复接口；不要对未知原因的端口反复执行启停。
- 若是明确的错误配置，保存现状和日志，再按已验证的上一版配置回滚。
- 若控制连接因 DNS、时间、证书或组织标识失败，修正单一原因后等待状态收敛，并重新验证业务，不要同时修改多个变量。
- 若设备资源、磁盘、内存或硬件告警异常，先保留事件信息，再按照厂商支持流程处理。
什么时候联系运营商、厂商或网络服务商
- 本地接口、设备和配置正常，但运营商网关或上游路径持续丢包、不可达或频繁抖动。
- 多条站点链路同时异常，且故障时间与上游维护、线路变更或区域事件一致。
- 控制连接持续失败，已核对时间、证书、组织标识、DNS、路由、NAT 和防火墙仍无法恢复。
- 隧道在线但业务持续被丢弃，且已保存策略命中、路由、BFD、抓包和事件日志。
- 设备出现硬件、磁盘、内存、温度或持续重启告警。
提交工单时至少附上：站点和拓扑、故障时间线、影响范围、最近变更、接口状态、Underlay 测试、控制连接状态、隧道与路由状态、策略命中结果、相关日志和脱敏抓包。这样可以减少“请先重启设备”式的重复确认。
常见问题 FAQ
SD-WAN 设备接口是 Up，但为什么仍然断网？
接口 Up 只说明链路层或端口状态满足条件，仍可能存在网关不可达、DNS 失败、上游丢包、NAT 或防火墙过滤、控制连接失败、Overlay 隧道未建立、路由缺失或策略丢弃。应继续按 Underlay、控制平面、Overlay 和策略顺序验证。
控制连接在线，是否代表业务一定正常？
不代表。控制连接解决的是设备与控制系统之间的管理关系；业务还需要 Overlay 隧道、BFD 或等价质量探测、路由、转发表和策略都正常。控制连接在线但业务不通时，应优先查看对端路由、隧道状态、策略和实际转发路径。
应该先重启 SD-WAN 设备吗？
通常不应把重启作为第一步。重启可能暂时改变现象，也可能丢失接口计数器、事件时间线和现场证据。先记录状态并完成网关、DNS、接口、控制连接、隧道和路由检查；只有在厂商流程或明确的恢复方案要求下，才执行受控重启。
怎么判断是线路问题还是 SD-WAN 配置问题？
分别从每条 WAN 链路指定源接口测试运营商网关、DNS 和控制器地址。若某条链路本地就出现持续丢包、错误或不可达，而其他链路正常，线路或上游问题的可能性更高；若 Underlay 正常但控制连接、隧道、路由或策略异常，则应优先检查 SD-WAN 配置和控制系统。最终结论需要结合设备日志和运营商侧证据。
不同厂商的 SD-WAN 排查命令能通用吗？
不能直接通用。可以通用的是排查层次和证据类型：接口、网关、DNS、Underlay、控制连接、隧道、路由、策略和日志；具体菜单、命令、错误码和抓包方法必须以设备型号、软件版本和厂商文档为准。
常见问题
SD-WAN 设备接口是 Up，但为什么仍然断网？
接口 Up 不等于网关、DNS、控制连接、Overlay、路由和策略都正常。应继续按 Underlay、控制平面、Overlay 和策略顺序检查。
控制连接在线，是否代表业务一定正常？
不代表。控制连接在线只说明管理关系可用，业务还需要隧道、质量探测、路由、转发表和策略正常。
应该先重启 SD-WAN 设备吗？
通常不应先重启。先保存现场状态、日志、接口计数器、控制连接和路由证据，确认恢复方案后再执行受控重启。
怎么判断是线路问题还是 SD-WAN 配置问题？
分别从每条 WAN 链路测试运营商网关、DNS 和控制器地址。Underlay 本身持续丢包或不可达时偏向线路问题；Underlay 正常而隧道、路由或策略异常时，应优先检查 SD-WAN 配置。
不同厂商的 SD-WAN 命令能通用吗？
不能直接通用。排查层次可以复用，但命令、菜单、错误码和抓包方法必须按设备型号与软件版本核实。