Comprendere i limiti delle code e le interruzioni dell'output sulle piattaforme software IOS

Introduzione

In questo documento vengono descritti i limiti delle code e le interruzioni dell'output sulle piattaforme software Cisco IOS® e sui router di accesso legacy.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Guida alla configurazione delle soluzioni Cisco IOS® Quality of Service

• QoS—Hierarchical Queueing Framework (HQF)

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software:

• Per pre-HQF: router Cisco con software Cisco IOS versione 12.3(26)

• Per HQF: router Cisco con software Cisco IOS versione 12.4(22)T

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

Questo documento è valido solo per le piattaforme software Cisco IOS®, che in genere include i router Cisco serie 7200VXR e Cisco ISR 3800, 2800 e 1800 e i router Cisco Access legacy, che include i router serie 3700, 3600, 2600 e 1700.

Primer Fiera Ponderata Basata Su Classi

Nelle immagini Cisco IOS pre-HQF, a qualsiasi classe con un bandwidth comando viene generalmente assegnata una priorità rispetto alle classi senza larghezza di banda o priorità in base al peso delle classi. Per comprendere l'algoritmo di programmazione CBWFQ (Class-Based Weighted Fair Queueing), è necessario innanzitutto comprendere il concetto di un peso, specifico del flusso per le code eque basate sul flusso e specifico della classe per le singole code basate su classi all'interno della coda equa ponderata basata su classi.

La formula per derivare il peso per una coda equa basata sul flusso è la seguente:

32384 / (IP Prec + 1)

Le classi definite dall'utente all'interno di una coda Weighted Fair basata su classi derivano i rispettivi pesi in funzione del bandwidth comando configurato nella classe come proporzione della SOMMA di tutte le classi di larghezza di banda nella coda basata su classi. La formula esatta è proprietaria.

Nelle immagini HQF, le code eque basate sul flusso, configurabili sia nelle classi definite dall'utente che nelle classi predefinite con la coda equa, sono programmate in modo uguale (anziché in base al peso). Inoltre, in HQF, la priorità di pianificazione di una coda basata su classi viene determinata in base all'utilità di pianificazione HQF e non in base alla formula del peso legacy delle classi.

Nota: questa sezione non intende essere un'analisi del comportamento completa per le operazioni di Class Based Queueing. L'intenzione è una spiegazione di come CBWFQ applica i limiti della coda e le perdite di output.

Informazioni sui limiti delle code e sulle interruzioni di output

Classi definite dall'utente configurate con il comando Priority

Per le classi MQC definite dall'utente configurate con qualsiasi variante del priority comando, con priority, priority <kbps> e priority percentinclusi.

Comportamento pre-HQF

Tecnicamente, anche se non esiste una CLI per visualizzarla e non è configurabile, esiste una coda di sistema nascosta che è condivisa da tutti i dati della classe di priorità. Funge da archivio temporaneo per i dati prioritari dopo che sono stati classificati e dopo che sono stati consentiti dal policer in grado di riconoscere la congestione. I pacchetti LLQ vengono inseriti in questa coda di sistema nascosta se non possono essere posizionati direttamente sull'anello di trasmissione dell'interfaccia di uscita durante l'interrupt di ricezione, altrimenti chiamato congestione funzionale. In questa situazione, poiché esiste una congestione funzionale, il pacchetto viene valutato rispetto al policer condizionale LLQ durante l'interrupt di ricezione e finché è ancora di proprietà del driver dell'interfaccia ricevente. Se il pacchetto non viene scartato dal policer condizionale LLQ, viene inserito in questa coda di sistema LLQ nascosta e l'interrupt di ricezione viene rilasciato. Pertanto, tutti i pacchetti inseriti in questa coda di sistema nascosta si sono conformati al policy di riconoscimento della congestione LLQ e possono essere rimossi immediatamente dall'utilità di pianificazione LLQ/CBWFQ dall'anello di trasmissione dell'interfaccia in uscita.

