Ejemplo de Configuración de WRED y MDRR en el Cisco 12000 Series Internet Router con una Combinación de Unidifusión, Multidifusión y Tráfico de Voz

Introducción

Este documento explica cómo configurar una tarjeta de línea Cisco 12000 Series para Weighted Random Early Detection (WRED), descrita en RFC 2309 , en un entorno de servicios múltiples.

Prerequisites

Requirements

Quienes lean este documento deben tener conocimiento de lo siguiente:

• Comprensión y configuración del MDRR y del WRED en el router de Internet de Cisco serie 12000

• Cómo leer el resultado del comando show controller frfab | Comandos tofab queue en un router de Internet de la serie 12000 de Cisco

• Tipo de servicio en Internet Protocol Suite, Precedence (RFC-1349)

• Detección temprana aleatoria ponderada

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software y hardware:

• Todos los lanzamientos de software Cisco IOS® que soporten el router de la serie de Internet 12000 de Cisco. Por lo general, éstas son las versiones 12.0S y 12.0ST.

• Este documento abarca todas las plataformas 12000 de Cisco Estos incluyen los 12008, 12012, 12016, 12404, 12406, 12410 y 12416.

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. If your network is live, make sure that you understand the potential impact of any command.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Antecedentes

La serie 12000 de Cisco es una de las plataformas más populares utilizadas para crear una red de núcleo IP de gran ancho de banda. Esta plataforma ofrece la posibilidad exclusiva de configurar la calidad del servicio (QoS).

Dado que cada vez es más común mezclar diferentes tipos de tráfico IP (como Voz sobre IP - VoIP - y multidifusión) en la misma red, los requisitos para la priorización y un comportamiento de descarte controlado se vuelven extremadamente importantes y, en muchos casos, son la diferencia entre éxito y fracaso al iniciar un nuevo servicio como VoIP.

Los requisitos de red para los diferentes tipos de tráfico IP están fuera del alcance de este documento. Este documento se centra en las pruebas de laboratorio realizadas para encontrar una configuración aplicable en diferentes tarjetas de línea, incluida la tarjeta de línea Cisco 12000 Series, Gigabit Ethernet de 3 puertos (GbE de 3 puertos). Los resultados de estas pruebas muestran que la tarjeta de línea de 3 puertos GbE Engine 2 es adecuada para un entorno de red que implica una combinación de tráfico de voz, datos y multidifusión. También demuestra que la configuración de QoS marca una diferencia real en una red congestionada.

Clases de precedencia utilizadas en la prueba

Los valores de precedencia asignados a diferentes clases deben ser los mismos en toda la red. Debe determinar una política genérica.

Clase	Precedencia	Tráfico
Tráfico malvado		Todo el tráfico neto no identificado (fuera de la red)
En la red: en la red	1	Tráfico que permanece dentro de la red SP (en la red)
Servicios de proveedor de servicios de Internet (ISP)	2	tráfico ISP, SMTP, POP, FTP, DNS, Telnet, SSH, www, https
PYME (pequeñas y medianas empresas)	3	Clientes empresariales, un servicio gold
Tiempo real, sin voz	4	TV, juegos en tiempo real
Voice	5	tráfico RTP VOIP
Mensajes de control de red	6-7	Protocolo de gateway fronterizo (BGP) y otros mensajes de control

Asignación de colores a los paquetes IP

Si se va a implementar QoS en el núcleo de una red, un prerrequisito es que el Proveedor de Servicios tenga el control total del valor de precedencia de todos los paquetes IP transportados en la red. La única manera de hacerlo es marcar todos los paquetes cuando ingresan a la red, sin hacer ninguna distinción si vienen del lado del cliente/usuario final o de Internet. No se debe marcar ni colorear el núcleo.

‘Resultados esperados’

El objetivo de este diseño es tener un verdadero comportamiento WRED en las clases 0-3. Esto significa que nos gustaría tener una situación en la que comencemos a descartar paquetes de precedencia 0 durante la congestión. Después de eso, también deberíamos empezar a descartar la precedencia 1 si la congestión continúa, y luego también la precedencia 2 y 3. Todo esto se describe en el gráfico siguiente.

Debe tener la latencia más baja posible para los paquetes de voz y ninguna pérdida para el tráfico de voz y multidifusión.

Configuración de la red

