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

Contenidos

Descripción general de la administración de congestión

¿Por qué utilice la administración de la congestión?

Decisión de qué política de colocación encola para utilizar

Colas primero en entrar, primero en salir

Espera cargada de la feria

Espera cargada flujo basado de la feria

Restricciones

WFQ y Prioridad IP

WFQ y RSVP

Espera cargada distribuida de la feria

Política para tirar paquetes

Restricciones

Colocación en cola equilibrada ponderada calculada en función de la clase

Asignación de ancho de banda CBWFQ

¿Por qué utilice el CBWFQ?

CBWFQ y RSVP

Restricciones

Class-Based Weighted Fair Queueing distribuido

Interacción de RSVP con el DCBWFQ

Beneficios

Restricciones

Prerrequisitos

Prioridad IP RTP

Asignación de ancho de banda de la prioridad de IP RTP

Restricciones

Prioridad IP RTP de Frame Relay

Frame Relay PVC Interface Priority Queueing

Restricciones

Prerrequisitos

Cola de tiempo de latencia bajo

Asignación del ancho de banda LLQ

LLQ y Committes Bursa Size

LLQ y soporte de la cola de espera por VC para los adaptadores ATM

¿Por qué utilice el LLQ?

Restricciones

Low latency queueing distribuido

Garantizar el ancho de banda con el comando priority

Beneficios

Restricciones

Prerrequisitos

Cola de tiempo de latencia bajo para Frame Relay

Restricciones

Prerrequisitos

Cómo funciona

Almacenamiento en cola personalizado

Cómo funciona

Determinar los valores de cuenta de bytes para las colas

Cómo se utiliza la cuenta de bytes

Determinar la cuenta de bytes

Tamaños de la ventana

¿Por qué utilice el CQ?

Restricciones

Espera de la prioridad

Cómo funciona

Cómo los paquetes se clasifican para la espera de la prioridad

¿Por qué utilice la espera de la prioridad?

Restricciones

Administración del ancho de banda


Descripción general de la administración de congestión


Las funciones de administración de la congestión permiten que usted controle la congestión determinando la orden en la cual los paquetes se envían una interfaz basada en las prioridades asignadas a esos paquetes. La administración de la congestión exige la creación de las colas de administración del tráfico, la asignación de los paquetes a esas colas de administración del tráfico basadas en la clasificación del paquete, y la previsión de los paquetes en una cola para la transmisión. La administración de la congestión función de calidad de servicio (QoS) ofrece cuatro tipos de protocolos de espera, que permite que usted especifique la creación de un diverso número de colas de administración del tráfico, permitir mayor o los grados menores de diferenciación del tráfico, y especificar la orden en la cual se envía ese tráfico.

Durante los períodos con el tráfico liviano, es decir, cuando existe ninguna congestión, los paquetes se envían la interfaz tan pronto como lleguen. Durante los períodos de transmita la congestión en la interfaz saliente, los paquetes llegan más rápidamente que la interfaz puede enviarlos. Si usted utiliza las funciones de administración de la congestión, los paquetes que acumulan en una interfaz se hacen cola hasta que la interfaz esté libre de enviarlas; entonces se programan para la transmisión según su prioridad asignada y el mecanismo de espera configurado para la interfaz. El router determina la orden de la transmisión de paquetes controlando se colocan qué paquetes en los cuales cola y cómo las colas se mantiene en cuanto a uno a.

Este módulo discute estos cuatro tipos de espera, que constituyen las características de QoS de la administración de la congestión:

(Primero en Salir FIFO) (primero en entrar, primero en salir). El (Primero en Salir FIFO) no exige ningún concepto de prioridad o clase de tráfico. Con el (Primero en Salir FIFO), la transmisión de paquetes hacia fuera la interfaz ocurre en la orden que llegan los paquetes.

Espera cargada de la feria (WFQ). El WFQ ofrece dinámico, feria que hace cola que ancho de banda de las divisorias a través de las colas de administración del tráfico del tráfico basadas en las ponderaciones. (el WFQ se asegura de que todo el tráfico esté tratado bastante, dado su ponderación.) Para entender cómo los trabajos WFQ, consideran la cola para una serie de paquetes del File Transfer Protocol (FTP) como una cola para la colectividad y la cola para los paquetes discretos del tráfico interactivo como cola para el individuo. Dado la ponderación de las colas de administración del tráfico, el WFQ se asegura de que para todos los paquetes FTP enviados como colectividad un mismo número de paquetes individuales del tráfico interactivo están enviados.)

Dado esta dirección, el WFQ asegura el tiempo de la respuesta satisfactoria a las aplicaciones críticas, tales como interactivo, las aplicaciones basadas en la transacción, que son intolerantes de la degradación del rendimiento. Para las interfaces seriales en el e1 (2.048 Mbps) y abajo, el flujo basado WFQ se utiliza por abandono. Cuando no se configura a ningunas otras Estrategias de almacenamiento en cola, el resto de las interfaces utilizan el (Primero en Salir FIFO) por abandono.

Hay cuatro tipos de WFQ:

– Flujo basado WFQ (WFQ)

– WFQ distribuido (DWFQ)

– Class-Based WFQ (CBWFQ)

– Class-Based WFQ distribuido (DCBWFQ)

Asignación personalizada de colas. Con el CQ, el ancho de banda se afecta un aparato proporcional para cada diversa clase de tráfico. El CQ permite que usted especifique la cantidad de bytes o los paquetes que se extraerán de la cola, que es especialmente útil en las interfaces lentas.

Asignación de colas de prioridad (PQ). Con el PQ, los paquetes que pertenecen a una clase de prioridad de tráfico se envían antes de todo el tráfico de prioridad más baja para asegurar la salida oportuna de esos paquetes.


Notausted puede asignar solamente un tipo de espera del mecanismo a una interfaz.



Observeuna variedad de mecanismos de espera puede ser configurado usando el multilink, por ejemplo, el multilink de multichasis PPP (MMP). Sin embargo, si solamente el PPP se utiliza en una interfaz tunneled — por ejemplo, el Virtual Private Dialup Network (VPND), PPP over Ethernet (pppoe), o PPP por Frame Relay (PPPoFR) — ninguna espera se puede configurar en la interfaz virtual.


¿Por qué utilice la administración de la congestión?

Las redes heterogéneas incluyen muchos diversos protocolos usados por las aplicaciones, dando lugar a la necesidad de dar prioridad al tráfico para satisfacer las aplicaciones de puntualidad crítica mientras que todavía dirigen las necesidades de las aplicaciones menos dependientes del tiempo, tales como transferencia de archivos. Diversos tipos de tráfico que comparten un trayecto de datos a través de la red pueden obrar recíprocamente el uno con el otro de las maneras que afectan a su rendimiento de la aplicación. Si su red se diseña para apoyar diversos tipos de tráfico que compartan un solo trayecto de datos entre el Routers, usted debe considerar usando las técnicas de administración de la congestión para asegurar la imparcialidad del tratamiento a través de los diversos tipos de tráfico.

Aquí están algunos factores amplios para considerar en determinar si configurar la administración de la congestión QoS:

La priorización del tráfico es especialmente importante para la retrasa sensible, las aplicaciones interactivas de transacción — por ejemplo, videoconferencia de escritorio — que requieren la prioridad más alta que las aplicaciones de la transferencia de archivos. Sin embargo, el uso del WFQ se asegura de que todo el tráfico esté tratado bastante, dado su ponderación, y de una manera dinámica. Por ejemplo, el WFQ dirige los requisitos de la aplicación interactiva sin la penalización de la aplicación FTP.

El priorización es el más eficaz en los links PÁLIDOS donde la combinación de tráfico congestionado y las velocidades de datos inferiores puede causar relativamente la congestión temporal.

Dependiendo de los tamaños promedios de los paquetes, el priorización es el más eficaz cuando está aplicado a los links a las velocidades del ancho de banda T1/E1 o baja.

Si los usuarios de las aplicaciones que se ejecutan a través de su red notan el tiempo de respuesta pobre, usted debe considerar usando las funciones de administración de la congestión. Las funciones de administración de la congestión son dinámicas, adaptándose a las condiciones de la red existente. Sin embargo, considere que si un link PÁLIDO se congestiona constantemente, la priorización del tráfico puede not resolver el problema. Agregar el ancho de banda pudo ser la solución apropiada.

Si no hay congestión en el link WAN, no hay razón para implementar la priorización del tráfico.

La lista siguiente resume los aspectos que usted debe considerar en determinar si usted debe establecer y implementar una política de colocación encola para su red:

Determine si se congestiona el WAN - es decir, si los usuarios de ciertas aplicaciones perciben una degradación del rendimiento.

Determine sus metas y objetivos basados en la mezcla de tráfico que usted necesita manejar y su topología de red y diseñar. En la identificación de lo que usted quiere alcanzar, considere si su meta está entre el siguiente:

– Para establecer la distribución justa de la asignación de ancho de banda a través de todos los tipos de tráfico que usted identifica.

– Para conceder la prioridad estricta para traficar de las clases especiales de aplicaciones que usted mantiene — por ejemplo, las aplicaciones de los multimedia interactivos — posiblemente a expensas del tráfico menos-crítico usted también soporta.

– Para personalizar la asignación de ancho de banda para compartir los recursos de red entre todas las aplicaciones que usted mantiene, cada uno que tiene los requerimientos de ancho de banda específicos usted ha identificado.

– Configurar con eficacia la espera. Usted debe analizar los tipos de tráfico que usan la interfaz y determinar cómo distinguirlos. Vea el módulo de la “Descripción general de la clasificación” para una descripción de cómo se clasifican los paquetes.

Después de que usted evalúe sus necesidades, revise los mecanismos de espera de la administración de la congestión disponible descritos en este módulo y determinelos que se acercan al mejor dirigen sus requisitos y metas.

Configure la interfaz para la clase de Estrategia de almacenamiento en cola que usted ha elegido, y observe los resultados.

Los patrones de tráfico cambian en un cierto plazo, así que usted debe relanzar el proceso del análisis descrito en el segundo punto negro periódicamente, y adapta la configuración de espera por consiguiente.

Vea la sección siguiente el “decidir de qué política de colocación encola a utilizar” para la elaboración de las diferencias entre los diversos mecanismos de espera.

Decisión de qué política de colocación encola para utilizar

Esta sección mira abreviadamente algunas de las diferencias entre los tipos de espera e incluye una tabla que compare las Estrategias de almacenamiento en cola principales.

La espera (Primero en Salir FIFO) no realiza ningún priorización de los paquetes de datos en el tráfico de datos del usuario. No exige ningún concepto de prioridad o clase de tráfico. Cuando se utiliza el (Primero en Salir FIFO), las fuentes mal educadas pueden consumir el ancho de banda disponible, las fuentes bursty pueden causar los retardos en el tráfico sensible al tiempo o importante, y el tráfico importante puede ser caído porque menos tráfico importante llena la cola.

Considere estas diferencias en la decisión de si utilizar el CQ o el PQ:

El CQ garantiza un cierto nivel de servicio a todo el tráfico porque usted puede afectar un aparato el ancho de banda a todas las clases de tráfico. Usted puede definir los tamaños de la cola determinando su capacidad configurada de la cuenta de paquetes, de tal modo controlando el acceso de ancho de banda.

El PQ garantiza la prioridad estricta en que se asegura de que envíen un tipo de tráfico, posiblemente a expensas de todos los demás. Para el PQ, una cola de baja prioridad puede ser afectada perjudicial, y, en el peor de los casos, nunca ser permitida enviar sus paquetes si las cantidades limitadas de ancho de banda están disponibles o si la velocidad de transmisión de tráfico crítico es alta.

En la decisión de si utilizar el WFQ o uno de los otros dos tipos de espera, considere estas diferencias entre el WFQ y PQ y CQ:

El WFQ no requiere la configuración de las Listas de acceso determinar el tráfico preferido en una interfaz serial. Bastante, el algoritmo de la cola justa clasifica dinámicamente el tráfico en los mensajes que son parte de a la conversación.

De poco volumen, el tráfico interactivo consigue la asignación adecuada del ancho de banda con el WFQ, al igual que el tráfico en grandes cantidades tal como transferencias de archivos.

La espera de la prioridad estricta se puede lograr con el WFQ usando la prioridad de IP RTP, la Prioridad de IP RTP en Frame Relay, el low latency queueing (LLQ), el low latency queueing distribuido, el Procesamiento de baja latencia de datos prioritarios en espera para Frame Relay, o las características del Interfaz de priorización de datos en espera de Frame Relay PVC. El PQ estricto permite que los datos sensibles al retardo tales como Voz dequeued y que sean enviados antes de que los paquetes en otras colas de administración del tráfico dequeued.

El cuadro 1 compara las características salientes del flujo basado WFQ, CBWFQ y DCBWFQ, CQ, y PQ.

Comparación de espera del cuadro 1

 
WFQ basado en flujos
CBWFQ/DCBWFQ
CQ
PQ

Number of Queues

Número configurable de colas de administración del tráfico (colas de administración del tráfico del usuario 256, por abandono)

Una cola por la clase, hasta 64 clases

16 colas de administración del tráfico del usuario

4 colas de administración del tráfico

Kind of Service

Asegura la imparcialidad entre todos los flujos de tráfico basados en las ponderaciones

La espera de la prioridad estricta está disponible con el uso de las características de la prioridad de IP RTP o de la Prioridad de IP RTP en Frame Relay

