Cisco Catalyst SD-WAN??AppQoE TCP???DRE????
Author: Cisco Systems, Inc.
Date: 2026-08-25T05:00:00+00:00
Description: ????????Cisco Catalyst SD-WAN??AppQoE TCP???DRE???????

目录

简介

背景信息

目的、范围和安全性

从这里开始:10分钟分类

1.验证AppQoE状态和最近出现的错误

2.双向验证策略和服务节点分配

3.检查一个已知流并进行端到端跟踪

跟踪单个流

4.检验服务节点资源和DRE

5.捕获服务控制器(SC)和服务节点(SN)之间的流量

方法 1：CLI（嵌入式数据包捕获 — EPC）

方法 2：GUI（思科SD-WAN管理器）

6.选择下一节

TCP优化和DRE如何处理流量

无优化或转移

确认

解释

正确并验证

分流故障和旁路

转移后丢弃

确认

解释

正确并验证

服务节点运行状况和分配

CFT和容量

SYN监察器和连接速率

MTU和MSS

确认

DRE处于活动状态，但缩减率较低

确认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文件供您下载：

1. 导航到Monitor > Devices。

2. 选择您的设备(c8000v-appqoe-4)。

3. 单击左侧窗格中的Troubleshooting。

4. 在流量部分下，选择数据包捕获。

5. 在接口选择下拉列表中，选择AppQoE隧道接口（例如Tunnel200000001）。

6. （可选）应用任何源/目标IP或端口过滤器。

7. 单击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

用于跟踪流及其功能状态的连接流表

无优化或转移

确认

1. 确认策略匹配和双向操作。

2. 通过预期的一对AppQoE设备确认对称路由。

3. 确认服务节点组和站点ID正确。

4. 确认两端的DRE已部署且运行正常。

5. 检查目标流的状态或直通原因。

解释

- 没有策略匹配通常意味着分类、方向、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真正好处。

验证：

1. DRE策略在两端匹配两个方向。

2. 流是对称的，并使用预期的对等体。

3. DRE运行状况和缓存状态处于活动状态，没有相关警报。

4. 对等体版本和AO功能是兼容的。

5. 磁盘延迟和资源利用率都在支持的范围内。

6. 流未处于自动旁路状态。

7. 加密流量具有所需的SSL/TLS解密和双端优化配置。

正确测量

在两端使用一个有代表性的数据集和相同的时间间隔。在测试前后捕获原始和优化的字节计数器。生命周期减少比上的优选间隔增量。如果测试缓存优势，请记录运行是冷缓存还是热缓存，并重复相同的内容。

证据收集和升级

首先使用支持的操作命令。如果原因仍不清楚，请收集：

- UTC复制窗口和受影响的元组/VPN

- 同一站点对中的一个发生故障且有一个已知良好的数据流

- AppQoE状态、最近的错误、策略、服务节点组和来自两端的流输出

- DRE状态、对等体统计信息、资源状态和间隔字节增量

- 存在这些命令时，CFT状态和QFP AppQoE统计信息

- 在清除计数器或重新启动服务之前捕获管理技术

show sdwan appqoe flow all debug是展开的show output，而不是用于启用广泛平台调试的许可证。它可能很昂贵，而且可能暴露流元组；当目标流命令不足时，仅将其用于范围有限的简短集合。

在没有经过验证的版本/平台、捕获持续时间、输出目标和测试停止过程的情况下，请勿发布generic platform-debug命令。在繁忙的生产设备上使用思科TAC指南进行主动调试或数据包跟踪收集。

相关思科文档

- AppQoE验证和故障排除
- TCP优化
- 使用DRE进行流量优化
- AppQoE服务的外部服务节点
- Catalyst SD-WAN AppQoE DRE:拓扑、配置、验证
- 思科技术支持和下载