La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritta l'applicazione dei comandi bandwidth e
priority in una mappa dei criteri dell'interfaccia della riga di comando quality of service modulare.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
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.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Premesse
I comandi bandwidth e priority definiscono entrambe le azioni che possono essere applicate all'interno di una mappa dei criteri MQC (Modular Quality of Service Command-Line Interface), che possono essere applicate a un'interfaccia, a una sottointerfaccia o a un circuito virtuale (VC) tramite il
service-policy comando. In particolare, questi comandi forniscono una garanzia di larghezza di banda ai pacchetti che soddisfano i criteri di una classe di traffico. Tuttavia, i due comandi hanno importanti differenze funzionali in queste garanzie. Questa nota tecnica spiega queste differenze e come la larghezza di banda non utilizzata di una classe viene distribuita ai flussi che corrispondono ad altre classi.
Riepilogo delle differenze
Nella tabella seguente vengono elencate le differenze funzionali tra i comandi
bandwidth e
priority :
Funzione | larghezzaDiBandaComando | ComandoPriorità |
---|---|---|
Garanzia larghezza di banda minima | Sì | Sì |
Massima garanzia di larghezza di banda | No | Sì |
Policer integrato | No | Sì |
Fornisce bassa latenza | No | Sì |
Inoltre, i comandi
bandwidth e priority sono progettati per soddisfare diversi obiettivi di policy QoS (Quality of Service). Nella tabella seguente sono elencati i diversi obiettivi:
Applicazione | larghezzaDiBandaComando | ComandoPriorità |
---|---|---|
Gestione della larghezza di banda per i collegamenti WAN | Sì | In qualche modo |
Gestire il ritardo e le variazioni del ritardo (jitter) | No | Sì |
Miglioramento dei tempi di risposta delle applicazioni | No | Sì |
Anche con le interfacce veloci, la maggior parte delle reti ha ancora bisogno di un forte modello di gestione QoS per gestire in modo efficace i punti di congestione e i colli di bottiglia che inevitabilmente si verificano a causa di mancata corrispondenza della velocità o di diversi modelli di traffico. Le reti del mondo reale hanno risorse limitate e colli di bottiglia delle risorse e necessitano di politiche QoS per garantire una corretta allocazione delle risorse.
Configurazione del comando della larghezza di banda
Le guide alla configurazione di Cisco IOS ®
bandwidth descrivono il comando come la "quantità di larghezza di banda, in kbps, da assegnare alla classe. . . per specificare o modificare la larghezza di banda allocata per una classe che appartiene a una mappa dei criteri."
Guardate cosa significano queste definizioni.
Il
bandwidth comando garantisce una larghezza di banda minima durante la congestione. La sintassi del comando è in tre forme, come illustrato nella tabella seguente:
Sintassi dei comandi | Descrizione |
---|---|
bandwidth {kbps} |
Specifica l'allocazione della larghezza di banda come velocità in bit. |
bandwidth percent {value} |
Specifica l'allocazione della larghezza di banda come percentuale della velocità del collegamento principale. |
bandwidth remaining percent {value} |
Specifica l'allocazione della larghezza di banda come percentuale della larghezza di banda non allocata ad altre classi. |
Nota: il comando bandwidth definisce un comportamento, ovvero una garanzia di larghezza di banda minima. Non tutte le piattaforme router Cisco utilizzano weighted-fair queueing (WFQ) come algoritmo principale per implementare questo comportamento. Per ulteriori informazioni, vedere Perché utilizzare CBWFQ?
Configurazione del comando Priority
Le guide alla configurazione di Cisco IOS descrivono il comando priority come una riserva per "una coda di priorità con una quantità specificata di larghezza di banda disponibile per il traffico CBWFQ...per dare priorità a una classe di traffico in base alla quantità di larghezza di banda disponibile in un criterio del traffico." Nell'esempio seguente viene illustrato il significato di tali definizioni.
È possibile creare una coda di priorità con i seguenti gruppi di comandi:
Router(config)#policy-map policy-name
Router(config-pmap)#class class-name
Router(config-pmap-c)#priority kpbs [bytes]
Durante le condizioni di congestione, alla classe di traffico viene garantita una larghezza di banda pari alla velocità specificata. (Tenere presente che le garanzie della larghezza di banda sono un problema solo quando un'interfaccia è congestionata.) In altre parole, il
priority comando garantisce una larghezza di banda minima.
Inoltre, il
priority comando implementa una garanzia di larghezza di banda massima. Internamente, la coda di priorità utilizza un bucket di token che misura il carico offerto e garantisce che il flusso di traffico sia conforme alla velocità configurata. La bassa latenza è garantita solo per il traffico conforme al bucket di token. L'eventuale traffico in eccesso viene inviato se il collegamento non è congestionato o viene interrotto in caso di congestione del collegamento. Per ulteriori informazioni, vedere Che cos'è un bucket di token?
Lo scopo del policer incorporato è garantire che le altre code siano servite dall'utilità di pianificazione delle code. Nella funzionalità originale di Cisco priority queueing, che utilizza i comandi
priority-group and
priority-list , lo scheduler ha sempre servito per primo la coda con priorità più alta. In casi estremi, le code con priorità inferiore raramente venivano servite ed effettivamente venivano private della larghezza di banda.
Il vero vantaggio del
priority comando, e la sua differenza principale rispetto al
bandwidth comando stesso, è rappresentato dal modo in cui fornisce una rigida priorità di rimozione dalla coda per fornire un limite alla latenza. Di seguito viene riportata la descrizione di questo vantaggio nella Guida alla configurazione di Cisco IOS: "Una coda a priorità rigida (PQ) consente di rimuovere dalla coda dati sensibili al ritardo, ad esempio la voce, e di inviarli prima che i pacchetti di altre code vengano rimossi dalla coda". Guardate cosa significa.
Ogni interfaccia del router conserva questi due gruppi di code:
Coda | Posizione | Metodi di coda | Applicazione dei criteri dei servizi | Comando da ottimizzare |
---|---|---|---|---|
Anello di trasmissione o coda hardware | Adattatore porta o modulo di rete | Solo FIFO | No | tx-ring-limit |
Coda di livello 3 | Buffer di interfaccia o sistema del processore di layer 3 | WFQ basato sul flusso, CBWFQ, LLQ | Sì | Varia a seconda del metodo di coda. Usare il comando queue-limit con una classe di larghezza di banda. |
Dalla tabella precedente si evince che una regola del servizio si applica solo ai pacchetti nella coda di layer 3.
Per rimozione dalla coda rigida si intende l'utilità di pianificazione che gestisce la coda di priorità e inoltra per prima i relativi pacchetti all'anello di trasmissione. L'anello di trasmissione è l'ultimo stop prima del supporto fisico.
Nella figura seguente, l'anello di trasmissione è stato configurato per contenere quattro pacchetti. Se ci sono già tre pacchetti sul ring, allora al massimo possiamo mettere in coda per la quarta posizione e poi aspettare che gli altri tre si svuotino. Pertanto, il meccanismo LLQ (Low Latency Queueing) si limita a rimuovere i pacchetti dalla coda nella coda FIFO (First-In, First-Out) a livello di driver nell'anello di trasmissione.
Usare il
tx-ring-limit comando per regolare le dimensioni dell'anello di trasmissione su un valore non predefinito. Cisco consiglia di sintonizzare l'anello di trasmissione quando si trasmette il traffico vocale.
L'assegnazione di priorità al traffico è particolarmente importante per le applicazioni interattive basate sulle transazioni sensibili ai ritardi. Per ridurre al minimo il ritardo e l'effetto jitter, i dispositivi di rete devono essere in grado di servire i pacchetti voce appena arrivano, o in altre parole in modo assolutamente prioritario. Solo una priorità rigorosa è adatta alla voce. A meno che i pacchetti voce non vengano immediatamente rimossi dalla coda, ciascun hop può introdurre un ritardo maggiore.
L'Unione Internazionale delle Telecomunicazioni (ITU) consiglia un ritardo end-to-end unidirezionale massimo di 150 millisecondi. Senza l'immediata rimozione dalla coda sull'interfaccia del router, un singolo hop sul router può coprire la maggior parte di questo budget di ritardo. Per ulteriori informazioni, fare riferimento al supporto per la qualità vocale.
Nota: con entrambi i comandi, il valore kbps deve tenere conto del sovraccarico del layer 2. In altre parole, se viene fornita una garanzia a una classe, tale garanzia è relativa al throughput di layer 2.
Classi Di Traffico Che Possono Utilizzare La Larghezza Di Banda In Eccesso
Anche se le garanzie di larghezza di banda fornite dai comandi
bandwidth and
priority sono state descritte con parole come "riservato" e "larghezza di banda da lasciare da parte", nessuno dei due comandi implementa una vera prenotazione. In altre parole, se una classe di traffico non utilizza la larghezza di banda configurata, qualsiasi larghezza di banda inutilizzata viene condivisa tra le altre classi.
Il sistema di coda impone un'eccezione importante a questa regola con una classe di priorità. Come accennato in precedenza, il carico offerto di una classe di priorità viene misurato da un sorvegliante del traffico. Durante le condizioni di congestione, una classe di priorità non può utilizzare larghezza di banda in eccesso.
Questa tabella descrive quando una classe di larghezza di banda e una classe di priorità possono utilizzare una larghezza di banda in eccesso:
Comando | Congestione | Non congestione |
---|---|---|
larghezzaDiBandaComando | Consente di superare il tasso allocato. | Consente di superare il tasso allocato. |
ComandoPriorità | Cisco IOS misura i pacchetti e applica un sistema di misurazione del traffico tramite un bucket di token. I pacchetti corrispondenti vengono controllati in base alla velocità in bps configurata e tutti i pacchetti in eccesso vengono eliminati. | La classe può superare la larghezza di banda configurata. |
Nota: un'eccezione a queste linee guida per LLQ è Frame Relay su Cisco 7200 router e altre piattaforme non Route/Switch Processor (RSP). L'implementazione originale di LLQ su Frame Relay su queste piattaforme non ha consentito alle classi di priorità di superare la velocità configurata durante i periodi di non congestione. Il software Cisco IOS versione 12.2 rimuove questa eccezione e garantisce che i pacchetti non conformi vengano scartati solo in caso di congestione. Inoltre, i pacchetti di dimensioni inferiori alla frammentazione FRF.12 non vengono più inviati attraverso il processo di frammentazione e ciò riduce l'utilizzo della CPU.
Dalla discussione precedente, è importante capire che, poiché le classi di priorità vengono controllate durante le condizioni di congestione, non viene assegnata loro alcuna larghezza di banda rimanente dalle classi di larghezza di banda. Pertanto, la larghezza di banda rimanente viene condivisa da tutte le classi di larghezza di banda e da class-default.
Allocazione della larghezza di banda non utilizzata
Questa sezione spiega come il sistema di coda distribuisce l'eventuale larghezza di banda rimanente. Di seguito viene riportata la descrizione della funzionalità di coda equa ponderata basata su classi relativa al meccanismo di allocazione: "Se è disponibile una larghezza di banda eccessiva, questa viene suddivisa tra le classi di traffico in base alla larghezza di banda configurata. Se non viene allocata tutta la larghezza di banda, la larghezza di banda rimanente viene ripartita proporzionalmente tra le classi in base alla larghezza di banda configurata." Guardate due esempi.
Nel primo esempio, policy-map foo garantisce il 30% della larghezza di banda alla barra di classe e il 60% della larghezza di banda alla baz di classe.
policy-map foo
class bar
bandwidth percent 30
class baz
bandwidth percent 60
Se si applica questo criterio a un collegamento a 1 Mbps, alla barra di classe verranno garantiti 300 kbps e alla barra di classe 600 kbps. È importante notare che 100 kbps sono rimanenti per class-default. Se class-default non ne ha bisogno, il valore inutilizzato 100 kbps è disponibile per l'uso da parte di class bar e class baz. Se entrambe le classi necessitano della larghezza di banda, la condividono in proporzione alle velocità configurate. In questa configurazione, il rapporto è condiviso di 30:60 o 1:2.
La configurazione di esempio seguente contiene tre mappe criteri: bar, baz e poli. Nella mappa dei criteri denominata bar e nella mappa dei criteri denominata baz, la larghezza di banda è specificata in percentuale. Tuttavia, nella mappa dei criteri denominata poli, la larghezza di banda è specificata in kbps.
Tenere presente che le mappe di classe devono essere già state create prima di creare le mappe di criteri.
policy-map bar
class voice
priority percent 10
class data
bandwidth percent 30
class video
bandwidth percent 20
policy-map baz
class voice
priority percent 10
class data
bandwidth remaining percent 30
class video
bandwidth remaining percent 20
policy-map poli
class voice
class data
bandwidth 30
class video
bandwidth 20
Nota: il comando larghezza di banda rimanente in percentuale è stato introdotto in Cisco IOS versione 12.2(T).
Utilizzare il comando Police per impostare un valore massimo
Se la larghezza di banda o la classe di priorità non deve superare la larghezza di banda allocata durante i periodi di assenza di congestione, è possibile combinare il
priority comando con il
police comando. Questa configurazione impone una velocità massima sempre attiva sulla classe. La scelta di configurare un'
police istruzione in questa configurazione dipende dall'obiettivo del criterio.
Comprendere il valore della larghezza di banda disponibile
In questa sezione viene spiegato come il sistema di coda deriva il valore Larghezza di banda disponibile, come mostrato nell'output del comando
show interface
o
show queueing .
Abbiamo creato questa mappa dei criteri chiamata Leslie:
7200-16#show policy-map leslie
Policy Map leslie
Class voice
Weighted Fair Queueing
Strict Priority
Bandwidth 1000 (kbps) Burst 25000 (Bytes)
Class data
Weighted Fair Queueing
Bandwidth 2000 (kbps) Max Threshold 64 (packets)
Abbiamo quindi creato un PVC (Permanent Virtual Circuit) ATM, lo abbiamo assegnato alla categoria di servizi ATM con velocità in bit variabile e non in tempo reale e abbiamo configurato una velocità di cella sostenuta di 6 Mbps. Abbiamo quindi applicato la mappa delle policy al PVC con il
service-policy output leslie comando.
7200-16(config)#interface atm 4/0.10 point
7200-16(config-subif)#pvc 0/101
7200-16(config-if-atm-vc)#vbr-nrt 6000 6000
7200-16(config-if-atm-vc)#service-policy output leslie
show queueing interface atm Il comando visualizza Larghezza di banda disponibile 1500 kilobit/sec.
7200-16#show queue interface atm 4/0.10
Interface ATM4/0.10 VC 0/101
queue strategy: weighted fair
Output queue: 0/512/64/0 (size/max total/threshold/drops)
Conversations 0/0/128 (active/max active/max total)
Reserved Conversations 1/1 (allocated/max allocated)
Available Bandwidth 1500 kilobits/sec
Di seguito viene illustrato come viene derivato questo valore:
-
6 Mbps è la velocità di cella sostenuta (SCR). Per impostazione predefinita, il 75% di questo valore è impegnabile:
0.75 * 6000000 = 4500000
-
3000 kbps è già utilizzato dalle classi voce e dati:
4500000 - 3000000 = 1500000 bps
-
La larghezza di banda disponibile è 1500000 bps.
Il valore predefinito del 75% per la larghezza di banda massima riservata è progettato in modo da lasciare una larghezza di banda sufficiente per il traffico di sovraccarico, ad esempio gli aggiornamenti del protocollo di routing e i pacchetti keepalive di layer 2. Copre anche il sovraccarico del layer 2 per i pacchetti che corrispondono e che sono classi di traffico definite o la classe predefinita della classe. Ora è possibile aumentare il valore della larghezza di banda massima riservabile sui PVC ATM con il
max-reserved-bandwidth comando. Per le versioni supportate di Cisco IOS e ulteriori informazioni di base, consultare Comprendere il comando max-reserve-bandwidth sul PVC ATM.
Sui PVC Frame Relay, i comandi
bandwidth e
priority calcolano la quantità totale di larghezza di banda disponibile in uno dei modi seguenti:
-
Se non è configurata una velocità minima di commit delle informazioni accettabile (minCIR), il CIR viene diviso per due.
-
Se è stato configurato un valore minCIR, nel calcolo viene utilizzata l'impostazione minCIR. L'intera larghezza di banda della velocità precedente può essere assegnata alle classi di larghezza di banda e priorità.
Pertanto, il
max-reserved-bandwidth comando non è supportato sui PVC Frame Relay, anche se è necessario verificare che la quantità di larghezza di banda configurata sia sufficiente per supportare il sovraccarico di layer 2. Per ulteriori informazioni, consultare il documento sulla configurazione di CBWFQ sui PVC Frame Relay.
Informazioni correlate
Revisione | Data di pubblicazione | Commenti |
---|---|---|
3.0 |
30-Aug-2023 |
Errori di battitura corretti. Certificazione. |
2.0 |
04-Apr-2023 |
Formato aggiornato, CCW corretto. Certificazione. |
1.0 |
27-Nov-2001 |
Versione iniziale |