Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Problemi

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

Soluzione

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

Test di priorità QoS RSP2

Configurazione

Traffico

Esempio di frame

Test con il generatore di traffico

Test negativo

Conclusioni

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).