WRED e MDRR su Cisco serie 12000 Internet Router con un esempio di configurazione Unicast, Multicast e Voice Traffic

Introduzione

Questo documento spiega come configurare una scheda di linea Cisco serie 12000 per Weighted Random Early Detection (WRED), descritto nella RFC 2309 , in un ambiente multiservizio.

Prerequisiti

Requisiti

I lettori di questo documento devono essere a conoscenza di quanto segue:

• Descrizione e configurazione di MDRR e WRED sul Cisco serie 12000 Internet Router

• Come leggere l'output del comando show controller frfab | comandi di coda tofab su un Cisco serie 12000 Internet Router

• Tipo di servizio nella suite di protocolli Internet, Precedence (RFC-1349)

• Weighted Random Early Detection

Componenti usati

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

• Qualsiasi versione del software Cisco IOS® che supporti Cisco serie 12000 Internet Router. Di solito queste sono le versioni 12.0S e 12.0ST.

• Tutte le piattaforme Cisco 12000 sono illustrate in questo documento. Questi includono 12008, 12012, 12016, 12404, 12406, 12410 e 12416.

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

Cisco serie 12000 è una delle piattaforme più diffuse utilizzate per creare una rete core IP ad ampia larghezza di banda. Questa piattaforma offre l'esclusiva possibilità di configurare Quality of Service (QoS).

Poiché è sempre più comune combinare diversi tipi di traffico IP (ad esempio Voice over IP - VoIP - e multicast) nella stessa rete, i requisiti per la definizione delle priorità e un comportamento di dropping controllato diventano estremamente importanti e, in molti casi, rappresentano la differenza tra esito positivo e negativo dell'avvio di un nuovo servizio come VoIP.

I requisiti di rete per i diversi tipi di traffico IP esulano dall'ambito di questo documento. Questo documento è incentrato sui test di laboratorio eseguiti per trovare una configurazione applicabile su diverse schede di linea, tra cui Cisco serie 12000 e la scheda di linea Gigabit Ethernet (GbE) a 3 porte. I risultati di questi test dimostrano che la scheda di linea GbE Engine 2 a 3 porte è adatta per un ambiente di rete che include una combinazione di voce, dati e traffico multicast. Dimostra anche che la configurazione di QoS fa una vera differenza in una rete congestionata.

Classi di precedenza utilizzate nel test

I valori di precedenza assegnati a classi diverse devono essere gli stessi nell'intera rete. È necessario determinare un criterio generico.

Classe	Precedenza	Traffico
Traffico dannoso		Tutto il traffico non identificato fuori rete (fuori rete)
In rete — in rete	1	Traffico che rimane all'interno della rete SP (in rete)
servizi Internet Service Provider (ISP)	2	traffico ISP, SMTP, POP, FTP, DNS, Telnet, SSH, www, https
PMI (piccole e medie imprese)	3	Clienti aziendali, un servizio eccellente
In tempo reale, senza voce	4	TV, giochi in tempo reale
Voce	5	Traffico VOIP RTP
Messaggi di controllo di rete	6-7	Border Gateway Protocol (BGP) e altri messaggi di controllo

Colorazione dei pacchetti IP

Se si desidera implementare QoS nel nucleo di una rete, un prerequisito è che il provider di servizi abbia il pieno controllo del valore di precedenza di tutti i pacchetti IP trasportati nella rete. L'unico modo per fare ciò è contrassegnare tutti i pacchetti quando entrano nella rete, senza fare distinzione se provengono dal lato del cliente/utente finale o da Internet. Non devono essere effettuate marcature o colorazioni nel nucleo.

Risultati previsti

L'obiettivo di questo progetto è di avere un comportamento WRED reale nelle classi 0-3. Ciò significa che ci piacerebbe avere una situazione in cui inizieremmo a perdere la precedenza dei pacchetti 0 durante la congestione. Dopo di che, dovremmo anche iniziare a perdere la precedenza 1 se la congestione continua, e poi anche la precedenza 2 e 3. Questo è tutto descritto nel grafico seguente.

La latenza deve essere la più bassa possibile per i pacchetti voce e non deve verificarsi alcuna perdita per il traffico voce e multicast.

Configurazione della rete

Per testare e valutare la configurazione, abbiamo utilizzato un Cisco 12410 insieme a un generatore di pacchetti di Agilant. Sul router Cisco 12000 è in esecuzione una versione tecnica basata sul software Cisco IOS versione 12.0(21)S1.

