Routers : Routers Cisco de la serie 12000

Entienda y configure el MDRR/WRED en el Cisco 12000 Series Internet Router

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


Contenido


Introducción

Este documentos revisa cómo configurar las características de la administración de la congestión y de la prevención de congestión del software del ½ del ¿Â de Cisco IOSï en el Cisco 12000 Series Internet Router.

Después de que usted lea este documento, usted debe poder:

  • Entienda porqué es importante configurar el Modified Deficit Round Robin (MDRR) y el Weighted Random Early Detection (WRED) en su red del núcleo.

  • Entienda la implementación que es la base del MDRR y del WRED en las Cisco 12000 Series.

  • Configure MDRR y WRED utilizando la sintaxis heredada de Clase de servicio (CoS) y modular CLI QoS (MQC).

prerrequisitos

Requisitos

Quienes lean este documento deben tener conocimiento de los siguientes temas:

  • Una Familiaridad general con la arquitectura del Cisco 12000 Series Internet Router.

  • Particularmente, una conciencia de la arquitectura de espera y estos términos:

    • El tofab (hacia la tela) – que describe al lado de recepción hace cola en un linecard entrante.

    • El frfab (de la tela) – que describe al lado de transmisión hace cola en un linecard saliente.

Nota: También se recomienda que usted mira para arriba cómo leer la salida del controlador frfab de la demostración | Comandos tofab queues en un Cisco 12000 Series Internet Router.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Todas las Plataformas del Cisco 12000, que incluyen los 12008, 12012, 12016, 12404, 12406, 12410, y los 12416.

  • Cisco IOS Software Release 12.0(24)S1.

Nota: Aunque las configuraciones en este documento fueran probadas en el Cisco IOS Software Release 12.0(24)S1, cualquier versión de Cisco IOS Software que apoye al Cisco 12000 Series Internet Router puede ser utilizada.

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 las Convenciones de Consejos Técnicos de Cisco.

Antecedentes

Los métodos para colocación en cola definen el mecanismo de planificación del paquete o la orden en los cuales los paquetes dequeued a la interfaz para la transmisión en el alambre físico. De acuerdo con la orden y la cantidad de veces que una cola es mantenida por una función del planificador de trabajos, los métodos para colocación en cola también soportan las garantías mínimas del ancho de banda y las latencias bajas.

Es importante asegurarse de que un mecanismo de planificación del paquete soporta el Switching Architecture en las cuales se implementa. El Espera equitativa ponderada (WFQ) es el algoritmo de programación bien conocido para la asignación del recurso en las plataformas del router de Cisco con una arquitectura megabus basada. Sin embargo, no se soporta en el Cisco 12000 Series Internet Router. La espera tradicional y el Custom Queueing de la prioridad del Cisco IOS Software también no se soportan. En lugar, las Cisco 12000 Series utilizan una forma especial de hacer cola el Modified Deficit Round Robin (MDRR) llamado, que proporciona las garantías del ancho de banda relativo así como una cola de tiempo de latencia bajo. El M de significa MDRR “se modificó”; agrega el priority queue comparado al DRR donde no hay presente priority queue. Para los detalles en el MDRR, vea la sección de Descripción general de MDRR.

Además, la serie 12000 de Cisco admite la Detección temprana aleatoria ponderada (WRED) como política de caída para las colas MDRR. Este mecanismo de prevención de congestionamiento proporciona una alternativa al mecanismo predeterminado de la eliminación de cola. La congestión puede evitarse mediante eliminaciones controladas.

La prevención de congestión y los mecanismos de administración tales como WRED y MDRR son determinado importantes en las colas de administración del tráfico del frfab de las interfaces de salida relativamente de poca velocidad, tales como linecards canalizado (LC). El Switch Fabric de alta velocidad puede entregar los paquetes a los grupos de canal mucho más rápidamente que los grupos de canal pueden transmitirlos. Mientras que haciendo cola/los buffers se manejan en el nivel del puerto físico, el backpressure en un canal puede afectar el resto de los canales en ese puerto. Así, es muy importante manejar ese backpressure con el WRED/MDRR, que limita al backpressure el impacto a los canales en la pregunta. Para más información sobre cómo manejar la suscripción excesiva de la interfaz saliente, vea los paquetes ignorados del troubleshooting y ningunos descensos de la memoria en el Cisco 12000 Series Internet Router.

Descripción general de MDRR

Esta sección proporciona una descripción del Modified Deficit Round Robin (MDRR).

Con el MDRR configurado como la Estrategia de almacenamiento en cola, las colas de administración del tráfico no vacías se sirven uno tras otro, en una forma de cargas balanceadas. Cada vez que se sirve una cola, una cantidad fija de datos dequeued. El algoritmo entonces mantiene la cola siguiente. Cuando se sirve una cola, el MDRR no pierde de vista la cantidad de bytes de datos que dequeued superior al valor configurado. En el paso siguiente, cuando la cola se sirve otra vez, menos datos dequeued para compensar los datos en exceso que fueron servidos previamente. Como consecuencia, la cantidad promedio de datos dequeued por la cola estará cercana al valor configurado. Además, el MDRR mantiene un priority queue que consigue servido en una base preferencial. El MDRR se explica minuciosamente en esta sección.

Cada cola dentro del MDRR es definida por dos variables:

  • Valor determinado – Ésta es la cantidad de bytes media servida en cada uno redondo.

  • Contador en déficit – Esto se utiliza para seguir cuántos bytes ha transmitido una cola en cada uno redondo. Se inicializa al valor determinado.

Los paquetes en una cola se sirven mientras el contador en déficit sea mayor de cero. Cada paquete en servicio hace disminuir el contador en déficit en un valor equivalente a su longitud en bytes. Una cola no puede ser atendida después de que el contador en déficit sea cero o negativo. En cada uno la nueva ronda, el contador en déficit de cada cola no vacía es aumentada en su valor determinado.

Nota: Generalmente el tamaño del quántum para una cola no debe ser más pequeño que la Unidad máxima de transmisión (MTU) (MTU) de la interfaz. Esto se asegura de que el planificador de trabajos sirva siempre por lo menos un paquete de cada cola no vacía.

Se le puede adjudicar un peso relativo a cada cola MDRR. Una de las colas del grupo se define como cola de prioridad. Las ponderaciones asignan el ancho de banda relativo para cada cola cuando se congestiona la interfaz. El algoritmo MDRR dequeues los datos de cada cola en una forma de cargas balanceadas si hay datos en la cola que se enviará.

Si todas las colas MDRR regulares tienen datos, se atienden de la siguiente manera:

0-1-2-3-4-5-6-0-1-2-3-4-5-6…

Durante cada ciclo, una cola puede dequeue un quántum basado en su ponderación configurada. En el linecards del motor 0 y del motor 2, un valor de 1 es equivalente a dar a la interfaz a la ponderación de su MTU. Para cada incremento superior a 1, el peso de la cola aumenta en 512 bytes. Por ejemplo, si la MTU de una interfaz particular es 4470 y el peso de una cola está configurado como 3, son 4470 + (3-1)*512 = 5494 los bytes que pueden salir de la cola por vez a través de la rotación. Si se utilizan dos colas de administración del tráfico normales DRR, Q0 y Q1, el Q0 se configura con una ponderación de 1 y el Q1 se configura con una ponderación de 9. Si ambas colas de administración del tráfico se congestionan, cada vez con la rotación, Q0 fueran permitidas enviar 4470 bytes y el Q1 sería permitido enviar [4470 + (9-1)*512] = 8566 bytes. Esto daría el tráfico que va a Q0 aproximadamente 1/3 del ancho de banda, y el tráfico que pasa con el Q1 cerca de 2/3 del ancho de banda.

Nota: La fórmula estándar de la de-cola usada para computar la asignación del ancho de banda MDRR es D = MTU+ (weight-1)*512. En las versiones anterior que el Cisco IOS Software Release 12.0(21) S/ST, el linecards del motor 4 utilizó un diferente dequeue la fórmula. Para configurar la ponderación MDRR para una asignación de ancho de banda correcta, asegúrese de que usted funciona con una versión de Cisco IOS Software más adelante de 12.0(21) S/ST.

Nota: La fórmula del quántum para el linecards del motor 4+ es (para la dirección del tofab, ésta es inválida para el frfab) Quantum = BaseWeight + {BaseWeight * (QueueWeight - 1) * 512}/MTU. El BaseWeight se obtiene con esta fórmula: BaseWeight = {(MTU+ 512 - 1)/512} + 5

Nota:  Se completan todos los cálculos; es decir, todos los decimales se ignoran.

Nota: Para saber si un linecard del motor del específico soporta el MDRR, vea el soporte MDRR del tipo de motor.

Cola prioritaria de MDRR

Las Cisco 12000 Series soportan un priority queue (PQ) dentro del MDRR. Esta cola proporciona el retardo y la fluctuación baja bajos requeridos por el tráfico sensible al tiempo tal como voz sobre IP (VoIP).

Como se observó anteriormente el Cisco series 12000 no admite weighted fair queueing (WFQ). Por lo tanto, el PQ dentro de MDRR opera de manera diferente de la función de colocación en Cola de tiempo de latencia bajo (LLQ) del software del IOS de Cisco disponible para otras plataformas.

Una diferencia fundamental es cómo el programador MDRR puede ser configurado para mantener el PQ en uno de dos modos, como se lista en el cuadro 1:

Cuadro 1 – Cómo configurar al programador MDRR para mantener el PQ en dos modos

