Guía de Configuración de Soluciones de Calidad de Servicio de Cisco IOS, versión 12.2SR
Descripción general de Congestion Avoidance
21 Agosto 2013 - Traducción Automática | Otras Versiones: PDFpdf 219 KB | Inglés (17 Marzo 2008) | Comentarios

Contenidos

Descripción general de Congestion Avoidance

Eliminación de cola

Weighted Random Early Detection

Sobre la detección temprana aleatoria

Cómo funciona

Probabilidad de caída de paquetes

Cómo TCP maneja la pérdida de tráfico

Cómo interactúa el router con TCP

Sobre el WRED

¿Por qué utilice el WRED?

Cómo funciona

Tamaños promedios de la cola

Restricciones

Weighted Random Early Detection distribuido

Cómo funciona

Tamaños promedios de la cola

Probabilidad de caída de paquetes

¿Por qué utilice el DWRED?

Restricciones

Prerrequisitos

Flujo basado WRED

¿Por qué utilice el flujo basado WRED?

Cómo funciona

DiffServ Compliant WRED

Cómo funciona

Escenarios del uso

Puntas del uso a observar


Descripción general de Congestion Avoidance


Las técnicas para prevenir el congestionamiento monitorean las cargas de tráfico de la red en un esfuerzo para anticipar y para evitar la congestión en los embotellamientos de la red común. La prevención de congestionamiento se alcanza con la caída del paquete. Entre los mecanismos de prevención de congestionamiento generalmente usados es el Detección temprana aleatoria (RED), que es óptimo para de alta velocidad transita las redes. El Cisco IOS QoS incluye una implementación del ROJO que, cuando está configurado, controla cuando el router cae los paquetes. Si usted no configura el Weighted Random Early Detection (WRED), el router utiliza el mecanismo predeterminado más crudo de la caída de paquetes llamado eliminación de cola.

Este módulo da una Breve descripción de las clases de mecanismos de prevención de congestionamiento proporcionados por las características de QoS del Cisco IOS. Discute las características siguientes:

Eliminación de cola. Éste es el comportamiento predeterminado de la prevención de congestionamiento cuando el WRED no se configura.

WRED. El WRED y el WRED distribuido (DWRED) — que es las implementaciones de Cisco del ROJO — combinan las capacidades del algoritmo RED con la característica de la Prioridad IP. Dentro de la sección en el WRED, se discuten las características relacionadas siguientes:

– Flujo basado WRED. El flujo basado WRED amplía el WRED para proporcionar la mayor imparcialidad a todos los flujos en una interfaz con respecto a cómo se caen los paquetes.

– DiffServ Compliant WRED. El DiffServ Compliant WRED amplía el WRED para soportar los Servicios diferenciados (DiffServ) y el Per Hop Behavior del Assured Forwarding (AF) (PHB). Esta característica permite a los clientes para implementar AF PHB coloreando los paquetes según los valores del Differentiated Services Code Point (DSCP) y después asignando las probabilidades de caída preferenciales a esos paquetes.

Eliminación de cola

La eliminación de cola trata todo el tráfico igualmente y no lo distingue entre las clases del servicio. Las colas de administración del tráfico llenan durante los períodos de congestión. Cuando la cola de salida es llena y la eliminación de cola está en efecto, se caen los paquetes hasta que se elimine la congestión y la cola es no más llena.

Weighted Random Early Detection

Esta sección da una introducción abreviada a los conceptos ROJOS y dirige el WRED, la implementación de Cisco del ROJO para las plataformas de Cisco IOS estándar.

El WRED evita los problemas de la globalización que ocurren cuando la eliminación de cola se utiliza como el mecanismo de prevención de congestionamiento en el router. La sincronización global ocurre como ondas de la cresta de la congestión que se seguirá solamente por los canales durante los cuales el link de transmisión no se utiliza completamente. La sincronización global de los host TCP, por ejemplo, puede ocurrir porque los paquetes se caen de una vez. La sincronización global manifiesta cuando los host TCP múltiples reducen sus velocidades de transmisión en respuesta al paquete que cae, después aumenta sus velocidades de transmisión de nuevo cuando se reduce la congestión.

Sobre la detección temprana aleatoria

El mecanismo ROJO fue propuesto por Sally Floyd y Van Jacobson en el principio de la década del 90 para dirigir la congestión de red en un responsivo bastante que la manera reactiva. Ser la base del mecanismo ROJO es la premisa que la mayoría del tráfico funciona con en las implementaciones del transporte de datos que son sensibles a la pérdida y retrasarán temporalmente cuando algo de su tráfico se cae. El TCP, que responde apropiadamente — incluso robusto — para traficar el descenso retrasando su transmisión de tráfico, permite con eficacia que el comportamiento del tráfico-descenso del ROJO trabaje como prevención de congestionamiento que señala el mecanismo.