Para probar y evaluar la configuración, utilizamos un Cisco 12410 junto con un generador de paquetes de Agilant. El router Cisco 12000 está ejecutando una versión de ingeniería basada en la versión 12.0(21)S1 del software del IOS de Cisco.

Implementación de almacenamiento en cola 3-Port GbE del motor 2

Las tarjetas del motor 2 normalmente tienen ocho colas fromfab y una cola de latencia baja, y ocho colas tofab por ranura de destino. También hay una cola de multidifusión tofab independiente. En la tarjeta GbE de 3 puertos, sólo hay una cola fromfab por puerto físico. En la prueba, la configuración aplicada especifica más colas. Los resultados muestran que la tarjeta GbE de 3 puertos acepta esta configuración y que las colas se asignan automáticamente a las colas disponibles.

Algoritmo WRED del motor 2 en el software de Cisco IOS

Debe comprender completamente el algoritmo utilizado para WRED en la tarjeta de línea del Motor 2 al configurar los valores de profundidad de cola mínima y máxima. Al código no le importa el valor mínimo configurado; en su lugar, utiliza su propia fórmula (basada en el valor máximo configurado) para establecer el valor mínimo.

Fórmula:

Valor mínimo = Valor máximo - (la potencia máxima de 2 que no genera un resultado negativo)

Los valores utilizados en esta prueba dieron como resultado los siguientes valores mínimos programados para el circuito integrado específico de la aplicación (ASIC):

Precedencia	Mínimo configurado	Máximo configurado	Mayor potencia de 2	Valor mínimo en ASIC
0	50	5000	4096	5000-4096 = 904
1	60	6000	4096	6000-4096 = 1904
2	70	7000	4096	7000-4096 = 2904
3	80	8000	4096	8000-4096 = 3904

El uso de esta fórmula para calcular el valor mínimo significa que puede terminar con un comportamiento incorrecto de manejo de paquetes si no lo tiene en cuenta al configurar los parámetros WRED. Esto se ilustra en el siguiente ejemplo:

Precedencia	Mínimo configurado	Máximo configurado	Mayor potencia de 2	Valor mínimo en ASIC
0	50	150	128	150-128 = 22
1	75	225	128	225-128 = 97
2	100	300	256	300-256 = 44
3	125	375	256	375-256 = 119

Esto significa que, aunque los valores se configuran para comenzar a caer según la regla 0 primero, luego 1, 2 y por último 3 (arriba), cuando los valores se escriben en el ASIC, realmente comienza a descartar la precedencia 0, luego la precedencia 2, luego la precedencia 1 y, por último, la precedencia 3. No hay manera de ver qué valores se han configurado en el ASIC en una tarjeta del Motor 2. Si aplica la configuración en una tarjeta Engine 3, los valores que aparecen en la configuración serán los valores reales (el valor mínimo recalculado).

Configuración de QoS

Para obtener más detalles sobre la configuración de QoS, lea Introducción y configuración de MDRR y WRED en el router de Internet de la serie Cisco 12000.

Rx CoS

rx-cos-slot 2 B2-Table
rx-cos-slot 3 B2-Table
rx-cos-slot 6 B2-Table

En la mayoría de los casos, puede utilizar el comando rx-cos-slot all. En nuestro caso de prueba, teníamos algunas tarjetas que no soportaban la colocación en cola de tofab, así que no siempre podíamos usar el comando rx-cos-slot all. En su lugar, asignamos nuestra tabla de ranuras a las tarjetas de línea que se utilizan en la prueba.

!   
slot-table-cos B2-Table  
destination-slot all B2  
multicast B2  
!--- If you don't fulfill the steps above, you will not be able to reach the goal of 0 drops for Multicast traffic. With no rx-cos configured, multicast will be treated in the default queue, meaning it will drop as soon as there is congestion.

!

Tx QoS (Calidad del servicio)

Ahora puede configurar su tx-cos. Elija un nombre para su qos tx, como "cos-queue-group B2".

Cada valor de precedencia para el que desea configurar un comportamiento de descarte debe asignarse a una etiqueta de detección aleatoria independiente.

precedence 0 random-detect-label 0  

precedence 1 random-detect-label 1  

precedence 2 random-detect-label 2  

precedence 3 random-detect-label 3

Para el ordenamiento cíclico de déficit modificado (MDRR), asigne cada prioridad a una cola MDRR. En nuestro ejemplo, asignamos la precedencia 0-3 a la misma cola MDRR para reservar ancho de banda para el vídeo (tráfico multidifusión). Esta asignación proporciona el comportamiento solicitado.

