Introduzione
In questo documento viene descritto come risolvere i problemi relativi ai pacchetti eliminati nella coda di output sulle piattaforme Catalyst serie 9000.
Prerequisiti
Requisiti
Per risolvere i problemi di Quality of Service (QoS) sulle piattaforme Catalyst serie 9000, è necessario conoscere:
- Nozioni base sulla qualità del servizio
- CLI (Modular QoS Command Line Interface)
Componenti usati
Le informazioni di questo documento si basano sulla versione hardware e software in uso, ma la metodologia e la maggior parte dei comandi possono essere applicati ad altri switch Catalyst serie 9000 con altro codice:
- Cisco Catalyst 9300
- Cisco IOS® XE 16.12.3
Nota: per i comandi usati per attivare queste funzionalità su altre piattaforme Cisco, consultare le relative guide alla configurazione.
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.
Premesse
Per una spiegazione dettagliata della funzionalità QoS sulle piattaforme Catalyst serie 9000, incluse le configurazioni QoS predefinite, la struttura delle code e le spiegazioni dei buffer, consultare il white paper Catalyst 9000 QoS e Queueing Per informazioni sulla versione consigliata del software per la piattaforma in uso, consultare la guida. Questi consigli assicurano il supporto del software e aiutano a evitare i bug noti nei codici meno recenti. Versioni consigliate per Catalyst
Che cosa sono le perdite di output
La conoscenza dell'allocazione del buffer consente di comprendere in che modo la congestione del buffer determina cali di output. La congestione si verifica quando l'interfaccia di destinazione ha un numero di pacchetti che supera la sua velocità di output. Questi pacchetti devono essere memorizzati nel buffer finché non possono essere trasmessi. Tenere presente che questi switch dispongono di un massimo di 36 MB di buffer per ASIC, che viene quindi condiviso tra tutte le porte dell'ASIC. Mentre un'interfaccia in uscita può svuotare quel buffer alla velocità della linea, qualunque scenario che faccia sì che i pacchetti vengano memorizzati nel buffer a una velocità maggiore può causare congestione. La congestione può verificarsi anche se il picco di traffico dura solo una frazione di secondo e può causare latenza nel traffico o una perdita di output se il buffer si esaurisce completamente.
Nota: per impostazione predefinita, il contatore di rilascio dell'output visualizzato in show interface è espresso in byte. Nella versione 16.9.3 e successive questi contatori sono pacchetti per impostazione predefinita.
Tipi di congestione
Come mostrato nell'Immagine 1, vi sono due tipi di congestione.