Proporciona la garantía de ancho de banda de la clase para las clases de tráfico definidas por el usario

Proporciona el soporte del flujo basado WFQ para las clases de tráfico no utilizador-definidas

La espera de la prioridad estricta está disponible con el uso de la prioridad de IP RTP, de la Prioridad de IP RTP en Frame Relay, del LLQ, del LLQ distribuido, y del LLQ para las características de Frame Relay

Servicio circular

Las colas de alta prioridad se mantienen primero

Priorización absoluto; asegura el tráfico crítico de la prioridad más alta con el uso de la característica del Interfaz de priorización de datos en espera de Frame Relay PVC

Configuration

Ninguna configuración requerida

Requiere la configuración

Requiere la configuración

Requiere la configuración


Colas primero en entrar, primero en salir

En su forma más simple, la espera (Primero en Salir FIFO) — también conocida como primero-vienen, primero-servido (FCFS) la espera — implica el mitigar y el remitir de los paquetes en la orden de la llegada.

El (Primero en Salir FIFO) no personifica ningún concepto de prioridad o clase de tráfico y por lo tanto no toma ninguna decisión sobre la prioridad del paquete. Hay solamente una cola, y todos los paquetes se tratan igual. Los paquetes se envían una interfaz en el orden en que llegan.

Cuando se utiliza el (Primero en Salir FIFO), las fuentes mal educadas pueden consumir todo el ancho de banda, las fuentes bursty pueden causar los retardos en el tráfico sensible al tiempo o importante, y el tráfico importante puede ser caído porque menos tráfico importante llena la cola.

Cuando no se configura a ningunas otras Estrategias de almacenamiento en cola, todas las interfaces excepto las interfaces seriales en el e1 (2,048 Mbps) y debajo del uso (Primero en Salir FIFO) por abandono. (Interfaces seriales en el e1 y debajo del uso WFQ por abandono.)

El (Primero en Salir FIFO), que es el método más rápido de espera, es eficaz para los links grandes que tienen poco retardo y congestión mínima. Si su link tiene congestión muy pequeña, la espera (Primero en Salir FIFO) puede ser la única haciéndole cola necesidad de utilizar.

Espera cargada de la feria

Esta sección discute los cuatro tipos de WFQ descritos en las secciones siguientes:

Espera cargada flujo basado de la feria

Espera cargada distribuida de la feria

Colocación en cola equilibrada ponderada calculada en función de la clase

Class-Based Weighted Fair Queueing distribuido

Esta sección también discute las seis características relacionadas descritas en las secciones siguientes:

Prioridad IP RTP

Prioridad IP RTP de Frame Relay

Frame Relay PVC Interface Priority Queueing

Cola de tiempo de latencia bajo

Low latency queueing distribuido

Cola de tiempo de latencia bajo para Frame Relay

El cuadro 2 resume las diferencias entre el WFQ, el DWFQ, el CBWFQ, y el DCBWFQ.

Cuadro 2 comparación WFQ, DWFQ, CBWFQ, y del DCBWFQ

WFQ
DWFQ
CBWFQ
DCBWFQ

Flujo basado WFQ:

Cargado, cuando se clasifican los paquetes; por ejemplo, Resource Reservation Protocol (RSVP)

Feria hecha cola (fq), cuando los paquetes no se clasifican (por ejemplo, tráfico Best-Effort (mejor esfuerzo))

Flujo basado DWFQ:

Fq, no cargado

DWFQ basado en la clase:

Cargado

QoS-grupo-basado

Tipo de servicio (ToS) - basado

Class-Based WFQ:

Cargado

La asignación de ancho de banda se puede especificar para una clase de tráfico específica

WFQ distribuido basado en la clase:

Cargado

La asignación de ancho de banda se puede especificar para una clase de tráfico específica

Funcionamientos en las plataformas de Cisco IOS estándar

Funcionamientos en el Versatile Interface Processor (VIP) (un funcionamiento más rápido)

Funcionamientos en las plataformas de Cisco IOS estándar

Funcionamientos en VIP (un funcionamiento más rápido)


Para el DWFQ y el DCBWFQ, todo la espera es tramitada por el VIP. En el VIP, todos los paquetes se envían directamente hacia fuera la interfaz. Un Route Switch Processor (RSP) reside en la misma plataforma que el VIP. El RSP maneja todas las tareas asociadas al mantenimiento del sistema y a la encaminamiento. El VIP y el RSP cada manija una cierta previsión. El soporte del procesador dual explica la velocidad más rápida del DWFQ y del DCBWFQ sobre el WFQ que se ejecuta en las plataformas de Cisco IOS estándar.

Para la información sobre cómo configurar el WFQ, el DWFQ, el CBWFQ, y el DCBWFQ, ven “configurar el módulo de espera cargado de la feria”. Para la información sobre cómo configurar el WFQ por VC y el CBWFQ, vea “configurando el módulo de la Clase de Servicio IP a ATM”.

Espera cargada flujo basado de la feria

El WFQ es un método de la previsión dinámica que proporciona la asignación del ancho de banda justo a todo el tráfico de la red. El WFQ aplica la prioridad, o las ponderaciones, al tráfico identificado para clasificar el tráfico en las conversaciones y para determinar cuánto ancho de banda no se prohibe cada conversación en relación con otras conversaciones. El WFQ es un algoritmo del flujo basado que programa simultáneamente el tráfico interactivo al frente de una cola para reducir el tiempo de respuesta y comparte bastante el ancho de banda restante entre los flujos del ancho de banda alto. Es decir el WFQ permite que usted dé el tráfico de poco volumen, tal como sesiones telnets, prioridad sobre el tráfico en grandes cantidades, tal como sesiones FTP. El WFQ da el uso equilibrado las transferencias de archivos simultáneas de la capacidad del link; es decir, cuando ocurren las transferencias de Archivo múltiple, las transferencias se dan el ancho de banda comparable. Cuadro 1 demostraciones cómo el WFQ trabaja.

Cuadro 1 espera cargada de la feria

El WFQ supera una limitación grave de la espera (Primero en Salir FIFO). Cuando el (Primero en Salir FIFO) está en efecto, el tráfico se envía en la orden recibida sin pensar en el consumo de ancho de banda o los retardos asociados. Como consecuencia, las transferencias de archivos y otras aplicaciones de red en grandes cantidades generan a menudo la serie de paquetes de datos asociados. Estos paquetes relacionados se conocen como trenes del paquete. Los trenes del paquete son grupos de paquetes que tiendan a acercar a través de la red. Estos trenes del paquete pueden consumir todo el ancho de banda disponible, privando el otro tráfico del ancho de banda.

El WFQ proporciona la Administración de la prioridad de tráfico que clasifica dinámicamente el tráfico en los mensajes que componen una conversación. El WFQ rompe para arriba el tren de los paquetes dentro de una conversación para asegurarse de que el ancho de banda está compartido bastante entre las conversaciones individuales y de que el tráfico de poco volumen está transferido a su debido tiempo.

El WFQ clasifica el tráfico en diversos flujos basados en el encabezado de paquete que dirige, incluyendo las características tales como la fuente y red de destino o dirección MAC, protocolo, puerto de origen y de destino y los números de socket del valor de la sesión, del identificador de la conexión de link de datos de Frame Relay (DLCI), y de valor TOS. Hay dos categorías de flujos: sesiones del ancho de banda alto y sesiones del ancho de banda baja. El tráfico del ancho de banda baja tiene prioridad eficaz sobre el tráfico de ancho de banda alto, y el tráfico de ancho de banda alto comparte el servicio de transmisión proporcional según los pesos asociados. Los flujos de tráfico del ancho de banda baja, que comprenden el mayor parte del tráfico, reciben el servicio preferencial, permitiendo que sus cargas ofrecidas enteras sean enviadas a su debido tiempo. Los flujos de tráfico en grandes cantidades comparten la capacidad restante proporcional entre ellos mismos.

El WFQ coloca los paquetes de las diversas conversaciones en las colas justas antes de la transmisión. La orden del retiro de las colas justas se determina por la época virtual de la salida del bit más reciente de cada paquete de llegada.

Los nuevos mensajes para los flujos del ancho de banda alto se desechan después de que se haya resuelto el umbral de los congestivo-mensajes. Sin embargo, los flujos del ancho de banda baja, que incluyen las conversaciones de mensaje de control, continúan enviando a la cola los datos. Como consecuencia, la cola justa puede contener de vez en cuando más mensajes que son especificados por el número de umbral.

El WFQ puede manejar las secuencias de datos dúplexes, tales como ésos entre los pares de aplicaciones, y los datos simples fluyen por ejemplo la Voz o el vídeo.

El algoritmo WFQ también aborda el problema de la variabilidad del retardo de ida y vuelta. Si las conversaciones en grandes cantidades múltiples son activas, sus velocidades de transferencia y períodos entre llegadas se hacen mucho más fiables. El WFQ aumenta grandemente los algoritmos tales como Logical Link Control (LLC) de la Arquitectura de red de sistemas (SNA) y control de la congestión TCP y reduce las características del comienzo.

Se utiliza el flujo basado WFQ mientras que el modo de espera predeterminado en la mayoría de las interfaces seriales configuradas para ejecutarse en las velocidades del e1 (2.048 Mbps) o abajo.

El WFQ proporciona la solución para las situaciones en las cuales es deseable proporcionar el tiempo de respuesta constante a los usuarios de la red pesados y ligeros igualmente sin agregar el ancho de banda excesivo. El WFQ se adapta automáticamente a las condiciones de tráfico de la red cambiantes.

Restricciones

El WFQ no se soporta con el Tunelización y el cifrado porque estas características modifican la información del contenido de paquetes requerida por el WFQ para la clasificación.

Aunque el WFQ se adapte automáticamente a las condiciones de tráfico de la red cambiantes, no ofrece el grado de control de la precisión sobre la asignación de ancho de banda que el CQ y el CBWFQ ofrecen.

WFQ y Prioridad IP

El WFQ es IP precedencia-enterado. Puede detectar paquetes más prioritarios marcados con la precedencia por el promotor IP y puede programarlos más rápidamente, proporcionando al tiempo de respuesta superior para este tráfico. Así, como la precedencia aumenta, el WFQ afecta un aparato más ancho de banda a la conversación durante los períodos de congestión.

El WFQ asigna una ponderación a cada flujo, que determina la pedido del transmitir para los paquetes en cola. En este esquema, ponderaciones más bajas se sirven primero. Para el Cisco IOS estándar WFQ, la Prioridad IP sirve como divisor a este factor de ponderación.

Como el CQ, el WFQ envía algunos bytes de cada cola. Con el WFQ, cada cola corresponde a un diverso flujo. Para cada ciclo con todo fluye, el WFQ envía con eficacia varios bytes iguales a la precedencia del flujo más uno. Este número se utiliza solamente como relación de transformación para determinar cuántos bytes por paquete a enviar. Sin embargo, con el propósito de entender el WFQ, usando este número como la cuenta de bytes es suficiente. Por ejemplo, el tráfico con un valor de precedencia IP de 7 consigue una ponderación más baja que el tráfico con un valor de precedencia IP de 3, así, la prioridad adentro transmite la orden. Las ponderaciones son inverso proporcionales al valor de precedencia IP.

Para determinar la asignación de ancho de banda para cada cola, divida la cuenta de bytes para el flujo por la cuenta de total de bytes para todos los flujos. Por ejemplo, si usted tiene un flujo en cada Nivel de precedencia, cada flujo conseguirá la precedencia + 1 parte del link:

1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 = 36

Así, la precedencia 0 tráficos conseguirá 1/36 del ancho de banda, la precedencia 1 tráfico conseguirá 2/36, y el tráfico de la precedencia 7 conseguirá 8/36.

Sin embargo, si usted tiene 18 flujos de la precedencia 1 y una de cada uno del resto, el total ahora está:

1 + 2(18) + 3 + 4 + 5 + 6 + 7 + 8 = 70

La precedencia que 0 tráficos conseguirán 1/70, cada uno de los flujos de la precedencia 1 conseguirá 2/70, y así sucesivamente.

Como flujos se agregan o terminado, el ancho de banda afectado un aparato real cambiará continuamente.

WFQ y RSVP

RSVP utiliza el WFQ para afectar un aparato los paquetes del espacio del búfer y del horario, y para garantizar el ancho de banda para los flujos reservados. Los trabajos WFQ con RSVP a ayudar a proporcionar distinguieron y garantizaron los servicios de QoS.

RSVP es el protocolo de la norma de Internet de la Fuerza de tareas de ingeniería en Internet (IETF) (IETF) (RFC 2205) para permitir que una aplicación reserve dinámicamente el ancho de banda de la red. RSVP permite a las aplicaciones para pedir un QoS específico para un flujo de datos. La implementación de Cisco permite que RSVP sea iniciado dentro de la red usando el proxy configurado RSVP.

RSVP es el único protocolo de señalización estándar diseñado para garantizar el ancho de banda de la red de punta a punta para las redes IP. Uso RSVP de los hosts y del Routers de entregar las peticiones de QoS al Routers a lo largo de las trayectorias de la secuencia de datos y de mantener el estado del router y de host para proporcionar el servicio pedido, generalmente ancho de banda y tiempo de espera. El RSVP utiliza una velocidad de datos mala, la cantidad más grande de datos que el router mantendrá la cola, y QoS mínimo para determinar la reserva de ancho de banda.

