Hello,

Currently I use following htb configuration:

              --------------- 1:0 -----------
             /                 |             \
         1:1                  1:2            1:x
      /   |   \            /   |   \        / | \
1:1001 1:2001 1:3001 1:1002 1:2002 1:3002

Classes like 1:1,1:2,1:3 limit my clients to some value, let's say
128kbit/s.
Classes like 1:1001 are used to divide and limit subflows of packets.
I use complicated classification mechanizm based on time, packet size,
protocol type, connection state, quota, source or destination port
numbers etc. It is working very well. Anyway I have encountered some
scalability issues, I have to solve before my shaping box collapses.

# iptables -vnL FORWARD -t mangle | wc -l
   2798


I have almost 3000 items in FORWARD chain in mangle table. Now I am
switching to IPMARK target which can mangle packets automaticaly based
on their src or dst address. IP address is converted to hex (ex.
10.11.12.13->0a0b0c0d), then 16 less importants bits are left (by and
operation with $ffff0000- so it is 0c0d) and then I can OR with some
number. I use class 192.168.0.0/16 for clients and I can't change
that.

So I want to create tree like this:

              --------------- 1:0 -----------
             /                 |             \
        1:0c0d              1:xxxx         1:xxxx
          |                    |
      2:0 3:0 4:0         5:0 6:0 7:0
      /   |   \            /   |   \        / | \
2:0c0d 3:0c0d 4:0c0d 5:xxxx 6:xxxx 7:xxxx

2:0,3:0,4:0 qdiscs are just a trick to allow me to split main customer
classes into 3 to 5 custom classes. I will use firewall filter co
classify packets. The filter will be connected tto the root htb qdisc
of device.

Thanks to that I will create a low number of rules inside FORWARD
chain of mangle table and so the load on my shaping boxes will
decrease.

I have discussed htb behaviour when used in complicated trees some
time ago (on this list - thread: how htb treats priorities?) and I
understand its behaviour.

My question is ... are there any problems lurking inside this idea
compared to my previous setup. Does an extra qdisc (no rate, no ceil,
no prio) change htb behaviour described on pages of docum.org,
especially link sharing rules? Is there a catch or everything will
work as expected?

Thx for you answers

Robert Kryczalo

On Tuesday 12 August 2003 15:27, Robert Krycza=B3o wrote:
[big snip]

> My question is ... are there any problems lurking inside this idea
> compared to my previous setup. Does an extra qdisc (no rate, no ceil,
> no prio) change htb behaviour described on pages of docum.org,
> especially link sharing rules? Is there a catch or everything will
> work as expected?
The setup wih the extra qdiscs will work.  But an extra qdisc means a bgger=
=20
box needed and higher delays.

Stef

=2D-=20

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