Re: Divide bandwidth between 4 groups of ip with the same rate

Linux Advanced Routing and Traffic Control

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

 



Thank you very munch for your advises. I should admit that I am a
beginner with respect to QoS and stuffs related to network protocols, so
I don't completely understand some of your explanations, doesn't matter.

I have made some modifications to the previous script.

1) I have decide to remove the traffic shape in eth0 (the one connected
to my LAN), because I have seen that the download traffic is not
overhead in the ADSL router that connect the linux box to the ISP. I
have read in Internet that a correct way to shape the download traffic
is using the imq device. So I would have to study how can I use the imq
device and if I should use it. I think that the packets dropping that
you indicated for the ingress traffic would be made in this device.

2) The main problem in my LAN is that two of the IP groups that I have
defined (two neighbor in the building) use almost all the upload
bandwidth. They use Bit-torrent and E-donkey with unlimited upload rate
I ask them to limit the upload without success. So I have followed your
advices related to the traffic control in eth1 (the one connected to the
ADSL router).
	2.1) Now the rates on egress add up to 200 which is equal to the parent
rate. I decrease the parent rate in order to avoid the queue in the ADSL
router that you think is building up in the router.
	2.2) I have removed the htb default on eth1, I suppose that the
unclassified packets will go to the parent class, is ok?. Is my arp
going to the parent class?.
	2.3) Sorry, I don't know how assymetric the dsl line is and I don't
know how I can get this information. I am a beginner :)
	2.4) I have changed the r2q value in the parent qdisc from the default
value (10) to 1, because I read in the htb manual that for low rates it
would be better.
	2.5) Finally, I have read in http://www.etxea.net/docu/qos/qos.html
(the page is written in Spanish but the script is in English) that a 2
seconds latency is obtained decreasing the queue size of the eth
connected to the router for Outbound Shaping. You can see that I have
added it at the first line of the script that I am using now.

It seems the latency problem in our LAN is solved by now, I am going to
testing it for a couple of weeks and if everything is OK I will tell you.

Please, forgive my lack of knowledge about all these concerns and thank
you again for your help. The new script is below...
---
Carlos Vereda

# set queue size to give latency of about 2 seconds on low-prio packets
ip link set dev eth1 qlen 30

tc qdisc add dev eth1 root handle 2: htb r2q 1
tc class add dev eth1 parent 2: classid 2:1 htb rate 10mbit
tc class add dev eth1 parent 2:1 classid 2:11 htb rate 8mbit ceil 10mbit
tc class add dev eth1 parent 2:1 classid 2:12 htb rate 200kbit
tc class add dev eth1 parent 2:12 classid 2:10 htb rate 50kbit ceil
200kbit prio 2
tc class add dev eth1 parent 2:12 classid 2:20 htb rate 50kbit ceil
200kbit prio 2
tc class add dev eth1 parent 2:12 classid 2:30 htb rate 50kbit ceil
200kbit prio 2
tc class add dev eth1 parent 2:12 classid 2:40 htb rate 50kbit ceil
200kbit prio 2

tc qdisc add dev eth1 parent 2:10 handle 210: sfq perturb 5
tc qdisc add dev eth1 parent 2:20 handle 220: sfq perturb 5
tc qdisc add dev eth1 parent 2:30 handle 230: sfq perturb 5
tc qdisc add dev eth1 parent 2:40 handle 240: sfq perturb 5

iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.0/26 --set-mark 1
iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.64/26
--set-mark 2
iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.128/26
--set-mark 3
iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.192/26
--set-mark 4

tc filter add dev eth1 protocol ip parent 2:0 handle 1 fw flowid 2:10
tc filter add dev eth1 protocol ip parent 2:0 handle 2 fw flowid 2:20
tc filter add dev eth1 protocol ip parent 2:0 handle 3 fw flowid 2:30
tc filter add dev eth1 protocol ip parent 2:0 handle 4 fw flowid 2:40



Andy Furniss wrote:
CVEREDA@xxxxxxxxxxxxxx wrote:

Your bandwidth is likely to have overheads so you can't go too close to ISP quoted numbers. There are ways to make it more accurate for dsl, but you'll need to patch kernel/tc.