El WFQ o el Weighted Random Early Detection (WRED) actúa como el preparador para RSVP, configurando la clasificación de paquetes y la previsión requeridas para los flujos reservados. Usando el WFQ, RSVP puede entregar un servicio garantizado de los Servicios integrados.

Espera cargada distribuida de la feria

El DWFQ es una versión de alta velocidad especial del WFQ que se ejecuta en el VIP. Se soporta en el Routers siguiente con un VIP2-40 o un mayor procesador de interfaz:

Cisco 7000 Series con el RSP7000

Cisco 7500 Series

Se recomienda un procesador de interfaz VIP2-50 cuando la línea global tarifa de los adaptadores de puerto en el VIP es mayor que el DS3. Un indicador luminoso LED amarillo de la placa muestra gravedad menor VIP2-50 se requiere para las tarifas OC-3.

Para utilizar el DWFQ, el Distributed Cisco Express Forwarding (dCEF) que conmuta se debe habilitar en la interfaz. Para más información sobre el CEF, vea “el módulo del mapa de ruta de las características del Cisco Express Forwarding”.


Observela implementación VIP-distribuida WFQ diferencia del WFQ que se ejecuta en el resto de las Plataformas.


Hay dos formas de WFQ distribuido:

Flujo basado. En esta forma, los paquetes son clasificados por el flujo. Los paquetes con la misma dirección IP de origen, IP Address de destino, fuente TCP o puerto del User Datagram Protocol (UDP), TCP de destino o puerto UDP, protocolo, y campo TOS pertenecen al mismo flujo. (Todos los paquetes del no IP se tratan como flujo 0.)

Cada flujo corresponde a una cola de salida separada. Cuando un paquete se asigna a un flujo, se coloca en la cola para ese flujo. Durante los períodos de congestión, el DWFQ afecta un aparato una parte igual del ancho de banda a cada cola activa.

El flujo basado DWFQ también se llama feria que hace cola porque todos los flujos se cargan igualmente y ancho de banda igual afectado un aparato. En la implementación actual del DWFQ, las ponderaciones no se asignan a los flujos. Con el DWFQ, los buenos hosts se protegen contra los hosts mal educados.

Basado en la clase. En esta forma, los paquetes se asignan a diversas colas de administración del tráfico basadas en su grupo de QoS o la Prioridad IP en el campo TOS.

Los grupos de QoS permiten que usted personalice su política de calidad de servicio (QoS). Un grupo de QoS es una clasificación interna de los paquetes usados por el router para determinar cómo los paquetes son tratados por ciertas características de QoS, tales como DWFQ y Committed Access Rate (CAR). Utilice una directiva CAR o el QoS Policy Propagation vía la característica del Border Gateway Protocol (BGP) para asignar los paquetes a los grupos de QoS.

Si usted quiere clasificar los paquetes basados solamente en los dos bits de orden inferior de la Prioridad IP, utilice el DWFQ basado en TOS. Especifique una ponderación para cada clase. En los períodos de congestión, afectan un aparato cada grupo un porcentaje del ancho de banda de la salida igual a la ponderación de la clase. Por ejemplo, si una clase se asigna una ponderación de 50, los paquetes de esta clase serán afectados un aparato por lo menos el 50 por ciento del ancho de banda saliente durante los períodos de congestión. Cuando la interfaz no se congestiona, las colas de administración del tráfico pueden utilizar cualquier ancho de banda disponible.

La sección de la “política para tirar paquetes” describe la política para tirar paquetes usada por ambas formas.

Política para tirar paquetes

El DWFQ no pierde de vista el número de paquetes en cada cola y el número total de paquetes en todas las colas de administración del tráfico.

Cuando el número total de paquetes está debajo del límite global, las colas de administración del tráfico pueden mitigar más paquetes que el límite de cola individual.

Cuando el número total de paquetes alcanza el límite global, la interfaz comienza a aplicar los límites de cola individuales. Se cae cualquier nuevo paquete que llegue para una cola que ha excedido su límite de cola individual. Los paquetes que están ya en la cola no serán caídos, incluso si la cola está sobre el límite individual.

En algunos casos, el número total de paquetes en todas las colas de administración del tráfico puestas juntas puede exceder el límite global.

Restricciones

Utilice el DWFQ con el tráfico IP. Todo el tráfico no IP se trata como flujo único y, por lo tanto, se coloca en la misma cola.

El DWFQ tiene las restricciones siguientes:

Puede ser configurado en las interfaces, pero no las subinterfaces.

No se soporta con los encapsulados ATM AAL5-MUX y AAL5-NLPID.

No se soporta en el Fast EtherChannel, las interfaces del túnel, o el otro lógico (virtual) interconecta por ejemplo el Multilink PPP (MLP).

No puede ser configurado en la misma interfaz que el PQ RSP basado, el CQ, o el WFQ.

Colocación en cola equilibrada ponderada calculada en función de la clase

El CBWFQ amplía la funcionalidad WFQ estándar para proporcionar el soporte para las clases de tráfico definidas por el usario. Para el CBWFQ, usted define las clases de tráfico basadas en los criterios de concordancia incluyendo los protocolos, el Listas de control de acceso (ACL), y las interfaces de entrada. Los paquetes que satisfacen los criterios de concordancia para una clase constituyen el tráfico para esa clase. Una cola primero en entrar, primero en salir es reservada para cada clase, y el tráfico que pertenece a una clase se dirige a la cola para esa clase.

Una vez que una clase se ha definido según sus criterios de concordancia, usted puede asignarle las características. Para caracterizar una clase, usted le asigna el ancho de banda, la ponderación, y el límite del PAQUETE MÁXIMO. El ancho de banda asignado a una clase es el ancho de banda garantizado entregada a la clase durante la congestión.

Para caracterizar una clase, usted también especifica el límite de cola para esa clase, que es la cantidad máxima de paquete permitida acumular en la cola para la clase. Los paquetes que pertenecen a una clase están conforme al ancho de banda y a los límites de cola que caracterizan la clase.

Después de que una cola haya alcanzado su límite de cola configurado, el enviar a la cola de los paquetes adicionales a la clase hace la eliminación de cola o la caída de paquetes tomar el efecto, dependiendo de cómo se configura la política de clase.

La eliminación de cola se utiliza para las clases CBWFQ a menos que usted configure explícitamente la directiva para que una clase utilice el WRED para caer los paquetes como medio para evitar la congestión. Observe que si usted utiliza la caída de paquetes WRED en vez de la eliminación de cola para una o más clases que comprenden una correspondencia de políticas, usted debe asegurarse de que el WRED no esté configurado para la interfaz a la cual usted asocia esa política de servicio.

Si una clase predeterminada se configura con bandwidth el comando de configuración de clase del directiva-mapa, todo el tráfico no clasificado se pone en una sola cola primero en entrar, primero en salir y un tratamiento dado según el configuré el ancho de banda. Si una clase predeterminada se configura con fair-queue el comando, todo el tráfico no clasificado es tratamiento clasificado y dado del flujo del mejor esfuerzo. Si no se configura ninguna clase predeterminada, después por abandono el tráfico que no hace juego las clases configuradas unas de los es tratamiento clasificado y dado del flujo del mejor esfuerzo. Una vez que se clasifica un paquete, todos los mecanismos estándars que se pueden utilizar para distinguir el servicio entre las clases se aplican.

La clasificación del flujo es tratamiento estándar WFQ. Es decir, los paquetes con la misma dirección IP de origen, IP Address de destino, fuente TCP o puerto UDP, o TCP de destino o puerto UDP se clasifican como perteneciendo al mismo flujo. El WFQ afecta un aparato una parte igual del ancho de banda a cada flujo. El flujo basado WFQ también se llama feria que hace cola porque todos los flujos se cargan igualmente.

Para el CBWFQ, la ponderación especificada para la clase se convierte en la ponderación de cada paquete que cumpla los criterios de concordancia de la clase. Los paquetes que llegan la interfaz de salida se clasifican según los criterios de concordancia le filtran definen, después cada uno se asigna la ponderación apropiada. La ponderación para un paquete que pertenece a una clase específica se deriva del ancho de banda que usted asignó a la clase cuando usted lo configuró; en este sentido la ponderación para una clase es utilizador configurable.

Después de que la ponderación para un paquete se asigne, el paquete se envía a la cola en la cola de clases apropiada. El CBWFQ utiliza las ponderaciones asignadas a los paquetes en cola para asegurarse de que la cola de clases está mantenida bastante.

Configurar una política de clase — así, configurando el CBWFQ — exige estos tres procesos:

Definición de las clases de tráfico para especificar la política de clasificación (correspondencias de la clase).

Este proceso determina cuántos tipos de paquetes deben ser distinguidos a partir del uno otro.

Asociando las directivas - es decir, características de la clase — a cada clase de tráfico (correspondencias de políticas).

Este proceso exige la configuración de las directivas que se aplicarán a los paquetes que pertenecen a una de las clases definidas previamente a través de una correspondencia de la clase. Para este proceso, usted configura una correspondencia de políticas que especifique la directiva para cada clase de tráfico.

Asociar las directivas a las interfaces (políticas de servicio).

Este proceso requiere que usted asocie una correspondencia de la política existente, o política de servicio, con una interfaz para aplicar el conjunto determinado de las directivas para la correspondencia a esa interfaz.

Asignación de ancho de banda CBWFQ

La suma de toda la asignación de ancho de banda en una interfaz no puede exceder el 75 por ciento del ancho de banda de la interfaz disponible total. Que sigue habiendo el 25 por ciento se utiliza para otros gastos indirectos, incluyendo la capa 2 de arriba, ruteando el tráfico, y tráfico Best-Effort (mejor esfuerzo). Que sigue habiendo el ancho de banda para el clase class-default CBWFQ, por ejemplo, se toma del 25 por ciento. Sin embargo, bajo circunstancias agresivas en las cuales usted quiera configurar el más de 75 por ciento del ancho de banda de la interfaz a las clases, usted puede reemplazar la suma máxima del 75 por ciento afectada un aparato a todas las clases o flujos. Si usted quiere reemplazar el valor por defecto el 75 por ciento, ejercite la precaución y asegúrese de que usted permite bastante ancho de banda restante para soportar el tráfico de máximo esfuerzo y de control, y acode 2 de arriba.

Cuando se utiliza la atmósfera usted debe explicar el hecho de que los gastos indirectos de los impuestos de célula ATM no son incluidos. Por ejemplo, considere el caso donde una clase necesita el ancho de banda garantizado en un circuito virtual permanente (PVC) atmósfera. Suponga que los tamaños promedios de los paquetes para la clase son los bytes 256 y la clase necesita 100 kbps (que traduce a 49 paquetes por segundo) del ancho de banda garantizado. Cada paquete del 256-byte estaría partido en seis células que se enviarán en un VC, dando un total de 6 * 53 = 318 bytes. En este caso, los gastos indirectos de los impuestos de célula ATM serían 62 bytes o 49 * 62 * 8 = 24,34 kbps. Al configurar el CBWFQ en este ejemplo, asegúrese de que la suma de todos los anchos de banda de la clase configurada es menos que el ancho de banda del VC por por lo menos 24,34 kbps a asegurar deseó la garantía del payload para las clases configuradas (en este ejemplo, hay solamente una clase). Si usted tiene varias clases, la suma de todo el overheads de la clase se debe estimar y agregar a la suma de todos los anchos de banda de la clase configurada. Este total debe ser menos que el ancho de banda del VC para asegurar las garantías requeridas del payload.

¿Por qué utilice el CBWFQ?

Aquí están algunos generales le descomponen en factores deben considerar en determinar si usted necesita configurar el CBWFQ:

Asignación de ancho de banda. El CBWFQ permite que usted especifique la cantidad exacta de ancho de banda que se afectará un aparato para una clase de tráfico específica. Teniendo en cuenta el ancho de banda disponible en la interfaz, usted puede configurar hasta 64 clases y controlar la distribución entre ellas, que no es el caso con el flujo basado WFQ. El flujo basado WFQ aplica las ponderaciones para traficar para clasificarla en las conversaciones y para determinar cuánto ancho de banda no se prohibe cada conversación en relación con otras conversaciones. Para el flujo basado WFQ, estas ponderaciones, y la Clasificación de tráfico, son dependientes en y limitado siete a la Prioridad IP los niveles.

Un granularity más grueso y scalability. El CBWFQ permite que usted defina qué constituye una clase basada en los criterios que exceden los límites del flujo. El CBWFQ permite que usted utilice los ACL y los protocolos o los nombres de la interfaz de entrada para definir cómo el tráfico será clasificado, de tal modo proporcionando a un granularity más grueso. Usted no necesita mantener la Clasificación de tráfico sobre una base del flujo. Por otra parte, usted puede configurar hasta 64 clases discretas en una política de servicio.

CBWFQ y RSVP

RSVP se puede utilizar conjuntamente con el CBWFQ. Cuando RSVP y el CBWFQ se configuran para una interfaz, un acto de RSVP y CBWFQ independientemente, exhibiendo el mismo comportamiento que si cada uno se ejecutaba solamente. RSVP continúa trabajando como lo hace cuando el CBWFQ no está presente, incluso con respecto a la disponibilidad del ancho de banda de la evaluación y asignación.

Restricciones

