bandwidth percent and bandwidth remaining percentIl WTD controlla quando i pacchetti in coda vengono scartati, mentre i buffer di coda determinano la quantità di traffico a raffica che può essere gestita.Se gli utenti segnalano cali di output, ritardi nella voce o una policy QoS che sembra inefficace, verificare separatamente la classificazione del traffico, i pesi di pianificazione delle code, le code prioritarie, le soglie WTD, i buffer delle code e l'installazione delle policy hardware.
Cosa significa "Round Robin ponderato" su Catalyst 9200/9300
Uno switch può avere diverse classi di traffico in competizione per la stessa interfaccia di uscita. Quando l'interfaccia si congestiona, i pacchetti vengono inseriti in code e lo scheduler determina quale coda verrà servita successivamente.
Un peso di pianificazione più elevato offre a una coda maggiori opportunità di utilizzare la larghezza di banda disponibile. Questo è il concetto che molti utenti descrivono come round robin ponderato.
Sulle piattaforme Catalyst 9200 e 9300, la configurazione pratica si basa generalmente su bandwidth percent, bandwidth remaining percent, bandwidth remaining ratiocode prioritarie, limiti delle code e allocazione del buffer delle code.
I comandi esatti e i parametri supportati dipendono dalla versione di IOS XE e dalla piattaforma. Controllare la documentazione software applicabile prima di implementare una policy QoS su un Interruttore Cisco Catalyst 9200.
Pianificazione delle code, code prioritarie e WTD
La pianificazione delle code, il trattamento prioritario e il Weighted Tail Drop risolvono problemi diversi. Aumentare il peso di una coda non correggerà una mappatura DSCP-coda errata, e modificare una soglia WTD non creerà ulteriore larghezza di banda fisica.
| Meccanismo | Scopo principale | Cosa non risolve |
|---|---|---|
| Programmazione del peso | Condivide la larghezza di banda tra le code | Classificazione del traffico errata |
| Coda di priorità | Garantisce un trattamento preferenziale al traffico critico | Congestione illimitata |
| WTD | Interrompe il traffico una volta superate le soglie della coda. | Mancanza di larghezza di banda fisica |
| rapporto del buffer di coda | Assegna spazio buffer per i burst | Garantisce una velocità di trasmissione |
| Mappatura DSCP/COS | Mette in coda il traffico | Controllo coda ordine di servizio |
WTD utilizza marcatori di traffico per applicare diverse soglie di coda. Quando una coda raggiunge la soglia associata a una classe di traffico, i nuovi pacchetti possono essere scartati anche se l'interfaccia fisica rimane operativa.
Cisco Guida alla configurazione QoS del Catalyst 9300 Descrive l'allocazione della larghezza di banda, la pianificazione delle code, il trattamento delle priorità e il comportamento WTD per le politiche QoS di Catalyst.
Come i pesi della larghezza di banda influenzano le code di uscita
Percentuale di larghezza di banda
bandwidth percent Assegna una percentuale minima di larghezza di banda a una classe. Se le percentuali configurate non consumano l'intera allocazione disponibile, la larghezza di banda rimanente può essere condivisa da altre code di larghezza di banda.
Questo metodo è utile quando la policy deve riservare una porzione prevedibile di un'interfaccia di uscita per una classe di traffico.
Percentuale di larghezza di banda rimanente
bandwidth remaining percent È utile quando una policy contiene anche una coda prioritaria. Assegna una quota relativa della larghezza di banda rimanente alle code non prioritarie.
Ad esempio, ai video, ai dati aziendali e al traffico di massa potrebbero essere assegnati valori relativi di 40, 40 e 20. In condizioni di contesa, le code video e dati aziendali ricevono una quota maggiore della larghezza di banda rimanente rispetto alla coda del traffico di massa.
Questi valori rappresentano dei pesi, non cifre di throughput garantite. Una coda può utilizzare più larghezza di banda quando altre code sono inattive, a seconda delle policy e del comportamento della piattaforma.
Allocazione del buffer della coda
I buffer delle code sono diversi dai pesi di banda. Una coda può avere un peso di pianificazione sufficiente, ma scartare comunque pacchetti durante un breve picco se il buffer disponibile si esaurisce.
- Traffico di backup e replica dello storage
- Video a raffica
- Collegamenti uplink ad alta velocità che alimentano porte a velocità inferiore.
- Molteplici porte di accesso convergenti su un'unica interfaccia di uscita.
Un esempio pratico di policy QoS
L'esempio seguente illustra come organizzare le classi di traffico e i pesi della larghezza di banda rimanente. Non si tratta di un modello di produzione universale. Prima di applicarlo, verificare la sintassi supportata dalla versione di IOS XE installata.
Prima di applicare una policy simile, verificare che le marcature DSCP siano affidabili, che le class-map corrispondano al traffico previsto, che l'interfaccia supporti le funzionalità QoS selezionate e che la policy non combini tipi di larghezza di banda incompatibili.
Un'alta densità Cisco Catalyst 9300L-48P-4X-E può aggregare più traffico di un Catalyst 9200 di livello di accesso. Il punto di congestione può quindi verificarsi su un uplink a 10G, su una porta endpoint a 1G o su una porta downstream, a seconda della topologia.
Come verificare il comportamento della coda
Conferma che la polizza è allegata
Iniziate con la configurazione dell'interfaccia e dei criteri. Verificate che i criteri siano applicati nella direzione corretta e che i contatori delle classi previsti siano in aumento.
Verifica le perdite a livello di interfaccia
Un elevato numero di cali di traffico in uscita di solito indica una congestione in uscita, ma i soli contatori di interfaccia potrebbero non essere sufficienti a identificare la coda o la classe di traffico interessata.
Controlla le statistiche della coda
Cerca informazioni su pacchetti scartati specifici per coda, occupazione della coda, contatori di soglia e differenze tra comportamento in ingresso e in uscita. La sintassi esatta del comando può variare a seconda della versione di IOS XE.
Verifica l'installazione dei criteri nell'hardware
Una policy può essere accettata dal parser di configurazione ma non essere installata correttamente nell'hardware. Per un'interfaccia stack, selezionare il membro switch corretto.
Uno stato come VALID,SET_INHW Indica che la policy è compresa dal software e installata nell'hardware. Uno stato non valido deve essere esaminato prima di considerare la policy attiva.
Verifica le risorse hardware
Per uno stack, sostituire active con il numero di interruttore appropriato quando necessario. Un criterio che non riesce a installarsi potrebbe essere influenzato da una sintassi non supportata, limiti delle risorse hardware o restrizioni della versione IOS XE.
Perché le code QoS scartano i pacchetti
Il traffico voce o video è in ritardo
- I valori DSCP non vengono conservati.
- Il traffico viene instradato alla coda predefinita.
- La mappatura delle classi prevista non corrisponde.
- La coda di priorità non è configurata.
- Il collegamento di uscita è sovraccarico.
Prima di modificare i pesi delle code, iniziate configurando i contatori delle policy e la mappatura delle classi.
Il traffico di massa consuma la maggior parte del collegamento
Tra le possibili cause si annoverano l'ingresso di traffico di massa in una classe ad alta priorità, pesi di banda eccessivamente generosi, classificazione errata del traffico aziendale o applicazione di una policy di servizio nella direzione sbagliata.
Nonostante il basso tasso di utilizzo medio, la produzione diminuisce.
L'utilizzo medio può nascondere i micro-burst. Brevi raffiche possono riempire una coda prima che i tassi medi a livello di interfaccia appaiano elevati.
- Esamina le statistiche della coda.
- Verifica l'allocazione del buffer.
- Cerca eventuali discrepanze di velocità.
- Verifica i modelli di traffico relativi a spazio di archiviazione, backup e video.
- Identificare più porte ad alta velocità che convergono su un'unica porta di uscita a velocità inferiore.
La policy QoS è configurata ma non ha alcun effetto
Verificare che la policy di servizio sia associata, che la direzione dell'interfaccia sia corretta, che la mappatura delle classi corrisponda ai pacchetti, che la policy sia installata nell'hardware e che i comandi selezionati siano supportati dalla versione IOS XE.
WTD causa una perdita di pacchetti imprevista
Verificare quale etichetta QoS è assegnata al traffico, quale soglia utilizza tale etichetta, se la coda sta ricevendo un picco improvviso e se l'allocazione del buffer della coda è sufficiente.
Aumentare la soglia WTD può ridurre le perdite, ma può anche consentire a una classe di traffico di consumare più spazio di buffer condiviso. Consideratelo piuttosto come una modifica di progettazione che come una soluzione universale.
Invia il modello dello switch, la versione di IOS XE, il ruolo dell'interfaccia, la policy-map e l'output di queue-drop.
Domande frequenti
show policy-map interface e lo stato obiettivo della politica della FED.Takeaway finale
Per gli switch Catalyst 9200 e 9300, l'algoritmo "weighted round robin" si analizza al meglio come una combinazione di pianificazione delle code, pesi della larghezza di banda, gestione delle priorità, soglie WTD e allocazione dei buffer.
Quando si risolve un problema di congestione, seguire questa sequenza:
- Verificare la classificazione del traffico.
- Verifica che la polizza sia allegata.
- Verificare i contatori della coda e dell'interfaccia.
- Rivedi i pesi di pianificazione e le impostazioni di priorità.
- Verifica il comportamento di WTD e del buffer.
- Verificare che la policy sia installata nell'hardware.
- Verifica le risorse hardware e la compatibilità con iOS XE.
La modifica del peso di una coda non risolverà un problema causato da una classificazione errata, un buffer insufficiente o una policy che non ha mai raggiunto l'ASIC.