Immagine 1. Tipi di congestione
I due tipi di congestione mostrati nell'Immagine 1 sono:
- Molti a uno: Quando più porte di origine inviano il traffico verso una singola destinazione contemporaneamente, la porta di destinazione può essere congestionata dalla quantità di traffico ricevuto da più porte.
- Mancata corrispondenza velocità: Quando una porta con velocità superiore trasmette dati a una porta con velocità inferiore (ad esempio, da 10 Gbps a 1 Gbps), i pacchetti devono impiegare del tempo per uscire dalla porta in uscita, il che può causare ritardi e/o perdite di pacchetti.
Congestione con basso throughput
I burst di traffico possono causare cali di output anche quando la velocità di output dell'interfaccia è significativamente inferiore alla capacità massima dell'interfaccia. per impostazione predefinita, le velocità di output nel comando show interface vengono calcolate su una media di cinque minuti, un valore non sufficiente per acquisire eventuali burst di breve durata. È consigliabile calcolare la media di tali intervalli in 30 secondi, anche se in questo scenario un'esplosione di traffico per millisecondi potrebbe determinare riduzioni dell'output che non causano l'aumento della frequenza media di 30 secondi. Questo documento può essere usato per risolvere i problemi relativi a qualsiasi altro tipo di congestione presente sugli switch Catalyst serie 9000.
Convalida congestione buffer
Per convalidare la congestione del buffer, sono disponibili due comandi. Il primo comando è show platform hardware fed switch active qos queue config interface<interfaccia>. Questo comando consente di visualizzare l'allocazione corrente del buffer sulla porta, come mostrato nell'Immagine 2.
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:2 - 1800
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 6 200 7 800 19 475 0 0 3 2400
1 1 5 0 8 1200 19 712 8 300 3 2400
2 1 5 0 6 0 0 0 0 0 3 2400
3 1 5 0 6 0 0 0 0 0 3 2400
4 1 5 0 6 0 0 0 0 0 3 2400
5 1 5 0 6 0 0 0 0 0 3 2400
6 1 5 0 6 0 0 0 0 0 3 2400
7 1 5 0 6 0 0 0 0 0 3 2400
Immagine 2. Allocazione buffer coda
Si desidera esaminare in modo specifico le colonne Hardmax e Softmax che mostrano il numero di buffer disponibili per le code. Per informazioni sui buffer e sulla loro allocazione predefinita, consultare il white paper Catalyst 9000 QoS and Queueing.
Il secondo comando è show platform hardware fed switch active qos queue status interface<interfaccia>. Questo comando consente di visualizzare le statistiche per coda su un'interfaccia, che includono quanti byte sono stati accodati nei buffer e quanti byte sono stati scartati a causa della mancanza di buffer disponibili.
9300#show platform hardware fed switch active qos queue stats interface Gig 1/0/1
DATA Port:0 Enqueue Counters
---------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 384251797 0
1 0 0 0 488393930284 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
DATA Port:0 Drop Counters
-------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0
1 0 0 192308101 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
Immagine 3. Statistiche buffer coda con rilasci
Come mostrato nell'immagine 3, la coda 0 e la coda 1 hanno entrambe byte accodati, ma è la coda 1 che sperimenta i rilasci nella colonna Drop-TH2. Queste informazioni indicano che il traffico della coda 0 non è stato influenzato da questa congestione e che la causa della congestione è in particolare il traffico della coda 1.
Modifica dei buffer per risolvere le perdite di output
Moltiplicatore SoftMax
Per aumentare il numero di buffer che ogni coda può richiedere dallo shared pool, aumentare la soglia SoftMax con la configurazione qos queue-softmax-moltiplicatore <100 - 1200>. Il valore più alto è 1200 e aumenta di un multiplo di 12, la capacità di una singola coda di assorbire micro-burst. Questo comando aumenta le soglie della coda delle porte in modo che la coda delle porte possa utilizzare unità buffer aggiuntive dal pool condiviso. Come mostrato nell'immagine 4, la configurazione e l'allocazione di buffer aumentata.
9300(config)#qos queue-softmax-multiplier 1200
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:3 - 14400
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 6 200 9 9600 2 600 0 0 1 15000
1 1 5 0 10 14400 2 900 1 450 1 15000
2 1 5 0 6 0 0 0 0 0 1 15000
3 1 5 0 6 0 0 0 0 0 1 15000
4 1 5 0 6 0 0 0 0 0 1 15000
5 1 5 0 6 0 0 0 0 0 1 15000
6 1 5 0 6 0 0 0 0 0 1 15000
7 1 5 0 6 0 0 0 0 0 1 15000
Immagine 4. Configurazione coda con Moltiplicatore SoftMax di 1200
Si tratta di una configurazione comune utilizzata come metodo rapido per risolvere le perdite di output. Nell'immagine 4, questa configurazione si applica a tutte le code non prioritarie su tutte le interfacce. Lo stesso processo di allocazione dei buffer presume che i micro-burst non si verifichino contemporaneamente su tutte le porte dello switch. Se i micro-burst si verificano in momenti casuali, il buffer condiviso può dedicare unità di buffer aggiuntive per assorbirli.
Modifica buffer per coda
La modifica del buffer per coda può essere utilizzata in scenari in cui non è possibile utilizzare il moltiplicatore SoftMax o in scenari in cui si tenta di ottimizzare i buffer per adattarli a un profilo di traffico. Per modificare l'allocazione del buffer della coda, lo switch per singola interfaccia, è necessario utilizzare le mappe dei criteri. Nella maggior parte dei casi, è possibile modificare la mappa dei criteri corrente di un'interfaccia e modificare i buffer per singola classe.
Nell'esempio, l'interfaccia Gigabit Ethernet1/0/48 ha registrato una perdita di output. Come mostrato nell'immagine 5, la mappa dei criteri in uscita applicata a questa interfaccia.
policy-map MYPOL
class Voice
priority level 1 percent 20
class Video
priority level 2 percent 10
class Control
bandwidth percent 10
class Data
bandwidth percent 5
class class-default
Immagine 5. Esempio di mappa dei criteri
Questa mappa dispone di 5 mappe di classe, che danno come risultato 5 code di uscita totali sull'interfaccia. A ogni classe è assegnato un numero predefinito di buffer in base al livello di priorità.
Nell'immagine 6 vengono visualizzate le allocazioni correnti del buffer.
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:3 - 600
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 7 100 9 100 0 0 0 0 3 800
1 1 7 100 10 400 19 237 0 0 3 800
2 1 5 0 10 400 19 237 8 100 3 800
3 1 5 0 10 400 19 237 8 100 3 800
4 1 5 0 10 400 19 237 8 100 3 800
5 1 5 0 6 0 0 0 0 0 3 800
6 1 5 0 6 0 0 0 0 0 3 800
7 1 5 0 6 0 0 0 0 0 3 800
Immagine 6. Configurazione buffer coda con il criterio di esempio
Poiché l'interfaccia ha registrato cali di output, esaminare le statistiche di coda dell'interfaccia per individuare la congestione.
9300#show platform hardware fed switch active qos queue stats interface gigabitEthernet 1/0/48
DATA Port:0 Enqueue Counters
---------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 489094 0
1 0 0 0 4846845 0
2 0 0 0 89498498 0
3 0 0 0 21297827045 0
4 0 0 0 74983184 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
DATA Port:0 Drop Counters
-------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0
1 0 0 0 0 0 0
2 0 0 0 0 0 0
3 0 0 3854484 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
Immagine 7. Statistiche del buffer di coda con drop con un criterio di esempio
L'immagine 7 mostra che la coda 3 ha più traffico in coda di qualsiasi altra coda ed è anche l'unica che ha sperimentato cali di output. Poiché il numero di coda inizia da 0, la coda 3 è mappata alla quarta mappa di classe, Class Data.
Per ridurre gli scarti nella coda, allocare più buffer alla coda 3. Per modificare l'allocazione del buffer, utilizzare la configurazione del rapporto tra i buffer della coda <0-100> nella mappa dei criteri. Se configurata per ogni classe del criterio, la relativa somma deve essere pari a 100. Se si configura una sola classe con questo comando, il sistema tenterà di sottrarre uniformemente i buffer dalle altre code.
Nell'immagine 8, la classe Data è stata configurata con un rapporto di buffer della coda pari a 40.
policy-map MYPOL
class Voice
priority level 1 percent 20
class Video
priority level 2 percent 10
class Control
bandwidth percent 10
class Data
bandwidth percent 5
queue-buffers ratio 40
Immagine 8. Esempio di mappa dei criteri con buffer di coda modificati
Nell'immagine 9 è possibile vedere che la classe Data ora ha il 40% dei buffer di interfaccia, 800 buffer totali.
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:3 - 1200
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 7 75 9 75 0 0 0 0 3 1600
1 1 7 75 10 300 19 178 0 0 3 1600
2 1 5 0 10 300 19 178 8 75 3 1600
3 1 5 0 7 800 19 475 8 200 3 1600
4 1 5 0 10 300 19 178 8 75 3 1600
5 1 5 0 6 0 0 0 0 0 3 1600
6 1 5 0 6 0 0 0 0 0 3 1600
7 1 5 0 6 0 0 0 0 0 3 1600
Immagine 9. Configurazione del buffer della coda con il criterio di esempio aggiornato
In questo modo anche le altre code avranno meno buffer Softmax. È importante apportare queste modifiche al buffer con piccoli incrementi per garantire che le modifiche non provochino perdite di output sulle altre code.
Dopo aver apportato la modifica, controllare lo stato della coda e verificare se le modifiche aumentano ancora in questa o in altre code. Se le interruzioni continuano, modificare ulteriormente la configurazione del buffer della coda fino a risolvere le interruzioni dell'output.
Metodi alternativi per gestire la congestione
QoS è principalmente un metodo per assegnare priorità al traffico e non è una soluzione per tutti gli scenari di perdita di output. In alcuni scenari la modifica dei buffer della coda non è sufficiente per risolvere tutte le perdite di output. In questi scenari è possibile gestire la congestione in diversi altri modi:
- Ridurre la percentuale di sottoscrizione in eccesso.
Ciò include metodi che aumentano la larghezza di banda in uscita, ad esempio i canali delle porte o Equal Cost Multipath (ECMP), ma che possono richiedere anche configurazioni più complesse, ad esempio la progettazione del traffico.
- Utilizzare uno scheduler di coda per assegnare la priorità al traffico.
Sebbene l'utilità di pianificazione delle code non arresti la congestione, protegge il traffico importante dall'impatto della congestione
- Utilizzare algoritmi di gestione della congestione, ad esempio WRED (Weighted Random Early Discard) o WTD (Weighted Tail Drop), per eliminare in anticipo parte del traffico.
- Controllare il traffico in entrata per ridurre il traffico in uscita.
Analisi delle perdite di output con Wireshark
Wireshark è uno strumento utile per identificare picchi di traffico che causano congestione e cadute del buffer. Se si espande un'interfaccia in direzione di uscita mentre sperimenta delle cadute, Wireshark può rappresentare graficamente la velocità di output per vedere quando e quale traffico ha attivato le cadute. Ciò è particolarmente utile quando si identificano cali di output in scenari di basso throughput.
Visualizza velocità I/O
Una volta aperta l'acquisizione SPAN con Wireshark, selezionare Statistics, quindi I/O Graph, come mostrato nell'Immagine 10.

