Configurare la funzione di ottimizzazione TCP su Cisco IOS® Router XE SD-WAN cEdge
Sommario
Introduzione
Questo documento descrive la funzione di ottimizzazione TCP (Transmission Control Protocol) sui router Cisco IOS® XE SD-WAN, introdotta nella versione 16.12 ad agosto 2019. Gli argomenti trattati sono: prerequisiti, descrizione del problema, soluzione, differenze negli algoritmi di ottimizzazione TCP tra Viptela OS (vEdge) e XE SD-WAN (cEdge), configurazione, verifica ed elenco dei documenti correlati.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il riferimento delle informazioni contenute in questo documento è Cisco IOS® XE SD-WAN.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Problema
L'alta latenza su un collegamento WAN tra due lati SD-WAN causa prestazioni errate delle applicazioni. È necessario ottimizzare il traffico TCP critico.
Soluzione
Quando si utilizza la funzione di ottimizzazione TCP, si migliora il throughput TCP medio per i flussi TCP critici tra due siti SD-WAN.
Panoramica e differenze tra l'ottimizzazione TCP su cEdge Bottleneck Bandwidth e Round-trip (BBR) e vEdge (CUBIC)
L'algoritmo per il tempo di propagazione Fast BBR viene utilizzato nell'implementazione XE SD-WAN (su cEdge).
Viptela OS (vEdge) ha un algoritmo diverso, più vecchio, chiamato CUBIC.
CUBIC prende in considerazione principalmente la perdita di pacchetti ed è ampiamente implementato nei diversi sistemi operativi client. Windows, Linux, MacOS, Android hanno già CUBIC incorporato. In alcuni casi, se sui vecchi client viene eseguito lo stack TCP senza CUBIC, l'abilitazione dell'ottimizzazione TCP su vEdge comporta miglioramenti. Uno degli esempi, in cui l'ottimizzazione TCP CUBIC di vEdge ha tratto vantaggio, è quello dei sottomarini che utilizzano host client e collegamenti WAN obsoleti che subiscono ritardi/perdite significativi. Si noti che solo vEdge 1000 e vEdge 2000 supportano TCP CUBIC.
La BBR è incentrata principalmente sul tempo di andata e ritorno e sulla latenza. Non sulla perdita di pacchetti. Se si inviano pacchetti dagli Stati Uniti occidentali verso la costa orientale o persino verso l'Europa attraverso il web pubblico, nella maggior parte dei casi non si vedono perdite di pacchetti. Internet pubblico a volte è troppo buono in termini di perdita di pacchetti. Ma ciò che vedete è ritardo/latenza. E questo problema è affrontato da BBR, che è stato sviluppato da Google nel 2016.
In poche parole, BBR modella la rete e analizza ogni conferma (ACK) e aggiorna la larghezza di banda massima (BW) e il tempo di andata e ritorno minimo (RTT). Quindi l'invio del controllo è basato sul modello: sonda per max BW e min RTT, passo vicino a stima BW e mantenere l'inattività vicino a Bandwidth-Delay-Product (BDP). L'obiettivo principale è quello di garantire un throughput elevato con una coda di colli di bottiglia di piccole dimensioni.
Questa diapositiva di Mark Claypool mostra l'area in cui opera CUBIC:
BBR opera in una posizione migliore, come illustrato in questa diapositiva anche da Mark Claypool:
Per ulteriori informazioni sull'algoritmo BBR, fare clic qui nella parte superiore della home page della mailing list bbr-dev, sono disponibili diverse pubblicazioni su BBR.
In sintesi:
| Piattaforma e algoritmo |
Parametro di input chiave | Scenario d'uso |
| cEdge (XE SD-WAN): BBR | RTT/Latenza | Traffico TCP critico tra due siti SD-WAN |
| vEdge (Viptela OS): POSTAZIONE UFFICIO | La perdita di pacchetti | Vecchi client senza ottimizzazione TCP |
Piattaforme XE SD-WAN supportate
Nel software XE SD-WAN versione 16.12.1d, queste piattaforme cEdge supportano l'ottimizzazione TCP BBR:
- ISR 4331
- ISR 4351
- CSR1000v con 8 vCPU e minimo 8 GB di RAM
Avvertenze
- Al momento non sono supportate tutte le piattaforme con memoria DRAM inferiore a 8 GB di RAM.
- Al momento non sono supportate tutte le piattaforme con 4 o meno core di dati.
- L'ottimizzazione TCP non supporta MTU 2000.
- Attualmente non è supportato il traffico IPv6.
- Ottimizzazione per il traffico DIA verso un server BBR di terze parti non supportata. È necessario avere un router cEdge SD-WAN su entrambi i lati.
- Nello scenario attuale del centro dati, è supportato un solo nodo di servizio (SN) per ogni nodo di controllo (CN).
- L'uso combinato di Use Case con protezione (contenitore UTD) e Ottimizzazione TCP sullo stesso dispositivo non è supportato nella versione 16.12. A partire dalla versione 17.2, lo Use Case combinato è supportato. L'ordine delle operazioni è TCP Opt, quindi Security. Il pacchetto verrà indirizzato al contenitore di ottimizzazione TCP e quindi concatenato (senza secondi punt) al contenitore di sicurezza UTD. L'ottimizzazione TCP viene eseguita per il flusso completo, non per i primi byte. Se UTD viene interrotto, la connessione completa viene interrotta.
La tabella seguente riepiloga le avvertenze per ogni release e sottolinea le piattaforme hardware supportate:
| Scenari |
Scenari d'uso |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
Commenti |
| Branch-to-Internet |
DIA |
No |
Sì |
Sì |
Sì |
In 16.12.1 AppQoE FIA non è abilitato sull'interfaccia Internet |
| SAAS |
No |
Sì |
Sì |
Sì |
In 16.12.1 AppQoE FIA non è abilitato sull'interfaccia Internet |
|
| Branch-to-DC |
Single Edge Router |
No |
No |
No |
Sì |
Necessità di supportare più SN |
| Router per edge multipli |
No |
No |
No |
Sì |
È necessaria la simmetria di flusso o la sincronizzazione di flusso di Appnav. 16.12.1 non testato con |
|
| Più SN |
No |
No |
No |
Sì |
Miglioramento di vManage per accettare più IP SN |
|
| Filiale a filiale |
Rete Mesh Completa (Spoke-to-spoke) |
Sì |
Sì |
Sì |
Sì |
|
| Hub e Spoke (Spoke-Hub-Spoke) |
No |
Sì |
Sì |
Sì |
||
| Supporto BBR |
TCP Opt con BBR |
Parziale | Parziale |
Full |
Full |
|
| Piattaforme |
Piattaforme supportate |
Solo 4300 e CSR |
Tutti tranne ISR1100 |
Tutto |
Tutto |
Configurazione
Per l'ottimizzazione TCP vengono utilizzati i concetti di SN e CN:
- SN è un daemon che è responsabile dell'ottimizzazione effettiva dei flussi TCP.
- CN è noto come AppNav Controller ed è responsabile della selezione del traffico e del trasporto da/verso SN.
SN e CN possono essere eseguiti sullo stesso router o separati come nodi diversi.
Esistono due casi di utilizzo principali:
- Caso di utilizzo per filiali con SN e CN in esecuzione sullo stesso router ISR4k.
- Scenario di utilizzo del data center, in cui CN viene eseguito su ASR1k e SN su un router virtuale CSR1000v separato.
In questa sezione vengono descritti entrambi i casi di utilizzo.
Caso di utilizzo 1. Configurazione dell'ottimizzazione TCP su un branch (tutto in un unico cEdge)
L'immagine mostra l'architettura interna complessiva per una singola opzione standalone in una filiale:
Passaggio 1. Per configurare l'ottimizzazione TCP, è necessario creare un modello di funzionalità per l'ottimizzazione TCP in vManage. Selezionare Configurazione > Modelli > Modelli funzionalità > Altri modelli > AppQoE come mostrato nell'immagine.
Passaggio 2. Aggiungere il modello della funzionalità AppQoE al modello di dispositivo appropriato in Modelli aggiuntivi:
Ecco l'anteprima CLI della configurazione del modello:
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
!
Passaggio 3. Creare una policy dei dati centralizzata con la definizione del traffico TCP interessante per l'ottimizzazione.
A titolo di esempio: questo criterio dei dati corrisponde al prefisso IP 10.0.0.0/8, che include gli indirizzi di origine e di destinazione, e abilita l'ottimizzazione TCP:
Di seguito è riportata l'anteprima CLI di vSmart Policy:
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
!
!
Caso di utilizzo 2. Configurazione dell'ottimizzazione TCP nel data center con un numero di serie esterno
La principale differenza rispetto al caso di utilizzo delle filiali è la separazione fisica tra SN e CN. Nel caso di utilizzo di un ramo all-in-one, la connettività viene effettuata all'interno dello stesso router utilizzando l'interfaccia Virtual Port Group. Nel caso di utilizzo del centro dati, è presente un tunnel incapsulato GRE di AppNav tra ASR1k che funge da CN e CSR1k esterno che funziona come SN. Non è necessario un collegamento dedicato o una connessione incrociata tra CN e SN esterno, è sufficiente una semplice raggiungibilità IP.
Esiste un tunnel AppNav (GRE) per SN. Per un utilizzo futuro, quando sono supportati più SN, si consiglia di utilizzare la subnet /28 per la rete tra CN ed SN.
Si consigliano due schede NIC su un CSR1k che funge da SN. Se il SN deve essere configurato/gestito da vManage, è necessaria una seconda scheda NIC per il controller SD-WAN. Se il numero di serie deve essere configurato/gestito manualmente, la seconda NIC è opzionale.
In questa immagine viene mostrato il Data Center ASR1k in esecuzione come CN e CSR1kv come numero di serie del nodo di servizio:
Di seguito è riportata la topologia dello scenario di utilizzo del centro dati con ASR1k e CSR1k esterno:
In questo modello di funzionalità AppQoE viene visualizzato ASR1k configurato come controller:
Di seguito è illustrato CSR1k configurato come Service Node esterno:
Caso di failover
Failover nello scenario di utilizzo del centro dati con CSR1k che funge da SN, in caso di guasto CSR1k esterno:
- Le sessioni TCP già esistenti vengono perse perché la sessione TCP su SN viene terminata.
- Le nuove sessioni TCP vengono inviate alla destinazione finale, ma il traffico TCP non è ottimizzato (bypass).
- Nessuna blackholing per il traffico interessante in caso di guasto della rete SAN.
Il rilevamento del failover si basa sull'heartbeat AppNav, che è di 1 beat al secondo. Dopo 3 o 4 errori, il tunnel viene dichiarato inattivo.
Il failover nello scenario di utilizzo della filiale è simile: in caso di guasto del server di rete, il traffico viene inviato non ottimizzato direttamente alla destinazione.
Verifica
Fare riferimento a questa sezione per verificare che la configurazione funzioni correttamente.
Verificare l'ottimizzazione TCP sulla CLI con questo comando CLI e vedere il riepilogo dei flussi ottimizzati:
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#
Questo output fornisce informazioni dettagliate sui flussi ottimizzati:
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#
Risoluzione dei problemi
La seguente CLI consente di identificare i problemi relativi a un flusso TCP specifico.
Tutti gli esempi sono stati tratti da un'immagine IOS XE SD-WAN 17.2.1 in esecuzione su ISR4431.
- Individuare l'ID VRF (diverso dal nome VRF). In questo caso, nell'output seguente, il servizio VPN (VRF) 1 ha 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
…
- Individuare l'ID di flusso appropriato per il client nella vpn del servizio. In questa pagina vengono visualizzati 4 diversi flussi tra due client Windows che utilizzano la condivisione SMB sulla porta 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#
- Per il flusso appropriato, vedere le statistiche dei valori TCP opzionali:
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#
- Vedere anche statistiche generiche TCP Opt, che mostrano anche 4 flussi ottimizzati:
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#
Utilizzo di TCPOpt con altre funzionalità AppQoE/UTD a partire dalla versione 17.2
Nella versione 16.12, lo scenario di utilizzo principale per TCPOpt è Branch-to-Branch. Esiste un reindirizzamento separato al proxy TCP e un reindirizzamento separato al contenitore UTD nella versione 16.12, ecco perché TCP Opt non funziona insieme alla sicurezza nella versione 16.12
Nella versione 17.2 viene implementato un percorso di policy centralizzato, che rileverà la necessità di TCP Opt e Security.
I pacchetti correlati verranno reindirizzati al piano di servizio (punted) una sola volta.
A partire dalla versione 17.2 sono possibili diverse opzioni di flusso:
- Solo TCP Opt
- Solo UTD
- TCP Opt -> UTD
- TCP Opt -> Proxy SSL -> UTD
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
29-Jan-2020 |
Versione iniziale |
Feedback