Konfigurieren der QoS-Priorität in Routern auf ASR 920- und RSP2-Basis

Einleitung

In diesem Dokument wird beschrieben, wie ASR920/RSP2-Router QoS-Prioritäten handhaben und wie diese konfiguriert werden.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Router der Serie ASR 920
• QoS-Richtlinien

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf einem ASR 9xx mit RSP2-Router, auf dem die Softwareversionen 16.x bis 17.x ausgeführt werden.
Mit einem Traffic Generator werden die Funktionen getestet, die Prioritätspakete verarbeiten.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Probleme

Dieses Dokument behandelt die folgenden spezifischen Probleme von Routern mit ASR 920 und RSP2:

• Prioritätspakete werden zugunsten von Best-Effort-Paketen aufgrund der ASIC-Einschränkung auf RSP2 verworfen
• Berechnung des in einer Klasse anzubietenden Bandbreitenprozentsatzes

Prioritätspakete, die zugunsten von Best-Effort-Paketen verworfen wurden

Während eines Tests wurde festgestellt, dass ein Prioritätspaket zugunsten eines Best-Effort-Pakets verworfen werden kann. Dies tritt auf, wenn eingehender Datenverkehr über eine Schnittstelle eingeht, die schneller ist als die Ausgangsschnittstelle, und eine Überbelegung in Ausgaberichtung verursacht. Wenn beispielsweise 5 Gbit/s Datenverkehr empfangen werden und über eine 1-Gbit/s-Schnittstelle weitergeleitet werden müssen.
Dies gilt auch für Ausgangsschnittstellen, die mit einem Shaper konfiguriert sind. Falls die Eingangsgeschwindigkeit bei der Ausgangspriorität höher ist als die konfigurierte CIR, kann ein Paket dennoch mithilfe eines Best-Effort-Pakets verworfen werden.

Hinweis: Es gibt eine ASIC-Einschränkung, für die keine untergeordnete Priorität für ein nicht-priorisiertes übergeordnetes Element festgelegt werden kann.

Wenn eine Warteschlange als "Beschleunigt" konfiguriert ist und ihr übergeordneter Unterkanal nicht, tritt aufgrund der Arbitrierungslatenzzeiten auf Unterkanalebene ein Jitter in der Prioritätswarteschlange auf.

Lösung

1. Konfigurieren von EFP
2. Einen Shaper auf die physische
3. Anwenden der gewünschten QoS auf das EFP
4. Anwenden der IP-Verbindung in der BDI-Schnittstelle

Beispiel:

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

Bei dieser Konfiguration wurden alle Prioritätspakete ordnungsgemäß priorisiert, und keines wurde zugunsten eines Pakets mit bestmöglicher Leistung verworfen. Sie müssen jedoch die zugewiesene Bandbreite berechnen.

Berechnung des prozentualen Bandbreitenangebots in einer Klasse

Die Bandbreitenzuweisung in der RSP2-Plattform hat ebenfalls ein bestimmtes Verhalten. In vielen Fällen treten Verluste auf, wenn die QoS wie bei anderen Plattformen konfiguriert wird.

Wenn Sie beispielsweise QoS mit einem Shaper von 2 Mbit/s in einem ASR1K-Router konfigurieren, wird dieser erst nach Erreichen von 2 Mbit/s fallen, und es werden keine Pakete in der Klasse in die Warteschlange gestellt. Dies geschieht jedoch mit RSP2.

In vielen Fällen erreicht die angebotene Geschwindigkeit noch nicht einmal das zulässige Maximum, wenn bereits Tropfen sichtbar sind.

Dies ist ein typisches Beispiel für einen RSP2, während dieselben Werte für denselben Datenverkehr, der auf eine andere Plattform angewendet wird, keinen Verlust aufweisen:

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

Das Problem ist auf die Art und Weise zurückzuführen, wie der Datenverkehr in der Hardware verarbeitet wird. Grundsätzlich berücksichtigt die RSP2-Hardware-Implementierung nicht nur den Layer 3, sondern den gesamten Frame, d. h. alle Header werden berücksichtigt.

