Damion,
: I am wondering, what is the best way to do some 'generic shaping' on a
: firewall/gateway box. Currently, I'm just running a wondershaper
: variant on the WAN interface. htb qdiscs for outbound, and ingress
: policer for inbound.
The wondershaper is well-designed for the standalone box connected to a
DSL link. You can also use it (usually) very well on a masquerading box,
but if you want to do fancier things, you may wish to consider ditching
wondershaper entirely.
: Now, assuming most traffic (except DNS requests etc) goes through the
: firewall, I could shape on the LAN side as well.
In a conventional masquerading firewall situation,
- shaping on the LAN interface will shape your usage of
download bandwidth (inbound packets).
- shaping on the WAN interface will shape your usage of
upload bandwidth (outbound packets).
: Should I put htb qdiscs on WAN as well as LAN and not use any ingress
: policers ? or should I use them as well?
There's no reason not to use ingress policers if you wish. I would
recommend, however, shaping on both the inbound and outbound traffic.
: tc qdisc add dev ppp0 root handle 1: htb default 20
: [ snip ] classid 1:1 htb rate 512kbit burst 6k
: [ snip ] classid 1:10 htb rate 512kbit burst 6k prio 1
: [ snip ] classid 1:20 htb rate 460kbit burst 6k prio 2
: [ snip ] classid 1:30 htb rate 409kbit burst 6k prio 2
:
: Will the slower queues be able to borrow extra bandwidth from the
: faster ones (when they're not in use), or do I need to specify the
: ceiling parameter to allow that?
I'm fairly certain that the above is not what you desire. When you
specify a "rate" in a class, that class will ALWAYS consume up to that
available amount of bandwidth before checking to see if the parent has any
bandwidth to lend. So, you will want to change this.
I think this is probably closer to what you wish to do, although your
numbers may be different.
[ snip ] classid 1:1 htb rate 512kbit burst 6k
[ snip ] classid 1:10 htb rate 256kbit ceil 512kbit burst 6k prio 1
[ snip ] classid 1:20 htb rate 96kbit ceil 460kbit burst 6k prio 2
[ snip ] classid 1:30 htb rate 96kbit ceil 409kbit burst 6k prio 2
Look at the sum of the rates of the children classes, this is
class 1:10 1:20 1:30
$ expr 256 + 96 + 96
448
This means that if all three classes are going full bore, you'll use
448kbit. When a class reaches its rate, it will try to borrow tokens from
the parent class (rate=ceil=512kbit). The parent will dole out the tokens
to each child class which requests tokens in quantum increments. Maybe
the diagram I drew will help you [0].
Once a child class (which is now exceeding "rate") reaches "ceil", it will
cease attempting to borrow tokens and will buffer/delay packets (this is
the shaping effect).
Nota bene: A child class will simply consume bandwidth until it reaches
its specified rate. Only after reaching the rate will the
class begin to consult the parent class and (potentially) delay
packets.
: I'm a bit unsure of the default behaviour of the htb qdisc.
I don't know if my explanation will help, but check out my description of
the HTB model [1]. Be sure to read Martin Devera's description [2], and
also consider Stef Coene's documentation [3] and tests [4]. His tests
show how bandwidth is distributed/allocated under various
conditions--essentially these graphs provide a good way to understand the
behaviour of HTB.
-Martin
[0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/diagram.html#d-general
[1] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb
[2] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
[3] http://www.docum.org/stef.coene/qos/docs/htb/
[4] http://www.docum.org/stef.coene/qos/tests/htb/index.html
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
