Configurar la función de optimización de TCP en Cisco IOS® Routers periféricos XE SD-WAN
Contenido
Introducción
Este documento describe la función de optimización del Protocolo de control de transmisión (TCP) en los routers Cisco IOS® XE SD-WAN, que se introdujo en la versión 16.12 en agosto de 2019. Los temas tratados son prerrequisitos, descripción del problema, solución, las diferencias en los algoritmos de optimización TCP entre Viptela OS (vEdge) y XE SD-WAN (cEdge), configuración, verificación y lista de documentos relacionados.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
La información de este documento se basa en Cisco IOS® XE SD-WAN.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Problema
La alta latencia en un enlace WAN entre dos lados de la SD-WAN provoca un mal rendimiento de las aplicaciones. Tiene tráfico TCP crítico, que debe optimizarse.
Solución
Cuando utiliza la función de optimización de TCP, mejora el rendimiento medio de TCP para los flujos críticos de TCP entre dos sitios SD-WAN.
Consulte la descripción general y las diferencias entre la optimización de TCP en ancho de banda de cuello de botella de extremo y de ida y vuelta (BBR) y vEdge (CUBIC)
El algoritmo de tiempo de propagación rápido BBR se utiliza en la implementación XE SD-WAN (en cEdge).
Viptela OS (vEdge) tiene un algoritmo diferente, más antiguo, llamado CUBIC.
CUBIC tiene en cuenta principalmente la pérdida de paquetes y está ampliamente implementado en diferentes sistemas operativos de clientes. Windows, Linux, MacOS y Android ya tienen CUBIC integrado. En algunos casos, cuando tiene clientes antiguos que ejecutan una pila TCP sin CUBIC, la activación de la optimización de TCP en vEdge aporta mejoras. Uno de los ejemplos en los que se benefició la optimización de vEdge TCP CUBIC es en los submarinos que utilizan hosts de cliente antiguos y enlaces WAN que experimentan retrasos/caídas significativos. Tenga en cuenta que solo vEdge 1000 y vEdge 2000 admiten TCP CUBIC.
BBR se centra principalmente en el tiempo de ida y vuelta y la latencia. No por pérdida de paquetes. Si envía paquetes desde el oeste de EE.UU. a la costa este o incluso a Europa a través del Internet público, en la mayoría de los casos no verá ninguna pérdida de paquetes. El Internet público es a veces demasiado bueno en términos de pérdida de paquetes. Pero lo que se ve es retraso/latencia. Y este problema es abordado por BBR, desarrollado por Google en 2016.
En pocas palabras, BBR modela la red y observa cada confirmación (ACK) y actualiza el ancho de banda máximo (BW) y el tiempo mínimo de ida y vuelta (RTT). A continuación, el envío de control se basa en el modelo: sondeo de ancho de banda máximo y RTT mínimo, espacio cercano a la estimación de ancho de banda y mantenimiento en vuelo cerca de Bandwidth-Delay-Product (BDP). El objetivo principal es garantizar un alto rendimiento con una pequeña cola de cuello de botella.
Esta diapositiva de Mark Claypool muestra el área en la que opera CUBIC:
BBR opera en un lugar mejor, lo que se muestra en esta diapositiva también de Mark Claypool:
Si desea leer más sobre el algoritmo BBR, puede encontrar varias publicaciones sobre BBR vinculadas en la parte superior de la página principal de la lista de correo bbr-dev Aquí.
En resumen:
| Plataforma y algoritmo |
Parámetro de entrada de clave | caso de uso |
| cEdge (XE SD-WAN): BBR | RTT/latencia | Tráfico TCP crítico entre dos sitios SD-WAN |
| vEdge (SO Viptela): CUBICP | Pérdida del paquete | Clientes antiguos sin ninguna optimización de TCP |
Plataformas XE SD-WAN compatibles
En XE SD-WAN SW Release 16.12.1d, estas plataformas cEdge soportan TCP Optimization BBR:
- ISR4331
- ISR4351
- CSR1000v con 8 vCPU y mín. 8 GB de RAM
Advertencias
- Actualmente no se admiten todas las plataformas con una DRAM inferior a 8 GB de RAM.
- Actualmente no se admiten todas las plataformas con 4 o menos núcleos de datos.
- La optimización de TCP no admite MTU 2000.
- Actualmente, no admite tráfico IPv6.
- No se admite la optimización para el tráfico DIA a un servidor BBR de terceros. Debe tener routers cEdge SD-WAN en ambos lados.
- En el escenario del Data Center actual, solo se admite un nodo de servicios (SN) por nodo de control (CN).
- La versión 16.12 no admite casos prácticos combinados con seguridad (contenedor UTD) y optimización de TCP en el mismo dispositivo. A partir de la versión 17.2, se admite el caso práctico combinado. El orden de funcionamiento es TCP Opt primero y, a continuación, Security. El paquete se enviará al contenedor de optimización de TCP y, a continuación, se encadenará el servicio (no se realizará un segundo envío) al contenedor de seguridad UTD. La optimización de TCP se realiza para el flujo completo, no para los primeros bytes. Si se interrumpe UTD, se interrumpirá la conexión completa.
Esta tabla resume las advertencias por versión y subraya las plataformas de hardware soportadas:
| Escenarios |
Casos de uso |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
Comentarios |
| De sucursal a Internet |
DIA |
No |
Yes |
Yes |
Yes |
En 16.12.1 AppQoE FIA no está habilitado en la interfaz de Internet |
| SAAS |
No |
Yes |
Yes |
Yes |
En 16.12.1 AppQoE FIA no está habilitado en la interfaz de Internet |
|
| De sucursal a DC |
Router de extremo único |
No |
No |
No |
Yes |
Necesidad de admitir varios SN |
| Routers periféricos múltiples |
No |
No |
No |
Yes |
Necesita simetría de flujo o sincronización de flujo de Appnav. 16.12.1 no probado con |
|
| Varios SN |
No |
No |
No |
Yes |
Mejora de vManage para aceptar varias IP de SN |
|
| De sucursal a sucursal |
Red de malla completa (De radio a radio) |
Yes |
Yes |
Yes |
Yes |
|
| Hub y radio (Spoke-Hub-Spoke) |
No |
Yes |
Yes |
Yes |
||
| Compatibilidad con BBR |
TCP Opt con BBR |
Parcial | Parcial |
Total |
Total |
|
| Plataformas |
Plataformas Soportadas |
Solo 4300 y CSR |
Todos menos ISR1100 |
Todos |
Todos |
Configurar
Para la optimización de TCP se utiliza un concepto de SN y CN:
- SN es un demonio, que es responsable de la optimización real de los flujos TCP.
- CN se conoce como controlador de AppNav y es responsable de la selección y el transporte del tráfico hacia/desde SN.
SN y CN pueden ejecutarse en el mismo router o separados como nodos diferentes.
Hay dos casos prácticos principales:
- Caso práctico de sucursal con SN y CN ejecutándose en el mismo router ISR4k.
- Caso práctico de Data Center, donde CN se ejecuta en ASR1k y SN se ejecuta en un router virtual CSR1000v independiente.
Ambos casos prácticos se describen en esta sección.
Caso práctico 1. Configuración de la optimización de TCP en una sucursal (extremo todo en uno)
Esta imagen muestra la arquitectura interna general de una única opción independiente en una sucursal:
Paso 1. Para configurar la optimización de TCP, debe crear una plantilla de función para la optimización de TCP en vManage. Vaya a Configuration > Templates > Feature Templates > Other Templates > AppQoE como se muestra en la imagen.
Paso 2. Agregue la plantilla de la función AppQoE a la plantilla de dispositivo correspondiente en Plantillas adicionales:
Esta es la vista previa de CLI de la configuración de plantilla:
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
!
Paso 3. Cree una política de datos centralizada con la definición del tráfico TCP interesante para la optimización.
Por ejemplo; esta política de datos coincide con el prefijo IP 10.0.0.0/8, que incluye las direcciones de origen y de destino, y habilita la optimización TCP para ello:
Esta es la vista previa de CLI de la política 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
!
!
Caso práctico 2. Configuración de la optimización de TCP en el Data Center con un SN externo
La diferencia principal en el caso práctico de la sucursal es la separación física de SN y CN. En el caso práctico de la sucursal del tipo todo en uno, la conectividad se realiza dentro del mismo router mediante la interfaz de grupo de puertos virtuales. En el caso práctico del Data Center, hay un túnel encapsulado GRE de AppNav entre ASR1k que actúa como CN y CSR1k externo que se ejecuta como SN. No es necesario un enlace dedicado ni una conexión cruzada entre CN y SN externo; basta con una simple disponibilidad de IP.
Hay un túnel AppNav (GRE) por SN. Para un uso futuro, donde se soportan varios SN, se recomienda utilizar /28 subred para la red entre CN y SN.
Se recomiendan dos NIC en un CSR1k que actúe como SN. Se necesita la segunda NIC para el controlador SD-WAN si SN tiene que ser configurado/gestionado por vManage. Si el SN se va a configurar/gestionar manualmente, la segunda NIC es opcional.
Esta imagen muestra el Data Center ASR1k ejecutándose como CN y CSR1kv como SN del nodo de servicio :
La topología para el caso práctico de Data Center con ASR1k y CSR1k externo se muestra aquí:
Esta plantilla de la función AppQoE muestra ASR1k configurado como controlador:
CSR1k configurado como nodo de servicio externo se muestra aquí:
Caso de falla
Conmutación por fallo en el caso práctico del Data Center con CSR1k actuando como SN, en caso de fallo CSR1k externo:
- Las sesiones TCP que ya existen se pierden porque la sesión TCP en el SN se termina.
- Las nuevas sesiones TCP se envían al destino final, pero el tráfico TCP no se optimiza (se omite).
- Sin agujeros negros para el tráfico interesante en caso de falla de SN.
La detección de conmutación por fallo se basa en el latido de AppNav, que es de 1 latido por segundo. Después de 3 o 4 errores, el túnel se declara como inactivo.
La conmutación por fallo en el caso práctico de la sucursal es similar: en caso de fallo del SN, el tráfico se envía directamente al destino sin optimizar.
Verificación
Utilize esta sección para confirmar que su configuración funcione correctamente.
Verifique la optimización de TCP en CLI con el uso de este comando CLI y vea el resumen de los flujos optimizados:
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#
Este resultado proporciona información detallada sobre los flujos optimizados:
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#
Troubleshoot
La siguiente CLI le ayudará a identificar problemas con un flujo TCP específico.
Todos los ejemplos se tomaron de la imagen IOS XE SD-WAN 17.2.1 que se ejecuta en ISR4431.
- Averigüe la ID de VRF (que no es igual al nombre de VRF). En este caso, vemos en el siguiente resultado, que el servicio VPN (VRF) 1 tiene el VRF Id 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
…
- Averigüe el id de flujo adecuado para el cliente en la vpn de servicio; aquí vemos 4 flujos diferentes entre dos clientes de Windows que utilizan el recurso compartido SMB a través del puerto 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#
- Consulte las estadísticas de TCP Opt para obtener el flujo adecuado:
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#
- Consulte también estadísticas genéricas de TCP Opt, que también muestran 4 flujos optimizados:
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#
Uso de TCPOpt con otras funciones de AppQoE/UTD a partir de 17.2
En 16.12, el caso práctico principal de TCPOpt es de sucursal a sucursal. Hay una redirección separada al proxy TCP y una redirección separada al contenedor UTD en 16.12, por eso la opción TCP no funciona junto con la seguridad en 16.12
En 17.2 se implementa una ruta de política centralizada, que detectará la necesidad de TCP Opt y Security.
Los paquetes relacionados se redirigirán al plano de servicio (punteados) solo una vez.
A partir de la versión 17.2 se pueden utilizar diferentes opciones de flujo:
- Sólo opción TCP
- Sólo UTD
- Opción TCP -> UTD
- Opción TCP -> Proxy SSL -> UTD
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
29-Jan-2020 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)