Troubleshoot AppQoE TCP Optimization and DRE in Cisco Catalyst SD-WAN
Available Languages
Contents
Introduction
This document describes how to troubleshoot AppQoE TCP Optimization and DRE in Cisco Catalyst SD-WAN.
Background Information
Use this guide when an AppQoE-enabled TCP flow is not optimized, is bypassed, resets after diversion, reports an unhealthy service node, or shows fewer Data Redundancy Elimination (DRE) reduction than expected.
Start with the 10-minute triage. It separates policy and path problems from service-node health, flow-state, capacity, TCP transport, and DRE-effectiveness problems. Continue to a symptom section only after you know where the flow stops behaving as expected.
Purpose, Scope, and Safety
This guide covers Cisco IOS® XE Catalyst SD-WAN devices using TCP optimization or DRE with integrated or external AppQoE service nodes.
| Validation Item | Status |
|---|---|
| Public behavior and operational CLI |
Aligned with the current Cisco Catalyst SD-WAN AppQoE 26.x documentation |
| Internal counter semantics |
Rechecked against current Cisco IOS XE source on 2026-07-15 |
| Exact release, platform, and topology used for publication |
Lab capture: Cisco IOS XE Catalyst SD-WAN 17.18.2 on C8000v, external service-node AppQoE. AppNav controller c8000v-appqoe-3, service node c8000v-appqoe-4, external SN appqoe-service-node (SN IP 15.15.15.2). SNG SNG-APPQOE, data policy _vpn-10_appqoe-policy (TCP + DRE) on VPN 10. Captured 2026-07-15. |
Command availability and output vary by software release, platform, and role. Confirm syntax with command help on the target device. The low-level QFP commands in this guide are read-only, but they are platform-and release-specific; use them only when the command is present.
Key release checkpoints are shown below; they do not replace platform-specific support and scale documentation.
| Capability | Minimum Release Checkpoint |
|---|---|
| DRE and automated service-controller/service-node MTU handling |
Cisco IOS XE Catalyst SD-WAN 17.5.1a |
| Enhanced AppQoE troubleshooting and sub-service health |
17.6.1a |
| Expanded flow-detail troubleshooting |
17.9.1a |
| SSL proxy with TLS 1.3 |
17.13.1a/Manager 20.13.1 |
| DRE through configuration groups |
17.14.1a/Manager 20.14.1 |
DRE requires supported service nodes at both ends and symmetric flow handling. It does not run on a device in service-controller-only role, and AppQoE cannot be combined with Packet Duplication on the same connection. Encrypted traffic requires the supported SSL/TLS handling if its payload is to be optimized.
Before changing policy, clearing statistics, restarting a service, or enabling debug, capture:
- Software release, platform, and AppQoE role at both ends
- Source and destination IP addresses, ports, protocol, VPN, and UTC test time
- Expected policy sequence and service-node assignment
- Whether the symptom affects one flow, one site pair, or all AppQoE traffic
- Two counter snapshots over the same test interval
Note: Do not clear the DRE cache during initial troubleshooting. Clearing it restarts DRE and destroys the warm cache, which changes the condition being measured.
Start Here: 10-minute Triage
1. Verify AppQoE State and Recent Errors
Run on the participating edge devices or service controllers:
show sdwan appqoe status show sdwan appqoe error recent
Lab sample:
c8000v-appqoe-4 (service node, 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)
Here overall status is YELLOW only because the SSL AO is not in use (SSL proxy is in clear mode); TCP, service-chain, and resource-manager subservices are GREEN. No PPs drops or new-connection failures.
Look for the enabled services, current service-node state, recent flow errors, and any reason that directly explains bypass or drop behavior.
2. Verify Policy and Service-node Assignment in Both Directions
show sdwan policy from-vsmart show service-insertion type appqoe service-node-group
Lab sample:
c8000v-appqoe-3 (AppNav controller), 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
The action accept carries both tcp-optimization and dre-optimization pointing at SNG-APPQOE, and the SN is alive with tcp/dre GREEN. ssl/http/utd show RED/NOT AVAILABLE because those AOs are not configured — expected for a TCP+DRE-only test.
Confirm that the intended sequence matches both directions of the test flow, includes the expected TCP/DRE actions, and points to the intended service-node group. DRE requires both ends and symmetric flow handling.
3. Inspect One Known Flow and Trace it End-to-end
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
Tracing a Single Flow
First, run show sdwan appqoe flow vpn-id <vpn-id> server-ip <server-ip> server-port <port> on both the edge and DC routers. This command returns the flow ID. Once you have the flow ID, run show sdwan appqoe flow flow-id <flow-id> on both routers.
show sdwan appqoe flow vpn-id <vpn-id> server-ip <server-ip> server-port <port> show sdwan appqoe flow flow-id <flow-id>
Lab sample:
c8000v-appqoe-4 (service node), 2026-07-15. No flows were active at capture time, so the historical (closed) table is shown.
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 means these flows were TCP-optimized; RR% is blank because the DRE reduction ratio is reported per DRE-optimized flow (see the DRE sections). Use flow flow-id <id> on a live flow in order to read its recorded optimized/bypass status directly. The traced flow above shows Service = TD (TCP + DRE) and a complete proxy event sequence — SYN options exchange, accept/connect, DRE flow-create success, and data enabled — confirming full end-to-end optimization.
Classify the flow as optimized, bypassed/passthrough, or failed. Prefer the recorded status of the flow or passthrough reason over an inference from one aggregate counter.
4. Verify Service-node Resources and DRE
Run the commands that apply to the device role:
show sdwan appqoe rm-resources show sdwan appqoe dreopt status detail show sdwan appqoe dreopt statistics detail show sdwan appqoe dreopt statistics peer
Lab sample:
c8000v-appqoe-4 (service node), 2026-07-15. Long DRE output trimmed to the health/capacity fields.
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
Health GREEN, no alarms, disk latency 2 ms, and a healthy 48% overall reduction ratio. The peer table confirms both DRE peers are reachable and version-compatible (see aoim-statistics).
Check health, maximum and active connections, peer compatibility, cache state, disk latency or alarms, and original-versus-optimized byte deltas.
5. Capture Traffic between Service Controller (SC) and Service Node (SN)
Take a monitor capture on the tunnel interface between the SC and SN. It provides clear, non-encapsulated data.
Method 1: CLI (Embedded Packet Capture — EPC)
You can use the Cisco IOS XE Embedded Packet Capture (EPC) feature directly on the device CLI. Here is the step-by-step configuration using Tunnel2000000001 as the example:
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
Method 2: GUI (Cisco SD-WAN Manager)
Alternatively, you can perform this capture directly from the Cisco SD-WAN Manager (formerly vManage) GUI, which will automatically output a .pcap file for you to download:
- Navigate to Monitor > Devices.
- Choose your device (c8000v-appqoe-4).
- Click Troubleshooting in the left pane.
- Under the Traffic section, choose Packet Capture.
- In the interface selection dropdown, choose the AppQoE tunnel interface (for example, Tunnel2000000001).
- (Optional) Apply any Source/Destination IP or Port filters.
- Click Start to begin the capture, and Stop when finished. The system will prepare a .pcap file for download.
6. Choose the Next Section
| First Abnormal Result |
Continue To |
|---|---|
| Policy does not match in both directions |
No optimization or diversion |
| No healthy or eligible service node is assigned |
Service-node health and assignment |
| Flow is bypassed or has a passthrough reason |
Diversion failure and bypass |
| Existing flow resets or packets drop |
Drops after diversion |
| Only new connections fail during a burst |
SYN policer and connection rate |
| CFT/FID failures increase |
CFT and capacity |
| TCP stalls and PMTU/MSS evidence is present |
MTU and MSS |
| Flow is optimized but reduction is weak |
DRE effectiveness |
How TCP Optimization and DRE Process a Flow
With dual-ended TCP optimization and DRE, the original connection is represented by three TCP connections:
Client <-- LAN leg --> Edge A proxy/SN <== overlay leg + DRE ==> Edge B proxy/SN <-- LAN leg --> Server
DRE compresses repeated data on the overlay leg. The far-end device reconstructs the original stream before forwarding it to the destination. An external-service-node topology adds service-controller-to-service-node redirection, but the same checkpoints remain: policy, path symmetry, service-node eligibility, flow diversion, peer compatibility, and DRE state.
| Term | Meaning in this Guide |
|---|---|
| Optimized |
The selected AppQoE service is active for the flow. |
| Bypass or passthrough |
Traffic continues without the chosen AppQoE service; inspect the passthrough reason. |
| Drop |
The packet does not continue; this is user-impacting and requires a drop/error correlation. |
| Fail-close flow state |
After a flow has been inspected/diverted, some later diversion failures cannot safely fall back to ordinary bypass. |
| SC |
Service Controller |
| SN/ISN/ESN |
Service Node/Integrated Service Node/External Service Node |
| CFT |
Connection Flow Table used to track flows and their feature state |
No Optimization or Diversion
Confirm
- Confirm the policy match and actions in both directions.
- Confirm symmetric routing through the expected pair of AppQoE devices.
- Confirm that the service-node group and site IDs are correct.
- Confirm that DRE is deployed and healthy at both ends.
- Inspect the status of the target flow or passthrough reason.
Interpret
- No policy match usually means classification, direction, VPN, or attachment is wrong.
- A one-sided match can enable TCP/DRE handling on one edge but cannot provide a valid two-ended DRE path.
- A flow can correctly bypass when the traffic is already optimized, is an unsupported flow type, is asymmetric, or matches an auto-bypass condition.
Correct and Verify
Correct policy, direction, node-group, site-ID, or routing issues. Then create a new TCP connection and verify the flow on both ends. Do not use an existing connection to validate a policy change.
Diversion Failure and Bypass
Use internal QFP statistics only after the supported AppQoE flow and error commands have narrowed the problem:
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
Compare two snapshots; these counters are cumulative.
Lab sample:
c8000v-appqoe-3 (AppNav controller), 2026-07-15. Healthy diversion: the SN index is Green and no drop-cause counters are climbing beyond the expected SN Unhealthy transients recorded earlier.
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 and appqoe_svc_on_appqoe_vpn_drop: 0 rule out CFT/FID failure and a recursive-VPN drop. The packets dropped as SN Unhealthy: 10 is a small historical count — correlate against the SN health transitions before treating it as active impact.
Drops after Diversion
Confirm
show sdwan appqoe error recent show sdwan appqoe flow closed all show sdwan appqoe status show service-insertion type appqoe service-node-group
If present on the release and platform, compare stats global or stats all before and after one controlled reproduction.
Lab sample:
Healthy baseline, c8000v-appqoe-3 (controller), 2026-07-15. No fail-close drops are accruing; the SN is Alive/Green and error recent shows vPath drop due to PPs: 0 and vPath new connection failed: 0. The datapath drop-cause snapshot is the deciding evidence:
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
Correlate the exact reproduction time against these deltas before labeling a reset as fail-close.
Interpret
A previously inspected/diverted flow can drop when the service node becomes unusable or a later AppNav redirect fails. This protects established proxy state; the original client-to-server connection cannot always be reconstructed transparently after a proxy path disappears. Service-chain flows can also drop when ordinary bypass violates chain processing.
Do not label every reset as fail-close. Correlate the exact test time with the flow error, service-node health transition, and counter delta.
Correct and Verify
Restore a stable eligible service node and correct the path or service-chain failure. Validate with a new TCP connection, then confirm that the relevant drop counter stops increasing.
Service-node Health and Assignment
Health is role and service-specific. Liveness, resource capacity, and the health of a particular Application Optimizer (AO) are related but not interchangeable.
| State |
Datapath Behavior to Expect |
|---|---|
| Green |
Eligible for new and existing flows |
| Yellow |
Existing inspected non-SYN traffic can continue; new SYNs are not diverted to that node. A FULL node is one possible Yellow condition |
| Red or Down |
New/uncommitted flows normally bypass when allowed; already-inspected/fail-close flows can drop; service-chain flows can drop |
Run:
show service-insertion type appqoe service-node-group show sdwan appqoe status show sdwan appqoe rm-resources show sdwan appqoe dreopt status detail
Check node membership, site ID, liveness, AO health, load/capacity, DRE alarms, and peer reachability. Before Cisco IOS XE Catalyst SD-WAN Release 17.6.1a, subservice health detail can be limited; interpret older output accordingly.
Lab sample:
Healthy node, 2026-07-15. On the controller the SN is Alive with per-AO health markers; on the node the resource manager reports Green with headroom:
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
Load is 0% and used sessions are well under the 40000/750 limits, so this node is neither full nor Yellow for capacity reasons. The Yellow overall status seen in show sdwan appqoe status traces only to the unused SSL AO.
When a node is full or Yellow because it is near its configured session capacity, distribute new connections, increase the supported AppQoE resource profile where the platform allows it, or add capacity. Do not assume that adding router DRAM changes the supported hardware flow scale.
CFT and Capacity
appqoe_cft_handle_pkt is an error counter. It increments when AppQoE cannot obtain a valid flow ID from CFT handling. A rising value is evidence of a CFT/FID handling failure; a low value relative to total traffic is not proof of saturation.
show platform hardware qfp active infrastructure cft status show platform hardware qfp active feature appqoe stats global show sdwan appqoe rm-resources
Interpret CFT state separately from service-node capacity:
Lab sample:
c8000v-appqoe-3 (controller), 2026-07-15. Long memory-element table trimmed.
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)
Total number of currently allocated flows: 8 against a 1,000,000 max means no table pressure, and cft_handle_pkt: 0 in the AppQoE stats confirms no FID-acquisition failure. A rising cft_handle_pkt — not table occupancy alone — is what points to a CFT/FID problem.
- CFT status identifies edge flow-table or flow-ID pressure/errors.
- rm-resources identifies AppQoE service-node session capacity.
- Full tables or memory pressure are possible causes of FID acquisition failure, but not the only causes.
If the error increases during the test interval, capture the CFT error/state, platform scale, active connections, and node resources. Reduce connection pressure, rebalance service nodes, change the supported resource profile, or move to a platform with the required scale. Engage Cisco TAC before treating a generic CFT error as a hardware-capacity conclusion.
SYN Policer and Connection Rate
Use the full status and documented counters. "SDVT_DROP_ERROR" is an error class; by itself it is not proof that the SYN policer fired.
show sdwan appqoe libuinet-statistics show sdwan appqoe error recent show sdwan appqoe rm-resources
Co-relate new-connection failures with Syn Drop Max PPs reached, vPath drop due to PPs, and the same test interval. Long-lived flows remaining healthy while only new SYNs fail strengthens the policer hypothesis.
Lab sample:
c8000v-appqoe-4 (service node), 2026-07-15. libuinet-statistics is long; the policer-relevant Vpath statistics block is shown.
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 reached: 0 (and vPath drop due to PPs: 0 in error recent) rules the SYN policer out here. The configured rate on the controller is syn_policer_rate: 2700 (from internal all); compare it against your offered SYN rate before acting.
Reduce the burst rate if possible, distribute new connections across healthy capacity, and confirm that the documented policer counters stop increasing. Do not tune or bypass protective limits from a generic guide; use the scale guidance of the platform and TAC when sustained rates approach supported limits.
MTU and MSS
MSS adjustment is not, by itself, a direct AppQoE SYN-drop path. The datapath calculates an MSS from the service-node adjacency MTU and encapsulation overhead. When it can, it adjusts the client MSS and stores a server-side MSS; when MTU information is unavailable, it can continue without that adjustment.
Therefore, do not use sdvt_drop_appnav_divert alone as proof of an MSS calculation failure.
Confirm
- Record the software release; automated SC-to-SN MTU handling was introduced in 17.5.1a.
- Verify a uniform supported MTU across the service-controller/service-node path and the SD-WAN underlay.
- Use DF-bit path-MTU testing and synchronized SYN/SYN-ACK captures at the relevant edges.
- Compare offered and adjusted MSS values and check for fragmentation or black-holing.
Useful platform command where supported:
show platform hardware qfp active feature sdwan datapath session summary
Lab sample:
c8000v-appqoe-3 (controller), 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
The IPsec overlay sessions report a uniform PMTU 1442. A consistent PMTU across the SC/SN tunnels (and no black-holing in DF-bit tests) means MSS is being derived from a stable adjacency MTU — rule this out before touching tunnel MTU.
Correct the path MTU or MSS policy only after confirming the failing hop. Do not increase a tunnel MTU unless the complete underlay path can carry it.
DRE is Active but Reduction is Weak
Low reduction does not automatically mean DRE is broken. Unique first-pass data, a cold cache, already-compressed payloads, encrypted traffic without the required SSL/TLS handling, asymmetric flows, peer incompatibility, or auto-bypass can all produce little or no reduction.
Confirm DRE State and Peers
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
Lab sample:
c8000v-appqoe-4 (service node), 2026-07-15. DRE status/statistics/peer appear in the triage Step 4. sample above; the remaining commands:
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
Nothing is in auto-bypass, AD negotiation is completing, and aoim-statistics shows 0 passthroughs from version mismatch with both DRE peers marked incompatible = N. sslproxy status shows Clear Mode: TRUE, so HTTPS payloads traverse without decryption — expected weak DRE reduction on already - encrypted traffic unless SSL proxy is enabled. The measured 48% reduction (triage Step 4.) is real DRE benefit on the clear-text flows.
Verify:
- DRE policy matches both directions at both ends.
- The flow is symmetric and uses the expected peers.
- DRE health and cache state are active with no relevant alarm.
- Peer versions and AO capabilities are compatible.
- Disk latency and resource utilization are within the supported range.
- The flow is not in auto-bypass.
- Encrypted traffic has the required SSL/TLS decryption and dual-ended optimization configuration.
Measure Correctly
Use one representative data set and the same time interval at both ends. Capture original and optimized byte counters before and after the test. Prefer interval deltas over a lifetime reduction ratio. If testing cache benefit, document whether the run is cold-cache or warm-cache and repeat the same content.
Evidence Collection and Escalation
Use supported operational commands first. If the cause remains unclear, collect:
- UTC reproduction window and affected tuple/VPN
- One failing and one known-good flow from the same site pair
- AppQoE status, recent errors, policy, service-node group, and flow output from both ends
- DRE status, peer statistics, resource state, and interval byte deltas
- CFT status and QFP AppQoE statistics when those commands exist
- Admin-tech captured before clearing counters or restarting services
show sdwan appqoe flow all debug is expanded show output, not a license to enable broad platform debugging. It can be expensive and can expose flow tuples; use it only for a short, scoped collection when targeted flow commands are insufficient.
Do not publish a generic platform-debug command without a validated release/platform, a capture duration, an output destination, and a tested stop procedure. Use Cisco TAC guidance for active debug or packet-trace collection on a busy production device.
Related Cisco Documentation
- AppQoE Verification and Troubleshooting
- TCP Optimization
- Traffic Optimization with DRE
- External Service Nodes for AppQoE Services
- Catalyst SD-WAN AppQoE DRE: Topology, Configuration, Verification
- Cisco Technical Support & Downloads
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
21-Aug-2026
|
Initial Release |
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)