Qualité de service (QoS) : Mécanismes d'efficacité de liaison QoS

Présentation de la compression (cRTP inclus) et de Qos (Qualité de service)

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document passe en revue des problèmes connus avec activer les caractéristiques de logiciel de½ du¿Â du Cisco IOSï du compactage et du Qualité de service (QoS) sur le même routeur.

Le logiciel de Cisco IOS offre beaucoup de caractéristiques qui optimisent des liens de réseau d'étendu (WAN) pour soulager l'étranglement BLÊME de bande passante. Le compactage est une méthode efficace d'optimisation et inclut deux types :

  • Compression de données - Fournit à chaque extrémité une structure de codage qui permet des caractères à retirer des trames au côté émission du lien, et puis les remplace correctement au côté réception. Puisque les trames condensées occupent moins de bande passante, de plus grands nombres peuvent être transmis par unité de temps. Les exemples des modèles de compression de données incluent STAC, Microsoft Point-to-Point Compression (MPPC), et Forum Frame Relay 9 (FRF.9).

  • Compression d'en-tête - Compresse une en-tête à de diverses couches du modèle de référence ouvert de System Interconnection (OSI). Les exemples incluent la compression d'en-tête de Protocole TCP (Transmission Control Protocol), le RTP comprimé (cRTP), et l'Internet Protocol/User Datagram Protocol comprimés (IP/UDP).

Conditions préalables

Conditions requises

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

Composants utilisés

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. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). 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 utilisées dans ce document, reportez-vous aux Conventions relatives aux conseils techniques Cisco.

Aperçu de Compression de données

La fonction de base de la Compression de données est de réduire la taille d'une trame de données transmise au-dessus d'une liaison réseau. La réduction de la taille de la trame réduit la durée requise pour transmettre la trame à travers le réseau.

Les deux algorithmes de compression de données les plus utilisés généralement sur des périphériques d'Interconnexion de réseaux sont stacker et predictor.

Les configurations d'échantillon suivantes affichent deux manières d'activer la compression de capacité utile sur une interface ou une sous-interface de Relais de trames.

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 de Cisco

La Compression de données assistée par le matériel réalise la même fonctionnalité globale que la compression de données logicielle, mais accélère des débits de compactage en débarquant ceci de calcul de la CPU principale. En d'autres termes :

  • Compression logicielle - Le compactage est mis en application en logiciel de Cisco IOS installé dans le processeur principal du routeur.

  • Compression matérielle - Le compactage est mis en application dans le matériel de compression installé dans un emplacement de système. La compression matérielle enlève des responsabilités de compactage et de décompression du processeur principal installé dans votre routeur.

    Le tableau suivant présente le matériel de compression de Cisco et les Plateformes prises en charge :

Matériel de compression Plates-formes prises en charge Notes
Adaptateurs du service SA-Comp/1 et SA-Comp/4 (CSA) Routeurs de la gamme Cisco 7200 et la Versatile Interface Processor de seconde génération (VIP2) dans les Routeurs de gammes Cisco 7000 et 7500 Algorithme de stacker de supports au-dessus des interfaces série configurées avec le Protocole point à point (PPP) ou l'Encapsulation de relais de trames.
NM-COMPR Routeurs de la gamme Cisco 3600 Algorithme de stacker de supports au-dessus des liens de PPP et des liens de Relais de trames avec l'algorithme de compression de FRF.9.
AIM-COMPR4 Routeurs de gamme Cisco 3660 seulement Norme de Lempel-Ziv de supports (LZS) et algorithmes MPPC.

Configurer le compactage sur une interface série avec une commande telle que le stac de compresse active automatiquement la compression matérielle s'il est disponible. Autrement, la compression logicielle est activée. Vous pouvez utiliser la commande de logiciel de stac de compresse de forcer l'utilisation de la compression logicielle.

Queue et compression matérielle de fantaisie

Cette section discute une question résolue avec la configuration et le matériel de compression de queue de priorité héritée de Cisco (PQ). Le matériel de compression initialement a retiré des paquets de la file d'attente agressivement du PQs, retirant efficacement les avantages de PQ. En d'autres termes, PQ fonctionné correctement, mais s'alignant fonctionellement déplacé aux propres files d'attente du matériel de compression (holdq, sonnerie de hw et compQ), qui sont strictement le first-in, first-out (FIFO). Les symptômes de ce problème sont documentés dans l'ID de bogue Cisco CSCdp33759 (marqué comme doublon de CSCdm91180).

