Configuration de la priorité QoS dans les routeurs ASR 920 et RSP2

Introduction

Ce document décrit comment les routeurs ASR920/RSP2 gèrent les priorités QoS et comment le configurer.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Routeurs de la gamme ASR 920
• Stratégies QoS

Composants utilisés

Les informations de ce document sont basées sur un routeur ASR 9xx avec RSP2 qui exécute les versions logicielles 16.x à 17.x.
Un générateur de trafic est utilisé pour tester les fonctions qui gèrent les paquets prioritaires.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Problèmes

Ce document traite des problèmes spécifiques des routeurs ASR 920 et RSP2 :

• Paquets prioritaires abandonnés au profit des paquets au mieux en raison de la limitation ASIC sur RSP2
• Comment calculer le pourcentage de bande passante à offrir dans un cours

Paquets prioritaires abandonnés à l'avantage des paquets au mieux

Au cours d’un test, il a été déterminé que le paquet prioritaire peut être abandonné au profit d’un paquet au mieux. Cela est évident lorsque le trafic entrant arrive via une interface avec une vitesse supérieure à celle de l'interface de sortie et provoque une sursouscription dans le sens de la sortie. Par exemple, lorsque 5 Gbits/s de trafic sont reçus et doivent être transférés via une interface 1 Gbits/s.
Ceci est également vrai pour les interfaces de sortie configurées avec un shaper. Si la vitesse d’entrée est supérieure à la vitesse de retour de l’information configurée à la priorité de sortie, un paquet peut toujours être abandonné au profit d’un paquet au mieux.

Remarque : il existe une limitation ASIC pour laquelle nous ne pouvons pas avoir d'enfant prioritaire par rapport à un parent non prioritaire.

Si une file d'attente est configurée comme étant rapide et que son sous-canal parent ne l'est pas, il y a une gigue sur la file d'attente prioritaire en raison des latences d'arbitrage au niveau du sous-canal.

Solution

1. Configuration d'EFP
2. Appliquer un outil de mise en forme sur le
3. Appliquez la QoS souhaitée sur l'EFP
4. Application de la connectivité IP dans l’interface BDI

Exemple :

configuration with issue 
-------------------------
interface GigabitEthernet0/0/0
description this is my egress interface 
service-policy output PM-1G-Out

configuration without issue 
---------------------------
interface GigabitEthernet0/0/0
description this is  egress interface
service-policy output POL-PRIO-MAIN-1G ==> shaper, useful to allow internal priority like BDF
service instance 200 ethernet
encapsulation dot1q 200
rewrite ingress tag pop 1 symmetric
service-policy output PM-1G-Out ==> the original QoS previously applied in the physical interface
bridge-domain 200
!
interface BDI200 ==> BDI must match the bridge-domain defined under the service-instance
description this is  L3 egress
ip address 10.20.2.45 255.255.255.0 
ip mtu 9000
==> no QoS applied under the BDI, all QoS are in the service-instance with a backpressure of the shaper in the physical

Avec cette configuration, tous les paquets prioritaires ont été classés par priorité correctement et aucun n'a été abandonné au profit d'un paquet au mieux, mais vous devez toujours calculer la bande passante allouée correctement.

Comment calculer le pourcentage de bande passante à offrir dans une classe

L'allocation de bande passante dans la plate-forme RSP2 a également un comportement spécifique. De nombreuses abandons sont observés alors que la QoS est configurée comme dans d'autres plates-formes.

Par exemple, si vous configurez la QoS avec un shaper de 2 Mbits/s dans un routeur ASR1K, elle n'est pas abandonnée avant que 2 Mbits/s soient atteints et elle ne met pas les paquets en file d'attente dans la classe. Cependant, cela se produit avec le RSP2.

Dans de nombreux cas, la vitesse offerte n'atteint même pas le maximum autorisé lorsque des chutes sont déjà observées.

