This is an email posted to the LARTC mailing-list. It's an example posted by Nikolai Vladychevski who is using the prio qdisc to manage his Internet link.
The following is my setup for a LAN that is masqueraded on a 56K modem link:
Used script (download)
tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: prio tc qdisc add dev eth0 parent 1:1 handle 2: tbf limit 1600 burst 2600 rate 28800 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dst 192.168.1.2 classid 1:1 tc filter add dev eth0 parent 1:0 protocol ip prio 7 u32 match ip dst 192.168.1.4 classid 1:1 iptables -A PREROUTING -i eth0 -s 192.168.1.2 -t mangle -j MARK --set-mark 2 iptables -A PREROUTING -i eth0 -s 192.168.1.4 -t mangle -j MARK --set-mark 4 tc qdisc del dev ppp0 root tc qdisc add dev ppp0 root handle 2: prio tc qdisc add dev ppp0 parent 2:1 handle 3: tbf limit 1600 burst 2600 rate 28800 tc filter add dev ppp0 protocol ip parent 2:0 prio 1 handle 2 fw classid 2:1 tc filter add dev ppp0 protocol ip parent 2:0 prio 7 handle 4 fw classid 2:1This script creates a virtual channel on eth0 that somewhat equal to 56K modem (well, I have to tune the TBF , did not yet finished that part) , so when prio dequeues the packets TBF just drops those that are overloading the bandwidth.....
The ip 192.168.1.4 has the highest priority (band 0) , the 192.168.1.2 the lowest (band 2). I tested this with FTP and Web. Since it's a strict priority scheduler, if both machines make the download over ftp, the downloads for 192.168.1.2 just stop after some time and 192.168.1.4 keeps downloading at full. When you stop downloading on 192.168.1.4 and the connection isn't timed out by ftp client on the machine .2, it returns to the normal download rate.
The only thing left to do is tune the TBF correctly to be equal to the bandwidth of the outgoing link ...
Regards
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/