Questo documento chiarisce come un router calcola le dimensioni del limite di coda quando le funzionalità di coda per-VC sono abilitate su un'interfaccia router ATM che supporta IP to ATM Class of Service (CoS). La CLI QoS (Modular Quality of Service) di Cisco (nota come MQC) viene utilizzata per configurare i criteri dei servizi da applicare a un'interfaccia logica, sia essa un'interfaccia principale, una sottointerfaccia o un circuito virtuale. Queste policy di servizio implementano alcune azioni QoS, dal policing e il shaping alla marcatura e le code.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Non sono previsti prerequisiti specifici per questo documento.
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.
Le interfacce del router Cisco con funzionalità di coda per-VC abilitate archiviano i pacchetti per un VC ATM in uno dei due gruppi di code a seconda del livello di congestione del VC:
Coda | Posizione | Metodi di accodamento | Applicazione dei criteri dei servizi | Comando da ottimizzare |
---|---|---|---|---|
Coda hardware o anello di trasmissione | Adattatore porta o modulo di rete | Solo FIFO | No | tx-ring-limit |
Coda di livello 3 | Sistema del processore di layer 3 o buffer di interfaccia | Nessuna | Sì | Varia a seconda del metodo di coda: - vc-hold-limit - limite di coda |
Per congestione si intende il riempimento dell'anello di trasmissione (tx-ring-limit). Vedere Comprensione e tuning del valore limite di anello tx.
È importante capire quando il router utilizza le code di livello 3, poiché i criteri del servizio si applicano solo ai pacchetti archiviati nelle code di livello 3. L'adattatore della porta ATM o il modulo di rete e il sistema di processori di layer 3 collaborano nel modo seguente:
L'interfaccia ATM trasmette le celle su ciascun PVC (Permanent Virtual Circuit) ATM in base alla velocità di shaping ATM.
L'interfaccia ATM conserva una coda hardware per-VC o un anello di trasmissione, in cui memorizza i pacchetti in attesa di trasmissione su quel VC.
Quando la coda dell'hardware o il circuito di trasmissione si riempiono, l'interfaccia ATM fornisce una contropressione esplicita al sistema di processore di layer 3. La contropressione per VC evita un consumo eccessivo di buffer da parte di un singolo PVC ATM. Notifica al processore di layer 3 di interrompere la rimozione dalla coda dei pacchetti destinati dal VC in uso al ring di trasmissione dell'interfaccia ATM perché la coda per VC ha raggiunto un determinato livello di occupazione. Il processore di layer 3 archivia ora i pacchetti in eccesso nelle code di layer 3. Durante questo periodo, il processore di layer 3 continua a inoltrare pacchetti destinati ad altri PVC non congestionati.
Quando l'interfaccia ATM invia i pacchetti sul ring di trasmissione e svuota il ring, di nuovo ha buffer sufficienti per memorizzare i pacchetti. Elimina la contropressione e il processore di layer 3 rimuove i nuovi pacchetti dall'interfaccia ATM.
Quando il numero totale di pacchetti memorizzati nel buffer sull'interfaccia ATM per tutti i PVC raggiunge un certo livello rispetto allo spazio totale disponibile per il buffer, l'interfaccia ATM fornisce la contropressione al livello aggregato all-VC. Questa contropressione notifica al processore di layer 3 di interrompere l'invio di pacchetti all'interfaccia ATM.
Ma soprattutto, con questo sistema di comunicazione, l'interfaccia ATM riconosce che il suo anello di trasmissione è pieno per un particolare VC e limita la ricezione di nuovi pacchetti dal sistema di processore di layer 3. Pertanto, quando la VC è congestionata, la decisione di perdita viene spostata da una decisione FIFO (First In, First Out) casuale, dell'ultimo ingresso/primo abbandono nella coda FIFO (First In, First Out) del ring di trasmissione a una decisione differenziata basata su policy di servizio a livello IP implementate dal processore di layer 3.
La coda di livello 3 ha sempre un limite di coda. Questo valore definisce il numero di pacchetti all'interno della coda. Quando la coda è piena, il router avvia un criterio di eliminazione. Questo criterio può essere tail drop o Weighted Random Early Detection (WRED). In altre parole, il limite della coda definisce il numero di pacchetti che possono essere memorizzati nella coda di livello 3 prima che inizino le eliminazioni.
Il router assegna automaticamente un valore predefinito per il limite della coda. Il valore calcolato varia in base al metodo di coda e alla piattaforma. È importante notare che il limite della coda deve essere sufficientemente piccolo da evitare l'introduzione della latenza dovuta all'accodamento, ma abbastanza grande da evitare cadute e un conseguente impatto sui flussi basati su TCP.
Su piattaforme distribuite come Cisco serie 7500 e FlexWAN, il valore predefinito varia a seconda del numero di interfacce nel sistema. Pertanto, le classi in un sistema con solo due interfacce possono ricevere più buffer rispetto a un sistema con centinaia di sottointerfacce e VC. Il router fornisce a ciascuna classe un valore minimo per assicurare un numero di buffer sufficiente per alimentare l'interfaccia alla velocità della linea. I limiti della coda rappresentano un limite di credito per l'interfaccia. In altre parole, il router alloca i buffer tra interfacce, PVC e classi in proporzione alla larghezza di banda di tali interfacce, PVC e classi. Per impostazione predefinita, i valori dei limiti di coda non sovrascrivono i buffer disponibili.
Nelle sezioni seguenti vengono illustrati in dettaglio i limiti della coda.
Sui VC ATM su piattaforme non distribuite, le code per-VC e le code di livello 3 sono abilitate per impostazione predefinita sul supporto delle versioni software Cisco IOS®. FIFO è il metodo di coda predefinito applicato alle code di livello 3 quando non è stato configurato alcun meccanismo di coda specifico. Le code di livello 3 utilizzano FIFO per impostazione predefinita poiché l'algoritmo di coda predefinito su un'interfaccia ATM è anche FIFO. In origine, queste code supportavano un limite di coda di soli 40. Questo è visibile nell'output seguente:
router#show queueing interface atm 2/0.10 Interface ATM2/0.10 VC 10/32 Queueing strategy: FIFO Output queue 0/40, 244 drops per VC
A partire dalla versione software Cisco IOS 12.1(5)T, è possibile regolare le dimensioni della coda FIFO per VC su un valore compreso tra 5 e 1024 con il comando vc-hold-queue.
Il comando queue-limit si applica solo alle classi configurate con CBWFQ (Weighted Fair Queuing) basato su classi con il comando bandwidth. Il comando queue-limit definisce il numero di pacchetti che le code di livello 3 memorizzeranno prima che inizino le eliminazioni. In altre parole, è la profondità della coda di livello 3.
Il valore predefinito del limite di coda varia a seconda della piattaforma in uso.
Cisco serie 2600, 3600, 7200 router e MC3810: Il valore predefinito è 64. Il seguente output di esempio è stato acquisito su un modulo di rete ATM nella serie 2600.
router#show queueing interface atm 2/0.10 Interface ATM2/0.10 VC 10/32 Queueing strategy: weighted fair Total output drops per VC: 1539 Output queue: 0/512/64/1539 (size/max total/threshold/drops) Conversations 0/37/128 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated)
Cisco serie 7500 e FlexWAN: Il valore predefinito viene calcolato assegnando a ciascuna classe la quota proporzionale dei buffer padre. La proporzione è basata sulla larghezza di banda allocata alla classe rispetto alla larghezza di banda dell'elemento padre. In particolare, il limite della coda è determinato dal ritardo massimo di 500 ms con una dimensione media del pacchetto di 250 byte. Ad esempio, a una classe con 1 MB di larghezza di banda viene assegnato un limite di coda pari a 1000000 / (250 x 8 x 2) = 250. È importante sottolineare che tale limite si basa anche su quanto segue:
La quantità di SRAM o di memoria del pacchetto disponibile.
La quantità di interfacce, in quanto la SRAM disponibile deve essere divisa tra le interfacce.
interface ATM9/1/0.100 point-to-point ip address 1.1.1.1 255.255.255.0 pvc 1/100 ubr 1000 service-policy out pmap flexwan#show policy-map interface atm 9/1/0.100 ATM9/1/0.100: VC 1/100 service-policy output: pmap queue stats for all priority classes: queue size 0, queue limit 75 packets output 0, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 class-map: e1 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: ip dscp 10 Priority: kbps 300, burst bytes 7500, b/w exceed drops: 0 class-map: e2 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: ip dscp 20 queue size 0, queue limit 75 packets output 0, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 bandwidth: kbps 300, weight 42 class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: any 0 packets, 0 bytes 5 minute rate 0 bps queue size 0, queue limit 33 packets output 2, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0
Nota: il Versatile Interface Processor (VIP) e il FlexWAN scelgono il valore predefinito del limite di coda e lo inviano al processore principale (ad esempio il Route Switch Processor [RSP] della serie 7500) con il primo set di statistiche sul numero di pacchetti. Di conseguenza, finché il VC ATM non trasporta il traffico, può apparire un valore errato nell'output di show policy-map interface.
LLQ (Low-Latency Queueing) implementa una garanzia sulla larghezza di banda minima e massima, configurate con il comando priority. LLQ implementa un dispositivo che limita il traffico prioritario alla sua larghezza di banda allocata durante la congestione per garantire che il traffico non prioritario, come i pacchetti di routing e altri dati, non diminuisca. Poiché il policy viene utilizzato per eliminare i pacchetti e non viene imposto il limite della coda, il comando queue-limit non può essere utilizzato con il comando priority.
WRED può essere configurato come un criterio di rilascio opzionale sui pacchetti nelle code di livello 3. È possibile configurare sia WRED che un sofisticato meccanismo di coda, ad esempio CBWFQ o LLQ (Low-latency queuing).
Sugli indirizzi VIP e FlexWAN, i parametri WRED predefiniti derivano direttamente dal limite di coda predefinito. In particolare, il valore di soglia massima è impostato su metà del limite di coda predefinito e i valori di soglia minima sono ridotti proporzionalmente.
Inoltre, i valori di soglia WRED predefiniti tengono conto dei parametri di shaping ATM associati al VC. Per adattarsi a burst più grandi che possono apparire a frequenze più alte, maggiore è la velocità di shaping del VC, maggiori sono le soglie minime e massime predefinite. Ad esempio, con un ATM a 10 kbps, di seguito sono riportati i parametri WRED predefiniti applicati al VC in un router specifico:
nf-7505-1# show running-config interface ATM1/1/0.47 point-to-point atm pvc 47 0 47 aal5snap 10 10 1 random-detect wredgroup1 nf-7505-1# show queueing red VC 0/47 - random-detect group default: exponential weight 9 precedence min-threshold max-threshold mark-probability --------------------------------------------------------------- 0: 20 40 1/10 1: 22 40 1/10 2: 24 40 1/10 3: 26 40 1/10 4: 28 40 1/10 5: 30 40 1/10 6: 32 40 1/10 7: 34 40 1/10
A titolo di confronto, di seguito sono riportati i parametri WRED predefiniti applicati dallo stesso router a un VC con forma a 9 Mbps di velocità cellulare sostenuta (SCR) e a 10 Mbps di velocità cella massima (PCR):
nf-7505-1#show running-config interface ATM1/1/0.49 point-to-point atm pvc 49 0 49 aal5snap 10000 9000 100 random-detect wredgroup3 nf-7505-1#show queueing red VC 0/49 - random-detect group default: exponential weight 9 precedence min-threshold max-threshold mark-probablity --------------------------------------------------------------- 0: 72 144 1/10 1: 81 144 1/10 2: 90 144 1/10 3: 99 144 1/10 4: 108 144 1/10 5: 117 144 1/10 6: 126 144 1/10 7: 135 144 1/10
Il limite di coda definisce il numero massimo di pacchetti che le code di livello 3 possono archiviare in un determinato momento. La soglia massima definisce la profondità media massima della coda. Quando si modifica il limite della coda, assicurarsi di regolare anche le soglie WRED e che il limite della coda configurato sia maggiore delle soglie WRED max.
Anche su un sistema VC configurato con WRED, tutti i pacchetti che arrivano a un VC quando le dimensioni medie della coda sono superiori al limite vengono scartati. Pertanto, nella seguente configurazione, il limite di coda di 400 e la soglia minima di 460 per il Differentiated Services Code Point (DSCP) 32 implementa una caduta finale con una dimensione media della coda di 400 pacchetti e impedisce effettivamente a WRED di avere effetto.
policy-map ppwe class voip priority 64 class bus bandwidth 168 random-detect dscp-based random-detect exponential-weighting-constant 10 random-detect dscp 8 11 66 1 random-detect dscp 32 460 550 1 queue-limit 400
Nota: vedere anche Considerazioni sull'ottimizzazione WRED nella Guida di progettazione IP to ATM Class of Service Phase 1 quando si regolano i valori di soglia predefiniti.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
15-Nov-2007 |
Versione iniziale |