Immagine 10. Selezione del grafico I/O
Una volta selezionato, Wireshark genera un grafico del traffico in bit al secondo. L'immagine 11 mostra un grafico di esempio per un'interfaccia che ha sperimentato cali di output.

Immagine 11. Bit/millisecondo del grafico I/O
Il grafico dell'immagine 11 indica che l'interfaccia ha un throughput massimo che supera appena gli 80 Mbps. La visualizzazione predefinita del grafico non è sufficientemente granulare per identificare piccoli picchi di traffico che causano la perdita di pacchetti. Media della velocità del traffico al secondo. Per comprendere come questa frequenza possa causare congestione del buffer, considerare il throughput su una scala di millisecondi.
Un'interfaccia Gigabit può inoltrare 1.000.000.000 di bit al secondo. Una volta convertiti in millisecondi, questo valore equivale a 1.000.000 (o 10^6) bit per millisecondo.
Quando la velocità dell'interfaccia supera la velocità di inoltro dell'interfaccia, gli switch devono memorizzare questi pacchetti nel buffer, con congestione e perdite di output.
Visualizza frequenza I/O in millisecondi
Wireshark consente all'utente di rappresentare graficamente la velocità di I/O in bit per millisecondo. A tale scopo, ridurre l'intervallo da 1 sec a 1 ms, quindi fare clic su Reimposta per visualizzare correttamente il grafico. Questo passaggio è illustrato nell'immagine 12.

Immagine 12. Riduzione dell'intervallo a 1 ms e ripristino del grafico
Il grafico aggiornato mostra in modo più accurato la velocità di I/O effettiva dell'interfaccia. Quando la velocità raggiunge o supera 10^6 bit per millisecondo, lo switch subisce una congestione o un calo dell'output. L'immagine 13 mostra il grafico I/O aggiornato di un'interfaccia che ha sperimentato cali di output.

Immagine 13. Bit/millisecondo del grafico I/O
L'immagine 13 mostra che sono presenti più picchi di traffico che soddisfano o superano la soglia 10^6. Il traffico sarebbe soggetto a buffer e verrebbe interrotto se superasse le dimensioni del nostro buffer di uscita.
Nota: Se la destinazione SPAN è connessa da un'interfaccia a 1 Gbps, la velocità di I/O in Wireshark non può superare la velocità di 10^6 bit per millisecondo, indipendentemente dalla velocità dell'interfaccia di origine. L'interfaccia di destinazione SPAN memorizza nel buffer o scarta i pacchetti. È comune vedere il grafico di I/O plateau al throughput massimo oppure presentare una velocità di traffico media che sembra aumentare.