RSP2 QoS-Prioritätstest

In diesem Fall wird CEM-Datenverkehr verwendet, um das Prioritätsverhalten zu testen.

Dieses Beispiel zeigt, wie Sie eine Priorität konfigurieren, um Datenverluste zu vermeiden, die sich im Rahmen von "Best Effort" bemerkbar machen, und die Bandbreitenzuweisung anpassen.

Konfiguration

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

Datenverkehr

2 Datenströme werden von CEM0/1/8 in Rot und CEM0/1/9 in Grün erzeugt:

Wir können das Verhalten mit einer anderen Paketgröße erkennen: CEM0/1/9 sendet doppelt so viele Pakete wie CEM0/1/8, das für 128 Byte konfiguriert ist.

Normalerweise berücksichtigt eine QoS-Konfiguration auf RP nur die Payload von CEM, RSP2 hingegen den gesamten Frame.

Frame-Beispiel

Es werden 30 Byte zusätzlich zur ursprünglichen Payload angezeigt, die unter CEM konfiguriert wurde. Dies lässt sich wie folgt erklären:

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

Berechnung der benötigten Bandbreite in der Hardware, erinnern, dass der Frame berücksichtigt werden muss:

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

Um das Verhalten und die Genauigkeit des Shapers auf der Schnittstelle zu überprüfen, für die er auf 8650000 bps konfiguriert wurde, werden exakte 4 % für die Prioritätsklasse festgelegt.

Berechnung: 346000,0000/8650000,0000 = 0,04 = 4%.

Dies wird in der obigen Konfiguration gezeigt. Die Ergebnisse bestätigen, dass die Konfiguration und Berechnung korrekt sind.

Policy-Ausgabe:

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 Kbit/s werden plattformunabhängig angewendet und sind deutlich mehr als L3, jedoch genau der L2-Datenverkehr.

Test mit Traffic Generator

Traffic Generator —> TenGig-Schnittstelle —> Asr9xx RSP2 —> Ausgabe 1G, auf die die Richtlinie angewendet wird.

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

Nach ca. 18 Stunden gab es keinen einzigen Prioritätsverlust, obwohl es auf der Schnittstelle eine Menge von Verlusten gibt, wie in der Drop-Rate des class-default zu sehen ist, aufgrund der CIR des Shaper-Limits.

Beachten Sie, dass der Standard-Warteschlangengrenzwert verwendet wurde: Um die Bandbreite auf die gesamte L2-Frame-Größe abzustimmen, müssen Sie die Warteschlangen nicht abstimmen.

Negativer Test

            

Ein weiterer Test, um die gute Genauigkeit zu überprüfen, besteht darin, die 4 Bytes des CEM-Trailers wegzulassen und zu sehen, ob kleine Tropfen auftreten:

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

Wie Sie sehen können, führt das Auslassen eines Teils dieses Frames zu Drops.

Schlussfolgerungen

Dieser Test mit dem CEM-Datenverkehr bestätigt, dass der gesamte L2-Frame für die Bandbreitenberechnung berücksichtigt werden muss.

Ein Fehler besteht darin, die Warteschlangengrenze zu erhöhen. Eine korrekte Berechnung des L2-Frames bedeutet jedoch, dass die von der Plattform verwendeten Speicherressourcen weniger beansprucht werden.

Es ist offensichtlich, dass nicht der gesamte Datenverkehr zu jedem Zeitpunkt vorhersehbar ist, wie bei einem Transfer mit variabler Paketgröße. Für eine präzise Konfiguration müssen Sie Ethernet-, Punkt1q-, MPLS-Tag-Header bis hin zur durchschnittlichen Paketgröße und Paketrate berücksichtigen.

Bei jedem Datenverkehr, der den ASIC eines RSP2 durchläuft, müssen Sie jedes einzelne Byte kennen, das in einem Frame enthalten ist, der von der Plattform gesendet wird (CRC nicht enthalten).