When shaping ingress traffic you have to sacrifice bandwidth or you will not build up a queue quick enough to have much effect. For ingress you should also limit the length of the queue so you drop packets.

If you really want to shape the whole eths aswell as the wan then the same applies - 100mbit nic is not 100mbit at ip level (in reality qdiscs on eth actually count as ip len + 14, but there are still more overheads than that).

Using htb default on eth will send your arp to that class unless you make filters to send it elsewhere - this may seriously mess things up if you have default as a low bandwidth class with other traffic.

If this is dsl then given how assymetric the line is, a big chunk of your egress bandwidth may be eaten by acks - on dsl an ack uses 106 bytes, but will be seen only as ip len + 14.

The rates on egress add up to 298 which if all full will not be capped by the parent setting of 256.

I think you are probably going over rate and getting a queue building up in the modem. To test you could make a high prio class and send pings through it, you can then see when you are getting lagged out.

Andy.


The script that I am using is:

#Shaping in eth0 for download traffic
tc qdisc add dev eth0 root handle 1: htb default 50
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80mbit ceil 100mbit tc class add dev eth0 parent 1:1 classid 1:12 htb rate 2700kbit ceil 2700kbit prio 7 tc class add dev eth0 parent 1:12 classid 1:10 htb rate 300kbit ceil 2700kbit prio 7 tc class add dev eth0 parent 1:12 classid 1:20 htb rate 300kbit ceil 2700kbit prio 7 tc class add dev eth0 parent 1:12 classid 1:30 htb rate 300kbit ceil 2700kbit prio 7 tc class add dev eth0 parent 1:12 classid 1:40 htb rate 300kbit ceil 2700kbit prio 7 tc class add dev eth0 parent 1:12 classid 1:50 htb rate 30kbit ceil 270kbit prio 7 tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.0/26 flowid 1:10 tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.64/26 flowid 1:20 tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.128/26 flowid 1:30 tc filter add dev eth0 protocol ip parent 1:0 u32 match ip dst 192.168.0.192/26 flowid 1:40

#Shaping in eth1 for upload traffic marking packets at mangle
tc qdisc add dev eth1 root handle 2: htb default 50 tc class add dev eth1 parent 2: classid 2:1 htb rate 10mbit
tc class add dev eth1 parent 2:1 classid 2:11 htb rate 8mbit ceil 10mbit
tc class add dev eth1 parent 2:1 classid 2:12 htb rate 256kbit
tc class add dev eth1 parent 2:12 classid 2:10 htb rate 72kbit ceil 200kbit prio 7 tc class add dev eth1 parent 2:12 classid 2:20 htb rate 72kbit ceil 200kbit prio 7 tc class add dev eth1 parent 2:12 classid 2:30 htb rate 72kbit ceil 200kbit prio 7 tc class add dev eth1 parent 2:12 classid 2:40 htb rate 72kbit ceil 200kbit prio 7
tc class add dev eth1 parent 2:12 classid 2:50 htb rate 10kbit prio 7

tc qdisc add dev eth1 parent 2:10 handle 210: sfq perturb 10
tc qdisc add dev eth1 parent 2:20 handle 220: sfq perturb 10
tc qdisc add dev eth1 parent 2:30 handle 230: sfq perturb 10
tc qdisc add dev eth1 parent 2:40 handle 240: sfq perturb 10

iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.0/26 --set-mark 1 iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.64/26 --set-mark 2 iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.128/26 --set-mark 3 iptables -A FORWARD -t mangle -i eth0 -j MARK -s 192.168.0.192/26 --set-mark 4

tc filter add dev eth1 protocol ip parent 2:0 handle 1 prio 16 fw flowid 2:10 tc filter add dev eth1 protocol ip parent 2:0 handle 2 prio 16 fw flowid 2:20 tc filter add dev eth1 protocol ip parent 2:0 handle 3 prio 16 fw flowid 2:30 tc filter add dev eth1 protocol ip parent 2:0 handle 4 prio 16 fw flowid 2:40


         TERRA
-->



------------------------------------------------------------------------

_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc




_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux