Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

Présentation de la compression des données

Matériel de compression Cisco

Mise en file d'attente et compression matérielle sophistiquées

Mise en file d'attente et compression logicielle

Compression d'en-tête RTP et QoS

Problèmes identifiés

Informations connexes

Introduction

Ce document passe en revue les problèmes connus liés à l'activation des fonctions logicielles Cisco IOS® de compression et de qualité de service (QoS) sur le même routeur.

La plate-forme logicielle Cisco IOS offre de nombreuses fonctionnalités qui optimisent les liaisons WAN (Wide-Area Network) pour réduire le goulot d'étranglement de la bande passante du WAN. La compression est une méthode d'optimisation efficace qui comprend deux types :

- Compression des données - Fournit à chaque extrémité un schéma de codage qui permet de supprimer des caractères des trames du côté émetteur de la liaison, puis de les remplacer correctement du côté récepteur. Comme les trames condensées occupent moins de bande passante, il est possible de transmettre des nombres plus importants par unité de temps. Exemples de schémas de compression de données : STAC, Microsoft Point-to-Point Compression (MPPC) et Frame Relay Forum 9 (FRF.9).

- Compression d'en-tête - Compresse un en-tête au niveau de différentes couches du modèle de référence OSI (Open System Interconnection). Exemples : compression d'en-tête TCP (Transmission Control Protocol), RTP compressé (cRTP) et IP/UDP (Internet Protocol/User Datagram Protocol) compressé.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Présentation de la compression des données

La fonction de base de la compression de données consiste à réduire la taille d’une trame de données transmise sur une liaison réseau. La réduction de la taille de la trame réduit le temps nécessaire à la transmission de la trame sur le réseau.

Les deux algorithmes de compression de données les plus couramment utilisés sur les périphériques interréseau sont Stacker et Predictor.

Les exemples de configuration suivants montrent deux façons d'activer la compression de charge utile sur une interface ou une sous-interface 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

Matériel de compression Cisco

La compression de données assistée par matériel atteint la même fonctionnalité globale que la compression de données basée sur logiciel, mais accélère les taux de compression en déchargeant ce calcul du processeur principal. En d'autres termes :

- Compression logicielle : la compression est mise en oeuvre dans le logiciel Cisco IOS installé sur le processeur principal du routeur.

- Compression matérielle : la compression est mise en oeuvre dans le matériel de compression installé dans un logement système. La compression matérielle supprime les responsabilités de compression et de décompression du processeur principal installé sur votre routeur.

Le tableau suivant répertorie le matériel de compression Cisco et les plates-formes prises en charge :

Matériel de compression

Plates-formes prises en charge

Notes

Adaptateurs de service SA-Comp/1 et SA-Comp/4 (CSA)

Routeurs de la gamme Cisco 7200 et processeur VIP2 de deuxième génération dans les routeurs des gammes Cisco 7000 et 7500

Prend en charge l’algorithme Stacker sur les interfaces série configurées avec l’encapsulation PPP (Point-to-Point Protocol) ou Frame Relay.

NM-COMPR

Routeurs de la gamme Cisco 3600

Prend en charge l'algorithme Stacker sur les liaisons PPP et les liaisons Frame Relay avec l'algorithme de compression FRF.9.

AIM-COMPR4

Routeurs de la gamme Cisco 3660 uniquement

Prend en charge les algorithmes LZS (Lempel-Ziv Standard) et MPPC.

La configuration de la compression sur une interface série à l'aide d'une commande telle que compress stac active automatiquement la compression matérielle si elle est disponible. Sinon, la compression logicielle est activée. Vous pouvez utiliser la commande compress stac software pour forcer l'utilisation de la compression logicielle.

Mise en file d'attente et compression matérielle sophistiquées

Cette section traite d'un problème résolu avec la fonctionnalité PQ (mise en file d'attente par priorité) et le matériel de compression Cisco. À l'origine, le matériel de compression déplaçait agressivement les paquets des PQ, supprimant ainsi les avantages de PQ. En d'autres termes, PQ fonctionnait correctement, mais la mise en file d'attente fonctionnellement déplacé vers les propres files d'attente du matériel de compression (holdq, hw ring et compQ), qui sont strictement premier entré, premier sorti (FIFO). Les symptômes de ce problème sont documentés dans l'ID de bogue Cisco CSCdp33759 (marqué comme un doublon de CSCdm91180).

