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
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
3
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)
4
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) 5
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
6
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)
7
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)
8
9. Verifica dell'installazione
• interroghiamo il sistema chiedendo che queuing
discipline sta usando:
• # tc qdisc show dev eth0
qdisc tbf 8008: rate 220000bit burst 1539b
lat 48.8ms
9
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
10
11. Rimettiamo tutto a posto
• # tc qdisc del dev eth0 root
• Rimuoviamo la disciplina di coda “root” dal
dispositivo eth0
11
12. Limitazione della banda verso uno specifico host
• Dobbiamo classificare il traffico: root
– Usiamo una qdisc di tipo PRIO
che consente di stabilire tre PRIO 1:
classi
– Ad una classe associamo un
TBF per il traffic shaping
– Mettiamo un filtro che dirotta in 1:1 1:2 1:3
quella classe tutto il traffico
diretto ad un certo nodo
TBF 20:
12
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
13
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
14
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
15
16. Verifica dell'installazione
• interroghiamo il sistema chiedendo che queuing discipline
sta usando e che filtri ha:
• # tc qdisc show dev eth0
qdisc prio 1: bands 3 priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
qdisc tbf 800c: parent 1:2 rate 220000bit burst 1539b lat 48.8ms
• # tc filter show dev eth0
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800
bkt 0 flowid 1:2 match 9bb90179/ffffffff at 16
filter parent 1: protocol ip pref 2 u32
filter parent 1: protocol ip pref 2 u32 fh 801: ht divisor 1
filter 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
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 2
scp node1:prova.data .
– durante il download viene mostrata la banda utilizzata
• Copiamo il file dalla macchina node1 e node3.
Da node 3
scp node1:prova.data .
– durante il download viene mostrata la banda utilizzata
• Le bande mostrate durante la copia sono differenti 17
18. Esercizio
LAN
Iinternet
Banda differente per Nodo3 e Node2 per accedere a Internet
18
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
19