Configurar el CBWFQ en una interfaz física es solamente posible si la interfaz está en el modo de espera predeterminado. Interfaces seriales en el e1 (2.048 Mbps) y debajo del uso WFQ por abandono — otras interfaces utilizan el (Primero en Salir FIFO) por abandono. Habilitar el CBWFQ en una interfaz física reemplaza el método de espera de la interfaz predeterminada. Habilitar el CBWFQ en una atmósfera PVC no reemplaza el método de espera predeterminado.

Si usted configura una clase en una correspondencia de políticas para utilizar el WRED 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.

El modelado de tráfico y el policing no se soportan actualmente con el CBWFQ.

El CBWFQ se soporta en el Velocidad de bits variable (VBR) y Velocidad de bits disponible (ABR) las conexiones ATM. No se soporta en las conexiones de la Velocidad de bit sin especificar (UBR).

El CBWFQ no se soporta en las subinterfaces Ethernet.

Class-Based Weighted Fair Queueing distribuido

Según lo explicado anterior, el WFQ ofrece dinámico, feria que hace cola que ancho de banda de las divisorias a través de las colas de administración del tráfico del tráfico basadas en las ponderaciones. El WFQ se asegura de que todo el tráfico esté tratado bastante, dado su ponderación. Para más información sobre el WFQ, vea “la sección de espera cargada de la feria” de este módulo.

La característica del DCBWFQ amplía la funcionalidad WFQ estándar para proporcionar el soporte para las clases de tráfico definidas por el usario en el VIP. Estas clases de tráfico definidas por el usario se configuran en la característica de la interfaz de línea de comando de calidad de servicio modular (Modular QoS CLI). Para la información sobre cómo configurar QoS con el Modular QoS CLI, vea “aplicando las características de QoS usando el módulo MQC”.

La cantidad máxima de paquete permitida acumular en una cola de la clase de tráfico se llama el límite de cola y se especifica con queue-limit el comando cuando usted crea una política de servicio con policy-map el comando. Los paquetes que pertenecen a una clase de tráfico están conforme a la asignación del ancho de banda garantizado y a los límites de cola que caracterizan la clase de tráfico.

Después de que una cola haya alcanzado su límite de cola configurado, el enviar a la cola de los paquetes adicionales a la clase de tráfico hace la eliminación de cola o el descenso WRED tomar el efecto, dependiendo de cómo se configura la política de servicio. (La eliminación de cola es los medios de evitar la congestión que 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).

La eliminación de cola se utiliza para las clases de tráfico del DCBWFQ a menos que usted configure explícitamente una política de servicio para utilizar el WRED para caer los paquetes como medio para evitar la congestión. Observe que si usted utiliza la caída de paquetes WRED en vez de la eliminación de cola para una o más clases de tráfico que componen una política de servicio, usted debe asegurarse de que el WRED no esté configurado para la interfaz a la cual usted asocia esa política de servicio.

Para la información sobre cómo configurar el DCBWFQ, vea “configurar el módulo de espera cargado de la feria”.

Interacción de RSVP con el DCBWFQ

Cuando se configuran RSVP y el DCBWFQ, acto independientemente de uno otro de RSVP y del DCBWFQ. RSVP y el DCBWFQ afectan un aparato el ancho de banda entre sus clases de tráfico y flujos según el ancho de banda unallocated disponible en la punta subyacente de la congestión.

Cuando se crea un flujo de RSVP, las reservas de sistema de espera VIP la unidad de asignación de ancho de banda en una cola de RSVP, similar a la manera una cola de la clase de tráfico se asignan a una clase de tráfico del DCBWFQ. Las clases de tráfico del DCBWFQ son inafectadas por los flujos de RSVP.

Beneficios

Asignación de ancho de banda

El DCBWFQ permite que usted especifique la cantidad de ancho de banda garantizado que se afectará un aparato para una clase de tráfico. Teniendo en cuenta el ancho de banda disponible en la interfaz, usted puede configurar hasta 64 clases de tráfico y controlar la asignación de ancho de banda entre ellas. Si el ancho de banda en exceso está disponible, el ancho de banda en exceso se divide entre las clases de tráfico en proporción a sus configuré el ancho de banda.

El flujo basado WFQ afecta un aparato el ancho de banda igualmente entre todos los flujos.

Un granularity más grueso y scalability

El DCBWFQ permite que usted defina qué constituye una clase de tráfico basada en los criterios que exceden los límites del flujo. El DCBWFQ permite que usted utilice los ACL y los protocolos o los nombres de la interfaz de entrada para definir cómo el tráfico se clasifica, de tal modo proporcionando a un granularity más grueso. Usted no necesita mantener la Clasificación de tráfico sobre una base del flujo. Por otra parte, usted puede configurar hasta 64 clases de tráfico discretas en una política de servicio.

Restricciones

Usando el comando bandwidth en la clase del tráfico predeterminado VIP

En un VIP, todo el tráfico que no hace juego una clase de tráfico definida por el usario se clasifica como parte de la clase del tráfico predeterminado. El ancho de banda implícito afectado un aparato a la clase del tráfico predeterminado en un VIP es igual al ancho de banda de link menos todo el ancho de banda definido por el usario dado a las clases de tráfico definidas por el usario (con bandwidth el comando). Por lo menos el 1 por ciento del ancho de banda de link es siempre reservado para la clase del tráfico predeterminado.

Porque el ancho de banda de la clase del tráfico predeterminado para un VIP está implícito (la clase del tráfico predeterminado recibe todo el ancho de banda restante no dado a las clases de tráfico definidas por el usario), bandwidth el comando no se puede utilizar con la clase del tráfico predeterminado cuando usted configura un VIP.

Usando el comando match protocol en un VIP

No utilice 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.

Módulos PA-A3-8T1IMA

El DCBWFQ no se soporta en los Cisco 7500 Series Router con los módulos PA-A3-8T1IMA.

Prerrequisitos

WFQ

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.

Para la información sobre el WFQ, vea “configurar el módulo de espera cargado de la feria”.

ACL

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, usted debe saber configurar las Listas de acceso.

Modular QoS CLI

Usted puede configurar el DCBWFQ usando el Modular QoS CLI.

Para la información sobre configurar las características de QoS con el Modular QoS CLI, vea “aplicando las características de QoS usando el módulo MQC”.

Prioridad IP RTP

La característica de la prioridad de IP RTP proporciona un esquema de espera de la prioridad estricta para los datos sensibles al retardo tales como Voz. El tráfico de voz se puede identificar por sus números del puerto del Real-Time Transport Protocol (RTP) y clasificar en un priority queue configurado por ip rtp priority el comando. El resultado es que la Voz está mantenida como prioridad estricta preferentemente al otro tráfico nonvoice.


Observeaunque esta sección se centra principalmente en el tráfico de voz, la prioridad de IP RTP es útil para cualquier tráfico RTP.


La característica de la prioridad de IP RTP extiende y mejora en las funciones ofrecidas por ip rtp reserve el comando permitiendo que usted especifique un rango de los puertos UDP/RTP cuyo tráfico es servicio de prioridad estricta garantizado sobre cualesquiera otras colas de administración del tráfico o clases usando la misma interfaz de salida. La prioridad estricta significa que si los paquetes existen en el priority queue, dequeued y antes de que los paquetes en otras colas de administración del tráfico dequeued. Recomendamos que usted utiliza ip rtp priority el comando en vez ip rtp reserve del comando para las configuraciones de la voz.

La característica de la prioridad de IP RTP no requiere que usted conozca el puerto de una llamada de voz. Bastante, la característica le da la capacidad de identificar un rango de puertos cuyo tráfico se ponga en el priority queue. Por otra parte, usted puede especificar el rango entero del puerto de voz — 16384 a 32767 — para asegurarse de que todo el tráfico de voz está dado el servicio de prioridad estricta. La prioridad de IP RTP es especialmente útil en los links cuya velocidad es menos que el 1.544 Mbps.

Esta característica se puede utilizar conjuntamente con el WFQ o el CBWFQ en la misma interfaz saliente. En ambos casos, el tráfico que corresponde con el rango de puertos especificado para el priority queue se garantiza que fluye la prioridad estricta sobre las otras clases CBWFQ o WFQ; los paquetes en el priority queue se mantienen siempre primero. Observe las condiciones siguientes ip rtp priority del comando:

Cuando está utilizado conjuntamente con el WFQ, ip rtp priority el comando proporciona la prioridad estricta para expresar, y la previsión WFQ se aplica a las colas de administración del tráfico restantes.

Cuando está utilizado conjuntamente con el CBWFQ, ip rtp priority el comando proporciona la prioridad estricta para expresar. El CBWFQ se puede utilizar para configurar las clases para otros tipos de tráfico (tales como SNA) esos necesita el Ancho de banda dedicado y necesita ser mejor que mejor esfuerzo tratado y no como prioridad estricta; se mantiene el tráfico nonvoice basó bastante en las ponderaciones asignadas a los paquetes enviados a la cola. El CBWFQ puede también soportar el flujo basado WFQ dentro de la clase del valor por defecto CBWFQ si está configurado tan.

Porque los paquetes de voz son pequeños de tamaño y la interfaz también puede tener paquetes grandes que salen, la característica del Link Fragmentation and Interleaving (LFI) se debe también configurar en interfaces más de poca velocidad. Cuando usted habilita el LFI, los paquetes de datos grandes están quebrados para arriba para poder interpolar los paquetes de voz pequeños entre los fragmentos de dato que componen un paquete de datos grande. El LFI evita que los paquetes de voz necesiten esperar hasta que se envíe un paquete grande. En lugar, los paquetes de voz se pueden enviar en una cantidad de tiempo más corta.

Para la información sobre cómo configurar la prioridad de IP RTP, vea “configurar el módulo de espera cargado de la feria”.

Asignación de ancho de banda de la prioridad de IP RTP

Si usted quiere entender su comportamiento y utilizar correctamente la característica de la prioridad de IP RTP, es importante considerar su control de admisión y características del policing. Cuando usted utiliza ip rtp priority el comando de configurar el priority queue para la Voz, usted especifica una limitación de ancho de banda estricta. Esta cantidad de ancho de banda se garantiza al tráfico de voz enviado a la cola en el priority queue. (Éste es el caso si usted utiliza la característica de la prioridad de IP RTP con el CBWFQ o el WFQ.)


La prioridad de IP RTPde la nota no tiene por llamada control de admisión. El control de admisión está sobre una base global. Por ejemplo, si está configurada para 96 kbps, la prioridad de IP RTP garantiza que 96 kbps están disponibles para la reserva. No se asegura de que solamente cuatro llamadas de 24 kbps estén admitidas. Una quinta llamada de 24 kbps podría ser admitida, pero porque las cinco llamadas conseguirán solamente 96 kbps, la calidad de la llamada será deteriorada. (Cada llamada conseguiría el kbps 96/5 = 19,2.) En este ejemplo, es la responsabilidad del usuario asegurarse de que solamente cuatro llamadas están puestas al mismo tiempo.


La prioridad de IP RTP limpia de cerca el uso del ancho de banda para el priority queue, asegurándose de que la cantidad afectada un aparato no está excedida en caso de congestión. De hecho, la prioridad de IP RTP limpia el flujo cada segundo. La prioridad de IP RTP prohíbe la transmisión de los paquetes adicionales una vez que se consume el ancho de banda afectado un aparato. Si descubre que la cantidad configurada de ancho de banda está excedida, la prioridad de IP RTP cae los paquetes, un evento que sea tolerado mal por el tráfico de voz. (Debugging del permiso a mirar para esta condición.) El policing cercano permite el tratamiento justo de otros paquetes de datos enviados a la cola en otras colas de administración del tráfico CBWFQ o WFQ. Para evitar la caída de paquetes, esté seguro de afectar un aparato al priority queue la mayoría de la cantidad óptima de ancho de banda, tomando en la consideración el tipo de codificador-decodificador usado y de características de la interfaz. La prioridad de IP RTP no permitirá el tráfico más allá de la cantidad afectada un aparato.

Es siempre el más seguro afectar un aparato al priority queue levemente más que la cantidad necesaria de ancho de banda sabida. Por ejemplo, suponga que usted afectó un aparato 24 anchos de banda del kbps, la cantidad estándar requerida para la transmisión de voz, al priority queue. Esta asignación parece segura porque la transmisión de los paquetes de voz ocurre a una velocidad de bit constante. Sin embargo, porque la red y el router o el Switch pueden utilizar algo del ancho de banda e introducir el jitter y el retardo, afectar un aparato levemente más que la cantidad necesaria de ancho de banda (tal como 25 kbps) asegura la constancia y la Disponibilidad.

La directiva de control de admisión de la prioridad de IP RTP toma en cuenta la Compresión de cabecera RTP. Por lo tanto, mientras que configura el parámetro de ancho de banda ip rtp priority del comando usted necesita solamente configurar para el ancho de banda de la llamada comprimida. Por ejemplo, si una llamada de voz de G.729 requiere 24 anchos de banda no comprimidos del kbps (no incluyendo el payload de la capa 2) solamente el ancho de banda comprimido kbps solamente 12, usted necesita solamente configurar un ancho de banda de 12 kbps. Usted necesita afectar un aparato el suficiente ancho de banda para todas las llamadas si hay más de una llamada.

La suma de toda la asignación de ancho de banda para la Voz y de flujos de datos en la interfaz no puede exceder el 75 por ciento del ancho de banda disponible total. La asignación de ancho de banda para los paquetes de voz tiene en cuenta el payload más el IP, el RTP, y los encabezados UDP, pero otra vez, no la encabezado de la capa 2. Permitir el ancho de banda del 25 por ciento para otros gastos indirectos es conservador y seguro. En un link PPP, por ejemplo, los gastos indirectos para las encabezados de la capa 2 asumen 4 kbps.

