Edward Smith wrote:
I want to thank the list and Andy Furniss for helping me get started
with TC. Here is my current script with some additional comments.
Please note that I can't really endorse anything below, as I'm new at
this. I can tell you that using the monitor_tc_top.pl script, I can
see traffic going into all these classes and that my users seem very
happy with the results (we are 57 people sharing a 2mbit/512k VSAT
link in Iraq). Also, all of this code is ultimately stolen from some
online source, I would love to give credit, but I don't keep records
:) I'll try to fill in some of where I found all of this as well as
compile a list of links on the page listed below.
Ok, pasting my code into this gmail window was getting ugly. So I
posted my code at:
http://www.stardotstar.org/?page_id=63
In case the script isn't clear, here is my overall idea:
4 kinds of traffic
1. 'Overhead Traffic' of ACKs and SYNs. Latency is a big problem, so
I gave this a class of its own.
2. 'Interactive Traffic' Telnet, SSH, and since our main goal is to
use this to communicate with family during our deployment, webchat.
I've tried to get a good method for matching this traffic but nothing
great has happenned. I have L7 filters installed and will probably
start using them soon. However, I also need some way to match video
and audio chat which I haven't seen yet.
For now there is an ugly hack which you will see.
3. Web Traffic. This is our secondary priority for our network.
4. All else.
Within each of the above classes (1:10, 1:20, 1:30, 1:100
respectively), I create a class for each IP on my network. I am using
shorewall, and have all of my IPs listed in /etc/ethers. There is no
checking of IPs, which would be a good addition to this script.
Feedback is welcome, use anything at your own risk, area not in sight
from tower :)
The main thing I noticed is that user rates are fixed - rate is
guaranteed and not limited by parent, which with 53 users and low rate
classes makes things a bit awkward.
With that many users some would opt for using esfq or wrr to share out
the bandwidth, though you can't set per user ceils with those and you
need to patch kernel/iproute.
Assuming you don't want to patch/rebuild and do this with what you've
got, then when you set really low rates with htb you should specify
quantum 1500 on the leafs (assuming that's your mtu).
I am not sure I would use 4 classes and do each per ip with so many
users. I suppose it depends on traffic patterns and the problem you want
to fix - maybe you only really need per ip on the chat and the lowest
class (if http is only the upstream for browsing rather than big uploads
to http ports). You could also consider putting the top class traffic
traffic with the per user seperated chat and giving it 300kbit and the
other 2 50kbit each.
Those are just thoughts, if I had 53 users I would just have to try
different things and see what worked. Doing NAT protects you somewhat
from P2P apps as they can't really be proper nodes - if thay had real
IPs then maybe you would need to do everything per user to protect from
the loads of syns and udp traffic generated.
If the users machines are windows then to acheive max download over high
latency their tcp may need tweaking, if they haven't done it already
turning on window scaling could help - it may also hinder your ingress
shaping which can be tricky :-).
Putting bfifos on the chat/video leaf classes will let you play with
buffer lengths - if someone is over their share and their app uses udp
it could be nicer to drop rather than have a long queue build up.
I think the way you are using classify means that each packet has to go
through 4x more checks than if you did the same thing with --or-mark but
with 53 users it may not be worth the extra hassle of optimising.
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
