Hi all,
based on the information in the "Linux Advanced Routing & Traffic
Control HOWTO", I was trying to set up traffic shaping on my firewall.
While I found the HOWTO very useful, in the process I ran into some
problems that I did not forsee: According to the HOWTO it seems that
it should have worked, even after spending some time going through the
sections looking for answers, the problem was not obvious to me.
So I would appreciate if you could tell me where my mistake was and
also maybe add a bit of information to the HOWTO to help others fall
into the same traps that I fell into. :-)
Here is what I wanted my ideal solution to look like:
A strong priority of traffic, where parts of the upstream should be
guaranteed rate for some traffic, the rest should be given to normal
traffic and any "leftovers" to BULK traffic, which is allowed to
starve for a while. Also, connection handshake and such very short,
time critical things should get absolute priority over everything
else.
So this is what I ideally wanted to set up:
1: PRIO QDISC (4 Bands), DEFAULT: ALL TO BAND 3 (2 in priomap)
1:1 -> SFQ, handle 10:
for priority communication (connection handshake & co)
1:2 -> HTB, handle 20:
limited to Xk for different kinds of guaranteed rates that
can "borrow" from each other, but never more than the
maximum -- so it cannot saturate the link fully.
20:1 -> SFQ, handle 100:
20:2 -> SFQ, handle 200:
20:3 -> SFQ, handle 300:
20:4 -> SFQ, handle 400:
[...]
1:3 -> PRIO QDISC (default), handle 30:
for all "normal"/unclassified traffic, TOS splitting only
30:1 (BAND 1)
30:2 (BAND 2)
30:3 (BAND 3)
1:4 -> PFIFO, handle 40:
"starvation bitbucket"
gets what is left, can starve at times
The setup was apparently successful, tc does not complain and displays
the structure: without any CLASSIFY targets, all traffic goes to 1:3
and is split in the three bands properly. Looks good.
I can also add CLASSIFY for 1:1 and 1:4, which seem to fall into the
SFQ/PFIFO buckets underneath, both look good.
The problem starts with the HTB embedded in 1:2 as 20: -- I can never
CLASSIFY traffic for it properly, the only way to get ANY traffic into
it is to CLASSIFY for 1:2, but that puts all into its default bucket,
which defeats its purpose.
Neither 20:1 nor 100:0 would put traffic into its first bucket.
Such classification is simply ignored as far as I can tell.
This is the problem that I ultimately did not find a way to solve, the
"indirect" approach of using the MARK target and tc filters also did
not work -- it shows the exact same result.
I currently run another approach to this, which I am not quite as
happy with, but which works for now -- but would still like to know:
* WHY was the 20:1 or 100:0 CLASSIFY not successful? Nothing in the
documentation seemed to indicate that it should fail.
* HOW could it have been made to work?
* WHAT kind of information was I lacking?
or, in short: WHAT did I do wrong?
I'd be grateful to find an answer and think it might help to then find
a way to add that answer into the LARTC HOWTO.
Regards,
Georg
--
Georg C. F. Greve <greve@xxxxxxxxxxxxx>
Free Software Foundation Europe (http://fsfeurope.org)
Join the Fellowship and protect your freedom! (http://www.fsfe.org)
Attachment:
pgpfdB6TNhU4Q.pgp
Description: PGP signature
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
