Guía de Configuración de Soluciones de Calidad de Servicio de Cisco IOS, versión 12.2SR
Descripción general de la regulación y diseño de tráfico
21 Agosto 2013 - Traducción Automática | Otras Versiones: PDFpdf 172 KB | Inglés (17 Marzo 2008) | Comentarios

Contenidos

Descripción general de la regulación y diseño de tráfico

¿Cuál es un token bucket?

Policing con el CAR

Cómo el CAR trabaja

Criterios correspondientes

Límites de velocidad

Acciones de conformidad y excedente

Directivas múltiples de la tarifa

Restricciones del CAR y del CAR VIP-distribuido

Regulación del tráfico

Ventajas de la Vigilancia de tráfico

Restricciones para la Vigilancia de tráfico

Requisitos previos para la Vigilancia de tráfico

Modelado de tráfico (flujo de paquetes de regulación)


Descripción general de la regulación y diseño de tráfico


El Cisco IOS QoS ofrece dos clases de mecanismos de regulación del tráfico — establecimiento de políticas y modelado.

Las funciones de limitación de velocidad del Committed Access Rate (CAR) y la característica de regulación del tráfico proporcionan las funciones para limpiar el tráfico. Las características del Control de tráfico genérico (GTS), del Control de tráfico basado en clases, del Control de tráfico distribuido (dTS), y del Control de tráfico de Frame Relay (FRTS) proporcionan las funciones para formar el tráfico.

Utilice el Cisco Feature Navigator para encontrar la información sobre el soporte del Soporte de la plataforma y de la imagen del software de Cisco. Para acceder a Cisco Feature Navigator, vaya a http://www.cisco.com/go/cfn. Una cuenta en el cisco.com no se requiere.

Usted puede desplegar estas características en su red para asegurarse de que un paquete, o la fuente de datos, se adhiere a un contrato estipulado y para determinar el QoS para rendir el paquete. Ambos mecanismos del establecimiento de políticas y modelado utilizan al descriptor del tráfico para un paquete — indicado por la clasificación del paquete — para asegurar la adherencia y el servicio.

El policers y las talladoras identifican generalmente las infracciones del descriptor del tráfico de una manera idéntica. Diferencian generalmente, sin embargo, de la manera que responden a las infracciones, por ejemplo:

Un policer cae típicamente el tráfico. (Por ejemplo, el policer de la limitación de la tarifa CAR cualquier descenso el paquete o reescribir su Prioridad IP, reajustando los bits del tipo de servicio en el encabezado de paquete.)

Un shaper retrasa típicamente el tráfico en exceso usando un buffer, o el mecanismo de espera, para sostener los paquetes y para formar el flujo cuando la velocidad de datos de la fuente es más alta que esperada. (Por ejemplo, el GTS y la modelación basada en la clase utilizan una cola justa cargada para retrasar los paquetes para formar el flujo, y el uso del DTS y FRTS un priority queue, una cola de encargo, o una cola primero en entrar, primero en salir para lo mismo, dependiendo de cómo usted la configura.)

El modelado de tráfico y el policing pueden trabajar en el tándem. Por ejemplo, un buen esquema del modelado de tráfico debe hacerlo fácil para los Nodos dentro de la red detectar los flujos que se comportan mal. Esta actividad se llama a veces vigilancia del tráfico del flujo.

Este módulo da una Breve descripción de la Vigilancia de tráfico y de los mecanismos de modelado de QoS del Cisco IOS. Porque el establecimiento de políticas y modelado todo utiliza el mecanismo del token bucket, este módulo primero explica cómo un token bucket funciona. Este módulo incluye las secciones siguientes:

¿Cuál es un token bucket?

Policing con el CAR

Regulación del tráfico

Modelado de tráfico (flujo de paquetes de regulación)

¿Cuál es un token bucket?

Un token bucket es una definición formal de un índice de transferencia. Tiene tres componentes: tamaños de ráfaga, una tasa promedio, y un intervalo de tiempo (Tc). Aunque la tasa promedio se represente generalmente como bits por segundo, cualquier dos valores se pueden derivar del tercero por la relación mostrada como sigue:

