Configuración de QoS Priority en routers basados en ASR 920 y RSP2

Introducción

Este documento describe cómo los routers ASR920/RSP2 manejan las prioridades de QoS y cómo configurarlas.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Routers de la serie ASR 920
• Políticas de QoS

Componentes Utilizados

La información de este documento se basa en un ASR 9xx con un router RSP2 que ejecuta la versión de software 16.x a 17.x.
Un generador de tráfico se utiliza para probar las funciones que manejan los paquetes de prioridad.

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.

Problemas

Este documento aborda estos problemas específicos de los routers basados en ASR 920 y RSP2:

• Los paquetes de prioridad se descartan en beneficio de los paquetes de mejor esfuerzo debido a la limitación de ASIC en RSP2
• Cómo calcular el porcentaje de ancho de banda que se ofrece en una clase

Paquetes de prioridad descartados con la ventaja de los paquetes de mejor esfuerzo

Durante una prueba se determinó que el paquete de prioridad se puede descartar en la ventaja de un paquete de mejor esfuerzo. Esto es evidente cuando el tráfico entrante llega a través de una interfaz con mayor velocidad que la interfaz de salida y causa una suscripción excesiva en la dirección de salida. Por ejemplo, cuando se reciben 5 Gbps de tráfico y es necesario reenviarlos a través de una interfaz de 1 Gbps.
Esto es igualmente cierto para las interfaces de salida configuradas con un modelador. En caso de que la velocidad de ingreso sea mayor que la CIR configurada en la prioridad de egreso, un paquete podría ser descartado en la ventaja de un paquete de mejor esfuerzo.

Nota: existe una limitación ASIC para la cual no podemos tener un hijo de prioridad a un padre no prioritario.

Si una cola está configurada como expedite y su subcanal principal no lo está, hay fluctuación en la cola de prioridad debido a las latencias de arbitraje en el nivel de subcanal.

Solución

1. Configuración de EFP
2. Aplique un modelador en el
3. Aplique la QoS deseada en el EFP
4. Aplicación de la conectividad IP en la interfaz BDI

Ejemplo:

configuration with issue 
-------------------------
interface GigabitEthernet0/0/0
description this is my egress interface 
service-policy output PM-1G-Out

configuration without issue 
---------------------------
interface GigabitEthernet0/0/0
description this is  egress interface
service-policy output POL-PRIO-MAIN-1G ==> shaper, useful to allow internal priority like BDF
service instance 200 ethernet
encapsulation dot1q 200
rewrite ingress tag pop 1 symmetric
service-policy output PM-1G-Out ==> the original QoS previously applied in the physical interface
bridge-domain 200
!
interface BDI200 ==> BDI must match the bridge-domain defined under the service-instance
description this is  L3 egress
ip address 10.20.2.45 255.255.255.0 
ip mtu 9000
==> no QoS applied under the BDI, all QoS are in the service-instance with a backpressure of the shaper in the physical

Con esta configuración, todos los paquetes de prioridad se priorizaron correctamente y ninguno se descartó en la ventaja de un paquete de mejor esfuerzo, aún así necesita calcular el ancho de banda asignado correctamente.

Cómo calcular el porcentaje de ancho de banda que se ofrece en una clase

La asignación de ancho de banda en la plataforma RSP2 también tiene un comportamiento específico. Muchas veces se observan caídas mientras la QoS está configurada como en otras plataformas.

Por ejemplo, si configura QoS con un modelador de 2 Mbps en un router ASR1K, no se descarta antes de alcanzar los 2 Mbps, ni pone en cola los paquetes de la clase. Sin embargo, esto sucede con RSP2.

En muchos casos, la velocidad ofrecida ni siquiera alcanza el máximo permitido cuando ya se ven caídas.

Este es un ejemplo típico de lo que se puede ver en un RSP2, mientras que los mismos valores para el mismo tráfico exacto aplicado a otra plataforma no mostrarían ninguna caída:

ASR903#show ethernet service instance policy-map | s EXP-5
  Class-map: EXP-5 (match-all)
    58803127 packets, 5488269944 bytes
    5 minute offered rate 279000 bps, drop rate 35000 bps

    Match: mpls experimental topmost 5
    Priority: 3% (297 kbps), burst bytes 37000, b/w exceed drops: 60373

    Priority Level: 1

El problema se debe a la forma en que se maneja el tráfico en el hardware. Básicamente, la implementación del hardware RSP2 no considera solamente la capa 3 sino toda la trama, lo que significa que todos los encabezados son tomados en cuenta.

Prueba de prioridad de QoS de RSP2

En este caso, el tráfico CEM se utiliza para probar el comportamiento de prioridad.

Este es un ejemplo que muestra cómo configurar la prioridad para evitar caídas en la ventaja del mejor esfuerzo y ajustar la asignación de ancho de banda.

Configuración

policy-map POL-PRIO-MAIN-1G
class class-default
shape average 8650000
!
policy-map PM-MPLS-1G-Out
class EXP-5
priority level 1 percent 4
class EXP-4
priority level 2 percent 24
class EXP-6
bandwidth percent 2
queue-limit 25000 us
class EXP-3
bandwidth percent 2
queue-limit 10000 us
class EXP-2
bandwidth percent 2
queue-limit 50000 us
class EXP-1
bandwidth percent 2
queue-limit 20000 us
class class-default
bandwidth percent 1
queue-limit 40000 us
!
interface GigabitEthernet0/0/0
no ip address
negotiation auto
service-policy output POL-PRIO-MAIN-1G
service instance 200 ethernet
encapsulation dot1q 200
rewrite ingress tag pop 1 symmetric
service-policy output PM-MPLS-1G-Out
bridge-domain 200
!
interface CEM0/1/8
no ip address
cem 0
service-policy input PM-CEM-in
payload-size 128
dejitter-buffer 20
!
interface CEM0/1/9
no ip address
cem 0
service-policy input PM-CEM-in
payload-size 64
dejitter-buffer 16
!
interface BDI200
description path for qos stress
ip address 10.20.2.45 255.255.255.0
ip mtu 9000
ip router isis
carrier-delay msec 0
cdp enable
mpls traffic-eng tunnels
bfd template BFD-1hop-5ms
isis circuit-type level-2-only
isis network point-to-point
isis metric 15 level-1
isis metric 15 level-2
ip rsvp bandwidth percent 90
ip rsvp signalling hello graceful-restart