El TCP constituye el transporte más muy usado de la red. Dado la presencia ubicua de TCP, el ROJO ofrece un mecanismo para prevenir la congestión extenso, eficaz.

En la consideración de la utilidad del ROJO cuando los transportes robustos tales como TCP son penetrantes, es importante considerar también seriamente los efectos negativos de emplear el ROJO cuando un porcentaje significativo del tráfico no es robusto en respuesta a la pérdida del paquete. Ni el Novell Netware ni el APPLETALK es apropiadamente robusto en respuesta a la pérdida del paquete, por lo tanto usted no debe utilizar el ROJO para ellos.

Cómo funciona

El ROJO apunta controlar los tamaños promedios de la cola indicando al final los hosts cuando deben retrasar temporalmente la transmisión de paquetes.

El ROJO se aprovecha del mecanismo de control de la congestión del TCP. Aleatoriamente cayendo los paquetes antes de la congestión de los periodos de alto, el ROJO dice la fuente del paquete disminuir su velocidad de transmisión. Si se asume que la fuente del paquete está utilizando el TCP, él disminuirá su velocidad de transmisión hasta que todos los paquetes alcancen su destino, indicando que la congestión está borrada. Usted puede utilizar el ROJO como manera de hacer el TCP retrasar la transmisión de paquetes. El TCP no sólo se detiene brevemente, pero también recomienza rápidamente y adapta su velocidad de transmisión a la tarifa que la red puede soportar.

El ROJO distribuye las pérdidas a tiempo y mantiene la profundidad de espera en cola normalmente baja mientras que absorbe los puntos. Cuando está habilitado en una interfaz, el ROJO comienza a caer los paquetes cuando la congestión ocurre a una tarifa que usted selecciona durante la configuración.

Probabilidad de caída de paquetes

La probabilidad de caída de paquetes se basa en el umbral mínimo, el umbral máximo, y el denominador de probabilidad de la marca.

Cuando la profundidad de cola promedio está sobre el umbral mínimo, el ROJO comienza a caer los paquetes. El índice de caída de paquetes aumenta linear mientras que los tamaños promedios de la cola aumentan hasta que los tamaños promedios de la cola alcancen el umbral máximo.

El denominador de probabilidad de la marca es la fracción de los paquetes caídos cuando la profundidad de cola promedio está en el umbral máximo. Por ejemplo, si el denominador es 512, uno fuera de cada 512 paquetes se cae cuando la cola promedio está en el umbral máximo.

Cuando los tamaños promedios de la cola están sobre el umbral máximo, se caen todos los paquetes. El cuadro 1 resume la probabilidad de caída de paquetes.

Cuadro 1 probabilidad de caída del paquete rojo

El valor de umbral mínimo se debe fijar arriba bastante para maximizar la utilización del vínculo. Si el umbral mínimo es demasiado bajo, los paquetes se pueden caer innecesariamente, y el link de transmisión no será utilizado completamente.

La diferencia entre el umbral máximo y el umbral mínimo debe ser bastante grande evitar la sincronización global de los host TCP (la sincronización global de los host TCP puede ocurrir mientras que los host TCP múltiples reducen sus velocidades de transmisión). Si la diferencia entre el máximo y los umbrales mínimos es demasiado pequeña, muchos paquetes se pueden caer inmediatamente, dando por resultado la sincronización global.

Cómo TCP maneja la pérdida de tráfico

Cuando el beneficiario de tráfico TCP — llamó el receptor — recibe un segmento de datos, marca el número de secuencia (de 32 bits) de cuatro octetos de ese segmento contra el número que el receptor esperó, que indicaría que el segmento de datos fue recibido en la orden. Si los números hacen juego, el receptor entrega todos los datos que sostenga a la aplicación de la blanco, después pone al día el número de secuencia para reflejar el número siguiente en la orden, y finalmente cualquiera envía inmediatamente un paquete del acuse de recibo (ACK) al remitente o programa un ACK para ser enviado al remitente después de una demora breve. El ACK notifica el remitente que el receptor recibió todos los segmentos de datos hasta pero no incluyendo el que está marcado con el nuevo número de secuencia.

Los receptores intentan generalmente enviar un ACK en respuesta a los segmentos de datos de alternancia que reciben; envían el ACK porque para muchas aplicaciones, si el receptor espera hacia fuera un pequeño retardo, puede incluir eficientemente su acuse de recibo de la contestación en una respuesta normal al remitente. Sin embargo, cuando el receptor recibe un segmento de datos fuera de servicio, responde inmediatamente con un ACK para ordenar al remitente volver a enviar el segmento de datos perdido.