mean rate = burst size / time interval

Aquí están algunas definiciones de estos términos:

Tasa promedio — También llamó la Velocidad de información comprometida (CIR), especifica cuánto se pueden enviar o remitir los datos por el tiempo de unidad por término medio.

Tamaños de ráfaga — También llamó los tamaños de (Bc) del committed burst, él especifica en los bits (o los bytes) por la explosión, cuánto tráfico se puede enviar dentro de una unidad de tiempo dada para no crear las preocupaciones de previsión. (Para un shaper, tal como GTS, especifica los bits por la explosión; para un policer, tal como CAR, especifica los bytes por la explosión, por segundo.)

Intervalo de tiempo — También llamó el intervalo de medición, él especifica el quántum del tiempo en los segundos por la explosión.

Por definición, sobre ningún múltiplo integral del intervalo, la velocidad de bits de la interfaz no excederá la tasa promedio. La velocidad de bits, sin embargo, puede ser arbitrariamente ayunar dentro del intervalo.

Un token bucket se utiliza para manejar un dispositivo que regule los datos en un flujo. Por ejemplo, el regulador pudo ser vigilante de tráfico, tal como CAR, o un modelador de tráfico, tal como FRTS o GTS. Una cubeta con ficha no posee una política de prioridad o descarte. Bastante, un token bucket desecha los tokens y deja al flujo el problema de manejar su cola de la transmisión si el flujo abruma el regulador. (Ni el CAR ni el FRTS y el GTS implementan un token bucket verdadero o el contador dinámico verdadero.)

En la metáfora de cubeta con fichas, los tokens se ponen en el compartimiento a una cierta velocidad. La cubeta posee una capacidad especificada. Si el compartimiento llena a la capacidad, los símbolos de llegada se desechan nuevamente. Cada token es un permiso para que el origen envíe cierto número de bits a la red. Para enviar un paquete, el regulador debe quitar del compartimiento varios tokens iguales en la representación a los tamaños de paquetes.

Si no bastantes tokens están en el compartimiento para enviar un paquete, el paquete cualquiera espera hasta que el compartimiento tenga bastantes tokens (en el caso del GTS) o el paquete se desecha o se marca abajo (en el caso del CAR). Si el compartimiento es ya lleno de tokens, los tokens entrantes desbordan y no están disponibles para los paquetes futuros. De esta manera, en cualquier momento, la ráfaga más grande que una fuente puede enviar a la red es más o menos proporcional al tamaño de la cubeta.

Observe que el mecanismo del token bucket usado para el modelado de tráfico tiene un token bucket y un búfer de datos, o cola; si no tuviera un búfer de datos, sería un policer. Para el modelado de tráfico, los paquetes que llegan eso no se pueden enviar inmediatamente se retrasan en el búfer de datos.

Para el modelado de tráfico, un token bucket permite el burstiness pero lo limita. Garantiza que el burstiness está limitado de modo que el flujo nunca envíe más rápidamente que la capacidad del token bucket, dividido para el momento en que intervalo, más la tarifa establecida en la cual los tokens se colocan en el token bucket. Vea la fórmula siguiente:

(token bucket capacity in bits / time interval in seconds) + established rate in bps = 
maximum flow speed in bps

Este método de limitar el burstiness también garantiza que la velocidad de transmisión a largo plazo no excederá la tarifa establecida en la cual los tokens se colocan en el compartimiento.

Policing con el CAR

El Committed Access Rate (CAR) personifica una función de limitación de velocidad para limpiar el tráfico, además de su característica de la clasificación de paquetes discutida en el módulo de la “Descripción general de la clasificación”. La función de limitación de velocidad del CAR maneja la política de ancho de banda del acceso para una red asegurándose de que el tráfico que baja dentro de los parámetros de la velocidad especificada está enviado, mientras que los paquetes de caída que exceden la cantidad de tráfico aceptable o el envío de ellos con una diversa prioridad. La acción de excedente para el CAR es caer o marcar abajo de los paquetes.

