Ce document fournit des exemples de configuration pour la configuration de la mise en file d'attente pondérée basée sur les classes (CBWFQ) sur une interface Frame Relay. CBWFQ est activé avec la commande bandwidth, telle que configurée dans une carte-politique avec les commandes de l'interface de ligne de commande QoS (Quality of Service Command Line Interface) modulaire.
Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.
Aucune condition préalable spécifique n'est requise pour ce document.
CBWFQ est pris en charge à partir des versions suivantes du logiciel Cisco IOS®, selon la plate-forme :
Gamme Cisco 7500 avec processeurs VIP (Versatile Interface Processors) (CBWFQ distribué) - 12.1(5)T
Gammes Cisco 7200, 2600/3600 et autres plates-formes non 7500 - 12.1(2)T
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.
La mise en file d'attente est généralement utilisée dans le contexte du formatage, ce qui réduit le débit de sortie et entraîne ainsi un encombrement. Utilisez CBWFQ avec les mécanismes et commandes de mise en forme suivants, selon votre plate-forme.
Gamme Cisco 7500 | Plates-formes Cisco 7200, 3600, 2600 et autres plates-formes non VIP | |
---|---|---|
Mécanismes de mise en forme pris en charge | Formatage du trafic distribué (DTS) | Formatage du trafic Frame Relay (Frame Relay TS) |
Commande Configuration | shape, commande dans une policy-map | formatage de trafic Frame Relay sur une interface principale, les commandes de configuration map-class pour spécifier les paramètres de formatage |
Nécessite Cisco Express Forwarding distribué (dCEF) | Oui (vérifier à l'aide de la commande show cef linecard) | Non |
Cisco IOS 12.1(2)T introduit la prise en charge de CBWFQ sur les plates-formes 7200, 2600/3600 et autres processeurs de commutation non routés (RSP). (Pour plus d'informations, reportez-vous à LLQ (Low Latency Queueing) Over Frame Relay.) Sur ces plates-formes, la CBWFQ sur les interfaces Frame Relay est toujours dans le contexte de la technologie Frame Relay TS. Utilisez la commande frame-relay traffic-formatage pour activer le TS Frame Relay. Vous ne pouvez pas utiliser CBWFQ avec GTS (Generic Traffic Shaping) et la commande shape sur ces plates-formes. Un exemple de configuration est fourni ci-dessous.
Exemple de configuration de CBWFQ sur les gammes Cisco 7200, 3600 et 2600 |
---|
policy-map mypolicy class voice priority 16 class priority-data bandwidth 16 !--- Create a policy-map and apply the bandwidth !--- command to a class. ! int s0/0 encapsulation frame-relay IETF load-interval 30 frame-relay traffic-shaping !--- Enable Frame Relay TS. ! interface Serial0/0.1 point-to-point frame-relay interface-dlci 100 class frclass !--- Apply the map-class to the Frame Relay PVC. ! map-class frame-relay frclass service-policy output mypolicy frame-relay cir 64000 frame-relay bc 640 !--- Apply the service policy inside the map-class. |
Remarque : Si vous activez une stratégie de service directement sur une interface principale et non dans une commande map-class, vous ne pouvez pas non plus appliquer le service de terminal Frame Relay directement à l'interface. Il est important de noter que les mécanismes de mise en file d’attente s’appliquent ensuite à une seule file d’attente d’interface de grande taille plutôt qu’aux files d’attente de circuit virtuel (VC) par circuit virtuel
Dans la gamme Cisco 7200, à partir du logiciel Cisco IOS version 12.0(26)S et ultérieure, il n'est plus possible de configurer une stratégie de service de sortie dans une commande frame-relay map-class. À la place, la configuration du Cisco 7500 doit être appliquée comme expliqué dans la section suivante. Une carte de stratégie hiérarchique doit être configurée avec mise en forme dans une stratégie parent et mise en file d'attente dans une stratégie enfant. La stratégie parent doit ensuite être associée à la principale ou à la sous-interface. Si vous essayez de configurer une sortie de stratégie de service dans la commande map-class frame-relay, le message d'erreur suivant s'affiche :
c7200(config)#map-class frame-relay stef c7200(config-map-class)#frame-relay cir 64000 c7200(config-map-class)#service-policy output aan Frame relay output service policy is not supported
Depuis Cisco IOS 12.1(5)T, les stratégies QoS doivent être exécutées en mode distribué sur le VIP ; car la QoS basée sur RSP n'est plus prise en charge. Vous devez donc utiliser la commande shape et d'autres commandes de l'interface de ligne de commande QoS modulaire pour implémenter DTS pour les interfaces Frame Relay sur les VIP de la gamme Cisco 7500. DTS combine GTS et Frame Relay TS. Un exemple de configuration est fourni dans Configuration de la mise en forme du trafic distribué et ci-dessous.
Exemple de configuration de DTS avec une politique hiérarchique |
---|
ip cef distributed ! class-map 1 match < > !--- Define match-on criteria. class-map 2 match < > !--- Define match-on criteria. ! policy-map CBWFQ class 1 bandwidth < > !-- Define value in kbps or percent. class 2 priority < > !--- Define value in kbps or percent. ! Policy-map SHAPE class class-default shape average service-policy CBWFQ ! int s0/0/0 encapsulation frame-relay ip route-cache distributed ! int s0/0/0.1 point-to-point ip address a.b.c.d frame-relay interface-dlci xxx class cisco ! map-class frame-relay cisco service-policy output SHAPE |
Lors de la configuration de CBWFQ, vous utilisez les commandes de la CLI QoS modulaire pour créer une carte de stratégie de trafic avec plusieurs classes de trafic et une ou plusieurs fonctions QoS. Dans les versions actuelles du logiciel Cisco IOS, les interfaces Frame Relay prennent en charge l'application d'une carte de stratégie avec la commande service-policy aux interfaces, sous-interfaces et circuits virtuels. Seules les combinaisons correctes de politiques sont désormais prises en charge. Le tableau suivant décrit spécifiquement où vous pouvez appliquer une stratégie QoS avec le formatage du trafic.
Gamme Cisco 7500 | Plates-formes Cisco 7200, 2600/3600 et autres | |
---|---|---|
Interface principale | Configurer une stratégie de service sur l'interface principale | Pris en charge uniquement si le service de terminal Frame Relay n’est pas activé et que les mécanismes de mise en file d’attente s’appliquent à un canal d’interface unique. |
Sous-interface | Configurez une stratégie de service sur la sous-interface. | Configurez une stratégie de service dans une classe de mappage Frame Relay et activez la mise en file d'attente par circuit virtuel à l'aide de la commande frame-relay traffic-formatage. Vous pouvez appliquer la classe map à la sous-interface. |
Niveau VC | Configurez une stratégie de service dans une classe de mappage Frame Relay et activez la mise en file d'attente par circuit virtuel à l'aide de la commande frame-relay traffic-formatage. Vous pouvez appliquer la classe de mappage au circuit virtuel. |
Lors de la configuration de CBWFQ sur des interfaces Frame Relay, notez les mises en garde suivantes :
Après le rechargement d'un routeur, les compteurs de correspondance de paquets d'une stratégie de service ne peuvent pas s'incrémenter lorsque la stratégie est appliquée à l'interface principale. Ce problème est résolu en s'assurant que les indicateurs de classification WFQ (Weighted Fair Queueing) sont copiés de l'interface principale vers les sous-interfaces.
La configuration simultanée de LLQ et de Frame Relay TS au niveau de l'interface physique n'est pas prise en charge. Le routeur supprime la stratégie de service de la configuration en cours après un rechargement du routeur. La stratégie de service doit être associée à la classe de mappage lorsque le service de terminal Frame Relay est activé sur l'interface. La tentative de configuration de cette combinaison génère le message d'erreur CBWFQ : Non pris en charge sur cette interface.
Lorsqu'une stratégie de service avec CBWFQ est appliquée directement à une interface principale Frame Relay (par exemple, mise en file d'attente non par circuit virtuel), la stratégie peut être supprimée après un rechargement du routeur si des instructions de bande passante sont configurées sur une sous-interface et une interface principale. Le routeur peut signaler des messages de journal similaires à ceux-ci :
CBWFQ: Not enough available bandwidth for all classes Available 44 (kbps) Needed 1 00 (kbps) CBWFQ: Removing service policy on Serial1/0
Ce problème est résolu en modifiant le comportement de CBWFQ pour ignorer les notifications lorsque la bande passante de la sous-interface est modifiée, car CBWFQ peut être configuré en dehors d'une classe de mappage Frame Relay uniquement au niveau de l'interface principale. Comme solution de contournement, supprimez la commande bandwidth de la sous-interface. Si vous utilisez la bande passante sur la sous-interface pour influencer la métrique de routage, utilisez une autre méthode comme le coût, comme dans OSPF (Open Shortest Path First) ou le délai, comme dans EIGRP (Enhanced Interior Gateway Routing Protocol).
Lorsque les commandes bandwidth et priority calculent la quantité totale de bande passante disponible sur une entité, les directives suivantes sont invoquées lorsque l'entité est un circuit virtuel permanent Frame Relay (PVC) en forme :
Si un débit minimum de données garanti acceptable (minCIR) n'est pas configuré, le CIR est divisé par deux.
Si un minCIR est configuré, le paramétrage de minCIR est utilisé dans le calcul.
La bande passante complète du débit ci-dessus peut être allouée aux classes de bande passante et prioritaires. Ainsi, la commande max-reservée-bandwidth n'est pas prise en charge sur les circuits virtuels permanents Frame Relay, mais vous devez veiller à ce que la quantité de bande passante configurée soit suffisamment grande pour prendre également en charge la surcharge de couche 2 (L2). Pour plus d'informations, référez-vous à Quels octets sont comptés par la mise en file d'attente CoS IP à ATM ?.
Évitez de définir le débit de données garanti (CIR) ou le débit minimal garanti (minCIR) au débit d'accès. Sinon, il se peut que des files d'attente de sortie se développent et provoquent de gros retards dans les classes CBWFQ. La raison en est que le taux de forme ne prend pas en compte les octets de surcharge des champs indicateur et CRC (Cyclic Redundancy Check), de sorte que le formatage au taux de ligne est en fait en surabonnement et provoquera un encombrement de l'interface. Il n'y a vraiment aucune raison de se former au taux d'accès. Vous devez toujours avoir une forme de trafic égale à 95 % du débit d'accès ou, plus généralement, le débit en forme d'agrégat doit toujours être inférieur de 95 % au débit d'accès.
Lorsque FRF.12 est configuré, la taille de la file d'attente de sortie augmente pour prendre en charge le même nombre d'octets qui sont maintenant fragmentés. En d'autres termes, vous passez d'une file d'attente de paquets à une file d'attente de fragments.
WFQ par VC est inclus dans le logiciel Cisco IOS version 12.0(7)T.
CBWFQ avec GTS est inclus dans le logiciel Cisco IOS version 12.1(2)T.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
10-Aug-2005 |
Première publication |