Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

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

CBWFQ et LLQ sur les interfaces de numérotation

LLQ et CBWFQ avec MLPPP distribué

CBWFQ et LLQ avec PPPoA et MLPPPoA

Informations connexes

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.

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.

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 :

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 :

- La commande ip cef distribute en mode de configuration globale.

- La commande ip route-cache distribute en mode de configuration d'interface.

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.

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