Implementazione accodamento GbE Engine 2 a 3 porte

Le schede del motore 2 in genere hanno otto code di fax e una coda a bassa latenza e otto code di fax per slot di destinazione. È inoltre disponibile una coda multicast tofab separata. Nella scheda GbE a 3 porte è presente una sola coda fromfab per porta fisica. Nel test, la configurazione applicata specifica più code. I risultati mostrano che la scheda GbE a 3 porte accetta questa configurazione e le code vengono mappate automaticamente alle code disponibili.

Algoritmo WRED Engine 2 nel software Cisco IOS

È necessario comprendere appieno l'algoritmo utilizzato per WRED nella scheda di linea Engine 2 durante la configurazione dei valori di profondità di coda minima e massima. Al codice non interessa il valore minimo configurato; per impostare il valore minimo viene invece utilizzata una formula specifica, basata sul valore massimo configurato.

Formula:

Valore minimo = Valore massimo - (la potenza massima di 2 che non genera un risultato negativo)

I valori utilizzati in questa prova hanno determinato i seguenti valori minimi programmati per il circuito integrato specifico dell'applicazione (ASIC):

Precedenza	Configurazione minima	Massimo configurato	Massima potenza di 2	Valore minimo in ASIC
0	50	5000	4096	5000-4096=904
1	60	6000	4096	6000-4096=1904
2	70	7000	4096	7000-4096=2904
3	80	8000	4096	8000-4096=3904

L'uso di questa formula per calcolare il valore minimo significa che si può finire con un comportamento di gestione dei pacchetti errato se non si tiene conto di questo quando si configurano i parametri WRED. come illustrato nell'esempio seguente:

Precedenza	Configurazione minima	Massimo configurato	Massima potenza di 2	Valore minimo in ASIC
0	50	150	128	150-128=22
1	75	225	128	225-128=97
2	100	300	256	300-256=44
3	125	375	256	375-256=119

Ciò significa che, anche se i valori sono configurati per iniziare a scendere in base alla regola 0, quindi 1, 2 e infine 3 (sopra), quando i valori vengono scritti nell'ASIC, in realtà si inizia a scartare la precedenza 0, quindi la precedenza 2, infine la precedenza 1 e infine la precedenza 3. Non è possibile vedere quali valori sono stati configurati nell'ASIC su una scheda Engine 2. Se si applica la configurazione su una scheda Engine 3, i valori visualizzati nella configurazione saranno i valori reali (il valore minimo ricalcolato).

Configurazione QoS

Per ulteriori informazioni sulla configurazione QoS, consultare il documento sulla descrizione e configurazione di MDRR e WRED sul Cisco serie 12000 Internet Router.

Rx CoS

rx-cos-slot 2 B2-Table
rx-cos-slot 3 B2-Table
rx-cos-slot 6 B2-Table

Nella maggior parte dei casi, è possibile utilizzare il comando rx-cos-slot all. Nel nostro test case, avevamo alcune schede che non supportavano l'accodamento delle schede, quindi non potevamo sempre usare il comando rx-cos-slot all. Al contrario, abbiamo assegnato la nostra slot-table alle schede di linea utilizzate nel test.

!   
slot-table-cos B2-Table  
destination-slot all B2  
multicast B2  
!--- If you don't fulfill the steps above, you will not be able to reach the goal of 0 drops for Multicast traffic. With no rx-cos configured, multicast will be treated in the default queue, meaning it will drop as soon as there is congestion.

!

QoS Tx

A questo punto è possibile configurare i costi di trasmissione. Scegliere un nome per il qos tx, ad esempio "cos-queue-group B2".

Ogni valore di precedenza per cui si desidera configurare un comportamento di rilascio deve essere mappato a un'etichetta di rilevamento casuale separata.

precedence 0 random-detect-label 0  

precedence 1 random-detect-label 1  

precedence 2 random-detect-label 2  

precedence 3 random-detect-label 3

Per il Round Robin di deficit modificato (MDRR), mappare ogni precedenza a una coda MDRR. Nell'esempio, abbiamo mappato la precedenza 0-3 alla stessa coda MDRR per riservare la larghezza di banda per il video (traffico multicast). Questo mapping fornisce il comportamento richiesto.

precedence 0 queue 0  

precedence 1 queue 0  

precedence 2 queue 0  

precedence 3 queue 0  

precedence 4 queue 4 