Si usted sabe cuánto ancho de banda se requiere para los gastos indirectos adicionales en un link, bajo circunstancias agresivas en las cuales usted quiera dar a tráfico de voz tanto ancho de banda como sea posible, usted puede reemplazar la asignación máxima del 75 por ciento para la suma del ancho de banda afectada un aparato a todas las clases o flujos. Si usted quiere reemplazar la cantidad fija de ancho de banda, ejercite la precaución y asegúrese de que usted permite bastante ancho de banda restante para soportar el tráfico de máximo esfuerzo y de control, y acode 2 de arriba.

Como otra alternativa, si la importancia del tráfico de voz excede lejos el de los datos, usted puede afectar un aparato la mayor parte del ancho de banda del 75 por ciento usado para los flujos y las clases a la cola de prioridad de voz. El ancho de banda sin utilizar en cualquier punta dada será puesto a disposición los otros flujos o clases.

Restricciones

Porque ip rtp priority el comando da la prioridad absoluta sobre el otro tráfico, debe ser utilizado con el cuidado. En caso de congestión, si el tráfico excede el ancho de banda configurado, entonces todo el excedente de tráfico es eliminado.

ip rtp reserve Y ip rtp priority los comandos no puede ser configurado en la misma interfaz.

Prioridad IP RTP de Frame Relay

La característica de la Prioridad de IP RTP en Frame Relay proporciona un esquema de espera de la prioridad estricta en un PVC de Frame Relay para los datos sensibles al retardo tales como Voz. El tráfico de voz se puede identificar por sus números del puerto RTP y clasificar en un priority queue configurado por frame-relay ip rtp priority el comando. El resultado de usar esta característica es que la Voz está mantenida como prioridad estricta preferentemente al otro tráfico nonvoice.

Esta característica amplía las funciones ofrecidas por ip rtp priority el comando soportando los PVC de Frame Relay. Esta característica permite que usted especifique un rango de los puertos UDP cuyo tráfico de voz es servicio de prioridad estricta garantizado sobre cualesquiera otras colas de administración del tráfico o clases usando la misma interfaz de salida. La prioridad estricta significa que si los paquetes existen en el priority queue, dequeued y están enviadas antes de que los paquetes en otras colas de administración del tráfico dequeued. Este proceso se realiza sobre una base por-PVC, bastante que en el nivel de la interfaz.

Para la información sobre cómo configurar la Prioridad de IP RTP en Frame Relay, vea “configurar el módulo de espera cargado de la feria”.

Frame Relay PVC Interface Priority Queueing

La característica del Interfaz de priorización de datos en espera de Frame Relay PVC (PIPQ) proporciona un esquema de espera de la prioridad del interfaz-nivel en el cual el priorización se base en el destino PVC bastante que el contenido de paquetes. Por ejemplo, el frame relay (FR) PIPQ permite que usted configuren un PVC que transporta el tráfico de voz para tener prioridad absoluta sobre un PVC que transporta señalando el tráfico, y un PVC que transporta señalando el tráfico para tener prioridad absoluta sobre un PVC que transporta los datos.

Para la información sobre cómo configurar el Frame Relay PIPQ, vea “configurar el módulo de espera cargado de la feria”. Para la información sobre el Frame Relay, vea “configurando el módulo del Frame Relay”.

El Frame Relay PIPQ proporciona cuatro niveles de prioridad: alto, medio, normal y bajo. El paquete de Frame Relay se examina en la interfaz para el valor del identificador de conexión de link de datos (DLCI). El paquete entonces se envía al priority queue correcto basado en el nivel de prioridad configurado para ese DLCI.


Observeal usar el Frame Relay PIPQ, configure la red para transportar diversos tipos de tráfico en los PVC separados. El Frame Relay PIPQ no se significa para ser utilizado cuando un PVC individual lleva diversos tipos de tráfico que tengan diversos requisitos de QoS.


Usted asigna la prioridad a un PVC dentro de una clase de correspondencia de Frame Relay. Todos los PVC usando o heredando ese map class serán clasificados según la prioridad configurada. Si un PVC no tiene un map class asociado a él, o si el map class asociado a él no tiene prioridad configurada explícitamente, después los paquetes en ese PVC serán hechos cola en el priority queue “normal” predeterminado.

Si usted no habilita el Frame Relay PIPQ en la interfaz usando frame-relay interface-queue priority el comando en el modo de configuración de la interfaz, configurar la prioridad del PVC dentro de un map class no será eficaz. Ahora usted tiene la opción también para fijar los tamaños (en la cantidad máxima de paquete) de las cuatro colas de administración del tráfico de prioridad.

El Frame Relay PIPQ funciona con o sin el Control de tráfico de Frame Relay (FRTS) y el FRF.12 (o más alto). La espera de la prioridad del interfaz-nivel toma el lugar del (Primero en Salir FIFO) que hace cola o del (Primero en Salir FIFO) dual que hace cola utilizado normalmente por el FRTS y el FRF.12 (o más alto). La prioridad del PVC asignada dentro de FR PIPQ toma la precedencia sobre la prioridad FRF.12, así que significa que todos los paquetes destinados para el mismo PVC serán hechos cola en la misma cola de la interfaz si fueron hechos fragmentos o no.


Observeaunque los PVC prioritarios transportará muy probablemente solamente los pequeños paquetes de tráfico de voz, usted puede querer configurar el FRF.12 (o más alto) en estos PVC de todos modos para guardar contra cualquier paquete inesperado grande.


Restricciones

Las restricciones siguientes se aplican al Frame Relay PIPQ:

No se soporta en el loopback o las interfaces del túnel, o las interfaces que rechazan explícitamente la espera de la prioridad.

No se soporta con la compresión por hardware.

No puede ser habilitado en una interfaz que se configure ya con la espera con excepción de la espera (Primero en Salir FIFO). El FR PIPQ puede ser habilitado si se configura el WFQ, mientras el WFQ sea el método de espera de la interfaz predeterminada.

Prerrequisitos

Los requisitos previos siguientes se aplican al Frame Relay PIPQ:

Los PVC se deben configurar para llevar un tipo único de tráfico.

La red se debe configurar con el control de admisión de llamadas adecuado para prevenir el hambre de las colas de administración del tráfico de prioridad unas de los.

Cola de tiempo de latencia bajo

La característica LLQ trae el PQ estricto al CBWFQ. El PQ estricto permite que los datos sensibles al retardo tales como Voz dequeued y que sean enviados antes de que los paquetes en otras colas de administración del tráfico dequeued.

Sin el LLQ, el CBWFQ proporciona el WFQ basado en las clases definidas sin la cola de prioridad estricta disponible para el tráfico en tiempo real. El CBWFQ permite que usted defina las clases de tráfico y después que asigne las características a esa clase. Por ejemplo, usted puede señalar el ancho de banda mínima entregado a la clase durante la congestión.

Para el CBWFQ, la ponderación para un paquete que pertenece a una clase específica se deriva del ancho de banda que usted asignó a la clase cuando usted lo configuró. Por lo tanto, el ancho de banda asignado a los paquetes de una clase determina la orden en la cual se envían los paquetes. Se mantienen todos los paquetes basaron bastante en la ponderación; ninguna clase de paquetes se puede conceder la prioridad estricta. Este esquema plantea los problemas para el tráfico de voz que es en gran parte intolerante del retardo, especialmente variación en el retardo. Para el tráfico de voz, las variaciones en el retardo introducen las irregularidades de la transmisión que manifiestan como jitter en la conversación oída.

El LLQ proporciona la prioridad estricta que hace cola para el CBWFQ, reduciendo el jitter en las conversaciones de la Voz. Configurado por priority el comando, uso de los permisos LLQ de un solo, cola de prioridad estricta dentro del CBWFQ en el nivel de clase, permitiéndole al tráfico directo que pertenece a una clase a la cola de prioridad estricta CBWFQ. Para enviar a la cola el tráfico de la clase a la cola de prioridad estricta, usted especifica la clase Nombrada dentro de una correspondencia de políticas y después configura priority el comando para la clase. (Las clases a las cuales priority el comando son aplicadas se considera las clases de prioridad.) Dentro de una correspondencia de políticas, usted puede dar a uno o más las clases estatus de prioridad. Cuando las clases múltiples dentro de una sola correspondencia de políticas se configuran como clases de prioridad, todo el tráfico de estas clases se envía a la cola lo mismo, solo, cola de prioridad estricta.

Una de las maneras de las cuales el PQ estricto usado dentro del CBWFQ diferencia de su uso fuera del CBWFQ está en los parámetros que toma. Fuera del CBWFQ, usted puede utilizar ip rtp priority el comando de especificar el rango de los puertos UDP cuyos flujos del tráfico de voz deben ser dados el servicio de prioridad. Usando priority el comando, le limitan no más a un número del puerto UDP para estipular los flujos de la prioridad porque usted puede configurar el estatus de prioridad para una clase dentro del CBWFQ. En lugar, todos los criterios de coincidencia válidos usados para especificar el tráfico para una clase ahora se aplican al tráfico de prioridad. Estos métodos de especificar el tráfico para una clase incluyen corresponder con en las Listas de acceso, los protocolos, y las interfaces de entrada. Por otra parte, dentro de una lista de acceso usted puede especificar que las coincidencias del tráfico están prohibidas basadas en el valor del Differentiated Services Code Point IP (DSCP) que se fija usando los primeros seis bits del Byte ToS en el encabezado IP.

Aunque sea posible enviar a la cola los diversos tipos de tráfico en tiempo real a la cola de prioridad estricta, recomendamos fuertemente que usted dirige solamente el tráfico de voz a él porque el tráfico de voz es bueno, mientras que no son otros tipos de tráfico en tiempo real. Por otra parte, el tráfico de voz requiere que el retardo sea nonvariable para evitar el jitter. El tráfico en tiempo real tal como vídeo podía introducir la variación en el retardo, de tal modo frustrando la regularidad del retardo requerida para la transmisión acertada del tráfico de voz.

Para la información sobre cómo configurar el LLQ, vea “configurar el módulo de espera cargado de la feria”.

Asignación del ancho de banda LLQ

Cuando usted especifica priority el comando para una clase, toma bandwidth un argumento que dé el ancho de banda máximo en el kbps. Usted utiliza este parámetro para especificar la cantidad máxima de ancho de banda afectada un aparato para los paquetes que pertenecen a la clase configurada con priority el comando. El parámetro de ancho de banda garantiza el ancho de banda a la clase de prioridad y refrena el flujo de paquetes de la clase de prioridad.

En caso de congestión, la vigilancia se utiliza para caer los paquetes cuando se excede el ancho de banda. El tráfico de voz enviado a la cola al priority queue es basado en UDP y por lo tanto no adaptante a la caída de paquetes temprana característica del WRED. Porque el WRED es ineficaz, usted no puede utilizar el comando random-detect WRED con priority el comando. Además, porque la vigilancia se utiliza para caer los paquetes y un límite de cola no se impone, queue-limit el comando no se puede utilizar con priority el comando.

Cuando ocurre una congestión, se mide el tráfico destinado a la cola de prioridad para asegurarse de que no se exceda la asignación de ancho de banda configurada para la clase a la cual pertenece el tráfico.

La medición de tráfico de prioridad tiene las calidades siguientes:

Está como la función de limitación de velocidad del CAR, salvo que la medición de tráfico de prioridad se realiza solamente bajo condiciones de la congestión. Cuando el dispositivo no está congestionado, se permite que el tráfico de clase de prioridad exceda el ancho de banda asignado. Cuando el dispositivo está congestionado, se descarta el tráfico de clase de prioridad por encima del ancho de banda asignado.

Se realiza por paquete y los tokens se recargan a medida que se envían los paquetes. Si no se dispone de suficientes tokens para enviar el paquete, éste se descarta.

Refrena el tráfico de prioridad a su ancho de banda afectado un aparato para asegurarse de que el tráfico no prioritario, tal como paquetes de ruteo y otros datos, no es hambriento.

Con la medición, se regulan y se limita la velocidad de las clases en forma individual. Es decir, aunque una sola correspondencia de políticas pudiera contener cuatro clases de prioridad, que se envían a la cola en un solo priority queue, cada uno se tratan como flujos separados con las asignaciones de ancho de banda y los apremios separados.

Es importante observar que porque el ancho de banda para la clase de prioridad se especifica como parámetro priority al comando, usted no puede también configurar bandwidth el comando de configuración de clase del directiva-mapa para una clase de prioridad. Para hacer tan es una infracción de la configuración que introduciría solamente la confusión en relación con la cantidad de ancho de banda para afectar un aparato.

El ancho de banda afectado un aparato para un priority queue incluye siempre el encabezado de encapsulado de la capa 2. Sin embargo, no incluye otras encabezados, tales como overheads de los impuestos de célula ATM. Cuando calcula la cantidad de ancho de banda a asignar para una clase de prioridad determinada, debe considerar el hecho de que los encabezados de Capa 2 están incluidos. Cuando se utiliza ATM, debe justificar el hecho de que la sobrecarga del impuesto de célula ATM no está incluida. Usted debe también permitir el ancho de banda para la posibilidad del jitter introducida por el Routers en el trayecto de la voz.

