Hi everyone, 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. Now, assuming most traffic (except DNS requests etc) goes through the firewall, I could shape on the LAN side as well. Should I put htb qdiscs on WAN as well as LAN and not use any ingress policers ? or should I use them as well? also, with rules like this: tc qdisc add dev ppp0 root handle 1: htb default 20 tc class add dev ppp0 parent 1:1 classid 1:1 htb rate 512kbit burst 6k tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 512kbit burst 6k prio 1 tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 460kbit burst 6k prio 2 tc class add dev ppp0 parent 1:1 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 a bit unsure of the default behaviour of the htb qdisc. thanks -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damion de Soto - Software Engineer email: damion@snapgear.com SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliances web: http://www.snapgear.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
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@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi Martin,> There''s no reason not to use ingress policers if you wish. I would > recommend, however, shaping on both the inbound and outbound traffic.If I''m running a web proxy on the gateway, then I would need ingress policer to limit the download bandwith for web requests. How will the ingress policer on the WAN interface interact with the other egress htb classes on the LAN interface ?> 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.Ok, I see this and have fixed it. So the wondershaper is wrong ? it doesn''t use the ceil values and creates rate values that sum up to a higher value than your ISP bandwidth.> [ 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 > 448Did you just guess at the ceiling numbers, or did you calculate them using some method?> 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.Thanks, I didn''t realise there was a ''LARTC HOWTO'' and a ''Traffic Control HOWTO'' The latter is much more useful and the diagrams are very helpful. regards, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damion de Soto - Software Engineer email: damion@snapgear.com SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliances web: http://www.snapgear.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/