1
TRAFFIC SHAPINGSU SISTEMI LINUX
2
Due note sul traffic shaping
• Il traffic shaping riguarda la gestione dei flussi di traffico in un sistema
• Usi tipici:
– Riduzione della banda passante per alcuni tipi di traffico
– Prioritizzazione del traffico (e.g., un ISP ha utenti “gold” e “silver”)
• Noi presentiamo due esempi molto semplici
– Limitazione della banda complessiva in output
– Limitazione della banda verso uno specifico host
• Ci si concentra sul caso di un sistema linux
– Uso dei tool forniti nella suite iproute 2
3
Funzioni avanzate di gestione del traffico
• Idea di base:
– I datagrammi IP vengono accodati prma di essere spediti
– La getione della coda dei datagrammi è gestita da una queuing discipline
– Si interviene sulla queuing discipline per fare traffic shaping
• Nel kernel di linux ho tante possibili queuing discipline
4
Scenario di riferimento:
• Realizzara la rete rappresentata in figura
USATE: linux-new!
• 3 nodi su una stessa sottorete
• Installare I moduli del kernel per il traffic shaping– I moduli si trovano nella directory:
/lib/modules/<versione>/...
– Sono file con estensione .ko (kernel object)
– Si installano con il comando insmod (modprobe ha dei problemi)
5
Installare I moduli necessari
• Installazione dei moduli:– Scheduler Token Bucket Filter (TBF):
insmod /lib/modules/2.6.30/kernel/net/sched/sch_tbf.ko
– Scheduler Priority (PRIO):insmod /lib/modules/2.6.30/kernel/net/sched/sch_prio.ko
– Classificatore di traffico u32:insmod /lib/modules/2.6.30/kernel/net/sched/cls_u32.ko
insmod /lib/modules/2.6.30/kernel/net/sched/em_u32.ko
– Verifica dell'installazione:lsmod
• Senza questi moduli I tentativi di usare il traffic shaping terminano con messaggi di errore di tipo “file not found”
• I moduli devono essere riferiti alla stessa versione del kernel UML che si usa! (USATE: linux-new)
6
Limitazione della banda complessiva
• # tc qdisc add dev eth0 root tbf rate \ 220kbit latency 50ms burst 1540
• Spiegazione:
– tc: comando per interagire con il controllo del traffico
– qdisc: mi interessa variare le discipline di coda
– add: aggiungo un disciplina di coda
– dev eth0: lavoro sulla prima interfaccia di rete
– root: la disciplina di coda è la prima disciplina che usiamo (posso creare una gerarchia ad albero di discipline diverse e concatenate)
– tbf: token bucket filter, disciplina per limitare la banda
– seguono parametri della disciplina
7
Il token bucket filter
• la disciplina modella il traffico come un secchio (bucket) di monetine (token)
– il secchio si riempie a ritmo costante
– Ogni volta che devo spedire dei dati consumo monetine
– Se non ho abbastanza monetine nel secchio aspetto che si riempia (overlimit)
8
Il token bucket filter
• Il TBF manda dati a ritmo costante. E' abbastanza preciso e CPU friendly→ la presenza di virtualizzazione tuttavia ne altera le prestazioni in modo sensibile
• Parametri:
– rate: il ritmo a cui riempio il secchio
– burst: la dimensione del secchio (serve per compensare il fatto che il flusso di monetine e l'invio dei dati sono discreti nel tempo)
9
Verifica dell'installazione
• interroghiamo il sistema chiedendo che queuing discipline sta usando:
• # tc qdisc show dev eth0qdisc tbf 8008: rate 220000bit burst 1539b lat 48.8ms
10
Verificare il funzionamento del traffic shaper
• Scenario:
– node1 macchina su cui abbiamo configurato il traffic shaper
– node2 una macchina che usiamo per il test
• Creiamo un file sulla macchina node1:
– dd if=/dev/zero of=prova.data bs=1024 count=10000
crea un file di circa 10 M pieno di byte nulli
• Copiamo il file dalla macchina node2
– dalla macchina node2 lanciamo:scp node1:prova.data .
– durante il download viene mostrata la banda utilizzata
11
Rimettiamo tutto a posto
• # tc qdisc del dev eth0 root
• Rimuoviamo la disciplina di coda “root” dal dispositivo eth0
12
Limitazione della banda verso uno specifico host
• Dobbiamo classificare il traffico:
– Usiamo una qdisc di tipo PRIO che consente di stabilire tre classi
– Ad una classe associamo un TBF per il traffic shaping
– Mettiamo un filtro che dirotta in quella classe tutto il traffico diretto ad un certo nodo
root
1:
1:1 1:2 1:3
PRIO
TBF 20:
13
Limitazione della banda verso un host
• # tc qdisc add dev eth0 root handle 1: prio \ priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
• # tc qdisc add dev eth0 parent 1:2 tbf rate \ 220kbit latency 50ms burst 1540
• # tc filter add dev eth0 protocol ip parent \ 1:0 prio 1 u32 match ip dst 192.168.1.2/32 \ flowid 1:2
• # tc filter add dev eth0 protocol ip parent \ 1:0 prio 2 u32 match ip dst 0.0.0.0/0 \ flowid 1:1
14
Cosa è successo?
• La prima riga definisce la root qdisc come “prio”
– priomap indica come classificare il traffico in funzione dei bit “TOS” del datagramma IP.
– Alla classe :2 dello scheduler “prio” associamo il traffic shaper
– Mettiamo un primo filtro ad alta priorità (prio 1) che intercetta il traffico diretto verso 192.168.1.2 (ip dst 192.168.1.2/32) e lo mette nelle classe :2 (flowid 1:2)
– Mettiamo un ultimo filtro a bassa priorità che fa il matching del resto e lo mette nella classe :1
15
Principali parametri di matching
• Dopo aver indicato “u32” (match su una qualsiasi parte del pacchetto) possiamo specificare il campo
• In base all'indirizzo ip sorgente/destinazione– match ip src 1.2.3.0/24
– match ip dst 1.2.3.0/24
• In base alla porta sorgente/destinazione– match ip sport 80 0xffff
– match ip dport 80 0xffff
• In base al protocollo (tcp, udp, icmp, gre, ipsec)Facendo riferimento ai numeri presenti in /etc/protocols. Per esempio icmp è 1:
– match ip protocol 1 0xff
16
Verifica dell'installazione
• interroghiamo il sistema chiedendo che queuing discipline sta usando e che filtri ha:
• # tc qdisc show dev eth0qdisc prio 1: bands 3 priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1qdisc tbf 800c: parent 1:2 rate 220000bit burst 1539b lat 48.8ms
• # tc filter show dev eth0filter parent 1: protocol ip pref 1 u32filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2 match 9bb90179/ffffffff at 16filter parent 1: protocol ip pref 2 u32filter parent 1: protocol ip pref 2 u32 fh 801: ht divisor 1filter parent 1: protocol ip pref 2 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:1 match 00000000/00000000 at 16
17
Verificare il funzionamento del traffic shaper
• Scenario:
– node1 macchina su cui abbiamo configurato il traffic shaper
– node2 e node3 macchine che usiamo per il test
• Creiamo il solito file sulla macchina LOCALE:
– dd if=/dev/zero of=prova.data bs=1024 count=10000
• Copiamo il file dalla macchina node1 e node2.
Da node 2scp node1:prova.data .
– durante il download viene mostrata la banda utilizzata
• Copiamo il file dalla macchina node1 e node3.
Da node 3scp node1:prova.data .
– durante il download viene mostrata la banda utilizzata
• Le bande mostrate durante la copia sono differenti
18
Esercizio
LAN
Iinternet
Banda differente per Nodo3 e Node2 per accedere a Internet
19
Approfondimento
• Per saperne di più su iproute 2 e traffic shaping:
– Linux Advanced Routing & Traffic Control http://lartc.org
– Howto online: http://lartc.org/howto/ (è anche possibile scaricarlo in formato pdf)
– man pages