La voce viene contrassegnata con la precedenza 5, motivo per cui la precedenza 5 viene mappata alla coda a bassa latenza.

precedence 5 queue low-latency  

precedence 6 queue 6  

precedence 7 queue 6  

A questo punto è necessario configurare il comportamento di rilascio per ciascuna delle etichette di rilevamento casuale. Durante il test, questi numeri sono stati modificati fino a quando non sono stati trovati dei valori che fornivano il modello di rilascio desiderato. Per i dettagli, vedere la sezione Risultati previsti. La profondità della coda viene misurata nella coda fisica e non nella coda MDRR o RED-Label.

random-detect-label 0 50 5000 1  

random-detect-label 1 60 6000 1  

random-detect-label 2 70 7000 1  

random-detect-label 3 80 8000 1 

Sul Cisco 12000, è possibile creare un comportamento CBWFQ (Weighted Fair Queuing) basato su classi, dando peso alla coda MDRR diversa. Il peso predefinito è 10 per coda. Il numero di byte trasmessi ogni ciclo MDRR è una funzione del valore di rilevanza. Un valore di 1 indica 1500 byte per ciclo. Un valore di 10 significa 1500+(9*512) byte per ciclo."

queue 0 20  

queue 4 20  

queue 6 20  

!  

Mapping interfaccia

Ogni interfaccia deve essere configurata per WRED. A tale scopo, utilizzare i comandi:

• configurare il terminale

• interface gig 6/0

• tx-cos B2

A partire da Senza rilasci

Il flusso generato utilizza i valori seguenti, a meno che non venga specificato un altro valore:

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb voip

Il risultato è un flusso in background di 240 MB (VoIP e multicast).

Successivamente vengono aggiunti quattro flussi di dati delle stesse dimensioni, ma con precedenza 0-3 (un valore di precedenza per flusso).

Quattro flussi di dati di 151 MB ciascuno

Questa configurazione offre una larghezza di banda totale di 844 MB. Il grafico seguente mostra che ci sono 0 pacchetti in uscita e una latenza molto bassa (circa 50 us - microsecondi - per ogni flusso, inclusa la voce).

Quattro flussi di dati di 160 MB ciascuno

Questa configurazione offre una larghezza di banda totale di 880 MB. Il grafico seguente mostra che i pacchetti iniziano a cadere dalla classe 0 di precedenza e la latenza per Voice è aumentata a 6 ms - millisecondi.

Quattro flussi di dati di 167 MB ciascuno

Questa configurazione offre una larghezza di banda totale di 908 MB. Anche per la classe Precedence 1 sono in corso rilasci. La latenza del traffico vocale è sempre la stessa.

Nota: il flusso non è stato arrestato prima di essere aumentato, quindi la differenza tra il numero di cali nel flusso 0 e 1 è cumulativa.

Quattro flussi di dati di 191 MB ciascuno

Quando la larghezza di banda totale aumenta, i pacchetti iniziano a uscire anche dalla coda precedence 2. La larghezza di banda totale che stiamo tentando di raggiungere per l'interfaccia Gigabit Ethernet è ora di 1004 MB. Questo è illustrato nei contatori degli errori di sequenza nel grafico sottostante.

Quattro flussi di dati di 244 MB ciascuno

Anche gli errori di sequenza per la precedenza 3 stanno iniziando ad aumentare. Questo è il primo segno che i rilasci inizieranno da quella coda. La quantità totale di larghezza di banda che stiamo tentando di inviare all'interfaccia GbE è ora di 1216 MB. Si noti che le interruzioni nella coda multicast (MC) e nella coda vocale sono ancora pari a zero e la latenza della coda vocale non è aumentata.

Arresto e avvio

Tutti i flussi sono stati arrestati e ha iniziato a generare un grafico che ha cancellato i contatori. Questo mostra come apparirà durante una forte congestione. Come si può vedere di seguito, il comportamento è quello desiderato.

QoS rimosso

Per dimostrare che QoS migliora realmente le prestazioni durante la congestione, QoS è stato rimosso e l'interfaccia è congestionata. I risultati sono inferiori (il flusso generato utilizza i valori seguenti a meno che non venga specificato un altro valore).

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb VoIP

Il risultato è un flusso in background di 240 MB (VoIP e multicast).

Successivamente vengono aggiunti quattro flussi di dati delle stesse dimensioni, ma con precedenza 0-3 (un valore di precedenza per flusso).

