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