Tráfico

CEM0/1/8 crea 2 flujos de tráfico en rojo y CEM0/1/9 en verde:

Podemos ver el comportamiento con diferentes tamaños de paquete, CEM0/1/9 envía el doble de paquetes que CEM0/1/8, que está configurado para 128 bytes.

Normalmente, una configuración de QoS en RP considera solamente la carga útil de CEM, mientras que RSP2 considera la trama completa.

Ejemplo de Trama

Puede ver 30 bytes adicionales a la carga útil original configurada bajo CEM. Esto se puede explicar como:

Ethernet header = 14 Bytes
Dot1q header    = 4 Bytes
Mpls header     = 4 Bytes
PW   Header     = 4 Bytes
CEM trailer     = 4 Bytes
Total           = 30 Bytes

Cálculo del ancho de banda necesario en el hardware, recuerde que la trama debe ser considerada:

CEM 0/1/8 125 Packet/sec, size 128bytes ==> 125*128*8 = 128000 bps
CEM 0/1/9 250 Packet/sec, size 64bytes  ==> 250*64*8  = 128000 bps
on each frame we need an extra 30bytes  ==> 375*30*8  = 90000 bps
Total                                                 = 346000 bps

Para verificar el comportamiento y la precisión del modelador en la interfaz que se configuró en 8650000 bps, esto se hace para tener un 4% exacto para la clase de prioridad.

Cálculo: 346000.0000/8650000.0000 = 0,04 = 4%.

Esto es lo que se ve en la configuración anterior. Los resultados confirman que la configuración y el cálculo son precisos.

Resultado de la política:

ASR903#show ethernet service instance policy-map | s EXP-5
  Class-map: EXP-5 (match-all)
    3063745 packets, 285949512 bytes
    5 minute offered rate 279000 bps, drop rate 0000 bps
    Match: mpls experimental topmost 5
    Priority: 4% (346 kbps), burst bytes 8650, b/w exceed drops: 0

    Priority Level: 1

346 Kbps aplicados independientemente de la plataforma es mucho más que L3, pero es exactamente el tráfico L2.

Prueba con el generador de tráfico

Generador de tráfico —> Interfaz TenGig —> Asr9xx RSP2 —> Salida 1G donde se aplica la política.

ASR903#show clock
22:54:40.976 CET Wed Nov 30 2022
ASR903#show ethernet service instance policy-map | inc Class-map:|drop rate
  Class-map: EXP-5 (match-all)
    5 minute offered rate 279000 bps, drop rate 0000 bps
  Class-map: EXP-4 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-6 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-3 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-2 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-1 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: class-default (match-any)
    5 minute offered rate 762348000 bps, drop rate 756024000 bps

ASR903#show clock
17:41:16.110 CET Thu Dec 1 2022
ASR903#show ethernet service instance policy-map | inc Class-map:|drop rate
  Class-map: EXP-5 (match-all)
    5 minute offered rate 279000 bps, drop rate 0000 bps
  Class-map: EXP-4 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-6 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-3 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-2 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-1 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: class-default (match-any)
    5 minute offered rate 762400000 bps, drop rate 756077000 bps

Después de aproximadamente 18 horas no hubo una sola caída en la prioridad, aunque en la interfaz hay muchas caídas, como se ve en la tasa de caída de la clase predeterminada, debido a la CIR del límite del modelador.

Observe que se utilizó el límite de cola predeterminado: para ajustar el ancho de banda de modo que admita el tamaño de trama l2 completo, no es necesario ajustar las colas.

Prueba negativa

            

Otra prueba para verificar la buena precisión es omitir los 4 bytes de la cola CEM y ver si se producen pequeñas caídas:

ASR903#show ethernet service instance policy-map | s EXP-5
  Class-map: EXP-5 (match-all)
    352466 packets, 32896848 bytes
    5 minute offered rate 279000 bps, drop rate 5000 bps
    Match: mpls experimental topmost 5
    Priority: 4% (334 kbps), burst bytes 8350, b/w exceed drops: 271

    Priority Level: 1

Como puede ver, si omite una parte de ese marco, se producirán caídas.

Conclusiones

Esta prueba con el tráfico CEM confirma que la trama L2 completa debe tenerse en cuenta para el cálculo del ancho de banda.

Un artificio es aumentar el límite de cola, pero claramente un cálculo correcto de la trama L2 pone menos estrés en los recursos de memoria utilizados por la plataforma.

Es obvio que no todo el tráfico se puede prever en cada momento, como en la transferencia con tamaño de paquete variable. Para tener una configuración precisa, debe tener en cuenta ethernet, dot1q(s), encabezados de etiquetas MPLS al tamaño promedio del paquete y también la velocidad de los paquetes.

Para cualquier tráfico que atraviese el ASIC de un RSP2, debe ser consciente de cada byte individual que está contenido en una trama enviada desde la plataforma (CRC no incluido).