La commande service-policy applique normalement une carte de stratégie configurée avec les commandes de l'interface de ligne de commande QoS modulaire (MQC) à une interface principale, une sous-interface ou un circuit virtuel. Vous pouvez également appliquer cette commande à une interface de modèle virtuel, à une interface multiliaison et à une interface de numérotation configurée avec encapsulation PPP (protocole point à point) et PPP multiliaison (MLPPP). Ces interfaces aboutissent à une interface d'accès virtuel, où la mise en file d'attente fonctionne. Ce document fournit une référence unique pour comprendre les configurations recommandées et les mises en garde associées à l'application de la file d'attente CBWFQ (Weighted Fair Queuing) basée sur les classes et de la file d'attente LLQ (Low Latency Queuing) aux interfaces de bundle MLPPP et aux interfaces de numérotation.
Aucune condition préalable spécifique n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
RFC 1990 définit le protocole PPP multiliaison, qui combine une ou plusieurs interfaces physiques dans une interface virtuelle « bundle ». La bande passante de l'interface de groupement est égale à la somme de la bande passante des liaisons de composant. Ainsi, l'interface du bundle a une valeur de bande passante maximale qui varie instantanément dans le temps.
À l'origine, les commandes bandwidth et priority ne prenaient en charge qu'une valeur absolue en kbits/s. Si vous avez appliqué une stratégie de service avec CBWFQ et LLQ à une interface de bundle et que la première interface active ne prenait pas en charge la valeur kbits/s absolue, le contrôle d'admission de la stratégie de service a échoué. Le routeur a supprimé la stratégie de service et a imprimé des messages d'erreur similaires à ce résultat :
May 18 17:32:34.766 MEST: CBWFQ: Not enough available bandwidth for all classes Available 48 (kbps) Needed 96 (kbps) May 18 17:32:34.766 MEST: CBWFQ: Removing service policy on Dialer100
Depuis la version 12.2T du logiciel Cisco IOS®, le routeur tente maintenant de réappliquer la stratégie lorsqu'il détecte qu'une interface supplémentaire (par exemple un deuxième canal B BRI) est ajoutée à l'offre groupée. Une approche supérieure consiste à configurer les commandes priority et bandwidth en pourcentage de la bande passante disponible. L’utilisation d’un pourcentage configure le routeur pour attribuer une quantité relative de bande passante qui s’ajuste lorsque l’ensemble contient une ou plusieurs liaisons membres. Le logiciel Cisco IOS Version 12.2(2)T a introduit la prise en charge de la commande priority pourcentage sur les routeurs de la gamme Cisco 7500 et d'autres plates-formes. Pour plus d'informations, référez-vous à Mise en file d'attente à faible latence avec prise en charge du pourcentage de priorité.
Le routage à établissement de connexion à la demande (DDR) peut être configuré de deux manières :
DDR hérité : applique les paramètres de numérotation et de protocole directement à l'interface physique.
Profils de numérotation : applique les paramètres de numérotation et de protocole de manière dynamique à une interface de numérotation, qui à son tour est liée aux interfaces physiques. Par exemple, une interface de numérotation inclut une ou plusieurs chaînes de numérotation pour atteindre un site distant, le type d'authentification PPP et MLPPP.
Le DDR traditionnel prenait initialement en charge la mise en file d'attente FIFO (First In, First Out) uniquement lorsqu'une interface série ou RNIS a été configurée avec MLPPP. Cette restriction s'appliquait même lorsque les deux extrémités de la connexion n'ont pas négocié MLPPP et utilisaient l'interface physique comme interface non groupée qui exécute l'encapsulation PPP. La mise en file d'attente pondérée traditionnelle (WFQ) via la commande fair-queue est désormais prise en charge.
Si vous choisissez de configurer des profils de numérotation, l'interface de numérotation et les interfaces physiques sous-jacentes prennent en charge la commande service-policy. Si vous appliquez une stratégie sur l'interface physique, émettez la commande show policy-map interface serial ou la commande show policy-map interface bri 0/0:1 (et bri0/0:2) pour confirmer la configuration. Le canal D, identifié dans IOS comme BRI0/0, prend en charge la signalisation et non le trafic de données. Si vous appliquez une stratégie à l'interface de numérotation, exécutez la commande show queueing interface dial <0-255> pour confirmer la configuration.
Les versions 12.2(4) et 12.2(4)T du logiciel Cisco IOS ont introduit la prise en charge des politiques de service basées sur la file d'attente sur les interfaces d'accès virtuel créées à partir d'une interface de numérotation configurée avec MLPPP. Dans les versions précédentes, les paramètres de stratégie de service ne sont pas copiés vers l'interface d'accès virtuel clonée, où la file d'attente a lieu. Ce résultat illustre ces symptômes :
Router#show policy interface dialer1 Dialer1 Service-policy output: foo Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Weighted Fair Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/0/0 Router#show policy interface virtual-access 2 Router#
Remarque : Les versions 12.2(8) et 12.2(8)T du logiciel Cisco IOS sont recommandées pour éviter le bogue Cisco ID CSCdu87408, qui résout les rechargements de routeur comme un effet secondaire rare de cette configuration.
Cet exemple de configuration montre comment appliquer CBWFQ et LLQ à une interface de numérotation. Cette configuration génère :
Utilise une interface de numérotation pour appliquer dynamiquement les paramètres de protocole de la connexion aux interfaces RNIS BRI. L'interface de numérotation est dite « liée » aux interfaces RNIS BRI.
Place deux interfaces RNIS BRI dans un ensemble multiliaison.
Utilise la charge dialer load-threshold [sortant | entrant | deux] pour déterminer quand le routeur doit activer des canaux B supplémentaires et augmenter la bande passante de l'interface du bundle.
Crée une interface d'accès virtuel avec la commande ppp multilink.
Applique une stratégie de service avec CBWFQ et LLQ à l'interface d'accès virtuel via l'interface de numérotation.
Exemple de configuration |
---|
access-list 101 permit udp any any range 16384 32767 access-list 101 permit tcp any any eq 1720 ! access-list 102 permit tcp any any eq 23 ! class-map voice match access-group 101 !--- Traffic that matches ACL 101 is classified as class voice. class-map data match access-group 102 !--- Traffic that matches ACL 102 is classified as class data. policy-map mlppp class voice priority percent 50 class data bandwidth percent 25 class class-default fair-queue ! interface BRI2/1 no ip address encapsulation ppp dialer pool-member 1 !--- Member of dialer pool 1. isdn switch-type basic-net3 no cdp enable ppp authentication chap ! interface BRI2/2 no ip address encapsulation ppp dialer pool-member 1 !--- Member of dialer pool 1. isdn switch-type basic-net3 no cdp enable ppp authentication chap ! interface Dialer2 ip unnumbered Loopback0 encapsulation ppp dialer pool 1 dialer load-threshold 1 either !--- Load level (in either direction) for !--- traffic at which additional connections !--- are added to the MPPP bundle !--- load level values that range from 1 (unloaded) !--- to 255 (fully loaded). dialer string 6113 dialer string 6114 dialer-group 1 ppp authentication chap ppp multilink !--- Allow MLPPP for the four BRI channels. service-policy output mlppp !--- Apply the service policy to the dialer interface. |
La gamme Cisco 7500 utilise une architecture distribuée qui garantit un débit de paquets élevé en transférant les décisions de transfert de paquets du processeur de commutation de route (RSP) vers les processeurs d'interface polyvalente (VIP). Cette architecture permet également le déploiement de services IP améliorés à grande échelle, tels que la qualité de service, en répartissant la charge de traitement entre les différents processeurs indépendants des VIP.
Basée sur le matériel d'interface, la gamme Cisco 7500 prend en charge deux formes de QoS :
QoS | Activation | Où pris en charge | Où traité |
---|---|---|---|
Basé sur RSP | Automatiquement sur les anciens processeurs d'interface. | Processeurs d'interface hérités. Ne peut plus être activé sur les VIP. | Processeur RSP |
Basé sur VIP (distribué) | Lorsque ces deux commandes sont configurées automatiquement :
|
VIP | CPU VIP |
Les mécanismes QoS basés sur VIP appliqués via l'interface de ligne de commande QoS modulaire (MQC) sont introduits dans les trois catégories de versions du logiciel Cisco IOS suivantes :
Logiciel Cisco IOS Version 12.0(XE), qui est devenu le logiciel Cisco IOS Version 12.1(E)
Logiciel Cisco IOS Version 12.0(9)S
Logiciel Cisco IOS Version 12.1(5)T, qui est devenu le logiciel Cisco IOS Version 12.2 Mainline et le logiciel Cisco IOS Version 12.2T
La fonctionnalité MLPPP distribuée vous permet de combiner la bande passante de plusieurs interfaces T1/E1 sur un VIP dans une interface groupée. Pour plus d'informations, référez-vous au protocole point à point multiliaison distribué pour les routeurs de la gamme Cisco 7500. La version 12.2(13)T du logiciel Cisco IOS introduit la prise en charge du protocole MLPPP distribué (dMLPPP) sur les cartes de ports non canalisées, telles que PA-4T+ et PA-8T.
La version 12.2(8)T du logiciel Cisco IOS a introduit la prise en charge de la LLQ et de la CBWFQ distribuées sur les interfaces de bundle dMLPPP sur les cartes de ports multicanaux fractionnés telles que PA-MC-xT1/E1 et PA-MC-xT3/E3. Comme la version non distribuée de cette fonctionnalité, dMLPPP utilise une interface multiliaison pour créer une interface d'accès virtuel où la mise en file d'attente a lieu. Reportez-vous à Informations nouvelles et modifiées pour le logiciel Cisco IOS Version 12.2T. Lorsque vous appliquez la mise en file d'attente distribuée avec dMLPPP, le logiciel Cisco IOS Version 12.2(10)T ou ultérieure est recommandé afin d'éviter le bogue Cisco ID CSCdw47678.
Seules CBWFQ et LLQ appliquées à la commande service-policy sont prises en charge avec dMLPPP/dLFI. Les fonctionnalités de mise en file d'attente héritées, telles que la mise en file d'attente équitable avec la commande fair-queue, la mise en file d'attente prioritaire avec la commande priority-group et la mise en file d'attente personnalisée avec la commande queue-list, ne sont pas prises en charge.
Le FlexWAN de la gamme Cisco 7600 prend en charge la dLLQ sur les interfaces non groupées. Il ne prend pas en charge dLLQ sur les interfaces de bundle MLPPP. Cette assistance est disponible avec le logiciel Cisco IOS Version 12.2S.
Cet exemple de configuration applique dLLQ sur une interface multiliaison :
Exemple de configuration dLLQ sur une interface de bundle MLPPP |
---|
Interface ! access-list 100 permit udp any any range 16384 32000 access-list 100 permit tcp any any eq 1720 access-list 101 permit tcp any any eq 80 access-list 102 permit tcp any any eq 23 ! class-map voip match access-group 100 class-map data1 match access-group 101 class-map data2 match access-group 102 ! policy-map llq-policy class voip bandwidth 40 class data1 bandwidth 15 class data2 bandwidth 15 class class-default fair-queue ! policy-map set-policy class voip bandwidth 40 class data1 bandwidth 15 class data2 bandwidth 15 class class-default fair-queue ! interface Serial5/0/0:0 no ip address encapsulation ppp keepalive 10 ppp chap hostname G2 ppp multilink multilink-group 2 ! interface Serial5/1/0:0 no ip address encapsulation ppp keepalive 10 ppp chap hostname G2 ppp multilink multilink-group 2 ! interface Multilink2 ip address 106.0.0.2 255.0.0.0 ppp multilink service-policy output llq-policy service-policy input set-policy multilink-group 2 |
La fragmentation et l'entrelacement des liaisons (LFI) ajoutent les commandes ppp multilink fragment-delay et ppp multilink interleave à une interface virtuelle-template configurée avec MLPPP et une politique de service. Cette configuration réduit le délai sur les liaisons à plus faible vitesse en divisant les grands datagrammes et en interlaissant les paquets de trafic à faible délai avec les paquets plus petits qui résultent du datagramme fragmenté. Pour plus d'informations, référez-vous à Configuration de la fragmentation et de l'entrelacement des liaisons pour les circuits virtuels Frame Relay et ATM.
La version 12.2(8)T du logiciel Cisco IOS a introduit la prise en charge des lignes série multicanaux fractionnés LFI distribuées (dLFI) sur la gamme Cisco 7500 avec VIP. Cette fonctionnalité est également disponible avec les commutateurs de la gamme Catalyst 6500 et les routeurs de la gamme Cisco 7600. Pour plus d'informations sur les versions qui prennent en charge dLFI, reportez-vous à l'Outil Feature Navigator (enregistré uniquement) et aux Notes de version des produits respectifs. Pour plus d'informations sur cette fonctionnalité, référez-vous à Fragmentation et entrelacement de liaison distribuée sur des lignes louées.
Le FlexWAN de la gamme Cisco 7600 avec la version 12.1E du logiciel Cisco IOS ne prend pas en charge le dLFI.
Après avoir configuré le délai de fragment maximal avec la commande ppp multilink fragment-delay <msec>, dLFI calcule la taille de fragment réelle sur les interfaces série multicanaux fractionnés à l'aide de cette formule (où la bande passante est en kbits/s) :
fragment size = bandwidth x fragment-delay / 8
En outre, la taille du fragment est calculée en fonction de la liaison de membre avec la bande passante la plus faible. Par exemple, dans une configuration avec des liaisons membres de 64 k et 128 k, la taille du fragment est calculée en fonction de la liaison 64 k.
La version 12.2(8) du logiciel Cisco IOS a introduit la prise en charge de la mise en file d’attente par circuit virtuel sur les circuits virtuels ATM configurés avec l’encapsulation PPP sur ATM (PPPoA) générique. Ces sous-sections vous donnent des exemples de configuration du marquage, de la réglementation et de la mise en file d'attente basés sur les classes.
1. Marquage basé sur les classes
La commande service-policy peut être connectée à l'interface Virtual-template ou au circuit virtuel permanent ATM pour le marquage basé sur les classes.
Dans cet exemple, la carte de classe PEER2PEER est définie, la carte de stratégie MARK_PEER2PEER est créée et la valeur par défaut dscp est configurée pour la classe PEER2PEER ; ensuite, la stratégie de service est associée au modèle virtuel ou au circuit virtuel permanent ATM.
Router(config)#class-map PEER2PEER Router(config-cmap)#match access-group 100 Router(config-cmap)#exit Router(config)#policy-map MARK_PEER2PEER Router(config-pmap)#class PEER2PEER Router(config-pmap-c)#set dscp default Router(config-pmap-c)#end Attaching Service-policy to Virtual Template Router(config-subif)#int atm1/0.1 point-to-point Router(config-subif)#ip address 10.10.10.1 255.255.255.0 Router(config-subif)#pvc 1/50 Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 1 Router(config)#interface Virtual-Template1 Router(config-if)#ip address negotiated Router(config-if)#service-policy output MARK_PEER2PEER Attaching Service-policy to ATM pvc Router(config)#int atm1/0.1 point-to-point Router(config-subif)#ip address 10.10.10.1 255.255.255.0 Router(config-subif)#pvc 1/50 Router(config-if-atm-vc)#service-policy output MARK_PEER2PEER
2. Réglementation basée sur les classes :
La commande service-policy peut être associée à l'interface Virtual-template ou au pvc ATM pour la réglementation basée sur les classes.
Router(config)#policy-map POLICE_PEER2PEER Router(config-pmap)#class PEER2PEERRouter(config-pmap-c)#police 8000 conform-action transmit exceed-action drop Attaching Service-policy to Virtual Template Router(config-subif)#int atm1/0.2 multipoint Router(config-subif)#no ip address Router(config-subif)#pvc 1/100 Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 2 Router(config)#interface Virtual-Template2 Router(config-if)#ip address negotiated Router(config-if)#service-policy output POLICE_PEER2PEER Attaching Service-policy to ATM pvc Router(config)#int atm1/0.2 multipoint Router(config-subif)#no ip address Router(config-subif)#pvc 1/100 Router(config-if-atm-vc)#service-policy output POLICE_PEER2PEER
3. Mise en file d'attente basée sur les classes :
Pour la mise en file d'attente basée sur les classes, c'est-à-dire la bande passante, la forme, la priorité et la détection aléatoire, la commande service-policy peut être associée au modèle virtuel ou au circuit virtuel permanent ATM.
Router(config)#policy-map QUEUE_PEER2PEER Router(config-pmap)#class PEER2PEER Router(config-pmap-c)#bandwidth 768 Attaching Service-policy to Virtual Template Router(config-subif)#int atm1/0 Router(config-subif)#no atm ilmi-keepalive Router(config-subif)#pvc 1/150 Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 3 Router(config)#interface Virtual-Template3 Router(config-if)#ip address negotiated Router(config-if)#service-policy output QUEUE_PEER2PEER Attaching Service-policy to ATM pvc Router(config)#int atm1/0 Router(config-subif)#no atm ilmi-keepalive Router(config-subif)#pvc 1/150 Router(config-if-atm-vc)#service-policy output QUEUE_PEER2PEER
Remarque : lorsque vous utilisez une combinaison de marquage basé sur les classes ou de contrôle basé sur les classes et de mise en file d'attente basée sur les classes, l'ordre des opérations est le suivant :
La commande service-policy configurée sur l'interface Virtual-Template marque ou applique les paquets.
La commande service-policy sur le circuit virtuel permanent ATM met les paquets en file d'attente.
Reportez-vous à cet exemple :
policy-map MARK_PEER2PEER class PEER2PEER set dscp default ! interface ATM0/0 no ip address no atm ilmi-keepalive pvc 1/100 encapsulation aal5mux ppp Virtual-Template1 service-policy output QUEUE_PEER2PEER ! interface Virtual-Template1 ip address negotiate service-policy output MARK_PEER2PEER
Si vous exécutez une version antérieure du logiciel Cisco IOS, vous pouvez configurer sur ATM VC avec l'encapsulation MLPPPoA et appliquer une stratégie de service basée sur la file d'attente à l'interface de modèle virtuel. Pour plus d'informations, référez-vous à Fragmentation et entrelacement de liaison pour les circuits virtuels Frame Relay et ATM et à la Vue d'ensemble des mécanismes d'efficacité de liaison.
La version 12.2(4)T3 du logiciel Cisco IOS introduit une version distribuée de cette fonctionnalité pour la gamme Cisco 7500. Pour plus d'informations sur cette fonctionnalité, référez-vous à Fragmentation et entrelacement de liaison distribuée pour ATM et Frame Relay.