Nonostante l'esistenza di questa coda, il comportamento è diverso da quello delle code Cisco IOS create per dati non LLQ (come le code di equità e larghezza di banda) in quanto non può verificarsi alcuna latenza di coda aggiuntiva (superiore alla latenza dell'anello di trasmissione) poiché i pacchetti in questa coda possono essere immediatamente scaricati nell'anello di trasmissione dall'utilità di pianificazione LLQ/CBWFQ. Se un pacchetto di classe di priorità non viene scartato dal policer condizionale durante l'interrupt di ricezione, il pacchetto LLQ può esistere brevemente in questa coda di sistema nascosta prima di essere rimosso dalla coda per l'anello di trasmissione dell'interfaccia di uscita. In questo caso, l'utilità di pianificazione LLQ/CBWFQ può presentare immediatamente il pacchetto all'anello di trasmissione dell'interfaccia di uscita. Il Policer condizionale è stato eseguito prima di ammettere il pacchetto nell'LLQ/CBWFQ, quindi limita l'LLQ alla velocità di priorità configurata.

In sintesi, si consiglia di eliminare i dati LLQ che superano la velocità di priorità nei momenti di congestione piuttosto che sostenere una latenza di coda aggiuntiva, che è un componente fondamentale di LLQ. Questo meccanismo di policy condizionale consente una coda di priorità rigida e non consente alla coda di priorità di monopolizzare l'intera interfaccia PLIM, il che rappresenta un miglioramento rispetto alla funzionalità di coda di priorità legacy di Cisco IOS.

• Limite coda pre-HQF: NA

• Priorità pre-HQF + comportamento di rilevamento casuale: NA, WRED non consentito in LLQ.

• Comportamento "priorità pre-HQF + coda equa": NA, coda equa non consentita in LLQ.

• Priorità pre-HQF + rilevamento casuale + comportamento della coda equa: NA, supporto di LLQ né fair-queue né random-detect.

Comportamento HQF

Uguale al Pre-HQF tranne che la coda nascosta non è più nascosta e il limite della coda è ora configurabile e per impostazione predefinita è di 64 pacchetti.

• Limite coda HQF: 64 pacchetti

• Priorità HQF + comportamento di rilevamento casuale: NA, WRED non consentito in LLQ.

• Priorità HQF + comportamento coda equa: NA, coda equa non consentita in LLQ.

• Priorità HQF + rilevamento casuale + comportamento della coda equa: NA, supporto di LLQ né di coda equa né di rilevamento casuale.

Classi definite dall'utente configurate con il comando Bandwidth

Per le classi MQC definite dall'utente configurate con qualsiasi variante del bandwidth comando, con bandwidth <kbps> , bandwidth percent e bandwidth remaining percentincluse.

Comportamento pre-HQF

Il limite predefinito per la coda è di 64 pacchetti, che possono essere configurati. Se, durante l'interrupt di ricezione, è necessario accodare un pacchetto che darebbe come risultato > 64 pacchetti nella coda, il pacchetto viene scartato.

• Limite di coda pre-HQF: 64 pacchetti, regolabili tramite limite di coda.

• Larghezza di banda pre-HQF + comportamento "random-detect":

Esempio:

policy-map PRE_HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   random-detect

Se viene configurata una qualsiasi variante della larghezza di banda insieme a una qualsiasi variante di random-detect, ignorare qualsiasi CLI basata su un limite di coda, rimuovendo in modo efficace qualsiasi limite di buffer nella classe. In altre parole, il rilevamento casuale e il limite della coda si escludono a vicenda nelle immagini pre-HQF. Con la strategia di rilevamento casuale come destinazione, le dimensioni della coda corrente non sono limitate e possono teoricamente occupare ogni buffer allocato alla coda equa basata su classi, dove questo numero di buffer allocati alla coda equa basata su classi viene derivato in base al punto di accesso del criterio del servizio:

• Interfaccia fisica: 1000 pacchetti, sintonizzabili con l'interfaccia CLI hold-queue out

• ATM PVC: 500 pacchetti, sintonizzabili con PVC CLI vc-hold-queue

• Classe mappa Frame Relay: 600 pacchetti, sintonizzabili con la coda di attesa Frame Relay classe mappa CLI

• Policy di shaping basato su classi applicata all'interfaccia (secondaria) (pre-HQF): 1000 pacchetti, sintonizzabili con max-buffer di forma CLI della classe MQC.

Nota: tutti gli esempi di shaping Frame Relay e basato su classi presuppongono che la somma dei shaper non superi la frequenza di clock dell'interfaccia.

Nota: nelle immagini pre-HQF, quando un criterio Class Based Shaping viene applicato a un'interfaccia (secondaria), prestare attenzione alla velocità dell'interfaccia fisica sottostante, in quanto le interfacce <2Mbps possono essere impostate per impostazione predefinita su una Coda equa ponderata e le interfacce >2Mbps possono essere impostate per impostazione predefinita su FIFO. In pre-HQF, la coda di shaping può alimentare la coda di attesa dell'interfaccia, sia che il criterio di shaping sia collegato a livello di sottointerfaccia o di interfaccia fisica.