Voici un exemple typique de ce qui peut être vu sur un RSP2, alors que les mêmes valeurs pour exactement le même trafic appliqué à une autre plate-forme n'afficheraient aucune baisse :

ASR903#show ethernet service instance policy-map | s EXP-5
  Class-map: EXP-5 (match-all)
    58803127 packets, 5488269944 bytes
    5 minute offered rate 279000 bps, drop rate 35000 bps

    Match: mpls experimental topmost 5
    Priority: 3% (297 kbps), burst bytes 37000, b/w exceed drops: 60373

    Priority Level: 1

Le problème est dû à la manière dont le trafic est géré dans le matériel. Fondamentalement, la mise en oeuvre matérielle du RSP2 ne tient pas compte uniquement de la couche 3, mais de la trame entière, ce qui signifie que tous les en-têtes sont pris en compte.

Test de priorité QoS RSP2

Dans ce cas, le trafic CEM est utilisé pour tester le comportement de priorité.

Voici un exemple qui montre comment configurer la priorité pour éviter les abandons au mieux et régler l'allocation de bande passante.

Configuration

policy-map POL-PRIO-MAIN-1G
class class-default
shape average 8650000
!
policy-map PM-MPLS-1G-Out
class EXP-5
priority level 1 percent 4
class EXP-4
priority level 2 percent 24
class EXP-6
bandwidth percent 2
queue-limit 25000 us
class EXP-3
bandwidth percent 2
queue-limit 10000 us
class EXP-2
bandwidth percent 2
queue-limit 50000 us
class EXP-1
bandwidth percent 2
queue-limit 20000 us
class class-default
bandwidth percent 1
queue-limit 40000 us
!
interface GigabitEthernet0/0/0
no ip address
negotiation auto
service-policy output POL-PRIO-MAIN-1G
service instance 200 ethernet
encapsulation dot1q 200
rewrite ingress tag pop 1 symmetric
service-policy output PM-MPLS-1G-Out
bridge-domain 200
!
interface CEM0/1/8
no ip address
cem 0
service-policy input PM-CEM-in
payload-size 128
dejitter-buffer 20
!
interface CEM0/1/9
no ip address
cem 0
service-policy input PM-CEM-in
payload-size 64
dejitter-buffer 16
!
interface BDI200
description path for qos stress
ip address 10.20.2.45 255.255.255.0
ip mtu 9000
ip router isis
carrier-delay msec 0
cdp enable
mpls traffic-eng tunnels
bfd template BFD-1hop-5ms
isis circuit-type level-2-only
isis network point-to-point
isis metric 15 level-1
isis metric 15 level-2
ip rsvp bandwidth percent 90
ip rsvp signalling hello graceful-restart

Trafic

2 flux de trafic sont créés par CEM0/1/8 en rouge et CEM0/1/9 en vert :

Nous pouvons voir le comportement avec la taille de paquet différente, CEM0/1/9 envoie deux fois plus de paquets que CEM0/1/8, qui est configuré pour 128 octets.

Normalement, une configuration QoS sur RP ne prend en compte que la charge utile de CEM, RSP2 prend en compte la trame entière à la place.

Exemple de trame

Vous pouvez voir 30 octets supplémentaires par rapport à la charge utile initiale configurée sous CEM. Ceci peut s'expliquer comme suit :

Ethernet header = 14 Bytes
Dot1q header    = 4 Bytes
Mpls header     = 4 Bytes
PW   Header     = 4 Bytes
CEM trailer     = 4 Bytes
Total           = 30 Bytes

Calcul de la bande passante nécessaire dans le matériel, rappelez-vous que la trame doit être prise en compte :

CEM 0/1/8 125 Packet/sec, size 128bytes ==> 125*128*8 = 128000 bps
CEM 0/1/9 250 Packet/sec, size 64bytes  ==> 250*64*8  = 128000 bps
on each frame we need an extra 30bytes  ==> 375*30*8  = 90000 bps
Total                                                 = 346000 bps

