Newsgroup: it.comp.os.linux.sys
Titolo: Fedora e Traffic Shaping

Buongiorno a tutti.
Sto provando a fare qualche esperimento con lo shaping del traffico in
uscita, ma "ovviamente" c'è qualcosa che mi sfugge... :-)
Per iniziare a vedere come funziona ho deciso di limitare la banda per
la porta 80 a 32Kbit, di dare un taglietto a 128Kbit al backup e di
dare un "boost" al traffico VoIP, e per farlo ho buttato giù una cosa
del genere:
_ _ _ _ _ _ _C_U_T_ _H_E_R_E_ _ _ _ _ _ _ _
#!/bin/bash
DEVICE="dev eth1"
SetClass() {
    echo "Class $1 -> htb/$2kbit"
    tc class add $DEVICE \
	parent 1: \
	classid $1 \
	htb \
	rate $2kbit
}
SetFilter() {
    echo " - $DEVICE/$1:$3 -> $4 at $5kbit"
    tc filter add $DEVICE \
	parent 1: \
	protocol $1 \
	prio $2 \
	u32 match ip dport $3 0xffff \
	flowid $4 \
	police \
	rate $5kbit \
	burst 10Kb \
	mpu 0 \
	action drop/continue
}
tc qdisc del $DEVICE root
tc qdisc add $DEVICE root handle 1: htb
#          CLASSID  MAXRATE
#          -------  -------
SetClass      1:1        32					# HTTP TEST
SetClass      1:10      384					# VoIP
SetClass      1:20      128					# TSM
#          PROTOCOL  PRIORITY  D-PORT  FLOWID  MAXRATE
#          --------  --------  ------  ------  -------
SetFilter        ip         1      80    1:1        32		# HTTP TEST
SetFilter        ip         1    5060    1:10      384		# VoIP
SetFilter        ip         3    1500    1:20      128		# TSM
_ _ _ _ _ _ _C_U_T_ _H_E_R_E_ _ _ _ _ _ _ _
Come risultato ho ottenuto... una "beata fava", come diceva il mio
vecchio professore di matematica. Ecco l'output di tc show:
_ _ _ _ _ _ _C_U_T_ _H_E_R_E_ _ _ _ _ _ _ _
qdisc htb 1: root r2q 10 default 0 direct_packets_stat 7856
 Sent 1551598 bytes 8188 pkt (dropped 17, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
class htb 1:10 root prio 0 rate 384000bit ceil 384000bit burst 1599b
cburst 1599b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 0 borrowed: 0 giants: 0
 tokens: 32551 ctokens: 32551
class htb 1:1 root prio 0 rate 32000bit ceil 32000bit burst 1600b
cburst 1600b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 0 borrowed: 0 giants: 0
 tokens: 390625 ctokens: 390625
class htb 1:20 root prio 0 rate 128000bit ceil 128000bit burst 1599b
cburst 1599b
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 0 borrowed: 0 giants: 0
 tokens: 97656 ctokens: 97656
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:1  (rule hit 7829 success 696)
  match 00000050/0000ffff at 20 (success 696 )
 police 0x68 rate 32000bit burst 10Kb mtu 2Kb action drop/continue
overhead 0b
ref 1 bind 1
 Sent 195937 bytes 696 pkts (dropped 0, overlimits 17)
filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht
800 bkt 0 flowid 1:10  (rule hit 7812 success 26)
  match 000013c4/0000ffff at 20 (success 26 )
 police 0x69 rate 384000bit burst 10Kb mtu 2Kb action drop/continue
overhead 0b
ref 1 bind 1
 Sent 15122 bytes 26 pkts (dropped 0, overlimits 0)
filter parent 1: protocol ip pref 3 u32
filter parent 1: protocol ip pref 3 u32 fh 801: ht divisor 1
filter parent 1: protocol ip pref 3 u32 fh 801::800 order 2048 key ht
801 bkt 0 flowid 1:20  (rule hit 7812 success 0)
  match 000005dc/0000ffff at 20 (success 0 )
 police 0x6a rate 128000bit burst 10Kb mtu 2Kb action drop/continue
overhead 0b
ref 1 bind 1
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
_ _ _ _ _ _ _C_U_T_ _H_E_R_E_ _ _ _ _ _ _ _
Ovviamente la connessione di test fatta da un host esterno sulla 80 va
full speed... :-(
Dove sbaglio ?
Perché sul filter i pacchetti ci sono ma sulla class no ?!?
Ho la *netta* sensazione che ne manchi un pezzo... HELP !

 Ho la *netta* sensazione che ne manchi un pezzo... HELP !
Beh, cosi' a naso, se hai fatto SOLO quello che ci hai mandato, manca
semplicemente la parte in cui istruisci il sistema a mandare i dati a tc...
E questo lo fai con iptables!
In ufficio, per il traffic-shaper che ho installato, dopo aver definito le
classi con tc, le ordino cosi':
/sbin/iptables -t mangle -A POSTROUTING -p tcp --sport <port> -d <server>
-j MARK --set-mark 5 -m comment --comment "risposta"
/sbin/iptables -t mangle -A PREROUTING -p tcp --dport <port> -d <server>
-j MARK --set-mark 5 -m comment --comment "risposta"
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Ho la *netta* sensazione che ne manchi un pezzo... HELP !
Beh, cosi' a naso, se hai fatto SOLO quello che ci hai mandato, manca
semplicemente la parte in cui istruisci il sistema a mandare i dati a tc...
E questo lo fai con iptables!
In ufficio, per il traffic-shaper che ho installato, dopo aver definito le
classi con tc, le ordino cosi':
/sbin/iptables -t mangle -A POSTROUTING -p tcp --sport <port> -d <server>
-j MARK --set-mark 5 -m comment --comment "domanda"


 E questo lo fai con iptables!
Potete evitare i filter e i MARK e usare direttamente il
target CLASSIFY di netfilter.

 E questo lo fai con iptables!
...allora mi sfugge davvero qualcosa.
Io avevo capito che l'utilizzo di fwmark fosse solo *una* delle
opzioni, o almeno l'ho dedotto da 
lartc.org
, dove dice:
You can mark packets with either ipchains or iptables and have that
mark survive routing across interfaces. This is really useful to for
example only shape traffic on eth1 that came in on eth0. Syntax:
# tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw
flowid 1:1
Note that this is not a u32 match!
You can place a mark like this:
# iptables -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 6
The number 6 is arbitrary.
If you don't want to understand the full tc filter syntax, just use
iptables, and only learn to select on fwmark.
Ok, potrei marcare i pacchetti, ma quando nel filter gli dico:
u32 match ip dport $3 0xffff
non dovrebbe essere sufficiente ?
Ad esempio, nel filter della porta 80 c'è:
(rule hit 7829 success 696)
quindi da li passano, ma nella class relativa trovo
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
quindi le due cose non sono collegate...
Mi sembra sempre che ne manchi un pezzo...

...e come volevasi dimostrare, era una tremenda STR... dovevo
monitorare la SOURCE port, e non la destination! :-)
Ora funziona. Se a qualcuno dovesse servire (è molto semplice, e si
può adattare) lo posto qui:
_ _ _ _ _ _ _C_U_T_ _H_E_R_E_ _ _ _ _ _ _
#!/bin/bash
DEVICE="eth1"
SetClass() {
    echo "Class $1 -> htb $2 Priority $3"
    tc class add dev $DEVICE parent 1: classid $1 htb rate $2 ceil $2
prio $3
}
SetFilter() {
    echo " - Filter $DEVICE/$1:$2 -> $3"
    tc filter add dev $DEVICE parent 1: protocol $1 u32 match ip sport
$2 0xffff flowid $3
}
tc qdisc del dev $DEVICE root
tc qdisc add dev $DEVICE root handle 1: htb default 1
# Default
SetClass 1:1 100Mbit 1
# VoIP
SetClass 1:11 384Kbit 1
SetFilter ip 5060 1:11
# Web
SetClass 1:12 256Kbit 1
SetFilter ip 80 1:12
# Backup
SetClass 1:13 256Kbit 1
SetFilter ip 1500 1:13
_ _ _ _ _ _ _C_U_T_ _H_E_R_E_ _ _ _ _ _ _
Buon divertimento...