Durante l'interrupt di ricezione, ogni volta che un pacchetto diventa candidato per una coda di output di interfaccia, le dimensioni medie della coda WRED vengono calcolate con la seguente formula:

Average Queue Size = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

Se la dimensione media della coda risultante è:

• Inferiore alla soglia minima WRED, accodare il pacchetto e rilasciare l'interrupt di ricezione.
• Tra la soglia minima WRED e la soglia massima WRED, è possibile che il pacchetto venga scartato con una probabilità maggiore quando la dimensione media della coda si avvicina alla soglia massima WRED. Se la dimensione media della coda è esattamente uguale alla soglia massima WRED, il pacchetto viene scartato in base al denominatore di probabilità del contrassegno. Il denominatore di probabilità mark serve anche come base per determinare la percentuale di pacchetti che possono essere scartati quando il limite medio della coda non è esattamente uguale alla soglia massima WRED ma è superiore alla soglia minima WRED. Questo è un esempio grafico:

Limite medio coda non uguale alla soglia massima WRED ma superiore alla soglia minima WRED

• • Se il pacchetto viene scartato, l'interrupt di ricezione viene rilasciato e una perdita casuale incrementata. Se il pacchetto non viene scartato, viene accodato e l'interrupt di ricezione viene rilasciato.

  • Superiore alla soglia massima WRED, rilasciare il pacchetto, rilasciare l'interrupt di ricezione e incrementare una perdita finale.

Nota: i valori WRED basati su IP Precedence (impostazione predefinita) e DSCP consentono di definire in modo diverso il denominatore di probabilità min-threshold, max-threshold e mark probability per valori diversi. In questo caso, la componente Weighted di Random Early Detection è evidente. È possibile proteggere determinati valori ToS relativi ad altri valori quando si regolano le relative soglie e si contrassegnano i denominatori di probabilità.