La résolution modifie le pilote du matériel de compression. Plus précisément, elle limite le débit auquel le matériel de compression supprime les paquets en réduisant la taille des files d'attente matérielles en fonction de la bande passante de l'interface. Ce mécanisme de contre-pression garantit que les paquets restent dans les files d'attente sophistiquées au lieu d'être conservés dans les files d'attente du matériel de compression. Référez-vous aux ID de bogue suivants pour plus d'informations :

Note : Pour plus d'informations sur ces ID de bogue, utilisez la boîte à outils des bogues (clients enregistrés uniquement).

- CSCdm91180 : s'applique à l'encapsulation Frame Relay et à l'adaptateur de service de compression (CSA).

- CSCdp33759 (et CSCdr18251) : s'applique à l'encapsulation PPP et à la CSA.

- CSCdr18251 - S'applique à l'encapsulation PPP et à la compression de module d'interface asynchrone (AIM-COMPR).

Les files d'attente au niveau matériel de la compression Cisco 3660 sont visibles dans l'exemple de sortie suivant de la commande show pas caim stats. Si les files d'attente de compression matérielle stockent de nombreux paquets, un paquet retiré de la file d'attente PQ attend à l'extrémité arrière de cette file d'attente, et subit donc un retard.

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

Remarque : CSCdr86700 supprime les modifications mises en oeuvre dans CSCdm91180 des plates-formes ne prenant pas en charge un CSA.

En outre, lors du dépannage de ce problème, les problèmes d'extension de paquets avec de petits paquets (environ 4 octets) et des modèles répétitifs particuliers, tels que les requêtes ping Cisco avec un modèle de 0xABCDABCD, ont été résolus avec l'ID de bogue CSCdm11401. Les petits paquets sont moins susceptibles d'être liés à d'autres paquets dans le flux, et tenter de les compresser peut entraîner des paquets étendus ou provoquer des réinitialisations du dictionnaire. La cause principale est un problème avec la puce utilisée sur la CSA. L'ID de bogue Cisco CSCdp64837 résout ce problème en modifiant le code de compression FRF.9 pour éviter de compresser les paquets ayant moins de 60 octets de données utiles.

Mise en file d'attente et compression logicielle

Contrairement à la compression matérielle, la compression logicielle et la mise en file d’attente sophistiquée, y compris la mise en file d’attente personnalisée, prioritaire et pondérée, ne sont pas prises en charge sur les interfaces configurées avec l’encapsulation PPP. Cette limitation est documentée dans les ID de bogue CSCdj45401 et CSCdk86833.

La raison de cette limitation est que la compression PPP n'est pas sans état et maintient un historique de compression sur le flux de données pour optimiser les ratios de compression. Les paquets compressés doivent être conservés afin de maintenir l'historique de compression. Si les paquets sont compressés avant la mise en file d'attente, ils doivent être placés dans une seule file d'attente. Les placer dans différentes files d'attente, comme le font les files d'attente personnalisées et prioritaires, peut conduire à l'arrivée des paquets hors séquence, ce qui rompt la compression. Les solutions alternatives sont sous-optimales et n'ont pas été mises en oeuvre. Ces alternatives incluent la compression des paquets lorsqu'ils sont retirés de la file d'attente (inacceptable pour des raisons de performances), le maintien d'un historique de compression distinct pour chaque file d'attente (non pris en charge et impliquant une surcharge importante), et la réinitialisation de l'historique de compression pour chaque paquet (influence substantiellement les ratios de compression). Comme solution de contournement, vous pouvez configurer l'encapsulation HDLC (High-Level Data Link Control), mais cette configuration peut affecter les performances du système et n'est pas recommandée. Utilisez plutôt la compression matérielle.

Compression d'en-tête RTP et QoS

RFC 1889 spécifie le RTP, qui gère le transport de chemin audio pour la voix sur IP (VoIP). RTP fournit des services tels que le séquençage pour identifier les paquets perdus et les valeurs 32 bits pour identifier et distinguer plusieurs expéditeurs dans un flux de multidiffusion. Surtout, il ne fournit pas ou ne garantit pas la qualité de service.

