Routers : Routers Cisco de la serie 12000

WRED y MDRR en el Cisco 12000 Series Internet Router con una mezcla de unicast, de Multicast, y de ejemplo de configuración del tráfico de voz

13 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Abril 2015) | Comentarios


Contenido


Introducción

Este documento explica cómo configurar un linecard de las Cisco 12000 Series para el Weighted Random Early Detection (WRED), descrito en el RFC 2309leavingcisco.com , en un entorno multiservicios.

prerrequisitos

Requisitos

Quienes lean este documento deben tener conocimiento de lo siguiente:

Componentes Utilizados

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

  • Cualquier versión de software de Cisco IOS� que apoye al Cisco 12000 Series Internet Router. Por lo general, éstas son las versiones 12.0S y 12.0ST.

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

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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

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

Antecedentes

Las Cisco 12000 Series son una de la mayoría de las plataformas populares usadas para construir una red de núcleo IP del ancho de banda alto. Esta plataforma ofrece la posibilidad exclusiva de configurar el Calidad de Servicio (QoS).

Puesto que es cada vez más común mezclar diversos tipos de tráfico IP (tal como voz sobre IP - VoIP - y Multicast) en la misma red, los requisitos para el priorización y un comportamiento de caída controlado llegan a ser extremadamente importantes, y, en muchos casos, son la diferencia entre el éxito y el fracaso al iniciar un nuevo servicio tal como VoIP.

Los requisitos de la red para diversos tipos de tráfico IP están fuera del alcance de este documento. Este documento se centra en los pruebas de laboratorio realizados para encontrar una configuración que sea aplicable en las placas de línea diferentes, incluyendo las Cisco 12000 Series, linecard 3-Port Gigabit Ethernet (GbE 3-Port). Los resultados de estas pruebas muestran que el linecard del motor 2 del GbE 3-Port está bien adaptado para un entorno de red que implica una mezcla de Voz, de datos, y de tráfico Multicast. También prueba que eso configurar QoS hace una diferencia real en una red congestionada.

Clases de precedencia utilizadas en la prueba

Los valores de precedencia que se asignan a diversas clases necesitan ser lo mismo en toda la red. Usted necesita determinar una política genérica.

Clase Precedencia Tráfico
Tráfico malvado   Todo el no identificado del tráfico neto (apagado-red)
En la red --- en la red 1 Trafique que estancias dentro de la red SP (en red)
Servicios de Proveedor de servicios de Internet (ISP) 2 Tráfico ISP, S TP, POP, FTP, DNS, Telnet, SSH, WWW, https
PME (comercios pequeños y medianos) 3 Clientes de Enterprise, un servicio del oro
Tiempo real, no Voz 4 TV, juego en tiempo real
Voice 5 Tráfico de VoIP RTP
Mensajes del control de red 6-7 Border Gateway Protocol (BGP) y otros mensajes del control

Asignación de colores a los paquetes IP

Si se va QoS a ser implementado en la base de una red, un requisito previó es que el proveedor de servicio esté en el control total del valor de precedencia de todos los paquetes IP transportados en la red. La única manera de hacer esto es marcar todos los paquetes cuando ingresan la red, no haciendo ninguna distinción si vienen del lado del cliente/del usuario final o del Internet. Ninguna marca o colorante se debe hacer en la base.

‘Resultados esperados’

La meta con este diseño es tener comportamiento verdadero WRED en las clases 0-3. Esto significa que quisiéramos tener una situación donde comenzamos a caer la precedencia 0 paquetes durante la congestión. Después de eso, debemos también comenzar a caer la precedencia 1 si la congestión continúa, y entonces también la precedencia 2 y 3. Esto se describe todo en el gráfico abajo.

wred_behavior.gif

Usted debe tener el tiempo de espera más bajo posible para los paquetes de voz, y ningunos descensos en absoluto para la Voz y el tráfico Multicast.

Configuración de la red

Para probar y evaluar la configuración, utilizamos un Cisco 12410 así como un generador de paquete de Agilant. El Cisco 12000 Router está ejecutando una versión de ingeniería basada en el Cisco IOS Software Release 12.0(21)S1.

/image/gif/paws/22561/network_setup.gif

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

Los indicadores luminosos LED amarillo de la placa muestra gravedad menor del motor 2 tienen normalmente ocho colas de administración del tráfico del fromfab y una cola de tiempo de latencia bajo, y ocho colas de administración del tráfico del tofab por el slot de destino. Hay también una cola separada del Multicast del tofab. En el indicador luminoso LED amarillo de la placa muestra gravedad menor del GbE 3-Port, hay solamente una cola del fromfab por el puerto físico. En la prueba, la configuración que era aplicada especifica más colas de administración del tráfico. Los resultados muestran que el indicador luminoso LED amarillo de la placa muestra gravedad menor del GbE 3-Port valida esta configuración, y las colas de administración del tráfico se asocian automáticamente a las colas de administración del tráfico que están disponibles.

Algoritmo WRED del motor 2 en el software de Cisco IOS