Quando il rilevamento casuale e la larghezza di banda vengono configurati insieme, la Dimensione coda corrente può essere maggiore della soglia massima WRED in un determinato momento. Ciò è dovuto al fatto che le soglie minime e massime WRED agiscono solo in base alle dimensioni medie (non correnti) della coda. In questo modo, è possibile far scadere tutti i buffer allocati alla coda basata su classi, con conseguenti possibili perdite di buffer in qualsiasi punto della coda equa basata su classi (fare riferimento all'ID bug Cisco CSCsm94757).

• Larghezza di banda pre-HQF + comportamento coda equa: NA, coda equa non consentita nella classe di larghezza di banda.

• Larghezza di banda pre-HQF + rilevamento casuale + comportamento coda equa: NA, coda equa non consentita nella classe di larghezza di banda

Comportamento HQF

Il comportamento è lo stesso descritto nella sezione Pre-HQF.

• Limite di coda HQF: 64 pacchetti, regolabili tramite il limite di coda.

Questa procedura è la stessa della versione pre-HQF.

• Larghezza di banda HQF + comportamento di rilevamento casuale:

Esempio:

policy-map HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   queue-limit 512
   random-detect

Nota: il limite predefinito per la coda è 64 pacchetti.

Il comportamento è lo stesso della sezione equivalente pre-HQF, con un'importante eccezione. Nelle immagini HQF, il rilevamento casuale e il limite di coda possono coesistere nella stessa classe definita dall'utente (o classe predefinita) e il limite di coda può essere abilitato e impostato su 64 pacchetti in una configurazione predefinita. Pertanto, il limite di coda può fungere da dimensione massima della coda corrente in una classe di rilevamento casuale, pertanto può fornire un meccanismo per limitare le cadute di nessun buffer discusse nella sezione equivalente pre-HQF. A causa di questa aggiunta, il limite della coda configurato deve essere almeno altrettanto grande della soglia max-threshold di random-detect, in cui la soglia max di random-detect può essere impostata su 40 pacchetti per impostazione predefinita, altrimenti il parser può rifiutare la configurazione.

Questo introduce un controllo del limite della coda corrente nelle classi WRED, in base al quale, anche se il calcolo della profondità media della coda è inferiore alla soglia massima, se la dimensione della coda corrente (non media) è superiore al limite della coda, il pacchetto può essere scartato, l'interrupt di ricezione rilasciato e un Tail Drop registrato. Tenere presente che se il limite della coda è impostato su un valore sufficientemente alto da esaurire i buffer di coda aggregati per la coda basata su classi, non è possibile che si verifichino cali del buffer. I buffer di accodamento aggregati per HQF sono definiti di seguito:

• Interfaccia fisica: 1000 pacchetti, sintonizzabili con l'interfaccia CLI hold-queue out.

• ATM PVC: 500 pacchetti, sintonizzabili con PVC CLI vc-hold-queue.

• Classe mappa Frame Relay: 600 pacchetti, sintonizzabili con la coda di attesa Frame Relay classe mappa CLI.

• Criterio di shaping basato su classi applicato all'interfaccia fisica nel codice HQF: 1000 pacchetti, sintonizzabile con una combinazione di interfacce CLI hold-queue-out e child policy queue-limit in cui child policy queue-limit ha un limite superiore di interface hold-queue out.

• Criterio di shaping basato su classi applicato alla sottointerfaccia nel codice HQF: 512 pacchetti, non regolabili (verificare con il team della piattaforma QoS NSSTG, è necessario che sia regolabile).

Nota: tutti gli esempi di shaping Frame Relay e basato su classi presuppongono che la somma dei shaper non superi la frequenza di clock dell'interfaccia.

Di seguito è riportato un esempio del mondo reale:

policy-map JACKLYN
 class 1
    bandwidth 64
    queue-limit 500 packets
     random-detect
     random-detect precedence 1 22 300

Durante questo output, non viene generato alcun traffico tramite l'interfaccia:

F340.11.25-7200-5_LAC#show policy-map interface | i queue      
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 0/387595/0

!--- Current_q_depth is 0

        Mean queue depth: 107 packets

!--- last calculation of Average_queue_depth

A questo punto, il traffico viene avviato. Lo streaming non è frammentato a 400 PPS ed è composto da frame da 1000 byte:

F340.11.25-7200-5_LAC#show policy-map interface | i queue
  queue limit 500 packets
  (queue depth/total drops/no-buffer drops) 461/387641/0

!--- 461 is Current_q_depth > Prec 1 max-thresh of 300 
!--- but < "queue-limit 500 packets".

  Mean queue depth: 274 packets

!--- Avg_q_depth is rising, Mark Prob Denom is being used.

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 363/387919/0 

!--- 363 is Current_q_depth and it is falling compared to last 
!--- iteration because WRED is random dropping packets. Mean queue depth: 351 packets 
!--- Avg_q_depth is now above max_thresh, WRED starts to tail-drop 
!--- in addition to random-drop. 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 199/388263/0 
 Mean queue depth: 312 packets 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 303/388339/0 
 Mean queue depth: 276 packets 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 325/388498/0 
 Mean queue depth: 314 packets 

F340.11.25-7200-5_LAC#show policy-map interface | i queue 
 queue limit 500 packets 
 (queue depth/total drops/no-buffer drops) 298/390075/0 
 Mean queue depth: 300 packets  

Si noti come, alla fine, con un flusso non frammentato, la profondità media della coda WRED possa essere uguale alla profondità della coda corrente, che è il comportamento previsto.

• Larghezza di banda HQF + comportamento della coda equa:

Quando la larghezza di banda e la coda equa vengono applicate insieme a una classe definita dall'utente HQF, a ogni coda basata sul flusso viene assegnato un limite di coda pari a .25 * limite di coda. Poiché il limite predefinito per la coda è di 64 pacchetti, a ciascuna coda basata sul flusso in una coda equa possono essere allocati 16 pacchetti. Se quattro flussi attraversano questa classe, per impostazione predefinita ogni coda di flusso ha 16 pacchetti, quindi non ci si aspetterebbe mai di vedere i pacchetti totali accodati di >64 (4 *16). Tutte le gocce di coda da una singola coda di flusso vengono registrate come gocce di flusso. Se il numero di code di flusso era significativamente elevato come il limite di coda, un'altra opportunità per non-buffer è stata eliminata. Ad esempio, se si presume che il punto di collegamento dei criteri sia un'interfaccia fisica in cui vengono allocati 1000 buffer aggregati, procedere come segue:

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128

In questa configurazione, un volume considerevole di traffico in tutte le code di flusso può causare la perdita di dati nei buffer di interfaccia aggregati e non causare perdite di dati in altre classi definite dall'utente (vedere l'ID bug Cisco CSCsw98427). Questo perché 1024 code di flusso, ognuna con un limite di 32 pacchetti, possono facilmente sovrascrivere l'allocazione del buffer di accodamento basato su classi dell'interfaccia aggregata di 1000.

