| View previous topic :: View next topic |
| Author |
Message |
ddaas
Tux's lil' helper
Joined: 28 Feb 2005
Posts: 106
Location: Germany
|
 Posted: Thu Jul 21, 2005 12:26 pm Post subject: HTB as a child of another HTB - doesn't work |
 |
|
Hi,
I am new to HTB and in the learning process I want to simulate a slower link on my server to see how qdisc works.
I have a 100Mbit connection.
I want to simulate a 100K connection and to divide traffic between FTP and SMB. (like in HTB user guide).
The problem is that it doesnt work. I can transfer files with FTP of SAMBA at the wire speed. (Just like when there was no HTB and qdisc). What do I do wrong?
Here is my script:
| Code: |
#!/bin/bash
tc qdisc del dev eth0 root
iptables -F
iptables -F -t mangle
# qdisc for delay simulation
tc qdisc add dev eth0 root handle 100: htb
tc class add dev eth0 parent 100: classid 100:1 htb rate 100kbps
tc qdisc add dev eth0 parent 100:1 handle 1: htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50kbps ceil 100kbps prio 1
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 50kbps ceil 100kbps prio 2
tc qdisc add dev eth0 parent 1:10 handle 22: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 23: sfq perturb 10
|
I've tried with u32 and with fw filter
| Code: |
tc filter add dev eth0 parent 1: protocol ip u32 match ip sport 20 0xffff flowid 1:10
tc filter add dev eth0 parent 1: protocol ip u32 match ip sport 139 0xffff flowid 1:20
|
OR
| Code: |
iptables -A OUTPUT -o eth0 -t mangle -p tcp --sport 20 -j MARK --set-mark 22
tc filter add dev eth0 parent 1: protocol ip handle 22 fw classid 1:10
iptables -A OUTPUT -o eth0 -t mangle -p tcp --sport 139 -j MARK --set-mark 33
tc filter add dev eth0 parent 1: protocol ip handle 33 fw classid 1:20
|
_________________
Best regards,
ddaas |
|
| Back to top |
|
 |
