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

Descripción general de la regulación y diseño de tráfico
Descargue este capítulo
Descripción general de la regulación y diseño de tráfico
Descargue el libro completo
Soluciones guía de configuración de la Calidad de servicio de Cisco IOS, versión 12.2SR (PDF - 6 MB)
Feedback
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 VIPdistribuido 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.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks
can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word
partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any
examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only.
Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2011 Cisco Systems, Inc. All rights reserved.
© 1992-2013 Cisco Systems Inc. Todos los Derechos Reservados.
Fecha de Generación del PDF: 21 Agosto 2013
http://www.cisco.com/cisco/web/support/LA/107/1075/1075577_polcing_shping_oview_ps6922_TSD_Products_Configuration_Guide_Chapter.html