Modo alternativo Modo de prioridad estricta
Ventajas Aquí, el PQ se mantiene entre las otras colas de administración del tráfico. Es decir el programador MDRR alternativamente mantiene el PQ y cualquier otra colas de administración del tráfico configurada. Aquí el PQ se mantiene siempre que sea no vacío. Esto proporciona el retardo posible más bajo para el tráfico coincidente.
Desventajas Este modo puede introducir el jitter y retrasar cuando está comparado al modo de prioridad estricta. Este modo puede morir de hambre otras colas de administración del tráfico, determinado si los flujos que corresponden con son remitentes agresivos.

El modo alterno puede efectuar menos control en el jitter y retrasar. Si el programador MDRR comienza a mantener las tramas MTU clasificadas de una cola de los datos y entonces los paquetes de voz llegan en el PQ, el planificador de trabajos en el modo alterno sirve totalmente la cola sin prioridad hasta que sus alcances cero del contador en déficit. Durante este tiempo, el PQ no se mantiene, y se retrasan los paquetes de VoIP.

Por el contrario, en el modo de prioridad estricta, los servicios programador solamente el paquete no prioritario actual y entonces el Switches al PQ. El planificador de trabajos comienza a mantener una cola sin prioridad solamente después que el PQ llega a estar totalmente vacío.

Es importante observar que el priority queue en el modo de prioridad alterno está mantenido más de una vez en un ciclo, y toma así más ancho de banda que otras colas de administración del tráfico con la misma ponderación nominal. Cuánto más es una función de cuántas colas de administración del tráfico se definen. Por ejemplo, con tres colas de administración del tráfico, la cola de tiempo de latencia bajo se mantiene dos veces más a menudo que las otras colas de administración del tráfico, y envía dos veces su ponderación por el ciclo. Si se definen ocho colas, la cola de latencia baja recibe servicio con una frecuencia siete veces mayor y el peso eficaz es siete veces superior. Así, el ancho de banda que la cola puede tomar se relaciona con cuantas veces se sirve por el ordenamiento cíclico, que a su vez depende de cuántas colas de administración del tráfico se definen en conjunto. En el modo de prioridad alterno, el priority queue se configura generalmente con una pequeña ponderación por esta razón determinada.

Como un ejemplo, asuma que cuatro colas de administración del tráfico están definidas: 0, 1, 2 y el priority queue. En el modo de prioridad alterno, si se congestionan todas las colas de administración del tráfico, serían mantenidas como sigue: 0, llq, 1, llq, 2, llq, 0, llq, 1,…. donde llq representa la cola de latencia baja.

Cada vez que se le presta servicio a una cola, ésta puede enviar hasta su peso configurado. Por lo tanto, el ancho de banda mínimo que puede tener la cola de latencia baja es:

  • WL = ponderación de la cola de tiempo de latencia bajo.

  • W0, W1,… Wn = ponderaciones de las colas de administración del tráfico regulares DRR.

  • n = número de colas de administración del tráfico regulares DRR usadas para esta interfaz.

  • BW = ancho de banda del link.

Para el modo de prioridad alternativo, el ancho de banda mínimo de la cola de tiempo de latencia bajo= BW * n * WL / (n * WL + Sum(W0,Wn)).

La ponderación es el único parámetro variable en el MDRR que puede ser configurado. Influencia la cantidad relativa de ancho de banda que una clase de tráfico puede utilizar, y cuánto tráfico se envía en una vuelta. El uso de ponderaciones más grandes significa que el ciclo total dura, y aumenta posiblemente el tiempo de espera.

Pautas de Configuración

  • Es mejor configurar la ponderación de la clase que tiene los requerimientos de ancho de banda más bajos a 1 para guardar el retardo y el jitter tan bajo como sea posible entre las otras clases.

  • Seleccione valores de peso que sean tan bajos como sea posible. Comience con un peso de 1 para la clase con el ancho de banda más bajo. Por ejemplo, cuando usted utiliza dos clases con el ancho de banda del 50% para cada clase, usted debe configurar 1 y 1. No tiene sentido de utilizar 10 y 10, porque no hay impacto en el funcionamiento cuando usted elige 1. Además, un peso mayor introduce mayor fluctuación.

  • Un valor bajo de la ponderación para el LLQ es muy importante, especialmente en el modo alterno para no agregar demasiado retardo o estar inquieto a las otras clases.

Ejemplo de MDRR

El ejemplo en esta sección se toma por dentro de la arquitectura de software del ½ del ¿Â de Cisco IOSïÂ, Cisco Press.

Asuma que tenemos tres colas de administración del tráfico:

  • La cola 0 – tiene un quántum de 1500 bytes; es la cola de latencia baja, configurada para operar en el modo alternativo.

  • La cola 1 – tiene un quántum de 3000 bytes.

  • Queue 2 – tiene una cantidad determinada de 1500 bytes.

El cuadro 1 ilustra al estado inicial de las colas de administración del tráfico, junto con algunos paquetes se han recibido y se han hecho cola que.

Cuadro 1 – Estado inicial MDRR

mdrr_wred_18841a.gif

Se transmite la cola 0 se mantiene primero, su quántum se agrega a su contador en déficit, el paquete 1, que es 250 bytes, y su tamaño se resta del contador en déficit. Porque el contador en déficit de la cola 0 es todavía mayor de 0 (1500 - 250 = 1250), el paquete 2 se transmite también, y su longitud restada del contador en déficit. El contador en déficit de la cola 0 ahora es -250, así que la cola 1 se mantiene después. El cuadro 2 indica este estado.

Cuadro 2 – Estado subsiguiente MDRR

mdrr_wred_18841b.gif

Fijan al contador en déficit de la cola 1 a 3000 (0 + 3000 = 3000), y se transmiten los paquetes 4 y 5. Con cada paquete transmitido, reste el tamaño del paquete del contador en déficit, así que reducen al contador en déficit de la cola 1 a 0. cuadros 3 ilustra este estado.

Cuadro 3 – Estado MDRR cuando el contador en déficit de la cola 1 es cero

/image/gif/paws/18841/mdrr_wred_18841c.gif

Necesitamos volver del modo de prioridad alterno a la cola de servicios 0. Una vez más el quántum se agrega al contador en déficit actual, y fijan al contador en déficit de la cola 0 al resultado (-250 + 1500 = 1250). El paquete 3 es transmitido ahora debido a que el contador de déficit es mayor que 0 y la cola 0 se encuentra vacía. Cuando se vacía una cola, su contador de déficit se establece en 0, como se muestra en la Figura 4.

Cuadro 4 – Estado MDRR cuando se vacia una cola

/image/gif/paws/18841/mdrr_wred_18841d.gif

La cola 2 se mantiene después; Su contador en déficit se configura a 1500 (0 + 1500 = 1500). Se transmiten los paquetes 7 a 10, que deja al contador en déficit en 500 (1500 - (4*250) = 500). Porque el contador en déficit es todavía mayor de 0, el paquete 11 también se transmite.

Cuando el paquete 11 es transmitido, la cola dos está vacía y el contador de déficit está configurado en 0, como se muestra en la Figura 5.

Cuadro 5 – Estado MDRR cuando se transmite el paquete 11

/image/gif/paws/18841/mdrr_wred_18841e.gif

Luego, se vuelve a realizar un mantenimiento de la Cola 0 (ya que estamos en modo de prioridad alterna). Porque está vacía, la cola de servicios 1 después, y transmitimos el paquete 6.

Soporte MDRR por tipo de motor

Las Series 12000 de Cisco soportan cinco modelos de tarjeta de línea con Capa 3 única (L3) reenviando arquitecturas de motor. El soporte para el MDRR varía con motor L3 el tipo, y el tipo de indicador luminoso LED amarillo de la placa muestra gravedad menor. Por ejemplo, no hay soporte para el MDRR y el WRED en el linecards atmósfera del motor 0. Para determinar el tipo de motor L3 de las tarjetas de línea instaladas, puede utilizar el comando show diag.

router#show diags | include (SLOT | Engine)

!--- The regular expression is case-sensitive.