bigfunkymo
Apprentice
Joined: 23 Jan 2004
Posts: 237
|
| Posted: Thu Jul 21, 2005 7:40 pm Post subject: |
|
|
transaferring in what direction? TO this box or FROM this box?
_________________
[No package... Grabbing a set.] |
|
| Back to top |
|
|
ddaas
Tux's lil' helper
Joined: 28 Feb 2005
Posts: 106
Location: Germany
|
| Posted: Thu Jul 21, 2005 8:55 pm Post subject: |
|
|
from the box (linux server) and instead tcp 139 is tcp 445. But no result...
_________________
Best regards,
ddaas |
|
| Back to top |
|
|
bigfunkymo
Apprentice
Joined: 23 Jan 2004
Posts: 237
|
| Posted: Thu Jul 21, 2005 9:05 pm Post subject: |
|
|
did you verify the packets are being marked by netfilter? Capture some packets using tcpdump to find out.
[edit]
I just noticed that you have no 'tc filter' lines that put your marked packets into their appropriate classes, nor do you have a default class.
go read the HTB manual... it's very informative
_________________
[No package... Grabbing a set.] |
|
| Back to top |
|
|
ddaas
Tux's lil' helper
Joined: 28 Feb 2005
Posts: 106
Location: Germany
|
| Posted: Fri Jul 22, 2005 7:34 am Post subject: |
|
|
| Quote: | | did you verify the packets are being marked by netfilter? Capture some packets using tcpdump to find out. |
Look what it says in the greatest tutorial of iptables (http://www.linuxsecurity.com/resource_files/firewalls/IPTables-Tutorial/iptables-tutorial.html ):
| Quote: | 6.5.5. MARK target
The MARK target is used to set Netfilter mark values that are associated with specific packets. This target is only valid in the mangle table, and will not work outside there. The MARK values may be used in conjunction with the advanced routing capabilities in Linux to send different packets through different routes and to tell them to use different queue disciplines (qdisc), etc. For more information on advanced routing, check out the Linux Advanced Routing and Traffic Control HOW-TO. Note that the mark value is not set within the actual package, but is an value that is associated within the kernel with the packet. In other words, you can not set a MARK for a packet and then expect the MARK still to be there on another host. If this is what you want, you will be better off with the TOS target which will mangle the TOS value in the IP header. |
I understand that I cant see if the packets are marked....not with a sniffer...
| Quote: | | I just noticed that you have no 'tc filter' lines that put your marked packets into their appropriate classes, nor do you have a default class. |
See my fist post under iptables command ! I've also tried with u32 filtered. No positive result...
This is the example from the htb user guid with minimal modifications....
_________________
Best regards,
ddaas |
|
| Back to top |
|
|
bigfunkymo
Apprentice
Joined: 23 Jan 2004
Posts: 237
|
| Posted: Fri Jul 22, 2005 2:35 pm Post subject: |
|
|
I have used tcpdump to verify my packets are getting their ToS fields set. *shrug* You have no 'tc filter' lines that classify traffic based on their marking--only source port.
Anywho, it was staring me right in the face, I don't know why I did not see this earlier. The overall problem with your TC setup is you have a HTB qdisc as the child of a class. I'm not sure what you're trying to accomplish by doing this, but I don't think that is how it is intended to be used. What are you trying to accomplish here?
I was thinking something like this would be more appropriate:
| Code: | # create the qdisc
tc qdisc add dev eth0 root handle 1: htb
# this class is the root of our class tree and limits everything to 100kbps
tc class add dev eth0 parent 1: classid 1:1 htb \
rate 100kbps
# this class is guaranteed 50kbps, limited to 100kbps, dequeued at prio 1
tc class add dev eth0 parent 1:1 classid 1:10 htb \
rate 50kbps \
ceil 100kbps \
prio 1
# this class is guaranteed 50kbps, limited to 100kbps, dequeued at prio 2 (will probably result in very high latency for this class)
tc class add dev eth0 parent 1:1 classid 1:20 htb \
rate 50kbps \
ceil 100kbps \
prio 2 |
and of course, use whatever filter lines you deem appropriate
_________________
[No package... Grabbing a set.] |
|
| Back to top |
|
|
ddaas
Tux's lil' helper
Joined: 28 Feb 2005
Posts: 106
Location: Germany
|
| Posted: Sat Jul 23, 2005 10:03 am Post subject: |
|
|
I don't set the tos in the header of IP. I mark the packet for the kernel. When you mark the packets with "-j MARK --set-mark value" the ip header is left untouched.(maybe I am wrong .... ).
This is the example from the HTB User guide - http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#prio
Is this example wrong?
| Quote: | | What are you trying to accomplish here? |
I want to simulate a slower link (100KBs) under my 100Mbs high speed link to see better the traffic delay etc.
Thanks for your example and for you help.
_________________
Best regards,
ddaas |
|
| Back to top |
|
|
bigfunkymo
Apprentice
Joined: 23 Jan 2004
Posts: 237
|
| Posted: Sun Jul 24, 2005 2:47 pm Post subject: |
|
|
You are right... -j MARK mangling would not be transmitted across the network. I've only been using the ToS field for my TC, so pardon my ignorance. Did you try using the TC lines I gave you? You would still need to add iptables rules to mark the packets and tc filter rules to classify based on the marking. Have you tried putting the iptables rules in another chain? It is possible that if the packets are marked in OUTPUT, they're already outside the scope of TC (I don't know for certain). Try PREROUTING or POSTROUTING.
_________________
[No package... Grabbing a set.] |
|
| Back to top |
|
|
ddaas
Tux's lil' helper
Joined: 28 Feb 2005
Posts: 106
Location: Germany
|
| Posted: Sun Jul 24, 2005 5:07 pm Post subject: |
|
|
thanks,
your tc line are good. 
_________________
Best regards,
ddaas |
|
| Back to top |
|
|
|
Networking & Security