Cuando el remitente recibe un ACK, hace esta determinación: Determina si algunos datos son excepcionales. Si no hay datos excepcionales, el remitente determina que el ACK es un keepalive, significado para guardar la línea active, y no hace nada. Si los datos son excepcionales, el remitente determina si el ACK indica que el receptor no ha recibido algún o ninguno de los datos. Si el ACK indica el recibo de un ciertos datos enviados, el remitente determina si el nuevo crédito se ha concedido para permitir que envíe más datos. Cuando el ACK indica que el recibo de ningunos de los datos enviados y allí es datos excepcionales, el remitente interpreta el ACK para ser un ACK en varias ocasiones enviado. Esta condición indica que un ciertos datos estaban fuera de servicio recibido, forzando al receptor a remitir el primer ACK, y que un segundo segmento de datos estaba fuera de servicio recibido, forzando al receptor a remitir el segundo ACK. En la mayoría de los casos, el receptor recibiría dos segmentos fuera de servicio porque uno de los segmentos de datos había sido caído.

Cuando un emisor TCP detecta un segmento de datos caído, vuelve a enviar el segmento. Entonces ajusta su velocidad de transmisión a la mitad de cuál es era antes de que el descenso fuera detectado. Éste es el TCP retrocede o retrasa el comportamiento. Aunque este comportamiento sea apropiadamente responsivo a la congestión, los problemas pueden presentarse cuando llevan a las sesiones TCP múltiples encendido simultáneamente al mismo router y todos los emisores TCP retrasan la transmisión de paquetes al mismo tiempo.

Cómo interactúa el router con TCP

Para ver cómo el router obra recíprocamente con el TCP, miraremos un ejemplo. En este ejemplo, por término medio, el router recibe el tráfico a partir de una secuencia determinada TCP cada otra, cada 10mo, y cada 100o o 200o mensaje en la interfaz en MAE-EAST o FIX-WEST. Un router puede manejar las sesiones TCP simultáneas múltiples. Porque los flujos de red son aditivos, hay una alta probabilidad que cuando el tráfico excede el límite de la cola de transmisión (TQL) en absoluto, él excederá sumamente el límite. Sin embargo, hay también una alta probabilidad que la profundidad del tráfico excesivo es temporal y que el tráfico no permanecerá excesivamente profundo excepto en las puntas donde los flujos de tráfico se combinan o en los routeres de borde.

Si el router cae todo el tráfico que exceda el TQL, al igual que cuando se hace la eliminación de cola se utiliza por abandono, muchas sesiones TCP entrarán simultáneamente el comienzo lento. Por lo tanto, trafique retrasa temporalmente al extremo y entonces todo fluye lento-principio otra vez; esta actividad crea una condición de la sincronización global.

Sin embargo, si el router no cae ningún tráfico, al igual que el caso cuando las características de espera tales como espera justa o la Asignación personalizada de colas se utilizan, después los datos es probable ser salvado en el rendimiento del router de memoria principal, drástico de degradación.

Ordenando un en un momento de la sesión TCP para retrasar, el ROJO soluciona los problemas descritos, teniendo en cuenta la total utilización del ancho de banda bastante que la utilización que manifiesta como las crestas y canales del tráfico.

Sobre el WRED

El WRED combina las capacidades del algoritmo RED con la característica de la Prioridad IP para prever el tratamiento de tráfico preferencial de paquetes más prioritarios. El WRED puede desechar selectivamente el tráfico de prioridad más baja cuando la interfaz comienza a conseguir congestionada y a proporcionar las características del rendimiento distinguidas para diversas clases del servicio.

Usted puede configurar el WRED para ignorar la Prioridad IP al tomar las decisiones del descenso para alcanzar el comportamiento ROJO nonweighted.

Para las interfaces configuradas para utilizar la característica del Resource Reservation Protocol (RSVP), el WRED elige los paquetes de otros flujos para caer bastante que los flujos de RSVP. También, la Prioridad IP gobierna qué paquetes son el tráfico interrumpido que está en una precedencia inferior tiene una tarifa más alta del descenso y por lo tanto es más probable ser estrangulado detrás.

El WRED diferencia de otras técnicas para prevenir el congestionamiento tales como Estrategias de almacenamiento en cola porque intenta anticipar y evitar la congestión bastante que la congestión que ocurre una vez.

¿Por qué utilice el WRED?

El WRED hace la detección inicial de la congestión posible y preve las clases múltiples de tráfico. También protege contra la sincronización global. Por estas razones, el WRED es útil en cualquier interfaz de salida donde usted espera que ocurra la congestión.