Pour vérifier le comportement et la précision du shaper sur l'interface qu'il a été configuré à 8650000 bps, ceci est fait pour avoir un 4% exact pour la classe de priorité.

Calcul : 346000.0000/8650000.0000 = 0,04 = 4 %.

C'est ce que l'on voit dans la configuration ci-dessus. Les résultats confirment que la configuration et le calcul sont corrects.

Sortie de stratégie :

ASR903#show ethernet service instance policy-map | s EXP-5
  Class-map: EXP-5 (match-all)
    3063745 packets, 285949512 bytes
    5 minute offered rate 279000 bps, drop rate 0000 bps
    Match: mpls experimental topmost 5
    Priority: 4% (346 kbps), burst bytes 8650, b/w exceed drops: 0

    Priority Level: 1

346 Kbits/s appliqués indépendamment de la plate-forme est beaucoup plus que L3, mais est exactement le trafic L2.

Test avec le générateur de trafic

Traffic Generator —> Interface TenGig —> Asr9xx RSP2 —> sortie 1G où la politique est appliquée.

ASR903#show clock
22:54:40.976 CET Wed Nov 30 2022
ASR903#show ethernet service instance policy-map | inc Class-map:|drop rate
  Class-map: EXP-5 (match-all)
    5 minute offered rate 279000 bps, drop rate 0000 bps
  Class-map: EXP-4 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-6 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-3 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-2 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-1 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: class-default (match-any)
    5 minute offered rate 762348000 bps, drop rate 756024000 bps

ASR903#show clock
17:41:16.110 CET Thu Dec 1 2022
ASR903#show ethernet service instance policy-map | inc Class-map:|drop rate
  Class-map: EXP-5 (match-all)
    5 minute offered rate 279000 bps, drop rate 0000 bps
  Class-map: EXP-4 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-6 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-3 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-2 (match-all)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: EXP-1 (match-any)
    5 minute offered rate 0000 bps, drop rate 0000 bps
  Class-map: class-default (match-any)
    5 minute offered rate 762400000 bps, drop rate 756077000 bps

Après environ 18 heures, il n'y a pas eu une seule baisse de priorité, bien que sur l'interface il y ait beaucoup de pertes, comme on le voit dans le taux de perte de la classe par défaut, en raison du CIR de la limite du shaper.

Notez que la limite de file d'attente par défaut a été utilisée : afin de régler la bande passante pour prendre en charge la taille de trame L2 entière, vous n'avez pas besoin de régler les files d'attente.

Test Négatif

            

Un autre test pour vérifier la bonne précision est d'omettre les 4 octets de la queue de bande CEM et de voir si de petites chutes se produisent :

ASR903#show ethernet service instance policy-map | s EXP-5
  Class-map: EXP-5 (match-all)
    352466 packets, 32896848 bytes
    5 minute offered rate 279000 bps, drop rate 5000 bps
    Match: mpls experimental topmost 5
    Priority: 4% (334 kbps), burst bytes 8350, b/w exceed drops: 271

    Priority Level: 1

Comme vous pouvez le voir, si vous omettez une partie de cette trame, elle provoque des pertes.

Conclusions

Ce test avec le trafic CEM confirme que la trame L2 entière doit être prise en compte pour le calcul de la bande passante.

L’un des artifices consiste à augmenter la limite de file d’attente, mais il est clair qu’un calcul correct de la trame L2 sollicite moins les ressources mémoire utilisées par la plate-forme.

Il est évident que tout le trafic ne peut pas être prévu à chaque point dans le temps, comme dans un transfert avec une taille de paquet variable. Afin d'avoir une configuration précise, vous devez prendre en considération ethernet, dot1q(s), MPLS tag(s) headers à la taille moyenne de paquet et aussi le débit de paquets.

Pour tout trafic qui traverse l'ASIC d'un RSP2, vous devez connaître chaque octet contenu dans une trame envoyée à partir de la plate-forme (CRC non inclus).