Considere este caso que utilice la atmósfera. Suponga que una secuencia de voz de 60 bytes que emiten 50 paquetes por segundo está codificada usando G.729. Antes de convertir la secuencia de voz a las células, el contador para el priority queue usado para la secuencia de voz evalúa la longitud del paquete después de que se hayan agregado las encabezados del Logical Link Control (LLC) de la capa 2.

Dado 8-byte el encabezado LLC de la capa 2, el contador tendrá en cuenta un paquete 68-byte. Porque las células ATM son un estándar 53 bytes de largo, antes de que el paquete 68-byte se emita en la línea, se divide en dos células ATM 53-byte. Así, el ancho de banda consumido por este flujo es 106 bytes por paquete.

Para este caso, entonces, usted debe configurar el ancho de banda para ser por lo menos 27,2 kbps (68 * 50 * 8 = 27,2 kbps). Sin embargo, recuerde que usted debe también tener en cuenta los gastos indirectos de los impuestos de célula ATM, que no es explicada por el configuré el ancho de banda. Es decir la suma de los anchos de banda para todas las clases debe ser menos que el ancho de banda de la interfaz por por lo menos 15,2 kbps ([106 - 68] * 50 * 8 = 15,2 kbps). Usted debe también recordar permitir el ancho de banda para el jitter router-introducido.

LLQ con la prioridad de IP RTP

El LLQ y la prioridad de IP RTP se pueden configurar al mismo tiempo, pero la prioridad de IP RTP toma la precedencia. Para demostrar cómo trabajan juntos, considere la configuración siguiente:

policy-map llqpolicy
 class voice
 priority 50

ip rtp priority 16384 20000 40
service-policy output llqpolicy

En este ejemplo, los paquetes que hacen juego el rango de puertos 16384 a 20000 serán dados la prioridad con el ancho de banda del kbps 40; los paquetes que hacen juego la clase de la Voz serán dados la prioridad con el ancho de banda del kbps 50. En caso de congestión, de paquetes que hagan juego los 16384 a los 20000 que el rango de puertos recibirá no más de 40 kbps del ancho de banda, y de paquetes que hagan juego la clase de la Voz recibirán no más que 50 kbps del ancho de banda.

Si los paquetes hacen juego ambos criterios (los puertos 16384 a 20000 y clasifican la Voz), la prioridad de IP RTP toma la precedencia. En este ejemplo, los paquetes serán considerados hacer juego el rango de puertos 16384 a 20000 y explicados en el ancho de banda del kbps 40.

LLQ y Committes Bursa Size

Las funciones del LLQ se han ampliado para permitir que usted especifique los tamaños de (Bc) del committed burst en el LLQ. Estas funciones se proporcionan los tamaños de ráfaga que configuran en la característica del low latency queueing. Con esta nueva funcionalidad, la red puede admitir ráfagas de tráfico temporales y manejar el tráfico de la red de manera más eficiente.


Observelos tamaños predeterminados del Bc usados por el LLQ se piensa dirigir Voz-como el tráfico NON-bursty. Si usted quiere configurar el LLQ para manejar el tráfico de las aplicaciones de la NON-Voz, usted puede necesitar aumentar los tamaños de ráfaga por consiguiente, sobre la base de la aplicación funcionando en su red.


LLQ y soporte de la cola de espera por VC para los adaptadores ATM

Por abandono, el mecanismo de espera funcionando determina los tamaños de la cola en espera, y, por lo tanto, el número de paquetes contenidos en la cola. El soporte configurable de la cola de espera por VC para la característica de adaptadores ATM permite que usted amplíe los tamaños predeterminados de la cola en espera y cambiar (o variar) el número de paquetes que la cola puede contener. Con esta nueva función, la cola en espera puede contener un máximo de 1024 paquetes.

Esta característica permite que usted especifique el número de paquetes contenidos en la cola en espera, por el VC, en los adaptadores ATM que soportan la espera por VC.


Observeesta característica se soporta solamente en los Cisco 7200 Series Router, y en los adaptadores de las Cisco y Series que soportan la espera por VC.


Para la información relacionada sobre por VC y las configuraciones de ATM, vea “el módulo de la descripción de la Clase de Servicio IP a ATM” y “configurando el módulo de la Clase de Servicio IP a ATM”.

¿Por qué utilice el LLQ?

Aquí están algunos generales le descomponen en factores deben considerar en determinar si usted necesita configurar el LLQ:

El LLQ proporciona el servicio de prioridad estricta en la atmósfera VCs y interfaces seriales. (La característica de la prioridad de IP RTP permite la prioridad que hace cola solamente en las interfaces.)

El LLQ no se limita a los números del puerto UDP. Porque usted puede configurar el estatus de prioridad para una clase dentro del CBWFQ, le limitan no más a los números del puerto UDP para estipular los flujos de la prioridad. En lugar, todos los criterios de coincidencia válidos usados para especificar el tráfico para una clase ahora se aplican al tráfico de prioridad.

Configurando la cantidad máxima de ancho de banda afectada un aparato para los paquetes que pertenecen a una clase, usted puede evitar el tráfico no prioritario muerto de hambre.

Restricciones

Las restricciones siguientes se aplican al LLQ:

Si usted utiliza las Listas de acceso para configurar los números del puerto que corresponden con, esta característica proporciona la prioridad que corresponde con para todos los números del puerto, impares e incluso. Porque la Voz existe típicamente en los números del puerto uniformes, y los paquetes de control se generan en los números del puerto impares, los paquetes de control también se dan la prioridad al usar esta característica. En mismo los links lentos, el donante de la prioridad a la Voz y a los paquetes de control puede producir la Calidad de voz degradada. Por lo tanto, si usted está asignando solamente la prioridad basada en los números del puerto, usted debe utilizar ip rtp priority el comando en vez priority del comando. ( ip rtp priority El comando proporciona la prioridad solamente para los números del puerto uniformes.)

random-detect El comando, queue-limit el comando, y bandwidth el comando de configuración de clase del directiva-mapa no pueden ser utilizados mientras que priority se configura el comando.

priority El comando se puede configurar en las clases múltiples, pero debe ser utilizado solamente para Voz-como, Velocidad de bits constante (CBR) tráfico.

Low latency queueing distribuido

La característica distribuida LLQ proporciona la capacidad de especificar el comportamiento de la latencia baja para una clase de tráfico en un Cisco 7500 Series Router VIP basado excepto uno con un módulo PA-A3-8T1IMA. El LLQ permite que los datos sensibles al retardo tales como Voz dequeued y que sean enviados antes de que los paquetes en otras colas de administración del tráfico dequeued.

La característica distribuida LLQ también introduce la capacidad de limitar la profundidad de un timbre de la transmisión del dispositivo. Antes de la introducción de LLQ distribuido, la profundidad del timbre de la transmisión máxima no era un parámetro del utilizador configurable. Por lo tanto, las partículas podrían acumular en un timbre de la transmisión sin la limitación, que podría dar lugar a los Latencia altas inevitables. La característica distribuida LLQ permite que los usuarios limiten el número de partículas que puedan existir en un timbre de la transmisión, bajando con eficacia el tiempo de espera contraído por los paquetes que se sientan en ese timbre de la transmisión.

priority Se utiliza el comando de permitir que los datos sensibles al retardo dequeued y que sean enviados primero. Uso de los permisos LLQ de un solo priority queue dentro de las cuales las clases de tráfico individuales pueden ser puestas. Para enviar a la cola el tráfico de la clase al priority queue, usted configura priority el comando para la clase después de que usted especifique la clase Nombrada dentro de una correspondencia de políticas. La cantidad de ancho de banda disponible para el priority queue se puede especificar como una determinada cantidad de ancho de banda en el kbps o como porcentaje de todo el ancho de banda disponible (principio en el Cisco IOS Release 12.1(5)T).

Dentro de una correspondencia de políticas, usted puede dar a uno o más las clases estatus de prioridad. Cuando las clases múltiples dentro de una sola correspondencia de políticas se configuran como clases de prioridad, todo el tráfico de estas clases se envía a la cola lo mismo, solo, priority queue.

tx-ring-limit El comando permite que el usuario especifique el número de partículas permisibles en un timbre de la transmisión, bajando con eficacia el tiempo de espera para ese timbre de la transmisión. Un paquete puede contener las partículas múltiples, y una partícula típica es 512 bytes de tamaño (los tamaños dependen de los tipos de interfaz. Para algunos tipos de interfaz, los tamaños de partícula típicos son los bytes 256.) Estas partículas pueden acumular no más en un timbre de la transmisión y causar los Latencia altas inevitables.

El LLQ distribuido se soporta en el Series Router del Cisco 7500 RSP con un VIP a menos que cuando se configura un módulo PA-A3-8T1IMA.

Esta característica también soporta Class-Based Quality of Service el MIB.

Para la información sobre cómo configurar el LLQ distribuido, vea “configurar el módulo de espera cargado de la feria”.

Garantizar el ancho de banda con el comando priority

Un método de usar priority el comando para una clase de tráfico es especificar bandwidth un argumento que dé el ancho de banda máximo en el kpbs. El otro método de usar priority el comando para una clase de tráfico, que fue introducida en el Cisco IOS Release 12.1(5)T, es especificar un porcentaje del ancho de banda disponible que se reservará para el priority queue. bandwidth El valor o el porcentaje garantiza el configuré el ancho de banda a la clase de prioridad bajo escenarios de congestión a lo peor. Si el ancho de banda en exceso está disponible, la clase de prioridad será permitida utilizar el ancho de banda. Si no hay ancho de banda en exceso disponible, el tráfico de prioridad será obligado a la velocidad configurada vía las caídas de paquetes. Cada clase individual que se configura a un valor de ancho de banda tendrá su tráfico obligado a su tarifa individual. Cuando una clase se obliga a su tarifa individual, el tráfico se permite una determinada cantidad de burstiness debido al mecanismo del token bucket que limpia la secuencia. Esta cantidad de burstiness es controlada por el parámetro de ráfaga opcional en priority el comando (este burstiness no puede ser especificado al especificar un priority queue basado en un porcentaje del ancho de banda disponible). El parámetro de ráfaga especifica, en los bytes, la cantidad de tráfico permitida pasar a través del token bucket como explosión de una sola vez superior a los parámetros del descenso del token bucket. El valor de ráfaga predeterminado es 200 milisegundos de tráfico en los parámetros configurados del descenso del token bucket.

Es importante observar que porque el ancho de banda para la clase de prioridad se especifica como parámetro priority al comando, usted no puede también configurar bandwidth el comando para una clase de prioridad. Para hacer tan es una infracción de la configuración que introduce la confusión en relación con la cantidad de ancho de banda para afectar un aparato.

El ancho de banda afectado un aparato para un priority queue incluye siempre el encabezado de encapsulado de la capa 2. Sin embargo, no incluye otras encabezados, tales como overheads de los impuestos de célula ATM. Cuando usted calcula la cantidad de ancho de banda para afectar un aparato para una determinada clase de prioridad, usted debe explicar el hecho de que las encabezados de la capa 2 son incluidas. Cuando se utiliza ATM, debe justificar el hecho de que la sobrecarga del impuesto de célula ATM no está incluida. Usted debe también permitir el ancho de banda para la posibilidad del jitter introducida por el Routers en el trayecto de la voz.

Considere este caso que utilice la atmósfera: Suponga que una secuencia de voz de 60 bytes que emiten 50 paquetes por segundo está codificada usando G.729. Antes de convertir la secuencia de voz a las células, el contador para el priority queue usado para la secuencia de voz evalúa la longitud del paquete después de que se hayan agregado las encabezados del Logical Link Control (LLC) de la capa.

Dado 8-byte el encabezado LLC de la capa 2, el contador tendrá en cuenta un paquete 68-byte. Porque las células ATM son un estándar 53 bytes de largo, antes de que el paquete 68-kbps se emita en la línea, se divide en dos células ATM 53-byte. Así, el ancho de banda consumido por este flujo es 106 bytes por paquete.

Para este caso, entonces, usted debe configurar el ancho de banda para ser por lo menos 27,2 kbps (68 * 50 * 8 = 27,2 kbps). Sin embargo, recuerde que usted debe también tener en cuenta los gastos indirectos de los impuestos de célula ATM, que no es explicada por el configuré el ancho de banda. Es decir la suma de los anchos de banda para todas las clases debe ser menos que el ancho de banda de la interfaz por por lo menos 15,2 kbps ([106 - 68] * 50 * 8 = 15,2 kbps). Usted debe también recordar permitir el ancho de banda para el jitter router-introducido.

Beneficios

Provee prioridad mantenga en la atmósfera VCs y interfaz serial

El esquema PQ permite que los datos sensibles al retardo tales como Voz dequeued y que sean enviados antes de que los paquetes en otras colas de administración del tráfico dequeued. Esta característica proporciona el PQ en la atmósfera VCs.

Control de admisión

Configurando la cantidad máxima de ancho de banda afectada un aparato para los paquetes que pertenecen a una clase, usted puede evitar el tráfico no prioritario muerto de hambre.

Limitación de las partículas en un timbre de la transmisión

La característica distribuida LLQ también introduce la partícula que limita para los timbres de la transmisión. Antes de la introducción de LLQ distribuido, la profundidad del timbre de la transmisión no era utilizador configurable. Por lo tanto, un usuario podría experimentar los Latencia altas inevitables en un timbre de la transmisión.

La característica distribuida LLQ permite que los usuarios limiten el número de partículas en un timbre de la transmisión a un límite predefinido, bajando con eficacia el tiempo de espera en los timbres de la transmisión.

