Este documento examina los problemas conocidos al habilitar las funciones de Cisco IOS® Software de compresión y de Calidad de Servicio (QoS) en el mismo router.
El software Cisco IOS ofrece muchas funciones que optimizan los enlaces de red de área extensa (WAN) para aliviar los cuellos de botella del ancho de banda de la WAN. La compresión es un método de optimización eficaz e incluye dos tipos:
Compresión de datos: proporciona a cada extremo un esquema de codificación que permite quitar caracteres de las tramas en el lado de envío del link y, a continuación, los reemplaza correctamente en el lado de recepción. Dado que las tramas condensadas ocupan menos ancho de banda, se pueden transmitir mayores números por unidad de tiempo. Algunos ejemplos de esquemas de compresión de datos son STAC, Microsoft Point-to-Point Compression (MPPC) y Frame Relay Forum 9 (FRF.9).
Compresión de encabezados: comprime un encabezado en varias capas del modelo de referencia de interconexión de sistemas abiertos (OSI). Algunos ejemplos son la compresión de encabezados de protocolo de control de transmisión (TCP), RTP comprimido (cRTP) y protocolo de Internet comprimido/protocolo de datagramas de usuario (IP/UDP).
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.
Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.
La función básica de la compresión de datos es reducir el tamaño de una trama de datos transmitida a través de un link de red. La reducción del tamaño de la trama reduce el tiempo necesario para transmitir la trama a través de la red.
Los dos algoritmos de compresión de datos más utilizados en los dispositivos de conexión entre redes son Stacker y Predictor.
Las siguientes configuraciones de ejemplo muestran dos maneras de habilitar la compresión de carga útil en una interfaz o subinterfaz Frame Relay.
interface Serial0/5 ip address 10.0.0.1 255.255.255.0 no ip directed-broadcast encapsulation frame-relay IETF clockrate 1300000 frame-relay map ip 10.0.0.2 16 broadcast IETF payload-compression FRF9 stac interface Serial0/0.105 point-to-point ip address 192.168.162.1 255.255.255.0 no ip directed-broadcast frame-relay interface-dlci 105 IETF class 128k frame-relay payload-compression FRF9 stac
La compresión de datos asistida por hardware logra la misma funcionalidad general que la compresión de datos basada en software, pero acelera las tasas de compresión descargando esto computativamente de la CPU principal. En otras palabras:
Compresión de Software: la Compresión se implementa en el software Cisco IOS instalado en el procesador principal del router.
Compresión de hardware: la compresión se implementa en el hardware de compresión instalado en una ranura del sistema. La compresión de hardware elimina las responsabilidades de compresión y descompresión del procesador principal instalado en el router.
La siguiente tabla enumera el hardware de compresión de Cisco y las plataformas soportadas:
Hardware de compresión | Plataformas Soportadas | Notas |
---|---|---|
Adaptadores de servicio (CSA) SA-Comp/1 y SA-Comp/4 | Cisco 7200 Series Routers y el Procesador de interfaz versátil de segunda generación (VIP2) en los Cisco 7000 y 7500 Series Routers | Admite el algoritmo Stacker en interfaces seriales configuradas con el protocolo punto a punto (PPP) o la encapsulación de Frame Relay. |
NM-COMPR | Cisco 3600 Series Routers | Admite el algoritmo Stacker sobre links PPP y links Frame Relay con el algoritmo de compresión FRF.9. |
AIM-COMPR4 | Solamente Cisco 3660 Series Routers | Admite algoritmos Lempel-Ziv Standard (LZS) y MPPC. |
La configuración de la compresión en una interfaz serial con un comando como compress stac habilita automáticamente la compresión de hardware si está disponible. De lo contrario, se habilita la compresión de software. Puede utilizar el comando compress stac software para forzar el uso de la compresión de software.
Esta sección trata un problema resuelto con la función de almacenamiento en cola de prioridad (PQ) heredada de Cisco y el hardware de compresión. El hardware de compresión originalmente quitó la cola de paquetes agresivamente de las PQ, eliminando de manera efectiva las ventajas de PQ. En otras palabras, PQ funcionó correctamente, pero la colocación en cola se trasladó funcionalmente a las propias colas del hardware de compresión (holdq, hw ring y compQ), que son estrictamente el primero en entrar, el primero en salir (FIFO). Los síntomas de este problema se documentan en el ID de bug de Cisco CSCdp33759 (marcado como un duplicado de CSCdm91180).
La resolución modifica el controlador del hardware de compresión. Específicamente, regula la velocidad a la que el hardware de compresión descoloca los paquetes mediante la reducción del tamaño de las colas de hardware según el ancho de banda de la interfaz. Este mecanismo de contrapresión asegura que los paquetes permanezcan en las colas de lujo en lugar de estar retenidos en las colas del hardware de compresión. Consulte los siguientes ID de bug para obtener más información:
Nota: Se puede encontrar más información sobre estos ID de bug usando el Bug Toolkit (sólo clientes registrados) .
CSCdm91180: se aplica a la encapsulación Frame Relay y al adaptador de servicio de compresión (CSA).
CSCdp33759 (y CSCdr18251): se aplica a la encapsulación PPP y al CSA.
CSCdr18251: se aplica a la encapsulación PPP y a la compresión de módulos de interfaz asíncrona (AIM-COMPR).
Las colas de nivel de hardware de la compresión Cisco 3660 se pueden ver en el siguiente ejemplo de salida del comando show pas caim stats. Si las colas de compresión de hardware están almacenando muchos paquetes, un paquete quitado de la cola de espera en el extremo posterior de esta cola y, por lo tanto, experimenta un retraso.
Router> show pas caim stats 0 CompressionAim0 ds:0x80F56A44 idb:0x80F50DB8 422074 uncomp paks in --> 422076 comp paks out 422071 comp paks in --> 422075 uncomp paks out 633912308 uncomp bytes in --> 22791798 comp bytes out 27433911 comp bytes in --> 633911762 uncomp bytes out 974 uncomp paks/sec in --> 974 comp paks/sec out 974 comp paks/sec in --> 974 uncomp paks/sec out 11739116 uncomp bits/sec in --> 422070 comp bits/sec out 508035 comp bits/sec in --> 11739106 uncomp bits/sec out 433 seconds since last clear holdq: 0 hw_enable: 1 src_limited: 0 num cnxts: 4 no data: 0 drops: 0 nobuffers: 0 enc adj errs: 0 fallbacks: 0 no Replace: 0 num seq errs: 0 num desc errs: 0 cmds complete: 844151 Bad reqs: 0 Dead cnxts: 0 No Paks: 0 enq errs: 0 rx pkt drops: 0 tx pkt drops: 0 >dequeues: 0 requeues: 0 drops disabled: 0 clears: 0 ints: 844314 purges: 0 no cnxts: 0 bad algos: 0 no crams: 0 bad paks: 0 # opens: 0 # closes: 0 # hangs: 0
Nota: CSCdr86700 elimina los cambios implementados en CSCdm91180 de las plataformas que no soportan un CSA.
Además, mientras se solucionaba este problema, los problemas de expansión de paquetes con paquetes pequeños (alrededor de 4 bytes) y patrones repetitivos particulares, como los pings de Cisco con un patrón de 0xABCDABCD, se resolvieron con el ID de bug CSCdm11401. Es menos probable que los paquetes pequeños estén relacionados con otros paquetes en el flujo, y el intento de comprimirlos puede dar lugar a paquetes expandidos o causar reinicios del diccionario. La causa raíz es un problema con el chip utilizado en el CSA. El ID de bug de Cisco CSCdp64837 resuelve este problema cambiando el código de compresión FRF.9 para evitar comprimir los paquetes con menos de 60 bytes de carga útil.
A diferencia de la compresión por hardware, la compresión por software y la colocación en cola elaborada, incluidas las colas personalizadas, prioritarias y ponderadas equitativas, no se soportan en las interfaces configuradas con encapsulación PPP. Esta limitación se documenta en los ID de bug CSCdj45401 y CSCdk86833.
La razón de la limitación es que la compresión PPP no es sin estado y mantiene un historial de compresión sobre el flujo de datos para optimizar los ratios de compresión. Los paquetes comprimidos deben mantenerse para mantener el historial de compresión. Si los paquetes se comprimen antes de la colocación en cola, deben colocarse en una sola cola. Ponerlos en diferentes colas, como hacen las colas personalizadas y de prioridad, puede llevar a que los paquetes lleguen fuera de secuencia, lo que interrumpe la compresión. Las soluciones alternativas no son óptimas y no se han implementado. Estas alternativas incluyen la compresión de paquetes a medida que se quitan la cola (inaceptable por razones de rendimiento), el mantenimiento de un historial de compresión separado para cada cola (no admitido y que implica una sobrecarga significativa) y el restablecimiento del historial de compresión para cada paquete (afecta sustancialmente a los ratios de compresión). Como solución alternativa, puede configurar la encapsulación de control de enlace de datos (HDLC) de alto nivel, pero esta configuración puede afectar al rendimiento del sistema y no se recomienda. En su lugar, utilice la compresión de hardware.
RFC 1889 especifica el RTP, que administra el transporte de la ruta de audio para Voz sobre IP (VoIP). RTP proporciona servicios como la secuenciación para identificar los paquetes perdidos y los valores de 32 bits para identificar y distinguir entre varios remitentes en un flujo multicast. Es importante destacar que no proporciona ni garantiza la calidad de servicio.
Los paquetes VoIP se componen de una o más muestras de códec de voz o tramas encapsuladas en 40 bytes de encabezados IP/UDP/RTP. 40 bytes es una cantidad relativamente grande de sobrecarga para las cargas VoIP de 20 bytes típicas, especialmente en links de baja velocidad. RFC 2508 especifica RTP comprimido (cRTP), que está diseñado para reducir los encabezados IP/UDP/RTP a dos bytes para la mayoría de los paquetes en el caso de que no se envíen sumas de comprobación UDP, o cuatro bytes con sumas de comprobación. El algoritmo de compresión definido en este documento se basa en gran medida en el diseño de la compresión del encabezado TCP/IP como se describe en RFC 1144 .
RFC 2508 en realidad especifica dos formatos de cRTP:
RTP comprimido (CR): se utiliza cuando los encabezados IP, UDP y RTP permanecen consistentes. Los tres encabezados están comprimidos.
UDP comprimido (CU): se utiliza cuando hay un gran cambio en la marca de tiempo RTP o cuando cambia el tipo de carga útil RTP. Los encabezados IP y UDP están comprimidos, pero el encabezado RTP no lo está.
La versión 12.1(5)T del software del IOS de Cisco introdujo varias mejoras para la compresión sobre los circuitos virtuales permanentes (PVC) de Frame Relay en los routers de las series 2600, 3600 y 7200 de Cisco. Estas mejoras incluyen lo siguiente:
Antes de Cisco IOS Release 12.1(5)T | Cisco IOS versiones 12.1(5)T y 12.2 |
---|---|
Los métodos de fragmentación de extremo de la WAN de baja velocidad necesarios para garantizar la calidad de voz no funcionaban en las interfaces con compresión de hardware. Estos métodos de fragmentación, que incluyen MLPPP/LFI, FRF.11 Annex C y FRF.12, funcionan con compresión basada en software. | La fragmentación (FRF.12 o la fragmentación y entrelazado de enlaces (LFI)) se admiten junto con la compresión de hardware. Además, la fragmentación FRF.12 y FRF.11 Annex-C se soportan con compresión de hardware FRF.9 en el mismo PVC. Los paquetes de voz de la cola de prioridad con cola de baja latencia (LLQ) eluden el motor del compresor FRF.9. Los paquetes de datos se comprimen. |
Las compresión FRF.9 se soportan solamente en PVC IETF-encap | La compresión cRTP y FRF.9 se soportan en el mismo PVC. La compresión FRF.9 es compatible con los PVC configurados con la encapsulación de Cisco e Internet Engineering Task Force (IETF). |
cRTP se soporta en PVC de Frame Relay configurados solamente con encapsulación de Cisco. | cRTP continúa siendo soportado solamente en los PVC encapsulados por Cisco. |
La siguiente tabla enumera los problemas conocidos con las funciones de cRTP y Cisco IOS QoS. Esta lista es exacta en el momento de la publicación. Consulte también las Release Notes para su versión del software Cisco IOS para obtener más información.
ID de la falla | Descripción |
---|---|
CSCdv73543 | Cuando una política de QoS jerárquica, utilizando los comandos de la CLI de QoS modular, se aplica a una interfaz saliente y especifica un regulador de tráfico de dos niveles, la velocidad de tráfico conformado puede ser inferior a la esperada. El problema ocurre cuando la acción tomada en el paquete en un nivel es diferente de la que se realiza en el segundo nivel. Por ejemplo, se ajustan en el primer nivel y superan en el segundo. A continuación se muestra un ejemplo de política: policy-map test-policer class class-default police 10000 1500 1500 conform-action transmit exceed-action transmit service-policy inner-police ! policy-map inner-police class prec5 police 20000 1500 1500 conform-action transmit exceed-action transmit |
CSCdt52094 | Se pueden ver caídas de paquetes inesperadas cuando se utiliza la cola de baja latencia (LLQ) sobre Frame Relay. El problema fue causado por que el sistema de colocación en cola no tomó en cuenta las ganancias de ancho de banda de cRTP. |
CSCds43465 | Originalmente, cRTP se produjo después de la colocación en cola. El resultado fue que la colocación en cola (potencialmente) vio un paquete mucho más grande de lo que se transmitió realmente en el cable. Este comportamiento se cambia con este error. En la cola ahora se consideran los paquetes comprimidos. Con este cambio, puede configurar las sentencias de ancho de banda con CBWFQ basándose en las velocidades de datos comprimidas. |