Configurazione dei router Cisco
- Parte II - QoS -
Copyright 2002-2010 – Gianrico Fichera –
Il materiale di questa libro non e’ sponsorizzato o sottoscritto da Cisco Systems, Inc. Cisco e’ un trademark di Cisco Systems, Inc. negli Stati Uniti e in altri stati. L’autore di questo libro non si assume nessuna responsabilita’ e non da nessuna garanzia riguardante l’accuratezza e la completezza delle informazioni presenti nonche’ da conseguenze sull’uso delle informazioni presenti in questa pagina.
Nessuna parte di questa pubblicazione puo' essere riprodotta o trasmessa, in qualsiasi forma o con qualsiasi mezzo, elettronico, meccanico, fotocopie, registrazione, senza il consenso dell'autore.
This material is not sponsored by, endorsed by, or affiliated with Cisco Systems, Inc., Cisco, Cisco Systems, and the Cisco Systems logo are trademarks or registered trade marks of Cisco Systems, Inc. or its affiliates. All other trademarks are trademarks of their respective owners.
Ultima revisione
Agosto 2010: impaginazione per formato ebook
QOS e gestione delle congestioni
Introduzione
Nei collegamenti di rete LAN e' noto
che la tecnologia piu' utilizzata e' la Ethernet. Nei collegamenti WAN e' invece
spesso utilizzato il protocollo ATM e il piu' vetusto Frame-Relay, piu'
recentemente MPLS e ancora Ethernet, su fibra ottica. Al di sopra di questi
protocolli si usa normalmente il protocollo IP.
Ai giorni nostri, in un mondo oramai dominato dal protocollo TCP/IP e
dall'Ethernet, con l'utilizzo di trasmissione simultanea di voce e dati si sono
resi evidenti dei limiti di tale infrastruttura: la mancanza di una
gestione efficiente della qualita' del servizio e dell'ingegneria del traffico.
D'altra parte continuare a investire nella rete ATM e' costoso,
specialmente per gestire quantita' di traffico quali quelle
richieste da un mondo sempre piu' dominato da Internet (difficilmente si arrivera' a interfacce
ATM con velocita' superiori
a 622mbps). Tecnologie come la Ethernet invece permettono di utilizzare bande
passanti dell'ordine di 1/10 Gbit/s con costi contenuti. Il protocollo
Ethernet inoltre e' uscito dall'ambito della rete locale per
essere utilizzato anche in reti WAN e Metropolitane. In queste reti si utilizza TCP/IP. Ed e' per questo che produttori
come Cisco Systems hanno focalizzato l'attenzione su tecnologie come Ethernet e IP/MPLS.
In Italia l'operatore monopolista possedeva inizialmente una rete dati
X.25 , successivamente affiancata da una rete Frame-Relay e quindi dalla piu'
recente rete ATM molto nota, oggigiorno, perche' rete di raccolta dei
collegamenti XDSL (come l'ADSL di casa nostra).
MPLS e' un protocollo di trasmissione che utilizza delle etichette
(label) per differenziare i flussi di traffico. MPLS non trasporta solo
TCP/IP ma si adatta a qualsiasi protocollo. Nel caso di IP supporta tutte le
specifiche di Qualita' di Servizio (QoS) sviluppate nel corso degli anni per
TCP/IP e fornisce gli strumenti per gestire Ingegneria del Traffico (IT)
e VPN. E proprio la QoS e l'IT erano i
vantaggi offerti dalla rete Frame-Relay e ATM, che permettevano di evitare
congestioni, garantendo ai clienti la banda contrattualizzata. Venendo meno la
principale limitazione del protocollo IP grazie a MPLS, i carrier
hanno trovato una valida alternativa ad ATM e Frame-Relay per le loro reti
geografiche.
La QoS
La Quality Of Service (QoS) permette di assegnare priorita' differenti a differenti flussi di traffico. Gestire le congestioni significa affrontare efficacemente i picchi di traffico. Come dice la stessa parola, "congestione" vuol dire eccesso di traffico rispetto alle possibilita' della rete. Per esempio, se abbiamo un collegamento a 2 megabit e si tenta di utilizzare una banda superiore si verifica una congestione.
Una corretta QoS consente di gestire efficacemente le congestioni, ovvero scegliere quale tipologia di traffico sacrificare e quale avvantaggiare. In linea di principio le applicazioni real-time, come VoIP oppure il VoD, devono avere priorita' maggiore rispetto le altre, quali web, email, ftp. Le applicazioni quali il peer-to-peer normalmente vanno penalizzate e devono essere servite per ultime in caso di congestione.
Ogni interfaccia di ogni router Cisco ha una unica coda legata al traffico in uscita che possiamo chiamare coda hardware oppure coda di basso livello. Questa ha lo scopo di assorbire i picchi di traffico conservandone i pacchetti. Tale coda e' gestita in modalita' FIFO, ovvero First In First Out. L'amministratore di rete puo' impostare la lunghezza di questa coda. Se la coda si riempie i pacchetti in eccesso vengono scartati. A monte di questa unica coda legata all'interfaccia hardware vi sono degli algoritmi software di gestione della QoS che utilizzano piu' code. Queste ultime ci permettono di gestire un tuning piu' preciso della QoS ed e' su queste che si interviene nella configurazione della propria politica di servizio.
Due
importanti concetti sono utilizzati nella gestione della QoS: traffic
shaping e traffic policing.
Traffic shaping: Il traffic shaping utilizza una o piu'
code per
tenere i pacchetti in eccesso. Significa che, in caso di congestione, si cerca
di conservare i pacchetti in coda fino alla sua saturazione. Controlla il
traffico in uscita. I pacchetti si bufferizzano. Pertanto in
ogni caso si ha un delay aggiuntivo del traffico in eccesso;
Traffic policing: Il traffic policing a differenza del traffic shaping rigetta il traffico in eccesso facendo il drop dei pacchetti. Per configurarlo normalmente si usa il comando "police". E' basato sui tre valori di average-rate, committed Burst (Bc), excess Burst (Be)
Uno "shaper" e' un algoritmo che utilizza un buffer, o coda, mentre un "policier" e' un algoritmo che scarta i pacchetti in eccesso senza utilizzare una coda. Nel momento in cui una coda dello shaper e' piena i pacchetti quelli in eccesso possono essere scartati, e in tal caso si parla di "tail drop" oppure possono essere gestiti con algoritmi di "congestion avoidance" (vedi RED o WRED piu' avanti) che mirano a prevenire le situazioni di congestione facendo il drop selettivo e intelligente di pacchetti. Se si utilizza il "tail drop" in caso di congestione uno shaper si comporta come un policier.
Per dimensionare un flusso di traffico sia uno shaper che un policier utilizzano un algoritmo chiamato token bucket. Vi sono a disposizione un certo numero di token nell'unita' di tempo, pari alla banda disponibile. Arrivano sempre nuovi token, con un flusso costante, dipendente quindi dal valore di traffico preimpostato. Questi token vengono associati ai bit o byte in transito. Se passano piu' dati dei token disponibili questi devono attendere in coda (in caso di shaping) o vengono eliminati (in caso di policing). Sostanzialmente si contano i bit o byte (a seconda di shaping o policing) di passaggio per verificare lo sforamento nel limite di traffico prefissato. E' possibile gestire anche i burst di traffico. Si tratta di un numero di token aggiuntivi che sono messi a disposizione a intervalli regolari. Questo consente di inviare picchi di traffico ma poi costringe all'attesa per poter inviare un ulteriore picco.
Al traffic shaping o policing si aggiunge il concetto di classificatore. Questa fase consiste nel marcare i pacchetti in base al loro contenuto differenziandoli per profili di traffico. La classificazione dei pacchetti e' fondamentale per la loro successiva discriminazione in base alle priorita'.
Ci sono due modi di gestire la qualita' del servizio in rete. Il primo e' IntServ e il secondo Diffserv. Nel primo caso si utilizzano protocolli come RSVP, che hanno una loro segnalazione, e che fanno comunicare i router tra loro per riservare banda. Nel secondo caso non c'e' comunicazione tra i router ma ci sono degli standard comuni (vedi DSCP) che permettono a differenti router di trattare allo stesso modo uno stesso flusso di traffico.
Consiglio di utilizzare un IOS versione 12.4 e un router Cisco
almeno della famiglia 1800 per avere a disposizione tutti i
comandi presenti in questi paragrafi. Seguono una serie di
algoritmi per la gestione del traffic shaping.
Seguono le descrizioni di alcuni algoritmi di
queueing che vengono utilizzati nel caso di traffic shaping.
Priority Queuing (PQ)
Il Priority Queuing e' un algoritmo di gestione delle code che utilizza piu' code con priorita' differenti. Le code a priorita' inferiore vengono servite solo se quelle a priorita' superiore sono vuote.
Weight Fair Queuing (WFQ)
Il Weight Fair Queuing e' un algoritmo di gestione delle code che crea automaticamente un insieme di code nelle quali viene suddiviso il traffico a seconda della sua priorita'. Il processo di selezione delle priorita' e' automatico. Ad esempio i flussi di traffico che occupano meno banda hanno priorita' sui restanti. I flussi con precedenza segnalata nei pacchetti IP hanno priorita'. I flussi configurati con l'RSVP hanno la priorita'.
Class Based Weight Fair Queuing (CB-WFQ)
Class Based Weight Fair Queuing e' un algoritmo di gestione delle code che consiste nel creare un insieme di code, associate ad applicazioni differenti, a cui vengono assegnate priorita' differenti. Nel CB-WFQ, la banda non e' mai "riservata". Se il canale e' libero, una classe puo' utilizzare anche la banda delle altre code. Richiede il CEF.
Low Latency Queuing (LLQ)
Il Low Latency Queuing e' un'estensione del CB-WFQ. A differenza di quest'ultimo permette di utilizzare, per alcune classi di traffico, il priority queueing. Questo e' particolarmente utile per dare priorita' a classi di traffico come voce o video.
NBAR
NBAR e' una tecnologia che ci permette di classificare i pacchetti. Pertanto e' un classificatore in base a quanto detto nei paragrafi precedenti.
I router normalmente lavorano al livello 3 della pila ISO/OSI.
In altri termini dei pacchetti in transito riconoscono solo
gli indirizzi, e non sono in grado di interpretare il
contenuto dati dei pacchetti. Per riconoscere il tipo di
servizio a cui e' eventualmente associato un pacchetto IP
bisogna infatti analizzare la informazioni di livello 4,
ovvero TCP, per leggere i valori delle porte e quindi il
tipo di servizio. Alcuni servizi poi, come citrix, hanno
porte variabili rendondene difficile l'identificazione.
NBAR e' una tecnologia Cisco che permette di riconoscere
differenti servizi, anche quelli con assegnazione dinamica
delle porte TCP/UDP (vedi peer-to-peer) o quelli che transitano
in VPN (riconoscendoli prima che i dati vengano criptati). Dopo
che l'applicazione e' riconosciuta, si puo' applicare una
politica di QoS. Questo e' fondamentale perche' la priorita'
dei dati va assegnata in base al servizio ai quali questi sono
associati. Cisco mette a disposizione dei file, gia'
presenti all'interno di alcune versioni di IOS, di nome PDLM,
che contengono le informazioni necessarie al router per
riconoscere un servizio.
Se un'applicazione non e' riconosciuta si possono aggiornare i
file PDLM messi a disposizione
da Cisco senza necessita' di reinstallare l'IOS o riavviare il router. Per
utilizzare NBAR bisogna avere una versione di IOS che lo
supporta. Affinche' NBAR funzioni dobbiamo utilizzare nel
nostro router il CEF e NON con il fast-switching.
Infine si utilizza insieme a CB-WFQ o LLQ.
Nel sito della Cisco Systems, nella sezione "Download
Software" e quindi su "Router Software", scegliete il vostro
modello di router e cliccate su "PDLM software". Troverete
le versioni di PDLM disponibili. Per verificare quelli
installati nel vostro router utilizzate il comando "show
ip nbar ...":
prova1800#show ip nbar version
NBAR software version: 6
1 base Mv: 2
2 ftp Mv: 2
3 http Mv: 9
...
15 gnutella Mv: 4
16 kazaa2 Mv: 7
...
25 edonkey Mv: 5
26 winmx Mv: 3
27 bittorrent Mv: 4
28 directconnect Mv: 2
29 skype Mv: 1
{<No.>}<PDLM name> Mv: <PDLM Version>, {Nv: <NBAR Software Version>; <File name>}
{Iv: <PDLM Interdependency Name> - <PDLM Interdependency Version>}
Figura 1 - NBAR: comando 'show ip nbar version'
Per vedere i protocolli supportati dal software installato nel router:
prova1800#show ip nbar port-map
port-map bgp udp 179
port-map bgp tcp 179
port-map bittorrent tcp 6881 6882 6883 6884 6885 6886 6887 6888 6889
port-map citrix udp 1604
port-map citrix tcp 1494
port-map cuseeme udp 7648 7649 24032
port-map cuseeme tcp 7648 7649
Figura 2 - NBAR: comando 'show ip nbar port-map'
Configurazione di CB-WFQ con NBAR
In questo esempio utilizziamo NBAR come classificatore
e LLQ come algoritmo di queuing. Quindi facciamo
traffic-shaping. Infine gestiamo la congestione con WRED. Il modo migliore di imparare rapidamente la
configurazione della QoS su un router Cisco consiste partire
subito con una configurazione funzionante. Nell'esempio
che segue un router, provvisto di due interfacce Ethernet,
una lato LAN e una lato WAN,
esamina il traffico in transito assegnando delle priorita'.
In circostanze normali l'interfaccia d'uscita ha velocita'
molto inferiore a quella d'ingresso, perche' lato WAN c'e'
un collegamento ad Internet con velocita' normalmente
inferiore a quella di una interfaccia Ethernet. Ma la
sostanza dell'esempio non cambia.
|
class-map match-any data |
La prima operazione da effettuare consiste nel definire le classi del CB-WFQ. Dobbiamo raggruppare tutti i servizi su cui vogliamo fare QoS per classi di priorita'. Abbiamo la possibilita' di specificare esattamente i servizi. Qui definiamo tre classi con il comando "class-map". La prima coda raccogliera' il traffico con protocollo http, smtp, ftp e pop3. L'argomento "match-any" indica che basti che ci sia match con uno solo dei quattro protocolli per far entrare il traffico in questa coda. L'alternativa e' "match-all" nel qual caso dovevano contemporaneamente rispettate tutte le condizioni affinche' il pacchetto facesse parte di questo gruppo. Infine "data" e' il nome da noi assegnato a questa classe. La seconda classe definisce la segnalazione SIP. La terza classe fa match con i pachetti RTP di voce, con codec ben specifici (vedi i paragrafi successivi per una descrizione dettagliata di questi valori. Normalmente si possono creare al massimo 64 class-map. |
|
policy-map VOIP |
Con il comando "policy-map" utilizziamo le classi definite in precedenza ed associamo loro un valore di priorita' e il banda. |
|
class RTP |
Il comando "priority" introduce la PQ nella CB-WFQ. Pertanto ora abbiamo un low latency queueing (LLQ). Il traffico VoIP e' il tipo di traffico che necessita' priorita'. Il comando completo qui e' "priority 256". Significa che 256kbps e' la banda garantita. Questa coda verra' servita prima delle altre. Se c'e' una richiesta di banda superiore a 256kbps in questa classe, il traffico in eccesso sara' tagliato in caso di congestione, per lasciare spazio al traffico con priorita' inferiore (quindi il comando "priority" fa policing e non shaping). Se il traffico in questa coda e' inferiore ai 256kbps, la banda rimanente e' a disposizione degli altri servizi. Le code di priorita' utilizzano l'algoritmo di token bucket. |
|
class SIP |
Alla segnalazione del protocollo SIP riserviamo 64kbps |
|
class WEB |
Alla classe WEB viene riservato un trattamento differente. Il comando "bandwidth" riserva 384kbps senza priorita'. Questo vuol dire che questa coda sara' servita dopo quelle con il comando "priority". Poiche' le code con il comando "priority" hanno la banda tagliata in caso di eccedenza, siamo sicuri che in caso di congestione ci sara' spazio per la classe WEB, a meno di non avere sbagliato i calcoli e riservato complessivamente piu' banda di quella realmente a disposizione. In caso di congestione, mentre le code di priorita' si ritirano al valore di banda specificato, le code con "bandwidth" possono eccedere il limite. Sostanzialmente in questo esempio potremmo avere una congestione con 256kbps di RTP, 64kbps di SIP e 512kbps di WEB, in caso di banda totale 256+512+64. |
|
random-detect |
Siamo sempre nella classe WEB. I comandi "random-detect" fanno parte dei comandi per gestire la "Congestion Avoidance". Si tratta di tecnologie che mirano a prevedere possibili congestioni e limitarle. Questa tecnologia si chiama "WRED". Sostanzialmente quando il traffico sta per raggiungere la saturazione si scartano dei pacchetti IP casualmente. Questo determina un rallentamento della trasmissione a causa del meccanismo di trasmissione del protocollo TCP. Il protocollo TCP infatti aumenta la finestra di trasmissione a meno di non riscontrare la mancata conferma di ricezione dei pacchetti. Se sono specificate delle priorita' i pacchetti a priorita' minore sono scartati prima degli altri. In generale usare un meccanismo di tail-drop su piu' stream TCP in congestione non e' ottimale nel caso di molti flussi TCP. Questo perche' i flussi tendono a diventare sincronizzati tra di loro rallentando e accelerando simultaneamente come risposta alle congestioni. Ma rallentare insieme significa sottoutilizzare il link per un periodo di tempo. Allora un meccanismo come RED fa il drop in modo random su tutti i flussi tcp presenti per abbassare il traffico evitando problemi di congestione globale. |
|
class class-default |
La classe "default" raccoglie tutto il traffico che non e' stato accoppiato ad una coda. In questo esempio, ad esempio, il traffico "telnet", o "peer-to-peer". Questo traffico utilizzera' il WFQ con 512 flussi di traffico, tramite il comando "fair-queue". Le code di default sono di 64 pacchetti. Con il comando "queue-limit" possiamo variare la lunghezza della coda. In questo caso l'aumentiamo a 70. Quando la coda si riempio il router inizia una politica di dropping dei pacchetti che puo' essere WRED se configurata. Il router assegna un valore di default a questo parametro. Un aumento della lunghezza della coda significa una minore perdita di pacchetti ma un aumento del delay. Qui stiamo facendo "shaping". Il comando "queue-limit" non ha senso in interfacce dove si fa "policing", ovvero dove c'e' il comando "priority". |
|
! |
|
|
interface FastEthernet0/1 |
Da notare qui i comandi "ip
nbar protocol-discovery" che abilita' NBAR, e "service-policy
output VOIP" che applica la policy di QoS
configurata al traffico in uscita nell'interfaccia
FastEthernet 0/1. Le policy di questo tipo vengono
configurate sempre in uscita, dove sono presenti le
code. itesys(config-if)#service-policy input VOIP
Come vedremo in seguito in inbound possiamo fare solo policing. |
Figura 3 : Esempio di confiugurazione CB-WFQ con NBAR
I comandi "bandwidth" e "priority" possono essere utilizzati anche indicando la percentuale di banda richiesta piuttosto che il valore assoluto della stessa, come e' possibile vedere dal seguente esempio":
!
class-map match-any SIP
match protocol sip
class-map match-any WEB
match protocol http
match protocol secure-http
class-map match-any RTP
match protocol rtp audio
match protocol rtp payload-type "8"
match protocol rtp payload-type "0"
match protocol rtp payload-type "98"
class-map match-any POSTA
match protocol pop3
match protocol smtp
!
!
policy-map VOIP
class RTP
priority percent 50
class SIP
priority percent 10
class POSTA
bandwidth remaining percent 20
class WEB
bandwidth remaining percent 70
class class-default
fair-queue <-- qui
rimane il 10%
!
!
!
interface FastEthernet0/0
ip address 192.168.30.200 255.255.255.0
load-interval 30
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.10.200 255.255.255.0
ip nbar protocol-discovery
load-interval 30
duplex auto
speed auto
service-policy output VOIP
!
Figura 4 : Esempio di confiugurazione. Comandi 'priority' e 'bandwidth'
Con il comando 'show policy-map' e' possibile verificare che la configurazione inserita e' stata recepita correttamente dal router:
Router#sh policy-map interface fastEthernet 0/1
FastEthernet0/1
Service-policy output: VOIP
Class-map: RTP (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: protocol rtp audio
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol rtp payload-type "8"
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol rtp payload-type "0"
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol rtp payload-type "98"
0 packets, 0 bytes
30 second rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 50 (%)
Bandwidth 50000 (kbps) Burst 1250000 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: SIP (match-any)
326 packets, 165724 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: protocol sip
326 packets, 165724 bytes
30 second rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 10 (%)
Bandwidth 10000 (kbps) Burst 250000 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: POSTA (match-any)
83 packets, 9417 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: protocol pop3
83 packets, 9417 bytes
30 second rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
30 second rate 0 bps
Queueing
Output Queue: Conversation 265
Bandwidth remaining 20 (%)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: WEB (match-any)
2093 packets, 2255242 bytes
30 second offered rate 245000 bps, drop rate 0 bps
Match: protocol http
2093 packets, 2255242 bytes
30 second rate 245000 bps
Match: protocol secure-http
0 packets, 0 bytes
30 second rate 0 bps
Queueing
Output Queue: Conversation 266
Bandwidth remaining 80 (%)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
333 packets, 26274 bytes
30 second offered rate 1000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
Router#
Router#show policy-map VOIP
Policy Map VOIP
Class RTP
Strict Priority
Bandwidth 50 (%)
Class SIP
Strict Priority
Bandwidth 10 (%)
Class POSTA
Bandwidth remaining 20 (%) Max Threshold 64 (packets)
Class WEB
Bandwidth remaining 80 (%) Max Threshold 64 (packets)
Class class-default
Flow based Fair Queueing
Bandwidth 0 (kbps) Max Threshold 64 (packets)
Router#
Figura 5 : Comando 'show policy-map'
Con il comando "show interfaces" e' possibile vedere quale meccanismo di queueing e' attivo sulle interfacce.
Router#show
int
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is 001b.5484.fb46 (bia 001b.5484.fb46)
Internet address is 192.168.30.200/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
...snip...
Queueing strategy: fifo
...snip...
FastEthernet0/1 is up, line protocol is up
Hardware is Gt96k FE, address is 001b.5484.fb47 (bia 001b.5484.fb47)
Internet address is 192.168.10.1/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txlo55, rxload 1/255
...snip...
Queueing strategy: Class-based queueing
...snip...
Figura 4 : Comando 'show interfaces' e queueing strategy
Con il comando "show queuing" e' possibile vedere i dettagli della configurazione delle code.
Router#show queueing
Current fair queue configuration:
Interface
Discard Dynamic Reserved Link
Priority
threshold queues queues queues
queues
FastEthernet0/1 64
256 256
8 1
Figura 6 : Comando 'show queueing'
Per vedere se la configurazione e' stata correttamente applicata all'interfaccia FastEthernet0/1 si utilizza il comando "show policy-map". Le informazioni fornite sono numerose ed estremamente utili. Infatti possiamo vedere in real-time il flusso di traffico che ricade in ogni classe definita. Nell'esempio che segue vediamo che c'e' un traffico di 85000bps di pacchetti RTP.
Router# show policy-map interface fastEthernet 0/1
FastEthernet0/1
Service-policy output: VOIP
Class-map: RTP (match-any)
7528 packets, 1610992 bytes
30 second offered rate 85000 bps, drop rate 0 bps
Match: protocol rtp audio
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol rtp payload-type "8"
7528 packets, 1610992 bytes
30 second rate 85000 bps
Match: protocol rtp payload-type "0"
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol rtp payload-type "98"
0 packets, 0 bytes
30 second rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 256 (kbps) Burst 6400 (Bytes)
(pkts matched/bytes matched) 1/214
(total drops/bytes drops) 0/0
Class-map: SIP (match-any)
293 packets, 151353 bytes
30 second offered rate 2000 bps, drop rate 0 bps
Match: protocol sip
293 packets, 151353 bytes
30 second rate 2000 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
211 packets, 17758 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
Router#
Figura 7 : Comando 'show policy-map interface'
E' importante sapere che la somma dei valori "bandwidth" e "priority" dev'essere <= al 75% della banda disponibile (si presume che il 25% sia traffico non classificato come protocolli di routing). Altrimenti utilizzare il comando "max-reserved-bandwidth" per cambiarne il valore (all'interno della configurazione delle interfacce fisiche dove si applicano le service-policy). Per vedere quanta banca allocabile vi rimane potete usare, in caso di un circuito frame-relay, il comando "show traffic-shape queue"
router#show traffic-shape queue
Traffic queued in shaping queue on Serial0/0/0.1 dlci 50
Queueing strategy: weighted fair
Queueing Stats: 0/600/70/43975 (size/max total/threshold/drops)
Conversations 0/19/512 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 175 kilobits/sec
Figura 8: Comando 'show traffic-shape queue'
Con il comando "show queue" e' possibile vedere lo stato delle code, ad esempio della Ethernet, nel caso dell'esempio1:
1800#show queue fastEthernet 0/1
<--- Interfaccia a 10mbps
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output
drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/70/0 (size/max
total/threshold/drops) <-- "max total" e' l'aggregato di tutte le code WFQ
Conversations 0/1/512 (active/max active/max total)
<--- Una coda con pacchetti e' una conversazione attiva
Reserved Conversations 1/1 (allocated/max allocated)
<--- Code CBWFQ che non sono catturati dal WFQ
Available Bandwidth 6732 kilobits/sec
Figura 9 : Comando 'show queue'
75% di 10000= 7500 - 768 = 6732 <--- la banda della class-default non viene conteggiata perche' non c'e' un comando "bandwidth"
Applicazioni di CB-WFQ e di NBAR per la VoIP
Poiche' la QoS e' molto utilizzata per la VoIP sara' utile richiamare la struttura della maggior parte dei pacchetti VoIP. La voce viene trasmetta tramite pacchetti RTP che sono inseriti all'interno di un pacchetto UDP/IP.
Figura 10 : Formato pacchetto RTP
Ecco nel dettaglio la descrizione del contenuto dei
campi di un pacchetto RTP:
Figura 11 : Dettaglio pacchetto RTP
Poiche' non e' nostro scopo spiegare nel dettaglio come viene trasmessa la VoIP ci limitiamo ad attenzionare il campo indicato in figura con PT, ovvero "payload type". Questo campo, di 7 bit, indica il tipo di enconding della voce presente nel payload. Questo ci permette di differenziale flussi di traffico con codec differenti. L'RTP payload di "8" e' il PCMA. La sorgente dei pacchetti voce potrebbe utilizzare un numero differente per il PCMA.
Riprendiamo la configurazione dell'esempio 1.
Durante il transito del traffico possiamo verificare quanti
pacchetti rtp sono stati trovati.
Router# show ip nbar protocol-discovery protocol rtp
FastEthernet0/1
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
30sec Bit Rate (bps) 30sec Bit Rate (bps)
30sec Max Bit Rate (bps) 30sec Max Bit Rate (bps)
------------------------ ------------------------ ------------------------
rtp 14236 7120
1907624 1523680
104000 83000
104000 83000
unknown 0 0
0 0
0 0
0 0
Total 14588 7533
2118723 1683739
106000 83000
110000 87000
Router#show ip nbar protocol-discovery protocol pop3
FastEthernet0/1
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
30sec Bit Rate (bps) 30sec Bit Rate (bps)
30sec Max Bit Rate (bps) 30sec Max Bit Rate (bps)
------------------------ ------------------------ ------------------------
pop3 93 83
5868 9417
0 0
1000 3000
unknown 104 131
6330 7494
0 0
1000 1000
Total 2105 2758
635534 2485914
5000 55000
47000 283000
Router#show ip nbar protocol-discovery protocol http
FastEthernet0/1
Input Output
----- ------
Protocol Packet Count Packet Count
Byte Count Byte Count
30sec Bit Rate (bps) 30sec Bit Rate (bps)
30sec Max Bit Rate (bps) 30sec Max Bit Rate (bps)
------------------------ ------------------------ ------------------------
http 1432 2131
374414 2296137
5000 55000
38000 275000
unknown 104 131
6330 7494
0 0
1000 1000
Total 2106 2758
635596 2485914
5000 55000
47000 283000
Figura 12 : Comando 'show ip nbar'
Abbiamo detto che il payload usato potrebbe cambiare in base alla sorgente di traffico. Se per esempio la sorgente di traffico e' una centrale telefonica Asterisk e' possibile utilizzare il comando "rtp debug" ed effettuare una telefonata con un codec noto. Ecco cosa accade nel caso di una telefonata con G711 e un telefono Thompson:
Got RTP packet from 192.168.10.100:41000 (type 08, seq 002633, ts 239760, len 000080)
Got RTP packet from 192.168.10.100:41000 (type 08, seq 002634, ts 239840, len 000080)
Sent RTP packet to 192.168.10.100:41000 (type 08, seq 028291, ts 210880, len 000160)
Got RTP packet from 192.168.10.100:41000 (type 08, seq 002635, ts 239920, len 000080)
Got RTP packet from 192.168.10.100:41000 (type 08, seq 002636, ts 240000, len 000080)
Sent RTP packet to 192.168.10.100:41000 (type 08, seq 028292, ts 211040, len 000160)
Figura 13 : Debug: pacchetti RTP G711 provenienti da un telefono IP
Nella figura successiva si vede il risultato nel caso di codec G729. Il payload type e' "18".
Sent RTP packet to 192.168.10.100:41000 (type 18, seq 018307, ts 021920, len 000020)
Got RTP packet from 192.168.10.100:41000 (type 18, seq 000282, ts 022600, len 000010)
Got RTP packet from 192.168.10.100:41000 (type 18, seq 000283, ts 022680, len 000010)
Sent RTP packet to 192.168.10.100:41000 (type 18, seq 018308, ts 022080, len 000020)
Got RTP packet from 192.168.10.100:41000 (type 18, seq 000284, ts 022760, len 000010)
Got RTP packet from 192.168.10.100:41000 (type 18, seq 000285, ts 022840, len 000010)
Sent RTP packet to 192.168.10.100:41000 (type 18, seq 018309, ts 022240, len 000020)
Figura 14 : Debug: pacchetti RTP G729 provenienti da un telefono IP
Riconsideriamo il campo "payload-type". Questo valore indica esattamente il tipo di codifica dei dati e ci puo' far capire che tipo di codec c'e' all'interno, ad esempio G711 o G729. Alcuni valori sono standard ma molti dispositivi se ne discostano. Il comando generico per riconoscere traffico RTP audio e' "match protocol rtp audio". In tal caso si lascia al router la responsabilita' di determinare automaticamente il traffico RTP audio. Nel caso in cui si e' fuori standard si puo' specificare manualmente il payload-type. La sintassi completa del comando e' in figura.
match protocol rtp [audio | video | payload-type payload-string]
Figura 15: Comando 'match protocol rtp'
Vengono mappate come 'audio' le porte RTP da 0 a 23. Vengono mappate come 'video' le porte RTP da 24 a 33. Altrimenti con 'payload-type' vengono definite dall'utente. Segue un esempio di utilizzo di NBAR per catturare il flusso RTP.
class-map
match-all giartp
class-map
match-any SIP
description --- match con la segnalazione ---
match
access-group name SIP-LIST
class-map
match-any RTP
description --- match con il traffico voce RTP --
match ip
rtp 16000 1000
match
protocol rtp audio <-- NBAR
policy-map
VOIP
description
--- questa va bene se non si usa il nat ---
class
SIP
priority 64
class
RTP
priority 256
policy-map parent
class
class-default
shape
average 350000
service-policy VOIP
!
interface
FastEthernet0/0.2
description --- cementrade ---
encapsulation dot1Q 231
ip
address 192.168.20.9 255.255.255.248
no snmp
trap link-status
service-policy output parent
Figura 16: NBAR e QoS
Prendendo come esempio i telefoni IP thomson, questi danno la possibilita' di definire il valore di RTP payload manualmente, come in figura. Notate che i valori configurabili vanno da 97 a 127. Cosi’ per usare l’NBAR cisco bisogna fare una riga personalizzata e non si puo’ usare “match ip rtp audio” per il quale vale 'Audio—Specifies matching for payload type values 0-23'
Figura 17: NBAR e QoS
Consideriamo la configurazione della figura che segue. Si tratta di un collegamento frame-relay dove vengono riservati 512kbps per il traffico RTP, che in questi esempi sara' VoIP.
no ip cef
!
class-map match-any SIP
description --- match con la segnalazione ---
match access-group name SIP-LIST
!
class-map match-any RTP
description --- match con il traffico voce RTP --
match
access-group 151
!
policy-map parent
class class-default
shape average 1400000
service-policy VOIP
!
policy-map VOIP
description --- questa va bene se non si usa il nat ---
class SIP
priority 64
class RTP
priority 512
!
...
interface Serial0/0/0
description --- TD 941837/44 ---
bandwidth 2048
ip nat outside
encapsulation frame-relay IETF
load-interval 30
frame-relay
traffic-shaping <- GINO: SE METTO QUESTA
NON FA METTERE LA (2) E VICEVERSA
!
interface Serial0/0/0.1 point-to-point
description --- TD 941837/44 subinterface ---
bandwidth 2048
ip address 83.211.4.186 255.255.255.255
ip nat outside
frame-relay
interface-dlci 20 IETF <-- (2)
class VOIP2
!
map-class frame-relay
VOIP2
frame-relay cir 1400000
frame-relay bc 128000
service-policy output parent
!
...
ip access-list extended SIP-LIST
permit udp any any eq 5060
!
!Questo
e' l'ip del gateway SIP (attenzione, qui .131 e' il registration proxy, ma rtp
e' 133)
access-list 151 permit udp any host 192.168.10.133
!Questo e' nel
caso dovesse cambiare l'ip del gateway sip
access-list 151 permit udp any range 16384 16500 any
Figura 18: Configurazione QoS di esempio
Con questo test vogliamo verificare la banda
effettivamente utilizzata da un telefono IP, in questo caso un Cisco Linksys
SPA, in una telefonata SIP con protocollo G729. Utilizzando un CB-WFQ possiamo
isolare il traffico RTP. Effettuando una unica telefonata e' possibile ottenere
il dato come in figura. Troviamo che una telefonata G729 occupa 19kbps effettivi
di banda come mostra la figura successiva.
acme-roma-grat#sh policy-map interface serial 0/0/0.1
Serial0/0/0.1: DLCI 20 -
Service-policy output: parent
Class-map: class-default (match-any)
1050589 packets, 942463925 bytes
30 second offered rate 168000 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
1400000/1400000 8750 35000 35000 25 4375
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 1049826 941433953 375193 381617645 no
Service-policy : VOIP
Class-map: SIP (match-any)
14418 packets, 5269237 bytes
30 second offered rate 3000 bps, drop rate 0 bps
Match: access-group name SIP-LIST
14418 packets, 5269237 bytes
30 second rate 3000 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 47/16675
(total drops/bytes drops) 0/0
Class-map: RTP (match-any)
60118 packets, 8339316 bytes
30 second offered rate 19000 bps, drop rate 0 bps
Match: access-group 151
60118 packets, 8339316 bytes
30 second rate 19000 bps <---
banda occupata da un linksys
in G729.
Attenzione che qui non si vede
il
pacchetto
IP/UDP che occupa molto spazio e dentro il
quale ci sta RTP
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 512 (kbps) Burst 12800 (Bytes)
(pkts matched/bytes matched) 587/98508
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
976053 packets, 928854160 bytes
30 second offered rate 145000 bps, drop rate 0 bps
Match: any
Figura 19: Traffico VoIP per G729
LLQ per circuiti ATM e Frame-Relay
In molti casi la QoS va applicata in circuiti WAN basati sul
protocollo Frame-Relay o ATM. Basti pensare alle
connettivita' ADSL, che sono basate su ATM. Secondo la
documentazione Cisco, ma anche secondo il buon senso, una
politica di QoS si puo' solo realizzare quanto sono noti
chiaramente i parametri contrattuali di banda con
l'operatore che ci vende un collegamento WAN. Se dobbiamo
collegare due sedi di un ufficio, dobbiamo richiedere una
banda garantita ben precisa per entrambe le sedi, e su
quella banda garantita configurare una politica di QoS
outbound per entrambe le sedi. Solo in questo modo la nostra
configurazione funzionera' correttamente.
Non e' possibile implementare politiche di QoS in collegamenti
senza banda garantita perche', come e' ovvio che sia, il
provider scarterebbe i pacchetti in eccesso in base alla
banda disponibile durante la giornata, rendendo vano il
tentativo del router di dare priorita' ad un certo tipo di
traffico. Sarebbe perfettamente inutile fare passare per
primi i pacchetti VoIP se poi e' il provider a scartarli! In ogni caso la trattazione
di questo documento e' rivolta a tutti quei casi dove non e'
possibile, per motivi di budget, acquistare collegamenti a
banda garantita "reale". Infatti non basta avere la banda
garantita ad entrambi i capi di un collegamento WAN. E'
importante avere la certezza che non vi siano tratte
congestionate tra i due capi. Per far questo i due capi di
un collegamento con QoS "dovrebbero avere collegamenti con
banda garantita di uno stesso operatore". Questo problema
non si pone se acquistiamo collegamenti ATM o frame-relay
punto-punto. Se invece volessimo utilizzare due collegamenti
ADSL verso Internet con banda garantita ma con due operatori
differenti, non e' detto che un trasferimento dati da un
capo all'altro abbia quella banda garantita.
Insomma, se dobbiamo fare QoS tra due punti, dobbiamo
effettuare un collegamento con banda garantita con un
operatore che sia in grado di darci uno SLA (service level
agreement) ben preciso. E' per chi vuole sfruttare
collegamenti verso Internet invece che circuiti punto-punto,
sappia che dovra' sacrificare la banda in eccesso rispetto
quella garantita, specialmente se si vuole fare QoS per
circuiti voce o video.
L'algoritmo di Token Bucket e il frame-relay
Nel caso di un circuito frame-relay si definiscono questi parametri:
- CIR ovvero banda massima media garantita;
- valore medio M di traffico consentito sull'interfaccia
(CIR - mediato su qualche secondo);
- valore di burst
Bc ovvero CIR per unita' di tempo, che e' una frazione di
secondo;
- intervallo di tempo t;
- valore di burst exceeded Be
ovvero bit che si possono inviare oltre al Bc e quindi al
CIR;
Supponiamo allora di avere un tipico collegamento frame-relay a 2mbps. Avremo un CIR ovvero un valore medio di traffico (media su un certo numero di secondi) che il provider ci garantisce e che abbiamo contrattualizzato. I blocchi dati vengono inviati in modo da trasmetterne in 1 secondo non oltre il valore di CIR configurato. Ma quanto sono grandi questi blocchi di dati? Possono introdurre delay e jitter per la voip. Per configurarne la dimensione si usa il burst size (Bc)
Tc = Bc / CIR
Figura 19 : Algoritmo Token Bucket
dove Tc e' il segmento di tempo che indica il tempo per l'invio
di uno dei blocchi di cui sopra.
Se il CIR e' 100kbps e il Bc e' di 1000 bit (ovvero 0,010 x CIR
come consigliato da Cisco) avremo un valore di Tc di 0,01 ovvero
10ms. Ogni 10ms verranno inviati 1000 bit alla velocita' di
clock di 2mhz cosi' da ottenere in un secondo il valore di CIR.
Quindi Bc non ha niente a che fare con trasmissione al di sopra
del CIR (nb. errore comune). Invece Be indica di quanto si puo'
aumentare Bc con lo scopo di andare oltre il valore di CIR.
Il Token Bucket e' un meccanismo per gestire il traffico che
attraversa una interfaccia. Il token bucket e' utilizzato dai router Cisco quale parametro
nella gestione della QoS. Ma come? Si crea un cestino (virtuale) di dimensione Bc bit
chiamato token bucket. Nel cestino entrano CIR token al secondo.
Ogni token e' dato ad un bit cosi', se non ci fossero problemi,
il cestino dovrebbe restare sempre pieno e i dati sempre
trasmessi. Se non ci sono token si blocca la trasmissione.
Poiche' pero' ci saranno applicazioni che vogliono mandare dati
a velocita' maggiore del CIR (in quanto le applicazioni non sono
consapevoli della banda disponibile) i token si esauriscono e la
trasmissione dati viene bloccata finche' non se ne accumulano a
sufficienza.
Il router cerchera' Bc token per ogni trasmissione in quanto
invia Bc bit per ogni Tc.Se pertanto creiamo dei cestini di dimensione opportuna per
alcuni flussi di traffico (alla fine associati a ACL) possiamo
limitare la banda disponibile per questi servizi. Si tratta di
creare N cestini con CIR_N per cestino. Normalmente la
CIR_1+CIR_2+...+CIR_N <= CIR.
LLQ Frame-Relay
Quanto detto, nel caso di un circuito frame-relay vuol dire
avere ben chiari i valori di minCIR e CIR garantiti dall'operatore sul circuito nel quale si lavora.
"La somma dei valori di priority e bandwith che utilizziamo
dovra' essere inferiore al valore di minCIR. Di default,
minCIR e' la meta' del CIR. Insomma, dobbiamo considerare la
banda realmente garantita.
Ecco come procedere:
| 1 |
frame-relay traffic-shaping |
Nell'interfaccia seriale relativa al circuito frame-relay (non nella sotto interfaccia) si deve abilitare il traffic shaping. Senza questo comando non funzionerebbero le map-class e l'LLQ. Quindi questo passo e' fondamentale. |
| 2 |
interface Serial0/0/0 |
Nella subinterface sara' presente il comando "class" che si associa al successivo comando "map-class" dove si specifica la banda totale disponibile nel circuito |
| 3 |
map-class frame-relay VOIP2 |
In questo caso abbiamo un circuito con banda garantita di 1,2mbps. CIR e minCIR allora corrispondono. Il minCIR sarebbe di default il 50% del CIR quindi e' bene specificarlo perche' questo e' il valore di banda disponibile sull'interfaccia che il router utilizza nei calcoli di banda allocabile. Con il comando "no frame-relay adaptive-shaping" disabilitiamo l'adaptive shaping che consiste in un automatismo con cui il router stabilisce la velocita' di trasmissione sul circuito in risposta alle notifiche di congestione di tipo BECN. Il punto e' che non bisogna superare la banda garantita. Non ci si puo' affidare al meccanismo del Frame-Relay di gestione della congestione, con i messaggi BECN, perche' la qualita' della VoIP ne risente. Il valore di "be" dev'essere zero perche' altrimenti un pacchetto VoIP potrebbe essere inviato in un burst. Il CIR=Tc/Bc. Si possono mandare "Bc" frames in un periodo di "Tc" secondi. Se riduciamo Tc un pacchetto voce dovra' aspettar meno prima di essere inviato. Notiamo la presenza di un "service-policy input", in apparente contraddizione con quanto detto nei paragrafi precedenti. Analizzeremo questa riga in seguito quando si approfondira' il problema del traffico in ingresso. |
Figura 20 : Esempio di configurazione LLQ su circuito Frame-Relay
Per la service-policy vale quanto detto nei paragrafi precedenti. Ricordatevi la limitazione di default del 75% della banda allocabile e la verifica della banda non ancora allocata con "show traffic-shape queue".
LLQ ATM
Osserviamo il seguente esempio:
| 1 |
|
Nel pvc relativo al circuito utilizziamo il comando "cbr", o il "vbr-nrt" per indicare la banda garantita. Non e' possibile utilizzare UBR con CBWFQ. Il fatto che possa essere un PCR molto piu' altro, ad esempio 512kbps, non e' rilevante ai fini del QoS. Di fatto perdiamo la banda eccedente i 64kbps, che pero' non e' garantita. Ecco allora che ha senso fare QoS solo su circuiti con una buona banda garantita. Notate il comando "tx-ring-limit" commentato sotto. "vrb-nrt" vale per il traffico in uscita. |
| 2 |
|
Qui applichiamo la policy. Da notare il "max-reserved-bandwidth 99" che ci permette di allocare tutta la banda disponibile, che per default e' allocabile nelle policy al 75%. |
Figura 21 : QoS e circuiti ATM
Il comando "tx-ring-limit" permette di fare il tuning della coda di basso livello associata ad un'interfaccia. Normalmente non e' necessario modificare questo parametro. Questa e' una coda che funziona solo in modalita' FIFO in quanto la linea di trasmissione e' una e quindi una sara' la coda. Sostanzialmente definisce il numero di pacchetti che possono aspettare la trasmissione a livello 2. Diciamo che per migliorare la qualita' della voce non si deve utilizzare un valore alto per questo parametro. A livello 3 poi ci sono le code software gestibili con i comandi spiegati sino ad ora. Quando una ring in trasmissione si riempie, l'interfaccia ATM sposta i dati a layer-3. Si notifica al processore di layer-3 di non inviare piu' pacchetti al layer-2.Per vedere il settaggio del ring si usa il comando "show controller atm".
Se si configura un PVC senza specificare il PCR il circuito automaticamente diventa di tipo UBR. Questo PVC avra' un PCR automaticamente pari alla velocita' della linea. Nel momento in cui c'e' un traffico in uscita superiore a quello che puo' gestire il PVC (o che e' configurato con lo shape) il router attiva il queueing e i meccanismi di drop come WRED o altri (se configurati esplicitamente).
Per determinare se si sta superando la banda disponibile basta verificare il valore OutPktDrops come in figura:
core-2600#sh int atm0/0
ATM0/0 is up, line protocol is up
Hardware is DSLSAR (with Alcatel ADSL Module)
Description: --- TISCALI ---
MTU 4470 bytes, sub MTU 4470, BW 640 Kbit, DLY 800 usec,
reliability 255/255, txload 24/255, rxload 27/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5 AAL2, PVC mode
23 maximum active VCs, 256 VCs per VP, 1 current VCCs
VC Auto Creation Disabled.
VC idle disconnect time: 300 seconds
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters 4d00h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 25313
Queueing strategy: Per VC Queueing
30 second input rate 68000 bits/sec, 23 packets/sec
30 second output rate 61000 bits/sec, 22 packets/sec
7519768 packets input, 1868924255 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 8 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
8116856 packets output, 490785195 bytes, 0 underruns
117 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out
Figura 22 : Output drops in interfacce ATM
...
TxQInfo for vcd 0
--------------------
tx_ring_limit=10, max_tsi_seq_num=4, max_tx_time=268200
Total number of packets = 0
Total number of packets transmitted = 0
Total number of packets dropped = 0
HP TxQInfo for vcd 0
--------------------
tx_ring_limit=30, max_tsi_seq_num=20, max_tx_time=268200
Total number of packets = 0
...
Figura 23 : Comando 'show controller atm'
Il protocollo ATM fornisce numerose classi di servizio quali VBR, CBR, UBR. Questo perche' ATM e' un protocollo che nasce per fornire una robusta gestione della qualita' del servizio e dell'ingegneria del traffico. Quando acquistiamo un circuito ATM, che puo' essere ad esempio un circuito ADSL o SHDSL, il fornitore del servizio configura sul nostro circuito una qualita' del servizio fornendoci parametri come PCR (peek cell rate) che rappresenta il valore massimo ma non garantito sulla linea, e poi valori quali l'MCR che rappresenta il minimum cell rate (e quindi garantito). Il VBR a sua volta puo' essere VBR-nrt (data+voip) o il VBR-rt (se solo voip o video). Un CBR e' un circuito con un PCR=MCR. Ecco un riepilogo:
- PCR picco che si puo' mantenere per MBS celle
- SCR banda media garantita
- MCR banda minima garantita
VBR-nrt usa l'algoritmo di token-bucket. Il token bucket si riempie alla velocita' dell'SCR e non del PCR. E qui sta la differenza. Infatti se si trasmette alla velocita' del PCR si potra' farlo sino allo svuotamento del bucket. A questo punto saro' costretto a trasmettere alla velocita' indicata dall'SCR finche' il bucket non ritorna ad un valore tale da permettere un altro burst. Il parametro MBS determina la dimensione massima del pacchetto che si puo' spedire come burst. Ad esempio 32 celle ATM possono trasmettere un pacchetto di 1500byte in quanto 32*53byte=1696byte.
Per un circuito XDSL con trasmissione voce/dati e' ideale utilizzare vbr-nrt con il PCR=SCR>MCR
Tutti questi parametri dovrebbero essere dati dal fornitore di servizio, ma non e' sempre semplice averli. Oltretutto molti collegamenti XDSL di fascia bassa sono configurati con UBR. In tal caso dovremmo chidere un servizio di qualita' superiore, oppure configurare il nostro router con un vbr-nrt specificando una banda garantita che siamo sicuri di avere, al di la' della configurazione lato provider.
Nota su UBR: Con UBR gli switch ATM dell'operatore cestinano le celle quando i loro buffer si riempiono, perche' congestionati. Il servizio UBR di ATM non ha un meccanismo di notifica della congestione. Semplicemente implementa una politica "tail drop".
Ecco un esempio con una configurazione tipica di LLQ in uscita in una interfaccia ATM:
!
class-map match-all VOICE
match access-group 100
!
policy-map MYPOLICY
class VOICE
priority 160
class class-default
bandwidth 320
!
...
interface ATM0/0.1 point-to-point
ip address 192.168.2.2 255.255.255.0
pvc 0/101
protocol ip 192.168.2.1 broadcast
vbr-nrt 640 640
<--- e' per l'outbound
tx-ring-limit 3
service-policy output MYPOLICY
!
...
access-list 100 permit udp any any precedence critical
!
Figura 24 : LLQ in interfaccia ATM
SECONDA PARTE
QUALITA' DEL SERVIZIO IN INPUT
I comandi service-policy sono stati inseriti in "output" sulle interfacce e non in "input". Questo perche' possiamo fare shaping solo in uscita. Infatti per il traffico in uscita il punto di congestione e' il CPE (ad esempio il router ADSL o HDSL) in quanto il traffico proviene da una rete ad alta velocita' come una Ethernet. Nel caso del traffico in ingresso il punto di congestione e' esterno al router e si trova presso il provider ISP fornitore di connettivita'. In ingresso possiamo fare policing. La tecnologia che si utilizza e' il CAR, tramite il comando "car" o tramite il comando "police" all'interno di una classe di servizio.
Il comando police
Con il comando "police" e' possibile aggiungere il traffic-policy in ingresso nelle configurazioni dei paragrafi precedenti. I comandi "priority" e "bandwidth" non possono essere utilizzati in ingresso. Il comando "police" puo' essere utilizzato in ingresso. Esaminiamolo con attenzione:
police cir percent percentage
[burst-in-ms] [bc
conform-burst-in-msec
ms] [be peak-burst-in-msec
ms] [pir percent percent]
police
bps [burst-normal] [burst-max]
conform-action action exceed-action action [violate-action action]
Figura 25 : Comando 'police'
I parametri "bc" e "be" hanno lo scopo di scartare i pacchetti gradualmente, un po' come fa WRED, per evitare che i pacchetti vengano scartati per "tail drop". I valori sono in millisecondi. I valori Bc e Be sono stati spiegati nel paragrafo dell'algoritmo tocken-bucket.
CAR
CAR ci permette di limitare il traffico che attraversa una interfaccia (si puo' agganciare ad una qualsiasi access-list). CAR fa policy e non shaping. Un secondo uso di CAR e' quello di classificare i pacchetti in base alla loro tipologia (ad esempio cambiandone la priorita' usando ToS e delegando la limitazione di banda ad altra policy). CAR e' spesso configurato nei router di confine di una rete, punto ideale per gestire la banda disponibile esternamente. CAR usa il token bucket per determinare quanta banda si sta utilizzando. Il CAR usa i concetti di burst e extended burst. Questi operano in modo simile a quanto gia' spiegato per il frame-relay.
CAR QUINDI NON FA RESERVATION DI BANDA MA CONTROLLA SOLO CHE NON SUPERA UNA CERTA SOGLIA <--- VERIFICARE
Cisco consiglia la scelta di questi valori con questa formula:
normal burst = configured rate * (1 byte)/(8 bits) * 1.5 seconds
extended burst = 2 * normal burst
Figura 26 : CAR e 'burst'
CAR e' aggressivo, fa drop dei pacchetti in eccesso e il protocollo TCP e' costretto a ritrasmetterli e a ridurre la finestra di trasmissione.
Ecco la sintassi del comando:
rate-limit {input | output} [access-group [rate-limit] acl-index] bps burst-normal burst-max conform-action action exceed-action action
Figura 27 : Comando 'rate-limit'
la spiegazione dei parametri sara' fatta con un esempio pratico nei prossimi paragrafi.
Configurazione con CAR
Supponiamo che in input si voglia limitare la banda per i servizi http a 100kbps. Cio' vuol dire che vogliamo che l'accesso http non occupi mai piu' di 100kbps. La banda restante sara' a disposizione degli altri servizi. Se non c'e' traffico http tutta la banda sara' a disposizione di altri servizi.
La configurazione del CAR non e' richiede solo il semplice valore di 100kbps. Infatti un flusso TCP non puo' essere vincolato ad una larghezza di banda perfettamente pari ad un valore in quanto la dimensione dei pacchetti e variabile e la dimensione della finestra e' variabile. Quando una connessione supera i 100kbps e si fa un packet drop allora il sender, tramite l'algoritmo di back-off, diminuisce la finestra e invia nuovamente il pacchetto. Poi provera' nuovamente ad allargare la finestra. Percio' un flusso TCP puo' oscillare attorno ad un valore ma non mantenerlo costantemente. Attenzione che cio' e' vero per il TCP e non per l'UDP. Da queste considerazioni nascono tre parametri.
Il valore di 100kbps lo definiamo
quindi come 'average rate' ovvero e' un valore medio a
lungo termine di flusso.
!
ip cef
!
interface FastEthernet0/1
description ------ OUTBOUND ----
ip address 192.168.30.241 255.255.255.0
rate-limit input access-group 100 1000000 120000 240000 conform-action continue exceed-action drop
service-policy output VOIP
!
Figura 28 : Esempio di configurazione CAR
Consideriamo un semplice caso di un router con due interfacce Ethernet (100mbps) attraversate da intenso traffico. Vediamo cosa succede applicando il policing. I test a seguire sono stati realizzati con l'aiuto del software opensource "iperf".
Ecco il nostro schema di rete:
192.168.30.230 (server) --- OUTBOUND --- ROUTER CISCO serie 1800 ios 12.4 --- INBOUND --- 192.168.10.241 (client)
Figura 29 : LAB per test CAR
La figura mostra cosa accade nel caso di un traffico intenso senza restrizioni di policing applicate:
-----------------------------------------------------------
client --> server
------------------------------------------------------------
[ 5] local 192.168.30.230 port 5001 connected with
192.168.10.241 port 2892
[ 5] 0.0-10.0 sec 112 MBytes 94.0 Mbits/sec
------------------------------------------------------------
server--> client
------------------------------------------------------------
[ 5] local 192.168.30.230 port 55473 connected with
192.168.10.241 port 5001
[ 5] 0.0-10.0 sec 111 MBytes 93.1 Mbits/sec
Figura 30 : LAB: test iniziale con CAR non attivo
Test 1: Flusso TCP di circa 100kbps in ingresso dalla rete esterna
Applichiamo il rate-limit sul traffico in input dell'interfaccia fasteth0/1 (per input si intende, come l'intuito suggerisce, il traffico proveniente dal cavo collegato all'interfaccia fasteth0/1).
average = 100000
Bc = 100000/8*1.5 = 18750
Be = Bc * 2 = 37500
Figura 31 : LAB test1 rate-limit - calcolo banda
Utilizzando una notazione propria del Frame-relay diciamo che "average" e' il CIR, che e' 100000 bytes. Il burst e' Bc. Il valore di Tc = Bc/CIR = 18750/100000=0,187 sec= 187ms. Vuol dire che il policer permettera che ogni 187ms possono transitare 18750 bytes. In un secondo avremo circa 6 Tc. Un valore piu' basso di Bc implica la presenza di un numero di intervalli di tempo maggiore per mandare il traffico e diminuisce la latenza. Questo e' buono per traffico come il VoIP. D'altro canto un burst troppo piccolo dara' una banda inferiore al valore specificato.
L'extended burst puo' essere disattivato (posto pari al normal
burst) quando e piu' alto del normal burst. Indica di quanti byte
puo' essere superato il normal burst. Nel traffico che ricade nell'extended burst la policy di drop dei pacchetti e' simile a quella del RED. Il flusso di traffico che cade nella fascia dell'extended bust piu' volte viene penalizzato maggiormente. E' necessario il CEF per usare il CAR.
Il test e' stato effettuato su un periodo di 10 secondi di trasmissione.
interface FastEthernet0/0
description ---- INSIDE ----
ip address 192.168.10.254 255.255.255.0
!
interface FastEthernet0/1
description ------ OUTBOUND ----
ip address 192.168.30.241 255.255.255.0
rate-limit input access-group 10 96000 18750 37500
conform-action continue exceed-action drop
!
access-list 10 permit 192.168.30.230
Figura 32 : LAB test1 rate-limit - configurazione
Dalla configurazione si evince che il traffico che ha come mittente l'indirizzo IP 192.168.30.230 e' soggetto a rate-limit in input. In presenza di NAT il rate-limit viene fatto dopo (nel caso di traffico in uscita viene fatto sull'ip pubblico)
1a prova
------------------------------------------------------------
traffico dal client verso il server (non rate-limit in quanto
outbound su fasteth0/1)
------------------------------------------------------------
[ 4] local 192.168.30.230 port 5001 connected with
192.168.10.241 port 2881
[ 4] 0.0-10.1 sec 11.3 MBytes 9.33 Mbits/sec
------------------------------------------------------------
traffico dal server verso il client (con rate-limit in quanto
input su fasteth0/1)
------------------------------------------------------------
[ 4] local 192.168.30.230 port 50883 connected with
192.168.10.241 port 5001
[ 4] 0.0-11.4 sec 128 KBytes 92.3 Kbits/sec
Figura 33 : LAB - prova 1 -
2a prova
[ 5] local 192.168.30.230 port 5001 connected with
192.168.10.241 port 2882
[ 5] 0.0-10.3 sec 11.0 MBytes 8.99 Mbits/sec
[ 5] local 192.168.30.230 port 50884 connected with
192.168.10.241 port 5001
[ 5] 0.0-11.0 sec 168 KBytes 125 Kbits/sec
Figura 34 : LAB - prova 2 -
3aprova
[ 4] local 192.168.30.230 port 5001 connected with
192.168.10.241 port 2885
[ 4] 0.0-10.2 sec 12.4 MBytes 10.2 Mbits/sec
[ 4] local 192.168.30.230 port 37016 connected with
192.168.10.241 port 5001
[ 4] 0.0-10.9 sec 160 KBytes 120 Kbits/sec
Figura 35 : LAB - prova 3 -
Notiamo che limitare la banda in ingresso puo' limitare anche la banda in uscita quanto piu' il traffico e' simmetrico. Se volete variare la "windows size" utilizzate il parametro "-w" di iperf.
Test 2. Flusso TCP di circa 100kbps in ingresso e uscita dalla rete esterna
[ 4] local 192.168.30.230 port 5001 connected
with 192.168.10.241 port 2898
[ 4] 0.0-11.1 sec 136 KBytes 100 Kbits/sec
[ 4] local 192.168.30.230 port 41936 connected with
192.168.10.241 port 5001
[ 4] 0.0-11.3 sec 144 KBytes 105 Kbits/sec
Figura 36 : LAB - test2 - Assegnazione traffico
interface FastEthernet0/1
description ------ OUTBOUND ----
ip address 192.168.30.241 255.255.255.0
rate-limit input access-group 10 96000 18750 37500
conform-action continue exceed-action drop
rate-limit output access-group 100 96000 18750 37500
conform-action continue exceed-action drop
access-list 10 permit 192.168.30.230
access-list 100 permit ip any host 192.168.30.230
Figura 37 : LAB test2 - configurazione
Conclusioni test CAR
Per il traffico UDP iperf non e' in grado di calcolare la larghezza di banda di un link. E' in grado di inviare un flusso CBR di pacchetti UDP e verificare il numero di datagrammi inviati e ricevuti. Inoltre indica il valore di jitter ovvero il tempo necessario per riassemblare piu' pacchetti IP per ricostruire un singolo datagramma UDP (quando richiede piu' di un pacchetto). Con UDP non esiste un meccanismo di backoff come per TCP cosi' nel CAR l'uso di Be non serve a nulla. In questo caso CAR tagliera' i pacchetti in eccesso e alla destinazione arriveranno dati incompleti (o voce a tratti se state usando la voip).
E' interessante usare il test UDP per vedere i packet-loss che non si vedono con il test sul TCP. Quindi per il test di un collegamento va usato insieme al test sul TCP.
Per quanto riguarda la VoIP il CAR e' utile per il traffico in ingresso. Infatti in caso di collegamenti di apparati verso Internet (XDSL, CDN, etc.) se volete avere banda riservata in ingresso per la voip non potete fare molto di piu' che mettere un "rate-limit" per limitare il traffico non VoIP.
Questo vi obbliga a rinunciare in modo permanente alla banda in ingresso riservata per il voip, anche quando non c'e' traffico voip. Pero' bisogna lavorare sulla banda garantita. Infatti la banda in ingresso spesso non e' garantita dal provider, quindi bisogna usare esperienza e buon senso. Non potete usare altre tecniche di shaping/policy in ingresso in quanto, in casi come collegamenti verso Internet, e' l'ISP che decide la policy per voi a monte in base a quanto contrattualizzato.
Qualita' del servizio in ingresso per collegamenti a banda variabile
Come abbiamo potuto osservare una qualita' del servizio per traffico in ingresso da un collegamento WAN che non siamo in grado di amministrare da entrambi i capi (caso tipico collegamento ADSL verso un ISP) e' fattibile solo se si lavora nella fascia di banda garantita a disposizione. Se infatti si chiede piu' banda di quella disponibile sara' il carrier a tagliare il traffico scartando senza criterio pacchetti IP.
Ci domandiamo fino a che punto possiamo spingerci per sfruttare al massimo ogni singolo bit di banda a disposizione. Devo dire che, al momento in cui scrivo, non si puo' far molto con i router Cisco. Questa in realta' non e' una limitazione della piattaforma ma piuttosto il contrario: sono router ben fatti e non ci sono applicazioni che non funzionerebbero con la necessaria affidabilita'.
In realta' con gli script TCL e EEM anche con Cisco possiamo immaginare una soluzione personalizzata. Infatti una class map e' in grado di fare il detect della VoIP e uno script TCL puo' vedere tramite MIB tale parametro. Quindi con EEM si puo' riconfigurare la class map finche' c'e' traffico voip. Attualmente il MIB dovrebbe essere aggiornata ogni 10 secondi quindi la voce potrebbe non essere rilevata all'istante.
In alternativa si puo' utilizzare un server Linux con snort, che e' in grado di fare lo sniffing del traffico e rilevare il Voip (ad esempio dalle porte UDP utilizzate con RTP), quindi SEC, un correlatore di eventi che e' in grado di eseguire script in corrispondenza di una serie di eventi letti in un file di log, e infine uno script in Perl in grado di fare telnet (con il package Net::Telnet) in un router per cambiare la configurazione. Su Internet si trova della documentazione, ad esempio cercando "APPLICATION AWARE TRIGGERED QUALITY OF SERVICE (AATQoS)"
Il protocollo IP prevede un byte per ogni pacchetto chiamato Type Of Service (ToS). Di questo byte vengono utilizzati 3 bit che prendono il nome di "IP precedence" e che consentono di etichettare i pacchetti in base alla precedenza che devono avere in rete. Ovviamente affinche' il tutto funzioni tutti i router della rete devono considerare il contenuto di tale byte e trattare il traffico di conseguenza. Nei router Cisco esiste il comando "ip precedence" proprio per gestire questo valore.
Questo modo di interpretare il byte di precedenza IP e' indicato nell'RFC-791.
In tempi piu' recenti e' stato introdotto un nuovo standard e un nuovo modo di interpretare il contenuto del byte ToS. Il nuovo standard si chiama DiffServ ed utilizza 6 degli 8 bit a disposizione.
Secondo questo nuovo formato il campo ToS viene anche chiamato DSCP (Differentiated Services Code Point).
Con DiffServ intendiamo l'abbreviazione di "Differentiated Services".
Consideriamo quindi il byte DiffServ. I primi sei bit sono DSCP e sono indicati con DS0-DS5. I due restanti bit sono indicati con 'IP ECN' e non sono utilizzati. DS3,DS4,DS5 indicano la priorita' ed hanno la stessa posizione dei campi "ip precedence" del ToS. Questo permette una parziale compatibilita' con quei router che interpretano il ToS byte secondo RFC-791.
I valori DSCP nella forma xxx000, con x pari a 0 o 1 permettono di conservare la compatibilita' con IP precedence.
Ecco i valori di questi tre bit:
| Valore | Descrizione |
|---|---|
| 7 |
Questo traffico ha priorita' massima. Deve essere traffico di controllo per la rete, come i keepalive. |
| 6 |
Traffico ad alta priorita', ad esempio le informazioni dei protocolli di routing come RIP, EIGRP etc. |
| 5 |
Classe EF - traffico ad alta priorita', ad esempio VoIP |
| 4 |
Class 4 -AF- |
| 3 | Class 3 -AF- |
| 2 | Class 2 -AF- |
| 1 | Class 1 -AF- |
| 0 | Best effort |
Figura 38 : Valori DSCP
Una volta fissati gli ultimi 3 bit, vengono utilizzati DS1-DS2 per indicare la probabilita' per il drop dei pacchetti. Con 'behavior aggregate' (BA) intendiamo un gruppo di pacchetti con lo stesso valore di DSCP in uno stesso flusso. Con PHB si intende il trattamento assegnato ad un BA. Ci sono quattro standard RFC per quattro tipi di PHB. DS0 vale sempre zero. Ci sono tre valori di preferenza, "low", "medium" e "high" rispettivamente associati a "01","10","11". Con "AFXY" indichiamo la classe X e il drop Y. Ad esempio AF21 e' la classe 2 e il drop low.
Il valore "5" Express Forwarding indica una priorita' particolare da utilizzare per creare una specie di circuito privato tra due punti, ad alta priorita'. Il valore DSCP e' 46. L'RFC-2597 definisce il PHB per le classi di tipo AF.
Il comando "ip precedence" e' considerato obsoleto e va invece usato "ip qos dscp".
I valori XXXXX0 sono predefiniti. I valori XXXX11 e XXXX01 sono utilizzabili localmente per configurazioni personalizzate.
L'uso del DSCP puo' anche essere limitato ad un singolo router, se utilizzato per fare QoS insieme a LLQ e CAR. E' quest'ultimo utilizzo che interessa in questa argomentazione. Il comando "rate-limit" ha un parametro di "set-dscp-transit" che permette di cambiare il valore del campo nei pacchetti IP che, ad esempio, sono conformi o eccedono la banda configurata.
rate-limit output access-group 120 28000 21500 22000 conform-action set-dscp-transmit 10 exceed-action set-dscp-transmit 20
Figura 39 : rate-limit e dscp
Anche la configurazione del WRED permette di considerare il dscp con il comando "random-detect dscp"
informedicanew(config-cmap)#match ip dscp ?
<0-63> Differentiated services codepoint value
af11 Match packets with AF11 dscp (001010)
af12 Match packets with AF12 dscp (001100)
af13 Match packets with AF13 dscp (001110)
af21 Match packets with AF21 dscp (010010)
af22 Match packets with AF22 dscp (010100)
af23 Match packets with AF23 dscp (010110)
af31 Match packets with AF31 dscp (011010)
af32 Match packets with AF32 dscp (011100)
af33 Match packets with AF33 dscp (011110)
af41 Match packets with AF41 dscp (100010)
af42 Match packets with AF42 dscp (100100)
af43 Match packets with AF43 dscp (100110)
cs1 Match packets with CS1(precedence 1) dscp (001000)
cs2 Match packets with CS2(precedence 2) dscp (010000)
cs3 Match packets with CS3(precedence 3) dscp (011000)
cs4 Match packets with CS4(precedence 4) dscp (100000)
cs5 Match packets with CS5(precedence 5) dscp (101000)
cs6 Match packets with CS6(precedence 6) dscp (110000)
cs7 Match packets with CS7(precedence 7) dscp (111000)
default Match packets with default dscp (000000)
ef Match packets with EF dscp (101110)
Figura 40 : comando 'match ip dscp'
Nell'esempio che segue vediamo una classificazione dei pacchetti in ingresso in una interfaccia Ethernet. In base alla classificazione otterranno delle priorita' differenti nell'interfaccia in uscita. In rosso sono indicati i comandi del classificatore. In blu i comandi dello shaper.
class-map match-any prioritavoip
match ip dscp ef
!
class-map match-any voip-tag
match access-group name etichetta
!
policy-map prioritavoip
class prioritavoip
bandwidth 8500
class class-default
fair-queue
queue-limit 5
!
policy-map trafficovoip
class voip-tag
set ip dscp ef
class class-default
set ip dscp default
!
interface
FastEthernet0/0
no ip
address
service-policy output prioritavoip
!
interface
FastEthernet0/0.7
encapsulation dot1Q 7
ip
address 192.168.1.1 255.255.255.0
!
interface
FastEthernet0/1
description Hub to Office
ip
address 192.168.7.9 255.255.255.0
service-policy input trafficovoip
!
ip
access-list extended etichetta
permit ip
host 192.168.7.19 host 192.168.1.19
!
Figura 41 : classificatore con DSCP
DSCP+POLICING + SHAPING
Tecnica QoS: Come usare il NAT e riconoscere i pacchetti voce che cambiano porte attraverso il nat
Si flaggano
con una policy prima del NAT e si controlla il flag dopo
| Inside-to-Outside | Outside-to-Inside |
|---|---|
|
|
Figura 42 : ordine di elaborazione pacchetti in ingresso e uscita
NAT Configuration and Output
? DA VERIFICARE ESATTEZZA
!-----------------------------------------------
! 1- Catturiamo tutto il traffico voce
!-----------------------------------------------
class-map match-any CATTURAVOCE
match protocol rtp audio
!-----------------------------------------------
! 1a- Catturiamo tutto il traffico di segnalazione
!-----------------------------------------------
class-map match-any CATTURAVOCESEGNALAZIONE
match protocol rtcp
!-----------------------------------------------
! 1b- Marchiamo il traffico in arrivo dalla LAN
!-----------------------------------------------
policy-map MARCADALAN
class CATTURAVOCE
set ip dscp ef
class CATTURAVOCESEGNALAZIONE
set ip dscp cs3
!-----------------------------------------------
! 1c- Marchiamo il traffico in arrivo dalla LAN
!-----------------------------------------------
interface Ethernet0
ip address 192.168.10.1 255.255.255.0
ip nat inside
service-policy input MARCADALAN
hold-queue 100 out
!-----------------------------------------------
! 2- Catturiamo tutto il traffico voce
!-----------------------------------------------
class-map match-any CATTURAVOCE
match ip dscp ef
!-----------------------------------------------
! 2a- Catturiamo tutto il traffico di segnalazione
!-----------------------------------------------
class-map match-any CATTURAVOCESEGNALAZIONE
match ip dscp cs3
!-----------------------------------------------
! 2b- Marchiamo il traffico in arrivo dalla LAN
!-----------------------------------------------
policy-map PRENDI_MARCATI
class CATTURAVOCE
match ip dscp ef
priority 128
class CATTURAVOCESEGNALAZIONE
match ip dscp cs3
priority 64
!----------------------------------------------
! 2c- Marchiamo il traffico in arrivo dalla LAN
!----------------------------------------------
interface ATM0
service-policy output PRENDI_MARCATI
pvc 8/35
encapsulation aal5mux ppp dialer
dialer pool-member 1interface Dialer0
bandwidth 400
ip address negotiated
ip nat outside
encapsulation ppp
dialer pool 1
dialer-group 1
ppp chap hostname a062901@sum.itesys.it
ppp chap password 0 abc1004
! access-list 102 permit udp host 16.0.0.4 host 15.0.0.5
access-list 103 permit udp host 16.0.0.4 host 13.0.0.5
ip cef
class-map match-all traffic-INTRA
match access-group 102
class-map match-all traffic-INTER
match access-group 103
class-map match-all traffic-dscp1
match ip dscp 1
! 24 = 0 0 0 1 1 0 0 0 ds3=ds4=1 priorita' 4
class-map match-any traffic-prec3
match ip dscp 24
match ip dscp 25
match ip dscp 26
match ip dscp 27
policy-map ADSL-out
class traffic-INTRA
bandwidth percent 8
class traffic-dscp1
set ip dscp 5
class traffic-prec3
set ip precedence 2
class traffic-INTER
bandwidth percent 8
class class-default
fair-queue
!
interface ATM0/0
no ip address
no atm ilmi-keepalive
!
interface ATM0/0.1 point-to-point
description COLLEGAMENTO
mtu 576
ip address 1.0.0.1 255.0.0.0
pvc 99/99
protocol ip 2.0.0.2 broadcast
vbr-nrt 142 142 1
encapsulation aal5snap
service-policy out ADSL-out
!
dial-peer voice 201 voip
destination-pattern 95434534
session target ipv4:192.168.30.10
ip qos dscp cs4 media <-- cs indica la precedenza (qui precedenza 4) ovvero dscp 100000, per i pacchetti voce
ip qos dscp cs5 signaling <-- qui applica ai pacchetti di segnalazione 101000
Figura 43 : ATM+NAT+DSCP+QoS
Traffic shaping per interfaccia
Con il comando "match input-interface" e' possibile classificare il traffico in base all'interfaccia di provenienza. Normalmente non e' possibile utilizzare le subinterfaces per il match. Segue un esempio di configurazione:
class-map match-any bob
match input-interface FastEthernet2/0
!
class-map match-any tom
match input-interface FastEthernet2/1
!
policy-map mypolicy
class bob
bandwidth 40000
queue-limit 20
class tom
bandwidth 80000
class class-default
fair-queue
!
interface ATM2/0.10 point-to-point
...
pvc 8/130
service-policy output mypolicy
vbr-nrt ...
!
Figura 44 : traffic-shaping e comando 'match input-interface'
Nel caso si voglia fare una policy per subinterfaces, ad esempio se abbiamo diversi utenti collegati a diverse subinterface ethernet 802.1q, e' possibile fare delle policy in input sulle subinterfaces, marchiando il traffico col DSCP, e poi applicare la policy in uscita in base al valore DSCP del traffico (vedi anche il paragrafo sul DSCP).
Gruppi di classi
E' possibile unire differenti class-map in gruppi. Disponibile dalla 12.1(5)T. Ecco un esempio:
class-map match-all udine
description traffico da Udine
match input-interface FastEthernet1/0
class-map match-all ftp1
description traffico totale
match class-map udine
match class-map catania
Figura 45 : comando 'class-map match-all'
Match del traffico VoIP IAX
In questo esempio intercettiamo tutto il traffico IAX in uscita in una interfaccia ATM. Si tratta di un trunk da due centrali telefoniche SIP basate su Asterisk:
interface ATM0/1/0.1 point-to-point
...
service-policy output VOIP
!
class-map match-all match-iax
match access-group 144
!
policy-map VOIP
class match-iax
...
!
access-list 144 permit udp any eq 4569 any eq 4569
Figura 46 : traffico VoIP con protocollo IAX
Alcuni comandi utili per il monitoraggio:
Tecno48#show atm pvc interface atm0/1/0
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
0/1/0.1 1 8 35 PVC SNAP VBR 640 640 1 UP
Tecno48#show policy-map VOIP
Policy Map VOIP
Class match-iax
Strict Priority
Bandwidth 200 (kbps) Burst 5000 (Bytes)
...
Tecno48#show queue atm0/1/0.1
Interface ATM0/1/0.1 VC 8/35
Queueing strategy: weighted fair <-- conseguenza del comando service-policy
Output queue: 0/512/70/0 (size/max total/threshold/drops)
Conversations 0/3/512 (active/max active/max total)
Reserved Conversations 1/1 (allocated/max allocated)
Available Bandwidth 24 kilobits/sec <--- il vbr e' a 640kbps-25%=480kbps
meno quelli allocati nella policy
Tecno48#sh policy-map interface atm0/1/0.1
ATM0/1/0.1: VC 8/35 -
Service-policy output: VOIP
Class-map: match-iax (match-all)
129131 packets, 16731372 bytes
30 second offered rate 25000 bps, drop rate 0 bps <--- una chiamata iax gsm
Match: access-group 144
Queueing
Strict Priority
Output Queue: Conversation 520
Bandwidth 200 (kbps) Burst 5000 (Bytes)
(pkts matched/bytes matched) 129131/16731372
(total drops/bytes drops) 0/0
...
Class-map: class-default (match-any)
59199 packets, 5202287 bytes
30 second offered rate 2000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 512
(total queued/total drops/no-buffer drops) 0/0/0
Figura 47 : comandi 'show policy-map', 'show queue', 'show atm'
CONFIGURAZIONE FINALE:
QOS IN INPUT/OUTPUT: FRAME-RELAY CON BANDA GARANTITA DI 1200/1300 KBPS. BLOCCO ANCHE DEL PEER-TO-PEER
In questo esempio si configura la QoS sia in input che in output. Si noti in particolare la configurazione della policy in input. La rete garantisce un CIR di 1,2megabit. Ma in ingresso non si puo' dare priorita' ad un tipo di traffico piuttosto che ad un'altro come in uscita. Siamo costretti ad allocare 500kbps per il traffico in RTP a priori. Ovvero, in assenza di traffico RTP la banda restera' allocata. Pertanto per il traffico restante saranno sempre disponibili al massimo 700kbps. Infatti l'unico modo per evitare la congestione in ingresso e' il non raggiungimento del CIR. Se ci fosse un traffico Internet in ingresso di 1megabit e improvvisamente ci fosse un traffico RTP tale da superare il CIR, la rete scarterebbe delle frame voip a monte del nostro router. In un collegamento punto-punto il problema non si pone, infatti faremmo uno shaping in output da entrambi e capi del collegamento. Qui si presume che vi sia un collegamento di banda Internet verso un ISP.
Nota: fino alla data di stesura di questa nota, Dicembre 2009, non sembra proposta da Cisco alcuna soluzione al problema delle connessioni peer-to-peer criptate con protocolli basati su RC4 quali MSE/PE o PHE. Il supporto a parte dei nuovi client peer-to-peer della criptazione che offusca il traffico limita la capacita' di NBAR di individuare questo traffico. Al momento in cui scrivo la capacita' di NBAR di bloccare il peer-to-peer sembra alquanto limitata e sembrano necessari apparati di altri produttori come il NetEnforcer della Alliot. La Alliot per prima nell'Agosto del 2006 ha annunciato la possibilita' per i propri prodotti di fare il detect della criptazione dei prodotti.
I peer-to-peer non si possono bloccare senza layer 7 inspection (content inspection) in quanto usano porte variabili. Inoltre, se non trovano altra via, fanno tunneling attraverso la porta 80 o usano i proxy.
!
class-map match-all data
match protocol http
match
protocol smtp
match protocol ftp
match protocol pop3
class-map match-any PEERTOPEER
match protocol kazaa2
match
protocol edonkey
match protocol gnutella
match protocol
bittorrent
match protocol fasttrack
class-map match-any SIP
match protocol sip
class-map match-any RTP
match protocol rtp audio
!
!
policy-map VOIP
class RTP
priority 500
class SIP
priority 125
class data
bandwidth 400
random-detect
random-detect exponential-weighting-constant 10
random-detect
precedence 0 20 40 10
class PEERTOPEER
drop
class class-default
fair-queue 512
queue-limit 70
policy-map INPUT_VOIP
class
RTP
police 500000 <-- in
input e' possibile solo il policing
class PEERTOPEER
drop
class class-default
police 700000
!
!
...
!
interface Serial0/0/0
no ip address
ip nat outside
ip virtual-reassembly
encapsulation frame-relay IETF
load-interval 30
no fair-queue
frame-relay traffic-shaping
frame-relay lmi-type cisco
!
interface Serial0/0/0.1 point-to-point
description ---- HDSL ---
ip address 192.119.211.62 255.255.255.252
ip verify unicast reverse-path
ip nat outside
ip
virtual-reassembly
frame-relay interface-dlci 50 IETF
class
VOIP2
crypto map SDM_CMAP_1
!
...
!
!
map-class
frame-relay VOIP2
frame-relay cir 1200000
frame-relay bc
12000
frame-relay be 0
frame-relay mincir 1200000
service-policy input INPUT_VOIP
service-policy output VOIP
Figura 48 : configurazione di esempio di QoS su frame-relay
Custom Queueing (legacy)
Il Custom Queue e' un meccanismo di gestione di quality of service basato su una gestione round robin di un insieme di code. E' possibile creare fino a 17 code d'uscita per interfaccia. La coda numero zero e' riservata dal sistema per la gestione di pacchetti ad alta priorita' quali ad esempio di segnalazione o keepalive.
Le code vengono servite a rotazione. Ogni coda pero' viene servita in modo differente. Le code a priorita' maggiore avranno un maggior numero di pacchetti mandati in uscita sull'interfaccia associata. Pertanto da ogni coda si preleverenno un numero differente di pacchetti. Questo consente di suddividere la banda disponibile tra le diverse code in modo predefinito. Piu' precisamente ad ogni coda sara' associata una percentuale della larghezza di banda disponibile. Da questo dato sara' possibile risalire all'esatto valore di banda, che dipende dalla banda garantita dalla rete associata alle interfacce del router.
La configurazione consiste nel creare le code, con il comando "queue-list" e poi associarle alle interfacce, con il comando "custom-queue-list":
interface serial 0
custom-queue-list 1
Figura 49 :custom queueing - esempio di configurazione
Consideriamo il caso in cui configuriamo tre code da associare rispettivamente al traffico telnet, al dns e al traffico rimanente. Configuriamo un prelievo di 1500 byte da una coda e 3000 byte dalle altre. Cio' determina come conseguenza una suddivisione della banda disponibile con percentuali del 20%, 30%, 30%
queue-list 1 protocol ip 2 tcp 23 |
pacchetti telnet alla coda 2 |
queue-list 1 protocol ip 3 udp 53 |
dns alla coda 3 |
queue-list 1 queue 2 byte-count 1500 |
1500 e' il valore di default cosi' questa riga non appare nello "show run". 20% traffico |
queue-list 1 queue 3 byte-count 3000 |
40% del traffico |
queue-list 1 default 4 |
tutti gli altri coda 2 |
queue-list 1 queue 4 byte-count 3000 |
Figura 50: comandi per la configurazione del custom queueing
Il motivo per cui con un byte-count di 1500 abbiamo un 20% di traffico riservato e' che il totale di byte-count dell'esempio e' 1500+3000+3000=7500 e il 20% di 7500 risulta 1500.
In questo secondo esempio vogliamo garantire banda al traffico identificato dall'access-list 111 lasciando il restante alla coda di default:
queue-list 1 protocol ip 5 list 111
queue-list 1 queue 3 byte-count 3000
queue-list 1 default 3
Figura 51: comandi per la configurazione del custom queueing
In assenza di congestione se una coda richiede piu' banda di quella assegnata potra' disporne. Questa e' una conseguenza dell'algoritmo round-robin che salta le code vuote.
Potete notare che non e' possibile applicare il custom-queuing in alcuni tipi d'interfacce. Ad esempio se abbiamo un collegamento ADSL con ATM e proviamo ad applicare custom-queuing in ATM o dialer (se presente) potrebbe non essere possibile.
Con il comando "show interfaces" e' possibile vedere la gestione del queueing sulle interfacce:
FastEthernet0/1 is up, line protocol is up
Hardware is Gt96k FE, address is 0013.c4a4.4fe5 (bia 0013.c4a4.4fe5)
Internet address is 192.168.15.110/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:07:04
Input queue: 5/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: custom-list 1
Output queues: (queue #: size/max/drops)
0: 0/20/0 1: 0/20/0 2: 0/20/0 3: 0/20/0 4: 0/20/0
5: 0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0
10: 0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0
15: 0/20/0 16: 0/20/0
1 minute input rate 305000 bits/sec, 99 packets/sec
1 minute output rate 793000 bits/sec, 108 packets/sec
57504 packets input, 32415206 bytes
Received 21 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
56332 packets output, 48085601 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 output buffer failures, 0 output buffers swapped
Figura 52: custom queueing e comando 'show interfaces'
Con il comando "show queueing custom" e' possile vedere la configurazione dettagliata delle code:
ITESYS-1800#show queueing custom
Current custom queue configuration:
List Queue Args
1 3 default
1 5 protocol ip list
111
1 3 byte-count 3000
Figura 53: comando 'show queueing custom'
Approfondimenti La banda che viene associata ad una coda e' data dalla seguente formula: (BYTEsullaCODA/BYTEsututteleCODE) * BANDAdellINTERFACCIA - Se il "byte count" e' superato ma un pacchetto e' in trasmissione questo verra' inviato per intero. Pertanto, specialmente con configurazioni di "byte count" piccole in relazione alla dimensione dei pacchetti in transito, dipendenti dal tipo di servizio utilizzato, la suddivisione di banda potrebbe essere anche molto differente rispetto quella preventivata
- La "window size" del protocollo TCP puo' alterare la distribuzione della banda. Infatti la sorgente non invia nuovi pacchetti finche' non riceve un acknowledge. Pertanto se il "byte count" e' inferiore alla dimensione della finestra puo' accadere che, al secondo giro, si trovino in coda meno pacchetti di quelli che si potrebbero inviare, in quanto la sorgente non ne ha inviati di nuovi non avendo ancora ricevuto l'acknowledge. Il byte-count di default e' 1500byte, che e' un buon compromesso. Appendice: ATMIl PCR (Pesk Cell Rate) e' la massima quantita' di celle che si possono trasmettere. Una cella ATM e' 53 byte (424 bit).
L'SCR (Sustained Cell Rate) indica il massimo valore medio al quale si possono inviare le celle. L'SCR e' minore del PCR MBS (Maximum Burst Size) e' il massimo numero di celle che possono essere inviate al PCR. Quando si raggiunge il MBS il traffico scende al di sotto dell'SCR finche' il tasso medio di invio delle celle raggiunge l'SCR. Sostanzialmente alla velocita' PCR si possono mandare al piu' MBS celle.
Troubleshooting
In alcune versioni di IOS non si puo' applicare direttamente una policy in una subinterface. Ve ne accorgete perche' quando ci provate vi appare il messaggio di errore: "CBWFQ : Not supported on subinterfaces". In tali casi dovete usare una policy parent, come in figura:
!
class-map match-any SIP
description --- match con la segnalazione ---
match access-group name SIP-LIST
class-map match-any RTP
description --- match con il traffico voce RTP --
match access-group 151
!
!
policy-map VOIP
description --- questa va bene se non si usa il nat ---
class SIP
priority 64
class RTP
priority 512
!
policy-map parent
class class-default
shape average 1400000
service-policy VOIP
!
...
!
map-class frame-relay VOIP2
...
service-policy output parent
...
Figura 54: errore 'CBWFQ : Not supported on subinterfaces'
2. Come verificare la velocita' del proprio ADSL
cisco#show dsl
interface atm 0
ATM0
Alcatel 20190 chipset information
ATU-R (DS) ATU-C (US)
Modem Status: Showtime (DMTDSL_SHOWTIME)
DSL Mode: ITU G.992.1 (G.DMT) Annex A
ITU STD NUM: 0x01 0x1
Vendor ID: 'STMI' 'GSPN'
Vendor Specific: 0x0000 0x0008
Vendor Country: 0x0F 0xFF
Chip ID: C196 (0)
DFE BOM: DFE3.0 Annex A (1)
Capacity Used: 45% 100%
Noise Margin: 27.0 dB 7.0 dB
Output Power: 18.5 dBm 12.0 dBm
Attenuation: 25.0 dB 15.0 dB
Defect Status: None None
Last Fail Code: None
Watchdog Counter: 0x8A
Watchdog Resets: 0
Selftest Result: 0x00
Subfunction: 0x00
Interrupts: 20646 (0 spurious)
PHY Access Err: 0
Activations: 4
LED Status: ON
LED On Time: 100
LED Off Time: 100
Init FW: init_AMR-3.0.014_no_bist.bin
Operation FW: AMR-3.0.014.bin
FW Source: embedded
FW Version: 3.0.14
Interleave Fast Interleave
Fast
Speed (kbps): 4096
0 832
0 <--- ecco la
configurazione del DSLAM
Cells:
612278308 0
355083463 0
Reed-Solomon EC: 24
0 2749
0
CRC Errors:
0 0
22 0
Header Errors: 0
0 10
0
Total BER: 0E-0 0E-0
Leakage Average BER: 0E-0 0E-0
ATU-R (DS) ATU-C (US)
Bitswap: enabled enabled
Bitswap success: 0 0
Bitswap failure: 0 0
LOM Monitoring : Disabled
...snip...
DSL: Training log buffer capability is not enabled
Figura 55: comando 'show queueing custom'
router# show controller atm
...snip...
VC QoS Summary
--------------
Active
Configured
Scheduled
Connections
VCD VPI VCI COS PCR SCR/MCR
COS PCR SCR/MCR
--- -------- ----- --- ------
---- --- --------
1 8 35 UBR
0 n/a
UBR 832 n/a
...snip...
Figura 56: comando 'show queueing custom'
Copyright 2005-2010 Gianrico Fichera
Nessuna parte di questa pubblicazione puo'
essere riprodotta o trasmessa, in qualsiasi forma o con qualsiasi mezzo,
elettronico, meccanico, fotocopie, registrazione, senza il consenso
dell'autore.Il
materiale di questa pagina non e’ sponsorizzato o
sottoscritto da Cisco Systems, Inc. Ciscoâ
e’ un trademark di Cisco Systems, Inc. negli Stati Uniti e
in altri stati. L’autore di questa pagina non si assume
nessuna responsabilita’ e non da nessuna garanzia
riguardante l’accuratezza e la completezza delle
informazioni presenti nonche’ da conseguenze sull’uso
delle informazioni presenti in questa pagina.
This
material is not sponsored by, endorsed by, or affiliated with
Cisco Systems, Inc., Cisco, Cisco Systems, and the Cisco Systems
logo are trademarks or registered trade marks of Cisco Systems,
Inc. or its affiliates. All other trademarks are trademarks of
their respective owners.
Il
sito web ufficiale della Cisco e’
http://www.cisco.com.
Nel caso si volesse utilizzare il contenuto di questa pagina
nella forma in cui e’ presentato rivolgersi all’autore
scrivendo a gianrico.fichera itesys.it.