目錄

簡介

背景資訊

目的、範圍和安全性

從這裡開始：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處理

Cisco IOS XE Catalyst SD-WAN 17.5.1a

增強的AppQoE故障排除和子服務運行狀況

17.6.1安

擴展的流量詳細故障排除

17.9.1安

使用TLS 1.3的SSL代理

17.13.1a/管理器20.13.1

DRE通過配置組

17.14.1a/管理器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

該操作接受同時攜帶指向SNG-APPQOE的tcp最佳化和dre最佳化功能，並且SN使用tcp/dre GREEN處於活動狀態。 ssl/http/utd顯示紅色/不可用，因為這些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-id <id>，以便直接讀取其記錄的optimized/bypass狀態。上面的跟蹤流顯示服務= 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)功能。以下是使用Tunnel1的分步2000000001態，範例：

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. 在Traffic部分下，選擇Packet Capture。

5. 在介面選擇下拉選單中，選擇AppQoE隧道介面(例如Tunnel2000000001)。

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服務的情況下繼續；檢查直通原因。

drop

封包不會繼續；這會影響使用者，並且需要丟棄/錯誤關聯。

失效關閉流狀態

在流量被檢查/轉移後，一些後來的轉移故障不能安全回落到普通旁路。

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

如果版本和平台上存在，請比較stats 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最大表示無表壓力，cft_handle_pkt:在AppQoE狀態中為0確認沒有FID獲取失敗。不斷上升的cft_handle_pkt（而非僅是表佔用）是導致CFT/FID問題的原因。

- CFT狀態標識邊緣流表或flow-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 PP:0(和vPath drop due to PP: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位元路徑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。

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時，除非啟用SSL代理，否則HTTPS負載在不解密的情況下遍歷 — 在已加密的流量上預期較弱的DRE減少。測得的減少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 is expanded show output，而不是用於啟用廣泛平台調試的許可證。它可能代價高昂，而且可能暴露流量元組；當目標流命令不足時，僅將其用於範圍有限的簡短集合。

在沒有經過驗證的版本/平台、捕獲持續時間、輸出目標和測試停止過程的情況下，不要發佈通用platform-debug命令。在繁忙的生產裝置上使用Cisco TAC指南進行主動調試或資料包跟蹤收集。

相關思科檔案

- AppQoE驗證和故障排除

- TCP最佳化

- 使用DRE的流量最佳化

- AppQoE服務的外部服務節點

- Catalyst SD-WAN AppQoE DRE:拓撲、配置、驗證

- 思科技術支援與下載