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 :

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 :

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.

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

Informations connexes

• Page d'assistance QoS
• Support technique - Cisco Systems