Sailing - SD-WAN | 更加可靠的互联网接入方案返回首页

SD-WAN 抖动怎么测试：从链路到隧道的完整方法

更新于 2026-10-28 · sailingnet.shop

简答：SD-WAN 抖动测试不要只看一次 Ping，而应分别测试 Underlay 链路、Overlay 隧道和真实业务。最快做法是先对固定目标持续发送 ICMP，记录延迟、抖动与丢包，再对照 SD-WAN 设备的路径监控数据，最后用高峰与低峰基线确认问题范围。

定义：SD-WAN 抖动是数据包到达时间变化的程度，常以毫秒表示；不同设备可能用标准差、平滑平均偏差或厂商自定义算法计算，因此结果必须结合统计口径比较。

先试这一步：用同一目标连续测 10 到 20 分钟

如果你只想快速判断是否存在明显抖动，先在固定位置、固定目标和固定包大小下进行连续探测。不要在不同时间更换目标，否则无法判断变化来自链路还是目标本身。

  1. 选择目标：优先使用企业控制的对端网关、数据中心入口或 SD-WAN 监控目标；不要只测试公共网站，因为目标服务器、路由和 ICMP 限速都可能影响结果。
  2. 固定条件：记录测试时间、出口线路、目标地址、包大小、持续时间，以及当时是否存在视频会议、备份或大流量传输。
  3. Windows：可使用 ping -t 目标地址 持续观察，按 Ctrl+C 停止并记录最小、最大、平均延迟和丢包。
  4. Linux 或 macOS：可使用 ping 目标地址 持续采样；不同系统的参数略有差异，先运行 ping --help 或 man ping 确认包大小和次数参数。
  5. 成功标准：至少得到一组完整的延迟、丢包和时间序列数据，而不是只得到一个平均 Ping 值。若结果中出现周期性尖峰，应把尖峰时间与链路利用率、切换事件和业务流量对照。
第一轮测试记录表
项目建议记录内容为什么重要
测试路径线路名称、出口接口、是否经过隧道区分 Underlay 与 Overlay
测试目标对端网关、控制器探测目标或业务服务避免目标差异造成误判
测试时长短测 10–20 分钟，基线测试覆盖工作日高峰与低峰观察瞬时尖峰和持续性问题
指标平均值、最大值、时间序列、丢包、切换事件平均值不能代表全部体验

WatchGuard 的 SD-WAN 文档说明，其链路监控会依据指定目标的探测结果计算丢包、延迟和抖动，并建议先建立网络自身的基线；稳定网络可以观察较短时间，但更可靠的判断应覆盖更长时间窗口。查看 WatchGuard 对探测与基线的说明。

抖动、延迟、RTT 和丢包不是同一个指标

延迟通常表示一个数据包从发送到收到响应所需的时间；RTT是往返时间；丢包表示发送的数据包没有在规定时间内收到；抖动表示连续数据包到达间隔或传输时间发生变化。

实时语音和视频更容易受到抖动、丢包和延迟共同影响。RFC 3550 将 RTP 抖动定义为接收端数据包间隔变化的统计估计，并采用平滑算法计算，而 SD-WAN 产品也可能采用自己的统计窗口或标准差算法，所以不同设备显示的“Jitter”不一定可以直接横向比较。查看 RFC 3550 的抖动定义。

常见结果如何理解
现象可能含义下一步
延迟高但抖动低路径较远、路由绕行或固定排队对比其他出口和目标，不要只换 DNS
延迟平均正常但尖峰明显瞬时拥塞、队列排队、无线干扰或路径切换对照接口利用率和切换时间
抖动高且丢包同时升高链路拥塞、介质质量或运营商路径异常分别测试每条 Underlay，并保留时间序列
探测抖动低但会议卡顿探测目标与真实业务路径不同，或应用端存在处理问题查看真实业务流、TCP 重传和端到端抓包

按三层路径测试：Underlay、Overlay、真实业务

1. 测试 Underlay 物理或运营商链路

在分支出口设备或连接到该出口的测试终端上，分别对每条 WAN 线路的对端探测目标进行连续测试。测试时不要先把所有线路聚合成一个逻辑接口，否则可能看不到单条线路的抖动。

  1. 固定一条线路和一个目标，记录 10 到 20 分钟。
  2. 切换到另一条线路，使用相同目标、包大小和时段。
  3. 在工作日高峰和低峰各测试一次。
  4. 比较最大延迟、丢包发生时间、抖动变化和接口利用率。

如果某一条物理线路在不同目标上都出现相同时间的抖动，而其他线路没有，优先检查接入链路、设备端口、运营商路径和拥塞。若只有一个目标异常，则不能直接认定线路故障。

2. 测试 Overlay 隧道

Overlay 测试应确认探测包是否真正经过 VPN 或 SD-WAN 隧道。只在终端上 Ping 公网地址，可能测到的是系统默认路由，而不是企业隧道。

在支持命令行监控的设备上，应查看虚拟 SD-WAN 接口的路径监控统计、隧道状态和路径选择事件。以 Palo Alto Networks 的文档为例，show sdwan path-monitor stats vif <sdwan.x> 用于查看虚拟 SD-WAN 接口的延迟、抖动和丢包，相关统计还会按多个时间窗口显示；实际命令必须替换为设备当前使用的接口名称。查看路径监控 CLI 说明。

需要注意，某些 SD-WAN 实现测量的是 ICMP 探测包，不是实际业务包。因此探测结果只能说明监控路径质量，不能单独证明语音、视频或文件传输的真实体验。查看探测指标与真实流量的区别。

3. 验证真实业务流量

