Re: Limit the use of bandwich
From: Simon Byrnand (simon@igrin.co.nz)Date: 10/25/01
- Previous message: Marc Ende: "Re: SQL Access Problem"
- In reply to: Thomas Zimmerman: "Re: Limit the use of bandwich"
- Next in thread: Lee Hetherington: "RE: Limit the use of bandwich"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Message-Id: <3.0.6.32.20011025111533.009f8bd0@mail.igrin.co.nz> Date: Thu, 25 Oct 2001 11:15:33 +1300 To: Thomas <thomas@zimres.net> From: Simon Byrnand <simon@igrin.co.nz> Subject: Re: Limit the use of bandwich
At 04:12 PM 22/10/01 -0700, Thomas Zimmerman wrote:
>On 22-Oct 12:33, Simon Byrnand wrote:
>[snip]
>> Recent 2.2 kernels support QoS as well. I'm using 2.2.19 with iproute2
>> tools (ip and tc) and they work identically to 2.4.
>
>Would you mind letting me in on the use of ip and tc for QoS? The man
>pages (and web "examples") are very dense [for me.]
Damn, I knew somebody was going to ask something like that :-)
The trouble is I don't fully understand it myself and struggled for many
hours to achieve what I was trying to do. The details are extremely
specific to what you're trying to do. However I'll post my script as an
example. (with comments and ip addresses changed to protect the innocent :-)
#!/bin/bash
# clear old entries and reset to defaults
/sbin/tc qdisc del dev eth0 root >/dev/null 2>/dev/null
[ "$1" = stop ] && exit
# enable queuing discipline and define root class
/sbin/tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000
/sbin/tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 100Mbit
rate 100Mbit allot 1514 weight 10Mbit prio 8 maxburst 5 avpkt 1000
# specify combined incomming and outgoing bandwidth for user abc (rate
128Kbit - weight should be approx 1/10th)
/sbin/tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth
100Mbit rate 128Kbit allot 1514 weight 12Kbit prio 5 maxburst 5 avpkt 1000
bounded
# specify combined incomming and outgoing bandwith for user xyz (rate
128Kbit - weight should be approx 1/10th)
/sbin/tc class add dev eth0 parent 10:1 classid 10:200 cbq bandwidth
100Mbit rate 128Kbit allot 1514 weight 12Kbit prio 5 maxburst 5 avpkt 1000
bounded
# define queuing disciplines
/sbin/tc qdisc add dev eth0 parent 10:100 sfq quantum 1514b perturb 15
/sbin/tc qdisc add dev eth0 parent 10:200 sfq quantum 1514b perturb 15
# match incomming and outgoing packets to user abc
/sbin/tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
dst 192.168.0.10 flowid 10:100
/sbin/tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
src 192.168.0.10 flowid 10:100
# match incomming and outgoing packets to user xyz
/sbin/tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
dst 192.168.1.0/24 flowid 10:200
/sbin/tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
src 192.168.1.0/24 flowid 10:200
Ok, some comments:
1) The script is designed so that you can re-execute it, and it will wipe
the old settings and reset it, this means that you can make changes by just
editing the script then re-executing it. If you use the command line option
'stop' then it will disable throttling.
2) The machine is question has *one* network card, eth0, for both incomming
and outgoing traffic. This is a very important fact, because the rate
limiting always occurs at the *outgoing* interface. If you're routing
between two networks using two different network cards, then one card is
the "outgoing" card for traffic in one direction, and the other card is the
"outgoing" card for traffic in the other direction.
This means that if you want to control the traffic flow in both directions
with a two network card system, you need to duplicate just about
everything, and set up seperate queues etc for eth1 as well as eth0, and
match the correct traffic direction for it to work.
3) My example limits the speed of traffic to 192.168.0.10 to 128Kbit
combined both directions. It also seperately limits the combined speed for
all ip addresses in the subnet 192.168.1.0/24 to 128Kbit as well. Because
of the "bounded" option there is no borrowing of spare bandwidth from one
user to the other.
4) It is organised in a tree hierachy starting at the root discipline, and
going further down. The linking between the different parts of the tree is
controled by the 'parent' directive, and the numbers like 10:0. It's really
hard to visualise and explain it, but I'll give it a go.
The root discipline is linked directly to a network interface, and is the
starting point for all other things that are attached to that interface.
This is the line:
/sbin/tc qdisc add dev eth0 root handle 10: cbq bandwidth 100Mbit avpkt 1000
The 100Mbit is defining the total bandwidth available on that interface, in
my case 100Mbit, but it may be 10Mbit for 10Mbit ethernet, or some other
figure, for a leased line for example.
From there we have a cbq class attached with the line:
/sbin/tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 100Mbit
rate 100Mbit allot 1514 weight 10Mbit prio 8 maxburst 5 avpkt 1000
Think of this like a group - we're going to attach two other entries to
this one, and you can consider them grouped. (Only important for
"unbounded" cases)
In this case because both the sub entries under this are "bounded" I don't
bother to specify a lower speed here than the ethernet speed. Then we have
an entry for a specific queue:
/sbin/tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth
100Mbit rate 128Kbit allot 1514 weight 12Kbit prio 5 maxburst 5 avpkt 1000
bounded
The parent 10:1 attaches it to the cbq queue we created before (group) and
the rate option specifies the maximum speed. I don't know the significance
of most of the other numbers.
As well as defining a maximum rate for this queue, we also have to assign a
queuing discipline to it (which controls HOW the rate limit is achieved)
and we also have to match packets to the queue.
For assigning the queueing discipline I used:
/sbin/tc qdisc add dev eth0 parent 10:100 sfq quantum 1514b perturb 15
Which tells it to use sfq. I didn't try any other queueing disciplines.
To match packets there are a number of different methods. In this case I
used the u32 packet matching which basically lets you match based on ip
address. For example:
/sbin/tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
dst 192.168.0.10 flowid 10:100
This is probably the simplest matching you can use. The flowid matches it
to the correct queue, and you can have more than one u32 match pointing to
the same flowid. Another one is 'fw' which matches to packets marked by
firewall rules.
This is about all I know on the subject but is really just scratching the
surface.
What it really needs is someone with a lot of time on their hands to
actually DOCUMENT all this stuff properly, in a fashion understandable to
mear mortals. In particular there need to be some diagrams to show the tree
heirachy nature of it.
The source of info I found most useful was the advanced routing howto at:
http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO.html
in particular this bit:
http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO-8.html
Good luck.
Regards,
Simon
- Previous message: Marc Ende: "Re: SQL Access Problem"
- In reply to: Thomas Zimmerman: "Re: Limit the use of bandwich"
- Next in thread: Lee Hetherington: "RE: Limit the use of bandwich"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
