[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: htb traffic control misfunction



Alohá!

LeVA wrote:

------------###------------
# internet
iptables -t mangle -A POSTROUTING -d ! 192.168.0.0/24 -j MARK --set-mark 1
# localnet
iptables -t mangle -A POSTROUTING -d 192.168.0.0/24 -j MARK --set-mark 2

tc qdisc add dev eth0 root handle 1:0 htb default 1

tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 128kbit

# mark 1, this is internet
tc filter add dev eth0 parent 1:0 protocol ip prio 0 handle 1 fw classid 1:10
# mark 2, this is localnet
tc filter add dev eth0 parent 1:0 protocol ip prio 0 handle 2 fw classid 1:1

------------###------------


With this configuration, my upload speed is 128kbit/s, no matter what is the destination. It seems, that the filter for handle 2 is getting ignored, and I get 128kbit/s upload speed on my localnet too.

Are the required kernel modules loaded or compiled in? The MARK-target for iptables as well as all the QoS-modules (out of which so far You don't seem to be using any but sch_prio.o) are separate modules that either need to be included in modules.conf, modprobed by the script itself or even statically compiled in the kernel (as I have done since I'm trying to cope without Module support in my Kernels).

Try running the scripts "undetached" and manually from Your console and see what the output is (no news is good news).

The bandwidth on the other hand is regulated by tc if I'm guessing correctly, thus giving You a limited upload. My guess is that an unMARKed packet simply traverses the classes and ends up in the leaf at the end being the 128KBit one. Intuitively I'd create both classes (100MBit and 128KBit) as leaf classes of another 1:0 _class_ (*not* as classes inside the qdisc itself). Have another look at my example setup. It's been quite a while since I created it so I don't know it all anymore, but most things are there for a reason ;-)

Another thing: IIRC tc filter handles _flowids_ not _classids_. The manpage of tc sure knows more about the syntax than me :-)

And finally: MARKing in POSTROUTING is probably not correct for packets sourced from the machine itself since AFAIK tc works on the FILTER chain in the OUTPUT table and never gets to see anything MARKed if You MARK packets in the POSTROUTING table that is traversed _after_ OUTPUT.

Also, if You use the box as a router You want to MARK the packets in PREROUTING, as the MANGLE table that uses the MARKs is traversed after it. Same here - if You MARK in POSTROUTING that is traversed _after_ the MANGLE table, Your tc will never get to see any MARKed packets (for table traversal see http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TRAVERSINGOFTABLES)

regards

Martin



Reply to: