Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Problema

Solución

Plataformas XE SD-WAN compatibles

Advertencias

Configurar

Caso práctico 1. Configuración de la optimización de TCP en una sucursal (extremo todo en uno)

Caso práctico 2. Configuración de la optimización de TCP en el Data Center con un SN externo

Caso de falla

Verificación

Troubleshoot

Información Relacionada

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