La résolution modifie le gestionnaire du matériel de compression. Spécifiquement, il étrangle le débit auquel le matériel de compression retire des paquets de la file d'attente en réduisant la taille des files d'attente de matériel basées sur la bande passante de l'interface. Ce mécanisme de contre-pression s'assure que les paquets restent dans les files d'attente de fantaisie au lieu d'être tenu dans les files d'attente du matériel de compression. Référez-vous au pour en savoir plus suivant d'id de bogue :

Remarque: Plus d'informations sur ces id de bogue peuvent être trouvées à l'aide du Bug Toolkit (clients enregistrés seulement).

  • CSCdm91180 - Applique à l'Encapsulation de relais de trames et à l'adaptateur de service de compression (CSA).

  • CSCdp33759 (et CSCdr18251) - S'applique à l'encapsulation PPP et au CSA.

  • CSCdr18251 - S'applique à l'encapsulation PPP et au module-compactage asynchrone d'interface (AIM-COMPR).

Les files d'attente de niveau matériel du compactage de Cisco 3660 peuvent être vues dans la sortie suivante témoin de la commande de stats de show pas caim. Si les files d'attente de compression matérielle enregistrent beaucoup de paquets, un paquet retiré de la file d'attente du PQ attend à la fin de cette file d'attente, et les expériences retardent ainsi.

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 enlève les changements mis en application de CSCdm91180 des Plateformes ne prenant en charge pas un CSA.

En outre, tout en dépannant ce problème, les questions de paquet-extension avec de petits paquets (environ 4 octets) et les modèles répétitifs particuliers, tels que Cisco cingle avec un modèle de 0xABCDABCD, ont été résolus avec l'ID CSCdm11401 de bogue. De petits paquets sont moins pour être liés à d'autres paquets dans le flot, et tenter de les compresser peut avoir comme conséquence les paquets développés, ou entraînez les réinitialisations du dictionnaire. La cause principale est un problème avec la puce utilisée sur le CSA. L'ID de bogue Cisco CSCdp64837 résout ce problème en changeant le code de compactage de FRF.9 pour éviter de compresser des paquets ayant moins de 60 octets de la charge utile.

Queue et compression logicielle de fantaisie

Contrairement à la compression matérielle, à la compression logicielle et à de fantaisie la queue, y compris la coutume, de la priorité, et de la mise en file d'attente pondérée, ne sont pas prises en charge sur des interfaces configurées avec l'encapsulation PPP. Cette limite est documentée dans les id CSCdj45401 et CSCdk86833 de bogue.