...
SLOT 1  (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode
  L3 Engine: 0 - OC12 (622 Mbps)
SLOT 3  (RP/LC 3 ): 3 Port Gigabit Ethernet
  L3 Engine: 2 - Backbone OC48 (2.5 Gbps)

MDRR en las colas de administración del tráfico del tofab (rx)

Usted puede utilizar la “sintaxis antigua del CoS” o la “interfaz de línea del comando modular qos” para configurar el MDRR en las Cisco 12000 Series. Las secciones posteriores en este documento discuten cómo configurar el MDRR con la herencia CoS o la Calidad del servicio (QoS) modular. Usted debe configurar las colas de administración del tráfico del tofab con la sintaxis antigua del CoS solamente pues no soportan el más nuevo sintaxis del MQC. Vea el cuadro 2 para los detalles.

Cuadro 2 – Detalles en el MDRR en las colas de administración del tráfico del tofab (rx)

Implementados Tofab MDRR Tofab PQ alterno ToFab Strict PQ ToFab WRED
Eng0 Software No ** No **
Eng1 - No No No No
Eng2 Hardware
Eng3 Hardware No
Eng4 Hardware
Eng4+ Hardware

** MDRR es soportado en Motores LC 0 en la dirección ToFab (Rx), pero sólo el modo prioridad estricta, no el modo prioridad alternada. Las siete colas restantes se admiten como de costumbre.

Las interfaces de entrada mantienen una cola de salida virtual separada por el destino LC. El modo de implementación de estas colas depende del tipo de motor L3.

  • Motor 0 – Los LC entrantes mantienen ocho colas de administración del tráfico por el slot de destino. Así, el número máximo de colas de administración del tráfico es 16x8 = 128. Cada cola se puede configurar por separado.

  • Motores 2, 3 , 4 y 4+ – Las LC entrantes mantienen ocho colas por interfaz de destino. Con 16 slots de destino y 16 interfaces por el slot, el número máximo de colas de administración del tráfico es 16x16x8 = 2048. Todas las interfaces en un slot de destino deben utilizar los mismos parámetros.

MDRR en colas FrFab (Tx)

El MDRR en las colas del frfab actúa constantemente si está implementado en el soporte físico o el software. Todo motor L3 teclea las colas de clases del soporte ocho para cada interfaz de salida. Vea el cuadro 3 para los detalles.

Cuadro 3 – Detalles en el MDRR en las colas de administración del tráfico del frfab (tx)

Implementados PQ alternativo de FrFab Frfab PQ estricto Frfab WRED
Eng0 Software1 No
Eng1 - No No No
Eng2 Hardware 2
Eng3 Hardware No
Eng4 Hardware
Eng4+ Hardware

1Support para el MDRR en las colas FrFab de motor 0 LC se introduce en estas versiones del Cisco IOS Software:

  • Cisco IOS Software Release 12.0(10)S - 4xOC3 y 1xOC12 POS, 4xOC3, y 1xCHOC12/ STM4.

  • Cisco IOS Software Release 12.0(15)S - 6xE3 y 12xE3.

  • Cisco IOS Software Release 12.0(17)S - 2xCHOC3/STM1.

2You debe configurar el sistema alterno de MDRR en la dirección FrFab con la sintaxis antigua del CoS.

Nota: El 3xGE LC soporta el MDRR en las colas de administración del tráfico del tofab y, como del Cisco IOS Software Release 12.0(15)S, en las colas de administración del tráfico del frfab con dos restricciones, a saber, un quántum fijo, y una sola cola de CoS para cada interfaz. El priority queue soporta un quántum que pueda ser configurado, y los modos de prioridad estrictos y alternos. Las tres interfaces comparten una única PQ.

Nota: Vea los Release Note de los Cisco 12000 Series Router para información de última hora sobre las características soportadas de QoS en las Cisco 12000 Series LC.

Información general sobre WRED

La detección temprana aleatoria ponderada (WRED) está diseñada para prevenir los efectos dañinos de la congestión de interfaz en el flujo de datos de la red.

Cuadro 6 – Probabilidad de caída de paquetes WRED

10778.gif

Vea el Weighted Random Early Detection en el Cisco 12000 Series Router para una explicación de los parámetros WRED. El mínimo, el máximo, y los parámetros de la probabilidad de la marca describen la curva real del Detección temprana aleatoria (RED). Cuando la media cargada de la cola está debajo del umbral mínimo, no se cae ningunos paquetes. Cuando la media cargada de la cola está sobre el umbral del almacenamiento en cola máximo, todos los paquetes se caen hasta los descensos medios debajo del umbral máximo. Cuando la media está entre el mínimo y los umbrales máximos, la probabilidad que el paquete será caído se puede calcular por una línea recta del umbral mínimo (la probabilidad del descenso será 0) al umbral máximo (la probabilidad del descenso es igual al denominador de probabilidad 1/mark).

La diferencia entre el ROJO y el WRED es que el WRED puede desechar selectivamente el tráfico de prioridad inferior cuando la interfaz comienza a conseguir congestionada, y puede proporcionar las características del rendimiento distinguidas para diversas Clases de servicio (CoS). Por abandono, el WRED utiliza un diverso perfil ROJO para cada ponderación (Prioridad IP - 8 perfiles). Descarta los paquetes menos importantes de manera más agresiva que los paquetes más importantes.

Es un desafío complejo para ajustar los parámetros WRED para manejar la profundidad de espera en cola, y depende de muchos factores, que incluyen:

  • Carga de tráfico y perfil ofrecidos.

  • Relación de transformación de la carga a la capacidad disponible.

  • Comportamiento del tráfico en presencia de la congestión.

Estos factores varían la red por la red y, a su vez, dependen de los servicios ofrecidos y de los clientes que utilizan esos servicios. Así, no podemos hacer las recomendaciones que se aplican a los entornos del cliente específicos. Sin embargo, el cuadro 4 describe generalmente los valores recomendados basados en el ancho de banda del link. En ese caso, no diferenciamos las características de eliminación entre las diferentes clases de servicios.

Cuadro 4 – Valores recomendados basados en el ancho de banda del link

Ancho de banda BW teórico (kbps) BW1 física (kbps) Umbral mínimo Umbral máximo
OC3 155000 149760 94 606
OC12 622000 599040 375 2423
OC48 2400000 239616 1498 9690
OC192 10000000 9584640 5991 38759

velocidad SONET 1Physical

Existen varias limitaciones que se consideran al calcular los valores de umbral anteriores. Por ejemplo, la maximización de la utilización del vínculo mientras que minimiza la profundidad de cola promedio, la diferencia entre el máximo y el mínimo deben ser un poder de dos (debido a la limitación del hardware). En función de la experiencia y simulación, la profundidad instantánea máxima de una cola controlada por RED es menor a 2 MaxTh. Para 0C48 y superiores, 1 MaxTh y así sucesivamente. No obstante, la determinación exacta de estos valores está más allá del alcance de este documento.

Nota: El valor del constante de equilibrio exponencial no necesita ser configurado en el motor 2 y sobre el linecards, puesto que el muestreo de la cola de hardware se utiliza en lugar de otro. Para el motor 0 LC, estos valores pueden ser configurados:

  • DS3 – 9

  • oc3 – 10

  • oc12 – 12

Nota: WRED no está soportada en LC de Motor 1.

Mientras que las secciones siguientes explican, usted puede utilizar la sintaxis antigua del CoS y la más nueva sintaxis MQC para configurar el WRED.

Utilice la sintaxis antigua del CoS para la configuración

La sintaxis de la clase de servicio (CoS) heredada del Cisco 12000 usa una plantilla cos-queue-group para establecer un conjunto de definiciones de CoS. Usted entonces aplica la plantilla a las colas de administración del tráfico del tofab y del frfab en entrante o las interfaces de salida, respectivamente.

Paso 1: Defina a una cola de grupo cos

El comando cos-queue-group crea una plantilla Nombrada del MDRR y de los parámetros WRED. Aquí están los parámetros de la configuración disponibles en el CLI:

Router(config)#cos-queue-group oc12
Router(config-cos-que)#?
Static cos queue commands:  

default                            Set a command to its defaults
dscp                               Set per DSCP parameters, Engine 3 only
exit                               Exit from COS queue group configuration mode
exponential-weighting-constant     Set group's RED exponential weight constant.
                                   (Not used by engine 0, 1 or 2 line cards)
no                                 Negate a command or set its defaults
precedence                         Set per precedence parameters
queue                              Set individual queue parmeters
random-detect-label                Set RED drop criteria
traffic-shape                      Enable Traffic Shaping on a COS queue group

Con el MDRR, usted puede asociar la Prioridad IP a las colas de administración del tráfico MDRR y configurar la cola de tiempo de latencia bajo especial. Usted puede utilizar el parámetro de precedente bajo comando cos-queue-group para esto:

precedence <0-7> queue [ <0-6> | low-latency]

Puede mapear una precedencia de IP específica a una cola MDRR regular (cola 0 a 6) o puede asignarla a la cola de prioridad. El comando anterior permite asociar varias precedencias IP con la misma cola.

Nota: Se recomienda que usted utiliza la precedencia 5 para la cola de tiempo de latencia bajo. La precedencia 6 se utiliza para las actualizaciones del router.

Usted puede dar a cada cola MDRR a la ponderación relativa, con una de las colas de administración del tráfico en el grupo definido como priority queue. Usted puede utilizar el comando queue bajo cola de grupo cos de hacer esto:

queue <0-6> <1-2048> 
queue low-latency [alternate-priority | strict-priority] <1-2048>

!--- The weight option is not available with strict priority.


Use el comando cos-queue-group para definir cualquier parámetro WRED:

random-detect-label  <label> <minimum-threshold> <maximum-threshold> 
    <mark-probability denominator>

Aquí está un ejemplo de una cola de grupo cos nombrada oc12. Define tres clases de tráfico: cola 0, 1, y latencia baja. Asocia los valores de precedencia IP 0 - 3 para hacer cola 0, los valores de precedencia 4, 6, y 7 para hacer cola 1, y la precedencia 5 a la cola de tiempo de latencia bajo. Se asigna mayor ancho de banda a la cola 1.

Ejemplo de configuración
cos-queue-group oc12

!--- Creation of cos-queue-group called "oc12".

precedence 0 queue 0

!--- Map precedence 0 to queue 0.

precedence 0 random-detect-label 0

!--- Use RED profile 0 on queue 0.

precedence 1 queue 0
precedence 1 random-detect-label 0
precedence 2 queue 0
precedence 2 random-detect-label 0
precedence 3 queue 0
precedence 3 random-detect-label 0

!--- Precedence 1, 2 and 3 also go into queue 0.

precedence 4 queue 1
precedence 4 random-detect-label 1
precedence 6 queue 1
precedence 6 random-detect-label 1
precedence 7 queue 1
precedence 7 random-detect-label 1
precedence 5 queue low-latency

!--- Map precedence 5 to special low latency queue.
!--- We do not intend to drop any traffic from the LLQ. We have an SLA 
!--- that commits not to drop on this queue. You want to give it all 
!--- the bandwidth it requires.

Random-detect-label 0 375 2423 1

!--- Minimum threshold 375 packets, maximum threshold 2423 packets. 
!--- Drop probability at maximum threshold is 1.

random-detect-label 1 375 2423 1
queue 1 20

!--- Queue 1 gets MDRR weight of 20, thus gets more Bandwidth.

queue low-latency strict-priority

!--- Low latency queue runs in strict priority mode.

Paso 2 - Cree un slot-table-cos para colas ToFab

Para evitar el jefe de la línea que bloquea, las interfaces de entrada en las Cisco 12000 Series mantienen una cola de salida virtual por el slot de destino. Vaya a un linecard usando el comando attach y ejecute ejecutar-en el comando show controller tofab queue (o ingrese directamente el execute-on slot 0 comandos show controllers tofab queue) de ver estas colas de salida virtual. La salida de muestra capturada directamente de la consola LC se proporciona abajo. Vea cómo leer la salida del controlador frfab de la demostración | Comandos tofab queues en un Cisco 12000 Series Internet Router.

LC-Slot1#show controllers tofab queues
 Carve information for ToFab buffers
  SDRAM size: 33554432 bytes, address: 30000000, carve base: 30029100
  33386240 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize, 2 carve(s)
  max buffer data size 9248 bytes, min buffer data size 80 bytes
  40606/40606 buffers specified/carved
  33249088/33249088 bytes sum buffer sizes specified/carved
            Qnum    Head    Tail        #Qelem     LenThresh
            ----    ----    ----        ------     ---------
       5 non-IPC free queues:

            20254/20254    (buffers specified/carved), 49.87%, 80 byte data size
            1       17297   17296       20254      65535
            12152/12152    (buffers specified/carved), 29.92%, 608 byte data size
            2       20548   20547       12152      65535
            6076/6076    (buffers specified/carved), 14.96%, 1568 byte data size
            3       32507   38582       6076       65535
            1215/1215    (buffers specified/carved), 2.99%, 4544 byte data size
            4       38583   39797       1215       65535
            809/809    (buffers specified/carved), 1.99%, 9248 byte data size
            5       39798   40606       809        65535
       IPC Queue:
            100/100 (buffers    specified/carved), 0.24%, 4112 byte data size
            30      72      71          100        65535
       Raw  Queue:
            31      0       17302       0          65535
       
       ToFab Queues:
               Dest
            Slot
            0       0       0           0          65535
            1       0       0           0          65535
            2       0       0           0          65535
            3       0       0           0          65535
            4       0       0           0          65535
            5       0       17282       0          65535
            6       0       0           0          65535
            7       0       75          0          65535
            8       0       0           0          65535
            9       0       0           0          65535
            10      0       0           0          65535
            11      0       0           0          65535
            12      0       0           0          65535
            13      0       0           0          65535
            14      0       0           0          65535
            15      0       0           0          65535
     Multicast      0       0           0          65535
    LC-Slot1#

Utilice el comando slot-table-cos de asociar a una cola de grupo cos Nombrada a una cola de salida virtual del destino. Usted puede configurar una plantilla única de la cola de grupo cos para cada cola de salida

Router(config)#slot-table-cos table1
Router(config-slot-cos)#destination-slot ?
  <0-15>  Destination slot number
  all     Configure for all destination slots
Router(config-slot-cos)#destination-slot 0 oc48
Router(config-slot-cos)#destination-slot 1 oc48
Router(config-slot-cos)#destination-slot 2 oc48
Router(config-slot-cos)#destination-slot 3 oc48
Router(config-slot-cos)#destination-slot 4 oc12
Router(config-slot-cos)#destination-slot 5 oc48
Router(config-slot-cos)#destination-slot 6 oc48
Router(config-slot-cos)#destination-slot 9 oc3
Router(config-slot-cos)#destination-slot 15 oc48

Nota: La configuración antedicha utiliza tres plantillas, oc48 Nombrado, el oc12, y el oc3. La configuración para la cola de grupo cos nombrada oc12 está tal y como se muestra en de Step1. Semejantemente, oc3 de la configuración y oc48. Se recomienda que usted aplica una plantilla única a un conjunto de las interfaces basadas en el ancho de banda y la aplicación.

Paso 3 - Aplique el slot vector lechuga romana a una interfaz de entrada

Use el comando rx-cos-slot para aplicar un slot-table-cos a un LC.

Router(config)#rx-cos-slot 0 ?
  WORD  Name of slot-table-cos
Router(config)#rx-cos-slot 0 table1
Router(config)#rx-cos-slot 2 table1

Paso 4 - Aplique a una cola de grupo cos a una interfaz de salida

Las Cisco 12000 Series mantienen una cola aparte por la interfaz de salida. Para ver estas colas de administración del tráfico, asocie al linecard CLI. Utilice el comando attach, y después ejecute el comando show controller frfab queue, según lo ilustrado aquí:

LC-Slot1#show controller frfab queue
    ========= Line Card (Slot 2) =======
  Carve information for FrFab buffers
   SDRAM size: 16777216 bytes, address: 20000000, carve base: 2002D100
   16592640 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize, 2 carve(s)
   max buffer data size 9248 bytes, min buffer data size 80 bytes
   20052/20052 buffers specified/carved
   16581552/16581552 bytes sum buffer sizes specified/carved
            Qnum    Head       Tail               #Qelem  LenThresh
            ----    ----       ----               ------  ---------
       5 non-IPC free queues:
            9977/9977 (buffers    specified/carved), 49.75%, 80 byte data size
            1       101        10077              9977    65535
            5986/5986 (buffers    specified/carved), 29.85%, 608 byte data size
            2       10078      16063              5986    65535
            2993/2993 (buffers    specified/carved), 14.92%, 1568 byte data size
            3       16064      19056              2993    65535
            598/598 (buffers    specified/carved), 2.98%, 4544 byte data size
            4       19057      19654              598     65535
            398/398 (buffers    specified/carved), 1.98%, 9248 byte data size
            5       19655      20052              398     65535
       IPC Queue:
            100/100 (buffers    specified/carved), 0.49%, 4112 byte data size
            30      77         76                 100     65535
       Raw Queue:
            31      0          82                 0       65535
       Interface Queues:
            0       0          0                  0       65535
            1       0          0                  0       65535
            2       0          0                  0       65535
            3       0          0                  0       65535

Utilice el comando tx-cos de aplicar una plantilla de la cola de grupo cos a una cola de la interfaz. Como se muestra aquí, usted aplica el parámetro configurado directamente a la interfaz; no hay tablas necesarias. En este ejemplo, pos48 es el nombre de un parámetro configurado.

Router(config)#interface POS 4/0
Router(config-if)#tx-cos ?
  WORD  Name of cos-queue-group
Router(config-if)#tx-cos pos48

Utilice el comando show cos para confirmar su configuración:

Router#show cos

!--- Only some of the fields are visible if MDRR is configured on Inbound 
!--- or Outbound interfaces.

Interface      Queue cos Group
Gi4/0             eng2-frfab

!--- TX-cos has been applied.

Rx Slot        Slot Table
4             table1

!--- rx-cos-slot has been applied.

Slot Table Name - table1
1           eng0-tofab
3           eng0-tofab

!--- slot-table-cos has been defined.

cos Queue Group - eng2-tofab

!--- cos-queue-group has been defined.

Prec    Red Label [min, max, prob]      Drr Queue [deficit]
0       0 [6000, 15000, 1/1]                  0 [10]
1       1 [10000, 20000, 1/1]                 1 [40]
2       1 [10000, 20000, 1/1]                 1 [40]
3       1 [10000, 20000, 1/1]                 0 [10]
4       2 [15000, 25000, 1/1]                 2 [80]
5       2 [15000, 25000, 1/1]                 2 [80]
6       no drop                               low latency
7       no drop                               low latency

Nota: La herencia CLI también utiliza la sintaxis de precedencia para el tráfico del Multiprotocol Label Switching (MPLS). El router trata los bits MPLS como si son bits del tipo de servicio IP (TOS) y pone los paquetes apropiados en las colas de administración del tráfico correctas. Esto no es cierto para MQC. El MPLS QoS está fuera del ámbito de este documento.

Utilice el Modular QoS CLI (MQC) para la configuración

El objetivo del Modular QoS CLI (MQC) de Cisco es conectar todas las características diferentes de QoS en una manera lógica, para simplificar la configuración de las características del Calidad de Servicio (QoS) del Cisco IOS Software. Por ejemplo, la clasificación se hace por separado de la espera, de la vigilancia, y de formar. Proporciona un solo marco de la configuración para QoS que sea basado en plantillas. Aquí están algunas puntas a recordar sobre la configuración de MQC:

  • Puede ser aplicada fácilmente a y ser quitada de una interfaz.

  • Puede ser reutilizada fácilmente (la misma directiva se puede aplicar a las interfaces múltiples).

  • Ofrece un solo marco de la configuración para QoS que permita le para provision, para monitorear fácilmente, y al Troubleshooting.

  • Proporciona un de alto nivel de la abstracción.

  • Es independiente de la plataforma.

En las Cisco 12000 Series, los comandos mqc pueden ser utilizados en vez del sintaxis del Clase de Servicio (CoS) de la herencia.

El soporte MQC en las Cisco 12000 Series no implica que lo mismo función de calidad de servicio (QoS) fija disponible en otra plataforma, tal como las Cisco 7500 Series, está disponible ahora en el Cisco 12000. El MQC proporciona una sintaxis común en la cual un comando dé lugar a una función o a un comportamiento compartida. Por ejemplo, el comando bandwidth implementa una garantía mínima del ancho de banda. Las Cisco 12000 Series utilizan el MDRR como el mecanismo de planificación para hacer la reserva de ancho de banda, mientras que las Cisco 7500 Series utilizan el WFQ. El algoritmo del principal complementa la plataforma particular.

Importantemente, solamente las colas de administración del tráfico del frfab soportan la configuración de las características de QoS con el MQC. Porque las colas de administración del tráfico del tofab son colas de salida virtual, y colas de entrada no verdaderas, no son soportadas por el MQC. Deben ser configuradas con los comandos de CoS de la herencia.

Soporte de las listas del cuadro 5 para el MQC por motor L3 el tipo.

Cuadro 5 – Soporte para el MQC para motor L3 los tipos

Tipo de motor L3 Motor 0 Motor 1 Motor 2 Motor 3 Motor 4 Motor 4+
Soporte' MQC. No
Versión del IOS 12.0(15)S - 12.0(15)S1 12.0(21)S 12.0(22)S 12.0(22)S

1Remember estas excepciones con el soporte MQC en el linecards del motor 0 y 2 (LC) s:

  • 2xCHOC3/STM1 – Incorporado en 12.0(17)S.

  • 1xOC48 DPT – Introducido en 12.0(18)S.

  • 8xOC3 ATM - Planificado para 12.0(22)S.

El MQC utiliza estos tres pasos para crear a política de calidad de servicio (QoS):

  1. Defina una o más clases de tráfico con el comando class-map.

  2. Cree una política de calidad de servicio (QoS) con el comando policy-map y asigne acciones de QoS, tales como ancho de banda o prioridad a una clase de tráfico con nombre.

  3. Utilice el comando service-policy de asociar un directiva-mapa a la cola del frfab de una interfaz de salida.

Utilice el comando show policy-map interface de monitorear su directiva.

Vea la descripción de la Interfaz de Línea de Comando de Calidad de Servicio Modular para más información.

Paso 1 - Defina class-maps

Utilizan al comando class-map de definir las clases de tráfico. Internamente, en las Cisco 12000 Series, el comando class-map asigna una clase a una cola específica de CoS en el linecard (véase el paso 4 para los detalles).

El comando class-map soporta el “match-any”, que coloca los paquetes que hacen juego las declaraciones de coincidencia unas de los en la clase, y el “corresponda con todos”, que coloca los paquetes en esta clase solamente cuando todas las declaraciones son verdades. Estos comandos crean una clase nombrada el "Prec_5", y clasifican todos los paquetes con una Prioridad IP de 5 a esta clase:

Router(config-cmap)#match ?
  access-group         Access group
  any                  Any packets
  class-map            Class map
  destination-address  Destination address
  fr-dlci              Match on fr-dlci
  input-interface      Select an input interface to match
  ip                   IP specific values
  mpls                 Multi Protocol Label Switching specific values
  not                  Negate this match result
  protocol             Protocol
  qos-group            Qos-group
  source-address       Source address
Router(config-cmap)#match ip precedence 5

El cuadro 6 enumera los criterios de concordancia soportados para cada uno motor L3 tipo.

Cuadro 6 – Criterios de concordancia soportados para los motores L3

Motor 0, 2 Motor 3 Motor 4 Motor 4+
Prioridad IP 1
acceso-grupo No No No
exp de los mpls No No Sí (12.0.26S)
dscp del IP No No Sí (12.0.26S)
qos-grupo No No No
x/y de la interfaz de entrada POS de la coincidencia No Sí (únicamente como política de recepción) No No

1 ingreso/salida desde 12.0.26S

Paso 2 - Cree un directiva-mapa

Utilizan al comando policy-map de asignar las políticas de manejo de paquete o las acciones a una o más clases definidas. Por ejemplo, cuando usted asigna una reserva de ancho de banda, o aplique un perfil al azar del descenso.

Las Cisco 12000 Series soportan un subconjunto de características MQC, sobre la base de la arquitectura de alta velocidad de los motores L3. El cuadro 7 enumera los comandos se soportan que:

Cuadro 7 – Comandos admitidos

Comando Descripción
ancho de banda Proporciona una garantía mínima del ancho de banda durante los períodos de congestión. Se especifica como porcentaje de la velocidad del link o como valor absoluto. Si una clase no utiliza ni necesita el ancho de banda igual al kbps reservado, el ancho de banda disponible se puede utilizar por otras clases de ancho de banda.
police, shape Limita la cantidad de tráfico que una clase puede transmitir. Estos comandos son levemente diferentes en la función. El comando police identifica el tráfico que excede el configuré el ancho de banda, y lo cae o comenta. Los buffers de comando shape cualquier tráfico en exceso y lo programan para la transmisión a una velocidad constante, pero no caen ni comentan.
Límite de cola Asigna una longitud fija de cola a una clase determinada de tráfico. Usted puede especificar esto en número de los paquetes que se pueden sostener en la cola.
prioridad Identifica una cola como cola de tiempo de latencia bajo. MQC admite el modo estricto solamente para un PQ. No soportan al modo alterno con el MQC. Utilice el comando priority sin un valor del porcentaje de habilitar al modo de prioridad estricta.

Nota: La implementación del comando priority en las Cisco 12000 Series diferencia de la implementación en el otro Routers que funciona con el Cisco IOS Software. En esta plataforma, el tráfico de prioridad no se limita al valor configurado del kbps durante los períodos de congestión. Así, usted debe también configurar el comando police de limitar cuánto ancho de banda puede utilizar y asegurar una clase de prioridad a ancho de banda adecuado para otras clases. Ahora, soportan al comando police solamente en Motor 3 el linecards. En el otro linecards del motor, solamente se permite el class-default cuando usted configura una clase de prioridad.

al azar-detecte Asigna un perfil WRED. Utilice el comando random-detect precedence de configurar los valores no valor por defecto WRED por el valor de precedencia IP.

En Motor 3 los LC, usted debe configurar las colas de administración del tráfico del frfab con el Modular QoS CLI (MQC); la interfaz de línea del comando legacy (CLI) no se soporta.

Cuando usted configura el comando bandwidth, observe que los LC del motor 0 y 2 soportan seis clases de ancho de banda solamente. Una séptima clase se puede utilizar para el servicio de la latencia baja y una octava clase, que es class-default, se utiliza para todo el tráfico NON-que corresponde con. Por lo tanto, tiene un total de ocho colas. Class-default no se utiliza como clase de prioridad.

En Motor 3 los LC, traducen a un valor del kbps, que varía con la velocidad subyacente del vínculo, y después se configuran al comando bandwidth percent directamente en la cola. La precisión de esta garantía mínima del ancho de banda es 64 kbps.

Aunque no se haga ninguna conversión a un valor determinado con el comando bandwidth, todas las colas de administración del tráfico tienen un quántum. En Motor 3 los LC, el valor determinado se fija internamente basado en la Unidad máxima de transmisión (MTU) (MTU) de la interfaz, y se fija igualmente para todas las colas de administración del tráfico. No hay un mecanismo MQC CLI para modificar este valor determinado, ni directa ni indirectamente. El valor determinado debe ser mayor o igual el MTU de interfaz. Internamente, el valor determinado está en las unidades de 512 bytes. Así, con un MTU de 4470 bytes, el valor determinado mínimo del MTU debe ser 9.

MDRR en Motor 3 el LC

Esta sección proporciona las notas de configuración para implementar el WRED y el MDRR en Motor 3 los LC.

  • El ancho de banda MDRR configurado en el CLI se traduce a una cantidad correspondiente al L2 (por ejemplo, se quitan los gastos indirectos L1). Esa cantidad luego se redondea en los próximos 64 kbps y se programa en el hardware.

  • Tres perfiles de WRED diferentes son admitidos para una sola clase.

  • El WRED (umbral máximo - umbral mínimo) se aproxima al poder más cercano de 2. El umbral mínimo entonces se ajusta automáticamente mientras que el umbral máximo se mantiene sin cambios.

  • Es admitido el valor 1 de mark probability.

  • La configuración constante de equilibrio exponencial no se soporta.

  • Se soportan la Prioridad IP, los bits MPLS EXP, y los valores DSCP.

Nota: Cada puerto o canal en el tetra (4GE-SFP-LC=) o CHOC12/DS1-IR-SC= las placas de línea de congelamiento tiene cuatro colas de administración del tráfico afectadas un aparato por abandono. Las cuatro colas de administración del tráfico consisten en el siguiente:

  • Una clase del priority queue (LLQ)

  • Una clase de la cola predeterminada

  • Dos clases no prioritarias normales

Al aplicar una servicio-directiva que contiene más que estas cuatro clases (1 HPQ, 2 LPQs y class-default) a la interfaz, el error siguiente será señalado:

La #service-directiva del router (config-if) hizo salir la MDRR-directiva

% no bastantes recursos de los Datos en espera disponibles para satisfacer la petición.

A partir de 12.0(26)S, un comando se ha agregado para el tetra linecard 4GE-SFP-LC= que permite la configuración de ocho queues/VLAN en vez de cuatro. Las ocho colas de administración del tráfico consisten en el siguiente:

  • Un LLQ

  • Una cola del class-default

  • Seis colas de administración del tráfico normales

El uso de este comando requerirá una recarga del microcódigo del linecard y dará lugar a la capacidad de configurar solamente 508 VLA N en vez de 1022. La sintaxis de los comandos es la siguiente:

[no] colas de la interfaz 8 de los qos del <slot-> del hw-module slot

Por ejemplo:

colas de la interfaz 8 de los qos del slot 2 del Router(config)#hw-módulo

Advertencia: Por favor recarga de micro el linecard para que este comando tome el efecto

Recarga 2 de Router(config)#microcode

Este comando estará disponible para CHOC12/DS1-IR-SC= la placa de línea de congelamiento en 12.0(32)S

Ejemplo #1 - comando bandwidth percent

Este ejemplo asigna el 20 por ciento del ancho de banda disponible al tráfico de clase Prec_4 y el 30 por ciento al tráfico de clase Prec_3. Deja el 50 por ciento restante al clase class-default.

Además, configura WRED como el mecanismo de descarte en todas las clases de datos.

Ejemplo #1 - porcentaje de ancho de banda
policy-map GSR_EXAMPLE
 class Prec_4
  bandwidth percent 20
  random-detect
  random-detect precedence 4 1498 packets 9690 packets 1 

  !--- All data classes should have WRED configured.

 class Prec_3
  bandwidth percent 30
  random-detect
  random-detect precedence 3 1498 packets 9690 packets 1
 class class-default

!--- Class-default uses any leftover bandwidth. 


  random-detect
  random-detect precedence 2 1498 packets 9690 packets 1
  random-detect precedence 1 1498 packets 9690 packets 1
  random-detect precedence 0 1498 packets 9690 packets 1

Ejemplo #2 - comando bandwidth {kbps}

Este ejemplo ilustra cómo aplicar el comando bandwidth como valor absoluto del kbps en vez de un porcentaje.

Ejemplo #2 - ancho de banda {kbps}
policy-map GSR_EXAMPLE
 class Prec_4
  bandwidth 40000 

!--- Configures a minimum bandwidth guarantee of 40000 kbps or 40 Mbps in 
!--- times of congestion.
 
  Random-detect

  random-detect precedence 4 1498 packets 9690 packets 1
 class Prec_3
  bandwidth 80000

!--- Configures a minimum bandwidth guarantee of 80000 kbps or 80 Mbps in 
!--- times of congestion.

  Random-detect
  random-detect precedence 3 1498 packets 9690 packets 1
 class class-default

!--- Any remaining bandwidth is given to class-default.

  Random-detect
  random-detect precedence 2 1498 packets 9690 packets 1
  random-detect precedence 1 1498 packets 9690 packets 1
  random-detect precedence 0 1498 packets 9690 packets 1

Ejemplo Nº 3: comando priority

Este ejemplo se diseña para los proveedores de servicio que utilizan al Cisco 12000 Series Router como router del borde del proveedor MPLS (PE) y necesitan configurar una política de servicio de QoS en el link entre el router PE y el router de la frontera del cliente (CE). Coloca la Prioridad IP 5 paquetes en un priority queue, y limita la salida de esa cola al 64 Mbps. Entonces asigna una porción del ancho de banda restante a las clases de ancho de banda.

Todas las colas de clases no prioritarias se configuran con el comando random-detect de habilitar el WRED como la política para tirar paquetes. Toda la clase de ancho de banda y class-default deben tener WRED configurado explícitamente.

Ejemplo #3 - prioridad
policy-map foo
  class Prec_5
    police 64000000 conform-action transmit exceed-action drop

!--- The police command is supported on Engine 3 line cards.

    priority
  class Prec_4
    bandwidth percent 30
    random-detect
    random-detect precedence 4 1498 packets 9690 packets 1
  class Prec_3
    bandwidth percent 10
    random-detect
    random-detect precedence 3 1498 packets 9690 packets 1
  class Prec_2
    bandwidth percent 10
    random-detect
    random-detect precedence 2 1498 packets 9690 packets 1
  class Prec_1
    bandwidth percent 10
    random-detect
    random-detect precedence 1 1498 packets 9690 packets 1
  class Prec_0
    bandwidth percent 25
    random-detect
    random-detect precedence 0 1498 packets 9690 packets 1
  class class-default
    random-detect
    random-detect precedence 6 1498 packets 9690 packets 1
    random-detect precedence 7 1498 packets 9690 packets 1

Paso 3 - Asigne un directiva-mapa a una cola de la interfaz de salida

Como se mencionó anteriormente, el MQC trabaja solamente con las colas de administración del tráfico del frfab en una interfaz de salida. Para aplicar un directiva-mapa definido, utilice el comando service-policy output, como se muestra aquí:

Router(config)#interface POS 0/0
Router(config-if)#service-policy ?
  history  Keep history of QoS metrics
  input    Assign policy-map to the input of an interface
  output   Assign policy-map to the output of an interface
Router(config-if)#service-policy output ?
  WORD  policy-map name
Router(config-if)#service-policy output GSR_EXAMPLE

Paso 4 - Monitoree y verifique la política de servicio

Utilice el comando show policy-map interface de ver la aplicación de una directiva. El comando show policy-map interface visualiza el siguiente:

  • Configuré el ancho de banda y clases de prioridad y los criterios de coincidencia.

  • Cualquier perfiles WRED.

  • Parámetros de la dimensión de una variable y de la policía.

  • Estadísticas y tarifas del tráfico.

  • La cola interna de CoS a la cual se asocia una clase determinada. Estas colas de administración del tráfico son referidas por el mismo índice que se utiliza en la salida del comando show controller frfab queue.

Aquí está un ejemplo de una configuración completa y los comandos show de monitorear la directiva:

Configuración completada
class-map match-all class1
   match ip precedence 1
class-map match-all class2
   match ip precedence 2

!--- Step 1 - Configure traffic classes.

!
policy-map policy1e
  Class class1
    bandwidth percent 10
    random-detect
    random-detect precedence 1 375 packets 2423 packets 1
  Class class2
    bandwidth percent 20
    random-detect

!--- Step 2 - Configure a policy-map.

!
interface POS6/0
 ip address 12.1.1.1 255.255.255.0
 no ip directed-broadcast
 no keepalive
 service-policy output policy1e

!--- Step 3- Attach policy-map to the interface.

Utilice el comando show policy-map interface de ver la directiva configurada en la interfaz, junto con todas las clases configuradas. Aquí está la salida del comando:

Router#show policy-map int pos6/0
 POS6/0

  Service-policy output: policy1e (1071)

    Class-map: class1 (match-all) (1072/3)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 1  (1073)
      Class of service queue: 1
      Tx Queue (DRR configured)  
      bandwidth percent         Weight
        10                      1
      Tx Random-detect:
      Exp-weight-constant: 1 (1/2)
      Precedence        RED Label       Min             Max             Mark
      1                 1               375             2423            1

    Class-map: class2 (match-all) (1076/2)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 2  (1077)
      Class of service queue: 2
      Tx Queue (DRR configured)
      bandwidth percent         Weight
        20                      9
      Tx Random-detect:
      Exp-weight-constant: 1 (1/2)
      Precedence        RED Label       Min             Max             Mark

    Class-map: class-default (match-any) (1080/0)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any  (1081)
        0 packets, 0 bytes
        5 minute rate 0 bps

Comandos de monitorear la administración de la congestión y la evitación

Esta sección enumera los comandos que usted puede utilizar para monitorear su administración de la congestión y política de evasión.

El cuadro 8 enumera los comandos relevant para el linecards del ingreso y de la salida.

Cuadro 8 – Comandos para el linecards

Linecard del ingreso Tarjeta de línea de egreso
  • show interfaces
  • cola del tofab del sh controller del <x> del slot del ejecutivo
  • exec slot <x> show controller tofab queue <slot> <port>
  • exec slot <x> show controller tofab qm stat
  • show interfaces
  • muestre el <y> de las interfaces al azar
  • cola del controlador frfab de la demostración del <y> del slot del ejecutivo
  • exec slot <y> show controller frfab queue <port>
  • exec slot <y> show controller frfab QM stat

Estos comandos se explican en esta sección.

El comando show interfaces

Antes de que usted utilice este comando, confirme la “Estrategia de almacenamiento en cola correcta.” Si la salida visualiza primero adentro, primero hacia fuera ((Primero en Entrar, Primero en Salir FIFO)), asegúrese de que el comando service-policy aparezca en la configuración corriente (si el MQC se ha utilizado para configurar el MDRR).

Controle la cantidad de caídas de salida la cual representa la cantidad total de caídas WRED FrFab que han tenido lugar para el tráfico saliente en esta interfaz. El número de caídas de resultados en la salida del comando show interfaces debe ser igual a o más arriba que el número de caídas de resultados en la salida del comando show interfaces <number> random.

Nota: En los routers de la serie 12000 de Cisco, las caídas de la interfaz de salida se actualizan después de que se actualizan las caídas de WRED. Hay una pequeña ocasión que si usted utiliza una herramienta para preguntar a ambos contadores de caídas, los descensos de la interfaz no son todavía actualizados.

Router#show interfaces POS 4/0
POS4/0 is up, line protocol is up
  Hardware is Packet over SONET
  Description: link to c12f9-1
  Internet address is 10.10.105.53/30
  MTU 4470 bytes, BW 622000 Kbit, DLY 100 usec, rely 255/255, load 82/255
  Encapsulation PPP, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled
  LCP Open
  Open: IPCP, CDPCP, OSICP, TAGCP
  Last input 00:00:02, output 00:00:05, output hang never
  Last clearing of "show interface" counters 00:04:54
  Queueing strategy: random early detection (WRED)
  Output queue 0/40, 38753019 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 200656000 bits/sec, 16661 packets/sec
     135 packets input, 6136 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
              0 parity
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     7435402 packets output, 11182627523 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

La demostración interconecta el comando random del {number}

Cuando usted utiliza este comando, usted debe:

  • Verifique que la plantilla correcta de la cola de grupo cos esté aplicada a esta interfaz.

  • Marque las ponderaciones MDRR. Para cada cola MDRR, usted puede marcar el promedio ponderado para el largo de la cola y el valor más alto alcanzado (en los paquetes). Los valores se calculan como promedio ponderado, y no necesitan reflejar el Maximum Queue Depth real alcanzado nunca.

  • Verifique los umbrales WRED mínimos y máximos.

  • Verifique la cantidad de caídas aleatorias y de umbral para cada etiqueta RED (Las caídas "A hacia el entramado" indican la cantidad total de caídas para esta etiqueta en todas las tarjetas de línea).

  • El “TX-cola-límite cae” contrarios se utiliza solamente en el motor 1 LC, que no soportan el WRED. Los indicadores luminosos LED amarillo de la placa muestra gravedad menor del motor 1 le permiten para establecer el límite de las colas de administración del tráfico MDRR con el comando TX-queue-limit interface. En los casos en que se admite WRED, sus umbrales determinan la profundidad de las colas MDRR.

Router#show interfaces POS 4/0 random
POS4/0
cos-queue-group: oc12
RED Drop Counts
                
TX Link                    
To Fabric
RED Label          Random       Threshold          Random       Threshold
0                29065142           73492         9614385               0
1                       0               0               0               0
2                       0               0               0               0
3                       0               0               0               0
4                       0               0               0               0
5                       0               0               0               0
6                       0               0               0               0

TX-queue-limit drops: 0

Queue Lengths

TX Queue (DRR configured) oc12
Queue              Average              High Water Mark         Weight
0                    0.000                2278.843               1
1                    0.000                   0.000              73
2                    0.000                   0.000              10
3                    0.000                   0.000              10
4                    0.000                   0.000              10
5                    0.000                   0.000              10
6                    0.000                   0.000              10
Low latency          0.000                   0.000              10

TX RED config
  Precedence 0: 375 min threshold, 2423 max threshold, 1/1 mark weight
  Precedence 1: not configured for drop
  Precedence 2: not configured for drop
  Precedence 3: not configured for drop
  Precedence 4: 375 min threshold, 2423 max threshold, 1/1 mark weight
  Precedence 5: not configured for drop
  Precedence 6: 375 min threshold, 2423 max threshold, 1/1 mark weight
  Precedence 7: not configured for drop weight 1/2

El comando del {port} de la cola del controlador frfab de la demostración del slot del ejecutivo (y)

Este comando visualiza la profundidad de espera en cola instantánea para un puerto dado en un slot dado. La salida de muestra en esta sección visualiza la cola MDRR en la interfaz POS 4/1. Usted ve una profundidad de espera en cola para la cola 1 MDRR de 1964 paquetes. La ponderación es la cantidad de bytes que se puede servir en esta cola. Esta ponderación determina el porcentaje de ancho de banda que usted quiere dar a esta cola. El déficit es el valor que dice a algoritmo DDR cuántos paquetes todavía necesitan ser servidos. Usted puede ver que no hay paquetes hechos cola en el LLQ (cola DRR 7).

Router#execute-on slot 4 show controllers frfab queue 1
========= Line Card (Slot 4) =======
FrFab Queue
Interface 1
DRR#    Head    Tail    Length  Average         Weight  Deficit
0       95330   40924   0            0.000      4608    0
1       211447  233337  1964      1940.156     41472    35036 
2       0       0       0            0.000      9216    0
3       0       0       0            0.000      9216    0
4       0       0       0            0.000      9216    0
5       0       0       0            0.000      9216    0
6       0       0       0            0.000      9216    0
7       0       0       0            0.000      9216    0

Este comando se utiliza, en particular, para monitorear la profundidad de la cola de prioridad de la tarjeta de línea de salida. Cuando usted ve que los paquetes comienzan a esperar en este LLQ, es una buena indicación que usted debe desviar un cierto tráfico de la voz sobre IP (VOIP) al otro linecards de la salida. En un buen diseño, la longitud debe siempre ser 0 o 1. En una red en la vida real, usted experimentará el tráfico congestionado, incluso para los datos de voz. El retardo adicional se torna más grave cuando la carga de voz total excede el 100% del ancho de banda de egreso durante un breve lapso de tiempo. El router no puede colocar más tráfico en el cable que el permitido; por lo tanto, el tráfico de voz se coloca en cola en su propia cola prioritaria. Esto crea el tiempo de espera de la Voz y el jitter de la Voz introducidos por la explosión del tráfico de voz sí mismo.

Router#execute-on slot 4 show controllers frfab queue 0
========= Line Card (Slot 4) =======
FrFab Queue
Interface 0
DRR#    Head    Tail    Length  Average         Weight  Deficit
0       181008  53494   2487      2282.937      4608    249
1       16887   45447   7            0.000      41472   0
2       0       0       0            0.000      9216    0
3       0       0       0            0.000      9216    0
4       0       0       0            0.000      9216    0
5       0       0       0            0.000      9216    0
6       0       0       0            0.000      9216    0
7       107818  142207  93           0.000      9216    -183600

La cola 7 es el LLQ, y la longitud le dice cuántos paquetes están en este LLQ.

El comando qm stat del controlador frfab de la demostración del slot del ejecutivo (y)

Utilice este comando cuando usted sospecha que memoria del paquete de un LC comienza a acercarse a la capacidad plena. Un valor creciente para el “ningún descenso del mem” contrario sugiere que el WRED no esté configurado o que los umbrales WRED están fijados demasiado altos. Este contador no debe incrementar en condiciones normales. Vea los paquetes ignorados del troubleshooting y ningunos descensos de la memoria en el Cisco 12000 Series Internet Router para más información.

Router#execute-on slot 4 show controllers frfab QM stat
========= Line Card (Slot 4) =======
68142538 no mem drop, 0 soft drop, 0 bump count
0 rawq drops, 8314999254 global red drops, 515761905 global force drops
0 no memory (ns), 0 no memory hwm (Ns)
no free queue
0       0       1968    88
0       0       0       0
0       0       0       0
0       0       0       0
0 multicast drops
TX Counts
 Interface 0
859672328848 TX bytes, 3908130535 TX pkts, 75431 kbps, 6269 pps
 Interface 1
86967615809 TX bytes, 57881504 TX pkts, 104480 kbps, 8683 PPS
 Interface 2
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS
 Interface 3
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS

Monitoree la administración de la congestión entrante

Esta sección describe los comandos usados para monitorear la administración de la congestión entrante.

El comando show interfaces

Antes de que usted publique este comando, marque si el valor en el contador ignorado está en el aumento. Usted verá los paquetes ignorados si usted funcionado con de la memoria en el lado del tofab o si el linecard no valida los paquetes rápidamente bastante. Para obtener más información, consulte Resolución de problemas de caídas de entrada en el router de Internet de la serie 12000 de Cisco.

Router#show interfaces POS 14/0
POS14/0 is up, line protocol is up
  Hardware is Packet over SONET
  Description: agilent 3b for QOS tests
  Internet address is 10.10.105.138/30
  MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 234/255, load 1/255
  Encapsulation HDLC, crc 32, loopback not set
  Keepalive not set
  Scramble disabled
  Last input never, output 00:00:03, output hang never
  Last clearing of "show interface" counters 00:34:09
  Queueing strategy: random early detection (WRED)
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 2231000 bits/sec, 4149 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     563509152 packets input, 38318622336 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
              0 parity
     166568973 input errors, 0 CRC, 0 frame, 0 overrun, 166568973 ignored, 0 abort
     35 packets output, 12460 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

El comando show controller tofab queue del slot(x) del ejecutivo

Esta salida de muestra del comando exec slot <x> show controller tofab queue fue capturada cuando no había congestión en un linecard de la salida en el slot 3.

Router#execute-on slot 13 show controllers tofab queue
========= Line Card (Slot 13) =======
Carve information for ToFab buffers

!--- Output omitted.

   ToFab Queues:
        Dest
        Slot
        0       0       0               0       9690
        1       0       0               0       9690
        2       0       0               0       9690
        3   11419   16812               0       9690
        4       0       0               0       2423
        5       0       0               0       9690
        6       0       0               0       9690
        7       0       0               0       262143
        8       0       0               0       262143
        9       0       0               0       606
        10      0       0               0       262143
        11      0       0               0       262143
        12      0       0               0       262143
        13      0       0               0       262143
        14      0       0               0       262143
        15      0       0               0       9690
 Multicast      0       0               0       262143

El producto siguiente fue capturado cuando había congestión en el slot 3:

Router#execute-on slot 13 show controllers tofab queue
========= Line Card (Slot 13) =======
Carve information for ToFab buffers

!--- Output omitted.

   ToFab Queues:
        Dest
        Slot
        0       0       0               0       9690
        1       0       0               0       9690
        2       0       0               0       9690
        3  123689   14003            1842       9690
        4       0       0               0       2423
        5       0       0               0       9690
        6       0       0               0       9690
        7       0       0               0       262143
        8       0       0               0       262143
        9       0       0               0       606
        10      0       0               0       262143
        11      0       0               0       262143
        12      0       0               0       262143
        13      0       0               0       262143
        14      0       0               0       262143
        15      0       0               0       9690
 Multicast      0       0               0       262143

El comando de la cola del tofab del regulador de la demostración del slot(x) del ejecutivo (slot) (puerto)

Utilice este comando de determinar cuánta memoria se utiliza en el lado del tofab. Particularmente, observe el número en 'columna del #Qelem la”. Note eso:

  • Cuando no se utiliza ninguna memoria, los valores están en su más alto.

  • El valor de la columna del “#Qelem” disminuye mientras que los paquetes están mitigados.

  • Cuando la columna "#Qelem" llega a cero, todos los búfers divididos se encuentran en uso. En el motor 2 LC, los paquetes pequeños pueden obtener espacio de búfer prestado de paquetes más grandes.

Usted puede también utilizar este comando de determinar el número de paquetes en cola en una cola de salida virtual. El ejemplo aquí muestra cómo marcar el slot 14 para la cantidad instantánea de paquetes en estas colas de administración del tráfico para el slot 4, el puerto 1 (POS 4/1). Vemos 830 paquetes hechos cola en la cola 1. MDRR.

Router# execute-on slot 14 show controllers tofab queue 4 1
========= Line Card (Slot 14) =======
ToFab Queue
Slot 4 Int 1
DRR#    Head    Tail    Length  Average         Weight  Deficit
0       0       0       0            0.000      4608    0
1       203005  234676  830        781.093      41472   37248
2       0       0       0            0.000      9216    0
3       0       0       0            0.000      9216    0
4       0       0       0            0.000      9216    0
5       0       0       0            0.000      9216    0
6       0       0       0            0.000      9216    0
7       0       0       0            0.000      9216    0

El comando qm stat del tofab del regulador de la demostración del slot(x) del ejecutivo

Utilice este comando para ver la cantidad de caídas ToFab por tarjeta de línea. También marque para saber si hay un ese contrario de “ningún descenso de la memoria” los incrementos. Este contador aumenta cuando la clase de servicio (CoS) no está configurada en el lado ToFab.

Router#execute-on slot 13 show controllers tofab QM stat
========= Line Card (Slot 13) =======
0 no mem drop, 0 soft drop, 0 bump count
0 rawq drops, 1956216536 global red drops, 6804252 global force drops
0 no memory (Ns), 0 no memory hwm (Ns)
no free queue
0       0       0       0
0       0       0       0
0       0       0       0
0       0       0       0
Q status errors
0       0       0       0
0       0       0       0
0       0       0       0
0       0       0       0

Caso Práctico

Este caso práctico muestra cómo configurar una política típica para el núcleo de la red de un entorno del proveedor de servicios. Aplica los comandos queue y le permite para utilizar el MDRR/WRED para la Administración de cola activa. Las directivas de QoS en los routeres de borde utilizan normalmente la marca del tráfico, condicionando, y así sucesivamente, para permitir al Routers en la base para clasificar el tráfico en las clases basadas en los valores de la Prioridad IP o del DiffServ Code Point (DSCP). Este caso práctico utiliza las características de QoS del Cisco IOS Software para resolver el Service Level Agreements apretado (SLA) y diversos niveles de servicio para la Voz, el vídeo, y los servicios de datos en la misma estructura básica IP.

En el acercamiento, un proveedor de servicio ha implementado tres clases de tráfico. Lo más importante es el LLQ o la clase de c/.ola de tiempo de latencia bajo Ésta es la clase para Voz y Video. Esta clase debe experimentar un retraso mínimo y un jitter, y debe nunca experimentar la pérdida del paquete o los paquetes reordenados mientras el ancho de banda de esta clase no exceda el ancho de banda de link. Esta clase se conoce como tráfico de Comportamiento por salto de reenvío acelerado (EF PHB) en la arquitectura DiffServ. El Proveedor de servicios de Internet (ISP) diseñó la red de una manera que esta clase no excede la carga del 30% por término medio del ancho de banda de link. Las otras dos clases son las de negocios y de esfuerzo razonable.

En el diseño, hemos configurado al Routers de una manera tal que la clase comercial consiga siempre el 90% del ancho de banda restante y la clase Best-Effort consiga el 10%. Estas dos clases tienen menos tráfico sensible al tiempo y pueden experimentar la pérdida de tráfico, un retardo más alto, y el jitter. En el diseño, el foco está en el linecards del motor 2: 1xOC48 rev B, 4xOC12 rev el linecards B, y 8xOC3.

El linecards de Rev B best suited para llevar el tráfico de VoIP debido a ASIC y una arquitectura de hardware revisados, que introduce el tiempo de espera muy pequeño. Con ASIC revisado, la cola primero en entrar, primero en salir del transmitir es vuelta a clasificar según el tamaño por el driver del linecard a áspero dos veces el MTU más grande en el indicador luminoso LED amarillo de la placa muestra gravedad menor. Busque “- B” añadió al final del fichero al numero de parte, tal como OC48E/POS-SR-SC-B=.

Nota: No debe confundir la cola de transmisión FIFO con las colas FrFab que se pueden ajustar en las tarjetas de línea de Motor 0 con el comando tx-queue-limit.

El cuadro 9 enumera los criterios concordantes para cada clase.

Cuadro 9 – Criterios concordantes para cada clase

Nombre de la clase Criterios correspondientes
Cola prioritaria - Tráfico de Voz Precedencia 5
Cola comercial Precedencia 4
La mejor cola de esfuerzo Precedencia 0

Las tarjetas de línea OC48 pueden colocar en cola una gran cantidad de paquetes en las colas ToFab. Por lo tanto, es importante configurar el MDRR/WRED en las colas ToFab, especialmente cuando la interfaz de egreso es una interfaz de alta velocidad como OC48. La estructura sólo puede conmutar tráfico a la tarjeta de línea receptora a una velocidad máxima hipotética de 3Gbps (paquetes de 1500 bytes). Si la cantidad total de tráfico enviada es más grande que lo que el Switching Fabric puede llevar a su indicador luminoso LED amarillo de la placa muestra gravedad menor de recepción, muchos paquetes serán hechos cola en las colas de administración del tráfico del tofab.

Interface POS3/0 
  description OC48 egress interface 
 ip address 10.10.105.53 255.255.255.252 
 no ip directed-broadcast 
 ip router Isis encapsulation ppp 
 mpls traffic-eng tunnels 
 tag-switching ip 
 no peer neighbor-route 
 crc 32 
 clock source internal 
 POS framing sdh 
 POS scramble-atm 
 POS threshold sf-ber 4 
 POS flag s1s0 2 
 TX-cos oc48 
 Isis metric 2 level-1 
 Isis metric 2 level-2 
 ip rsvp bandwidth 2400000 2400000 
! 
interface POS4/1 
 description OC12 egress interface 
 ip address 10.10.105.121 255.255.255.252 
 no ip directed-broadcast 
 ip router Isis encapsulation ppp 
 mpls traffic-eng tunnels 
 no peer neighbor-route 
 crc 32 
 clock source internal 
 POS framing sdh 
 POS scramble-ATM POS threshold sf-ber 4 
 POS flag s1s0 2 
 TX-cos oc12 
 Isis metric 2 level-1 
 Isis metric 2 level-2 
 ip RSVP bandwidth 600000 60000 
! 
interface POS9/2 
 description OC3 egress interface 
 ip address 10.10.105.57 255.255.255.252 
 no ip directed-broadcast 
 ip router Isis crc 16 
 POS framing sdh 
 POS scramble-ATM POS flag s1s0 2 
 TX-cos oc3 
 Isis metric 200 level-1 
 Isis metric 2 level-2 
! 
interface POS13/0 
 description agilent 3a for QOS tests - ingress interface. 
 ip address 10.10.105.130 255.255.255.252 
 no ip directed-broadcast 
 no ip route-cache cef 
 no ip route-cache 
 no ip mroute-cache 
 no keepalive 
 crc 32 
 POS threshold sf-ber 4 
 TX-cos oc48 
! 
interface POS14/0 
 description agilent 3b for QOS tests - ingress interface. 
 ip address 10.10.105.138 255.255.255.252 
 no ip directed-broadcast 
 no keepalive 
 crc 32 
 POS threshold sf-ber 4 
 TX-cos oc48 
! 
interface POS15/0 
 description agilent 4A for QOS tests - ingress interface 
 ip address 10.10.105.134 255.255.255.252 
 no ip directed-broadcast 
 no ip mroute-cache 
 no keepalive 
 crc 32 
 POS threshold sf-ber 4 
 TX-CoS oc48 
! 
rx-cos-slot 3 StotTable 
rx-cos-slot 4 StotTable 
rx-cos-slot 9 StotTable 
rx-cos-slot 13 StotTable 
rx-cos-slot 14 StotTable 
rx-cos-slot 15 StotTable 
! 
slot-table-cos StotTable 
 destination-slot 0 oc48 
 destination-slot 1 oc48 
 destination-slot 2 oc48 
 destination-slot 3 oc48 
 destination-slot 4 oc12 
 destination-slot 5 oc48 
 destination-slot 6 oc48 
 destination-slot 9 oc3 
 destination-slot 15 oc48 
! 
cos-queue-groupoc3 
 precedence 0 random-detect-label 0 
 precedence 4 queue 1 
 precedence 4 random-detect-label 1 
 precedence 5 queue low-latency 
 precedence 6 queue 1 
 precedence 6 random-detect-label 1 
 random-detect-label 0 94 606 1 
 random-detect-label 1 94 606 1 
 queue 0 1 
 queue 1 73 
 queue low-latency strict-priority 

!--- Respect the tight SLA requirements. 
!--- No packets drop/low delay and jitter for the priority queue.
 
! 
CoS-queue-groupoc12 
 precedence 0 random-detect-label 0 
 precedence 4 queue 1 
 precedence 4 random-detect-label 1 
 precedence 5 queue low-latency 
 precedence 6 queue 1 
 precedence 6 random-detect-label 1 
 random-detect-label 0 375 2423 1 
 random-detect-label 1 375 2423 1 
 queue 0 1 
 queue 1 73 
 queue low-latency strict-priority 
! 
CoS-queue-groupoc48 
 precedence 0 random-detect-label 0 
 precedence 4 queue 1 
 precedence 4 random-detect-label 1 
 precedence 5 queue low-latency 
 precedence 6 queue 1 
 precedence 6 random-detect-label 1 
 random-detect-label 0 1498 9690 1 
 random-detect-label 1 1498 9690 1 
 queue 0 1 
 queue 1 73 
 queue low-latency strict-priority 

Se espera que cuanto más tráfico de VoIP que usted tiene, más el tráfico del negocio tiene que esperar antes de que consigue servido. Sin embargo, éste no es un problema porque SLA apretado no requiere ninguna caída de paquetes, y mismo latencia baja y jitter para el priority queue.


Información Relacionada


Document ID: 18841