Sin embargo, el WRED se utiliza generalmente en los routeres del núcleo de una red, bastante que en el borde de la red. Los routeres de borde asignan el precedences IP a los paquetes mientras que ingresan la red. El WRED utiliza este precedences para determinar cómo tratar diversos tipos de tráfico.

El WRED proporciona los umbrales y las ponderaciones separados para diverso precedences IP, permitiendo que usted proporcione diversas calidades de servicio con respecto al paquete que cae para diversos tipos de tráfico. El tráfico estándar se puede caer más con frecuencia que el tráfico de primera clase durante los períodos de congestión.

El WRED es también consciente, y puede proporcionar el servicio de QoS de la controlado-carga del servicio integrado.

Cómo funciona

Aleatoriamente cayendo los paquetes antes de la congestión de los periodos de alto, el WRED dice la fuente del paquete disminuir su velocidad de transmisión. Si la fuente del paquete está utilizando el TCP, disminuirá su velocidad de transmisión hasta que todos los paquetes alcancen su destino, que indica que la congestión está borrada.

El WRED cae generalmente los paquetes basados selectivamente en la Prioridad IP. Los paquetes con una Prioridad IP más alta son menos probables ser caídos que los paquetes con una precedencia inferior. Así, cuanto más alta es la prioridad de un paquete, más alta es la probabilidad que el paquete será entregado.

El WRED reduce las ocasiones de la eliminación de cola selectivamente cayendo los paquetes cuando la interfaz de salida comienza a mostrar las muestras de la congestión. Cayendo algunos paquetes temprano bastante que esperando hasta que la cola sea llena, el WRED evita caer un gran número de paquetes inmediatamente y minimiza las ocasiones de la sincronización global. Así, el WRED permite que la Línea de transmisión sea utilizada completamente siempre.

Además, el WRED cae estadístico más paquetes de los usuarios grandes que pequeños. Por lo tanto, las fuentes del tráfico que generan la mayoría del tráfico son más probables ser retrasadas que las fuentes del tráfico que generan el poco tráfico.

El WRED evita los problemas de la globalización que ocurren cuando la eliminación de cola se utiliza como el mecanismo de prevención de congestionamiento. La sincronización global manifiesta cuando los host TCP múltiples reducen sus velocidades de transmisión en respuesta al paquete que cae, después aumenta sus velocidades de transmisión de nuevo cuando se reduce la congestión.

El WRED es solamente útil cuando el bulto del tráfico es tráfico TCP/IP. Con el TCP, los paquetes perdidos indican la congestión, así que la fuente del paquete reducirá su velocidad de transmisión. Con otros protocolos, las fuentes del paquete pueden no responder o pueden volver a enviar los paquetes perdidos a la misma tarifa. Así, la caída de los paquetes no disminuye la congestión.

El WRED trata el tráfico no IP como precedencia 0, la precedencia más baja. Por lo tanto, el tráfico no IP, es generalmente más probable ser caído que el tráfico IP.

El cuadro 2 ilustra cómo el WRED trabaja.

Cuadro 2 Weighted Random Early Detection

Tamaños promedios de la cola

El router determina automáticamente los parámetros para utilizar en los cálculos WRED. Los tamaños promedios de la cola se basan en los tamaños medios y actuales anteriores de la cola. La fórmula es:

average = (old_average * (1-2 -n)) + (current_queue_size * 2 -n)

donde n está el factor de ponderación exponencial, un valor del utilizador configurable. El valor predeterminado del factor de ponderación exponencial es 9. Se recomienda para utilizar solamente el valor predeterminado para el factor de ponderación exponencial. Cambie este valor del valor predeterminado solamente si usted ha determinado que su escenario se beneficiaría de usar un diverso valor.

Para los valores altos de n, la media anterior llega a ser más importante. Un factor grande allana los picos y los puntos bajos en el largo de la cola. Los tamaños promedios de la cola son poco probables de cambiar muy rápidamente, evitando los oscilaciones drásticos de tamaño. El proceso WRED será lento comenzar a caer los paquetes, pero puede continuar cayendo los paquetes por una época después de que los tamaños de la cola reales hayan caído debajo del umbral mínimo. La media de movimiento lento acomodará las ráfagas temporarias en el tráfico.


Observesi el valor de n consigue demasiado alto, el WRED no reacciona a la congestión. Los paquetes serán enviados o caídos como si el WRED no estuviera en efecto.


Para los valores bajos de n, los tamaños promedios de la cola siguen de cerca los tamaños de la cola actuales. La media resultante puede fluctuar con los cambios en los niveles de tráficog. En este caso, el proceso WRED responde rápidamente a las colas de administración del tráfico largas. Una vez que la cola cae debajo del umbral mínimo, el proceso parará el caer de los paquetes.