Restricciones

Las restricciones siguientes se aplican a la característica distribuida LLQ:

Si usted utiliza las Listas de acceso para configurar los números del puerto que corresponden con, esta característica proporciona la prioridad que corresponde con para todos los números del puerto. Porque la Voz existe típicamente en los números del puerto uniformes, y los paquetes de control se generan en los números del puerto impares, los paquetes de control también se dan la prioridad al usar esta característica. En mismo los links lentos, el donante de la prioridad a la Voz y a los paquetes de control puede producir la Calidad de voz degradada.

priority El comando se puede utilizar conjuntamente con set el comando. priority El comando no se puede utilizar conjuntamente con ningún otro comando, incluyendo random-detect queue-limit, y bandwidth los comandos.

priority El comando se puede configurar en las clases de tráfico múltiple. Si el tráfico no es tráfico CBR, usted debe configurar bastante grande un parámetro del ancho de banda-Kbps para absorber las ráfagas de datos.

Porque el 1 por ciento del ancho de banda disponible es reservado para la clase del tráfico predeterminado, la suma del porcentaje para bandwidth percent y priority percent las reservas del comando no puede exceder el 99 por ciento.

Las colas de administración del tráfico de prioridad se pueden reservar por los valores de los tamaños o del porcentaje, pero no ambos, en la misma correspondencia de políticas. Por lo tanto, si priority el comando se utiliza sin percent la opción en una correspondencia de políticas, bandwidth el comando, si está utilizado, se debe también utilizar sin percent la opción, y vice versa. Semejantemente, si priority percent el comando se utiliza en una correspondencia de políticas, bandwidth percent el comando se debe utilizar para especificar la asignación de ancho de banda para la clase, y vice versa. priority Y priority percent los comandos también no puede ser utilizado en la misma correspondencia de políticas.

bandwidth Y priority los comandos no puede ser utilizado en la misma correspondencia de la clase. Estos comandos se pueden utilizar juntos en la misma correspondencia de políticas, sin embargo.

Los siguientes comandos no se pueden utilizar en la misma clase o la correspondencia de políticas con priority el comando:

priority percent -

bandwidth percent -

Los siguientes comandos no se pueden utilizar en la misma clase o la correspondencia de políticas con priority percentage el comando:

priority – (sin percent la opción)

bandwidth – (sin percent la opción)

tx-ring-limit El comando puede afectar solamente a un VC VBR en un adaptador de puerto PA-A3. tx-ring-limit El comando no afecta a UBR VCs.

El DLLQ no se soporta en los Cisco 7500 Series Router con los módulos PA-A3-8T1IMA.

Prerrequisitos

Para utilizar esta característica, usted debe ser familiar con las características siguientes:

ACL

ATM PVC

Administración del ancho de banda

CBWFQ

LFI

Plantillas virtuales e interfaces de acceso virtual

Cola de tiempo de latencia bajo para Frame Relay

El LLQ para el Frame Relay proporciona una cola de prioridad estricta para el tráfico de voz y las colas justas cargadas para otras clases de tráfico. Con esta característica, el LLQ está disponible en el VC de Frame Relay llano cuando se configura el FRTS.

El LLQ, también llamado PQ/CBWFQ, es un superconjunto y más flexible que de las ofrendas anteriores de QoS del Frame Relay, particularmente priorización RTP y PQ/WFQ.

Con el priorización RTP y el PQ/WFQ, el tráfico que hace juego un rango de puertos especificado UDP/RTP se considera prioritario y se afecta un aparato al priority queue (PQ). Con el LLQ para el Frame Relay, usted configura las clases de tráfico según el protocolo, interconecta, o las Listas de acceso, y después define las correspondencias de políticas para establecer cómo las clases se manejan en el priority queue y las colas justas cargadas.

Las colas de administración del tráfico se configuran sobre una base por-PVC: cada PVC tiene un PQ y un assigned number de las colas justas. Las colas justas son pesos asociados proporcionales a los requerimientos de ancho de banda de cada clase; una clase que requiere dos veces el ancho de banda de otro tendrá mitad de la ponderación. El oversubscription del ancho de banda no se permite. El CLI rechazará un cambio de la configuración que haría el ancho de banda total ser excedido. Estas funciones diferencian de la del WFQ, en el cual los flujos se asignan una ponderación basada en la Prioridad IP. El WFQ permite que el tráfico de la precedencia más alta obtenga proporcionalmente más del ancho de banda, pero cuanto más flujos hay, menos el ancho de banda es disponibles para cada flujo.

La PQ es controlada para garantizar que las colas justas no se saturen de ancho de banda. Cuando configura PQ, especifica en kbps la cantidad máxima de ancho de banda disponible para esa cola. Se eliminan los paquetes que exceden ese máximo. No hay policing de las colas justas.

El LLQ para el Frame Relay se configura usando una combinación de class-map policy-map, y los comandos de la clase de correspondencia de Frame Relay. class-map El comando define las clases de tráfico según el protocolo, la interfaz, o la lista de acceso. policy-map El comando define cómo cada clase se trata en el sistema de espera según el ancho de banda, la prioridad, el límite de cola, o el WRED. service-policy output El comando de asignación de clases asocia una correspondencia de políticas a un VC de Frame Relay.

Las directivas relacionadas no no directamente con el LLQ — por ejemplo, modelado de tráfico, fijando la Prioridad IP, y limpiándola — no son soportadas por class-map y policy-map los comandos para el Frame Relay VCs. Usted debe utilizar otros mecanismos de configuración, tales como comandos de asignación de clases, de configurar estas directivas.

Para la información sobre cómo configurar el LLQ para el Frame Relay, vea “configurar el módulo de espera cargado de la feria”.

Restricciones

Se soportan los comandos siguientes solamente de la clase de la correspondencia y de la correspondencia de políticas:

match El comando de configuración class-map

priority bandwidth queue-limit random-detect, Y fair-queue comandos de configuración de correspondencia de políticas

Prerrequisitos

Las tareas siguientes deben ser completadas antes de que el LLQ para el Frame Relay pueda ser habilitado:

El FRTS se debe habilitar en la interfaz.

Una política de servicio de resultados se debe configurar en el map class asociado a la interfaz, a la subinterfaz, o al DLCI.

Cualquier cola con excepción de una cola primero en entrar, primero en salir que se configure en el map class debe ser quitada. El LLQ para el Frame Relay no se puede configurar si hay ya una cola NON-(Primero en Salir FIFO) configurada, a excepción de la cola predeterminada se crea que cuando se habilita la fragmentación.

Cómo funciona

El LLQ para el Frame Relay se utiliza conjuntamente con las características descritas en las secciones siguientes:

Priorización RTP

Voz sobre el Frame Relay

Fragmentación de Frame Relay

Cisco Express Forwarding Switching IP

Priorización RTP

El priorización RTP proporciona un esquema estricto PQ para el tráfico de voz. El tráfico de voz es identificado por sus números del puerto RTP y clasificado en un priority queue configurado por frame-relay ip rtp priority el comando de configuración de la clase correspondiente. Usted clasifica el tráfico como Voz especificando un rango del número del puerto RTP. Si el tráfico hace juego el rango especificado, se clasifica como la Voz y se hace cola en el LLQ PQ, y la cola de prioridad de interfaz. Si el tráfico no baja dentro del rango de puertos especificado RTP, es clasificado por la política de servicio del esquema LLQ.

ip rtp priority El comando está disponible en el modo de configuración de la interfaz y el modo de configuración de la clase de asociador. Solamente frame relay ip rtp priority el comando de configuración de la clase correspondiente se soporta en esta característica.

Voz sobre el Frame Relay

El voz sobre Frame Relay (VoFR) utiliza el priority queue (PQ) LLQ bastante que su propio mecanismo PQ. frame-relay voice bandwidth El comando de configuración de la clase correspondiente configura el ancho de banda total disponible para el tráfico de VoFR. El ancho de banda visible puesto a disposición las otras colas de administración del tráfico será la velocidad de información comprometida mínima (CIR) menos el ancho de banda de voz.

frame-relay voice bandwidth El comando de configuración de la clase correspondiente también configura una función de control de admisión de llamadas, que se asegura de que siga habiendo el suficiente ancho de banda de VoFR antes de permitir una llamada. No hay policing del tráfico de voz una vez que se ha establecido la llamada.

Para VoFR sin los datos, todos los paquetes de la Voz y de Control de llamadas se hacen cola en el Asignación de colas de prioridad (PQ) LLQ. Para VoFR con los datos, un VoFR PVC puede llevar ambos paquetes de voz y datos en diversos subcanales. Los paquetes de datos de VoFR se hacen fragmentos y se interpolan con los paquetes de voz para asegurar los buenos límites del tiempo de espera para los paquetes de voz y el scalability para el tráfico de voz y de datos.

Observe que cuando se habilita VoFR, no hay necesidad de configurar una correspondencia de la clase de prioridad para la Voz. Los únicos comandos vofr de ser utilizado con el LLQ para el Frame Relay son frame-relay voice bandwidth el comando de configuración de la clase correspondiente y vofr data el comando configuration del DLCI de Frame Relay.


Notaes posible — no recomendado sin embargo — configurar el otro tráfico para el PQ al mismo tiempo que VoFR. El hacer tan podría causar los retardos porque la interpolación de los paquetes NON-VoFR en el PQ no sería posible, hacer el PQ (y cualquier paquetes de VoFR en él) ser soportado durante la fragmentación hasta que se haya enviado el paquete fragmentado entero.


Fragmentación de Frame Relay

El propósito del Frame Relay Fragmentation (FRF.12) es soportar los paquetes de voz y datos en links más de poca velocidad sin causar el Retraso excesivo a los paquetes de voz. Los paquetes de datos grandes se hacen fragmentos y se interpolan con los paquetes de voz.

Cuando el FRF.12 se configura con el LLQ, los pequeños paquetes clasificados para el PQ pasan con unfragmented sobre el LLQ PQ y la cola de la interfaz prioritaria. Los paquetes grandes destinados para el PQ se forman y se hacen fragmentos cuando están dequeued.

Utilice frame-relay fragment y service-policy los comandos de configuración de la clase correspondiente habilitar el LLQ con el FRF.12.

Cisco Express Forwarding Switching IP

El CEF Switching IP no es afectado por las funciones LLQ.

Almacenamiento en cola personalizado

El CQ permite usted especifique algunos bytes para remitir de una cola cada vez que se mantiene la cola, de tal modo permitiendo que usted comparta a los recursos de red entre las aplicaciones con el ancho de banda mínima o los requisitos de latencia específicos. Usted puede también especificar una cantidad máxima de paquete en cada cola.

Para la información sobre cómo configurar el CQ, vea “configurando el módulo del Custom Queueing”.

Cómo funciona

Las manijas CQ trafican especificando el número de paquetes o de bytes que se mantendrán para cada clase de tráfico. Mantiene las colas de administración del tráfico completando un ciclo a través de ellas en la forma de cargas balanceadas, enviando la porción de ancho de banda afectado un aparato para cada cola antes de mover a la cola siguiente. Si una cola está vacía, el router enviará los paquetes de la cola siguiente que tiene paquetes listos para enviar.

Cuando el CQ se habilita en una interfaz, el sistema mantiene 17 colas de salida para esa interfaz. Usted puede especificar las colas de administración del tráfico 1 a 16. Se asocia a cada cola de salida una cuenta de bytes configurable, que especifica cuántos bytes de dato debe entregar el sistema de la cola actual antes de que se mueva encendido a la cola siguiente.

La cola número 0 es una cola del sistema; se vacia antes de las colas de administración del tráfico unas de los numeradas 1 a 16 se procesa. Los paquetes con prioridad altas de las colas del sistema, tales como paquetes de keepalive y paquetes de la señalización, a esta cola. El otro tráfico no se puede configurar para utilizar esta cola.

Para la cola numera 1 a 16, los ciclos del sistema a través de las colas de administración del tráfico secuencialmente (en una forma de cargas balanceadas), dequeueing la cuenta de bytes configurada de cada cola en cada ciclo, entregando los paquetes en la cola actual antes de mover encendido la siguiente. Cuando se está procesando una cola particular, se envían los paquetes hasta que la cantidad de bytes enviada exceda la cuenta de bytes de la cola o la cola está vacía. El ancho de banda usado por una cola particular se puede especificar indirectamente solamente en términos de cuenta de bytes y largo de la cola.

Cuadro 2 demostraciones cómo el CQ se comporta.

Cuadro 2 Custom Queueing

El CQ se asegura de que ninguna aplicación o grupo especificado de aplicaciones alcance más que una proporción predeterminada de capacidad total cuando la línea está bajo tensión. Como el PQ, el CQ se configura estáticamente y no se adapta automáticamente al estado de la red cambiante.

En la mayoría de las Plataformas, todos los protocolos se clasifican en el trayecto de Switching rápido.

Determinar los valores de cuenta de bytes para las colas

Para afectar un aparato el ancho de banda a diversas colas de administración del tráfico, usted debe especificar la cuenta de bytes para cada cola.

Cómo se utiliza la cuenta de bytes

El router envía los paquetes de una cola particular hasta que se exceda la cuenta de bytes. Una vez que se excede el valor de cuenta de bytes, el paquete que se está enviando actualmente será enviado totalmente. Por lo tanto, si usted fija la cuenta de bytes a 100 bytes y los tamaños de paquetes de su protocolo son 1024 bytes, después cada vez que se mantiene esta cola, 1024 bytes serán enviados, no 100 bytes.

