Abraham van der Merwe
2002-Nov-22 10:58 UTC
traffic shaping using HTB (doesn''t seem to work as expected)
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
Stef Coene
2002-Nov-22 15:41 UTC
Re: traffic shaping using HTB (doesn''t seem to work as expected)
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/