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

[Abraham van der Merwe <abz@frogfoot.net>]

[-- Attachment #1: Type: text/plain, Size: 2718 bytes --]

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.

-- 

Regards
 Abraham

Old soldiers never die.  Young ones do.

___________________________________________________
 Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks
 P.O. Box 3472, Matieland, Stellenbosch, 7602
 Cell: +27 82 565 4451 Http: http://www.frogfoot.net
 Email: abz@frogfoot.net


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]