La función de la limitación de la tarifa del CAR hace el siguiente:

Permite que usted controle la velocidad máxima de tráfico enviada o recibida en una interfaz.

Le da la capacidad de definir la capa los límites de velocidad entrantes o salientes globales o granulares de 3 (ingreso o salida) del ancho de banda y de especificar las directivas de la gestión de tráfico cuando el tráfico se ajusta a o excede los límites de la velocidad especificada.

Los límites de velocidad del ancho de banda total hacen juego todos los paquetes en una interfaz o una subinterfaz. Los límites de velocidad granulares del ancho de banda hacen juego un tipo determinado de tráfico basado en la precedencia, la dirección MAC, u otros parámetros.

El CAR se configura a menudo en las interfaces en el borde de una red para limitar el tráfico en o la red de los.

Cómo el CAR trabaja

El CAR examina el tráfico recibido en una interfaz o un subconjunto de ese tráfico seleccionado por los criterios de lista de acceso. Después compara el índice del tráfico a un token bucket configurado y toma medidas basadas en el resultado. Por ejemplo, el CAR caerá el paquete o reescribirá la Prioridad IP reajustando los bits del Tipo de servicio (ToS). Usted puede configurar el CAR para enviar, para caer, o para fijar la precedencia.

Los aspectos de la limitación de la tarifa CAR se explican en las secciones siguientes:

Criterios correspondientes

Límites de velocidad

Acciones de conformidad y excedente

Directivas múltiples de la tarifa

El CAR utiliza una medición de cubeta con fichas. Los tokens se insertan en el compartimiento a la velocidad comprometida. La profundidad del compartimiento es los tamaños de ráfaga. Trafique la llegada el compartimiento cuando los suficientes tokens están disponibles se dicen para conformar, y el número de correspondencia de tokens se quita del compartimiento. Si una cantidad suficiente de tokens no está disponible, después el tráfico se dice para excederse.

Criterios correspondientes

El corresponder con del tráfico exige la identificación del tráfico del interés para la limitación, la configuración de precedencia, o ambas de la tarifa. Las directivas de la tarifa se pueden asociar a una de las calidades siguientes:

Interfaz entrante

Todo el tráfico IP

Prioridad IP (definida por una lista de acceso del tarifa-límite)

Dirección MAC (definida por una lista de acceso del tarifa-límite)

Valor experimental del Multiprotocol Label Switching (MPLS) (EXP) (definido por una lista de acceso del tarifa-límite)

Lista de IP Access (estándar y extendido)

El CAR proporciona las acciones configurables, por ejemplo envíe, caiga, o fije la precedencia cuando el tráfico se ajusta a o excede el límite de velocidad.


La notaque corresponde con a las listas de IP Access es más hace un uso intensivo del procesador que corresponder con basado en otros criterios.


Límites de velocidad

El CAR propaga las explosiones. No hace ningún alisar o formar del tráfico, y por lo tanto no hace ningún mitigar y no agrega ningún retardo. El CAR se optimiza altamente para ejecutarse en los links de alta velocidad — DS3, por ejemplo — en el modo distribuido en el Versatile Interface Processors (VIP) en las Cisco 7500 Series.

Los límites de velocidad CAR se pueden implementar en la interfaz de entrada o salida o las subinterfaces incluyendo el Frame Relay y las subinterfaces ATM.

Qué límites de velocidad definen

Los límites de velocidad definen qué paquetes se ajustan a o exceden la velocidad definida basada en los tres parámetros siguientes:

Tasa promedio. La tasa promedio determina la velocidad de transmisión media a largo plazo. Trafique que conformarán las caídas bajo esta tarifa siempre.

Tamaños de ráfaga normales. Los tamaños de ráfaga normales determinan cómo las ráfagas de tráfico grandes pueden ser antes de que un cierto tráfico exceda el límite de velocidad.

