Configureren van TCP-optimalisatiefunctie op Cisco IOS® XE SD-WAN cEdge-routers
Inhoud
Inleiding
Dit document beschrijft de Optimalisatiefunctie voor Transmission Control Protocol (TCP) op Cisco IOS® XE SD-WAN routers, die in augustus 2019 werd geïntroduceerd in versie 16.12. De behandelde onderwerpen zijn vereisten, probleembeschrijving, oplossing, de verschillen in TCP-optimalisatiealgoritmen tussen Viptela OS (vEdge) en XE SD-WAN (cEdge), configuratie, verificatie en lijst van gerelateerde documenten.
Voorwaarden
Vereisten
Er zijn geen specifieke vereisten van toepassing op dit document.
Gebruikte componenten
De informatie in dit document is gebaseerd op Cisco IOS® XE SD-WAN.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Probleem
Hoge latentie op een WAN-verbinding tussen twee SD-WAN-kanten veroorzaakt slechte toepassingsprestaties. U hebt kritisch TCP-verkeer, dat moet worden geoptimaliseerd.
Oplossing
Wanneer u de functie voor TCP-optimalisatie gebruikt, verbetert u de gemiddelde TCP-doorvoersnelheid voor kritische TCP-stromen tussen twee SD-WAN-sites.
Bekijk het overzicht en de verschillen tussen TCP-optimalisatie op cEdge Bottleneck Bandwidth en Round-trip (BBR) en vEdge (CUBIC)
Het snelle BBR-propagatietijdalgoritme wordt gebruikt in de XE SD-WAN implementatie (op cEdge).
Viptela OS (vEdge) heeft een ander, ouder algoritme, genaamd CUBIC.
CUBIC houdt voornamelijk rekening met pakketverlies en wordt op grote schaal geïmplementeerd op verschillende client-besturingssystemen. Windows, Linux, MacOS en Android hebben CUBIC al ingebouwd. In sommige gevallen, waar u oude clients met TCP stack zonder CUBIC, waardoor TCP optimalisatie op vEdge mogelijk maakt, brengt verbeteringen. Een van de voorbeelden waar vEdge TCP/CUBIC-optimalisatie heeft geprofiteerd, is op onderzeeërs die gebruik maken van oude client hosts en WAN-links die aanzienlijke vertragingen/dalingen ondervinden. Let op dat alleen vEdge 1000 en vEdge 2000 TCP/CUBIC ondersteunen.
BBR is vooral gericht op ronde-trip tijd en latentie. Niet met pakketverlies. Als je pakketten van US West naar de oostkust of zelfs naar Europa stuurt via het openbare internet, zie je in de meeste gevallen geen pakketverlies. Het openbaar internet is soms te goed in termen van pakketverlies. Maar wat je ziet is vertraging/latentie. Dit probleem wordt aangepakt door BBR, dat in 2016 door Google werd ontwikkeld.
In een notendop, BBR modelleert het netwerk en bekijkt elke erkenning (ACK) en werkt max Bandbreedte (BW) en minimum Ronde Reistijd (RTT) bij. Dan controle het verzenden is gebaseerd op model: sonde voor max. BW en min. RTT, tempo dichtbij schatting BW en houden inflight dichtbij Bandwidth-Delay-Product (BDP). Het belangrijkste doel is om een hoge doorvoersnelheid te garanderen met een kleine knelpuntwachtrij.
Op deze dia van Mark Claypool staat het gebied waar CUBIC werkt:
BBR werkt op een betere plaats, zoals ook te zien is op deze dia van Mark Claypool:
Als u meer over het BBR-algoritme wilt lezen, vindt u verschillende publicaties over BBR die zijn gekoppeld bovenaan de bbr-dev mailinglijst startpagina Hier.
Samenvattend:
| Platform en algoritme |
Belangrijke inputparameter | Use case |
| cEdge (XE SD-WAN): BBR | RTT/Latency | Kritisch TCP-verkeer tussen twee SD-WAN-sites |
| vEdge (Viptela OS): KUBICP | Pakketverlies | Oude clients zonder TCP-optimalisatie |
Ondersteunde XE SD-WAN platforms
In de XE SD-WAN SW release 16.12.1d ondersteunen deze cEdge-platforms TCP-optimalisatie BBR:
- ISR-4331
- ISR 4351 router
- CSR1000v met 8 vCPU’s en min. 8 GB RAM
Voorbehouden
- Alle platforms met DRAM van minder dan 8 GB RAM worden momenteel niet ondersteund.
- Alle platforms met vier of minder datakernen worden momenteel niet ondersteund.
- TCP-optimalisatie ondersteunt MTU 2000 niet.
- Momenteel - geen ondersteuning voor IPv6-verkeer.
- Optimalisatie voor DIA-verkeer naar een BBR-server van derden wordt niet ondersteund. Je hebt aan beide kanten een cEdge SD-WAN router nodig.
- In het datacenterscenario wordt momenteel slechts één Service Node (SN) ondersteund per één Control Node (CN).
- Gecombineerd gebruik met security (UTD-container) en TCP-optimalisatie op hetzelfde apparaat wordt niet ondersteund op 16.12 release. Vanaf 17.2 wordt het gecombineerde gebruik ondersteund. De volgorde van de werking is eerst TCP Opt en vervolgens Security. Het pakket zal worden gestraft aan TCP Optimalisatiecontainer en dan de dienst ketend (geen tweede punt) aan UTD veiligheidscontainer. TCP-optimalisatie wordt uitgevoerd voor volledige flow, niet voor de eerste paar bytes. Als UTD zakt, wordt de volledige verbinding verbroken.
In deze tabel worden de voorbehouden per release samengevat en worden de ondersteunde hardwareplatforms onderstreept:
| Scenario's |
Use cases |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
Opmerkingen |
| Vestigings-aan-internet |
DIA |
Nee |
Ja |
Ja |
Ja |
In 16.12.1 wordt AppQoE FIA niet ingeschakeld op de internetinterface |
| SAAS |
Nee |
Ja |
Ja |
Ja |
In 16.12.1 wordt AppQoE FIA niet ingeschakeld op de internetinterface |
|
| Vestigings-aan-DC |
Single Edge-router |
Nee |
Nee |
Nee |
Ja |
Ondersteuning van meerdere SN nodig |
| Meervoudige Edge-routers |
Nee |
Nee |
Nee |
Ja |
Behoefte aan stroomsymmetrie of Appnav-stroomsynchronisatie. 16.12.1 niet getest met |
|
| Meervoudige SN’s |
Nee |
Nee |
Nee |
Ja |
Verbetering in vManager om meerdere SN IP’s te accepteren |
|
| Vestigings-aan-vertakking |
Volledig mesh-netwerk (Gesproken) |
Ja |
Ja |
Ja |
Ja |
|
| Hub-and-Spoke (Spoke-Hub-Spoke) |
Nee |
Ja |
Ja |
Ja |
||
| Ondersteuning van BBR |
TCP kiezen met BBR |
gedeeltelijk | gedeeltelijk |
Full |
Full |
|
| Platforms |
Ondersteunde platforms |
Alleen 4300 en CSR |
Alles, behalve ISR1100 |
Alle |
Alle |
Configureren
Een concept van SN en CN wordt gebruikt voor TCP-optimalisatie:
- SN is een daemon, die verantwoordelijk is voor de daadwerkelijke optimalisatie van TCP-stromen.
- CN staat bekend als AppNav Controller en is verantwoordelijk voor verkeersselectie en transport van/naar SN.
SN en CN kunnen op dezelfde router worden uitgevoerd of als verschillende knooppunten worden gescheiden.
Er zijn twee belangrijke gevallen van gebruik:
- Verdeel het gebruiksgeval met SN en CN die op de zelfde router ISR4k lopen.
- Data Center use case, waarbij CN draait op ASR1k en SN draait op een aparte CSR1000v virtuele router.
Beide gevallen van gebruik worden in deze rubriek beschreven.
Use Case 1. Configureer TCP-optimalisatie op een branch (alles in één cEdge)
Dit beeld toont de algemene interne architectuur voor één enkele standalone optie bij een tak:
Stap 1. Om TCP-optimalisatie te kunnen configureren, moet u een functiesjabloon voor TCP-optimalisatie in vManager maken. Navigeer naar Configuration > Templates > Feature Templates > Andere sjablonen > AppQoE zoals in de afbeelding.
Stap 2. Voeg de AppQoE-functiesjabloon toe aan de juiste apparaatsjabloon onder Aanvullende sjablonen:
Hier is de CLI-voorvertoning van de Sjabloonconfiguratie:
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
!
Stap 3. Maak een gecentraliseerd gegevensbeleid met de definitie van het interessante TCP-verkeer voor optimalisatie.
Bij wijze van voorbeeld; dit gegevensbeleid past IP prefix 10.0.0.0/8, dat bron en bestemmingsadressen omvat, aan en laat de optimalisering van TCP voor het toe:
Hier is de CLI preview van het 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
!
!
Use Case 2. Configureer TCP-optimalisatie in datacenter met een extern SN
Het belangrijkste verschil met het geval van branchegebruik is de fysieke scheiding van SN en CN. In de all-in-one branch use case wordt de connectiviteit gedaan binnen dezelfde router met behulp van Virtual Port Group Interface. In het datacentergebruiksgeval is er een AppNav GRE-ingekapselde tunnel tussen ASR1k als CN en externe CSR1k als SN. Er is geen behoefte aan een specifieke link of cross-connect tussen CN en externe SN, eenvoudige IP bereikbaarheid is genoeg.
Er is één AppNav (GRE) tunnel per SN. Voor toekomstig gebruik, waar meerdere SNs worden ondersteund, is het aanbevolen om /28-subnetverbinding te gebruiken voor het netwerk tussen CN en SN.
Twee NIC's worden aanbevolen voor een CSR1k die fungeert als SN. 2e NIC voor SD-WAN controller is nodig als SN moet worden geconfigureerd / beheerd door vManager. Als SN handmatig wordt geconfigureerd/beheerd, is 2e NIC optioneel.
Dit beeld toont datacenter ASR1k dat draait als CN en CSR1kv als Service Node SN:
De topologie voor de datacentergebruikscase met ASR1k en extern CSR1k wordt hier weergegeven:
Deze AppQoE-functiesjabloon toont ASR1k geconfigureerd als controller:
CSR1k geconfigureerd als extern serviceknooppunt wordt hier weergegeven:
failover-case
failover in de datacentergebruikscase met CSR1k als SN, in het geval van een externe CSR1k-storing:
- TCP-sessies die al bestaan, gaan verloren omdat de TCP-sessie op SN is beëindigd.
- Nieuwe TCP-sessies worden naar de eindbestemming verzonden, maar TCP-verkeer wordt niet geoptimaliseerd (omzeilen).
- Geen versperring voor interessant verkeer in het geval van SN falen.
De detectie van failover is gebaseerd op AppNav-hartslag, die 1 slag per seconde is. Na 3 of 4 fouten, wordt de tunnel zoals beneden verklaard.
failover in de branch use case is vergelijkbaar - in het geval van SN-fout wordt het verkeer niet-geoptimaliseerd rechtstreeks naar de bestemming gestuurd.
Verifiëren
Gebruik deze sectie om te controleren of uw configuratie goed werkt.
Controleer TCP-optimalisatie op CLI met het gebruik van deze CLI-opdracht en zie de samenvatting van de geoptimaliseerde stromen:
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#
Deze output geeft gedetailleerde informatie over geoptimaliseerde stromen:
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#
Problemen oplossen
De volgende CLI helpt problemen met een specifieke TCP-stroom te identificeren.
Alle voorbeelden zijn afkomstig van een IOS XE SD-WAN 17.2.1 afbeelding die op ISR4431 draait.
- Ontdek de VRF-id (niet gelijk aan de VRF-naam). In dit geval zien we in de onderstaande output dat de VRF-service (VRF) 1 de VRF-id 2 heeft:
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
…
- Ontdek de juiste flow-id voor de client in de service-VPN - we zien hier 4 verschillende stromen tussen twee Windows-clients met SMB-aandeel via TCP-poort 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#
- Zie de TCP-opstartstatus voor de juiste stroom:
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#
- Zie ook generieke TCP Opt stats, die ook 4 geoptimaliseerde stromen tonen:
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#
TCPOpt gebruiken met andere AppQoE / UTD-functies vanaf 17.2
In 16.12 is de primaire gebruikscase voor TCPOpt Branch-to-Branch. Er is een aparte omleiding naar TCP Proxy en een aparte omleiding naar UTD-container in 16.12, daarom werkt TCP Opt niet samen met Security in 16.12
In 17.2 wordt een gecentraliseerd beleidspad geïmplementeerd, dat de noodzaak van TCP-keuze en -beveiliging zal detecteren.
Verwante pakketten worden slechts één keer naar het servicevliegtuig (geleegd) doorgestuurd.
Verschillende stromingsopties zijn mogelijk vanaf 17.2:
- Alleen TCP-optie
- Alleen UTD
- TCP kiezen -> UTD
- TCP-optie -> SSL-proxy -> UTD
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
29-Jan-2020 |
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)