Re: [LARTC] traffic shaping using HTB (doesn't seem to work as expected)

[Stef Coene <stef.coene@docum.org>]

On Friday 22 November 2002 11:58, Abraham van der Merwe wrote:
> Hi!
>
> I started shaping our clients using HTB/Linux recently (since about 2 days
> ago). (Previously I used dummynet/FreeBSD and before that CBQ/GTS/IOS).
>
> I tested HTB in a lab setup (just shaped 2 connections to different speeds
> and tried it). That seemed to work, so then I switched, but in a live setup
> it all turns to ****.
>
> Basically I've got setup like this:
>
>
> internet
>
>    | eth0
>
> +---------+ eth2
>
> | qos box |-------- DMZ
>
> +---------+
>
>    | eth1
>
> +---------+
>
> | clients |
>
> +---------+
>
> I'm shaping egress on both eth0 and eth1 (shaping traffic to clients on
> eth1 and traffic to internet on eth0)
>
> my config looks like this:
>
> ------------< snip <------< snip <------< snip <------------
> # usage: class <cid> <in-rate> <out-rate> <prio>
> function class()
> {
>         $tc class add dev $iface_uunet parent 1:1 classid $1 htb rate $2
> prio $4
>         $tc class add dev $iface_wan parent 1:1 classid $1 htb rate $3 prio
> $4 }
>
> # usage: filter <cid> <net>
> function filter()
> {
>         $tc filter add dev $iface_uunet protocol ip parent 1: prio 1    \
>                 u32 match ip src $2 flowid $1
>
>         $tc filter add dev $iface_wan protocol ip parent 1: prio 1
> \
>                 u32 match ip dst $2 flowid $1
> }
>
> for i in $iface_uunet $iface_wan; do
>         # remove all queueing disciplines
>         $tc qdisc del dev $i root 2> /dev/null
>
>         # add a hierarchial token bucket queueing discipline
>         $tc qdisc add dev $i root handle 1: htb default 99 r2q 3
> done
>
> class 1:10 xxx yyy 1
> filter 1:10 a.b.c.d/e
> filter 1:10 ...
>
> class 1:11 ...
> .
> .
> .
>
> ....
>
> # catch the rest
> class 1:99 128kbit 128kbit 1
> filter 1:99 66.8.28.0/24
> filter 1:99 66.8.85.0/24
> ------------< snip <------< snip <------< snip <------------
>
> I'm not sure what is going wrong. I suspect one/more of the following
>
> 1. HTB only works if the total number of classes does not exceed total
> bandwidth - is this true? if so, it explains why this does not work since
> we oversell bandwidth with priority 2. how can I add shaping rules and
> interface bandwidth and let the qos subsystem handle the congestion
> avoidance?
>
> 2. I'm missing a client's subnet which may be eating up all me bandwidth
> (esp true for DMZ since I'm not shaping incoming bandwidth for DMZ)
>
> 3. I'm doing something wrong.
>
> If anyone has suggestions/comments re (1) and (3), please let me know.
I don't have the command that creates clasqs 1:1, but if you have a 128kbit 
connection, you have to take 120kbit or so for the maximum bandwidth.  You 
loose some small amounts of bandwidth, but that's needed.  Otherwise it can 
be the modem or router that's shaping and not your firewall.  Try it with 
100kbit and raise it untill your box is not shaping anymore.

If you add a class, you don't provide a ceil parameter.  So ceil = rate.  So 
the classes can never borrow bandwidth to each other.
And regarding to 1., htb assumes that the sum of the rates of the child 
classes is <= the rate of parent.  You don't have to follow this rule, but 
htb will work better if you do.

And if the qos box is natting, you can't use the src address on eth2 because 
the source address of the packets is natted to the address of the qos box.


Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/