Configuración de la función de optimización de TCP en routers periféricos SD-WAN Cisco IOS® XE

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.

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 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 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, que fue 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). Entonces 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 es compatible con el 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).
• Actualmente no se admite un caso práctico combinado con seguridad (contenedor UTD) y optimización de TCP en el mismo dispositivo.

Nota: ASR1k no admite actualmente la optimización de TCP. Sin embargo, existe una solución para ASR1k, donde el ASR1k envía el tráfico TCP a través del túnel AppNav (GRE encapsulado) a un CSR1kv externo para la optimización. Actualmente (febrero de 2020) solo se admite un CSR1k como nodo de servicio externo. Esto se describe más adelante en la sección de configuración.

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	EFT	Yes	Necesita compatibilidad con varios SN
	Varios routers periféricos	No	No	EFT	Yes	Necesita simetría de flujo o sincronización de flujo de Appnav. 16.12.1 no probado con
	Varios SN	No	No	EFT	Yes	Mejora de vManage para aceptar varias IP de SAN
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:

1. Caso práctico de sucursal con SN y CN ejecutándose en el mismo router ISR4k.
2. 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 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 accesibilidad IP.

Hay un túnel AppNav (GRE) por SN. Para su uso futuro, cuando se admitan varios SN, se recomienda utilizar la subred /28 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 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

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Información Relacionada

• Notas de la versión para Cisco IOS XE SD-WAN Release 16.12.x
• Cisco SD-WAN Releases 19.1, 19.2 - Guía de configuración de optimización de TCP
• Cisco SD-WAN Configurar la optimización de TCP para vEdge
• Soporte Técnico y Documentación - Cisco Systems