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處理 |
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檔案供您下載：
- 導覽至Monitor > Devices。
- 選擇您的裝置(c8000v-appqoe-4)。
- 在左窗格中按一下Troubleshooting。
- 在Traffic部分下，選擇Packet Capture。
- 在介面選擇下拉選單中，選擇AppQoE隧道介面(例如Tunnel2000000001)。
- （可選）應用任何源/目標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服務的情況下繼續；檢查直通原因。 |
| drop |
封包不會繼續；這會影響使用者，並且需要丟棄/錯誤關聯。 |
| 失效關閉流狀態 |
在流量被檢查/轉移後，一些後來的轉移故障不能安全回落到普通旁路。 |
| 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
如果版本和平台上存在，請比較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真正的益處。
驗證:
- DRE策略在兩端匹配兩個方向。
- 流量是對稱的，並使用預期的對等體。
- DRE運行狀況和快取狀態處於活動狀態，沒有相關警報。
- 對等體版本和AO功能是相容的。
- 磁碟延遲和資源利用率在支援的範圍內。
- 流量未處於自動旁路狀態。
- 加密流量具有所需的SSL/TLS解密和雙端最佳化配置。
正確測量
在兩端使用一個有代表性的資料集和相同的時間間隔。在測試前後捕獲原始和最佳化的位元組計數器。生命週期減少比率上的優選間隔增量。如果測試快取的優點，請記錄運行是冷快取還是熱快取，並重複相同的內容。
證據收集和升級
首先使用支援的操作命令。如果原因仍不清楚，請收集：
- UTC複製視窗和受影響的元組/VPN
- 同一站點對中的一個失敗流和一個已知正常的流
- 兩端的AppQoE狀態、最近錯誤、策略、服務節點組和流輸出
- DRE狀態、對等體統計資訊、資源狀態和間隔位元組增量
- 存在這些命令時，CFT狀態和QFP AppQoE統計資訊
- 在清除計數器或重新啟動服務之前捕獲管理技術
show sdwan appqoe flow all debug is expanded show output，而不是用於啟用廣泛平台調試的許可證。它可能代價高昂，而且可能暴露流量元組；當目標流命令不足時，僅將其用於範圍有限的簡短集合。
在沒有經過驗證的版本/平台、捕獲持續時間、輸出目標和測試停止過程的情況下，不要發佈通用platform-debug命令。在繁忙的生產裝置上使用Cisco TAC指南進行主動調試或資料包跟蹤收集。
相關思科檔案
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
21-Aug-2026
|
初始版本 |
意見