Guía del usuario de sobrecarga de tráfico de control SD-WAN

Introducción

Este documento describe cómo calcular la sobrecarga de tráfico de control en una implementación de superposición SD-WAN. Tenga en cuenta que se debe utilizar la siguiente guía de artículo en el código de viptela debajo de 20.10.x e IOS-XE SD-WAN 17.10.x e inferior (desde 20.10.x /17.10.x Cisco ha implementado el modelo push para la recopilación de datos). 

Problema

Una pregunta común que se recibe en el momento de la fase de diseño de un usuario es "¿Cuánta sobrecarga supondría la solución SD-WAN para nuestro circuito de sucursal?" La respuesta es que depende de unas pocas variables.

Solución

Este caso práctico le ayuda a encontrar la respuesta. La mayoría de los usuarios en el momento de una función de sucursal pueden o no tener el circuito de Internet aprovisionado. Si tienen uno, normalmente se parecería a la Figura 1.

Figura 1. Sucursal SD-WAN con Internet y circuito de switching de etiquetas multiprotocolo (MPLS).

Esto podría no ser siempre el caso, algunos usuarios preferirían sobre todo migrar a SD-WAN con el cambio mínimo y la introducción de nuevo circuito, la adición de circuito posiblemente planeado para una fase posterior, que sería como la Figura 2. sin un circuito de Internet.

Figura 2 Sucursal SD-WAN con solo circuito MPLS.

Para establecer el escenario, si tiene 100 sucursales con 2 centros distribuidores y una topología de malla completa propuesta entre sucursales y centros distribuidores, y el usuario tiene un estándar de QoS estricto con una asignación del 20% a la cola de baja latencia (LLQ) para voz.

Con la migración a la SD-WAN, ¿cuáles serían los costes generales que deberíamos tener en cuenta para estas sucursales, si las hubiera? Vamos a profundizar más.

Nota: Estos cálculos se tendrán en cuenta en un requisito de funcionamiento normal, incluidos los picos de necesidad. Sin embargo, no considere todos los escenarios posibles.

Estos números se derivan de la prueba de laboratorio que se realizó con 1vManage, 1vBond y 1vSmart, 255 sesiones BFD. 

Tabla 1. Ancho de banda por sesión.

1 sesión BFD/vecino	2 x 132 x 8 = 2,2 Kbps 2: En un segundo usted envía y recibe hasta 2 paquetes BFD 132: tamaño de paquete BFD en B
DTLS a vSmart	hasta 80 Kbps*
Sondeo de vManage para datos	hasta 1,2 Mbps**
Habilitación de DPI	200 Kbps

Kbps = Kilobits por segundo

B = Bytes

Mbps = Megabits por segundo

* Depende de la política y las rutas; este cálculo es necesario solo en el momento del intercambio inicial y el estado estable es mucho más bajo / mínimo alrededor de 200 B.

** No tiene en cuenta una actividad activada por el usuario, como la ejecución de comandos remotos o la administración de tecnología; 1,2 Mbps se encuentra en el pico máximo.

Ahora, si considera todos los 100 sitios de malla completa que son 200 sesiones BFD (2 routers por sucursal, 2 TLOC por router con restricción de color), la tabla mencionada anteriormente se convertiría en.x.

Tabla 2. Ancho de banda Queue0 para 200 sesiones BFD [100 sitios] que incluye sondeo vSmart y vManage.

200 sesiones BFD	440 Kbps [2.2 x 200]
DTLS a vSmart	hasta 80 Kbps*
vManage polls	hasta 1,2 Mbps**
Total	1.72 Mbps

* Depende de la política y las rutas; este cálculo es necesario solo en el momento del intercambio inicial y el estado estable es mucho más bajo / mínimo alrededor de 200 B.

** No tiene en cuenta una actividad activada por el usuario, como la ejecución de comandos remotos o la administración de tecnología; 1,2 Mbps se encuentra en el pico máximo.

Tenga esto en cuenta que todos estos ataques de tráfico en el LLQ Queue0, este tráfico de control siempre recibe prioridad ciudadana de primera clase, lo que significa que es el último que se controla en un LLQ.

A menudo, en el momento del diseño de QoS, el tráfico de voz se coloca en Queue0 (LLQ), con un requisito de 1,72 Mbps para 100 sucursales de malla completa con Tloc para SD-WAN; puede ver regulación/descarte en LLQ con ramas de circuitos de ancho de banda bajo.

Ahora, si considera la sobrecarga de la extensión Tloc que no contribuirá a la cola 0 pero constituye el requisito de capacidad general.

Tabla 3. Requisito de ancho de banda general después de considerar cómo controlar el tráfico en la extensión Tloc.

Requisito Queue0	1.72 Mbps
200 sesiones BFD para extensión Tloc [cifrada] no Queue0	520 Kbps [440 + 80*]                [BFD + DTLS]
Total	2.24 Mbps

* Depende de la política y las rutas; este cálculo es necesario solo en el momento del intercambio inicial y el estado estable es mucho más bajo / mínimo alrededor de 200 B.

Por 100 ramas de malla completa con extensiones TLOC con restricción de color considere una planificación de capacidad de ~2.5 Mbps en un requisito extremo, nuevamente puede recopilar comandos en tiempo real, la tecnología de administración no se considera en el cálculo mencionado anteriormente, considere esto en una situación de funcionamiento normal. 