Les paquets VoIP sont composés d'un ou plusieurs échantillons de codec vocal ou de trames encapsulés dans 40 octets d'en-têtes IP/UDP/RTP. 40 octets représente une surcharge relativement importante pour les charges utiles VoIP standard de 20 octets, en particulier sur les liaisons à faible débit. RFC 2508 spécifie RTP (cRTP) compressé, qui est conçu pour réduire les en-têtes IP/UDP/RTP à deux octets pour la plupart des paquets dans le cas où aucune somme de contrôle UDP n'est envoyée, ou à quatre octets avec des sommes de contrôle. L'algorithme de compression défini dans ce document s'appuie fortement sur la conception de la compression d'en-tête TCP/IP, comme décrit dans RFC 1144 .

RFC 2508 spécifie en fait deux formats de cRTP :

- RTP compressé (CR) - Utilisé lorsque les en-têtes IP, UDP et RTP restent cohérents. Les trois en-têtes sont compressés.

- UDP compressé (CU) - Utilisé en cas de modification importante de l'horodatage RTP ou lorsque le type de charge utile RTP change. Les en-têtes IP et UDP sont compressés, mais pas l'en-tête RTP.

La version 12.1(5)T de la plate-forme logicielle Cisco IOS a apporté plusieurs améliorations à la compression sur les circuits virtuels permanents (PVC) Frame Relay sur les routeurs des gammes Cisco 2600, 3600 et 7200. Ces améliorations sont les suivantes :

Avant la version 12.1(5)T de Cisco IOS

Cisco IOS versions 12.1(5)T et 12.2

Les méthodes de fragmentation de périphérie WAN à faible débit nécessaires pour garantir que la qualité de la voix ne fonctionne pas sur les interfaces avec compression matérielle. Ces méthodes de fragmentation, qui incluent MLPPP/LFI, FRF.11 Annexe C et FRF.12, fonctionnent avec la compression logicielle.

La fragmentation (FRF.12 ou LFI) est prise en charge avec la compression matérielle. En outre, les formats FRF.12 et FRF.11 de fragmentation de l'annexe C sont pris en charge avec la compression matérielle FRF.9 sur le même circuit virtuel permanent. Les paquets voix de la file d'attente prioritaire avec mise en file d'attente à faible latence (LLQ) contournent le moteur de compression FRF.9. Les paquets de données sont compressés.

Les compressions FRF.9 sont prises en charge uniquement sur les circuits virtuels permanents IETF-encap

La compression cRTP et FRF.9 sont prises en charge sur le même circuit virtuel permanent. La compression FRF.9 est prise en charge sur les circuits virtuels permanents configurés avec l'encapsulation Cisco et IETF (Internet Engineering Task Force).

cRTP est pris en charge sur les circuits virtuels permanents Frame Relay configurés avec l’encapsulation Cisco uniquement.

cRTP continue d'être pris en charge uniquement sur les circuits virtuels permanents encapsulés Cisco.

Problèmes identifiés

Le tableau suivant répertorie les problèmes connus liés aux fonctions QoS de cRTP et de Cisco IOS. Cette liste est exacte au moment de la publication. Reportez-vous également aux Notes de version de votre version du logiciel Cisco IOS pour plus d'informations.

ID de bogue

Description

CSCdv73543

Lorsqu'une stratégie QoS hiérarchique, à l'aide des commandes de l'interface de ligne de commande QoS modulaire, est appliquée à une interface de sortie et spécifie un régulateur à deux niveaux, le débit de trafic conforme peut être inférieur à ce qui était prévu. Le problème se produit lorsque l'action effectuée sur le paquet dans un niveau est différente de celle du second niveau. Par exemple, se conformer au premier niveau et dépasser au deuxième niveau. Voici un exemple de politique :
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

Des pertes de paquets inattendues peuvent être observées lors de l'utilisation de la mise en file d'attente à faible latence (LLQ) sur Frame Relay. Le problème est dû au fait que le système de mise en file d’attente ne prend pas en compte les gains de bande passante de cRTP.

CSCds43465

À l'origine, cRTP s'est produit après la mise en file d'attente. En conséquence, la mise en file d’attente (potentiellement) a vu un paquet beaucoup plus grand que ce qui était réellement transmis sur le câble. Ce comportement est modifié avec ce bogue. La mise en file d'attente prend désormais en compte les paquets compressés. Avec cette modification, vous pouvez configurer des instructions de bande passante avec CBWFQ en fonction des débits de données compressés.

Informations connexes

- Page d'assistance QoS

- Support technique - Cisco Systems