--CE+1k2dSO48ffgeK
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 ...
=2E
=2E
=2E

=2E...

# 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 avoidan=
ce?

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.

--=20

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


--CE+1k2dSO48ffgeK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE93g3O0jJV70h31dERAsdZAJ9mRxc1FLJxLxajh8UFC0FN9b9H9ACgksu8
kI301EvEAUCh9YeSx/VGQL8=
=22aS
-----END PGP SIGNATURE-----

--CE+1k2dSO48ffgeK--

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 d=
ays
> 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 spe=
eds
> and tried it). That seemed to work, so then I switched, but in a live s=
etup
> 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 sin=
ce
> 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 bandwidt=
h
> (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 128kb=
it=20
connection, you have to take 120kbit or so for the maximum bandwidth.  Yo=
u=20
loose some small amounts of bandwidth, but that's needed.  Otherwise it c=
an=20
be the modem or router that's shaping and not your firewall.  Try it with=
=20
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 =3D rate=
=2E  So=20
the classes can never borrow bandwidth to each other.
And regarding to 1., htb assumes that the sum of the rates of the child=20
classes is <=3D the rate of parent.  You don't have to follow this rule, =
but=20
htb will work better if you do.

And if the qos box is natting, you can't use the src address on eth2 beca=
use=20
the source address of the packets is natted to the address of the qos box=
=2E


Stef

--=20

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