Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Problem

Lösung

Unterstützte XE SD-WAN-Plattformen

Hinweise

Konfigurieren

Anwendungsfall 1. Konfigurieren der TCP-Optimierung in einer Außenstelle (alles in einem cEdge)

Anwendungsfall 2. Konfigurieren der TCP-Optimierung im Rechenzentrum mit einem externen SN

Failover-Fall

Überprüfung

Fehlerbehebung

Zugehörige Informationen

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 verstehen.

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-Laufzeitalgorithmus 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 senden, 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.

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 cEdge SD-WAN-Router.

- Im Rechenzentrumsszenario wird derzeit nur ein Service Node (SN) pro Control Node (CN) unterstützt.

- Derzeit wird kein kombinierter Anwendungsfall mit Sicherheit (UTD-Container) und TCP-Optimierung auf demselben Gerät unterstützt.

Anmerkung: ASR1k unterstützt derzeit keine TCP-Optimierung. Es gibt jedoch eine Lösung für ASR1k, bei der der ASR1k TCP-Datenverkehr über den AppNav-Tunnel (GRE-gekapselt) an einen externen CSR1kv zur Optimierung sendet. Derzeit (Februar 2020) wird nur ein CSR1k als externer Serviceknoten unterstützt. Dies wird später im Konfigurationsabschnitt beschrieben.

In dieser Tabelle werden die Probleme pro Version zusammengefasst und die unterstützten Hardwareplattformen hervorgehoben:

Szenarien

Anwendungsbeispiele

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

EFT

Ja

Unterstützung mehrerer SN erforderlich

Router mit mehreren Edges

Nein

Nein

EFT

Ja

Flow-Symmetrie oder AppNav-Flow-Synchronisierung erforderlich. 16.12.1 nicht getestet mit

Mehrere SNs

Nein

Nein

EFT

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:

1. Anwendungsfall in Zweigstellen mit SN und CN auf demselben ISR4k-Router

2. 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 als CN und CSR1kv als Service Node SN:

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 mit CSR1k als SN, 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

Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.

Zugehörige Informationen

- Versionshinweise für Cisco IOS XE SD-WAN Version 16.12.x

- Cisco SD-WAN-Versionen 19.1, 19.2 - Konfigurieren des TCP-Optimierungsleitfadens

- Cisco SD-WAN Konfigurieren der TCP-Optimierung für vEdge

- Technischer Support und Dokumentation für Cisco Systeme