Si el valor de n consigue demasiado bajo, el WRED reaccionará exageradamente a las ráfagas de tráfico y al tráfico temporales del descenso innecesariamente.

Restricciones

Usted no puede configurar el WRED en la misma interfaz que el Route Switch Processor (RSP) - CQ basado, Asignación de colas de prioridad (PQ), o espera cargada de la feria (WFQ).

Weighted Random Early Detection distribuido

El WRED distribuido (DWRED) es una implementación del WRED para el Versatile Interface Processor (VIP). El DWRED proporciona el conjunto completo de las funciones para el VIP que el WRED proporciona en las plataformas de Cisco IOS estándar.

La característica DWRED se soporta solamente en los Cisco 7000 Series Router con un procesador de interfaz RSP basado RSP7000 y los Cisco 7500 Series Router con un VIP2-40 VIP basado o un mayor procesador de interfaz. Un procesador de interfaz VIP2-50 se recomienda fuertemente cuando la línea global tarifa de los adaptadores de puerto en el VIP es mayor que el DS3. Un procesador de interfaz VIP2-50 se requiere para las tarifas OC-3.

El DWRED se configura la misma manera que el WRED. Si usted habilita el WRED en una interfaz VIP conveniente, tal como un VIP2-40 o mayor con por lo menos el 2 MB de SRAM, el DWRED será habilitado en lugar de otro.

Para utilizar el DWRED, el Distributed Cisco Express Forwarding (dCEF) que conmuta se debe habilitar en la interfaz.

Usted puede configurar el DWRED y la feria cargada distribuida que hace cola (DWFQ) en lo mismo interconecta, pero usted no puede configurar el WRED distribuido en una interfaz para la cual se configure el CQ RSP basado, el PQ, o el WFQ.

Cómo funciona

Cuando llega un paquete y se habilita el DWRED, los eventos siguientes ocurren:

Se calculan los tamaños promedios de la cola. Vea la sección de los “tamaños promedios de la cola” para los detalles.

Si la media es menos que el umbral mínimo de la cola, se hace cola el paquete de llegada.

Si la media está entre el umbral mínimo de la cola y el umbral del almacenamiento en cola máximo, el paquete se cae o se hace cola, dependiendo de la probabilidad de caída de paquetes. Vea la sección de la “probabilidad de caída de paquetes” para los detalles.

Si los tamaños promedios de la cola son mayores que el umbral del almacenamiento en cola máximo, el paquete se cae automáticamente.

Tamaños promedios de la cola

Los tamaños promedios de la cola se basan en los tamaños medios y actuales anteriores de la cola. La fórmula es:

average = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

donde n está el factor de ponderación exponencial, un valor del utilizador configurable.

Para los valores altos de n, los tamaños promedios de la cola anteriores llegan a ser más importantes. Un factor grande allana los picos y los puntos bajos en el largo de la cola. Los tamaños promedios de la cola son poco probables de cambiar muy rápidamente, evitando los oscilaciones drásticos de tamaño. El proceso WRED será lento comenzar a caer los paquetes, pero puede continuar cayendo los paquetes por una época después de que los tamaños de la cola reales hayan caído debajo del umbral mínimo. La media de movimiento lento acomodará las ráfagas temporarias en el tráfico.


Observesi el valor de n consigue demasiado alto, el WRED no reacciona a la congestión. Los paquetes serán enviados o caídos como si el WRED no estuviera en efecto.


Para los valores bajos de n, los tamaños promedios de la cola siguen de cerca los tamaños de la cola actuales. La media resultante puede fluctuar con los cambios en los niveles de tráficog. En este caso, el proceso WRED responde rápidamente a las colas de administración del tráfico largas. Una vez que la cola cae debajo del umbral mínimo, el proceso para el caer de los paquetes.

Si el valor de n consigue demasiado bajo, el WRED reaccionará exageradamente a las ráfagas de tráfico y al tráfico temporales del descenso innecesariamente.

Probabilidad de caída de paquetes

La probabilidad que un paquete será caído se basa en el umbral mínimo, el umbral máximo, y el denominador de probabilidad de la marca.

Cuando los tamaños promedios de la cola están sobre el umbral mínimo, el ROJO comienza a caer los paquetes. El índice de caída de paquetes aumenta linear mientras que los tamaños promedios de la cola aumentan, hasta que los tamaños promedios de la cola alcancen el umbral máximo.

El denominador de probabilidad de la marca es la fracción de los paquetes caídos cuando los tamaños promedios de la cola están en el umbral máximo. Por ejemplo, si el denominador es 512, uno fuera de cada 512 paquetes se cae cuando la cola promedio está en el umbral máximo.

