Cómo gestionar microrráfagas en ASR 920, diferencias entre bytes y porcentajes con límite de cola
Contenido
Introducción
Este documento describe cómo manejar las microrráfagas en los routers ASR 920, que a menudo son la causa de las caídas de paquetes de salida de la interfaz. En detalle se muestra la diferencia entre el uso de bytes y el porcentaje con el comando queue-limit.
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 router ASR 920 que ejecuta la versión de software Cisco IOS-XE 16.9.6.
IXIA se utiliza como generador de tráfico de la prueba de laboratorio.
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.
Antecedentes
Las microrráfagas se conocen como pequeños picos en el tráfico de red. En las redes de Service Provider Access, por ejemplo, esto ocurre comúnmente en escenarios de discordancia de velocidad donde un flujo de tráfico entra al router desde una interfaz de alta velocidad, como 10 Gigabit Ethernet (GE), y sale a través de una interfaz de baja velocidad, como 1 GE.
El problema más común que causan los microbustos en los routers ASR 920 son las caídas de paquetes de interfaz en la dirección de salida. Esto sucede cuando hay ráfagas en la interfaz entrante que son más altas que la velocidad de la interfaz saliente, durante un período de tiempo muy corto (orden de milisegundos). Durante este tiempo, los paquetes deben almacenarse en el búfer.
En las plataformas ASR 920 / RSP2, el búfer predeterminado asignado a las colas en cada interfaz 1 GE es de 48 KB, mientras que para las colas en cada interfaz 10 GE es de 120 KB.
Además, hay un búfer compartido disponible de 11,75 MB. Cuando el búfer de interfaz predeterminado no es suficiente para acomodar una ráfaga de paquetes, se puede utilizar el búfer compartido.
Para habilitar el uso del búfer compartido para una interfaz, es necesario configurar una política de QoS en esa interfaz que defina el parámetro queue-limit.
Configurar límite de cola
Este es un ejemplo de configuración de queue-limit para la interfaz GE 0/0/1:
class-map match-all DUMMY
match qos-group 99 <--- it can be any unused group
policy-map QUEUE-LIMIT
class DUMMY
class class-default
queue-limit percent 5
interface GigabitEthernet 0/0/1
service-policy output QUEUE-LIMIT
Esta política no coincide con ningún tráfico, por lo que tampoco le afecta. Todo lo que esta política hace es aumentar el buffer de cola de la interfaz GE 0/0/1.
El comando match qos-group 99 es necesario porque no se soporta configurar queue-limit en una clase que no es de hoja, por lo que necesita utilizar un class-map ficticio como una clase primaria para configurar el comando queue-limit bajo el comando leaf class-default:
ASR-920-1(config)#policy-map QUEUE-LIMIT
ASR-920-1(config-pmap)#class class-default
ASR-920-1(config-pmap-c)# queue-limit percent 5
QOS: queue-limit command not supported in non-leaf classes
queue-limit: platform params check fail
El límite de cola se puede establecer de diferentes maneras:
(config-pmap-c)#queue-limit ?
<1-2097152> in bytes, <1-1677721> in us, <1-8192000> in packets by default
percent % of threshol
El parámetro y el valor deben seleccionarse de acuerdo con los requisitos de la red.
Para entender esos parámetros y cómo un cambio en los valores afecta el uso del buffer, puede consultar la prueba de laboratorio presentada en la siguiente sección.
ASR-920-1(config)#interface port-channel 2
ASR-920-1(config-if)#service-policy output qos-tac
QoS: Configuration failed. Policy-map with Queueing actions not supported on EC main-interface/EFP
QoS: Configuration errors for policymap qos-tac
Diferencias con RSP3 y NCS 520
Capacidades de QoS del módulo Cisco RSP3:
- El módulo RSP3 tiene búferes de paquetes externos de 4 GB por NPU
- El módulo RSP3 admite 48000 colas
- De forma predeterminada, el módulo RSP3 admite un límite de cola de hasta 1 MB por cola
- El porcentaje de límite de cola se considera de 1 GB del total de búferes
Para los routers con supervisores RSP3 y NCS 520, el número de grupos de calidad de servicio que se pueden configurar está limitado a 0-7:
ASR-903-1(config)#class-map match-all qos-tac
ASR-903-1(config-cmap)#match qos-group ?
<0-7> Qos Group value
En NCS 520 hay un búfer de cola de 2 MB compartido entre todas las interfaces de forma predeterminada; se puede acceder a un búfer externo de 2 GB cuando se configura un policy-map con queue-limit. También hay una diferencia en los parámetros bytes y us para queue-limit:
ASR-520-1(config-pmap-c)# queue-limit ?
<1-8192000> in bytes, <1-40000> in us, <1-8192000> in packets by default
percent % of threshold
Prueba de laboratorio de límite de cola (QL), diferencias entre bytes y porcentaje
Ámbito y parámetros de la prueba
Como se observó anteriormente, el valor máximo configurable para el límite de cola en bytes es 2097152, que es aproximadamente el 18% del búfer compartido en las plataformas ASR 920 (11,75 MB ~ 45898 * 256 bytes).
Sin embargo, si configura el límite de cola en porcentaje, puede subir hasta el 100%. Por lo tanto, para comparar el porcentaje y los bytes con valores equivalentes, la prueba toma los valores de bytes de 117498 a 2097152 bytes y los valores porcentuales de límite de cola de 1% a 18%:
queue-limit percent 1 <=> queue-limit 117498 bytes
queue-limit percent 2 <=> queue-limit 234996 bytes
queue-limit percent 3 <=> queue-limit 352494 bytes
queue-limit percent 4 <=> queue-limit 469992 bytes
queue-limit percent 5 <=> queue-limit 587490 bytes
queue-limit percent 6 <=> queue-limit 704988 bytes
queue-limit percent 7 <=> queue-limit 822486 bytes
queue-limit percent 8 <=> queue-limit 939984 bytes
queue-limit percent 9 <=> queue-limit 1057482 bytes
queue-limit percent 10 <=> queue-limit 1174980 bytes
queue-limit percent 11 <=> queue-limit 1292478 bytes
queue-limit percent 12 <=> queue-limit 1409976 bytes
queue-limit percent 13 <=> queue-limit 1527474 bytes
queue-limit percent 14 <=> queue-limit 1644972 bytes
queue-limit percent 15 <=> queue-limit 1762470 bytes
queue-limit percent 16 <=> queue-limit 1879968 bytes
queue-limit percent 17 <=> queue-limit 1997466 bytes
queue-limit percent 18 <=> queue-limit 2097152 bytes
Se configuran 36 policy-maps: 18 con valores límite de cola que oscilan entre el 1% y el 18% y los otros 18 con valores límite de cola que oscilan entre 117498 y 2097152 bytes.
policy-map QUEUE-LIMIT-PERCENT-X
class DUMMY
class class-default
queue-limit percent X
policy-map QUEUE-LIMIT-BYTES-X
class DUMMY
class class-default
queue-limit Y bytes
=> X values range from 1 to 18
=> Y values range from 117498 to 2097152
Cada política se prueba con el mismo tráfico de microrráfaga, que se genera con IXIA. Este tráfico llega a un puerto 10 GE del ASR 920 y sale de un puerto 1 GE del mismo router.
Las ráfagas consisten en 20000 paquetes a 4 Gbps a intervalos de 5 segundos. Esta es la duración de ráfaga dada un tamaño de paquete específico:
1280000 bytes at 64 packet size, Burst duration: 0.00256 second
4000000 bytes at 200 packet size, Burst duration: 0.008 second
6000000 bytes at 300 packet size, Burst duration: 0.012 second
10360000 bytes at 518 packet size, Burst duration: 0.02072 second
16000000 bytes at 800 packet size, Burst duration: 0.032 second
20480000 bytes at 1024 packet size, Burst duration: 0.04096 second
28000000 bytes at 1400 packet size, Burst duration: 0.056 second
Procedimiento de prueba
Paso 1. Aplique el policy-map QUEUE-LIMIT-BYTES-X (X=1) con bytes Y=117498 en la interfaz saliente.
Paso 2. Ejecute el tráfico de microrráfaga durante 1 minuto.
Paso 3. Mida el número total de paquetes en la salida y cuántos paquetes se descartaron.
Paso 4. Calcule la relación entre los paquetes descartados y los paquetes de salida totales.
Paso 5. Repita una vez desde el paso 1, esta vez use policy-map QUEUE-LIMIT-PERCENT-X con queue-limit percent X, donde X=1.
Paso 6. Repita desde el paso 1 con X=X+1 para el nombre de policy-map y el valor porcentual, Y=Y+117498 bytes. Repita hasta X=18 e Y=2097152.
Ejemplo:
Medición con mapa de política QUEUE-LIMIT-BYTES-1:
ASR-920-1#show int Gi0/0/1
GigabitEthernet0/0/1 is up, line protocol is up
Hardware is 24xGE-4x10GE-FIXED-S, address is 70df.2f2f.ed01 (bia 70df.2f2f.ed01)
Internet address is 10.12.10.47/31
MTU 8900 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 4/255, rxload 4/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, link type is auto, media type is T
output flow-control is unsupported, input flow-control is on
Carrier delay is 0 msec
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 684263427
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
30 second input rate 19475000 bits/sec, 19533 packets/sec
30 second output rate 19157000 bits/sec, 13356 packets/sec
5064106237 packets input, 4333296255278 bytes, 0 no buffer
Received 29 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 726180 multicast, 0 pause input
7829367523 packets output, 4217074973677 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
ASR-920-1#show policy-map int Gi0/0/1 output
GigabitEthernet0/0/1
Service-policy output: QUEUE-LIMIT-BYTES-1
Class-map: DUMMY (match-all)
0 packets, 0 bytes
30 second offered rate 0000 bps
Match: qos-group 99
Class-map: class-default (match-any)
1044078 packets, 73085460 bytes
30 second offered rate 9759000 bps, drop rate 0000 bps
Match: any
queue limit 117498 bytes
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Medición después de 1 minuto de tráfico de microrráfaga:
ASR-920-1#show int Gi0/0/1
GigabitEthernet0/0/1 is up, line protocol is up
Hardware is 24xGE-4x10GE-FIXED-S, address is 70df.2f2f.ed01 (bia 70df.2f2f.ed01)
Internet address is 10.12.10.47/31
MTU 8900 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 2/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, link type is auto, media type is T
output flow-control is unsupported, input flow-control is on
Carrier delay is 0 msec
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 684561562
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
30 second input rate 13981000 bits/sec, 19643 packets/sec
30 second output rate 11256000 bits/sec, 12784 packets/sec
5064715137 packets input, 4333338878716 bytes, 0 no buffer
Received 29 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 726190 multicast, 0 pause input
7829753878 packets output, 4217102018968 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
ASR-920-1#show policy-map int Gi0/0/1 output
GigabitEthernet0/0/1
Service-policy output: QUEUE-LIMIT-BYTES-1
Class-map: DUMMY (match-all)
0 packets, 0 bytes
30 second offered rate 0000 bps
Match: qos-group 99
Class-map: class-default (match-any)
1847215 packets, 129305050 bytes
30 second offered rate 10804000 bps, drop rate 0000 bps
Match: any
queue limit 117498 bytes
(queue depth/total drops/no-buffer drops) 0/387570/0
(pkts output/bytes output) 656508/45955560
Paquete descarta delta: 684561562 - 684263427 = 298135
Delta de salida total de paquetes: 7829753878 - 7829367523 = 386355
Relación entre las pérdidas de paquetes y los paquetes salientes: 298135 / 386355 = 77%
Resultados de pruebas de laboratorio
Como se explicó, se prueban 36 mapas de políticas: 18 configurados con valores de límite de cola que oscilan entre el 1% y el 18% se comprueban con las otras 18 políticas configuradas con valores de límite de cola que oscilan entre 117498 y 2097152 bytes. Cada mapa de políticas se prueba con el mismo tráfico de microrráfaga generado con IXIA.
En esta sección se exponen los resultados de esta prueba, repetida 7 veces para verificar los resultados con diferentes tamaños de paquete, en bytes: 64, 200, 300, 518, 800, 1024, 1400.
Para facilitar la lectura, para cada tamaño de paquete los resultados se exponen en una tabla y luego se grafican.
Porcentaje de QL frente a bytes con paquetes de 64 bytes
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 81% | 77%
QL Bytes/Percent 2 | 72% | 31%
QL Bytes/Percent 3 | 61% | 15%
QL Bytes/Percent 4 | 54% | 0%
QL Bytes/Percent 5 | 45% | 0%
QL Bytes/Percent 6 | 38% | 0%
QL Bytes/Percent 7 | 33% | 0%
QL Bytes/Percent 8 | 26% | 0%
QL Bytes/Percent 9 | 22% | 0%
QL Bytes/Percent 10 | 17% | 0%
QL Bytes/Percent 11 | 12% | 0%
QL Bytes/Percent 12 | 8% | 0%
QL Bytes/Percent 13 | 4% | 0%
QL Bytes/Percent 14 | 1% | 0%
QL Bytes/Percent 15 | 0% | 0%
QL Bytes/Percent 16 | 0% | 0%
QL Bytes/Percent 17 | 0% | 0%
QL Bytes/Percent 18 | 0% | 0%
-------------------------------------------------------------------
Porcentaje de QL frente a bytes con paquetes de 200 bytes
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 82% | 80%
QL Bytes/Percent 2 | 72% | 63%
QL Bytes/Percent 3 | 63% | 52%
QL Bytes/Percent 4 | 54% | 39%
QL Bytes/Percent 5 | 46% | 42%
QL Bytes/Percent 6 | 51% | 17%
QL Bytes/Percent 7 | 32% | 18%
QL Bytes/Percent 8 | 27% | 3%
QL Bytes/Percent 9 | 22% | 3%
QL Bytes/Percent 10 | 17% | 3%
QL Bytes/Percent 11 | 12% | 0%
QL Bytes/Percent 12 | 8% | 0%
QL Bytes/Percent 13 | 5% | 0%
QL Bytes/Percent 14 | 1% | 0%
QL Bytes/Percent 15 | 0% | 0%
QL Bytes/Percent 16 | 0% | 0%
QL Bytes/Percent 17 | 0% | 0%
QL Bytes/Percent 18 | 0% | 0%
-------------------------------------------------------------------
Porcentaje de QL frente a bytes con paquetes de 300 bytes
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 84% | 106%
QL Bytes/Percent 2 | 72% | 72%
QL Bytes/Percent 3 | 62% | 63%
QL Bytes/Percent 4 | 54% | 52%
QL Bytes/Percent 5 | 46% | 46%
QL Bytes/Percent 6 | 39% | 34%
QL Bytes/Percent 7 | 33% | 34%
QL Bytes/Percent 8 | 27% | 22%
QL Bytes/Percent 9 | 21% | 21%
QL Bytes/Percent 10 | 23% | 20%
QL Bytes/Percent 11 | 13% | 2%
QL Bytes/Percent 12 | 9% | 2%
QL Bytes/Percent 13 | 5% | 2%
QL Bytes/Percent 14 | 1% | 1%
QL Bytes/Percent 15 | 0% | 2%
QL Bytes/Percent 16 | 0% | 1%
QL Bytes/Percent 17 | 0% | 2%
QL Bytes/Percent 18 | 0% | 0%
-------------------------------------------------------------------
Porcentaje de QL frente a bytes con paquetes de 518 bytes
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 85% | 86%
QL Bytes/Percent 2 | 97% | 81%
QL Bytes/Percent 3 | 62% | 71%
QL Bytes/Percent 4 | 54% | 68%
QL Bytes/Percent 5 | 46% | 84%
QL Bytes/Percent 6 | 52% | 54%
QL Bytes/Percent 7 | 42% | 54%
QL Bytes/Percent 8 | 27% | 43%
QL Bytes/Percent 9 | 21% | 43%
QL Bytes/Percent 10 | 17% | 43%
QL Bytes/Percent 11 | 17% | 34%
QL Bytes/Percent 12 | 8% | 35%
QL Bytes/Percent 13 | 5% | 26%
QL Bytes/Percent 14 | 1% | 23%
QL Bytes/Percent 15 | 0% | 26%
QL Bytes/Percent 16 | 0% | 34%
QL Bytes/Percent 17 | 0% | 26%
QL Bytes/Percent 18 | 0% | 2%
-------------------------------------------------------------------
Porcentaje de QL frente a bytes con paquetes de 800 bytes
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 112% | 117%
QL Bytes/Percent 2 | 74% | 86%
QL Bytes/Percent 3 | 63% | 82%
QL Bytes/Percent 4 | 54% | 75%
QL Bytes/Percent 5 | 47% | 73%
QL Bytes/Percent 6 | 39% | 66%
QL Bytes/Percent 7 | 33% | 88%
QL Bytes/Percent 8 | 27% | 56%
QL Bytes/Percent 9 | 22% | 57%
QL Bytes/Percent 10 | 17% | 57%
QL Bytes/Percent 11 | 13% | 44%
QL Bytes/Percent 12 | 9% | 56%
QL Bytes/Percent 13 | 5% | 43%
QL Bytes/Percent 14 | 2% | 44%
QL Bytes/Percent 15 | 0% | 43%
QL Bytes/Percent 16 | 0% | 43%
QL Bytes/Percent 17 | 0% | 44%
QL Bytes/Percent 18 | 0% | 21%
-------------------------------------------------------------------
Porcentaje de QL frente a bytes con paquetes de 1024 bytes
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 85% | 93%
QL Bytes/Percent 2 | 97% | 89%
QL Bytes/Percent 3 | 82% | 83%
QL Bytes/Percent 4 | 51% | 82%
QL Bytes/Percent 5 | 45% | 78%
QL Bytes/Percent 6 | 39% | 72%
QL Bytes/Percent 7 | 41% | 72%
QL Bytes/Percent 8 | 26% | 62%
QL Bytes/Percent 9 | 20% | 65%
QL Bytes/Percent 10 | 16% | 66%
QL Bytes/Percent 11 | 11% | 68%
QL Bytes/Percent 12 | 7% | 53%
QL Bytes/Percent 13 | 3% | 53%
QL Bytes/Percent 14 | 0% | 52%
QL Bytes/Percent 15 | 0% | 52%
QL Bytes/Percent 16 | 0% | 53%
QL Bytes/Percent 17 | 0% | 52%
QL Bytes/Percent 18 | 0% | 33%
-------------------------------------------------------------------
Porcentaje de QL frente a bytes con paquetes de 1400 bytes
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 101% | 93%
QL Bytes/Percent 2 | 68% | 87%
QL Bytes/Percent 3 | 58% | 86%
QL Bytes/Percent 4 | 50% | 85%
QL Bytes/Percent 5 | 43% | 82%
QL Bytes/Percent 6 | 36% | 75%
QL Bytes/Percent 7 | 27% | 79%
QL Bytes/Percent 8 | 24% | 72%
QL Bytes/Percent 9 | 25% | 76%
QL Bytes/Percent 10 | 14% | 95%
QL Bytes/Percent 11 | 9% | 62%
QL Bytes/Percent 12 | 5% | 62%
QL Bytes/Percent 13 | 1% | 58%
QL Bytes/Percent 14 | 0% | 62%
QL Bytes/Percent 15 | 0% | 85%
QL Bytes/Percent 16 | 0% | 63%
QL Bytes/Percent 17 | 0% | 62%
QL Bytes/Percent 18 | 0% | 50%
-------------------------------------------------------------------
Relación entre caídas y tamaño de paquete
Como se ha mencionado, ASR 920 tiene un búfer de paquetes interno de 11,75 MB que se divide en 45898 nodos Q de 256 bytes cada uno.
- Para un paquete con un tamaño < 256 bytes, se utiliza exactamente 1 Qnode
- Para un paquete con tamaño de 1024 bytes, se utilizan 4 nodos Q
- Para un paquete con un tamaño de 257 bytes, se utilizan 2 nodos Q y se pierden los 255 bytes no utilizados
Por lo tanto, puede almacenar una cantidad menor de paquetes grandes que la que puede almacenar con paquetes pequeños. Se espera la relación entre la velocidad de descarte y el tamaño del paquete en tamaños de límite de cola equivalentes.
Diferencia entre bytes equivalentes y valores porcentuales
Como se explicó, hay 45898 nodos Q en el búfer compartido de 11,75 MB, redondeados a 45900 para facilitar el cálculo.
El cálculo del porcentaje de límite de cola no calcula el porcentaje de los 11,75 MB sino el de los 45900 nodos Q. Por lo tanto, queue-limit percent 10 significa 10% de 45900 que da 4590 nodos Q.
Además, el porcentaje de Qnodes asignados se considera el número de paquetes que se pueden almacenar en la cola, independientemente de su tamaño. Volviendo al ejemplo anterior, esto significa que:
queue-limit percent 10 = 4590 Qnodes = 4590 paquetes.
Dado que este cálculo es independiente del tamaño del paquete, para paquetes con un tamaño de 256 bytes o menos, sólo se utiliza un Qnode y se mantiene la equivalencia entre Qnodes y paquetes:
queue-limit percent 10 = 4590 Qnodes = 4590 paquetes de 256 bytes = 4590*256 bytes = 1,175 MB = 10% del búfer
Sin embargo, con paquetes más grandes, se asigna una porción más generosa del búfer. Por ejemplo, este es el cálculo para paquetes de 1024 bytes, donde cada paquete consume 4 nodos Q:
queue-limit percent 10 = 4590 Qnodes = 4590 paquetes de 1024 bytes = 4590*4*256 bytes = 4,7 MB = 40% del búfer
Si configura valores altos de porcentaje de límite de cola, una sola interfaz podría ocupar temporalmente todo el búfer compartido de 11,75 MB.
Conclusiones
- Puede ver claramente que la eficiencia de los bytes de límite de cola es mejor con paquetes pequeños: los bytes de límite de cola <x> funcionan mejor que el límite de cola <x> para hasta 300 bytes
- En paquetes de 300 bytes, los bytes de límite de cola y la eficiencia porcentual de límite de cola son iguales
- Tamaño de paquete de más de 300 bytes, el porcentaje de límite de cola es más eficiente. Dado que el tráfico de Internet es de una media de 518 bytes, esto significa que los escenarios de la vida real se benefician más del porcentaje de límite de cola, tal y como indican los clientes
- La eficiencia del porcentaje de límite de cola mejora linealmente en relación con el tamaño del paquete (cuanto más grandes sean los paquetes, más eficiente será el porcentaje de límite de cola frente a los bytes de límite de cola)
- El porcentaje de límite de cola se implementa para ser más generoso en la asignación de espacio de búfer para paquetes de más de 256 MB
Cómo aproximar los valores porcentuales en escenarios de tráfico real
En el caso de que tenga paquetes con un tamaño de 256 bytes y un límite de cola del 10%, ya sabe que esta equivalencia es válida:
minimum queue-limit = 4590 Qnodes = 4590*256 bytes = 1.175 MB = 10% of the buffer
Con los paquetes de 512 bytes solamente el uso es el doble, con los paquetes de 1024 bytes solamente es cuatro veces mayor, y así sucesivamente.
Esto significa que el límite de cola real es como mínimo el 10% del buffer y, si asume una MTU máxima de 1500 bytes, necesita 6 nodos Q para almacenar un solo paquete, lo que da un límite de cola máximo de:
maximum queue-limit = 4590*6 Qnodes = 4590*256*6 bytes = 7.05 MB = 60% of the buffer
De esta manera, puede definir los límites inferior y superior del uso del búfer con queue-limit percent 10, por lo que, en general, el uso máximo promedio del búfer es aproximadamente:
ceil(avg_pkt_size/256)*((qlimit_percent/45900)*100)
Ejemplo de un equipo de laboratorio:
GigabitEthernet0/0/1 is up, line protocol is up
Hardware is 24xGE-4x10GE-FIXED-S, address is 70df.2f2f.ed01 (bia 70df.2f2f.ed01)
Internet address is 10.12.10.47/31
MTU 8900 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 25/255, rxload 30/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, link type is auto, media type is T
output flow-control is unsupported, input flow-control is on
Carrier delay is 0 msec
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:01, output hang never
Last clearing of "show interface" counters 00:11:43
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 2036062
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
30 second input rate 118520000 bits/sec, 18902 packets/sec
30 second output rate 101646000 bits/sec, 16124 packets/sec
13185272 packets input, 10328798549 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 235 multicast, 0 pause input
11247114 packets output, 8870166880 bytes, 0 underruns <<< avg_pkt_size = 8870166880/11247114 = 788.66 bytes
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Puede calcular el tamaño_promedio_pkt_size como 8870166880/11247114 ~ 788 bytes.
Con un límite de cola por ciento 10, tiene un promedio de uso máximo de búfer de:
ceil(avg_pkt_size/256)*((45900/100)*qlimit_percent)
Calculation example with Python:
>>> import math
>>> math.ceil(788/256)*((45900/100)*10)
18360.0
=> 18360 Qnodes = 18360 * 256 bytes = 4.7 MB = 40% of the buffer
Cómo verificar el uso del búfer de microrráfaga
En las versiones de Cisco IOS-XE anteriores a 16.9.3, el buffer compartido de las interfaces se utilizaba para paquetes de datos y de control (como BFD, protocolos de ruteo, ARP, LDP, señales de mantenimiento de punt). Para verificar el uso del buffer instantáneo, puede utilizar este comando:
ASR-920-1#request platform software sdcli "nile bm reg buffertablefreelistcount show 0 0 0"
Después de 16.9.3 se han introducido algunos cambios para mejorar el uso del búfer y se ha dividido en 2: Se han reservado 1024 entradas (256 KB) para el tráfico de control y el resto se reserva para el tráfico de datos.
El uso del buffer en este caso se puede monitorear con estos comandos:
ASR-920-1#request platform software sdcli "nile bm reg supervisorresourcereservedcounttableaccess sh 0 0 0"
reservedUsedCount = 48 (0x30)
reservedFreeCount = 976 (0x3d0)
ASR-920-1#request platform software sdcli "nile bm reg supervisorresourcereservedcounttableaccess sh 0 2 0"
reservedUsedCount = 8114 (0x1fb2)
reservedFreeCount = 37784 (0x9398)
Observe que, dado el hecho de que el búfer controla las microrráfagas, debe repetir el comando muchas veces para ver el valor reservedUsedCount diferente de 0.
El uso del búfer se puede calcular simplemente con reservedUsedCount/reservedFreeCount; por ejemplo, 8114/37784 = 21,5% utilizado. Una vez finalizada la ráfaga, el búfer debe volver rápidamente a caer en 0 o cerca de 0.
A partir de la versión 17.6.1 de Cisco IOS-XE, se puede optar por utilizar el búfer completo para el tráfico de datos y de control (preferiblemente si la red tiene una alta velocidad de tráfico de control) o dividir el búfer en 2, como se ha descrito anteriormente. La elección se realiza con la configuración de esta instrucción (desactivada de forma predeterminada):
ACDC-920-1(config)#platform qos-buffer enhance enable
ACDC-920-1(config)#no platform qos-buffer enhance enable
Desde la versión 17.7.1 de Cisco IOS-XE, también es posible elegir el tamaño que se asignará al tráfico de control:
ACDC-920-1(config)#platform qos-buffer enhance [1-4]
Where:
- 1 indica un búfer de control de 256 KB
- 2 indica 500 KB
- 3 indica 756 KB
- 4 indica 1 MB
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
10-Oct-2022 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)