Usted debe entender completamente el algoritmo usado para el WRED en el linecard del motor 2 al configurar el mínimo y los valores del Maximum Queue Depth. El código no cuida sobre el valor mínimo configurado; en lugar, utiliza su propia fórmula (basada en el valor máximo configurado) para fijar el valor mínimo.

Fórmula:

Valor mínimo = valor máximo - (el poder más alto de 2 que no genera un resultado negativo)

Los valores usados en esta prueba dieron lugar a los valores mínimos siguientes programados al circuito específico de la aplicación (ASIC):

Precedencia Mínimo configurado Máximo configurado El poder más alto 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

Usando esta fórmula calcular el valor mínimo significa que usted puede terminar para arriba con el paquete incorrecto que maneja el comportamiento si usted no toma esto en la consideración al configurar sus parámetros WRED. Esto se ilustra en el siguiente ejemplo:

Precedencia Mínimo configurado Máximo configurado El poder más alto 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 configura para comenzar a caer según la regla 0 primero, después 1, 2 y pasado 3 (arriba), cuando los valores se escriben a ASIC, usted comienza realmente a caer la precedencia 0, entonces la precedencia 2, entonces la precedencia 1, y pasado la precedencia 3. No hay manera de ver qué valores se han configurado en ASIC en un indicador luminoso LED amarillo de la placa muestra gravedad menor del motor 2. Si usted aplica la configuración en Motor 3 un indicador luminoso LED amarillo de la placa muestra gravedad menor, los valores que aparecen en la configuración serán los valores reales (el valor mínimo recalculado).

Configuración de QoS

Para más detalles sobre la configuración de QoS, lea por favor la comprensión y configurar del MDRR y del WRED en el Cisco 12000 Series Internet Router.

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, usted puede utilizar el comando rx-cos-slot all. En nuestro caso de prueba, teníamos algunos indicadores luminosos LED amarillo de la placa muestra gravedad menor que no soportaron el almacenamiento en cola tofab, así que no podríamos utilizar siempre el comando rx-cos-slot all. En lugar, asignamos nuestra slot-tabla al linecards que era utilizado 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 usted puede configurar su tx-CoS. Elija un nombre para sus qos del tx, tales como “cola de grupo cos el B2".

Cada valor de precedencia que usted quiere configurar un comportamiento del descenso para que las necesidades sean asociadas a un Random-detect-label separado.

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 Modified Deficit Round Robin (MDRR), asocie cada precedencia a una cola MDRR. En nuestro ejemplo, asociamos la precedencia 0-3 a la misma cola MDRR para reservar el ancho de banda para video (tráfico Multicast). Esta asignación proporciona la conducta solicitada.

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, que es porqué la precedencia 5 se asocia a la cola de tiempo de latencia bajo.

precedence 5 queue low-latency  

precedence 6 queue 6  

precedence 7 queue 6  

Ahora usted tiene que configurar el comportamiento de caída para cada uno del Random-detect-labels. Durante la prueba, estos números fueron cambiados hasta que los valores fueran encontrados que dieron el modelo deseado del descenso. Para los detalles, vea la sección de los resultados esperados. La profundidad de espera en cola se mide en la cola física, y no en el MDRR o la cola de la Rojo-escritura de la etiqueta.

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 basado en la clase, comportamiento del Weighted Fair Queuing (CBWFQ), dando a la diversa cola MDRR a la ponderación. El peso predeterminado es 10 por la cola. La cantidad de bytes transmitió cada ciclo MDRR es una función del valor de la ponderación. Un valor de 1 significa 1500 bytes cada ciclo. Un valor de 10 significa 1500+(9*512) los bytes por el ciclo.”

queue 0 20  

queue 4 20  

queue 6 20  

!  

Mapeo de interfaz

Cada interfaz necesita ser configurada para el WRED. Esto se hace usando los comandos:

  • configure terminal

  • carruaje 6/0 de la interfaz

  • tx-CoS B2

Inicio sin caídas

El flujo generado utiliza los valores siguientes a menos que se exponga el algo más:

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

126Mb MC, 114Mb voip

Esto da lugar a una secuencia de fondo de 240Mb (VoIP y Multicast).

Entonces agregamos cuatro secuencias de datos de los mismos tamaños, pero con la precedencia 0-3 (un valor de precedencia por la secuencia).

Cuatro secuencias de datos de 151 Mb cada una

Esta configuración da un ancho de banda total de 844Mb. El gráfico abajo muestra que hay las caídas de paquetes 0, y mismo una latencia baja (cerca de 50 nosotros - los microsegundos - para cada secuencia, incluyendo la Voz).

151mb.gif

Cuatro secuencias de datos de 160 Mb cada una

Esta configuración da un ancho de banda total de 880Mb. El gráfico abajo muestra que los paquetes comienzan a caer de la precedencia 0 clases, y el tiempo de espera para la Voz ha aumentado al ms 6 - los milisegundos.

/image/gif/paws/22561/160mb.gif