precedence 0 queue 0  

precedence 1 queue 0  

precedence 2 queue 0  

precedence 3 queue 0  

precedence 4 queue 4 

La voz se marca con la precedencia 5, por lo que la precedencia 5 se asigna a la cola de latencia baja.

precedence 5 queue low-latency  

precedence 6 queue 6  

precedence 7 queue 6  

Ahora debe configurar el comportamiento de descarte para cada una de las etiquetas random-detect-. Durante las pruebas, estos números se cambiaron hasta que se encontraron los valores que dieron el patrón de descarte deseado. Para obtener más información, vea la sección Resultados esperados. La profundidad de la cola se mide en la cola física y no en la cola MDRR o RED-Label.

random-detect-label 0 50 5000 1  

random-detect-label 1 60 6000 1  

random-detect-label 2 70 7000 1  

random-detect-label 3 80 8000 1 

En el Cisco 12000, es posible crear un comportamiento de cola equilibrada ponderada y basada en clases (CBWFQ), dando a las diferentes colas MDRR un peso. El peso predeterminado es 10 por cola. El número de bytes transmitidos cada ciclo MDRR es una función del valor de peso. Un valor de 1 significa 1500 bytes cada ciclo. Un valor de 10 significa más de 1500 bytes (9*512) por ciclo".

queue 0 20  

queue 4 20  

queue 6 20  

!  

Mapeo de interfaz

Cada interfaz debe configurarse para WRED. Esto se realiza mediante los comandos:

• configure terminal

• interface gig 6/0

• tx-cos B2

Inicio sin caídas

La secuencia generada utiliza los siguientes valores a menos que se indique otra cosa:

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb voip

Esto da como resultado un flujo de fondo de 240 Mb (VoIP y multidifusión).

A continuación, agregamos cuatro secuencias de datos del mismo tamaño, pero con precedencia 0-3 (un valor de precedencia por secuencia).

Cuatro secuencias de datos de 151 Mb cada una

Esta configuración proporciona un ancho de banda total de 844 Mb. El gráfico de abajo muestra que hay 0 caídas de paquetes, y una latencia muy baja (unos 50 us - microsegundos - para cada flujo, incluyendo Voz).

Cuatro secuencias de datos de 160 Mb cada una

Esta configuración proporciona un ancho de banda total de 880 Mb. El gráfico siguiente muestra que los paquetes comienzan a caer de la clase de precedencia 0 y que la latencia para Voz ha aumentado a 6 ms - milisegundos.

Cuatro secuencias de datos de 167 Mb cada una

Esta configuración proporciona un ancho de banda total de 908Mb. Las caídas también se están iniciando para la clase de precedencia 1. La latencia del tráfico de voz sigue siendo la misma.

Nota: La secuencia no se detuvo antes de aumentarse, por lo que la diferencia entre el número de caídas en la secuencia 0 y 1 es acumulativa.

Cuatro secuencias de datos de 191Mb cada uno

Cuando el ancho de banda total aumenta, los paquetes también empiezan a caer de la cola de precedencia 2. El ancho de banda total que intentamos alcanzar para la interfaz Gigabit Ethernet es ahora de 1004Mb. Esto se ilustra en los contadores de errores de secuencia del gráfico siguiente.

Cuatro secuencias de datos de 244Mb cada una

Los errores de secuencia para la precedencia 3 también están empezando a aumentar. Este es el primer signo de que las caídas comenzarán desde esa cola. La cantidad total de ancho de banda que intentamos enviar a la interfaz GbE es ahora de 1216 Mb. Tenga en cuenta que las caídas en la cola de multidifusión (MC) y de voz siguen siendo cero y que la latencia de la cola de voz no ha aumentado.

Detención e inicio

Todas las secuencias se detuvieron y comenzaron a generar un gráfico que ha borrado los contadores. Esto muestra cómo se verá durante una congestión intensa. Como puede ver a continuación, el comportamiento es el deseado.

Eliminación total de QoS

Para demostrar que QoS mejora realmente el rendimiento durante la congestión, QoS se ha eliminado y la interfaz se ha congestionado. Los resultados se muestran a continuación (la secuencia generada utiliza los siguientes valores a menos que se indique otra cosa).

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb VoIP