Tamaños de ráfaga en exceso. Los tamaños de (Be) de la ráfaga en exceso determinan cómo las ráfagas de tráfico grandes pueden ser antes de que todo el tráfico exceda el límite de velocidad. Trafique que las caídas entre los tamaños de ráfaga normales y los tamaños de ráfaga en exceso exceden el límite de velocidad con una probabilidad que aumente mientras que los tamaños de ráfaga aumentan.

El número máximo de tokens que un compartimiento pueda contener es determinado por los tamaños de ráfaga normales configurados para el token bucket.

Cuando el límite de velocidad CAR se aplica a un paquete, el CAR quita de los tokens del compartimiento que son equivalentes en gran número a los tamaños de bytes del paquete. Si llega un paquete y los tamaños de bytes del paquete son mayores que el número de tokens disponibles en el compartimiento del Token estándar, se dedica la capacidad de ráfaga ampliada si se configura.

Valor de ráfaga ampliada

La ráfaga ampliada es configurada fijando el valor de ráfaga ampliada mayor que el valor de ráfaga normal. La determinación del valor de ráfaga ampliada igual al valor de ráfaga normal excluye la capacidad de ráfaga ampliada. Si la ráfaga ampliada no se configura, dado el ejemplo de escenario, la acción de excedente del CAR toma el efecto porque una cantidad suficiente de tokens no está disponible.

Cuando se configura la ráfaga ampliada y ocurre este escenario, el flujo se permite pedir prestados los tokens necesarios para permitir que el paquete sea enviado. Esta capacidad existe para evitar el comportamiento de la eliminación de cola, y, en lugar, dedicar el comportamiento como el del Detección temprana aleatoria (RED).

Cómo la capacidad de ráfaga ampliada trabaja

Aquí es cómo la capacidad de ráfaga ampliada trabaja. Si un paquete llega y necesita pedir prestado n el número de tokens porque el token bucket contiene menos tokens que sus tamaños de paquetes requiere, después el CAR compara los dos valores siguientes:

Valor de parámetro de la ráfaga ampliada.

Deuda compuesta. La deuda compuesta se computa como la suma sobre todos ai:

a – indica el valor real de la deuda del flujo después de que se envíe i el paquete. La deuda real es simplemente una cuenta de cuántos tokens ha pedido prestados el flujo actualmente.

i – indica iel paquete del th que intenta pedir prestados los tokens puesto que la última vez que un paquete fue caído.

Si la deuda compuesta es mayor que el valor de ráfaga ampliada, la acción de excedente del CAR toma el efecto. Después de que se caiga un paquete, la deuda compuesta se fija con eficacia a 0. CAR computará un nuevo valor compuesto de la deuda igual a la deuda real para el próximo paquete que necesita pedir prestados los tokens.

Si la deuda real es mayor que el limite extendido, todos los paquetes serán caídos hasta que la deuda real se reduzca con la acumulación de tokens en el token bucket.

Los paquetes perdidos no cuentan contra ninguna tarifa ni reparten el límite. Es decir, cuando se cae un paquete, no se quita ningunos tokens del token bucket.