Quattro flussi di dati di 153 MB ciascuno

per un totale di 852 MB. Ci sono 0 gocce, e una latenza di meno di 50 us.

Quattro flussi di dati di 158 MB ciascuno

L'utilizzo iniziale è pressoché identico a quello dell'applicazione di WRED (872 MB ). La differenza ora è che esiste una latenza dei pacchetti voce di 14 ms (più del doppio rispetto al test WRED) e che le perdite si verificano in egual misura da tutte le classi, inclusi VoIP e multicast.

Aggiunta del carico in ingresso

Finora tutti i test hanno incluso solo la trasmissione attraverso le interfacce Gigabit Ethernet. Per verificare la reazione dell'interfaccia in una situazione in cui l'interfaccia viene convogliata nell'altra direzione, sono stati eseguiti i test seguenti.

Per questo test, è stata caricata l'interfaccia Gigabit Ethernet con una quantità totale di 1056 MB. Ciò ha comportato cali sulla precedenza 0-2, non cali sul traffico sulla precedenza 3. (MC e VOIP rimasero gli stessi, cioè non si verificarono perdite). Abbiamo quindi aggiunto il traffico nell'altra direzione, tanto quanto il generatore di pacchetti è stato in grado di inviare attraverso l'interfaccia Gigabit Ethernet. Il risultato è piuttosto impressionante: la congestione della ricezione non interferisce affatto con la coda di trasmissione e la latenza per il traffico di ricezione è estremamente bassa, inferiore a 13 us per la voce.

12-RP#show interfaces g 6/0

È possibile monitorare il carico sul collegamento Gigabit utilizzando il comando show interfaces:

Router#show interfaces gig 6/0
GigabitEthernet6/0 is up, line protocol is up
  Hardware is GigMac 3 Port GigabitEthernet, address is 0004.de56.c264 
  (bia 0004.de56.c264)
  Internet address is 178.6.0.1/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 232/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex mode, link type is force-up, media type is SX 
  output flow-control is unsupported, input flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output 00:00:05, output hang never
  Last clearing of "show interface" counters 08:52:40
  Queueing strategy: random early detection (WRED)
  Output queue 0/40, 2174119522 drops; input queue 0/75, 0 drops
  30 second input rate 838969000 bits/sec, 792079 packets/sec
  30 second output rate 910819000 bits/sec, 464704 packets/sec
    7584351146 packets input, 1003461987270 bytes, 0 no buffer
	Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
	0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
	0 watchdog, 514 multicast, 0 pause input
	11167110605 packets output, 2241229569668 bytes, 0 underruns
	0 output errors, 0 collisions, 0 interface resets
	0 babbles, 0 late collision, 0 deferred
	0 lost carrier, 0 no carrier, 0 pause output
	0 output buffer failures, 0 output buffers swapped out

Modifica delle dimensioni dei flussi

Per verificare che i risultati del test non siano dovuti al fatto che la larghezza di banda è la stessa per tutti i flussi, abbiamo modificato i flussi in modo che trasmettessero quantità diverse di dati. Abbiamo anche provato a modificare l'MTU (Maximum Transmission Unit) in modo che fosse diversa per ogni flusso. Con i valori della coda configurati, il risultato era ancora lo stesso, eliminando prima la precedenza 0, quindi 1, infine 2 e infine 3.

Verifica con una scheda di linea Gigabit Ethernet Engine 4 a 10 porte

Poiché la latenza della coda VoIP (la coda a bassa latenza) nel test è stata piuttosto elevata, è stato eseguito lo stesso test con la scheda di linea Gigabit Ethernet Engine 4 a 10 porte. Come previsto, il risultato con questa scheda di linea è stato molto migliore per quanto riguarda la latenza nella coda a bassa latenza (LLQ). I risultati sono gli stessi per quanto riguarda il modo in cui si è verificato il calo. La latenza per LLQ era di circa 10 us, ovvero 1:1000 della latenza nella scheda di linea Gigabit Ethernet Engine 2 a 3 porte.

Informazioni correlate

• Descrizione e configurazione di MDRR e WRED sul Cisco serie 12000 Internet Router
• Come leggere l'output del comando show controller frfab | comandi di coda tofab su un Cisco serie 12000 Internet Router
• Tipo di servizio nella suite di protocolli Internet, Precedence (RFC-1349)
• Weighted Random Early Detection
• Documentazione e supporto tecnico – Cisco Systems