Esto da como resultado un flujo de fondo de 240 Mb (VoIP y multidifusión).

A continuación, agregamos cuatro secuencias de datos del mismo tamaño, pero con precedencia 0-3 (un valor de precedencia por secuencia).

Cuatro secuencias de datos de 153 Mb cada una

Esto da un total de 852Mb. Hay 0 gotas y una latencia de menos de 50.

Cuatro secuencias de datos de 158 Mb cada una

Empezamos a caer en aproximadamente la misma utilización que cuando se aplica WRED (872Mb ). La diferencia ahora es que hay una latencia de paquetes de voz de 14 ms (más del doble que en la prueba WRED), y que las caídas se están produciendo por igual desde todas las clases, incluidos VoIP y multidifusión.

Incorporación de la carga de ingreso

Hasta ahora, todas las pruebas solo han incluido la transmisión a través de las interfaces Gigabit Ethernet. Para verificar cómo reacciona la interfaz en una situación en la que también congestionamos la interfaz en la otra dirección, se realizaron las siguientes pruebas.

Para esta prueba, cargamos la interfaz Gigabit Ethernet con una cantidad total de 1056 Mb. Esto resultó en caídas en la precedencia 0-2, sin caídas en el tráfico de precedencia 3. (MC y VOIP permanecieron iguales, es decir, no hubo caídas). Luego agregamos tráfico en la otra dirección, tanto tráfico como el generador de paquetes pudo enviar a través de la interfaz Gigabit Ethernet. El resultado es bastante impresionante: la congestión de recepción no interfiere en absoluto con la cola de transmisión, y la latencia para el tráfico de recepción es extremadamente baja, menos de 13 us para Voz.

12-RP#show interfaces g 6/0

Puede monitorear la carga en el link Gigabit usando el comando show interfaces:

Router#show interfaces gig 6/0
GigabitEthernet6/0 is up, line protocol is up
  Hardware is GigMac 3 Port GigabitEthernet, address is 0004.de56.c264 
  (bia 0004.de56.c264)
  Internet address is 178.6.0.1/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 232/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex mode, link type is force-up, media type is SX 
  output flow-control is unsupported, input flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output 00:00:05, output hang never
  Last clearing of "show interface" counters 08:52:40
  Queueing strategy: random early detection (WRED)
  Output queue 0/40, 2174119522 drops; input queue 0/75, 0 drops
  30 second input rate 838969000 bits/sec, 792079 packets/sec
  30 second output rate 910819000 bits/sec, 464704 packets/sec
    7584351146 packets input, 1003461987270 bytes, 0 no buffer
	Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
	0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
	0 watchdog, 514 multicast, 0 pause input
	11167110605 packets output, 2241229569668 bytes, 0 underruns
	0 output errors, 0 collisions, 0 interface resets
	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

Cambio del tamaño de las secuencias

Para verificar que los resultados de la prueba no se deben a que el ancho de banda sea el mismo para todos los flujos, cambiamos los flujos de modo que transmitieran diferentes cantidades de datos. También intentamos cambiar la unidad máxima de transmisión (MTU), por lo que era diferente para cada flujo. Con los valores de cola configurados, el resultado seguía siendo el mismo, dejando precedencia 0 primero, luego 1, luego 2 y finalmente precedencia 3.

Verificación con una tarjeta de línea Gigabit Ethernet Motor 4 de 10 puertos

Como la latencia de la cola VoIP (la cola de baja latencia) en la prueba era bastante alta, realizamos la misma prueba con la tarjeta de línea 10-Port Gigabit Ethernet Engine 4. Como se esperaba, el resultado con esta tarjeta de línea fue mucho mejor con respecto a la latencia en la cola de latencia baja (LLQ). Los resultados fueron los mismos con respecto a cómo ocurrió la caída. La latencia para el LLQ era de unos 10us, que es 1:1000 de la latencia en la tarjeta de línea de 3 puertos Gigabit Ethernet Engine 2.

Información Relacionada

• Comprensión y configuración del MDRR y del WRED en el router de Internet de Cisco serie 12000
• Cómo leer el resultado del comando show controller frfab | Comandos tofab queue en un router de Internet de la serie 12000 de Cisco
• Tipo de servicio en Internet Protocol Suite, Precedence (RFC-1349)
• Detección temprana aleatoria ponderada
• Soporte Técnico y Documentación - Cisco Systems