Cuatro secuencias de datos de 167 Mb cada una

Esta configuración da un ancho de banda total de 908Mb. Los descensos ahora están comenzando para la precedencia 1 clase también. El tiempo de espera del tráfico de voz sigue siendo lo mismo.

Nota: La secuencia no fue parada antes de ser aumentado, así que la diferencia entre el número de descensos en la secuencia 0 y 1 es acumulativa.

/image/gif/paws/22561/167mb.gif

Cuatro secuencias de datos de 191Mb cada uno

Cuando el ancho de banda total aumenta, los paquetes están comenzando a caer de la cola de la precedencia 2 también. El ancho de banda total que estamos intentando alcanzar para la interfaz de Ethernet Gigabite ahora es 1004Mb. Esto se ilustra en los contadores de error de secuencia en el gráfico abajo.

191mb.gif

Cuatro secuencias de datos de 244Mb cada una

Los errores de secuencia para la precedencia 3 están comenzando a aumentar también. Ésta es la primera muestra que los descensos comenzarán de esa cola. La cantidad total de ancho de banda que estamos intentando enviar la interfaz del GbE ahora es 1216 Mb. Observe que los descensos en el Multicast (MC) y la cola de la Voz es todavía cero, y el tiempo de espera de la cola de la Voz no ha aumentado.

/image/gif/paws/22561/244mb.gif

Detención y el comenzar

Todas las secuencias fueron paradas y comenzadas para generar un gráfico que ha borrado los contadores. Esto muestra cómo mirará durante la congestión alta. Como usted puede ver abajo, el comportamiento es deseado.

/image/gif/paws/22561/stop_start.gif

Eliminación total de QoS

Para probar que QoS mejora realmente el funcionamiento durante la congestión, QoS ahora se ha quitado y se ha congestionado la interfaz. Los resultados están abajo (el flujo generado utiliza los valores siguientes a menos que se exponga el algo más).

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

126Mb MC, 114Mb VoIP

Esto da lugar a una secuencia de fondo de 240Mb (VoIP y Multicast).

Entonces agregamos cuatro secuencias de datos de los mismos tamaños, pero con la precedencia 0-3 (un valor de precedencia por la secuencia).

Cuatro secuencias de datos de 153 Mb cada una

Esto da un total de 852Mb. Hay los descensos 0, y un tiempo de espera menos entonces 50 nosotros.

/image/gif/paws/22561/153mb.gif

Cuatro secuencias de datos de 158 Mb cada una

Comenzamos a caer en la utilización casi igual como cuando el WRED es aplicado (872Mb). La diferencia ahora es que hay un tiempo de espera de los paquetes de voz del ms 14 (más de dos veces tanto como en la prueba WRED), y que los descensos están ocurriendo igualmente de todas las clases, incluyendo el VoIP y el Multicast.

/image/gif/paws/22561/158mb.gif

Incorporación de la carga de ingreso

Hasta ahora, todas las pruebas han incluido solamente transmitir a través de las interfaces de Ethernet Gigabite. Para verificar cómo la interfaz reacciona en una situación donde también congestionamos la interfaz en la otra dirección, las pruebas siguientes fueron hechas.

Para esta prueba, cargamos la interfaz de Ethernet Gigabite con un importe total de 1056 Mb. Esto dio lugar a los descensos en la precedencia 0-2, ningunos descensos en el tráfico de la precedencia 3. (el MC y VOIP seguían siendo lo mismo, es decir, ningunos descensos). Entonces agregamos el tráfico en la otra dirección, tanto tráfico como el generador de paquete podía enviar a través de la interfaz de Ethernet Gigabite. El resultado es bastante impresionante: la congestión de recepción no interfiere en absoluto con la cola que transmite, y el tiempo de espera para el tráfico de recepción es extremadamente - bajo, menos de 13 nosotros para la Voz.

ingress_load1.gif

12-RP#show interfaces g 6/0

Usted 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 sean debido al ancho de banda que es lo mismo para todas las secuencias, cambiamos las secuencias de modo que transmitieran diversas cantidades de datos. También intentamos cambiar la Unidad máxima de transmisión (MTU) (MTU) así que era diferente para cada secuencia. Con los valores de la cola configurados, el resultado seguía siendo lo mismo, cayendo la precedencia 0 primero, después 1, entonces 2, y pasado la precedencia 3.

stream_size.gif

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

Puesto que el tiempo de espera de la cola VoIP (la cola de tiempo de latencia bajo) en la prueba era bastante alto, realizamos la misma prueba con 10-Port el linecard del dispositivo Ethernet Gigabit 4. Como se esperaba, el resultado con este linecard estaba mucho mejor con respecto al tiempo de espera en la cola de tiempo de latencia bajo (LLQ). Los resultados eran lo mismo en lo que respecta a cómo ocurrió la caída. El tiempo de espera para el LLQ estaba alrededor de 10us, que es 1:1000 del tiempo de espera en 3-Port el linecard del dispositivo Ethernet Gigabit 2.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 22561