Cuando los tamaños promedios de la cola están sobre el umbral máximo, se caen todos los paquetes. El cuadro 3 resume la probabilidad de caída de paquetes.

Cuadro 3 probabilidad de caída de paquetes

El valor de umbral mínimo se debe fijar arriba bastante para maximizar la utilización del vínculo. Si el umbral mínimo es demasiado bajo, los paquetes se pueden caer innecesariamente, y el link de transmisión no será utilizado completamente.

La diferencia entre el umbral máximo y el umbral mínimo debe ser bastante grande evitar la sincronización global de los host TCP (la sincronización global de los host TCP puede ocurrir mientras que los host TCP múltiples reducen sus velocidades de transmisión). Si la diferencia entre el máximo y los umbrales mínimos es demasiado pequeña, muchos paquetes se pueden caer inmediatamente, dando por resultado la sincronización global.

¿Por qué utilice el DWRED?

El DWRED proporciona un funcionamiento más rápido que el WRED RSP basado. Usted debe ejecutar el DWRED en el VIP si usted quiere alcanzar muy de alta velocidad en la plataforma de las Cisco 7500 Series — por ejemplo, usted puede alcanzar la velocidad a las tarifas OC-3 ejecutando el WRED en un procesador de interfaz VIP2-50.

Además, las mismas razones que usted utilizaría el WRED en las plataformas de Cisco IOS estándar se aplican a usar el DWRED. Por ejemplo, cuando el WRED o el DWRED no se configura, la eliminación de cola se decreta durante los períodos de congestión. Habilitando el DWRED evita los problemas de sincronización globales que resultan cuando la eliminación de cola se utiliza para evitar la congestión.

La característica DWRED proporciona la ventaja de los flujos de tráfico constantes. Cuando el ROJO no se configura, los búferes de salida llenan durante los períodos de congestión. Cuando los buffers son llenos, la eliminación de cola ocurre; se caen todos los paquetes adicionales. Porque los paquetes se caen de una vez, la sincronización global de los host TCP puede ocurrir mientras que los host TCP múltiples reducen sus velocidades de transmisión. Los claros de la congestión, y los host TCP aumentan sus velocidades de transmisión, dando por resultado las ondas de la congestión seguidas en los períodos en que el link de transmisión no se utiliza completamente.

El ROJO reduce las ocasiones de la eliminación de cola selectivamente cayendo los paquetes cuando la interfaz de salida comienza a mostrar las muestras de la congestión. Cayendo algunos paquetes bastante que esperando hasta el buffer es temprano lleno, el ROJO evita caer un gran número de paquetes inmediatamente y minimiza las ocasiones de la sincronización global. Así, el ROJO permite que la Línea de transmisión sea utilizada completamente siempre.

Además, el ROJO cae estadístico más paquetes de los usuarios grandes que pequeños. Por lo tanto, las fuentes del tráfico que generan la mayoría del tráfico son más probables ser retrasadas que las fuentes del tráfico que generan el poco tráfico.

El DWRED proporciona los umbrales y las ponderaciones separados para diverso precedences IP, permitiendo que usted proporcione diversas calidades de servicio para diverso tráfico. El tráfico estándar se puede caer más con frecuencia que el tráfico de primera clase durante los períodos de congestión.

Restricciones

Las restricciones siguientes se aplican a la característica DWRED:

El DWRED basado en la interfaz no se puede configurar en una subinterfaz. (La subinterfaz A es una de varias interfaces virtuales en una sola interfaz física.)

El DWRED no se soporta en el Fast EtherChannel y las interfaces del túnel.

RSVP no se soporta en el DWRED.

El DWRED es útil solamente cuando el bulto del tráfico es tráfico TCP/IP. Con el TCP, los paquetes perdidos indican la congestión, así que la fuente del paquete reduce su velocidad de transmisión. Con otros protocolos, las fuentes del paquete pueden no responder o pueden volver a enviar los paquetes perdidos a la misma tarifa. Así, la caída de los paquetes no disminuye necesariamente la congestión.

El DWRED trata el tráfico no IP como precedencia 0, la precedencia más baja. Por lo tanto, el tráfico no IP es generalmente más probable ser caído que el tráfico IP.

El DWRED no se puede configurar en la misma interfaz que el CQ RSP basado, el PQ, o el WFQ. Sin embargo, el DWRED y el DWFQ se pueden configurar en la misma interfaz.


La notano utiliza match protocol el comando de crear una clase de tráfico con un protocolo del no IP como criterio de la coincidencia. El VIP no soporta corresponder con de los protocolos del no IP.


Prerrequisitos

Esta sección proporciona los requisitos previos que deben ser resueltos antes de que usted configure la característica DWRED.

