QoS-prioriteit configureren in ASR 920 en RSP2-gebaseerde routers

Inleiding

Dit document beschrijft hoe de ASR 920/RSP2-routers QoS-prioriteiten verwerken en hoe u het kunt configureren.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• ASR 920 Series routers
• QoS-beleid

Gebruikte componenten

De informatie in dit document is gebaseerd op een ASR 9xx met RSP2 router die softwareversie 16.x door 17.x in werking stelt.
Een traffic generator wordt gebruikt om de functies te testen die prioriteitspakketten behandelen.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Problemen

Dit document gaat in op deze specifieke problemen van op ASR 920 en RSP2 gebaseerde routers:

• Prioriteitspakketten die op voorsprong van best-inspanningspakketten als gevolg van ASIC-beperking op RSP2 worden gelaten vallen
• Hoe de bandbreedte te berekenen percentage te bieden in een klasse

Prioriteitspakketten gedaald in het voordeel van de beste inspanningspakketten

Tijdens een test werd bepaald dat prioriteitspakket kan worden gedropt ten voordele van een best-inspanningspakket. Dit is duidelijk wanneer inkomend verkeer door een interface met hogere snelheid dan de uitgangsinterface aankomt en overabonnement in de outputrichting veroorzaakt. Bijvoorbeeld, wanneer 5 Gbps verkeer wordt ontvangen en door een 1 Gbps interface moet worden verstuurd.
Dit is ook het geval voor uitgaande interfaces die met een shaper zijn geconfigureerd. Als de toegangssnelheid hoger is dan de geconfigureerde CIR bij de uitgangsprioriteit, kan een pakket nog steeds worden gedropt met het voordeel van een best practice-pakket.

Opmerking: er is een ASIC-beperking waarvoor we geen prioritair kind kunnen hebben ten opzichte van een niet-prioritaire ouder.

Als een wachtrij zo snel is geconfigureerd en het hoofdsubkanaal niet is, is er jitter op de prioriteitswachtrij vanwege de arbitragelatency op subkanaalniveau.

Oplossing

1. EFP configureren
2. Pas een shaper toe op de fysieke
3. Pas de gewenste QoS op de EFP toe
4. De IP-connectiviteit in de BDI-interface toepassen

Voorbeeld:

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

Met deze configuratie, werden alle prioriteitspakketten correct geprioriteerd en geen werd gelaten vallen in het voordeel van een beste inspanningspakket, nog moet u de band die behoorlijk wordt toegewezen berekenen.

Hoe te berekenen de te bieden bandbreedtepercentage in een klasse

De bandbreedte toewijzing in RSP2 platform heeft ook een specifiek gedrag. Vaak worden druppels gezien terwijl QoS zoals in andere platforms wordt gevormd.

Als u bijvoorbeeld QoS met een shaper van 2 Mbps in een ASR1K-router configureert, daalt het niet voordat 2 Mbps zijn bereikt, noch worden pakketten in de klasse in de wachtrijen geplaatst. Echter, dit gebeurt met RSP2.

In veel gevallen bereikt de aangeboden snelheid zelfs niet het maximum dat is toegestaan als er al druppels worden gezien.

Dit is een typisch voorbeeld van wat op een RSP2 kan worden gezien, terwijl de zelfde waarden voor het nauwkeurige zelfde die verkeer op een ander platform wordt toegepast geen daling zouden tonen:

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

Het probleem wordt veroorzaakt door de manier waarop verkeer in de hardware wordt verwerkt. In principe houdt RSP2 hardware-implementatie niet alleen rekening met de Layer 3 maar met het gehele frame, wat betekent dat alle headers in aanmerking worden genomen.

RSP2-QoS-prioriteitstest

In dit geval wordt CEM-verkeer gebruikt om het prioriteitsgedrag te testen.

Dit is een voorbeeld dat laat zien hoe je prioriteit kan configureren om druppels te voorkomen ten voordele van best-inspanning en de bandbreedte toewijzing te stemmen.

Configuratie

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

Verkeer

2 verkeersstromen worden gecreëerd door CEM0/1/8 in rood en CEM0/1/9 in groen:

We kunnen het gedrag zien met verschillende pakketgrootte, CEM0/1/9 verstuurt tweemaal zoveel pakketten als CEM0/1/8, die is geconfigureerd voor 128 bytes.

Normaal, een QoS configuratie op RP overweegt alleen de payload van CEM, RSP2 overweegt in plaats daarvan het gehele frame.

Frame Relay Voorbeeld

U kunt zien 30 bytes extra aan de originele payload die onder CEM wordt gevormd. Dit kan als volgt worden verklaard:

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

Berekening van de bandbreedte die nodig is in de hardware, moet het frame in overweging worden genomen:

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

Om het gedrag en de nauwkeurigheid van de shaper op de interface te verifiëren het aan 8650000 bps werd gevormd, wordt dit gedaan om nauwkeurige 4% voor prioritaire klasse te hebben.

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

Dit is wat in de configuratie hierboven wordt gezien. De resultaten bevestigen dat de configuratie en de berekening nauwkeurig zijn.

Beleidsoutput:

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 Kbps toegepast in platformonafhankelijke is veel meer dan L3 maar is precies het L2 verkeer.

Test met traffic generator

Traffic generator —> TenGig interface —> Asr9xx RSP2 —> output 1G waar het beleid wordt toegepast.

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

Na ongeveer 18 uur was er geen enkele daling in de prioriteit, hoewel er op de interface een heleboel dalingen zijn, zoals gezien in de dalingsgraad van het class-default, als gevolg van de CIR van de shaper limiet.

Merk op dat de standaard wachtrij-limiet werd gebruikt: om de bandbreedte af te stemmen om de gehele l2 framegrootte te ondersteunen, hoeft u de wachtrijen niet af te stemmen.

Negatieve test

            

Een andere test om de goede nauwkeurigheid te controleren is om de 4 bytes van de CEM aanhangwagen weg te laten en te zien of kleine druppels voorkomen:

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

Zoals je kunt zien, als je een deel van dat frame weglaat, veroorzaakt dat druppels.

Conclusies

Deze test met het CEM-verkeer bevestigt dat het gehele L2-frame in aanmerking moet worden genomen voor de bandbreedteberekening.

Een kunstwerk is om de wachtrij-limiet te verhogen, maar een correcte berekening van het L2 frame geeft duidelijk minder stress op de geheugenbronnen die door het platform worden gebruikt.

Het is duidelijk dat niet al het verkeer op elk moment kan worden voorzien, zoals bij overdracht met variabele pakketgrootte. Om een nauwkeurige configuratie te hebben, moet u rekening houden met de kopregels Ethernet, dot1q(s), MPLS-tag(s) voor de gemiddelde pakketgrootte en ook de pakketsnelheid.

Voor elk verkeer dat de ASIC van een RSP2 doorkruist, moet u zich bewust zijn van elke enkele byte die is opgenomen in een frame verzonden uit het platform (CRC niet inbegrepen).