La raison pour la limite est que la compression PPP n'est pas sans état et met à jour un historique de la compression au-dessus du flux de données pour optimiser les taux de compression. Les paquets compressés doivent être gardés afin de mettre à jour l'historique de la compression. Si des paquets sont compressés avant la queue, ils doivent être mis dans une file d'attente simple. La mise de eux dans différentes files d'attente, comme coutume et file d'attente à priorité déterminée font, peuvent mener aux paquets arrivant hors de l'ordre, qui casse le compactage. Les solutions alternatives sont suboptimales et n'ont pas été mises en application. De telles solutions de rechange incluent compresser des paquets comme elles sont retirées de la file d'attente (inacceptable pour des raisons d'interprétation), mettant à jour un historique de la compression distinct pour chaque file d'attente (non vérifié et impliquant le temps système significatif), et remettant à l'état initial l'historique de la compression pour chaque paquet (sensiblement taux de compression d'incidences). Comme contournement, vous pouvez configurer l'encapsulation de High-Level Data Link Control (HDLC), mais cette configuration peut affecter la performance du système et n'est pas recommandée. Au lieu de cela, compression matérielle d'utilisation.

Compression d'en-tête RTP et QoS

Le RFC 1889leavingcisco.com spécifie le RTP, qui gère le transport par chemin audio pour la voix sur ip (VoIP). Le RTP fournit des services tels que le séquençage pour identifier les paquets perdus et les valeurs 32 bits pour l'identifier et distinguer de plusieurs expéditeurs dans un flot de Multidiffusion. D'une manière primordiale, il ne fournit pas ou assure QoS.

Des paquets VoIP se composent d'un ou plusieurs échantillons Codec ou trames de la parole encapsulés dans 40 octets d'en-têtes IP/UDP/RTP. 40 octets est relativement un grand nombre de temps système pour les charges utiles typiques 20-byte VoIP, en particulier au-dessus des liaisons à bas débit. RFC 2508leavingcisco.com spécifie le RTP comprimé (cRTP), qui est conçu pour ramener les en-têtes IP/UDP/RTP à deux octets pour la plupart des paquets dans le cas où aucune somme de contrôle d'UDP n'est envoyée, ou quatre octets avec des sommes de contrôle. L'algorithme de compression défini dans ce document dessine fortement sur la conception de la compression d'en-tête TCP/IP comme décrit dans RFC 1144leavingcisco.com .

RFC 2508 spécifie réellement deux formats de cRTP :

  • RTP comprimé (CR) - Utilisé quand les en-têtes IP, d'UDP, et de RTP restent cohérentes. Chacune des trois en-têtes est compressé.

  • UDP comprimé (CU) - Utilisé quand il y a un grand changement de l'horodateur de RTP ou quand le type de charge utile de RTP change. Les en-têtes IP et d'UDP sont compressées, mais l'en-tête de RTP n'est pas.

Le Logiciel Cisco IOS version 12.1(5)T a introduit plusieurs améliorations pour le compactage au-dessus des circuits virtuels permanents en relais de trame (PVCs) sur le Cisco 2600, 3600, et des Routeurs de gamme 7200. Ces améliorations concernent ce qui suit :

Avant Cisco IOS version 12.1(5)T Cisco IOS versions 12.1(5)T et 12.2
Les méthodes de fragmentation à basse vitesse de périphérie WAN requises pour assurer la Qualité vocale n'ont pas travaillé aux interfaces avec la compression matérielle. Ces méthodes de fragmentation, qui C incluent MLPPP/LFI, de FRF.11 annexe, et FRF.12, fonctionnent avec la compression logicielle. Fragmentation (FRF.12 ou Fonction Link Fragmentation and Interleaving (LFI)) sont pris en charge ainsi que la compression matérielle. En outre, la fragmentation d'annexe-C de FRF.12 et de FRF.11 sont prises en charge avec la compression matérielle de FRF.9 sur le même PVC. Paquets vocaux de la file d'attente prioritaire avec le contournement de queue de basse latence (LLQ) l'engine de compresseur de FRF.9. Des paquets de données sont compressés.
Des compactages de FRF.9 est pris en charge seulement sur l'IETF-encap PVCs le cRTP et le compactage de FRF.9 sont pris en charge sur le même PVC. Le compactage de FRF.9 est pris en charge sur PVCs a configuré avec l'encapsulation de Cisco et de l'Internet Engineering Task Force (IETF).
le cRTP est pris en charge sur le PVC en relais de trame configuré avec l'encapsulation de Cisco seulement. le cRTP continue à être pris en charge seulement sur PVCs Cisco-encapsulé.

Problèmes identifiés

Le tableau suivant présente des problèmes connus avec des configurations de QoS de cRTP et de Cisco IOS. Cette liste est précise au moment de l'édition. Référez-vous également les aux notes de mise à jour pour votre version de pour en savoir plus de logiciel de Cisco IOS.

ID de bogue Description
CSCdv73543 Quand une stratégie QoS hiérarchique, utilisant les commandes du QoS modulaire CLI, est appliquée à une interface sortante et spécifie un régulateur à deux niveaux, le débit de trafic conformé peut être moins que prévu. Le problème se pose quand la mesure prise sur le paquet dans un niveau est différente de celle au deuxième niveau. Par exemple, conformez-vous au premier niveau et dépassez au deuxième niveau. Une stratégie d'exemple est illustrée ci-dessous :
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 vues en utilisant la basse latence s'alignant (LLQ) au-dessus du Relais de trames. Le problème a été provoqué par par le système de mise en file d'attente ne prenant pas en considération les gains de bande passante du cRTP.
CSCds43465 Initialement, le cRTP s'est produit après la queue. Le résultat était que s'alignant (potentiellement) a vu un paquet beaucoup plus grand que ce qui a été transmis réellement sur le fil. Ce comportement est changé avec cette bogue. La queue maintenant considère des paquets compressés. Avec cette modification, vous pouvez configurer des instructions de bande passante avec CBWFQ basé sur des débits de données compressées.


Informations connexes


Document ID: 22308