Traffic Shaping Limitations?

Hey,

A while ago I setup a traffic shaping box for the ISP I work for that
dynamically generated the rules periodically to recalculate custoemrs
priorities based on their usage over the last month. It's been running for
about a year now with 500 or so customers running through it, and
everything worked as expected.
Now we have an influx of new customers and as a result we now have over 3000
customers we want to prioritise through the traffic shaping box, and I seem
to have run into some kind of limit on the number of filters I can have at
any one time. For whatever reason, if I add N filters as the child of a
given rule, it seems to produce N squared entries when i run the command:

tc filter list dev eth1 parent 2:

Now i'm wondering if there is some easier way of filtering by IP rather than
creating specific entries for each IP going through. I was looking at hash
filters on lartc, but they only seem to be of any use when the IPs can be
filtered on a per subnet basis, which isn't the case here as all the rules
are generated dynamically, and the custoemrs all have static IP addresses.

A sample of the ruleset is as follows, please help me if you can see
anything blatantly wrong or stupid i'm doing here, I only have the LARTC to
guide me, and this system is a lot more complex than most of the examples
given there, so I could be missing something obvious. (Sorry about the word
wrapping, but theres not much i can do about that)

tc qdisc add dev eth1 root handle 1: htb default 1
tc class add dev eth1 parent 1:0 classid 1:1 htb rate 100000kbit ceil
100000kbit
tc qdisc add dev eth1 parent 1:1 handle 2: htb
tc class add dev eth1 parent 2:0 classid 2:1 htb rate 100000kbit ceil
100000kbit
tc class add dev eth1 parent 2:1 classid 2:3 htb rate 13312kbit ceil
13312kbit
tc qdisc add dev eth1 parent 2:3 handle 3: htb default 1
tc class add dev eth1 parent 3: classid 3:1 htb rate 13312kbit ceil
13312kbit
tc class add dev eth1 parent 2:1 classid 2:6 htb rate 13312kbit ceil
13312kbit
tc qdisc add dev eth1 parent 2:6 handle 6: htb default 1
tc class add dev eth1 parent 6: classid 6:1 htb rate 13312kbit ceil
13312kbit
tc class add dev eth1 parent 2:1 classid 2:7 htb rate 13312kbit ceil
13312kbit
tc qdisc add dev eth1 parent 2:7 handle 7: htb default 1
tc class add dev eth1 parent 7: classid 7:1 htb rate 13312kbit ceil
13312kbit
tc class add dev eth1 parent 2:1 classid 2:8 htb rate 13312kbit ceil
13312kbit
tc qdisc add dev eth1 parent 2:8 handle 8: htb default 1
tc class add dev eth1 parent 8: classid 8:1 htb rate 13312kbit ceil
13312kbit
tc class add dev eth1 parent 2:1 classid 2:9 htb rate 75776kbit ceil
75776kbit
tc qdisc add dev eth1 parent 2:9 handle 9: htb default 1
tc class add dev eth1 parent 9: classid 9:1 htb rate 75776kbit ceil
75776kbit
tc class add dev eth1 parent 2:1 classid 2:10 htb rate 102400kbit ceil
102400kbit
tc qdisc add dev eth1 parent 2:10 handle 10: htb default 1
tc class add dev eth1 parent 10: classid 10:1 htb rate 102400kbit ceil
102400kbit
tc class add dev eth1 parent 3:1 classid 3:29 htb rate 300kbit prio 0 ceil
512kbit
tc qdisc add dev eth1 parent 3:29 handle 29: sfq quantum 30000 perturb 5
tc filter add dev eth1 pref 29 protocol ip parent 2:0 u32 match ip dst
X.X.X.X/32 flowid 2:3
tc filter add dev eth1 pref 29 protocol ip parent 3:0 u32 match ip dst
X.X.X.X/32 flowid 3:29
tc class add dev eth1 parent 3:1 classid 3:31 htb rate 256kbit prio 0 ceil
256kbit
tc qdisc add dev eth1 parent 3:31 handle 31: sfq quantum 25600 perturb 5
tc filter add dev eth1 pref 31 protocol ip parent 2:0 u32 match ip dst
X.X.X.X/32 flowid 2:3
tc filter add dev eth1 pref 31 protocol ip parent 3:0 u32 match ip dst
X.X.X.X/32 flowid 3:31
tc class add dev eth1 parent 3:1 classid 3:32 htb rate 1536kbit prio 0 ceil
1536kbit
tc qdisc add dev eth1 parent 3:32 handle 32: sfq quantum 153600 perturb 5
tc filter add dev eth1 pref 32 protocol ip parent 2:0 u32 match ip dst
X.X.X.X/32 flowid 2:3
tc filter add dev eth1 pref 32 protocol ip parent 3:0 u32 match ip dst
X.X.X.X/32 flowid 3:32
tc class add dev eth1 parent 3:1 classid 3:33 htb rate 1536kbit prio 0 ceil
1536kbit
tc qdisc add dev eth1 parent 3:33 handle 33: sfq quantum 153600 perturb 5
tc filter add dev eth1 pref 33 protocol ip parent 2:0 u32 match ip dst
X.X.X.X/32 flowid 2:3
tc filter add dev eth1 pref 33 protocol ip parent 3:0 u32 match ip dst
X.X.X.X/32 flowid 3:33

The trouble is in the 2: rule which all the IPs pass through before being
split into other groups for various purposes. There are several thousand
filters with a parent of 2:0, and after a while i start getting the message

RTNETLINK answers: File exists

which leads me to think i've hit some kind of limit somewhere stopping me
from addings rules.

Any advice or suggestions as to what i'm doing wrong and how i could fix it
would be greatly appreciated.

Regards,
Daniel

On Fri, 12 Nov 2004 10:16:48 +1000, Daniel Andersen <(E-Mail Removed)>
wrote:

>tc filter add dev eth1 pref 29 protocol ip parent 2:0 u32 match ip dst
>X.X.X.X/32 flowid 2:3
>tc filter add dev eth1 pref 29 protocol ip parent 3:0 u32 match ip dst
>X.X.X.X/32 flowid 3:29

Try setting all the PREF values for all the filters to the same value.
There was a thread on this in LARTC mailing list, but it seems down so
I can't give you much more. google LARTC with phrase "please document
this" and then find the discussion that the quoted posting came from.

buck

buck wrote:

> On Fri, 12 Nov 2004 10:16:48 +1000, Daniel Andersen <(E-Mail Removed)>
> wrote:
>
>>tc filter add dev eth1 pref 29 protocol ip parent 2:0 u32 match ip dst
>>X.X.X.X/32 flowid 2:3
>>tc filter add dev eth1 pref 29 protocol ip parent 3:0 u32 match ip dst
>>X.X.X.X/32 flowid 3:29
>
> Try setting all the PREF values for all the filters to the same value.
> There was a thread on this in LARTC mailing list, but it seems down so

Hm that would explain why my subscription attempt has taken 24 hours so far
with no response

> I can't give you much more. google LARTC with phrase "please document
> this" and then find the discussion that the quoted posting came from.
>
> buck

Aha, that fixed it all up Works perfectly now. Thanks a lot for that.
Sombody really *does* need to document that Or at least make tc come up
with a decent error message.
Thanks again.

Daniel