Por ejemplo, suponga que un protocolo tiene paquetes del 500-byte, otro tiene paquetes del 300-byte, y un tercero tiene paquetes del 100-byte. Si usted quiere partir el ancho de banda uniformemente a través de los tres protocolos, usted puede ser que elija especificar las cuentas de bytes de 200, 200, y 200 para cada cola. Sin embargo, esta configuración no da lugar a una relación de transformación de 33/33/33. Cuando los servicios del router la primera cola, él envían un solo paquete del 500-byte; cuando mantiene la segunda cola, envía un paquete del 300-byte; y cuando mantiene la tercera cola, envía dos paquetes del 100-byte. La relación de transformación eficaz es 50/30/20.

Así, fijando la poder demasiado baja de la cuenta de bytes dé lugar a una asignación de ancho de banda involuntaria.

Sin embargo, las cuentas de bytes muy grandes producirán una distribución “desigual”. Es decir, si usted asigna 10 KB, 10 KB, y 10 KB a tres colas de administración del tráfico en el ejemplo dado, cada protocolo se mantiene puntualmente cuando su cola es la que es mantenida, pero puede ser un tiempo prolongado antes de que la cola se mantenga otra vez. Una mejor solución es especificar el 500-byte, el 600-byte, y las cuentas del 500-byte para la cola. Esta configuración resulta en un coeficiente de 31/38/31, que puede ser aceptable.

Para las colas de servicios a tiempo y se aseguran de que la asignación del configuré el ancho de banda esté tan cerca como sea posible a la asignación del ancho de banda necesario, usted deben determinar la cuenta de bytes basada en los tamaños de paquetes de cada protocolo, si no sus porcentajes pueden no corresponder con lo que usted configura.


El CQde la nota fue modificado en el Cisco IOS Release 12.1. Cuando la cola se agota temprano, o el paquete más reciente de la cola no hace juego exactamente la cuenta de bytes configurada, la cantidad de déficit se recuerda y se explica la próxima vez que se mantiene la cola. Empezando por el Cisco IOS Release 12.1, usted no necesita ser tan exacto en especificar las cuentas de bytes como usted hizo al usar versiones anteriores del Cisco IOS que no tomaron en cuenta el déficit.



Observealgunos protocolos, tales como Intercambio de paquetes entre redes (IPX), negociará los tamaños de trama en el tiempo de iniciación de sesión.


Determinar la cuenta de bytes

Para determinar las cuentas de bytes correctas, realice los pasos siguientes:


Paso 1Para cada cola, divida el porcentaje de ancho de banda que usted quiere afectar un aparato a la cola por los tamaños de paquetes, en los bytes. Por ejemplo, asuma que los tamaños de paquetes para el protocolo A son 1086 bytes, el protocolo B es 291 bytes, y el C del protocolo es 831 bytes. Queremos afectar un aparato el 20 por ciento para A, el 60 por ciento para B, y el 20 por ciento para el C. Las relaciones de transformación serían:

20/1086, 60/291, 20/831 o

0,01842, 0,20619, 0,02407

Paso 2Normalice los números dividiendo por el número más bajo:

1, 11,2, 1,3

El resultado es la relación de transformación del número de paquetes que deban ser enviados de modo que el porcentaje de ancho de banda que cada protocolo utiliza sea el aproximadamente 20, 60, y 20 por ciento.

Paso 3Una fracción en los valores uces de los de la relación de transformación significa que un paquete adicional será enviado. Reúna los números al número entero siguiente para obtener la cuenta del paquete real.

En este ejemplo, la relación de transformación real será 1 paquete, 12 paquetes, y 2 paquetes.

Paso 4Convierta la relación de transformación del número del paquete en las cuentas de bytes multiplicando cada cuenta de paquetes por los tamaños de paquetes correspondientes.

En este ejemplo, el número de paquetes enviados está un paquete 1086-byte, doce paquetes del 291-byte, y dos paquetes del 831-byte, o a 1086, 3492, y 1662 bytes, respectivamente, de cada cola. Éstas son las cuentas de bytes que usted especificaría en su configuración CQ.

Paso 5Para determinar la distribución de ancho de banda que esta relación de transformación representa, primero determine el número total de bytes enviados después de que se mantengan las tres colas:

(1 * 1086) + (12 * 291) + (2 * 831) = 1086 + 3492 + 1662 = 6240

Paso 6Entonces determine el porcentaje del número total de bytes enviados de cada cola:

el 1086/6240, 3492/6240, 1662/6240 = 17,4, 56, y 26,6 por ciento

Este resultado está cercano a la relación de transformación deseada de 20/60/20.

Paso 7Si el ancho de banda real no está bastante cercano al ancho de banda deseado, multiplique la relación de transformación original de 1:11.2:1.3 por el mejor valor, intentando conseguir tan cerca a tres valores del número entero como posible. Observe que el multiplicador que usted utiliza no necesita ser un número entero. Por ejemplo, si multiplicamos la relación de transformación por dos, conseguimos 2:22.4:2.6. Ahora enviaríamos dos paquetes 1086-byte, veintitrés paquetes del 291-byte, y tres paquetes del 831-byte, o 2172/6693/2493, para un total de 11.358 bytes. La relación de transformación resultante es el 19/59/22 por ciento, que es mucho más cercano a la relación de transformación deseada que alcanzamos.


El ancho de banda que una cola de encargo recibirá es dado por la fórmula siguiente:

(queue byte count / total byte count of all queues) * bandwidth capacity of the interface

donde está igual la capacidad de ancho de banda al ancho de banda de la interfaz menos el ancho de banda para las colas de administración del tráfico de prioridad.

Tamaños de la ventana

Los tamaños de la ventana también afectan a la distribución de ancho de banda. Si los tamaños de la ventana de un protocolo particular se fijan a uno, después ese protocolo no colocará otro paquete en la cola hasta que reciba un acuse de recibo. El algoritmo CQ se mueve a la cola siguiente si se excede la cuenta de bytes o no hay paquetes en esa cola.

Por lo tanto, con los tamaños de la ventana de uno, solamente una trama será enviada cada vez. Si su Conteo de tramas se fija a 2 kilobytes, y sus tamaños de trama son los bytes 256, después solamente los bytes 256 serán enviados cada vez que se mantiene esta cola.

¿Por qué utilice el CQ?

Usted puede utilizar la característica CQ de QoS del Cisco IOS para proporcionar el ancho de banda garantizado específico del tráfico en una punta de la congestión potencial, asegurando el tráfico un de porción fija del ancho de banda disponible y dejando el ancho de banda restante al otro tráfico. Por ejemplo, usted podría reservar la mitad del ancho de banda para los datos SNA, permitiendo que la otra mitad sea utilizada por otros protocolos.

Si un tipo determinado de tráfico no está utilizando el ancho de banda reservado para él, después el ancho de banda sin utilizar se puede afectar un aparato dinámicamente a otros tipos de tráfico.

Restricciones

El CQ se configura y no se adapta estáticamente al estado de la red cambiante. Con el CQ habilitado, el sistema dura para conmutar los paquetes que el (Primero en Salir FIFO) porque los paquetes son clasificados por la placa del procesador.

Espera de la prioridad

El PQ permite que usted defina cómo el tráfico se da prioridad en la red. Usted configura cuatro prioridades de tráfico. Usted puede definir una serie de filtros basados en las características del paquete para hacer al router poner el tráfico en estas cuatro colas de administración del tráfico; la cola con la prioridad más alta se mantiene primero hasta que esté vacía, después las colas más bajas se mantienen en orden.

Para la información sobre cómo configurar el PQ, vea “configurar el módulo de espera de la prioridad”.

Cómo funciona

Durante la transmisión, el PQ da a colas de administración del tráfico de prioridad el trato preferencial absoluto sobre las colas de baja prioridad; el tráfico importante, dado la prioridad más alta, toma siempre la precedencia sobre menos tráfico importante. Los paquetes se clasifican sobre la base de los criterios definidos por el usuario y se colocan en una de las cuatro colas de salida — alto, media, normal, y punto bajo — basadas en la prioridad asignada. Paquetes que no se clasifican por la caída de la prioridad en la cola normal. El cuadro 3 ilustra este proceso.

Cuadro 3 espera de la prioridad

Cuando un paquete debe ser enviado una interfaz, las colas de administración del tráfico de prioridad en esa interfaz se analizan para los paquetes en el orden de prioridad descendente. La cola de alta prioridad se analiza primero, entonces la cola de Prioridad media, y así sucesivamente. El paquete en el jefe de la cola más alta se elige para la transmisión. Este procedimiento se repite cada vez que se está por enviar un paquete.

El Largo máximo de una cola es definido por el límite de la longitud. Cuando una cola es más larga que el límite de cola, se caen todos los paquetes adicionales.


Observeel mecanismo de espera de la prioridad de resultado puede ser utilizado para manejar el tráfico de todos los protocolos de establecimiento de una red. El ajuste fino adicional está disponible para el IP y para fijar los límites en los tamaños de paquetes.


Cómo los paquetes se clasifican para la espera de la prioridad

Una lista de prioridad es un conjunto de reglas que describe cómo los paquetes se deben asignar a las colas de administración del tráfico de prioridad. Una lista de prioridad pudo también describir una prioridad predeterminada o los límites de los tamaños de la cola de las diversas colas de administración del tráfico de prioridad.

Los paquetes se pueden clasificar por los criterios siguientes:

Protocolo o tipo del subprotocol

Interfaz entrante

Tamaños de paquetes

Fragmentos

Lista de acceso

El Keepalives originado por el servidor de red se asigna siempre a la cola de alta prioridad; el resto del tráfico de administración (tal como actualizaciones del Interior Gateway Routing Protocol (IGRP)) debe ser configurado. Los paquetes que no son clasificados por el mecanismo de la lista de prioridad se asignan a la cola normal.

¿Por qué utilice la espera de la prioridad?

El PQ proporciona el trato preferencial absoluto al tráfico de prioridad alta, asegurándose de que el tráfico crítico que atraviesa los diversos links PÁLIDOS consigue el tratamiento de prioridad. Además, el PQ proporciona un tiempo de respuesta más rápido que otros métodos de espera.

Aunque usted pueda habilitar la prioridad de resultado que hace cola para cualquier interfaz, se utiliza mejor para el ancho de banda baja, las interfaces seriales congestionadas.

Restricciones

Al elegir utilizar el PQ, considere que porque el tráfico de prioridad más baja se niega a menudo el ancho de banda a favor de un tráfico más prioritario, podría el uso del PQ, en el peor de los casos, da lugar al tráfico de prioridad más baja nunca que era enviado. Para evitar infligir estas condiciones en el tráfico de prioridad más baja, usted puede utilizar el modelado de tráfico o el tarifa-límite CAR el tráfico más prioritario.

El PQ introduce los gastos indirectos adicionales que son aceptables para las interfaces lentas, pero puede no ser aceptable para interfaces más altas de la velocidad tales como Ethernetes. Con el PQ habilitado, el sistema dura para conmutar los paquetes porque los paquetes son clasificados por la placa del procesador.

El PQ utiliza una configuración estática y no se adapta al estado de la red cambiante.

El PQ no se soporta en ninguna túneles.

Administración del ancho de banda

RSVP, el CBWFQ, el LLQ, la prioridad de IP RTP, la Prioridad de IP RTP en Frame Relay, y el Frame Relay PIPQ pueden toda la reserva y consumir el ancho de banda, hasta un máximo del ancho de banda reservado en una interfaz.

Para afectar un aparato el ancho de banda, usted puede utilizar uno de los siguientes comandos:

Para RSVP, utilice ip rsvp bandwidth el comando.

Para el CBWFQ, utilice bandwidth el comando de configuración de clase del directiva-mapa. Para más información sobre la asignación de ancho de banda CBWFQ, vea la sección “Class-Based Weighted Fair Queueing” en este módulo. Para el LLQ, usted puede afectar un aparato el ancho de banda usando priority el comando. Para más información sobre la asignación del ancho de banda LLQ, vea la sección “Interfaz de priorización de datos en espera de Frame Relay PVC” en este módulo.

Para la prioridad de IP RTP, utilice ip rtp priority el comando. Para más información sobre la asignación de ancho de banda de la prioridad de IP RTP, vea la sección “prioridad de IP RTP” en este módulo.

Para la Prioridad de IP RTP en Frame Relay, utilice frame-relay ip rtp priority el comando. Para más información sobre la Prioridad de IP RTP en Frame Relay, vea la sección “Prioridad de IP RTP en Frame Relay” en este módulo.

Para el Interfaz de priorización de datos en espera de Frame Relay PVC, utilice frame-relay interface-queue priority el comando. Para más información sobre el Frame Relay PIPQ, vea la sección “Interfaz de priorización de datos en espera de Frame Relay PVC” en este módulo.

Cuando usted configura estos comandos, sea consciente de las limitaciones de ancho de banda y del ancho de banda de la configuración según los requisitos en su red. Recuerde, la suma de todos los anchos de banda no puede exceder el ancho de banda reservado máximo. El máximo predeterminado del ancho de banda es el 75 por ciento del ancho de banda disponible total en la interfaz. Que sigue habiendo el 25 por ciento del ancho de banda se utiliza para los gastos indirectos, incluyendo la capa 2 de arriba, ruteando el tráfico, y tráfico Best-Effort (mejor esfuerzo).