• Larghezza di banda HQF + rilevamento casuale + comportamento della coda equa:

Esempio:

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128
  random-detect

Uguale alla larghezza di banda e alla coda equa nella sezione, con l'eccezione che la dimensione media della coda WRED viene calcolata ogni volta che arriva un pacchetto per decidere se il pacchetto deve essere eliminato in modo casuale o nella coda. Come con il pre-HQF, tutte le code di flusso possono condividere un'istanza delle soglie WRED, il che significa che tutti i pacchetti accodati a tutte le code di flusso vengono utilizzati per calcolare la profondità media delle code WRED, quindi la decisione di rifiuto applica le soglie minime e massime WRED ai pacchetti aggregati in tutte le code di flusso. Tuttavia, poiché un'istanza delle soglie WRED si applica a tutte le code basate sul flusso, il limite di coda delle singole code di flusso (.25 * "limite di coda") viene ignorato e rispetta il limite di coda aggregato delle classi per un controllo del limite di coda corrente.

Comportamento predefinito della classe

Comportamento pre-HQF

In pre-HQF, il valore predefinito della classe è fair-queue, tutte le code di flusso condividono il limite di coda per la classe (il valore predefinito è 64) e non c'è riserva di larghezza di banda. In altre parole, il numero totale di pacchetti accodati in tutte le code di flusso non può mai superare il limite di coda. La quantità di pacchetti accodati in ciascuna coda di flusso può dipendere dal peso calcolato della coda di flusso. Viceversa, se in class-default vengono utilizzati sia il protocollo fair-queue che il protocollo random-detect, il limite della coda può essere ignorato e tutte le code di flusso possono condividere le stesse soglie WRED. Di conseguenza, tutti i pacchetti attualmente accodati in tutte le code di flusso possono essere utilizzati per calcolare le dimensioni medie delle code WRED. Poiché la dimensione corrente della coda non ha un limite superiore in questa configurazione, è possibile che si verifichino perdite di dati senza buffer (fare riferimento all'ID bug Cisco CSCsm94757).

• Se la larghezza di banda viene aggiunta a quella predefinita per le classi, è possibile che venga generato il comportamento descritto nella sezione Comportamento HQF precedente - Classi definite dall'utente configurate con il comando "larghezza di banda".

• Se la larghezza di banda e il rilevamento casuale vengono aggiunti a class-default, possono verificarsi i comportamenti descritti nella sezione Larghezza di banda + rilevamento casuale di Pre-HQF Behavior di Pre-HQF Behavior - User Defined Classes Configurato con il comando "bandwidth".

Nota: in pre-HQF, la larghezza di banda non può coesistere con fair-queue in class-default.

Comportamento HQF

In HQF, l'impostazione predefinita della classe è una coda FIFO e viene allocata una pseudo prenotazione della larghezza di banda in base alle allocazioni rimanenti delle classi definite dall'utente. Per informazioni sul comportamento predefinito della classe HQF, vedere la sezione Comportamento HQF - Classi definite dall'utente configurate con il comando "larghezza di banda". In qualsiasi momento, indipendentemente dalla configurazione, l'impostazione predefinita per le classi nelle immagini HQF può sempre avere una riserva implicita della larghezza di banda uguale alla larghezza di banda dell'interfaccia non utilizzata non utilizzata dalle classi definite dall'utente. Per impostazione predefinita, la classe predefinita riceve almeno l'1% della larghezza di banda dell'interfaccia o della forma padre. È anche possibile configurare esplicitamente la CLI della larghezza di banda nella classe predefinita.

• Se la proprietà fair-queue è configurata in class-Default, il comportamento corrisponde alla sezione larghezza di banda HQF + comportamento fair-queue di HQF Behavior - User Defined Classes Configurato con il comando "bandwidth".

• Se in Class-Default sono configurati sia la funzionalità fair-queue che la funzionalità random-detect, il comportamento corrisponde alla sezione larghezza di banda HQF + random-detect + fair-queue behavior di HQF Behavior - User Defined Classes Configurato con il comando "bandwidth".

Informazioni correlate

• Guida alla configurazione delle soluzioni Cisco IOS Quality of Service, versione 12.2SR
• QoS - HQF (Hierarchical Queueing Framework) [non supportato]
• Supporto router
• Supporto tecnico Cisco e download