Konfigurieren der TCP-Optimierungsfunktion in Cisco IOS® XE SD-WAN cEdge-Router
Inhalt
Einleitung
In diesem Dokument wird die TCP-Optimierungsfunktion (Transmission Control Protocol) auf Cisco IOS® XE SD-WAN-Routern beschrieben, die im August 2019 mit der Version 16.12 eingeführt wurde. Zu den behandelten Themen gehören Voraussetzungen, Problembeschreibung, Lösung, Unterschiede bei TCP-Optimierungsalgorithmen zwischen Viptela OS (vEdge) und XE SD-WAN (cEdge), Konfiguration, Verifizierung und Liste verwandter Dokumente.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf Cisco IOS®XE SD-WAN.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Problem
Eine hohe Latenz bei einer WAN-Verbindung zwischen zwei SD-WAN-Seiten führt zu einer schlechten Anwendungsleistung. Sie haben kritischen TCP-Datenverkehr, der optimiert werden muss.
Lösung
Wenn Sie die TCP-Optimierungsfunktion verwenden, verbessern Sie den durchschnittlichen TCP-Durchsatz für kritische TCP-Datenflüsse zwischen zwei SD-WAN-Standorten.
Überblick und Unterschiede zwischen TCP-Optimierung auf cEdge Bottleneck-Bandbreite und Round-Trip (BBR) und vEdge (CUBIC)
Bei der XE SD-WAN-Implementierung (auf cEdge) wird ein schneller BBR-Propagierungszeitalgorithmus verwendet.
Viptela OS (vEdge) verfügt über einen anderen, älteren Algorithmus, den so genannten CUBIC.
CUBIC berücksichtigt hauptsächlich den Paketverlust und wird häufig in verschiedenen Client-Betriebssystemen implementiert. Für Windows, Linux, MacOS und Android ist CUBIC bereits integriert. In einigen Fällen führen ältere Clients den TCP-Stack ohne CUBIC aus, wodurch die TCP-Optimierung auf vEdge verbessert wird. Eines der Beispiele, bei denen die vEdge TCP CUBIC-Optimierung von Nutzen war, ist das Vorhandensein von U-Booten, die alte Client-Hosts und WAN-Verbindungen nutzen, bei denen es zu erheblichen Verzögerungen/Verlusten kam. Beachten Sie, dass TCP CUBIC nur von vEdge 1000 und vEdge 2000 unterstützt wird.
Der Schwerpunkt von BBR liegt auf Round-Trip-Zeit und Latenz. Kein Paketverlust. Wenn Sie Pakete von der West- zur Ostküste der USA oder sogar nach Europa über das öffentliche Internet versenden, sehen Sie in den meisten Fällen keinen Paketverlust. Das öffentliche Internet ist manchmal zu gut, was den Paketverlust angeht. Aber was Sie sehen, ist Verzögerung/Latenz. Und dieses Problem wird durch BBR angegangen, das 2016 von Google entwickelt wurde.
Kurz gesagt modelliert BBR das Netzwerk und betrachtet jede Bestätigung (ACK) und aktualisiert die maximale Bandbreite (BW) und die minimale Round-Trip-Zeit (RTT). Die Steuerung des Sendens basiert dann auf dem Modell: Überprüfung auf max. Bandbreite und min. RTT, Annäherung an den Schätzwert und Aufrechterhaltung des Flugverkehrs in der Nähe des Bandwidth-Delay-Product (BDP). Das Hauptziel besteht darin, einen hohen Durchsatz mit einem kleinen Engpass in der Warteschlange sicherzustellen.
Diese Folie von Mark Claypool zeigt den Einsatzbereich von CUBIC:
BBR arbeitet an einem besseren Ort, was in dieser Folie auch von Mark Claypool gezeigt wird:
Wenn Sie mehr über den BBR-Algorithmus lesen möchten, finden Sie mehrere Publikationen über BBR, die oben auf der bbr-dev Mailinglisten-Homepage verlinkt sind. Hier finden Sie die wichtigsten Informationen zum BBR.
Zusammenfassung:
| Plattform und Algorithmus |
Eingabeparameter | Anwendungsfall |
| cEdge (XE SD-WAN): BR | RTT/Latenz | Kritischer TCP-Datenverkehr zwischen zwei SD-WAN-Standorten |
| vEdge (Viptela OS): CUBICP | Paketverlust | Alte Clients ohne TCP-Optimierung |
Unterstützte XE SD-WAN-Plattformen
In der XE SD-WAN SW-Version 16.12.1d unterstützen diese cEdge-Plattformen TCP-Optimierung BBR:
- ISR 4331
- ISR 4351
- CSR1000v mit 8 vCPU und mind. 8 GB RAM
Hinweise
- Alle Plattformen mit DRAM unter 8 GB RAM werden derzeit nicht unterstützt.
- Alle Plattformen mit 4 oder weniger Datenkernen werden derzeit nicht unterstützt.
- Die TCP-Optimierung unterstützt MTU 2000 nicht.
- Derzeit keine Unterstützung für IPv6-Datenverkehr.
- Optimierung für DIA-Datenverkehr zu einem BBR-Server eines Drittanbieters wird nicht unterstützt. Sie benötigen auf beiden Seiten einen cEdge SD-WAN-Router.
- Im Rechenzentrumsszenario wird derzeit nur ein Service Node (SN) pro Control Node (CN) unterstützt.
- Ein kombinierter Anwendungsfall mit Sicherheit (UTD-Container) und TCP-Optimierung auf demselben Gerät wird in Version 16.12 nicht unterstützt. Ab 17.2 wird der kombinierte Anwendungsfall unterstützt. Die Reihenfolge der Vorgänge lautet "TCP Opt first" (TCP zuerst aktivieren) und "Security" (Sicherheit). Das Paket wird an den TCP-Optimierungscontainer gesendet und dann vom Dienst (kein zweiter Punkt) an den UTD-Sicherheitscontainer angekettet. Die TCP-Optimierung wird für den kompletten Datenfluss durchgeführt, nicht für die ersten paar Bytes. Wenn UTD unterbrochen wird, wird die gesamte Verbindung unterbrochen.
In dieser Tabelle werden die Probleme pro Version zusammengefasst und die unterstützten Hardwareplattformen hervorgehoben:
| Szenarien |
Anwendungsfälle |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
Kommentare |
| Zweigstelle-zu-Internet |
DIA |
Nein |
Ja |
Ja |
Ja |
In 16.12.1 ist AppQoE FIA auf der Internetschnittstelle nicht aktiviert. |
| SAAS |
Nein |
Ja |
Ja |
Ja |
In 16.12.1 ist AppQoE FIA auf der Internetschnittstelle nicht aktiviert. |
|
| Von Zweigstelle zu Rechenzentrum |
Single-Edge-Router |
Nein |
Nein |
Nein |
Ja |
Unterstützung mehrerer SN erforderlich |
| Router für mehrere Edges |
Nein |
Nein |
Nein |
Ja |
Flow-Symmetrie oder AppNav-Flow-Synchronisierung erforderlich. 16.12.1 nicht getestet mit |
|
| Mehrere SNs |
Nein |
Nein |
Nein |
Ja |
vManage-Erweiterung zur Annahme mehrerer SN-IPs |
|
| Von Zweigstelle zu Zweigstelle |
Vollständiges Mesh-Netzwerk (Spoke-to-Spoke) |
Ja |
Ja |
Ja |
Ja |
|
| Hub and Spoke (Spoke-Hub-Spoke) |
Nein |
Ja |
Ja |
Ja |
||
| BBR-Unterstützung |
TCP-Auswahl mit BBR |
Teilweise | Teilweise |
Full-Commit |
Full-Commit |
|
| Plattformen |
Unterstützte Plattformen |
Nur 4300 und CSR |
Alle außer ISR1100 |
Alle |
Alle |
Konfigurieren
Für die TCP-Optimierung wird ein Konzept aus SN und CN verwendet:
- SN ist ein Daemon, der für die eigentliche Optimierung von TCP-Flows verantwortlich ist.
- CN ist als AppNav Controller bekannt und für die Auswahl des Datenverkehrs und den Transport von/zu SN verantwortlich.
SN und CN können auf demselben Router oder getrennt als verschiedene Knoten ausgeführt werden.
Es gibt zwei Hauptanwendungsfälle:
- Anwendungsfall in Zweigstellen mit SN und CN auf demselben ISR4k-Router
- Anwendungsfall für Rechenzentren: CN wird auf ASR1k und SN auf einem separaten virtuellen CSR1000v-Router ausgeführt.
Beide Anwendungsfälle werden in diesem Abschnitt beschrieben.
Anwendungsfall 1. Konfigurieren der TCP-Optimierung in einer Außenstelle (alles in einem cEdge)
Dieses Bild zeigt die interne Gesamtarchitektur für eine einzelne Standalone-Option in einer Außenstelle:
Schritt 1: Um die TCP-Optimierung zu konfigurieren, müssen Sie in vManage eine Funktionsvorlage für die TCP-Optimierung erstellen. Navigieren Sie zu Konfiguration > Vorlagen > Funktionsvorlagen > Andere Vorlagen > AppQoE, wie im Bild dargestellt.
Schritt 2: Fügen Sie die AppQoE-Funktionsvorlage der entsprechenden Gerätevorlage unter "Zusätzliche Vorlagen" hinzu:
Dies ist die CLI-Vorschau der Vorlagenkonfiguration:
service-insertion service-node-group appqoe SNG-APPQOE
service-node 192.3.3.2
!
service-insertion appnav-controller-group appqoe ACG-APPQOE
appnav-controller 192.3.3.1
!
service-insertion service-context appqoe/1
appnav-controller-group ACG-APPQOE
service-node-group SNG-APPQOE
vrf global
enable
! !
interface VirtualPortGroup2
ip address 192.3.3.1 255.255.255.0
no mop enabled
no mop sysid
service-insertion appqoe
!
Schritt 3: Erstellen Sie eine zentrale Datenrichtlinie mit der Definition des interessanten TCP-Verkehrs für die Optimierung.
Als Beispiel: Diese Datenrichtlinie stimmt mit dem IP-Präfix 10.0.0.0/8 überein, das Quell- und Zieladressen enthält, und aktiviert die TCP-Optimierung:
Dies ist die CLI-Vorschau der vSmart-Richtlinie:
policy
data-policy _vpn-list-vpn1_TCPOpt_1758410684
vpn-list vpn-list-vpn1
sequence 1
match
destination-ip 10.0.0.0/8
!
action accept
tcp-optimization
!
!
default-action accept
!
lists
site-list TCPOpt-sites
site-id 211
site-id 212
!
vpn-list vpn-list-vpn1
vpn 1
!
!
!
apply-policy
site-list TCPOpt-sites
data-policy _vpn-list-vpn1_TCPOpt_1758410684 all
!
!
Anwendungsfall 2. Konfigurieren der TCP-Optimierung im Rechenzentrum mit einem externen SN
Der Hauptunterschied zwischen SN und CN zum Anwendungsfall für Zweigstellen. Im Anwendungsfall einer Zweigstelle erfolgt die Anbindung mittels Virtual Port Group Interface innerhalb desselben Routers. Im Anwendungsfall für Rechenzentren gibt es einen AppNav GRE-gekapselten Tunnel zwischen ASR1k als CN und einem externen CSR1k als SN. Es ist keine dedizierte Verbindung oder Cross-Connect-Verbindung zwischen CN und externem SN erforderlich, einfache IP-Erreichbarkeit ist ausreichend.
Pro SN ist ein AppNav-Tunnel (GRE) vorhanden. Für die zukünftige Verwendung, bei der mehrere SNs unterstützt werden, wird empfohlen, das Subnetz /28 für das Netzwerk zwischen CN und SN zu verwenden.
Auf einem CSR1k werden zwei NICs empfohlen, die als SN fungieren. Eine zweite NIC für den SD-WAN-Controller ist erforderlich, wenn SN von vManage konfiguriert/verwaltet werden muss. Wenn SN manuell konfiguriert/verwaltet wird, ist die zweite Netzwerkkarte optional.
Dieses Bild zeigt das Rechenzentrum ASR1k, das als CN und CSR1kv als Service Node SN ausgeführt wird:
Die Topologie für den Anwendungsfall des Rechenzentrums mit ASR1k und externem CSR1k ist hier dargestellt:
Diese AppQoE-Funktionsvorlage zeigt den als Controller konfigurierten ASR1k:
Der als externer Serviceknoten konfigurierte CSR1k wird hier angezeigt:
Failover-Fall
Failover im Rechenzentrums-Anwendungsfall, wobei CSR1k als SN fungiert, bei einem externen CSR1k-Ausfall:
- Bereits vorhandene TCP-Sitzungen gehen verloren, da die TCP-Sitzung auf SN beendet wird.
- Neue TCP-Sitzungen werden an das endgültige Ziel gesendet, der TCP-Datenverkehr wird jedoch nicht optimiert (umgangen).
- Kein Blackholing von interessantem Datenverkehr bei einem SN-Ausfall.
Die Failover-Erkennung basiert auf AppNav-Heartbeat, d. h. 1 Beat pro Sekunde. Nach 3 oder 4 Fehlern wird der Tunnel als ausgefallen deklariert.
Das Failover in der Außenstelle ist ähnlich: Bei einem SN-Ausfall wird der Datenverkehr nicht optimiert direkt an das Ziel gesendet.
Überprüfung
Verwenden Sie diesen Abschnitt, um zu überprüfen, ob Ihre Konfiguration ordnungsgemäß funktioniert.
Überprüfen Sie mithilfe dieses CLI-Befehls die TCP-Optimierung für CLI, und sehen Sie sich die Zusammenfassung der optimierten Datenflüsse an:
BR11-CSR1k#show plat hardware qfp active feature sdwan datapath appqoe summary TCPOPT summary ---------------- optimized flows : 2 expired flows : 6033 matched flows : 0 divert pkts : 0 bypass pkts : 0 drop pkts : 0 inject pkts : 20959382 error pkts : 88
BR11-CSR1k#
Diese Ausgabe liefert detaillierte Informationen zu optimierten Flows:
BR11-CSR1k#show platform hardware qfp active flow fos-to-print all
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
GLOBAL CFT ~ Max Flows:2000000 Buckets Num:4000000
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Filtering parameters:
IP1 : ANY
Port1 : ANY
IP2 : ANY
Port2 : ANY
Vrf id : ANY
Application: ANY
TC id: ANY
DST Interface id: ANY
L3 protocol : IPV4/IPV6
L4 protocol : TCP/UDP/ICMP/ICMPV6
Flow type : ANY
Output parameters:
Print CFT internal data ? No
Only print summary ? No
Asymmetric : ANY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
keyID: SrcIP SrcPort DstIP DstPort L3-Protocol L4-Protocol vrfID
==================================================================
key #0: 192.168.25.254 26113 192.168.25.11 22 IPv4 TCP 3
key #1: 192.168.25.11 22 192.168.25.254 26113 IPv4 TCP 3
==================================================================
key #0: 192.168.25.254 26173 192.168.25.11 22 IPv4 TCP 3
key #1: 192.168.25.11 22 192.168.25.254 26173 IPv4 TCP 3
==================================================================
key #0: 10.212.1.10 52255 10.211.1.10 8089 IPv4 TCP 2
key #1: 10.211.1.10 8089 10.212.1.10 52255 IPv4 TCP 2
Data for FO with id: 2
-------------------------
appqoe: flow action DIVERT, svc_idx 0, divert pkt_cnt 1, bypass pkt_cnt 0, drop pkt_cnt 0, inject pkt_cnt 1, error pkt_cnt 0, ingress_intf Tunnel2, egress_intf GigabitEthernet3
==================================================================
key #0: 10.212.1.10 52254 10.211.1.10 8089 IPv4 TCP 2
key #1: 10.211.1.10 8089 10.212.1.10 52254 IPv4 TCP 2
Data for FO with id: 2
-------------------------
appqoe: flow action DIVERT, svc_idx 0, divert pkt_cnt 158, bypass pkt_cnt 0, drop pkt_cnt 0, inject pkt_cnt 243, error pkt_cnt 0, ingress_intf Tunnel2, egress_intf GigabitEthernet3
==================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Number of flows that passed filter: 4
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
FLOWS DUMP DONE.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
BR11-CSR1k#
Fehlerbehebung
Die folgende CLI hilft bei der Identifizierung von Problemen mit einem bestimmten TCP-Fluss.
Alle Beispiele stammen aus dem IOS XE SD-WAN 17.2.1-Image, das auf dem ISR 4431 ausgeführt wird.
- Ermitteln Sie die VRF-ID (entspricht nicht dem VRF-Namen). In diesem Fall wird in der unten stehenden Ausgabe angezeigt, dass Service VPN (VRF) 1 die VRF-ID 2 aufweist:
AppQoE_R2#show vrf detail
VRF 1 (VRF Id = 2); default RD 1:1; default VPNID <not set>
New CLI format, supports multiple address-families
Flags: 0x180C
Interfaces:
Gi0/0/3
…
- Finden Sie die passende Flow-ID für den Client im Service-VPN heraus. Hier sehen wir vier verschiedene Flows zwischen zwei Windows-Clients, die SMB Share über TCP-Port 445 verwenden:
AppQoE_R2#show sdwan appqoe flow vpn-id 2 client-ip 192.168.200.50
Optimized Flows
---------------
T:TCP, S:SSL, U:UTD
Flow ID VPN Source IP:Port Destination IP:Port Service
15731593842 2 192.168.200.50:49741 192.168.100.50:445 T
17364128987 2 192.168.200.50:49742 192.168.100.50:445 T
25184244867 2 192.168.200.50:49743 192.168.100.50:445 T
28305760200 2 192.168.200.50:49744 192.168.100.50:445 T
AppQoE_R2#
- Siehe TCP-Opt-Statistiken für den entsprechenden Fluss:
AppQoE_R2#show sdwan appqoe flow flow-id 15731593842
VPN: 2 APP: 0 [Client 192.168.200.50:49741 - Server 192.168.100.50:445]
TCP stats
---------
Client Bytes Received : 14114
Client Bytes Sent : 23342
Server Bytes Received : 23342
Server Bytes Sent : 14114
TCP Client Rx Pause : 0x0
TCP Server Rx Pause : 0x0
TCP Client Tx Pause : 0x0
TCP Server Tx Pause : 0x0
Client Flow Pause State : 0x0
Server Flow Pause State : 0x0
TCP Flow Bytes Consumed : 0
TCP Client Close Done : 0x0
TCP Server Close Done : 0x0
TCP Client FIN Rcvd : 0x0
TCP Server FIN Rcvd : 0x0
TCP Client RST Rcvd : 0x0
TCP Server RST Rcvd : 0x0
TCP FIN/RST Sent : 0x0
Flow Cleanup State : 0x0
TCP Flow Events
1. time:2196.550604 :: Event:TCPPROXY_EVT_FLOW_CREATED
2. time:2196.550655 :: Event:TCPPROXY_EVT_SYNCACHE_ADDED
3. time:2196.552366 :: Event:TCPPROXY_EVT_ACCEPT_DONE
4. time:2196.552665 :: Event:TCPPROXY_EVT_CONNECT_START
5. time:2196.554325 :: Event:TCPPROXY_EVT_CONNECT_DONE
6. time:2196.554370 :: Event:TCPPROXY_EVT_DATA_ENABLED_SUCCESS
AppQoE_R2#
- Siehe auch generische TCP Opt Statistiken, die auch 4 optimierte Flows zeigen:
AppQoE_R2#show tcpproxy statistics
==========================================================
TCP Proxy Statistics
==========================================================
Total Connections : 6
Max Concurrent Connections : 4
Flow Entries Created : 6
Flow Entries Deleted : 2
Current Flow Entries : 4
Current Connections : 4
Connections In Progress : 0
Failed Connections : 0
SYNCACHE Added : 6
SYNCACHE Not Added:NAT entry null : 0
SYNCACHE Not Added:Mrkd for Cleanup : 0
SYN purge enqueued : 0
SYN purge enqueue failed : 0
Other cleanup enqueued : 0
Other cleanup enqueue failed : 0
Stack Cleanup enqueued : 0
Stack Cleanup enqueue failed : 0
Proxy Cleanup enqueued : 2
Proxy Cleanup enqueue failed : 0
Cleanup Req watcher called : 135003
Total Flow Entries pending cleanup : 0
Total Cleanup done : 2
Num stack cb with null ctx : 0
Vpath Cleanup from nmrx-thread : 0
Vpath Cleanup from ev-thread : 2
Failed Conn already accepted conn : 0
SSL Init Failure : 0
Max Queue Length Work : 1
Current Queue Length Work : 0
Max Queue Length ISM : 0
Current Queue Length ISM : 0
Max Queue Length SC : 0
Current Queue Length SC : 0
Total Tx Enq Ign due to Conn Close : 0
Current Rx epoll : 8
Current Tx epoll : 0
Paused by TCP Tx Full : 0
Resumed by TCP Tx below threshold : 0
Paused by TCP Buffer Consumed : 0
Resumed by TCP Buffer Released : 0
SSL Pause Done : 0
SSL Resume Done : 0
SNORT Pause Done : 0
SNORT Resume Done : 0
EV SSL Pause Process : 0
EV SNORT Pause Process : 0
EV SSL/SNORT Resume Process : 0
Socket Pause Done : 0
Socket Resume Done : 0
SSL Pause Called : 0
SSL Resume Called : 0
Async Events Sent : 0
Async Events Processed : 0
Tx Async Events Sent : 369
Tx Async Events Recvd : 369
Tx Async Events Processed : 369
Failed Send : 0
TCP SSL Reset Initiated : 0
TCP SNORT Reset Initiated : 0
TCP FIN Received from clnt/svr : 0
TCP Reset Received from clnt/svr : 2
SSL FIN Received -> SC : 0
SSL Reset Received -> SC : 0
SC FIN Received -> SSL : 0
SC Reset Received -> SSL : 0
SSL FIN Received -> TCP : 0
SSL Reset Received -> TCP : 0
TCP FIN Processed : 0
TCP FIN Ignored FD Already Closed : 0
TCP Reset Processed : 4
SVC Reset Processed : 0
Flow Cleaned with Client Data : 0
Flow Cleaned with Server Data : 0
Buffers dropped in Tx socket close : 0
TCP 4k Allocated Buffers : 369
TCP 16k Allocated Buffers : 0
TCP 32k Allocated Buffers : 0
TCP 128k Allocated Buffers : 0
TCP Freed Buffers : 369
SSL Allocated Buffers : 0
SSL Freed Buffers : 0
TCP Received Buffers : 365
TCP to SSL Enqueued Buffers : 0
SSL to SVC Enqueued Buffers : 0
SVC to SSL Enqueued Buffers : 0
SSL to TCP Enqueued Buffers : 0
TCP Buffers Sent : 365
TCP Failed Buffers Allocations : 0
TCP Failed 16k Buffers Allocations : 0
TCP Failed 32k Buffers Allocations : 0
TCP Failed 128k Buffers Allocations : 0
SSL Failed Buffers Allocations : 0
Rx Sock Bytes Read < 512 : 335
Rx Sock Bytes Read < 1024 : 25
Rx Sock Bytes Read < 2048 : 5
Rx Sock Bytes Read < 4096 : 0
SSL Server Init : 0
Flows Dropped-Snort Gbl Health Yellow : 0
Flows Dropped-Snort Inst Health Yellow : 0
Flows Dropped-WCAPI Channel Health Yellow : 0
Total WCAPI snd flow create svc chain failed : 0
Total WCAPI send data svc chain failed : 0
Total WCAPI send close svc chain failed : 0
Total Tx Enqueue Failed : 0
Total Cleanup Flow Msg Add to wk_q Failed : 0
Total Cleanup Flow Msg Added to wk_q : 0
Total Cleanup Flow Msg Rcvd in wk_q : 0
Total Cleanup Flow Ignored, Already Done : 0
Total Cleanup SSL Msg Add to wk_q Failed : 0
Total UHI mmap : 24012
Total UHI munmap : 389
Total Enable Rx Enqueued : 0
Total Enable Rx Called : 0
Total Enable Rx Process Done : 0
Total Enable Rx Enqueue Failed : 0
Total Enable Rx Process Failed : 0
Total Enable Rx socket on Client Stack Close : 0
Total Enable Rx socket on Server Stack Close : 0
AppQoE_R2#
Verwenden von TCPOpt mit anderen AppQoE-/UTD-Funktionen ab 17.2
In Version 16.12 lautet der primäre Anwendungsfall für TCPOpt "Branch-to-Branch". Es gibt eine separate Umleitung zum TCP Proxy und eine separate Umleitung zum UTD Container in 16.12, deshalb funktioniert TCP Opt nicht zusammen mit Security in 16.12
In Version 17.2 wird ein zentralisierter Richtlinienpfad implementiert, der den Bedarf an TCP-Opt und Sicherheit erkennt.
Freigegebene Pakete werden nur einmal an die Serviceebene weitergeleitet (Auslösung).
Ab 17.2 sind verschiedene Strömungsoptionen möglich:
- Nur TCP Opt
- Nur UTD
- TCP Opt -> UTD
- TCP Opt -> SSL Proxy -> UTD
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
29-Jan-2020 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)