Escenario 1.

Si necesita acomodar los requisitos de tráfico de control a la cola 0 y si una sucursal tiene solamente un circuito de 10 Mbps, debe ser incorporado en la superposición SD-WAN con una política de QoS de solamente el 20% LLQ para el tráfico de voz y control. Puede observar una experiencia degradada en el momento del pico de sondeo de vManage. Una solución radial podría no ser útil en este caso, ya que todavía consume alrededor de 1,28 Mbps.

Tabla 4. Requisito de ancho de banda de cola0 de radios y concentradores.

4 sesiones de BFD a los centros distribuidores	8.8 Kbps [2.2 x 4]
DTLS a vSmart	hasta 80 Kbps*
vManage polls	hasta 1,2 Mbps**
Total	1.28 Mbps

* Depende de la política y las rutas; este cálculo es necesario solo en el momento del intercambio inicial y el estado estable es mucho más bajo / mínimo alrededor de 200 B.

** No tiene en cuenta una actividad activada por el usuario, como la ejecución de comandos remotos o la administración de tecnología; 1,2 Mbps se encuentra en el pico máximo.

Situación hipotética 2.

Si decide rediseñar la política de QoS, para dar cabida al requisito de ancho de banda adicional de ~2 Mbps, puede aumentar el LLQ de QoS del 20% al 40%. Sin embargo, esto tendría un efecto negativo en los circuitos de ancho de banda más grandes.

Figura 3. Asignación de cola0 típica del 20% para QoS.

Para un circuito de 10 Mbps, Queue0 obtiene 2 Mbps al 20%. Supongamos que se trata de un estándar de QoS típico de una empresa. La adopción de SD-WAN requiere una malla completa, por lo que debe aumentar la asignación de la cola 0 para acomodar la sobrecarga de 2 Mbps a la cola 0 si el usuario decide aumentar la asignación de QoS al 40%, como se muestra en la imagen.

Observe que una enorme cantidad de Queue0 para un circuito quita los recursos para la otra cola. Sin embargo, la diferencia está más en un circuito de ancho de banda más grande.

Idealmente, debe tener el LLQ para tener una asignación fija para el tráfico de control y otra cola para el tráfico de voz, pero ambos requieren una cola de prioridad. Los routers de Cisco admiten una cola de prioridad con dos niveles conocidos como LLQ dividido; de nuevo, esto no resuelve un problema de requisito de ancho de banda mínimo una vez que se cumple un requisito mínimo, un LLQ dividido sería el diseño de QoS preferido

Dividir LLQ:

 

 

Con Split LLQ, agrega el ancho de banda necesario a la cola y aún mantiene la cola de prioridad.

El LLQ dividido actualmente soporta solamente con la CLI complementaria, con la LLQ dividida podría tener dos niveles de la cola de prioridad, una configuración de muestra sería como se muestra aquí. La configuración se puede personalizar con variables, este fragmento de código reserva 4 Mbps para el tráfico de control y el resto de la cola como porcentaje de ancho de banda asignado.

Ejemplo de una cola dividida:

policy-map GBL_edges_qosmap_rev1

class Queue0

  priority level 1

  police cir 2000000 bc 250000

   conform-action transmit

   exceed-action drop

  !

!

class Queue1

  bandwidth remaining ratio 16

  random-detect precedence-based

!

class class-default

  bandwidth remaining ratio 8

  random-detect precedence-based

!

class Queue3

  bandwidth remaining ratio 16

  random-detect precedence-based

!

class Queue4

  bandwidth remaining ratio 32

  random-detect precedence-based

!

class Queue5

  bandwidth remaining ratio 8

  random-detect precedence-based

!

class Queue6

  priority level 2

  police rate percent 20

  !

!

!

Nota: Estas configuraciones se han probado en ISR/ASR que ejecuta 17.3.x y en los controladores de 20.3.x.

Directriz genérica para el cálculo de gastos generales

Esta tabla puede ayudarle a planificar la capacidad por circuito para una sobrecarga de control de SD-WAN.

Tabla 5. Cálculo de directrices genéricas (se supone que tiene restricciones de color).

Ejemplo de Cálculo de Costes Generales

Si necesita calcular la sobrecarga del circuito MPLS para 100 sitios similares al que se muestra aquí, puede asumir que cada color tiene la restricción habilitada.

Nº de sitios = 100

Nº de BFD a un sitio desde WAN Tloc = 2.

Tabla 6. Calcule la sobrecarga de MPLS para la implementación de 100 sitios.

Protocolo/Sesión	Ancho de banda necesario
Queue0	2,2 x [100 x 2] + 80 + 1200 Tamaño BFD x [ no.de sitios x no.de BFD a un sitio desde WAN Tloc] + DTLS + vManage = 1,72 Mbps
Control del tráfico sobre TLOC	2,2 x [100 x 2] + 80 Tamaño de BFD x [Sitios x TLOC/por router] + DTLS = 520 Kbps
Total	1720 Kbps + 520 Kbps = 2,24 Mbps

La sobrecarga de Queue0 es de 1,72 Mbps y la sobrecarga total es de 2,24 Mbps.