Phill,
: _____________________________________________ 160kbps/96kbps _____
: |imq0(eth1, eth2) Linux router with NAT>ppp0|------------------------|ISP|
: --------------------------------------------- -----
: +|Roman| - 192.168.1.10 on eth1
: +|Phill| - 192.168.2.10 on eth2
: + ...
I don't understand what you are trying to convey with the notes "eth1/eth2"
and 160kbps/96kbps part of the diagram, but the rest makes sense to me.
I'm going to draw a picture of your traffic control structure to point out
where I think your problem lies.
root class
+ r/c 160kbit
r 80kbit | r 80kbit
c 160kbit +---------------+---------------+ c 160kbit
Roman | | Phill
+---------+---------+ +---------+---------+
| ftp other | | other ftp |
| | | |
r 1kbit r 79kbit r 79kbit r 1kbit
c 160kbit c 160kbit c 160kbit c 160kbit
Note that you have four leaf classes. Two classes, each with a rate of 79kbit
and two each with a rate of 1kbit (which HTB can't reasonably accomplish [1],
but your technique should work, anyway--keep reading).
Several items of note.
- HTB only performs shaping in the leaf classes. [2]
- HTB rate is essentially treated as a CIR, and HTB will not
check a parent class to see if a parent class is above its
rate. [2]
- The sum of the rates of your leaf classes is 160kbit. You have
committed all of your bandwidth, and left nothing for borrowing or
dynamic allocation.
Try this instead:
root class
+ r/c 160kbit
r 80kbit | r 80kbit
c 160kbit +---------------+---------------+ c 160kbit
Roman | | Phill
+---------+---------+ +---------+---------+
| ftp other | | other ftp |
| | | |
r 1kbit r 40kbit r 40kbit r 1kbit
c 160kbit c 160kbit c 160kbit c 160kbit
With this sort of configuration, the borrowing model of HTB should distribute
the leftover bandwidth in a way that seems fairer to you. You have now
guaranteed a total of 82kbit to your leaf classes and above that (sum of the
rates of the leaf classes), the leaf classes will try to borrow as much as
they can up to ceil.
: The point is, that I want to shape the speed of each client
: and I want to shape the speed of the services the client uses.
: I don't use iptables to mark the packets, because the use of IMQ,
: but I know that there is a patch for this.
I don't know what you mean in this paragraph.....
[ snipped textual description ]
: modprobe imq numdevs=1
: ip link set imq0 up
: $IPT -t mangle -A PREROUTING -i ppp0 -j IMQ
Do you need to use IMQ? It's not a bad thing to use IMQ, but if your router
is a separate machine, you can simply attach the "download" shaper to the
internal interface--the interface closest to Phill and Roman. [3]
[ snipped start of script ]
See notes above about the rate/ceil here.
: ... parent 1:0 protocol ip u32 match ip dst 192.168.1.10 flowid 1:110
: ... parent 1:110 protocol ip u32 match ip dst 192.168.1.10 flowid 1:1101
: ... parent 1:110 protocol ip u32 match ip dport 20 0xffff flowid 1:1102
: ... parent 1:110 protocol ip u32 match ip dport 21 0xffff flowid 1:1102
See note above about IMQ necessity. In particular your u32 classifier with
"ip dport 21" will never match. Do you perhaps mean "ip sport 21"? Still
probably not all that helpful. Your u32 classifier "ip dport 20" is correct,
but will only work for port mode connections. Check/search the LARTC archives
for a description of the problems involved with shaping FTP (port v. passive
mode data channel). [4]
Best of luck,
-Martin
[1] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#sharing
(see last paragraph, for mtu=1500, r2q=1, 12kbit is minimum rate)
[2] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#hsharing
[3] http://www.docum.org/stef.coene/qos/faq/cache/9.html
[4] http://www.google.com/search?q=site%3Amailman.ds9a.nl+ftp+shaping
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