当用户反馈会议卡顿、语音断续或跨站点应用变慢时，应同时观察业务流的路径、TCP 重传、应用响应时间和实际 WAN-to-WAN 指标。部分设备可按应用流查看 WAN 延迟、丢包、抖动、RTT 和 TCP 重传；例如 ExtremeCloud SD-WAN 的实时流量页面将 WAN 流量的延迟、丢包和抖动分开显示。查看应用流实时指标说明。

多少抖动算异常：先用参考区间，再用业务基线

没有一个脱离设备、目标和业务类型的通用“正常值”。作为一组厂商文档中的参考区间，WatchGuard 将抖动低于 20ms列为较好，20–50ms列为受到影响，50–100ms列为明显受影响，超过 100ms列为基本不可用；该页面同时强调应结合本地网络和应用敏感度解释。查看该参考区间的适用说明。

实际验收时，建议把参考区间当作告警起点，而不是服务承诺。至少建立以下两组基线：

  • 低负载基线：没有大规模备份、更新或视频会议时，记录每条链路的平均值、P95或最大尖峰、丢包和切换次数。
  • 高峰基线：在工作日常见高峰重复测试，记录队列利用率、带宽占用和应用体验。
  • 业务基线：为语音、视频会议、远程桌面和文件传输分别记录可接受的延迟、丢包、重传和卡顿现象。

如果设备使用标准差，而终端脚本只计算相邻 Ping 的绝对差值，两者不要直接比较数值。应统一工具、时间窗口和统计口径，或者只比较同一设备、同一目标在不同时间的变化。

按现象定位：从抖动结果回到根因

SD-WAN 抖动故障定位速查表
观察结果优先检查验证与回退
单条 WAN 抖动和丢包同步升高接入链路、接口错误、运营商拥塞切换到备用线路；若备用线路稳定，保留两组时间序列并联系线路提供方
Underlay 正常，Overlay 异常隧道封装、MTU、加密设备负载、隧道重协商分别测试隧道两端；检查隧道事件和接口计数，必要时回到单链路验证
高峰时延迟和抖动同时上升出口队列、带宽饱和、QoS 排队降低非关键流量或启用已验证的优先级策略，再比较同一测试窗口
路径切换后指标改善原路径质量低于策略阈值查看切换事件、命中的策略和实际出口，不要只看控制器总览
探测正常但用户仍反馈卡顿业务路径、应用服务器、终端 Wi-Fi、TCP 重传按源地址、目的地址和应用流抓包或查看流量日志

Palo Alto Networks 的排障流程建议先确认受影响的链路和应用，再查看流量日志中的源地址、目的地址与出口接口；如果路径中存在多个设备，还应在不同位置抓包并对照时间戳，以缩小到具体设备或链路。查看排障步骤。

测试失败时的回退顺序建议是：先恢复原有路径或备用线路，再确认是否为单条 WAN 问题；随后分别关闭高流量任务、检查 MTU 与隧道状态，最后再调整 SD-WAN 阈值。不要为了让仪表盘变绿而直接放宽阈值，因为这可能掩盖真实的业务质量问题。

测试结果应如何保存和验收

  1. 保存原始输出，不只记录平均抖动；至少保留时间、目标、出口、包大小、延迟、丢包和异常时间点。
  2. 把 Underlay、Overlay 和真实业务测试分开命名，避免将三种路径混成一张图。
  3. 每次测试都记录线路切换、设备配置变更、业务高峰和故障开始时间。
  4. 验收时同时看抖动、丢包、延迟和用户业务结果；任何单一指标都不足以证明链路完全正常。
  5. 对比同一目标、同一时段和同一统计口径；若更换目标或设备，重新建立基线。

截至 2026-10-28，本文只采用已检索到的厂商文档和标准资料作为方法依据；不同 SD-WAN 平台的菜单、命令、采样窗口和抖动算法可能不同，执行前应以当前设备文档和实际界面为准。

常见问题

SD-WAN 抖动测试只用 Ping 可以吗？

可以用 Ping 做第一轮筛查，但不能只靠一次 Ping 下结论。Ping 主要反映探测路径的往返情况，建议进一步分别测试每条 Underlay、Overlay 隧道和真实业务流，并记录丢包、路径切换及 TCP 重传。

抖动超过多少毫秒就算异常？

可以先把 20ms、50ms 和 100ms作为参考分界，但它们不是所有网络和业务的统一标准。WatchGuard 将这些数值用于通用解释，同时建议结合本地基线、应用敏感度和统计算法判断。

为什么设备显示的抖动和 Ping 计算结果不一样？

因为设备可能使用标准差、平滑平均偏差或其他时间窗口，而简单脚本常计算相邻响应时间差。应统一目标、采样窗口和算法，优先比较同一设备在不同时间的变化。

Underlay 抖动正常，为什么视频会议仍然卡？

可能是实际会议流量没有经过你测试的路径，也可能存在隧道封装、设备队列、应用服务器、终端 Wi-Fi 或 TCP 重传问题。应按会议流的源地址、目的地址和出口接口继续核对。

测试 SD-WAN 抖动时应该测多久？

快速筛查可先测 10 到 20 分钟；要判断周期性拥塞或工作日稳定性，应在高峰与低峰重复测试并建立至少一组较长时间基线。关键是保持目标、出口和包大小一致。

相关阅读

参考资料

  1. WatchGuard：Interpret SD-WAN Data
  2. Palo Alto Networks：How to Troubleshoot SD-WAN Latency, Jitter, and Packet Loss
  3. Palo Alto Networks：SD-WAN Troubleshooting CLI
  4. RFC 3550：RTP 抖动定义与计算方法
  5. Extreme Networks：实时查看 SD-WAN 应用流