Verifica dei comandi di larghezza di banda e priorità di una policy di qualità del servizio (QoS)

Introduzione

In questo documento viene descritta la modalità di 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

In questa tabella vengono elencate le differenze funzionali tra i comandi bandwidth e priority :

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:

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:

bandwidth {kbps}

bandwidth percent {value}

bandwidth remaining percent {value}

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 PQ (strict priority queue) consente di rimuovere dalla coda i 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:

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 di 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:

Nota: Un'eccezione a queste linee guida per LLQ è Frame Relay su router Cisco 7200 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 interfaceoshow 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:

1. 6 Mbps è la velocità di cella sostenuta (SCR). Per impostazione predefinita, il 75% di questo valore è impegnabile:

   0.75 * 6000000 = 4500000
   

2. 3000 kbps è già utilizzato dalle classi voce e dati:

   4500000 - 3000000 = 1500000 bps
   

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

• Supporto tecnico Cisco e download