Cisco Catalyst SD-WAN中的AppQoE TCP优化和DRE故障排除
目录
简介
本文档介绍如何对Cisco Catalyst SD-WAN中的AppQoE TCP优化和DRE进行故障排除。
背景信息
当启用AppQoE的TCP流未优化、被绕过、在转移后重置、报告不正常的服务节点或显示比预期更少的数据冗余消除(DRE)减少时，请使用此指南。
从10分钟的分类开始。它将策略和路径问题与服务节点运行状况、流状态、容量、TCP传输和DRE有效性问题区分开来。只有在您知道流量停止按预期运行后，才继续症状部分。
目的、范围和安全性
本指南涵盖使用TCP优化或DRE与集成或外部AppQoE服务节点的Cisco IOS® XE Catalyst SD-WAN设备。
| 验证项目 | 状态 |
|---|---|
| 公共行为和操作CLI |
与当前的Cisco Catalyst SD-WAN AppQoE 26.x文档保持一致 |
| 内部计数器语义 |
已根据2026-07-15上的当前Cisco IOS XE源重新检查 |
| 用于发布的确切版本、平台和拓扑 |
实验捕获：C8000v上的Cisco IOS XE Catalyst SD-WAN 17.18.2，外部服务节点AppQoE。AppNav控制器c8000v-appqoe-3，服务节点c8000v-appqoe-4，外部SN appqoe-service-node(SN IP 15.15.15.2)。SNG SNG-APPQOE，VPN 10上的数据策略_vpn-10_appqoe-policy(TCP + DRE)。捕获2026-07-15。 |
命令可用性和输出因软件版本、平台和角色而异。在目标设备上使用命令帮助确认语法。本指南中的低级QFP命令是只读的，但它们特定于平台和版本；仅当存在命令时才使用它们。
主要发布检查点如下所示；它们不会取代平台特定的支持和扩展文档。
| 功能 | 最低版本检查点 |
|---|---|
| DRE和自动服务控制器/服务节点MTU处理 |
思科IOS XE Catalyst SD-WAN 17.5.1a |
| 增强的AppQoE故障排除和子服务运行状况 |
17.6.1安 |
| 扩展的flow-detail故障排除 |
17.9.1安 |
| 使用TLS 1.3的SSL代理 |
17.13.1a/Manager 20.13.1 |
| 通过配置组执行DRE |
17.14.1a/Manager 20.14.1 |
DRE需要两端受支持的服务节点和对称流量处理。它不在仅服务控制器的设备上运行，并且AppQoE不能与同一连接上的数据包复制结合使用。如果要优化其负载，则加密流量需要支持的SSL/TLS处理。
更改策略、清除统计信息、重新启动服务或启用调试之前，请捕获：
- 软件版本、平台以及两端的AppQoE角色
- 源和目标IP地址、端口、协议、VPN和UTC测试时间
- 预期的策略序列和服务节点分配
- 症状是否影响一个流、一个站点对或所有AppQoE流量
- 两个计数器快照在同一测试间隔内
注意：在初始故障排除期间不要清除DRE缓存。清除该信息会重新启动DRE并销毁热缓存，这将更改要测量的条件。
从这里开始:10分钟分类
1.验证AppQoE状态和最近出现的错误
在参与的边缘设备或服务控制器上运行：
show sdwan appqoe status show sdwan appqoe error recent
实验示例：
c8000v-appqoe-4（服务节点，C8000v，IOS XE 17.18.2）。
c8000v-appqoe-4#show sdwan appqoe status APPQOE Status : YELLOW Service Status: SSLPROXY : YELLOW TCPPROXY : GREEN SERVICE CHAIN : GREEN RESOURCE MANAGER : GREEN c8000v-appqoe-4#show sdwan appqoe error recent Appqoe Statistics Recent ------------------------ Label Current value Value(30 sec bfr) Value(60 sec bfr) RM TCP used sessions 0 0 0 RM TCP session allocated 21516 21516 21516 TCP number of connections 21215 21215 21215 TCP failed connections 298 298 298 vPath drop due to pps 0 0 0 vPath new connection failed 0 0 0 BBR Active connections 1 1 1 Syn Drop Max PPS Reached 0 0 0 ... (output truncated)
此处总体状态为黄色，仅因为SSL AO未使用（SSL代理处于清除模式）；TCP、服务链和资源管理器子服务为绿色。没有PP丢弃或新连接故障。
查找启用的服务、当前服务节点状态、最近的流错误以及直接解释旁路或丢弃行为的任何原因。
2.双向验证策略和服务节点分配
show sdwan policy from-vsmart show service-insertion type appqoe service-node-group
实验示例：
c8000v-appqoe-3（AppNav控制器），2026-07-15。
c8000v-appqoe-3#show sdwan policy from-vsmart
from-vsmart data-policy _vpn-10_appqoe-policy
direction all
vpn-list vpn-10
sequence 1
match
source-ip 31.31.31.0/24 41.41.41.0/24
action accept
tcp-optimization
dre-optimization
service-node-group SNG-APPQOE
default-action accept
from-vsmart lists vpn-list vpn-10
vpn 10
c8000v-appqoe-3#show service-insertion type appqoe service-node-group
Service Node Group name : SNG-APPQOE
Service Context : appqoe/1
Member Service Node count : 1
Service Node (SN) : 15.15.15.2
Auto discovered : No
SN belongs to SNG : SNG-APPQOE
Current status of SN : Alive
System IP : 10.20.0.1
Site ID : 30
Time current status was reached : Fri Jun 12 07:45:14 2026
Cluster protocol VPATH version : 2 (Bitmap recvd: 3)
Cluster protocol incarnation number : 3
Health Markers:
AO Load State
tcp GREEN 0%
ssl RED/NOT AVAILABLE
dre GREEN 0%
http RED/NOT AVAILABLE
utd chnl RED/NOT AVAILABLE
操作接受同时携带tcp-optimization和dre-optimization，指向SNG-APPQOE，并且SN使用tcp/dre GREEN处于活动状态。ssl/http/utd显示RED/NOT AVAILABLE，因为这些AO未配置 — 对于仅TCP+DRE测试是预期的。
确认目标序列与测试流的两个方向都匹配，包括预期的TCP/DRE操作，并指向预期的服务节点组。DRE需要两端和对称流处理。
3.检查一个已知流并进行端到端跟踪
show sdwan appqoe flow vpn-id <vpn-id> server-port <port> show sdwan appqoe flow flow-id <flow-id> show sdwan appqoe flow closed all
跟踪单个流
首先，在边缘和DC路由器上运行show sdwan appqoe flow vpn-id <vpn-id> server-ip <server-ip> server-port <port>。此命令返回流ID。获得流ID后，在两台路由器上运行show sdwan appqoe flow-id <flow-id>。
show sdwan appqoe flow vpn-id <vpn-id> server-ip <server-ip> server-port <port> show sdwan appqoe flow flow-id <flow-id>
实验示例：
c8000v-appqoe-4（服务节点），2026-07-15。捕获时没有流处于活动状态，因此显示历史（关闭）表。
c8000v-appqoe-4#show sdwan appqoe flow all Active Flows: 0 T:TCP, S:SSL, U:UTD, D:DRE, H:HTTP Flow ID VPN Source IP:Port Destination IP:Port Service No Matching Flows c8000v-appqoe-4#show sdwan appqoe flow closed all Current Historical Optimized Flows: 100 Optimized Flows --------------- T:TCP, S:SSL, U:UTD, D:DRE, H:HTTP RR: DRE Reduction Ratio Flow ID VPN Source IP:Port Destination IP:Port Service RR% 91989394759551 10 41.41.41.2:50748 185.125.190.99:80 T - 91990285862945 10 41.41.41.2:36804 185.125.190.100:80 T - 91996708679695 10 41.41.41.2:54614 91.189.91.97:80 T - 92002614507991 10 41.41.41.2:57534 91.189.91.97:80 T - 92101839402141 10 41.41.41.2:36856 185.125.188.54:443 T - ... (95 more rows truncated) ++++ Tracing single flow end to end, run below command on both edge and DC routers +++++++ ========================================================================================== c8000v-appqoe-4#show sdwan appqoe flow vpn-id 10 server-ip 41.41.41.2 server-port 21 T:TCP, S:SSL, U:UTD, D:DRE, H:HTTP Flow ID VPN Source IP:Port Destination IP:Port Service 93741048628578 10 31.31.31.2:37632 41.41.41.2:21 TD c8000v-appqoe-4#show sdwan appqoe flow flow-id 93741048628578 Flow ID: 93741048628578 VPN: 10 APP: 0 [Client 31.31.31.2:37632 - Server 41.41.41.2:21] HTTP Connect: 0 TCP stats --------- Client Bytes Received : 213 Client Bytes Sent : 363 Server Bytes Received : 176 Server Bytes Sent : 36 Client Bytes sent to SSL: 165 Server Bytes sent to SSL: 176 ... (195 more rows truncated) TCP Flow Events 1. time:303.932637 :: Event:TCPPROXY_EVT_FLOW_CREATED 2. time:303.932696 :: Event:TCPPROXY_EVT_AD_RX_SYN_WITH_OPTIONS 3. time:303.932741 :: Event:TCPPROXY_EVT_SYNCACHE_ADDED 4. time:303.932759 :: Event:TCPPROXY_EVT_AD_TX_CORE_SYNACK 5. time:303.933496 :: Event:TCPPROXY_EVT_AD_RX_CORE_ACK_WITH_OPTIONS 6. time:303.933594 :: Event:TCPPROXY_EVT_ACCEPT_DONE 7. time:303.933650 :: Event:TCPPROXY_EVT_AD_TX_CORE_SYN_NO_OPTIONS 8. time:303.933657 :: Event:TCPPROXY_EVT_CONNECT_START 9. time:303.933993 :: Event:TCPPROXY_EVT_AD_RX_CORE_SYNACK 10. time:303.934022 :: Event:TCPPROXY_EVT_AD_TX_CORE_ACK_NO_OPTIONS 11. time:303.934024 :: Event:TCPPROXY_EVT_CONNECT_DONE 12. time:303.934049 :: Event:TCPPROXY_EVT_FLOW_CREATE_DRE_SENT 13. time:303.934198 :: Event:TCPPROXY_EVT_FLOW_CREATE_DRE_RSP_SUCCESS 14. time:303.934222 :: Event:TCPPROXY_EVT_FLOW_CREATE_SSL_DONE 15. time:303.934232 :: Event:TCPPROXY_EVT_DATA_ENABLED_SUCCESS ... (95 more rows truncated)
Service = T表示这些流量是TCP优化的；RR%为空，因为每个DRE优化流都会报告DRE减少率（请参阅DRE部分）。 对实时流使用flow flow flow-id <id>，以便直接读取其记录的“优化/旁路”状态。以上跟踪的流显示服务= TD(TCP + DRE)和完整的代理事件序列 — SYN选项交换、接受/连接、DRE流创建成功和启用数据 — 确认完整的端到端优化。
将流分类为已优化、已绕过/已直通或已失败。首选流或传递原因的记录状态而不是来自一个聚合计数器的推断。
4.检验服务节点资源和DRE
运行适用于设备角色的命令：
show sdwan appqoe rm-resources show sdwan appqoe dreopt status detail show sdwan appqoe dreopt statistics detail show sdwan appqoe dreopt statistics peer
实验示例：
c8000v-appqoe-4（服务节点），2026-07-15。长DRE输出调整为运行状况/容量字段。
c8000v-appqoe-4#show sdwan appqoe rm-resources
==========================================================
RM Resources
==========================================================
RM Global Resources :
System Memory Status : GREEN
Num sessions Status : GREEN
Overall HTX health Status : GREEN
Registered Service Resources :
TCP Resources: Max Sessions : 40000 Used Sessions : 0
SSL Resources: Max Sessions : 40000 Used Sessions : 0
DRE Resources: Max Sessions : 750 Used Sessions : 0
c8000v-appqoe-4#show sdwan appqoe dreopt status detail
DRE ID : 52:54:dd:77:4a:a7-019cdaae7bca-9a025f66
DRE uptime : 126:13:46:58
Health status : GREEN
DRE cache status : Active
Disk cache usage : 29%
Disk latency : 2 ms
Active alarms: None
Configuration:
Profile type : S
Maximum connections : 750
Disk size : 60 GB
Compression type : DRE-LZ
c8000v-appqoe-4#show sdwan appqoe dreopt statistics detail
Total connections : 48
Max concurrent connections : 2
Current active connections : 0
Total original bytes : 63254 MB
Total optimized bytes : 32691 MB
Overall reduction ratio : 48%
Disk size used : 29%
Cache details:
Cache status : Active Cache Size : 59132 MB Cache used : 29%
... (per-connection reset/EBP/encode/decode detail truncated)
c8000v-appqoe-4#show sdwan appqoe dreopt statistics peer
Peer No. System IP Hostname Active connections Cummulative connections
----------------------------------------------------------------------------------------
0 10.30.0.1 c8000v-app 0 22
1 10.20.0.1 appqoe-ser 0 26
运行状况为绿色，无警报，磁盘延迟2毫秒，总体缩减率正常48%。对等体表确认两个DRE对等体均可访问且版本兼容（请参阅aoim-statistics）。
检查运行状况、最大和活动连接、对等体兼容性、缓存状态、磁盘延迟或警报以及原始与优化字节增量。
5.捕获服务控制器(SC)和服务节点(SN)之间的流量
在SC和SN之间的隧道接口上捕获监控器。它提供清晰的非封装数据。
方法 1：CLI（嵌入式数据包捕获 — EPC）
您可以直接在设备CLI上使用Cisco IOS XE嵌入式数据包捕获(EPC)功能。以下是使用Tunnel2000000001的分步配置，例如：
monitor capture APPQOE_CAP interface Tunnel2000000001 both monitor capture APPQOE_CAP match <ipv4 or any or access-list> monitor capture APPQOE_CAP start show monitor capture APPQOE_CAP monitor capture APPQOE_CAP stop monitor capture APPQOE_CAP export bootflash:appqoe_clear_data.pcap
方法 2：GUI（思科SD-WAN管理器）
或者，您可以直接从Cisco SD-WAN Manager（以前称为vManage）GUI执行此捕获，GUI将自动输出.pcap文件供您下载：
- 导航到Monitor > Devices。
- 选择您的设备(c8000v-appqoe-4)。
- 单击左侧窗格中的Troubleshooting。
- 在流量部分下，选择数据包捕获。
- 在接口选择下拉列表中，选择AppQoE隧道接口（例如Tunnel200000001）。
- （可选）应用任何源/目标IP或端口过滤器。
- 单击Start开始捕获，然后单击Stop。系统将准备.pcap文件以供下载。
6.选择下一节
| 第一个异常结果 |
继续 |
|---|---|
| 策略在两个方向上都不匹配 |
没有优化或转移 |
| 没有分配正常或符合条件的服务节点 |
服务节点运行状况和分配 |
| 流已绕过或具有直通原因 |
分流故障和旁路 |
| 现有流重置或数据包丢弃 |
在转移后丢弃 |
| 在突发期间，只有新连接会失败 |
SYN监察器和连接速率 |
| CFT/FID故障增加 |
CFT和容量 |
| 存在TCP停滞和PMTU/MSS证据 |
MTU和MSS |
| 流量优化，但缩减幅度较弱 |
DRE有效性 |
TCP优化和DRE如何处理流量
使用双端TCP优化和DRE时，原始连接由三个TCP连接表示：
Client <-- LAN leg --> Edge A proxy/SN <== overlay leg + DRE ==> Edge B proxy/SN <-- LAN leg --> Server
DRE压缩重叠支路上的重复数据。远端设备在将原始流转发到目的地之前重新构建原始流。外部服务节点拓扑添加服务控制器到服务节点重定向，但保留相同的检查点：策略、路径对称、服务节点资格、流转移、对等兼容性和DRE状态。
| 期限 | 本指南中的含义 |
|---|---|
| 优化 |
所选的AppQoE服务对于流处于活动状态。 |
| 旁路或直通 |
流量在没有选定AppQoE服务的情况下继续；检查直通原因。 |
| 丢弃 |
数据包不会继续；这会影响用户，并且需要丢弃/错误关联。 |
| Fail-close flow state |
在流量经过检测/分流后，一些后来的分流故障无法安全回退到普通旁路。 |
| SC |
服务控制器 |
| SN/ISN/ESN |
服务节点/集成服务节点/外部服务节点 |
| CFT |
用于跟踪流及其功能状态的连接流表 |
无优化或转移
确认
- 确认策略匹配和双向操作。
- 通过预期的一对AppQoE设备确认对称路由。
- 确认服务节点组和站点ID正确。
- 确认两端的DRE已部署且运行正常。
- 检查目标流的状态或直通原因。
解释
- 没有策略匹配通常意味着分类、方向、VPN或连接错误。
- 单侧匹配可以在一个边缘上启用TCP/DRE处理，但无法提供有效的两端DRE路径。
- 当流量已优化、流量类型不受支持、非对称或匹配自动旁路条件时，流量可以正确旁路。
正确并验证
更正策略、方向、节点组、站点ID或路由问题。然后创建新的TCP连接并检验两端的流量。请勿使用现有连接来验证策略更改。
分流故障和旁路
仅在受支持的AppQoE flow和错误命令缩小问题范围之后才使用内部QFP统计信息：
show platform hardware qfp active feature appqoe stats global show platform hardware qfp active feature appqoe stats all show platform hardware qfp active feature appqoe internal all
比较两个快照；这些计数器是累积的。
实验示例：
c8000v-appqoe-3（AppNav控制器），2026-07-15。正常转移：sn索引为绿色，并且没有下降原因计数器正在爬升到之前记录的SN不正常瞬变预期值之外。
c8000v-appqoe-3#show platform hardware qfp active feature appqoe stats all
APPQOE Feature Statistics:
Global:
ip-non-tcp-pkts: 1354682
cft_handle_pkt: 0
sdvt_divert_req_fail: 1374
appqoe_svc_on_appqoe_vpn_drop: 0
appqoe_sng_not_configured: 0
SDVT Global stats:
within SDVT syn policer limit: 71660
SNG: 0 SN Index [0 (Green)], IP: 15.15.15.2, oce_id: 221252816
APPNAV STATS: toSN 85540403 / 75619122643 fromSN 105667460 / 109985814214
NoFoDrop 0 / 0
SDVT Count stats:
Active Connections: 4
decaps: 58388600 encaps: 47119306
SDVT Packet stats:
Divert packets / bytes 47119306 / 34139250226
Reinject packets / bytes 58388600 / 52530512355
Pkts dropped packets / bytes 10 / 690
SDVT Drop Cause stats:
Packets Dropped as SN Unhealthy: 10
c8000v-appqoe-3#show platform hardware qfp active feature appqoe internal all
APPQOE Feature Internal:
syn_policer_rate: 2700
Cluster Type: External
Service chnl health : Green
TCP sub-chnl health : Green
SSL sub-chnl health : Red
DREOPT sub-chnl health : Green
Service-Node-Group: 0
Active SN Bitmask: 0x0000000000000001
SN Table:
Idx | Id | Ver | Status | DP Status | msecs ago | IP
0 | 1 | 2 | Green | Green | 27707 | 15.15.15.2
cft_handle_pkt:0和appqoe_svc_on_appqoe_vpn_drop:0排除CFT/FID故障和递归VPN丢弃。丢弃为SN不正常的数据包：10是一个小历史计数 — 在将SN运行状况转换视为主动影响之前将其关联起来。
转移后丢弃
确认
show sdwan appqoe error recent show sdwan appqoe flow closed all show sdwan appqoe status show service-insertion type appqoe service-node-group
如果版本和平台上存在统计信息，请比较统计信息global或stats all before and after one controlled replication。
实验示例：
健康基线，c8000v-appqoe-3（控制器），2026-07-15。没有出现故障关闭下降；sn处于活动状态/绿色状态，最近出现的错误显示由于PP导致的vPath丢弃：0和vPath新连接失败：0.数据路径丢弃原因快照是决定性证据：
c8000v-appqoe-3#show platform hardware qfp active feature appqoe stats all | include Drop|Unhealthy|NoFoDrop
SDVT Drop Cause stats:
Packets Dropped as SN Unhealthy: 10
NoFoDrop 0 / 0
在将重置标记为失效关闭之前，请根据这些增量关联确切的复制时间。
解释
当服务节点不可用或以后AppNav重定向失败时，先前检查/转移的流可能会丢失。这保护已建立的代理状态；代理路径消失后，无法始终以透明方式重建原始客户端到服务器的连接。当普通旁路违反链处理时，服务链流也会下降。
不要将每次重置都标记为失败关闭。将确切的测试时间与流错误、服务节点运行状况过渡和计数器增量相关联。
正确并验证
恢复符合条件的稳定服务节点并更正路径或服务链故障。使用新的TCP连接进行验证，然后确认相关的丢弃计数器停止增加。
服务节点运行状况和分配
运行状况特定于角色和服务。特定应用优化程序(AO)的活性、资源容量和运行状况是相关的，但不可互换。
| 状态 |
预期的数据路径行为 |
|---|---|
| 绿色 |
符合新流量和现有流量的条件 |
| 黄色 |
现有已检查的非SYN流量可以继续；新的SYN不会转移到该节点。FULL节点是一个可能的黄色情况 |
| 红色或向下 |
新的/未提交的流通常在允许时绕过；已检查/失败关闭的流可能会丢失；服务链流可能会下降 |
运行：
show service-insertion type appqoe service-node-group show sdwan appqoe status show sdwan appqoe rm-resources show sdwan appqoe dreopt status detail
检查节点成员资格、站点ID、活动、AO运行状况、负载/容量、DRE警报和对等体可接通性。在Cisco IOS XE Catalyst SD-WAN版本17.6.1a之前，可以限制子服务运行状况详细信息；相应地解释旧版输出。
实验示例：
正常节点，2026-07-15。在控制器上，SN使用每个AO运行状况标记处于活动状态；在节点上，资源管理器报告带净空的绿色：
c8000v-appqoe-3#show service-insertion type appqoe service-node-group | begin Health
Health Markers:
AO Load State
tcp GREEN 0%
ssl RED/NOT AVAILABLE
dre GREEN 0%
c8000v-appqoe-4#show sdwan appqoe rm-resources | include Status|Max Sessions|Used Sessions
System Memory Status : GREEN
Num sessions Status : GREEN
Overall HTX health Status : GREEN
TCP Resources: Max Sessions : 40000 Used Sessions : 0
DRE Resources: Max Sessions : 750 Used Sessions : 0
负载为0%，并且已使用的会话远远低于40000/750限制，因此由于容量原因，此节点既不满也不黄色。show sdwan appqoe status中显示的黄色总体状态仅跟踪未使用的SSL AO。
当节点已满或黄色（因为它接近其配置的会话容量）时，分配新连接，在平台允许的情况下增加支持的AppQoE资源配置文件，或添加容量。请勿假设添加路由器DRAM会改变支持的硬件流规模。
CFT和容量
appqoe_cft_handle_pkt是错误计数器。当AppQoE无法从CFT处理获取有效流ID时，该流量会增加。价值上升是CFT/FID处理失败的证明；相对于总流量而言值较低并不能证明存在饱和。
show platform hardware qfp active infrastructure cft status show platform hardware qfp active feature appqoe stats global show sdwan appqoe rm-resources
将CFT状态与服务节点容量分开解释：
实验示例：
c8000v-appqoe-3（控制器），2026-07-15。已修剪长内存元素表。
c8000v-appqoe-3#show platform hardware qfp active infrastructure cft status
===================================== CFT 1/1 =====================================
CFT id: 0 CFT name: GLOBAL_CFT
General Parameters:
Max flows: 1000000
Number of buckets in CFT hash table: 7227108
Statistics:
Total number of flows added : 1424672
Total number of flows removed : 1424664
Total number of currently allocated flows : 8
... (per-feature memory element table truncated)
当前分配的流总数：8对1,000,000 max表示无表压力，cft_handle_pkt:在AppQoE统计信息中显示0确认没有FID获取故障。不断上升的cft_handle_pkt（不仅仅是表占用）是导致CFT/FID问题的原因。
- CFT状态标识边缘流表或流ID压力/错误。
- rm-resources标识AppQoE服务节点会话容量。
- 满表或内存压力是FID获取失败的可能原因，但不是唯一的原因。
如果在测试间隔期间错误增加，请捕获CFT错误/状态、平台扩展、活动连接和节点资源。减少连接压力，重新平衡服务节点，更改支持的资源配置文件，或迁移到具有所需规模的平台。在将常规CFT错误视为硬件容量结论之前，请与Cisco TAC联系。
SYN监察器和连接速率
使用完整状态和已记录的计数器。“SDVT_DROP_ERROR”是错误类；就其本身而言，这并不能证明SYN监察器已触发。
show sdwan appqoe libuinet-statistics show sdwan appqoe error recent show sdwan appqoe rm-resources
将新连接故障与达到的Syn Drop Max PP、由于PP导致的vPath丢弃，以及相同的测试间隔相关联。只有新的SYN发生故障时，长期流仍保持正常，这增强了监察器的假设。
实验示例：
c8000v-appqoe-4（服务节点），2026-07-15。 libuinet-statistics很长；将显示与监察器相关的Vpath统计信息块。
c8000v-appqoe-4#show sdwan appqoe libuinet-statistics | begin Vpath Statistics Vpath Statistics: Packets In : 112733521 Syn Packets : 21516 Syn Drop Max PPS Reached : 0 Flow Info Allocs : 21516 Flow Info Allocs Failed : 0 Vpath drops due to min threshhold: 0 Failed to create new connection: 0
已达到Syn Drop Max PPs:0(和由于PP导致的vPath丢弃：0 in error recent)在此处规则SYN监察器。控制器上配置的速率是syn_policer_rate:2700（来自内部所有）；将其与提供的SYN速率进行比较，然后再执行操作。
尽可能降低突发速率，将新连接分配到正常容量，并确认记录的监察器计数器停止增加。不要调整或绕过通用指南的保护限制；当持续费率接近支持限制时，使用平台和TAC的规模指导。
MTU和MSS
MSS调整本身不是直接AppQoE SYN丢弃路径。数据路径根据服务节点邻接MTU和封装开销计算MSS。在能够时，调整客户端MSS并存储服务器端MSS;当MTU信息不可用时，可以继续而不进行该调整。
因此，请勿单独使用sdvt_drop_appnav_divert作为MSS计算失败的证明。
确认
- 记录软件版本；17.5.1a中引入了SC到SN MTU的自动处理。
- 验证跨服务控制器/服务节点路径和SD-WAN底层支持的统一MTU。
- 使用DF-bit path-MTU测试并在相关边缘同步进行SYN/SYN-ACK捕获。
- 比较提供的和调整的MSS值，并检查分段或黑洞。
支持的有用平台命令：
show platform hardware qfp active feature sdwan datapath session summary
实验示例：
c8000v-appqoe-3（控制器），2026-07-15。
c8000v-appqoe-3#show platform hardware qfp active feature sdwan datapath session summary Src IP Dst IP Src Port Dst Port Encap Uidb Bfd Discrim PMTU Flags ------ ------ -------- ------- ------ ------- ----------- ----- ----- 192.168.172.19 192.168.172.6 12346 12346 IPSEC 65528 20005 1442 0x0 192.168.172.19 192.168.172.5 12346 12366 IPSEC 65528 20009 1442 0x0 192.168.172.19 192.168.172.20 12346 12346 IPSEC 65528 20006 1442 0x0
IPsec重叠会话报告统一PMTU 1442。跨SC/SN隧道的一致的PMTU（并且在DF位测试中没有黑洞）意味着MSS从稳定的邻接MTU派生 — 在接触隧道MTU之前排除此限制。
仅在确认失败跳后更正路径MTU或MSS策略。请勿增加隧道MTU，除非整个底层路径可以承载隧道MTU。
DRE处于活动状态，但缩减率较低
低缩减率并不自动意味着DRE中断。唯一的首遍数据、冷缓存、已压缩负载、无必要SSL/TLS处理的加密流量、非对称流、对等体不兼容或自动旁路都只能产生很少的或根本不会产生的降低。
确认DRE状态和对等体
show sdwan appqoe dreopt status detail show sdwan appqoe dreopt statistics detail show sdwan appqoe dreopt statistics peer show sdwan appqoe dreopt auto-bypass show sdwan appqoe ad-statistics show sdwan appqoe aoim-statistics show sslproxy status
实验示例：
c8000v-appqoe-4（服务节点），2026-07-15。DRE状态/统计信息/对等项显示在分类步骤4中。以上示例；其余命令：
c8000v-appqoe-4#show sdwan appqoe dreopt auto-bypass
c8000v-appqoe-4#
(empty — no flows in DRE auto-bypass)
c8000v-appqoe-4#show sdwan appqoe ad-statistics
[Edge] AD Negotiation Start : 21513
[Edge] AD Negotiation Done : 21215
[Edge] Rcvd SYN-ACK w/o AD options : 21167
[Core] AD Negotiation Start : 55
[Core] AD Negotiation Done : 55
c8000v-appqoe-4#show sdwan appqoe aoim-statistics
Total Number Of Peer Syncs : 2
Total Passthrough Connections Due to Peer Version Mismatch : 0
LOCAL AO Statistics: SSL 1.3 (Y), DRE 0.23 (Y)
PEER 10.20.0.1: SSL 1.3 InCompatible=N, DRE 0.23 InCompatible=N
PEER 10.30.0.1: SSL 1.3 InCompatible=N, DRE 0.23 InCompatible=N
c8000v-appqoe-4#show sslproxy status
CA TP Label : PROXY-SIGNING-CA
Dual-Side Optimization : TRUE
Min TLS Ver : TLS Version 1
Clear Mode : TRUE
没有任何内容处于自动旁路状态，AD协商正在完成，aoim-statistics显示来自版本不匹配的0个通道，两个DRE对等体都标记为不兼容= N。 sslproxy状态显示清除模式：TRUE，因此HTTPS负载在不解密的情况下传输 — 预期已加密流量的DRE减少 — 除非启用SSL代理。测得的减少48%（分类步骤4.）是对明文流的DRE真正好处。
验证：
- DRE策略在两端匹配两个方向。
- 流是对称的，并使用预期的对等体。
- DRE运行状况和缓存状态处于活动状态，没有相关警报。
- 对等体版本和AO功能是兼容的。
- 磁盘延迟和资源利用率都在支持的范围内。
- 流未处于自动旁路状态。
- 加密流量具有所需的SSL/TLS解密和双端优化配置。
正确测量
在两端使用一个有代表性的数据集和相同的时间间隔。在测试前后捕获原始和优化的字节计数器。生命周期减少比上的优选间隔增量。如果测试缓存优势，请记录运行是冷缓存还是热缓存，并重复相同的内容。
证据收集和升级
首先使用支持的操作命令。如果原因仍不清楚，请收集：
- UTC复制窗口和受影响的元组/VPN
- 同一站点对中的一个发生故障且有一个已知良好的数据流
- AppQoE状态、最近的错误、策略、服务节点组和来自两端的流输出
- DRE状态、对等体统计信息、资源状态和间隔字节增量
- 存在这些命令时，CFT状态和QFP AppQoE统计信息
- 在清除计数器或重新启动服务之前捕获管理技术
show sdwan appqoe flow all debug是展开的show output，而不是用于启用广泛平台调试的许可证。它可能很昂贵，而且可能暴露流元组；当目标流命令不足时，仅将其用于范围有限的简短集合。
在没有经过验证的版本/平台、捕获持续时间、输出目标和测试停止过程的情况下，请勿发布generic platform-debug命令。在繁忙的生产设备上使用思科TAC指南进行主动调试或数据包跟踪收集。
相关思科文档
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
1.0 |
21-Aug-2026
|
初始版本 |
反馈