[LARTC] how to define a port range?
hi, i´am new in tcc (tcng). i try to define my qos for VoIP-Services. For this i wantto define a class for a port range 1 till 15000. how is the right way? this down works: class ($voip) if tcp_sport = 1 || tcp_sport = 1 ; are there any examples of real installations - maybe including VoIP, HTTP and P2P services? regards thorsten gehrig ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Transfer rate above the desired (tc+htb)
Hi folks. I started to play with tc+htb last week, and I must confess that this thing is really driving me nuts. All we want to do is control bw, with no borrowing. In order to get the feeling on this subject, I have setup the following test bed. ---A---B---C--- On B: eth0 connecting A and eth1 connecting C. The script. tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 50 tc class add dev eth0 parent 1: classid 1:1 htb rate 32kbit ceil 32kbit tc filter add dev eth0 protocol ip parent 1:0 prio 100 u32 match ip src 10.4.0.0/16 match ip dst 0.0.0.0/0 classid 1:1 If I try to transfer a 1M file from C to A: [EMAIL PROTECTED] tmp]# wget 192.168.0.23/1M --09:22:32-- http://192.168.0.23/1M = `1M.8' Connecting to 192.168.0.23:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,024,000 [text/plain] 100%[=] 1,024,000183.12K/sETA 00:00 09:22:38 (182.88 KB/s) - `1M' saved [1,024,000/1,024,000] Wasn't it supposed to be around the 32KB/s? If I play with the numbers (rate=ceil) I get the following results: 128k == 404.78 KB/s 64k == 337.9 KB/s 16k == 68.86 KB/s 8k == 31.12 KB/s 1k == 3.77 KB/s I even tried to set the rate to 1kbps in root, but also led to pretty much the same results. With no qdisc, the rate will go close to 1000 KB/s B machine: 2.6.11-1.1369_FC4 iproute-2.6.11-1 TC HTB version 3.3 I have no clue on what I am doing wrong. Could anyone browse the above script and give me hint? Thanks in advance, AL ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Transfer rate above the desired (tc+htb)
Alvaro Motta wrote: Hi folks. I started to play with tc+htb last week, and I must confess that this thing is really driving me nuts. All we want to do is control bw, with no borrowing. In order to get the feeling on this subject, I have setup the following test bed. ---A---B---C--- On B: eth0 connecting A and eth1 connecting C. The script. tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 50 tc class add dev eth0 parent 1: classid 1:1 htb rate 32kbit ceil 32kbit tc filter add dev eth0 protocol ip parent 1:0 prio 100 u32 match ip src 10.4.0.0/16 match ip dst 0.0.0.0/0 classid 1:1 Should be src 192.168.0.0/24. Andy. If I try to transfer a 1M file from C to A: [EMAIL PROTECTED] tmp]# wget 192.168.0.23/1M --09:22:32-- http://192.168.0.23/1M = `1M.8' Connecting to 192.168.0.23:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,024,000 [text/plain] 100%[=] 1,024,000183.12K/sETA 00:00 09:22:38 (182.88 KB/s) - `1M' saved [1,024,000/1,024,000] Wasn't it supposed to be around the 32KB/s? If I play with the numbers (rate=ceil) I get the following results: 128k == 404.78 KB/s 64k == 337.9 KB/s 16k == 68.86 KB/s 8k == 31.12 KB/s 1k == 3.77 KB/s I even tried to set the rate to 1kbps in root, but also led to pretty much the same results. With no qdisc, the rate will go close to 1000 KB/s B machine: 2.6.11-1.1369_FC4 iproute-2.6.11-1 TC HTB version 3.3 I have no clue on what I am doing wrong. Could anyone browse the above script and give me hint? Thanks in advance, AL ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TBF + burst
js si wrote: I am using tbf to do rate limitation. i set the rate, burst and latency parameters for tbf. but when i start passing data i notice that there is an initial burst and then the rate goes down to the configured level. is this because tbf starts with a full bucket? Well I suppose the burst starts full. Remember if you are looking at tc stats then they show enqueue not dequeue, so you would see the whole buffer filling, but the dequeue rate will be lower. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HELP PLEASE BITTORRENT SHAPING (HTB)
Edgar wrote: I've never used ipp2p/l7 connmark or tcng, but usually when using connmark I would expect to see --restore-mark somewhere. If the PC running bittorrent is linux+python a workaround would be to add another address to its eth and -bind bittorrent to that. I don't know if thats possible with other OS/bt software. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] script for limiting uploaddoes not work
Hello, I want only a very simple thing, but somehow I cannot manage to get it working. I would like to shape download and upload speeds of my DC++ client firmly to some speed, but I cannot make the upload part working. I use a linux router (asus wl500g, actually), and a NATed PC (adress 192.168.1.100) eth1 is my WAN interface, br0 is LAN, DC++ is active and running on ports(udp and tcp) 4111. This is my script (working) for download: iptables -t mangle -A FORWARD -p tcp --dport 4111 -j MARK --set-mark 1 tc qdisc add dev br0 root handle 1:0 htb default 0 tc class add dev br0 parent 1:0 classid 1:1 htb rate 1024kbit tc class add dev br0 parent 1:1 classid 1:11 htb rate 256kbit tc filter add dev br0 parent 1:0 protocol ip handle 1 fw flowid 1:11 I thought that upload would be very similar: iptables -t mangle -A FORWARD -p tcp --sport 4111 -j MARK --set-mark 2 tc qdisc add dev eth1 root handle 2:0 htb default 0 tc class add dev eth1 parent 2:0 classid 2:1 htb rate 1024kbit tc class add dev eth1 parent 2:1 classid 2:11 htb rate 256kbit tc filter add dev eth1 parent 2:0 protocol ip handle 2 fw flowid 2:11 but it does not work. tc part is actually ok, because if I type this: iptables -t mangle -A FORWARD -i br0 -j MARK --set-mark 2 or this: iptables -t mangle -D FORWARD -s 192.168.1.100 -j MARK --set-mark 2 upload goes to 64kbit, but do does everything else too - which is not exactly what I am trying to do:-). So the problem si something with marking and iptables - any ideas? (or even a completle different approach to the problem then marking packets?) Thanks for help in advance. Tomas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] limiting upload speeds does not work
Hello, I want only a very simple thing, but I have been unable to get it working so far. I would like to shape my DC++ traffic firmly to certain speeds. I am using an embedded linux router (asus wl500g), and a NATed PC (address 192.168.1.100). eth1 is a WAN interface and br0 is the LAN interface of the router.DC++ client is running on 4111 ports(tcp and udp) I actually managed to shape download wth this script: iptables -t mangle -A FORWARD -p tcp --dport 4111 -j MARK --set-mark 1 tc qdisc add dev br0 root handle 1:0 htb default 0 tc class add dev br0 parent 1:0 classid 1:1 htb rate 1024kbit tc class add dev br0 parent 1:1 classid 1:11 htb rate 256kbit tc filter add dev br0 parent 1:0 protocol ip handle 1 fw flowid 1:11 And I thought it would be similar with upload, but it is not, I tried this script: iptables -t mangle -A FORWARD -p tcp --sport 4111 -j MARK --set-mark 2 tc qdisc add dev eth1 root handle 2:0 htb default 0 tc class add dev eth1 parent 2:0 classid 2:1 htb rate 1024kbit tc class add dev eth1 parent 2:1 classid 2:11 htb rate 256kbit tc filter add dev eth1 parent 2:0 protocol ip handle 2 fw flowid 2:11 but it did not work. However, the problem seems to be in the way how I mark packets since when I type this: iptables -t mangle -A FORWARD -i br0 -j MARK --set-mark 2 or this: iptables -t mangle -A FORWARD -s 192.168.1.100 -j MARK --set-mark 2 upload immidiately goes to 64kbits or something, but so does everything else too - which is not exactly what I am trying to accomplish;-). Since I am running out of ideas, have you got any? Or even an completely different approach to the problem? Thanks in advance, Tomas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] sorry for sending this twice
My opera browser crashed and I somehow missed the mail was actually already sent, so I wrote it again. Sorry for two almost identical mails. Tomas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Transfer rate above the desired (tc+htb)
Hi Andy, thanks for your reply. I don't see why the src should be the culprit, since the AB segment is 10.4 network and the BC is 192.168. And IMHO 0.0.0.0/0 Also, after modifying the src, the traffic rate was the same as if no qdisc were attached to the interface. I even played with the interfaces and the only way to throttle the traffic, is assigning the qdisc to the eth0 and having the src and dst as in the script I've sent. AL On 7/20/05, Andy Furniss [EMAIL PROTECTED] wrote: Alvaro Motta wrote: Hi folks. I started to play with tc+htb last week, and I must confess that this thing is really driving me nuts. All we want to do is control bw, with no borrowing. In order to get the feeling on this subject, I have setup the following test bed. ---A---B---C--- On B: eth0 connecting A and eth1 connecting C. The script. tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 50 tc class add dev eth0 parent 1: classid 1:1 htb rate 32kbit ceil 32kbit tc filter add dev eth0 protocol ip parent 1:0 prio 100 u32 match ip src 10.4.0.0/16 match ip dst 0.0.0.0/0 classid 1:1 Should be src 192.168.0.0/24. Andy. If I try to transfer a 1M file from C to A: [EMAIL PROTECTED] tmp]# wget 192.168.0.23/1M --09:22:32-- http://192.168.0.23/1M = `1M.8' Connecting to 192.168.0.23:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,024,000 [text/plain] 100%[=] 1,024,000183.12K/sETA 00:00 09:22:38 (182.88 KB/s) - `1M' saved [1,024,000/1,024,000] Wasn't it supposed to be around the 32KB/s? If I play with the numbers (rate=ceil) I get the following results: 128k == 404.78 KB/s 64k == 337.9 KB/s 16k == 68.86 KB/s 8k == 31.12 KB/s 1k == 3.77 KB/s I even tried to set the rate to 1kbps in root, but also led to pretty much the same results. With no qdisc, the rate will go close to 1000 KB/s B machine: 2.6.11-1.1369_FC4 iproute-2.6.11-1 TC HTB version 3.3 I have no clue on what I am doing wrong. Could anyone browse the above script and give me hint? Thanks in advance, AL ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem with HTB and ceil
Quoting Andreas Klauer [EMAIL PROTECTED]: I might've misunderstood you here, but just in case: The HTB prio parameter affects borrowing priority, not packet priority. You mean priority after the guaranteed bitrates have been fullfilled. Which basically means that the proportions which you'd get if all classes had the same priority, will look much different. In other words, low priority classes will not get any bandwidth except their guaranteed rate, as long as a higher priority class is borrowing. More precisely, after the guaranteed bandwidhts have been assigned the excess bandwidth will be spread to the highest prio class first until the ceiling is reached and then any remainin will be assigne to the next highes prio class and the same procedure is repeated until the bandwidht is 0. Correct? If so, that is exactly what I am trying to achieve. Personally, I only use the HTB prio for unwanted traffic class (P2P), because I find that for normal traffic, the restriction is too harsh. This is why I recommend not using the HTB prio parameter at all in the beginning, and only start experimenting with it when you really need it. I think I really need it ;-) But I have observed something else, it looks like if I use two different IP A and B where I sent packets to, and mark those packets with the correct different marks, I can see how the prio works, one of the flows is almost drown by the other as expected from my prio config. So, it _might_ be a problem in the way how I tag the packets. If you remember I had the ACK class which should have prio 1, and I matched them with following rules: iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m tcp --tcp-flags SYN,RST,ACK ACK -m length --length :128 -j MARK --set-mark 200 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m tcp --tcp-flags ! SYN,RST,ACK ACK -m length --length :128 -j MARK --set-mark 200 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m length --length 0:48 -j MARK --set-mark 200 Is it possible that still some ACKs are not marked correctly? And if so, how would such a set of rules look like to catch all ACK packets? Thanks for your help! nik ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Transfer rate above the desired (tc+htb)
Alvaro Motta wrote: Hi Andy, thanks for your reply. I don't see why the src should be the culprit, since the AB segment is 10.4 network and the BC is 192.168. And IMHO 0.0.0.0/0 Also, after modifying the src, the traffic rate was the same as if no qdisc were attached to the interface. I even played with the interfaces and the only way to throttle the traffic, is assigning the qdisc to the eth0 and having the src and dst as in the script I've Hmm I am confused now :-) If you run wget on machine A with address 10.4.x.y and request a file from machine C address 192.168.0.23 then the source address of the packets passing egress eth0 on machine B should be 192.168.0.23 - unless there is some sort of NAT going on in machine B. FWIW you use default 50 on your htb rule but don't have a class 1:50 and your filter rule dst 0.0.0.0/0 matches any dst ipaddress and so is redundant. Maybe you should as a test limit all IP traffic on eth0 and see if that works - tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:1 htb rate 32kbit ceil 32kbit tc filter add dev eth0 protocol ip parent 1:0 prio 100 u32 match u32 0 0 classid 1:1 Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] limiting upload speeds does not work
Tomáš Hnyk wrote: Hello, I want only a very simple thing, but I have been unable to get it working so far. I would like to shape my DC++ traffic firmly to certain speeds. I am using an embedded linux router (asus wl500g), and a NATed PC (address 192.168.1.100). eth1 is a WAN interface and br0 is the LAN interface of the router.DC++ client is running on 4111 ports(tcp and udp) I actually managed to shape download wth this script: iptables -t mangle -A FORWARD -p tcp --dport 4111 -j MARK --set-mark 1 tc qdisc add dev br0 root handle 1:0 htb default 0 tc class add dev br0 parent 1:0 classid 1:1 htb rate 1024kbit tc class add dev br0 parent 1:1 classid 1:11 htb rate 256kbit tc filter add dev br0 parent 1:0 protocol ip handle 1 fw flowid 1:11 And I thought it would be similar with upload, but it is not, I tried this script: iptables -t mangle -A FORWARD -p tcp --sport 4111 -j MARK --set-mark 2 tc qdisc add dev eth1 root handle 2:0 htb default 0 tc class add dev eth1 parent 2:0 classid 2:1 htb rate 1024kbit tc class add dev eth1 parent 2:1 classid 2:11 htb rate 256kbit tc filter add dev eth1 parent 2:0 protocol ip handle 2 fw flowid 2:11 but it did not work. However, the problem seems to be in the way how I mark packets since when I type this: iptables -t mangle -A FORWARD -i br0 -j MARK --set-mark 2 or this: iptables -t mangle -A FORWARD -s 192.168.1.100 -j MARK --set-mark 2 upload immidiately goes to 64kbits or something, but so does everything else too - which is not exactly what I am trying to accomplish;-). Since I am running out of ideas, have you got any? Or even an completely different approach to the problem? Thanks in advance, Tomas Probably ports alone are not enough, I suppose DC will make outgoing connections so src port will be anything and dst port will be whatever the peer chose to run DC on. There are projects called ipp2p and l7 filter that are made to match P2P - I don't use them myself so can't say if they work well with DC. Another way would be to mark the traffic from 192.168.1.100 that you know is not from DC and then mark any unmarked packets as DC. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Transfer rate above the desired (tc+htb)
Alvaro Motta wrote: Hi folks. Hola. I started to play with tc+htb last week, and I must confess that this thing is really driving me nuts. If you started last week, you have a lng way to go :-) All we want to do is control bw, with no borrowing. In order to get the feeling on this subject, I have setup the following test bed. ---A---B---C--- On B: eth0 connecting A and eth1 connecting C. The script. tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 50 tc class add dev eth0 parent 1: classid 1:1 htb rate 32kbit ceil 32kbit tc filter add dev eth0 protocol ip parent 1:0 prio 100 u32 match ip src 10.4.0.0/16 match ip dst 0.0.0.0/0 classid 1:1 If I try to transfer a 1M file from C to A: [EMAIL PROTECTED] tmp]# wget 192.168.0.23/1M --09:22:32-- http://192.168.0.23/1M = `1M.8' Connecting to 192.168.0.23:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,024,000 [text/plain] 100%[=] 1,024,000183.12K/sETA 00:00 09:22:38 (182.88 KB/s) - `1M' saved [1,024,000/1,024,000] Wasn't it supposed to be around the 32KB/s? Around 32 kilobits/s. Besides this, the rate calculation includes not only the ip packet effective payload, but all the packet size, and I guess that wget's speed calculation only includes the payload. The tc manpage have a section on Units. If I play with the numbers (rate=ceil) I get the following results: 128k == 404.78 KB/s 64k == 337.9 KB/s 16k == 68.86 KB/s 8k == 31.12 KB/s 1k == 3.77 KB/s I even tried to set the rate to 1kbps in root, but also led to pretty much the same results. With no qdisc, the rate will go close to 1000 KB/s B machine: 2.6.11-1.1369_FC4 iproute-2.6.11-1 TC HTB version 3.3 I have no clue on what I am doing wrong. Could anyone browse the above script and give me hint? Thanks in advance, AL ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ppp uplink shaping problems
Staenker wrote: Hello, i played a few days with tc htb classes and classified my packets using iptables CLASSIFY target. here is what i did: #!/bin/bash int='ppp0' #making all things clear tc qdisc del dev $int root iptables -t mangle --flush iptables -t mangle --delete-chain if $1 then #defining classes tc qdisc add dev $int root handle 1: htb default 20 r2q 2 tc class add dev $int parent 1: classid 1:1 htb rate 22kbps tc class add dev $int parent 1:1 classid 1:10 htb rate 10kbps ceil 22kbps prio 0 tc class add dev $int parent 1:1 classid 1:20 htb rate 9kbps ceil 15kbps prio 1 tc class add dev $int parent 1:1 classid 1:30 htb rate 3kbps ceil 13kbps prio 2 tc qdisc add dev $int parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev $int parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev $int parent 1:30 handle 30: sfq perturb 10 iptables -t mangle -N TS_FWD iptables -t mangle -A FORWARD -j TS_FWD iptables -t mangle -A TS_FWD -o ppp0 -p ! icmp --match length --length 0:70 -j CLASSIFY --set-class 1:10 iptables -t mangle -A TS_FWD -o ppp0 -p ! icmp --match length --length 0:70 -j RETURN iptables -t mangle -A TS_FWD -i eth2 -o ppp0 -p tcp --source 192.168.0.2 --destination-port 80 -j CLASSIFY --set-class 1:20 iptables -t mangle -A TS_FWD -i eth2 -o ppp0 -p tcp --source 192.168.0.2 --destination-port 80 -j RETURN iptables -t mangle -A TS_FWD -i eth2 -o ppp0 -p tcp --source 192.168.0.2 --destination-port 443 -j CLASSIFY --set-class 1:20 iptables -t mangle -A TS_FWD -i eth2 -o ppp0 -p tcp --source 192.168.0.2 --destination-port 443 -j RETURN iptables -t mangle -A TS_FWD -i eth2 -o ppp0 -p tcp --source 192.168.0.2 --destination-port 554 -j CLASSIFY --set-class 1:10 iptables -t mangle -A TS_FWD -i eth2 -o ppp0 -p tcp --source 192.168.0.2 --destination-port 554 -j RETURN #if $2 #then #iptables -t mangle -A TS_FWD -i eth2 -o ppp0 --source 192.168.0.2 -j LOG #fi iptables -t mangle -A TS_FWD -i eth2 -o ppp0 --source 192.168.0.2 -j CLASSIFY --set-class 1:30 fi It works not really good. I tested it using my internal 100MBit network interface using multiple ftp connections and classified the packets based on their source-ip. That works fine with same classes. Immediately all things i expected took place. Also the prio option worked fine. If i was running 2 simultanious downloads, the one with the higher piority gets all borrowable downloadspeed and the one with the lower priority gets his ashured rate. But same classes didnt work with my 192kbit 2048kbit ppp link. Well ok, they are working, but not like i want them to work. The speed changes takes some seconds to take place. And the priority seems to be ignored. I have to say, that the i tested the ppp uplink using emule with many connections (500 - 800) and the higher priority upload was one active ftp connection. Whats my fault? I can't see what rule seperates ftp from the rest, so that could be it - check counters/classification with tc -s class ls dev ppp0 If ftp is going to the right class then it may be that emule network traffic consists of loads of small packets. If your ppp0 is adsl then the difference between the ip length that htb sees and the actual length used on the wire can be significant enough to make you go over limits and end up with a 2+ second queue in your modem. Check with ping and make icmp go to top priority class. It is possible to patch tc/kernel to allow for this. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] HTB and prio
Hi, this is a followup to Problem with HTB and ceil, the problem with the ceiling has been resolved, thanks to the memebers on this m/g. Now I have the problem that packets get into the correct classe with the correct marks but the prios are not respected. I have 4 different classes: 1. voip class / prio 0 / mark 100 / voip traffic 2. ACK class / prio 1 / mark 200 / ACK packets to keep downloads as fast as possible 3. SSH class / prio 3 / mark 300 / ssh/scp interactive traffic 4. http/client class / prio 3 / mark 400 / traffic from the internal net/web browsing traffic 5. bulk classe / prio 4 / mark 500 / bulk traffic like p2p stuff etc, also locally from the router All the minium settings are respected, same goes for ceiling. I would expect that after assuring that the guaranteed minimum bitrates have been assigned, that the excess bandwidth will first be given to the class with the highest prio until the ceiling has been reached, and if there is any bandwidth left, proceed with the class with the next lower prio. That doesnt happen, any excess b/w will be spread all across the classes/prios. Now here is the script: #!/bin/bash # # Shell-Skript fuer Quality of Service mit HTB # EXTIF=ppp0 INTIF=eth0 if [ $1 = start ]; then # Outgoing ## Root /sbin/tc qdisc add dev $EXTIF root handle 1:0 htb default 400 ## Hauptklasse /sbin/tc class add dev $EXTIF parent 1:0 classid 1:1 htb rate 380kbit ceil 380kbit /sbin/tc class add dev $EXTIF parent 1:1 classid 1:2 htb rate 380kbit ceil 380kbit ## voip class /sbin/tc class add dev $EXTIF parent 1:2 classid 1:100 htb rate 32kbit ceil 96kbit prio 0 ## non voip class /sbin/tc class add dev $EXTIF parent 1:2 classid 1:101 htb rate 248kbit ceil 380kbit ## ACK class /sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate 200kbit ceil 380kbit prio 1 ## VPN/SSH class /sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate 16kbit ceil 380kbit prio 3 ## http class /sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate 16kbit ceil 380kbit prio 3 ## bulk class /sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate 16kbit ceil 380kbit prio 4 ### # Marking ### # default marking *500 iptables -A POSTROUTING -t mangle -o $EXTIF -j MARK --set-mark 500 # voip *100 iptables -A POSTROUTING -t mangle -o $EXTIF -p udp --sport 5060:5061 -m length --length 0:45 -j MARK --set-mark 100 iptables -A POSTROUTING -t mangle -o $EXTIF -p udp -s 172.20.1.200 -j MARK --set-mark 100 # ACK+dns *200 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m tcp --tcp-flags SYN,RST,ACK ACK -j MARK --set-mark 200 iptables -A POSTROUTING -t mangle -o $EXTIF -p udp --sport 53 -j MARK --set-mark 200 iptables -A POSTROUTING -t mangle -o $EXTIF -p udp --dport 53 -j MARK --set-mark 200 # SSH *300 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp --dport 22 -j MARK --set-mark 300 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp --sport 22 -j MARK --set-mark 300 # http *400 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp --dport 80 -j MARK --set-mark 400 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -s 172.20.1.0/24 -j MARK --set-mark 400 # bulk *500 iptables -A POSTROUTING -t mangle -o $EXTIF -p icmp -j MARK --set-mark 500 tc filter add dev $EXTIF parent 1:0 prio 0 protocol ip handle 1 fw flowid 1:1 tc filter add dev $EXTIF parent 1:0 prio 0 protocol ip handle 2 fw flowid 1:2 tc filter add dev $EXTIF parent 1:0 prio 0 protocol ip handle 100 fw flowid 1:100 tc filter add dev $EXTIF parent 1:0 prio 0 protocol ip handle 101 fw flowid 1:101 tc filter add dev $EXTIF parent 1:0 prio 0 protocol ip handle 200 fw flowid 1:200 tc filter add dev $EXTIF parent 1:0 prio 0 protocol ip handle 300 fw flowid 1:300 tc filter add dev $EXTIF parent 1:0 prio 0 protocol ip handle 400 fw flowid 1:400 tc filter add dev $EXTIF parent 1:0 prio 0 protocol ip handle 500 fw flowid 1:500 ### # SFQ ### #tc qdisc add dev $EXTIF parent 1:2 handle 2: sfq perturb 10 tc qdisc add dev $EXTIF parent 1:100 handle 100: sfq perturb 10 #tc qdisc add dev $EXTIF parent 1:101 handle 101: sfq perturb 10 tc qdisc add dev $EXTIF parent 1:200 handle 200: sfq perturb 10 tc qdisc add dev $EXTIF parent 1:300 handle 300: sfq perturb 10 tc qdisc add dev $EXTIF parent 1:400 handle 400: sfq perturb 10 tc qdisc add dev $EXTIF parent 1:500 handle 500: sfq perturb 10 fi o root 1:0 | + 1:1 | + 1:2 /| || 1:101 | __+__ | | | | | | | | | | | | | | | voip ACKSSHhttp bulk pr 0 pr 1 pr 2 pr 3 pr 4 1:100 1:200 1:300 1:300 1:400 Does anyone have a clue what I am doing wrong? (1:1 is not needed, I know, I wanted to attach another