Espera cargada de la feria

Asociando una política de servicio a una interfaz inhabilita el WFQ en esa interfaz si el WFQ se configura para la interfaz. Por este motivo, usted debe asegurarse de que el WFQ no esté habilitado en tal interfaz antes de configurar el DWRED.

WRED

Asociando una política de servicio configurada para utilizar el WRED a una interfaz inhabilita el WRED en esa interfaz. Si es un de los las clases de tráfico que usted configura en un uso WRED de la correspondencia de políticas para la caída de paquetes en vez de la eliminación de cola, usted debe asegurarse de que el WRED no esté configurado en la interfaz a la cual usted se prepone asociar esa política de servicio.

Listas de control de acceso

Usted puede especificar una lista de acceso numerada como el criterio de la coincidencia para cualquier clase de tráfico que usted cree. Por este motivo, antes de configurar el DWRED usted debe saber configurar las Listas de acceso.

Cisco Express Forwarding

Para utilizar el DWRED, el DCEF Switching se debe habilitar en la interfaz.

Flujo basado WRED

El flujo basado WRED es una característica esa las fuerzas WRED para permitir la mayor imparcialidad a todos los flujos en una interfaz con respecto a cómo se caen los paquetes.

¿Por qué utilice el flujo basado WRED?

Antes de que usted considere las ventajas que el uso del flujo basado WRED ofrece, ayuda a pensar en cómo el WRED (sin el flujo basado WRED configurado) afecta a los diferentes tipos de flujos de paquetes. Incluso antes de que el flujo basado WRED clasifica los flujos de paquetes, los flujos se pueden pensar en como perteneciendo a una de las categorías siguientes:

Flujos Nonadaptive, que son los flujos que no responden a la congestión.

Flujos robustos, que por término medio tienen una velocidad de datos uniforme y retrasan en respuesta a la congestión.

Los flujos frágiles, que, aunque que reconoce la congestión, tienen menos paquetes mitigados en un gateway que hacen los flujos robustos.

El WRED tiende hacia el prejuicio contra los flujos frágiles porque todo fluye, incluso ésos con relativamente menos paquetes en la cola de salida, es susceptible a la caída de paquetes durante los períodos de congestión. Los flujos frágiles tienen sin embargo menos paquetes mitigados, ellos se caen a la misma tarifa que los paquetes de otros flujos.

Para proporcionar la imparcialidad a todo fluye, el flujo basado WRED tiene las características siguientes:

Se asegura de que los flujos que responden a las caídas de paquetes WRED (retrocediendo la transmisión de paquetes) estén protegidos contra los flujos que no responden a las caídas de paquetes WRED.

Prohíbe un flujo único de monopolizar a los recursos del búfer en una interfaz.

Cómo funciona

El flujo basado WRED confía en los dos acercamientos principales siguientes para remediar el problema de la caída de paquetes injusta:

Clasifica el tráfico entrante en los flujos basados en los parámetros tales como direcciones de origen y destino y puertos.

Mantiene el estado sobre los flujos activos, que son los flujos que tienen paquetes en las colas de salida.

El flujo basado WRED utiliza esta clasificación y información del estado para asegurarse de que cada flujo no consume más que su parte permitida de los recursos del búfer de salida. El flujo basado WRED determina que los flujos monopolizan los recursos y penaliza más pesadamente estos flujos.

Para asegurar la imparcialidad entre los flujos, el flujo basado WRED mantiene una cuenta del número de flujos activos que existan a través de una interfaz de salida. Dado el número de flujos activos y de los tamaños de la cola de resultado, el flujo basado WRED determina la cantidad de búfers disponible por el flujo.

Para tener en cuenta algún burstiness, el flujo basado WRED escala la cantidad de búfers disponible por el flujo por un factor configurado y permite que a cada uno el flujo activo tenga algunos paquetes en la cola de salida. Este factor de escala es común a todos los flujos. El resultado de la cantidad de búfers escalada se convierte en el límite del por-flujo. Cuando un flujo excede el límite del por-flujo, la probabilidad que un paquete de ese flujo será aumentos caídos.

DiffServ Compliant WRED

El DiffServ Compliant WRED amplía las funciones del WRED para habilitar el soporte para el DiffServ y el Per Hop Behavior PHB AF. Esta característica permite a los clientes para implementar AF PHB coloreando los paquetes según los valores DSCP y después asignando las probabilidades de caída preferenciales a esos paquetes.


Observeesta característica puede ser utilizado con los paquetes IP solamente. No se piensa para el uso con el Multiprotocol Label Switching (MPLS) - los paquetes encapsulados.


Los soportes de MIB basados en la clase de la calidad de servicio esta característica. Este MIB es realmente el dos MIB siguiente:

