Configuration de la mise en file d'attente pondérée basée sur les classes (CBWFQ) et de LLQ sur des interfaces MLPPP et de numéroteur

Introduction

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.

Conditions préalables

Conditions requises

Aucune condition préalable spécifique n'est requise pour ce document.

Components Used

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

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Appliquer la mise en file d'attente aux interfaces avec une variété de bandes passantes

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é.

CBWFQ et LLQ sur les interfaces de numérotation

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.

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.

LLQ et CBWFQ avec MLPPP distribué

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 :

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 :

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.

CBWFQ et LLQ avec PPPoA et MLPPPoA

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 :

1. La commande service-policy configurée sur l'interface Virtual-Template marque ou applique les paquets.

2. 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.

Informations connexes

• Mise en file d'attente pondérée basée sur les classes par circuit virtuel (Per-VC CBWFQ) sur les routeurs Cisco 7200, 3600 et 2600
• Mise en file d'attente à faible latence (LLQ)
• Assistance technique sur la technologie QoS
• Support et documentation techniques - Cisco Systems