Configurer la fonctionnalité d'optimisation TCP sur Cisco IOS® ; Routeurs cEdge SD-WAN XE
Introduction
Ce document décrit la fonctionnalité d'optimisation TCP (Transmission Control Protocol) sur les routeurs SD-WAN Cisco IOS® XE, qui a été introduite dans la version 16.12 en août 2019. Les sujets abordés sont les conditions préalables, la description du problème, la solution, les différences dans les algorithmes d'optimisation TCP entre Viptela OS (vEdge) et XE SD-WAN (cEdge), la configuration, la vérification et la liste des documents connexes.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Les informations contenues dans ce document sont basées sur Cisco IOS® XE SD-WAN.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Problème
Une latence élevée sur une liaison WAN entre deux côtés SD-WAN entraîne une mauvaise performance des applications. Vous avez un trafic TCP critique qui doit être optimisé.
Solution
Lorsque vous utilisez la fonctionnalité d'optimisation TCP, vous améliorez le débit TCP moyen pour les flux TCP critiques entre deux sites SD-WAN.
Examinez la vue d'ensemble et les différences entre l'optimisation TCP sur la bande passante et l'aller-retour (BBR) goulot d'étranglement cEdge et vEdge (CUBIC)
L'algorithme de temps de propagation BBR rapide est utilisé dans l'implémentation SD-WAN XE (sur cEdge).
Viptela OS (vEdge) a un algorithme différent, plus ancien, appelé CUBIC.
CUBIC prend principalement en compte la perte de paquets et est largement mis en oeuvre sur différents systèmes d'exploitation client. Windows, Linux, MacOS et Android intègrent déjà CUBIC. Dans certains cas, lorsque d'anciens clients exécutent la pile TCP sans CUBIC, l'activation de l'optimisation TCP sur vEdge apporte des améliorations. L'un des exemples, où l'optimisation CUBIC TCP vEdge a bénéficié, concerne les sous-marins qui utilisent d'anciens hôtes clients et des liaisons WAN connaissant des retards/abandons importants. Notez que seuls vEdge 1000 et vEdge 2000 prennent en charge TCP CUBIC.
Le BBR est principalement axé sur le temps d'aller-retour et la latence. Pas en cas de perte de paquets. Si vous envoyez des paquets de l'Ouest américain à la côte Est ou même à l'Europe à travers l'Internet public, dans la majorité des cas, vous ne voyez aucune perte de paquets. L'Internet public est parfois trop performant en termes de perte de paquets. Mais ce que vous voyez est le délai/la latence. Et ce problème est résolu par BBR, qui a été développé par Google en 2016.
En bref, BBR modélise le réseau et examine chaque accusé de réception (ACK) et met à jour la bande passante maximale (BW) et le temps de parcours aller-retour minimum (RTT). Ensuite, l'envoi de contrôle est basé sur le modèle : Pour déterminer la bande passante maximale et la durée de vie minimale, caler près de la bande passante estimée et maintenir la bande passante en vol près de Bandwidth-Delay-Product (BDP). L'objectif principal est de garantir un débit élevé avec une petite file d'attente en goulot d'étranglement.
Cette diapositive de Mark Claypool montre la zone dans laquelle CUBIC opère :
BBR fonctionne dans un meilleur endroit, qui est montré dans cette diapositive également de Mark Claypool :
Si vous voulez en savoir plus sur l'algorithme BBR, vous pouvez trouver plusieurs publications sur BBR liées en haut de la page d'accueil de la liste de diffusion bbr-dev Ici.
En résumé :
| Plateforme et algorithme |
Paramètre d'entrée clé | Scénario |
| cEdge (XE SD-WAN) : BARRE | RTT/Latence | Trafic TCP critique entre deux sites SD-WAN |
| vEdge (Viptela OS) : CUBIQUE | La perte de paquets | Anciens clients sans aucune optimisation TCP |
Plates-formes SD-WAN XE prises en charge
Dans le logiciel XE SD-WAN version 16.12.1d, ces plates-formes cEdge prennent en charge l'optimisation TCP BBR :
- ISR4331
- ISR4351
- CSR1000v avec 8 vCPU et min. 8 Go de RAM
Mises en garde
- Toutes les plates-formes avec une mémoire DRAM inférieure à 8 Go ne sont actuellement pas prises en charge.
- Toutes les plates-formes avec 4 coeurs de données ou moins ne sont pas prises en charge actuellement.
- L'optimisation TCP ne prend pas en charge MTU 2000.
- Actuellement - aucune prise en charge du trafic IPv6.
- L'optimisation du trafic DIA vers un serveur BBR tiers n'est pas prise en charge. Vous devez disposer de routeurs SD-WAN cEdge des deux côtés.
- Dans le scénario de data center actuel, un seul noeud de service (SN) est pris en charge par noeud de contrôle (CN).
- Le cas d'utilisation combiné avec la sécurité (conteneur UTD) et l'optimisation TCP sur le même périphérique n'est pas pris en charge sur la version 16.12. À partir de la version 17.2, le cas d'utilisation combiné est pris en charge. L'ordre de fonctionnement est d'abord TCP Opt, puis Sécurité. Le paquet est envoyé au conteneur d'optimisation TCP, puis le service est enchaîné (pas de deuxième envoi) au conteneur de sécurité UTD. L'optimisation TCP est effectuée pour un flux complet, et non pour les premiers octets. Si l'UTD est abandonnée, la connexion complète est abandonnée.
Ce tableau récapitule les mises en garde par version et souligne les plates-formes matérielles prises en charge :
| Scénarios |
Scénarios : |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
Commentaires |
| Connexion de la filiale à Internet |
DIA |
Non |
Oui |
Oui |
Oui |
Dans 16.12.1, AppQoE FIA n'est pas activé sur l'interface Internet |
| SAAS |
Non |
Oui |
Oui |
Oui |
Dans 16.12.1, AppQoE FIA n'est pas activé sur l'interface Internet |
|
| Branche vers DC |
Routeur de périphérie unique |
Non |
Non |
Non |
Oui |
Nécessité de prendre en charge plusieurs SN |
| Routeurs de périphérie multiples |
Non |
Non |
Non |
Oui |
Symétrie de flux ou synchronisation de flux Appnav requise. 16.12.1 non testé avec |
|
| Plusieurs SN |
Non |
Non |
Non |
Oui |
Amélioration de vManage pour accepter plusieurs IP SN |
|
| De filiale à filiale |
Réseau à maillage global (Spoke-to-Spoke) |
Oui |
Oui |
Oui |
Oui |
|
| hub-and-spoke (Spoke-Hub-Spoke) |
Non |
Oui |
Oui |
Oui |
||
| Support BBR |
Option TCP avec BBR |
Partiel | Partiel |
Complet |
Complet |
|
| Plates-formes |
Plates-formes prises en charge |
Uniquement 4300 et CSR |
Tous sauf ISR1100 |
tout |
tout |
Configurer
Un concept de SN et CN est utilisé pour l'optimisation TCP :
- SN est un démon, qui est responsable de l'optimisation réelle des flux TCP.
- Le CN est connu sous le nom de contrôleur AppNav et est responsable de la sélection du trafic et du transport vers/depuis le SN.
Les noeuds SN et CN peuvent être exécutés sur le même routeur ou séparés en tant que noeuds différents.
Il existe deux cas d'utilisation principaux :
- Exemple d'utilisation de filiale avec SN et CN exécutés sur le même routeur ISR4k.
- Exemple d'utilisation de centre de données, où CN s'exécute sur ASR1k et SN s'exécute sur un routeur virtuel CSR1000v distinct.
Les deux cas d'utilisation sont décrits dans cette section.
Exemple d’utilisation 1 : configuration de l’optimisation TCP sur une filiale (tout en un cEdge)
Cette image présente l'architecture interne globale d'une seule option autonome dans une filiale :
Étape 1. Pour configurer l'optimisation TCP, vous devez créer un modèle de fonction pour l'optimisation TCP dans vManage. Accédez à Configuration > Templates > Feature Templates > Other Templates > AppQoE comme indiqué dans l'image.
Étape 2. Ajoutez le modèle de fonctionnalité AppQoE au modèle de périphérique approprié sous Modèles supplémentaires :
Voici l'aperçu CLI de la configuration du modèle :
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
!
Étape 3 : création d’une politique de données centralisée avec la définition du trafic TCP intéressant pour l’optimisation
À titre d'exemple ; cette stratégie de données correspond au préfixe IP 10.0.0.0/8, qui inclut les adresses source et de destination, et permet l'optimisation TCP pour celui-ci :
Voici l'aperçu CLI de la politique vSmart :
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
!
!
Exemple d’utilisation 2 : configuration de l’optimisation TCP dans le data center avec un SN externe
La principale différence par rapport au cas d'utilisation d'une succursale est la séparation physique du SN et du CN. Dans le cas d'une filiale tout-en-un, la connectivité s'effectue au sein du même routeur à l'aide de l'interface de groupe de ports virtuels. Dans le cas d'utilisation d'un data center, il existe un tunnel encapsulé GRE AppNav entre ASR1k agissant comme CN et CSR1k externe fonctionnant comme SN. Il n'est pas nécessaire de disposer d'une liaison dédiée ou d'une interconnexion entre le CN et le SN externe, une simple accessibilité IP suffit.
Il existe un tunnel AppNav (GRE) par numéro de série. Pour une utilisation ultérieure, lorsque plusieurs numéros de série sont pris en charge, il est recommandé d'utiliser le sous-réseau /28 pour le réseau entre CN et SN.
Deux cartes réseau sont recommandées sur un CSR1k agissant en tant que numéro de série. Une deuxième carte réseau pour le contrôleur SD-WAN est nécessaire si le numéro de série doit être configuré/géré par vManage. Si le SN doit être configuré/géré manuellement, la deuxième carte réseau est facultative.
Cette image montre le noeud de service ASR1k de centre de données exécuté en tant que CN et CSR1kv en tant que SN de noeud de service :
La topologie de l'exemple d'utilisation du data center avec ASR1k et CSR1k externe est présentée ici :
Ce modèle de fonctionnalité AppQoE affiche ASR1k configuré en tant que contrôleur :
CSR1k configuré en tant que noeud de service externe s'affiche ici :
Cas de basculement
Basculement dans l'exemple d'utilisation du data center avec CSR1k agissant en tant que SN, en cas de défaillance externe de CSR1k :
- Les sessions TCP existantes sont perdues car la session TCP sur SN est interrompue.
- Les nouvelles sessions TCP sont envoyées à la destination finale, mais le trafic TCP n’est pas optimisé (contournement).
- Aucun trou noir pour le trafic intéressant en cas de défaillance du SN.
La détection de basculement est basée sur le battement de coeur AppNav, qui est de 1 battement par seconde. Après 3 ou 4 erreurs, le tunnel est déclaré hors service.
Le basculement dans le cas d'utilisation d'une succursale est similaire : en cas de défaillance du numéro de série, le trafic est envoyé non optimisé directement à la destination.
Vérifier
Utilisez cette section pour confirmer que votre configuration fonctionne correctement.
Vérifiez l'optimisation TCP sur CLI à l'aide de cette commande CLI et consultez le résumé des flux optimisés :
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#
Cette sortie donne des informations détaillées sur les flux optimisés :
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#
Dépannage
L’interface de ligne de commande suivante permet d’identifier les problèmes liés à un flux TCP spécifique.
Tous les exemples proviennent de l'image SD-WAN 17.2.1 d'IOS XE exécutée sur ISR4431.
- Recherchez l'ID VRF (qui n'est pas égal au nom VRF). Dans ce cas, nous voyons dans le résultat ci-dessous que le service VPN (VRF) 1 a l'ID VRF 2 :
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
…
- Trouvez l'ID de flux approprié pour le client dans le VPN de service - nous voyons ici 4 flux différents entre deux clients Windows utilisant le partage SMB sur le port TCP 445 :
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#
- Voir TCP Opt stats pour le flux approprié :
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#
- Voir aussi statistiques d'option TCP génériques, qui montrent également 4 flux optimisés :
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#
Utilisation de TCPOpt avec d'autres fonctionnalités AppQoE / UTD à partir de 17.2
Dans la version 16.12, l'exemple d'utilisation principal de TCPOpt est Branch-to-Branch. Il y a une redirection séparée vers le proxy TCP et une redirection séparée vers le conteneur UTD dans 16.12, c'est pourquoi TCP Opt ne fonctionne pas avec la sécurité dans 16.12
Dans la version 17.2, un chemin de stratégie centralisé est mis en oeuvre, ce qui permet de détecter la nécessité de TCP Opt et Security.
Les paquets associés sont redirigés vers le plan de service (pointé) une seule fois.
Différentes options de flux sont possibles à partir de la version 17.2 :
- Option TCP uniquement
- UTD uniquement
- Option TCP -> UTD
- Option TCP -> Proxy SSL -> UTD
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
29-Jan-2020 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)