CISCO-CLASS-BASED-QOS-MIB

CISCO-CLASS-BASED-QOS-CAPABILITY-MIB

Los soportes de característica del DiffServ Compliant WRED los RFC siguientes:

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

RFC 2475, An Architecture for Differentiated Services Framework

RFC 2597, Assured Forwarding PHB

RFC 2598, An Expedited Forwarding PHB

Cómo funciona

La característica del DiffServ Compliant WRED permite al WRED para utilizar el valor DSCP cuando calcula la probabilidad de caída para un paquete. El valor DSCP es los primeros seis bits del byte del tipo de servicio IP (TOS).

Esta característica agrega dos comandos new, random-detect dscp y dscp. También agrega dos nuevos argumentos, dscp-based y prec-based, a dos comandos WRED-relacionados existentes — random-detect el comando (de la interfaz) y random-detect-group el comando.

dscp-based El argumento permite al WRED para utilizar el valor DSCP de un paquete cuando calcula la probabilidad de caída para el paquete. prec-based El argumento permite al WRED para utilizar el valor de precedencia IP de un paquete cuando calcula la probabilidad de caída para el paquete.

Estos argumentos son opcionales (usted no necesitan utilizar ningunos de ellos para utilizar los comandos) pero son también mutuamente - exclusiva. Es decir, si usted utiliza dscp-based el argumento, usted no puede utilizar prec-based el argumento con el mismo comando.

Después de habilitar el WRED para utilizar el valor DSCP, usted puede entonces utilizar el comando new random-detect dscp de cambiar el mínimo y los umbrales del PAQUETE MÁXIMO para ese valor DSCP.

Tres escenarios para usar estos argumentos se proporcionan.

Escenarios del uso

El nuevo dscp-based y prec-based los argumentos pueden ser utilizados si usted está utilizando el WRED en el nivel de la interfaz, en el nivel del Per-Virtual Circuit (VC), o en el nivel de clase (como parte del Class-Based WFQ (CBWFQ) con las correspondencias de políticas).

WRED en el nivel de la interfaz

En el nivel de la interfaz, si usted quiere tener uso WRED el valor DSCP cuando calcula la probabilidad de caída, usted puede utilizar dscp-based el argumento con random-detect el comando (de la interfaz ) de especificar el valor DSCP. Entonces utilice random-detect dscp el comando de especificar el mínimo y los umbrales máximos para el valor DSCP.

WRED en el nivel por VC

En el nivel por VC, si usted quiere tener uso WRED el valor DSCP cuando calcula la probabilidad de caída, usted puede utilizar dscp-based el argumento con random-detect-group el comando. Entonces utilice dscp el comando de especificar el mínimo y los umbrales máximos para el valor DSCP o el denominador de la marca-probabilidad.

Esta configuración se puede entonces aplicar a cada VC en la red.

WRED en el nivel de clase

Si usted está utilizando el WRED en el nivel de clase (con el CBWFQ), dscp-based y prec-based los argumentos se pueden utilizar dentro de la correspondencia de políticas.

Primero, especifique la correspondencia de políticas, la clase, y el ancho de banda. Entonces, si usted quisiera que el WRED utilizara el valor DSCP cuando calcula la probabilidad de caída, utilice dscp-based el argumento con random-detect el comando (de la interfaz ) de especificar el valor DSCP. Entonces utilice random-detect dscp el comando de modificar el mínimo y los umbrales máximos predeterminados para el valor DSCP.

Esta configuración puede entonces ser aplicada dondequiera que se asocien las correspondencias de políticas (por ejemplo, en el nivel de la interfaz, el nivel por VC, o el shaper llano).

Puntas del uso a observar

Recuerde las puntas siguientes al usar los comandos new y los nuevos argumentos incluidos con esta característica:

Si usted utiliza dscp-based el argumento, el WRED utilizará el valor DSCP para calcular la probabilidad de caída.

Si usted utiliza prec-based el argumento, el WRED utilizará el valor de precedencia IP para calcular la probabilidad de caída.

dscp-based Y prec-based los argumentos es mutuamente - la exclusiva.

Si usted no especifica cualquier argumento, el WRED utilizará el valor de precedencia IP para calcular la probabilidad de caída (el método predeterminado).

random-detect dscp El comando se debe utilizar conjuntamente con random-detect el comando (de la interfaz ).

random-detect dscp El comando puede ser utilizado solamente si usted utiliza dscp-based el argumento con random-detect el comando (de la interfaz ).

dscp El comando se debe utilizar conjuntamente con random-detect-group el comando.

dscp El comando puede ser utilizado solamente si usted utiliza dscp-based el argumento con random-detect-group el comando.