Observeaunque es verdad la deuda compuesta entera se perdona cuando se cae un paquete, la deuda real no se perdona, y el próximo paquete a llegar a los tokenes insuficientes se asigna inmediatamente un nuevo valor compuesto de la deuda igual a la deuda real actual. De esta manera, la deuda real puede continuar creciendo hasta que sea tan grande que no hay composición necesario hacer un paquete ser caído. En efecto, ahora, la deuda compuesta no se perdona realmente. Este escenario llevaría a los descensos excesivos en las secuencias que exceden continuamente la explosión normal. (Véase el ejemplo en la sección siguiente, “ejemplo real y compuesto de la deuda.”


La prueba de tráfico TCP sugiere que el normal y los valores de ráfaga ampliada elegidos estén por orden del valor de varios segundos del tráfico a la tasa promedio configurada. Es decir, si la tasa promedio es 10 Mbps, después tamaños de ráfaga normales de 10 al 20 Mb y tamaños de ráfaga en exceso de 20 al 40 Mb sea apropiado.

Valores de ráfaga recomendados

Cisco recomienda los valores siguientes para los parámetros normales y de la ráfaga ampliada:

normal burst = configured rate * (1 byte)/(8 bits) * 1.5 seconds
extended burst = 2 * normal burst

Con las opciones mencionadas para los parámetros, los resultados de la prueba extensos han mostrado el CAR para alcanzar la velocidad configurada. Si los valores de ráfaga son demasiado bajos, después la tarifa alcanzada es a menudo mucho más baja que la velocidad configurada.

Ejemplo real y compuesto de la deuda

Este ejemplo muestra cómo se perdona la deuda compuesta, pero la deuda real acumula.

Por este ejemplo, asuma los parámetros siguientes:

La tarifa simbólica es 1 unidad de datos por la unidad de tiempo

Los tamaños de ráfaga normales son 2 unidades de datos

Los tamaños de la ráfaga ampliada son 4 unidades de datos

2 unidades de datos llegan por la unidad de tiempo

Después de 2 unidades de tiempo, la secuencia ha utilizado encima de su explosión normal y debe comenzar a pedir prestada una unidad de datos por la unidad de tiempo, comenzando en la unidad de tiempo 3:

Time    DU arrivals     Actual Debt     Compounded Debt
-------------------------------------------------------
1       2               0               0
2       2               0               0
3       2               1               1
4       2               2               3
5       2               3 (temporary)   6 (temporary)

Ahora un paquete se cae porque la nueva deuda compuesta (6) excedería el límite de la ráfaga ampliada (4). Cuando se cae el paquete, la deuda compuesta se convierte en con eficacia 0, y la deuda real es 2. (los valores 3 y 6 eran solamente temporales y no siguen siendo válidos en el caso donde se cae un paquete.) Los valores finales para la unidad de tiempo 5 siguen. La secuencia comienza a pedir prestado otra vez en la unidad de tiempo 6.

Time    DU arrivals     Actual Debt     Compounded Debt
-------------------------------------------------------
5       2               2               0
6       2               3               3
7       2               4 (temporary)   7 (temporary)

En la unidad de tiempo 6, se cae otro paquete y los valores de la deuda se ajustan por consiguiente.

Time    DU arrivals     Actual Debt     Compounded Debt
-------------------------------------------------------
7       2               3               0

Acciones de conformidad y excedente

El CAR utiliza un token bucket, así el CAR puede pasar las ráfagas temporarias que exceden el límite de velocidad mientras los tokens estén disponibles.

Una vez que un paquete se ha clasificado como conforme a o excediendo un límite de velocidad determinado, el router realiza una de las acciones siguientes en el paquete:

Transmita — Se envía el paquete.

Descenso — Se desecha el paquete.

Fije la precedencia y transmítala — Los bits de la Prioridad IP (TOS) en el encabezado de paquete se reescriben. El paquete entonces se envía. Usted puede utilizar esta acción al color (fije la precedencia) o al recolor (modifique la precedencia del paquete existente) el paquete.

Continúe — El paquete se evalúa usando la directiva siguiente de la tarifa en un encadenamiento de los límites de velocidad. Si no hay otra directiva de la tarifa, se envía el paquete.

Fije la precedencia y continúe — Fije los bits de la Prioridad IP a un valor especificado y después evalúe la directiva siguiente de la tarifa en el encadenamiento de los límites de velocidad.

Para las Plataformas VIP basadas, dos más acciones son posibles:

Fije el grupo de QoS y transmítalo — El paquete se asigna a un grupo de QoS y se envía.

Fije el grupo de QoS y continúe — El paquete se asigna a un grupo de QoS y después se evalúa usando la directiva siguiente de la tarifa. Si no hay otra directiva de la tarifa, se envía el paquete.

Directivas múltiples de la tarifa

Una sola directiva de la tarifa CAR incluye la información sobre el límite de velocidad, las acciones de conformidad, y las acciones de excedente. Cada interfaz puede tener directivas múltiples de la tarifa CAR correspondiente a diversos tipos de tráfico. Por ejemplo, el tráfico de la prioridad baja se puede limitar a una menor velocidad que el tráfico de prioridad alta. Cuando hay directivas múltiples de la tarifa, el router examina cada directiva en la orden ingresada hasta que el paquete corresponda con. Si no se encuentra ninguna coincidencia, la acción predeterminada es enviar.

Las directivas de la tarifa pueden ser independientes: cada directiva de la tarifa se ocupa de un tipo diferente de tráfico. Alternativamente, las directivas de la tarifa pueden conectar en cascada: un paquete se puede comparar a diversas directivas múltiples de la tarifa sucesivamente.

La conexión en cascada de las directivas de la tarifa permite que una serie de límites de velocidad sea aplicada a los paquetes para especificar directivas más granulares (por ejemplo, usted podría tráfico total del límite de velocidad en un vínculo de acceso a un tráfico especificado del World Wide Web del ancho de banda y entonces del límite de velocidad del subrate en el mismo link a una proporción dada del límite del subrate) o para hacer juego los paquetes contra una secuencia ordenada de directivas hasta que se encuentre un límite de velocidad aplicable (por ejemplo, valore la limitación de varias direcciones MAC con diversas asignaciones de ancho de banda en una punta del intercambio). Usted puede configurar hasta las directivas de las 100 tarifas en una subinterfaz.

Restricciones del CAR y del CAR VIP-distribuido

El CAR y el CAR VIP-distribuido se pueden utilizar solamente con el tráfico IP. El tráfico no IP no es tarifa limitada.

El CAR o el CAR VIP-distribuido se puede configurar en una interfaz o una subinterfaz. Sin embargo, el CAR y el CAR VIP-distribuido no se soportan en las interfaces siguientes:

Fast EtherChannel

Túnel

PRI

Cualquier interfaz que no soporte el Cisco Express Forwarding (CEF)

El CAR se soporta solamente en las subinterfaces ATM con las encapsulaciones siguientes: aal5snap, aal5mux, y aal5nlpid.


La notaCAR proporciona la tarifa que limita y no garantiza el ancho de banda. El CAR se debe utilizar con otras características de QoS, tales como feria cargada distribuida que hace cola (DWFQ), si se requieren las garantías superiores del ancho de banda.


Regulación del tráfico

La Vigilancia de tráfico permite que usted controle la velocidad máxima de tráfico enviada o recibida en una interfaz, y que divida una red en los niveles de prioridad múltiples o el Clase de Servicio (CoS).

La característica de regulación del tráfico maneja la velocidad máxima de tráfico a través de un algoritmo de cubeta con fichas. El algoritmo de cubeta con fichas puede utilizar los valores configurados por el usuario para determinar la velocidad máxima de tráfico permitida en una interfaz en un momento en el tiempo dado. El algoritmo de cubeta con fichas es afectado por todo el tráfico que ingresa o que se va (dependiendo de donde la política de tráfico con la Vigilancia de tráfico configurada) y es útil en manejo del ancho de banda de la red en caso de que varios paquetes grandes se envíen en el mismo flujo de tráfico.

El algoritmo de cubeta con ficha provee a los usuarios de tres acciones por paquete. una acción de conformidad, una acción de excedente, y una acción de violación opcional. El tráfico que ingresa la interfaz con la Vigilancia de tráfico configurada se pone en una de estas categorías. Dentro de estas tres categorías, los usuarios pueden decidir los tratamientos de los paquetes. Por ejemplo, los paquetes que conforman se pueden configurar para ser transmitido, los paquetes que se exceden se pueden configurar para ser enviado con una prioridad disminuida, y los paquetes que violan se pueden configurar para ser caído.

La Vigilancia de tráfico se configura a menudo en las interfaces en el borde de una red para limitar el índice de tráfico que ingresa o que sale de la red. En las configuraciones mas comunes de la Vigilancia de tráfico, se transmite el tráfico que conforma y el tráfico que se excede se envía con una prioridad disminuida o se cae. Los usuarios pueden cambiar esta opción de configuración de adaptarse a sus necesidades de la red.

La característica de regulación del tráfico soporta el MIB siguiente:

CISCO-CLASS-BASED-QOS-MIB

CISCO-CLASS-BASED-QOS-CAPABILITY-MIB

Esta característica también soporta el RFC 2697, A Single Rate Three Color Marker.

Para la información sobre cómo configurar la característica de regulación del tráfico, vea “configurando el módulo de la Vigilancia de tráfico”.

Ventajas de la Vigilancia de tráfico

Administración del ancho de banda con la limitación de la tarifa

La Vigilancia de tráfico permite que usted controle la velocidad máxima de tráfico enviada o recibida en una interfaz. La Vigilancia de tráfico se configura a menudo en las interfaces en el borde de una red para limitar el tráfico en o la red de los. Trafique que las caídas dentro de los parámetros de velocidad están enviadas, mientras que el tráfico que excede los parámetros se cae o se envía con una diversa prioridad.

Marca del paquete a través de la Prioridad IP, del grupo de QoS, y de la configuración del valor DSCP

La marca del paquete permite que usted divida su red en los niveles de prioridad múltiples o las Clases de servicio (CoS), como sigue:

Utilice la Vigilancia de tráfico para fijar la Prioridad IP o los valores del Differentiated Services Code Point (DSCP) para los paquetes que ingresan la red. Los dispositivos de interconexión de redes dentro de su red pueden entonces utilizar los valores ajustados de la Prioridad IP para determinar cómo el tráfico debe ser tratado. Por ejemplo, la característica DWRED utiliza los valores de la Prioridad IP para determinar la probabilidad que un paquete será caído.

Utilice la Vigilancia de tráfico para asignar los paquetes a un grupo de QoS. El router utiliza el grupo de QoS para determinar cómo dar prioridad a los paquetes.

Restricciones para la Vigilancia de tráfico

Las restricciones siguientes se aplican a la característica de regulación del tráfico:

En un Cisco 7500 Series Router, la Vigilancia de tráfico puede monitorear las trayectorias del CEF Switching solamente. Para utilizar la característica de regulación del tráfico, el CEF se debe configurar en la interfaz que recibe el paquete y la interfaz que envía el paquete.

En un Cisco 7500 Series Router, la Vigilancia de tráfico no se puede aplicar a los paquetes que originaron de ni se destina a un router.

La Vigilancia de tráfico se puede configurar en una interfaz o una subinterfaz.

La Vigilancia de tráfico no se soporta en las interfaces siguientes:

– Fast EtherChannel

– Túnel

– PRI

– Ningunos interfaz en un Cisco 7500 Series Router que no soporta el CEF

Requisitos previos para la Vigilancia de tráfico

En un Cisco 7500 Series Router, el CEF se debe configurar en la interfaz antes de que la Vigilancia de tráfico pueda ser utilizada.

Para más información sobre el CEF, vea “el módulo del mapa de ruta de las características del Cisco Express Forwarding”.

Modelado de tráfico (flujo de paquetes de regulación)

Regulando el flujo de paquetes (es decir, el flujo del tráfico) en la red también se conoce como modelado de tráfico. El modelado de tráfico permite que usted controle la velocidad del tráfico que deja una interfaz. Esta manera, usted puede hacer juego el flujo del tráfico a la velocidad de la interfaz que recibe el paquete.

Cisco proporciona tres mecanismos para regular o formar el tráfico: Control de tráfico basado en clases, Control de tráfico genérico (GTS), y Control de tráfico de Frame Relay (FRTS).

Para más información sobre el modelado de tráfico, vea de “flujo de paquetes regulación usando el módulo del modelado de tráfico”.

Para la información sobre configurar el Frame Relay y el FRTS, vea configurando el módulo del Frame Relay” y el módulo del “Control de tráfico de Frame Relay MQC-basado”, respectivamente.