Configurazione della priorità QoS nei router ASR 920 e RSP2

Introduzione

In questo documento viene descritto come i router ASR920/RSP2 gestiscono le priorità QoS e come configurarle.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• ASR serie 920 router
• Criteri QoS

Componenti usati

Per questo documento, è stato usato un router ASR 9xx con RSP2 con software versione da 16.x a 17.x.
Un generatore di traffico viene utilizzato per verificare le funzioni che gestiscono i pacchetti con priorità.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Problemi

Questo documento affronta questi problemi specifici dei router ASR 920 e RSP2:

• Pacchetti con priorità scartati a vantaggio dei pacchetti più impegnativi a causa delle limitazioni ASIC su RSP2
• Come calcolare la percentuale di larghezza di banda da offrire in una classe

Pacchetti con priorità scartati a vantaggio dei pacchetti con il massimo sforzo

Durante un test è stato stabilito che il pacchetto di priorità può essere scartato a vantaggio di un pacchetto che richiede il massimo sforzo. Questo è evidente quando il traffico in entrata arriva tramite un'interfaccia con una velocità superiore a quella dell'interfaccia in uscita e causa un'iscrizione eccessiva nella direzione di output. Ad esempio, quando si ricevono 5 Gbps di traffico che deve essere inoltrato tramite un'interfaccia da 1 Gbps.
Ciò vale anche per le interfacce in uscita configurate con uno shaper. Nel caso in cui la velocità in entrata sia superiore al CIR configurato con la priorità in uscita, un pacchetto potrebbe comunque essere scartato a proprio vantaggio.

Nota: esiste una limitazione ASIC per la quale non è possibile avere un elemento figlio con priorità rispetto a un elemento padre non con priorità.

Se una coda è configurata come urgente e il relativo canale secondario padre non lo è, la coda di priorità è soggetta a jitter a causa delle latenze di arbitraggio a livello di canale secondario.

Soluzione

1. Configura EFP
2. Applicare uno shaper sul
3. Applicare la QoS desiderata all'EFP
4. Applicazione della connettività IP nell'interfaccia BDI

Esempio:

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

Con questa configurazione, a tutti i pacchetti con priorità è stata assegnata la corretta priorità e nessuno di essi è stato scartato a vantaggio di un pacchetto di massimo sforzo, tuttavia è necessario calcolare la larghezza di banda allocata correttamente.

Come calcolare la percentuale di larghezza di banda da offrire in una classe

Anche l'allocazione della larghezza di banda nella piattaforma RSP2 ha un comportamento specifico. Molte volte si osservano cadute mentre QoS è configurato come in altre piattaforme.

Ad esempio, se si configura QoS con uno shaper di 2 Mbps in un router ASR1K, questo non scade prima che siano raggiunti 2 Mbps, né accoda i pacchetti nella classe. Tuttavia, ciò accade con RSP2.

In molti casi, la velocità offerta non raggiunge nemmeno il massimo consentito quando si notano già delle cadute.

Questo è un tipico esempio di quanto può apparire su un RSP2, mentre gli stessi valori per lo stesso traffico applicato a un'altra piattaforma non mostrano alcuna perdita:

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

Il problema è dovuto alla modalità di gestione del traffico nell'hardware. Fondamentalmente, l'implementazione dell'hardware RSP2 non considera solo il layer 3 ma l'intero frame, il che significa che vengono prese in considerazione tutte le intestazioni.

Test di priorità QoS RSP2

In questo caso, il traffico CEM viene utilizzato per verificare il comportamento di priorità.

In questo esempio viene illustrato come configurare la priorità in modo da evitare cali a vantaggio di un intervento rapido e ottimizzare l'allocazione della larghezza di banda.

Configurazione

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

Traffico

2 flussi di traffico vengono creati da CEM0/1/8 in rosso e CEM0/1/9 in verde:

Possiamo notare il comportamento con dimensioni del pacchetto diverse, CEM0/1/9 invia il doppio dei pacchetti di CEM0/1/8, che è configurato per 128 byte.

Normalmente, una configurazione QoS su RP considera solo il payload di CEM, mentre RSP2 considera l'intero frame.

Esempio di frame

È possibile visualizzare 30 byte aggiuntivi al payload originale configurato in CEM. Ciò può essere spiegato come segue:

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

Calcolo della larghezza di banda necessaria nell'hardware, ricordare che il frame deve essere preso in considerazione:

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

Per verificare il comportamento e l'accuratezza dello shaper sull'interfaccia configurata a 8650000 bps, è necessario che la classe di priorità corrisponda esattamente al 4%.

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

Ciò si verifica nella configurazione descritta sopra. I risultati confermano l'accuratezza della configurazione e dei calcoli.

Output criteri:

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 applicati in modo indipendente dalla piattaforma è molto più di L3 ma è esattamente il traffico L2.

Test con il generatore di traffico

Traffic generator —> TenGig interface —> Asr9xx RSP2 —> output 1G in cui viene applicato il criterio.

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

Dopo circa 18 ore non c'è stata una singola caduta di priorità, anche se sull'interfaccia ci sono molte cadute, come si vede nella frequenza di caduta della classe-default, a causa del CIR del limite di shaper.

Si noti che è stato utilizzato il limite di coda predefinito: per regolare la larghezza di banda in modo da supportare l'intera dimensione del frame l2, non è necessario regolare le code.

Test negativo

            

Un altro test per verificare la buona accuratezza consiste nell'omettere i 4 byte del trailer CEM e verificare se si verificano piccole cadute:

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

Come potete vedere, se omettete una parte di quel fotogramma ciò causa delle gocce.

Conclusioni

Questo test con il traffico CEM conferma che l'intero frame L2 deve essere preso in considerazione per il calcolo della larghezza di banda.

Un artificio è aumentare il limite della coda, ma un calcolo corretto del frame L2 mette meno stress sulle risorse di memoria utilizzate dalla piattaforma.

È ovvio che non tutto il traffico può essere previsto in ogni momento, come nel caso del trasferimento con pacchetti di dimensioni variabili. Per ottenere una configurazione accurata, occorre prendere in considerazione ethernet, dot1q(s), tag MPLS intestazioni per le dimensioni medie dei pacchetti e anche la velocità dei pacchetti.

Per tutto il traffico che attraversa l'ASIC di un RSP2, è necessario essere a conoscenza di ogni singolo byte contenuto in un frame inviato fuori dalla piattaforma (CRC non incluso).