QoS hizo con frecuencia las preguntas
Contenido
Introducción
Este documento responde a las preguntas más frecuentes (FAQ) relacionadas con la Calidad de Servicio (QoS).
General
Q. ¿Qué es la calidad de servicio (QoS)?
A. QoS se refiere a la capacidad de una red para ofrecer un mejor servicio a un tráfico de red seleccionado a través de varias tecnologías subyacentes, entre ellas, Frame Relay, modo de transferencia asíncrona (ATM, asynchronous transfer mode), Ethernet y redes 802.1X, SONET y redes con routing IP.
QoS es una recolección de tecnologías que permite que las aplicaciones pidan y que reciban los niveles del servicio predecible en términos de capacidad de producción de datos (ancho de banda), variaciones de latencia (inquietud), y retraso. Particularmente, las características de QoS proporcionan mejor y más servicio de red predecible por los métodos siguientes:
Admite un ancho de banda dedicado.
Mejora de las características de pérdida.
Evitando y manejo de la congestión de red.
Define el tráfico de red.
Establecer las prioridades de tráfico a través de la red.
El Internet Engineering Task Force (IETF) define las dos arquitecturas siguientes para QoS:
Servicios integrados (IntServ)
Servicios diferenciados (DiffServ)
IntServ utiliza el Resource Reservation Protocol (RSVP) para señalar explícitamente las necesidades de QoS del tráfico de una aplicación a lo largo de los dispositivos en la trayectoria de punta a punta a través de la red. Si cada dispositivo de red a lo largo de la trayectoria puede reservar el ancho de banda necesario, la aplicación de origen puede comenzar a transmitir. La petición de comentarios (RFC) 2205 define el RSVP, y la RFC 1633 define el IntServ.
DiffServ se centra en el agregado y el aprovisionamiento de QoS. En vez de señalar los requisitos de QoS de una aplicación, el DiffServ utiliza un punto del código del DiffServ (DSCP) en la encabezado IP para indicar los niveles requeridos de QoS. El Software Release 12.1(5)T de Cisco IOS® introdujo la conformidad del DiffServ en el Routers de Cisco. Si desea más información, consulte los siguientes documentos:
Q. ¿Cuáles son congestión, retrasan, e inquietud?
A. Una interfaz experimenta congestión cuando tiene más tráfico del que puede gestionar. Las puntas de la congestión de red son candidatos posibles para los mecanismos del Calidad de Servicio (QoS). A continuación, un ejemplo de los puntos de congestión más comunes:
Resultados de la congestión de red en el retraso. Una red y sus dispositivos introducen varios tipos de retrasos, como se explica en Conocimientos sobre el retraso en redes de paquetes de voz. La variación en el retraso se conoce como inquietud, como se explica en comprensión de la inquietud en las redes de voz en paquetes (Plataformas del Cisco IOS). Es necesario controlar y minimizar tanto la demora como las fluctuaciones para admitir el tráfico en tiempo real e interactivo.
Q. ¿Cuál es el MQC?
A. MQC significa interfaz de línea de comando (CLI) de calidad de servicio (QoS) modular. Está diseñado para simplificar la configuración de QoS en los routers y switches de Cisco, mediante la definición de una sintaxis de comandos y un conjunto final de comportamientos de QoS en común entre las plataformas. Este modelo substituye el modelo previó de la definición de una sintaxis única para cada uno función de calidad de servicio (QoS) y para cada plataforma.
El MQC comprende los tres pasos siguientes:
Definir una clase de tráfico ejecutando el comando class-map.
Cree una política de tráfico asociando la clase de tráfico a una o más características de QoS publicando el comando policy-map.
Adjuntar la directiva del tráfico a la interfaz, subinterfaz o circuito virtual (VC) ejecutando el comando service-policy.
Nota: Usted ejecuta las funciones de condicionamiento del tráfico del DiffServ, tales como marca y formar, usando la sintaxis MQC.
Para obtener más información, consulte Interfaz de línea de comando de calidad del servicio modular.
Q. ¿Qué hace la servicio-directiva se utiliza solamente en los interfaces VIP con el mensaje habilitado de DCEF significó?
A. En procesadores de interfaz versátil (VIP) de la serie 7500 de Cisco, solo se admiten funciones de Calidad de servicio (QoS) distribuida a partir de Cisco IOS 12.1(5)T, 12.1(5)E y 12.0(14)S. La acción de habilitar distributed Cisco Express Forwarding (dCEF) habilita automáticamente la QoS distribuida.
Las interfaces no VIP, conocidas como procesadores de la interfaz Legacy (IPS), utilizan las características centrales de QoS según lo activado en el Procesador del switch de la ruta (RSP). Si desea más información, consulte los siguientes documentos:
Q. ¿Cuántas clases admite una política de calidad del servicio (QoS)?
A. En las versiones del Cisco IOS de 12.2 usted podría definir anterior un máximo solamente de las clases 256, y usted podría definir hasta las clases 256 dentro de cada directiva si las mismas clases se reutilizan para diversas directivas. Si usted tiene dos políticas, el número total de clases de ambas políticas no debe superar 256. Si una política incluye el Mecanismo de cola de espera equitativo y ponderado basado en clases (CBWFQ) (lo que significa que contiene una declaración de ancho de banda [o prioridad] dentro de cualquiera de las clases), el número total de clases compatibles es 64.
En Cisco IOS versiones 12.2(12), 12.2(12)T y 12.2(12)S, esta limitación de 256 asignaciones de clase globales se ha cambiado, y ahora es posible configurar un máximo de 1024 asignaciones de clase globales y utilizar 256 asignaciones de clase dentro de la misma asignación de política.
Q. ¿Cómo se procesan las actualizaciones de routing y los mensajes de actividad de Protocolo punto a punto (PPP) / Control de enlace de datos de alto nivel (HDLC) cuando se aplica una política de servicio?
A. Los routers de Cisco IOS utilizan los dos mecanismos siguientes para priorizar los paquetes de control:
Prioridad IP
pak_priority
Ambos mecanismos se diseñan para asegurarse de que los paquetes de Control de Llaves no son caídos ni son caídos por último por el router y el sistema de colocación en cola cuando se congestiona una interfaz de salida. Para más información, refiera a entender cómo encamina las actualizaciones y los paquetes de control se hacen cola en un interfaz con una política de servicio de QoS.
Q. ¿Se admite la Calidad del servicio (QoS) en las interfaces configuradas con Puente y routing integrado (IRB)?
A. No. No puede configurar las funciones de QoS cuando la interfaz está configurada para IRB.
Clasificación y marcado
Q. ¿Cuál es pre-clasificación del Calidad de Servicio (QoS)?
A. La clasificación previa de QoS permite hacer coincidir y clasificar el contenido del encabezado de IP original de los paquetes que pasan por encapsulamiento, tunelización o cifrado. Esta función no describe el proceso de copiar el valor original del byte del tipo de servicio (ToS) desde el encabezado del paquete original al encabezado de túnel. Si desea más información, consulte los siguientes documentos:
Q. ¿Qué campos del encabezado del paquete pueden ser comentados? ¿Qué valores están disponibles?
A. La característica del Marcado basado en clases permite que usted fije o que marque la capa 2, la capa 3 o la encabezado del Multiprotocol Label Switching (MPLS) de sus paquetes. Si desea más información, consulte los siguientes documentos:
Q. ¿Puedo dar prioridad al tráfico basado en el URL?
A. Yes. El Reconocimiento de aplicaciones basadas en la red (NBAR) permite que usted clasifique los paquetes correspondiendo con en los campos en la capa de la aplicación. Antes de la introducción de NBAR, la clasificación más granular eran los números de puertos de protocolo de control de transmisión (TCP) y protocolo de datagramas de usuario (UDP) de capa 4. Si desea más información, consulte los siguientes documentos:
Q. ¿Qué Plataformas y versiones de software del Cisco IOS utilizan el Reconocimiento de aplicaciones basadas en la red (NBAR)?
A. Las siguientes versiones de software de Cisco IOS son compatibles con NBAR:
Plataforma Versión mínima del Software del IOS de Cisco 7200 12.1(5)T 7100 12.1(5)T 3660 12.1(5)T 3640 12.1(5)T 3620 12.1(5)T 2600 12.1(5)T 1700 12.2(2)T Nota: Para utilizar NBAR debe activar Cisco Express Forwarding (CEF).
NBAR distribuido (DNBAR) está disponible en las siguientes plataformas:
Plataforma Versión mínima del Software del IOS de Cisco 7500 12.2(4)T, 12.1(6)E FlexWAN 12.1(6)E Nota: NBAR no se utiliza en los interfaces del VLA N del indicador luminoso LED amarillo de la placa muestra gravedad menor de característica de switch multicapa del catalizador 6000 (MSFC), las Cisco 12000 Series, o el módulo del switch de la ruta (RSM) para las Catalyst 5000 Series. Si no ve incluida una plataforma en particular, póngase en contacto con su representante técnico de Cisco.
Administración de congestión y colas
Q. ¿Cuál es el objetivo de la cola?
A. La cola está diseñada para manejar la congestión temporal en la interfaz de un dispositivo de red almacenando el exceso de paquetes en búferes hasta que haya ancho de banda disponible. El Routers del Cisco IOS utiliza varios métodos para colocación en cola para cumplir el ancho de banda, la inquietud, y los requisitos de retraso diversos de diversas aplicaciones.
El mecanismo predeterminado en la mayoría de los interfaces es Primero en entrar, primero en salir (FIFO). Algunos tipos de tráfico tienen más requisitos exigentes del retraso/de la inquietud. Así, uno de los Mecanismos para formar la cola alternativos siguientes se debe configurar o se activa por abandono:
Espera cargada de la feria (WFQ)
Mecanismo de cola de espera equitativo y ponderado basado en clases (CBWFQ)
Low latency queueing (LLQ), que es de hecho CBWFQ con un priority queue (PQ) (conocido como PQCBWFQ)
Asignación de colas de prioridad (PQ)
Asignación personalizada de colas
La espera sucede generalmente en las interfaces de salida solamente. Paquetes de cola de router que están saliendo un interfaz. Se puede supervisar el tráfico entrante, pero normalmente no se puede poner en cola (una excepción es el almacenamiento en búfer del lado de recepción en un router de Cisco de la serie 7500 mediante Cisco Express Forwarding distribuida (dCEF) para reenviar paquetes desde la interfaz de entrada a la interfaz de salida; para obtener más información, consulte Descripción de VIP CPU con ejecución al 99% y almacenamiento en búfer del lado de recepción. En las plataformas distribuidas de gama alta tales como las Cisco y? Series, la interfaz de entrada puede utilizar sus propios almacenes intermedios del paquete para salvar exceso del tráfico cambiado a una interfaz de salida congestionada que sigue la decisión de Switching de la interfaz de entrada. En las condiciones poco probables, típicamente cuando la interfaz de entrada está alimentando una interfaz de salida más lenta, la interfaz de entrada puede experimentar el incremento de los errores ignorados cuando se ejecuta de memoria del paquete. La congestión excesiva puede llevar a las pérdidas de la cola de salida. Las caídas de entradas en la cola tienen una diversa causa raíz la mayor parte del tiempo. Para más información sobre los descensos del troubleshooting, refiera al documento siguiente:
Si desea más información, consulte los siguientes documentos:
Q. ¿Cómo hacen feria cargada que hace cola (WFQ) y feria cargada basada clase que hace cola (CBWFQ) actuaron?
A. La cola equitativa intenta asignar una parte equitativa del ancho de banda de una interfaz entre conversaciones activas o flujos de IP. Clasifica los paquetes en los subqueues, identificados por un número de identificación de la conversación, usando un algoritmo de troceo basado en varios campos de la encabezado IP y la longitud del paquete. Lo que sigue es cómo se calcula la ponderación:
W=K/(precedencia +1)
K= 4096 con el Cisco IOS 12.0(4)T y las versiones anteriores, y 32384 con 12.0(5)T y versiones posteriores.
Cuanto más baja es la ponderación, más alta es la prioridad y la parte del ancho de banda. Además de la ponderación, la longitud del paquete se tiene en cuenta.
CBWFQ le permite definir una clase de tráfico y asignarle una garantía de ancho de banda mínimo. El algoritmo detrás de este mecanismo es WFQ, que explica el nombre. Para configurar CBWFQ, usted define las clases específicas en las declaraciones del map-class. Luego, puede asignar una política a cada clase en una asignación de políticas. Esta directiva-correspondencia entonces será saliente asociado a un interfaz. Si desea más información, consulte los siguientes documentos:
Q. ¿Si una clase en la feria cargada basada clase que hace cola (CBWFQ) no está utilizando su ancho de banda, pueden otras clases utilizar el ancho de banda?
A. Yes. Aunque las garantías de ancho de banda proporcionadas publicando los comandos bandwidth and priority se hayan descrito con las palabras como “reservado” y el “ancho de banda que se pondrá a un lado”, ninguno de los dos comandos ejecuta una reserva real. El significar, si una clase de tráfico no está utilizando su configuré el ancho de banda, cualquier ancho de banda sin utilizar se comparte entre las otras clases.
El sistema de envío a cola impone una excepción importante de clase prioritaria a esta regla. Según lo observado arriba, la carga ofrecida de una clase de prioridad es medida por un policer del tráfico. Durante las condiciones de la congestión, una clase de prioridad no puede utilizar ningún exceso de ancho de banda. Para más información, refiera a comparar los comandos bandwidth and priority de una política de servicio de QoS.
Q. ¿Se admite el mecanismo de cola equitativo ponderado basado en clases (CBWFQ) en las subinterfaces?
A. Las interfaces lógicas del Cisco IOS intrínsecamente no utilizan un estado de la congestión y no utilizan la aplicación directa de una política de servicio que aplique un método para colocación en cola. En lugar, usted primero necesita aplicar formar al subinterface usando el Control de tráfico genérico (GTS) o la modelación basada en la clase. Para más información, refiera a aplicar las características de QoS a las subinterfaces Ethernet.
Q. ¿Cuál es la diferencia entre la prioridad y las declaraciones del ancho de banda en una directiva-correspondencia?
A. Los comandos priority and bandwidth diferencian en las funciones y en qué aplicaciones utilizan típicamente. En la siguiente tabla, se resumen esas diferencias:
Función Comando bandwidth Comando priority Garantía de ancho de banda mínimo Yes Yes Garantía de ancho de banda máxima No Yes Policer incorporado No Yes Proporciona latencia baja No Yes Para más información, refiera a comparar de una política de servicio de QoS.
Q. ¿Cómo el límite de cola se calcula en el FlexWAN y el Procesadores de interfaz versátil (VIP)?
A. Con la suposición de que haya suficiente SRAM en VIP o FlexWAN, el límite de cola se calcula sobre la base de un retraso máximo de 500 ms, con un tamaño promedio de paquetes de 250 bytes. El siguiente es un ejemplo de una clase con un Mbps de ancho de banda:
Límite de cola = 1000000/(250 x 8 x 2) = 250
Se asignan límites de cola más pequeños como la cantidad de disminuciones disponibles de memoria del paquete y con un número más grande de circuitos virtuales (VCS).
En el ejemplo siguiente, un PA-A3 está instalado en una placa FlexWAN para las Cisco 7600 Series y está utilizando las subinterfaces múltiples con los circuitos virtuales permanentes del 2 MB (PVCs). La política de servicio se aplica a cada VC.
class-map match-any XETRA-CLASS match access-group 104 class-map match-any SNA-CLASS match access-group 101 match access-group 102 match access-group 103 policy-map POLICY-2048Kbps class XETRA-CLASS bandwidth 320 class SNA-CLASS bandwidth 512 interface ATM6/0/0 no ip address no atm sonet ilmi-keepalive no ATM ilmi-keepalive ! interface ATM6/0/0.11 point-to-point mtu 1578 bandwidth 2048 ip address 22.161.104.101 255.255.255.252 pvc ABCD class-vc 2048Kbps-PVC service-policy out POLICY-2048KbpsEl interfaz del Asynchronous Transfer Mode (ATM) consigue un límite de cola para el interfaz entero. El límite es una función de los almacenadores intermediarios disponibles totales, del número de interfaces físicas en el FlexWAN, y del retraso máximo de almacenamiento en cola permitido en el interfaz. Cada PVC consigue una porción del límite del interfaz basado en la velocidad continua de celda PVC (SCR) o la velocidad mínima de celda (MCR), y cada clase consigue una porción del límite PVC basado en su asignación de ancho de banda.
La salida de muestra siguiente del comando show policy-map interface se deriva de un FlexWAN con 3687 memorias intermedias globales. Publique el comando show buffer de ver este valor. Cada PVC de dos Mbps se afecta un aparato 50 paquetes basados en el ancho de banda de PVC de dos Mbps (2047/149760 x 3687 = 50). Cada clase luego recibe una parte de los 50, como se muestra en el siguiente resultado:
service-policy output: POLICY-2048Kbps class-map: XETRA-CLASS (match-any) 687569 packets, 835743045 bytes 5 minute offered rate 48000 bps, drop rate 6000 BPS match: access-group 104 687569 packets, 835743045 bytes 5 minute rate 48000 BPS queue size 0, queue limit 7 packets output 687668, packet drops 22 tail/random drops 22, no buffer drops 0, other drops 0 bandwidth: kbps 320, weight 15 class-map: SNA-CLASS (match-any) 2719163 packets, 469699994 bytes 5 minute offered rate 14000 BPS, drop rate 0 BPS match: access-group 101 1572388 packets, 229528571 bytes 5 minute rate 14000 BPS match: access-group 102 1146056 packets, 239926212 bytes 5 minute rate 0 BPS match: access-group 103 718 packets, 245211 bytes 5 minute rate 0 BPS queue size 0, queue limit 12 packets output 2719227, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 bandwidth: kbps 512, weight 25 queue-limit 100 class-map: class-default (match-any) 6526152 packets, 1302263701 bytes 5 minute offered rate 44000 BPS, drop rate 0 BPS match: any 6526152 packets, 1302263701 bytes 5 minute rate 44000 BPS queue size 0, queue limit 29 packets output 6526840, packet drops 259 tail/random drops 259, no buffer drops 0, other drops 0Si sus flujos de tráfico utilizan los tamaños de paquetes grandes, la salida del comando show policy-map interface puede señalar un valor de incremento para el ningún campo de las caídas del búfer puesto que usted puede ejecutarse de los almacenadores intermediarios antes de alcanzar el límite de cola. En este caso, intente reducir manualmente el límite de cola en las clases no prioritarias. Para obtener más información, consulte Descripción del límite de cola de transmisión con CoS ATM IP.
Q. ¿Cómo usted verifica el valor del cola-límite?
A. En las plataformas no distribuidas, el límite de cola es de 64 paquetes de forma predeterminada. La salida de ejemplo siguiente fue capturada en un Cisco 3600 Series Router:
november# show policy-map interface s0 Serial0 Service-policy output: policy1 Class-map: class1 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 5 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 30 (kbps) Max Threshold 64 (packets) !--- Max Threshold is the queue-limit. (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class2 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 2 Match: ip precedence 3 Weighted Fair Queueing Output Queue: Conversation 266 Bandwidth 24 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: any
Q. ¿Puedo activar la feria que hace cola dentro de una clase?
A. Las Cisco 7500 Series con el Calidad de Servicio (QoS) distribuido utilizan la feria que hace cola por la clase. Otras plataformas, incluidas la serie 7200 de Cisco y las series 2600/3600 de Cisco, admiten el Mecanismo de cola de espera equitativo y ponderado (WFQ) en la clase de clase predeterminada. todas las clases de ancho de banda utilizan el Primero en entrar, primero en salir (FIFO).
Q. ¿Qué comandos puedo utilizar para vigilar la espera?
A. Utilice los siguientes comandos para supervisar la cola:
show queue {interface}{interface number} - En las plataformas de Cisco IOS que no sean de la serie 7500 de Cisco, este comando muestras las colas o conversaciones activas. Si el interfaz o el virtual circuit (VC) no se congestiona, no hay colas de administración del tráfico mencionadas. En las Cisco 7500 Series, no apoyan al comando show queue.
muestre el [vc [[vpi/] vci del Número de interfaz del interfaz de espera] - esto visualiza las estadísticas de espera de un interfaz o un VC. Incluso cuando no haya congestión, podrá ver algunos resultados aquí. La razón de esto es que los paquetes cambiados proceso están contados siempre sin importar la congestión que está presente. El Cisco Express Forwarding (CEF) y los paquetes rápido-cambiados no se están contando a menos que haya congestión. Los mecanismos de cola heredada como Cola prioritaria (PQ), Cola personalizada (CQ) y Cola equitativa ponderada (WFQ) no proporcionan estadísticas de clasificación. Solo las funciones basadas en la interfaz de línea de comando de calidad de servicio modular (MQC) en las imágenes posteriores a 12.0(5)T ofrecen estas estadísticas.
muestre la interfaz de la política {interfaz} {Número de interfaz} - los paquetes al revés cuentan el número de paquetes que corresponden con los criterios de la clase. Este contador se incrementa sin importar si la interfaz está congestionada o no. El contador de paquetes coincidentes indica el número de paquetes que cumplen los criterios de la clase cuando la interfaz se congestiona. Para más información sobre los contadores de paquetes, refiera al documento siguiente:
Introducción a los contadores de paquetes en el resultado de show policy-map interface.’
MIB de configuración y estadística de QoS basada en clases de Cisco - Proporciona capacidades de supervisión de Protocolo simple de administración de redes (SNMP).
Q. Puede utilizarse RSVP junto con el mecanismo de cola equitativo ponderado basado en clases (CBWFQ). ¿Cuándo Resource Reservation Protocol (RSVP) y CBWFQ se configuran para un interfaz, RSVP y CBWFQ actúan independientemente, exhibiendo el mismo comportamiento que si cada uno se ejecutaba solamente? RSVP se comporta como si CBWFQ no estuviera configurado con respecto a la asignación, evaluación y disponibilidad del ancho de banda.
A. Al usar RSVP y CB-WFQ en el Cisco IOS Software Release 12.1(5)T y Posterior, el router puede actuar tales que los flujos de RSVP y las clases CBWFQ comparten el ancho de banda disponible en un interfaz o un PVC, sin la sobresubscripción.
El Software Release 12.2(1)T y Posterior IOS, permite que RSVP haga el control de admisión usando sus el propio “pool del ancho de banda del rsvp IP”, mientras que CBWFQ hace la clasificación, limpiando, y programando de los paquetes de RSVP. Esto asume los paquetes premarcados por el remitente, y que los paquetes de no-RSVP están marcados diferentemente.
Weighted Random Early Detection (WRED) de la evitación de la congestión
Q. ¿Puedo activé el Weighted Random Early Detection (WRED) y el low latency queueing (LLQ), o la clase basada cargó la feria que hacía cola (CBWFQ) al mismo tiempo?
A. Yes. La espera define la pedido de los paquetes que salen de una cola. Este los medios, define un mecanismo de paquete-previsión. También se puede utilizar para proporcionar una asignación equitativa de ancho de banda y garantías de ancho de banda mínimo. Por el contrario, la petición de comentarios (RFC) 2475 define el descarte como el "proceso de descartar paquetes según las reglas especificadas". El mecanismo de descarte del valor por defecto es la eliminación de cola, en la cual el interfaz cae los paquetes cuando la cola es llena. Un mecanismo de descarte alternativo es Detección temprana aleatoria (RED) y WRED de Cisco, que comienza a descartar paquetes de forma aleatoria antes de que la cola esté llena e intenta mantener un promedio uniforme de profundidad de la cola. WRED utiliza el valor de la Prioridad IP de los paquetes para tomar una decisión distinguida del descenso. Para obtener más información, consulte Detección temprana aleatoria y ponderada (WRED).
Q. ¿Cómo puedo supervisar la Detección temprana aleatoria y ponderada (WRED) y ver si realmente tiene un efecto?
A. WRED supervisa la profundidad promedio de la cola y comienza a descartar paquetes cuando el valor calculado supera el valor umbral mínimo. Ejecute el comando show policy-map interface y supervise el valor de profundidad media de la cola, como se muestra en el ejemplo siguiente:
Router# show policy interface s2/1 Serial2/1 output : p1 Class c1 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 20 (%) (pkts matched/bytes matched) 168174/41370804 (pkts discards/bytes discards/tail drops) 20438/5027748/0 mean queue depth: 39 Dscp Random drop Tail drop Minimum Maximum Mark (Prec) pkts/bytes pkts/bytes threshold threshold probability 0(0) 2362/581052 1996/491016 20 40 1/10 1 0/0 0/0 22 40 1/10 2 0/0 0/0 24 40 1/10 [output omitted]
Establecimiento de políticas y modelado
Q. ¿Cuál es la diferencia entre el establecimiento de políticas y modelado?
A. El siguiente diagrama ilustra la diferencia fundamental. El modelado del tráfico conserva los paquetes en exceso en una cola y luego programa el exceso para la transmisión posterior en incrementos de tiempo. El resultado del diseño del tráfico es una velocidad atenuada del paquete de salida. En cambio, la Vigilancia de tráfico propaga las explosiones. Cuando la velocidad del tráfico alcance la velocidad máxima configurada, el tráfico en exceso se suprime (o remarca). El resultado es una velocidad de salida que tiene la apariencia de un diente de sierra, con crestas y depresiones.
Para obtener más información, consulte Descripción general de modelado y políticas.
Q. ¿Qué es un token bucket y cómo funciona el algoritmo?
A. Una cubeta con ficha no posee una política de prioridad o descarte. Lo que sigue es un ejemplo de cómo la metáfora de cubeta con fichas funciona:
Los token ingresan al bloque de memoria a una velocidad determinada.
Cada token es permiso para que la fuente envíe algunos bits.
Para enviar un paquete, el regulador del tráfico debe ser capaz de retirar de la cubeta una cantidad de fichas equivalente al tamaño del paquete.
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 de un shaper) o el paquete se desecha o se marca abajo (en el caso de un policer).
La cubeta posee una capacidad especificada. Si la capacidad del compartimiento de memoria se encuentra completa, todos los símbolos nuevos que lleguen serán descartados y no estarán disponibles para 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. El token bucket permite la saturación, pero la limita.
Q. Con una regulación del tráfico como política basada en las clases, ¿qué significa Tamaño de ráfaga comprometida (Bc) y Tamaño de ráfaga en exceso (Be), y cómo debo seleccionar estos valores?
A. Un policer del tráfico no protege exceso de los paquetes y los transmite más adelante, al igual que el caso para un shaper. En lugar, el policer ejecuta un simple envía o no envía la directiva sin proteger. Durante los períodos de congestión, ya que no puede almacenar en búfer, lo mejor que puede hacer es descartar paquetes de forma menos agresiva configurando correctamente las ráfagas excesivas. Por lo tanto, es importante tener en cuenta que la regulación utiliza los valores de ráfaga normal y de ráfaga excesiva para garantizar que se cumpla con la tasa de información comprometida (CIR) configurada.
Los parámetros de ráfaga se modelan libremente en la regla genérica del buffering para el Routers. La regla recomienda el configurar de proteger igual al bitrato del Round-Trip Time para acomodar las ventanas excepcionales del Transmission Control Protocol (TCP) de todas las conexiones en tiempos de la congestión.
En la tabla siguiente, se describe la finalidad y la fórmula recomendada para los valores de ráfaga normal y extendida:
Parámetro de ráfaga Propósito Fórmula recomendada ráfaga normal
Implementa un token bucket estándar.
Fija el tamaño máximo del compartimiento simbólico (aunque los tokens pueden ser pedidos prestados si sea es mayor que A.C.).
Determina cómo es grande el compartimiento simbólico puede ser puesto que los tokens nuevamente de llegada se desechan y no están disponibles para los paquetes futuros si el compartimiento llena a la capacidad.
Nota: 1,5 segundos es el tiempo típico de ida y vuelta.
explosión extendida
Ejecuta un compartimiento simbólico con la capacidad de ráfaga extendida.
Se deshabilita estableciendo BC = Be.
Cuando BC es igual a Be, la regulación de tráfico no puede pedir prestados tokens y simplemente descarta el paquete cuando no hay suficientes tokens disponibles.
No todas las Plataformas utilizan o utilizan el mismo rango de los valores para un policer. Refiera al documento siguiente para aprender los valores admitidos para su plataforma específica:
Q. ¿De qué forma la velocidad de acceso comprometida (CAR) o las políticas basadas en las clases deciden si un paquete se ajusta o supera la velocidad de información confirmada (CIR)? El router está cayendo los paquetes y está señalando una tarifa excedida aunque la tarifa conformada es menos que el círculo configurado.
A. Un policer del tráfico utiliza la explosión normal y los valores de ráfaga extendidos para asegurar el círculo configurado se alcanzan. La determinación suficientemente de los valores altos de ráfaga es importante para asegurar la buena producción. Si los valores de ráfaga son demasiado bajos configurado, la tarifa alcanzada puede ser mucho más baja que la velocidad configurada. Castigar las ráfagas temporarias puede tener un efecto adverso fuerte en la producción del tráfico del Transmission Control Protocol (TCP). Con CAR, ejecute el comando show interface rate-limit para supervisar la ráfaga actual y determinar si el valor mostrado se acerca de modo uniforme a los valores de límite (BC) y límite extendido (Be).
rate-limit 256000 7500 7500 conform-action continue exceed-action drop rate-limit 512000 7500 7500 conform-action continue exceed-action drop router# show interfaces virtual-access 26 rate-limit Virtual-Access26 Cable Customers Input matches: all traffic params: 256000 BPS, 7500 limit, 7500 extended limit conformed 2248 packets, 257557 bytes; action: continue exceeded 35 packets, 22392 bytes; action: drop last packet: 156ms ago, current burst: 0 bytes last cleared 00:02:49 ago, conformed 12000 BPS, exceeded 1000 BPS Output matches: all traffic params: 512000 BPS, 7500 limit, 7500 extended limit conformed 3338 packets, 4115194 bytes; action: continue exceeded 565 packets, 797648 bytes; action: drop last packet: 188ms ago, current burst: 7392 bytes last cleared 00:02:49 ago, conformed 194000 BPS, exceeded 37000 BPSSi desea más información, consulte los siguientes documentos:
Q. ¿Son independientes entre sí el límite de cola y el de ráfaga?
A. Sí, la regulación para la ráfaga y el límite de cola son diferentes e independientes entre sí. Puede considerar la regulación como una puerta de entrada que permite un determinado número de paquetes (o bytes) y la cola como un contenedor de tamaño límite de cola que retiene los paquetes admitidos antes de la transmisión en la red. Lo ideal sería que el contenedor sea lo suficientemente grande como para retener una ráfaga de bytes/paquetes admitidos por la puerta de entrada (regulación).
Frame Relay de Calidad de servicio (QoS)
Q. ¿Qué valora debe yo seleccionar para la Velocidad de información comprometida (CIR), el committed burst (A.C.), la explosión del exceso (ser), y el CIR mínimo (MinCIR)?
A. El modelado del tráfico de Frame Relay, que se activa al ejecutar el comando frame-relay traffic-shaping, es compatible con varios parámetros configurables. Estos parámetros incluyen el CIR del Frame Relay, el mincir del Frame Relay, y el Frame Relay A.C. Refiera a los documentos siguientes para más información sobre la selección de estos valores y la comprensión de los comandos show relacionados:
Q. ¿La cola de prioridad en la interfaz principal Frame Relay funciona en Cisco IOS 12.1?
A. Las interfaces de Frame Relay admiten tanto los mecanismos de cola de interfaz como los mecanismos de cola por circuito virtual (VC). A partir del Cisco IOS 12.0(4)T, la cola de la interfaz utiliza el Primero en entrar, primero en salir (FIFO) o por la prioridad de interfaz que hace cola (PIPQ) solamente cuando usted configura el Control de tráfico de Frame Relay (FRTS). Por lo tanto, la configuración siguiente trabajará no más si usted actualiza al Cisco IOS 12.1.
interface Serial0/0 frame-relay traffic-shaping bandwidth 256 no ip address encapsulation frame-relay IETF priority-group 1 ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 136.238.91.214 255.255.255.252 no ip mroute-cache traffic-shape rate 128000 7936 7936 1000 traffic-shape adaptive 32000 frame-relay interface-dlci 200 IETFSi FRTS no se activa, usted puede aplicar un método para colocación en cola alternativo, tal como feria cargada basada clase haciendo cola (CBWFQ), a la interfaz principal, que está actuando como un solo tubo del ancho de banda. Además, a partir del Cisco IOS 12.1.1(T), usted puede activar el interfaz de la prioridad de los circuitos virtuales permanentes del Frame Relay (PVC) que hace cola (PIPQ) en una interfaz principal de Frame Relay. Usted puede definir el alto, el media, normal, o prioridad baja PVCs y publicar el comando frame-relay interface-queue priority en la interfaz principal, tal y como se muestra en del ejemplo siguiente:
interface Serial3/0 description framerelay main interface no ip address encapsulation frame-relay no ip mroute-cache frame-relay traffic-shaping frame-relay interface-queue priority interface Serial3/0.103 point-to-point description frame-relay subinterface ip address 1.1.1.1 255.255.255.252 frame-relay interface-dlci 103 class frameclass map-class frame-relay frameclass frame-relay adaptive-shaping becn frame-relay cir 60800 frame-relay BC 7600 frame-relay be 22800 frame-relay mincir 8000 service-policy output queueingpolicy frame-relay interface-queue priority low
Q. ¿El modelado del tráfico de Frame Relay (FRTS) funciona con Distributed Cisco Express Forwarding (dCEF) y con el Mecanismo de cola de espera equitativo y ponderado basado en clases distribuidas (dCBWFQ)?
A. A partir de Cisco IOS 12.1(5)T, solo la versión distribuida de las funciones de QoS se admite en los VIP de la serie 7500 de Cisco. Para activar el modelado de tráfico en las interfaces de Frame Relay, utilice el Control de tráfico distribuido (dTS). Si desea más información, consulte los siguientes documentos:
Calidad de Servicio (QoS) sobre el Asynchronous Transfer Mode (ATM)
Q. ¿De dónde aplico una política de servicio con la espera cargada basada clase de la feria (CBWFQ) y el low latency queueing (LLQ) en un interfaz del Asynchronous Transfer Mode (ATM)?
A. A partir de Cisco IOS 12.2, las interfaces de ATM admiten políticas de servicios en tres niveles o interfaces lógicas: interfaz principal, subinterfaz y circuito virtual permanente (PVC). Donde usted se aplica la directiva es una función de la característica del Calidad de Servicio (QoS) que usted está activando. Las políticas de colocación encola deben ser aplicadas por el virtual circuit (VC) puesto que el interfaz atmósfera vigila el nivel de congestión por VC, y mantienen las colas de administración del tráfico para exceso de los paquetes por VC. Si desea más información, consulte los siguientes documentos:
Q. ¿Qué bytes se cuentan por IP para la cola de Clase de servicio (COs) de modo de transferencia asíncrona (ATM, asynchronous transfer mode)?
A. Los comandos bandwidth and priority configurados en una política de servicio para activar el Mecanismo de cola de espera equitativo y ponderado basado en clases (CBWFQ) y el low latency queueing (LLQ), utilizan respectivamente un valor del Kbps que cuente los mismos bytes de tara que son contados por la salida del comando show interface. Específicamente, el protocolo logical link control/subnetwork access de las cuentas del sistema de colocación en cola de la capa 3 (LLC/SNAP). No cuenta el siguiente:
Remolque del capa 5 de adaptación del ATM (AAL5)
Relleno para lograr que la última celda sea un múltiplo par de 48 bytes.
Encabezado de celdas de cinco bytes
¿Qué bytes son contados por el IP ATM a clase de servicio (CoS) a la espera?
Q. ¿Cuántos circuitos virtuales (VCS) puede admitir una política de servicios de forma simultánea?
A. El siguiente documento proporciona instrucciones útiles sobre el número de VCS de modo de transferencia asíncrona (ATM) que se pueden admitir. Se han implementado de forma segura de 200 a 300 circuitos virtuales permanentes con velocidad de bits variable en tiempo no real (VBR-nrt):
También considere el siguiente:
Utilice un procesador potente capaz. Por ejemplo, un VIP4-80 proporciona un rendimiento muy superior al de un VIP2-50.
Cantidad de memoria disponible para paquetes. En el NPE-400, hasta el 32 MB (en un sistema con el 256 MB) se pone a un lado para el almacén intermedio del paquete. Para un NPE-200, hasta el 16 MB se pone a un lado para los almacenes intermedios del paquete en un sistema con el 128 MB.
Las configuraciones con por-VC el Weighted Random Early Detection (WRED) que actuaba simultáneamente en hasta 200 ATM PVC se han probado extensivamente. La cantidad de memoria del paquete en el VIP2-50 que se puede utilizar para por-VC las colas de administración del tráfico es finita. Por ejemplo, un VIP2-50 con 8-MB SRAM proporciona a 1085 almacenes intermedios del paquete disponibles para el IP a ATM a clase de servicio (CoS) por-VC la espera en qué WRED actúa. Si 100 ATM PVC fueran configurados y si todo el VCS experimentara congestión excesiva simultáneamente (como podía ser simulado en los entornos de prueba en donde la fuente de corriente regulada no-TCP sería utilizada), después por término medio cada PVC tendría valor de cerca de 10 paquetes del buffering, que puede ser demasiado corto para que WRED actúe con éxito. Los dispositivos VIP2-50 con SRAM grande se recomiendan así fuertemente en los diseños con un número alto de ATM PVC que ejecuta el WRED por cada VC y ése puede experimentar la congestión simultáneamente.
Cuanto mayor sea el número de circuitos virtuales permanentes activos configurados, se necesitará menos velocidad de celda sostenida (SCR) y, por lo tanto, más breve será la cola que la WRED necesita para funcionar en el circuito. Así, al igual que el caso al usar los perfiles del valor por defecto WRED de la característica de la fase 1 de la Clase de Servicio IP a ATM (Lechuga romana), configurando umbrales de caída de WRED más bajos cuando el WRED por cada VC se activa en un gran número de ATM PVC congestionado de poca velocidad minimizaría el riesgo de escasez de búfer en el VIP. La escasez de búfer en el VIP no da lugar a ningún malfuncionamiento. En el caso de la escasez de búfer en el VIP, la característica de la fase 1 IP ATM a clase de servicio (CoS) degrada simplemente al Primero en entrar, primero en salir (FIFO) la eliminación de cola durante el período de escasez de búfer (es decir, la misma directiva del descenso que ocurriría si el IP ATM a clase de servicio (CoS) a ofrecer no fue activado en este PVC).
Número máximo de VCS simultáneo que puede razonablemente ser utilizado.
Q. ¿Qué soportes del hardware del Asynchronous Transfer Mode (ATM) que la Clase de Servicio IP a ATM (Lechuga romana) ofrece incluyendo la clase basada cargaron la espera de la feria (CBWFQ) y el low latency queueing (LLQ)?
A. CoS IP a ATM se refiere a un conjunto de funciones que están activadas sobre una base de circuito virtual. Dado esta definición, el IP a ATM a clase de servicio (CoS) no se utiliza en el procesador de interfaz ATM (AIP), el PA-A1 o 4500 procesadores de red atmósfera. Este hardware ATM no admite cola por canal virtual como la definen PA-A3 y la mayoría de los módulos (excepto ATM-25). Si desea más información, consulte el siguiente documento:
Comprensión de la ayuda del hardware ATM para el IP a ATM a clase de servicio (CoS)
Por-VC Clase-basado, Weighted Fair Queuing en las plataformas basadas en RSP
Class-Based Weighted Fair Queuing por VC (por VC CBWFQ) en los routers Cisco 7200, 3600, y 2600
Envío a la cola por VC en el adaptador del puerto atmósfera PA-A3-8T1/E1IMA
Voz y calidad de servicio (QoS)
Q. ¿Cómo el Link Fragmentation and Interleaving (LFI) trabaja?
A. El tráfico interactivo, como Telnet y la Voz por IP, es propenso a la mayor latencia cuando la red procesa grandes paquetes, como Protocolos de transferencia de archivos (FTP) a través de una WAN. El retraso de paquetes para el tráfico interactivo es significativo cuando los paquetes FTP se hacen cola en links PÁLIDOS más lentos. Un método fue ideado para hacer fragmentos de paquetes más grandes, y hacer cola los paquetes más pequeños (de la Voz) entre los fragmentos de los paquetes más grandes de los paquetes (FTP). El Routers del Cisco IOS utiliza varios los mecanismos de fragmentación de la capa 2. Si desea más información, consulte los siguientes documentos:
Q. ¿Qué herramientas puedo utilizar para supervisar el rendimiento de la Voz por IP?
A. Actualmente, Cisco ofrece varias opciones para supervisar la calidad del servicio (QoS) en las redes que usan soluciones de Voz por IP de Cisco. Estas soluciones no miden la Calidad de voz usando la medida de calidad vocal perceptiva (PSQM) o algo de los nuevos algoritmos propuestos para la medición de calidad de voz. Para este fin, se dispone de herramientas de Agilent (HP) y NetIQ. Sin embargo, Cisco ofrece herramientas que dan una idea de la calidad de voz que está experimentando mediante la medición del retraso, la fluctuación y la pérdida de paquetes. Para obtener más información, consulte Uso del agente de garantía del servicio de Cisco y supervisión del rendimiento de Internetwork para administrar la calidad del servicio en redes de Voz por IP.
Q. %SW_MGR-3-CM_ERROR_FEATURE_CLASS: Error de la función de Connection Manager: Clase SSS: (QoS) - error de instalación, ignorar.
A. El error observado de instalación de la función es un comportamiento previsto cuando se aplica una configuración no válida a una plantilla. Indica que no se ha aplicado la política de servicio debido a un conflicto. En general, no se debe configurar el modelado del valor predeterminado de clase de la política secundaria en asignaciones de políticas jerárquicas; configúrelo en la política principal de la interfaz. Este mensaje, junto con la trazabilidad, aparece como una consecuencia.
Con las políticas basadas en la sesión, el modelado del valor predeterminado de clase debe realizarse solo en el nivel del circuito virtual permanente o la subinterfaz. No se admite el modelado en la interfaz física. Si la configuración se realiza en la interfaz física, la aparición de este mensaje de error es un comportamiento previsto.
En caso de LNS, otro motivo podría ser que la política de servicio podría aprovisionarse a través del servidor Radius cuando aparecen las sesiones. Ejecute el comando show tech para ver la configuración del servidor Radius y para ver cualquier política de servicio ilegal que se instale a través del servidor Radius cuando la sesión se reactiva o está intermitente.
Información Relacionada
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)