I have the following setup:

tc qdisc del dev eth1 root
tc qdisc add dev eth1 root handle 1: htb
tc class add dev eth1 parent 1: classid 1:1 htb rate 80kbit ceil 80kbit
tc qdisc add dev eth1 parent 1:1 handle 2: prio
tc qdisc add dev eth1 parent 2:1 handle 3: sfq perturb 10
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
flowid 3:

(the filter line is not like the one suggested in the howto because my
version of tc (the most recent with htb patch) barfs on not having any
rules)

After a while, looking at the stats:
qdisc sfq 3: dev eth1 limit 128p quantum 1514b perturb 10sec
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc prio 2: dev eth1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc htb 1: dev eth1 r2q 10 default 0 direct_packets_stat 476
 Sent 112219 bytes 476 pkts (dropped 0, overlimits 0)

All the traffic went through the top htb (which wasn't limited) and
went straight out again. Why didn't the filter rule put everything in
the 3: SFQ, forcing it to trickle through the limited HTB class 1:1?

--
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2

On Sat, Apr 19, 2003 at 10:55:53PM +0200, Frank v Waveren wrote:
> tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
flowid 3:
Perhaps of interest:

Replacing the filter line with:
tc filter add dev $DEV protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
flowid 1:1
tc filter add dev $DEV protocol ip parent 1:1 prio 2 u32 match u8 0 0x0 at 0
flowid 2:
will convince the packet to trickle down to 2:.
Adding
tc filter add dev $DEV protocol ip parent 2: prio 2 u32 match u8 0 0x0 at 0
flowid 3:
will not get it down to 3: however.
Also, adding just
tc filter add dev $DEV protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
flowid 2:

will _not_ get it down to 2:.

I think this has gotten to the point where kernel versions are
interesting, I'm running 2.4.21-pre5-ac3.

--
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2

On Saturday 19 April 2003 22:55, Frank v Waveren wrote:
> I have the following setup:
>
> tc qdisc del dev eth1 root
> tc qdisc add dev eth1 root handle 1: htb
> tc class add dev eth1 parent 1: classid 1:1 htb rate 80kbit ceil 80kbit
> tc qdisc add dev eth1 parent 1:1 handle 2: prio
> tc qdisc add dev eth1 parent 2:1 handle 3: sfq perturb 10
> tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
> flowid 3:
>
> (the filter line is not like the one suggested in the howto because my
> version of tc (the most recent with htb patch) barfs on not having any
> rules)
>
> After a while, looking at the stats:
> qdisc sfq 3: dev eth1 limit 128p quantum 1514b perturb 10sec
>  Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
> qdisc prio 2: dev eth1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
>  Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
> qdisc htb 1: dev eth1 r2q 10 default 0 direct_packets_stat 476
>  Sent 112219 bytes 476 pkts (dropped 0, overlimits 0)
>
> All the traffic went through the top htb (which wasn't limited) and
> went straight out again. Why didn't the filter rule put everything in
> the 3: SFQ, forcing it to trickle through the limited HTB class 1:1?
Qdisc 3: is added to class 2:1.  So all traffic flowing in class 2:1 is
handled by qdisc 3:.  Also, traffic in class 1:1 is handled by qdisc 2:.
So you have to put the traffic in the class and not the qdisc.  So your filter
should be : 1: -> 1:1 and a second filter from 2: -> 2:1.
Or 1: -> 2:1.
The end of a filter is a class, not a qdisc.

Stef

--

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

Stef Coene wrote:
> The end of a filter is a class, not a qdisc.

Ok, changed it to:
tc qdisc del dev eth1 root
tc qdisc add dev eth1 root handle 1: htb
tc class add dev eth1 parent 1: classid 1:1 htb rate 80kbit ceil 80kbit
tc qdisc add dev eth1 parent 1:1 handle 2: prio
tc qdisc add dev eth1 parent 2:1 handle 3: sfq perturb 10
tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
flowid 2:1

>> After a while, looking at the stats:
Once again, after a while:

qdisc sfq 3: dev eth1 limit 128p quantum 1514b perturb 10sec
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc prio 2: dev eth1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc htb 1: dev eth1 r2q 10 default 0 direct_packets_stat 2600
 Sent 448816 bytes 2600 pkts (dropped 0, overlimits 0)

Still no traffic going through the SFQ :-(

--
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2

On Sunday 20 April 2003 23:56, Frank v Waveren wrote:
> Stef Coene wrote:
> tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0 at 0
> flowid 2:1
What do you want to match??????

Stef

--

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

On Sun, Apr 20, 2003 at 11:59:44PM +0200, Stef Coene wrote:
> On Sunday 20 April 2003 23:56, Frank v Waveren wrote:
> > Stef Coene wrote:
> > tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8 0 0x0
at 0
> > flowid 2:1
> What do you want to match??????

That should match anything, right? I tried not having any filter in
the commandline as the HOWTO suggested, but tc didn't like it and
complained:
Unknown filter "flowid", hence option "2:1" is unparsable.

--
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2

On Monday 21 April 2003 00:12, Frank v Waveren wrote:
> On Sun, Apr 20, 2003 at 11:59:44PM +0200, Stef Coene wrote:
> > On Sunday 20 April 2003 23:56, Frank v Waveren wrote:
> > > Stef Coene wrote:
> > > tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match u8
0 0x0
> > > at 0 flowid 2:1
> >
> > What do you want to match??????
>
> That should match anything, right? I tried not having any filter in
> the commandline as the HOWTO suggested, but tc didn't like it and
> complained:
You can specify a default class if you add the htb qdisc.  So all packets not
matched by a filter ends up in that default class.
And try this if you want to have a catch all rule :
tc filter add dev eth0 parent 1: protocol ip u32 match ip src 0/0 flowid 2:1

Stef

--

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

On Mon, Apr 21, 2003 at 11:20:12AM +0200, Stef Coene wrote:
> You can specify a default class if you add the htb qdisc.  So all packets
not
> matched by a filter ends up in that default class.
Yeah, but the filters I pasted are just a test case, my actual setup
(pasted at the bottom of this email) really does require having
filters that properly delegate the traffic.

> And try this if you want to have a catch all rule :
> tc filter add dev eth0 parent 1: protocol ip u32 match ip src 0/0 flowid
2:1
Tried that too, the packets still aren't going through the SFQ.

The setup:
BW=80
DEV=eth1

HBW=$(($BW/2))

tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 1: htb r2q 1
tc class add dev $DEV parent 1: classid 1:1 htb rate ${BW}kbit ceil ${BW}kbit
tc qdisc add dev $DEV parent 1:1 handle 2: prio bands 4
tc qdisc add dev $DEV parent 2:1 handle 10: sfq perturb 10 # Lowlatency
tc qdisc add dev $DEV parent 2:2 handle 20: sfq perturb 10 # Medium Latency
tc qdisc add dev $DEV parent 2:3 handle 30: sfq perturb 10 # Regular
tc qdisc add dev $DEV parent 2:4 handle 40: htb r2q 1      # Bulk

tc class add dev $DEV parent 40: classid 40:1 htb rate ${HBW}kbit ceil ${BW}kbit
tc class add dev $DEV parent 40: classid 40:2 htb rate ${HBW}kbit ceil ${BW}kbit
tc qdisc add dev $DEV parent 40:1 handle 41: sfq perturb 10
tc qdisc add dev $DEV parent 40:2 handle 42: sfq perturb 10

tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip protocol 1 0xff
flowid 2:1
tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip tos 0x10 0xff
flowid 2:1
tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip protocol 6 0xff
match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33
flowid 2:1 # Small ACKs

tc filter add dev $DEV parent 1: protocol ip prio 2 handle 1022 fw flowid 40:1 
# Bulk1
tc filter add dev $DEV parent 1: protocol ip prio 2 handle 1027 fw flowid 40:2 
# Bulk2

tc filter add dev $DEV parent 1: protocol ip prio 3 u32 match ip protocol 6 0xff
match u8 0x10 0xff at nexthdr+13 flowid 2:1  # All ACKs

tc filter add dev $DEV protocol ip parent 1: prio 999 u32 match ip src 0/0
flowid 2:3  # Anything else goes into the Regular category


--
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2

On Monday 21 April 2003 16:04, Frank v Waveren wrote:
> On Mon, Apr 21, 2003 at 11:20:12AM +0200, Stef Coene wrote:
> > And try this if you want to have a catch all rule :
> > tc filter add dev eth0 parent 1: protocol ip u32 match ip src 0/0
flowid
> > 2:1
>
> Tried that too, the packets still aren't going through the SFQ.
>
> The setup:
> BW=80
> DEV=eth1
>
> HBW=$(($BW/2))
>
> tc qdisc del dev $DEV root
> tc qdisc add dev $DEV root handle 1: htb r2q 1
> tc class add dev $DEV parent 1: classid 1:1 htb rate ${BW}kbit ceil
> ${BW}kbit tc qdisc add dev $DEV parent 1:1 handle 2: prio bands 4
> tc qdisc add dev $DEV parent 2:1 handle 10: sfq perturb 10 # Lowlatency
> tc qdisc add dev $DEV parent 2:2 handle 20: sfq perturb 10 # Medium Latency
> tc qdisc add dev $DEV parent 2:3 handle 30: sfq perturb 10 # Regular
> tc qdisc add dev $DEV parent 2:4 handle 40: htb r2q 1      # Bulk
>
> tc class add dev $DEV parent 40: classid 40:1 htb rate ${HBW}kbit ceil
> ${BW}kbit tc class add dev $DEV parent 40: classid 40:2 htb rate ${HBW}kbit
> ceil ${BW}kbit tc qdisc add dev $DEV parent 40:1 handle 41: sfq perturb 10
> tc qdisc add dev $DEV parent 40:2 handle 42: sfq perturb 10
>
> tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip protocol 1
> 0xff flowid 2:1 tc filter add dev $DEV parent 1: protocol ip prio 1 u32
> match ip tos 0x10 0xff flowid 2:1 tc filter add dev $DEV parent 1: protocol
> ip prio 1 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16
> 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 2:1 # Small ACKs
>
> tc filter add dev $DEV parent 1: protocol ip prio 2 handle 1022 fw flowid
> 40:1  # Bulk1 tc filter add dev $DEV parent 1: protocol ip prio 2 handle
> 1027 fw flowid 40:2  # Bulk2
>
> tc filter add dev $DEV parent 1: protocol ip prio 3 u32 match ip protocol 6
> 0xff match u8 0x10 0xff at nexthdr+13 flowid 2:1  # All ACKs
>
> tc filter add dev $DEV protocol ip parent 1: prio 999 u32 match ip src 0/0
> flowid 2:3  # Anything else goes into the Regular category
But where is your catch all rule to put the packets in the 2:4 band?
And you never put packets in the 2:2 band.

An other question, why do you added that 4 bands prio?  You can do the same
only with the htb qdisc.

Stef

--

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

On Mon, Apr 21, 2003 at 09:33:52PM +0200, Stef Coene wrote:
> > The setup:
> > BW=80
> > DEV=eth1
> > HBW=$(($BW/2))
> >
> > tc qdisc del dev $DEV root
> > tc qdisc add dev $DEV root handle 1: htb r2q 1
> > tc class add dev $DEV parent 1: classid 1:1 htb rate ${BW}kbit ceil
> > ${BW}kbit tc qdisc add dev $DEV parent 1:1 handle 2: prio bands 4
> > tc qdisc add dev $DEV parent 2:1 handle 10: sfq perturb 10 #
Lowlatency
> > tc qdisc add dev $DEV parent 2:2 handle 20: sfq perturb 10 # Medium
Latency
> > tc qdisc add dev $DEV parent 2:3 handle 30: sfq perturb 10 # Regular
> > tc qdisc add dev $DEV parent 2:4 handle 40: htb r2q 1      # Bulk
> >
> > tc class add dev $DEV parent 40: classid 40:1 htb rate ${HBW}kbit ceil
> > ${BW}kbit tc class add dev $DEV parent 40: classid 40:2 htb rate
${HBW}kbit
> > ceil ${BW}kbit tc qdisc add dev $DEV parent 40:1 handle 41: sfq
perturb 10
> > tc qdisc add dev $DEV parent 40:2 handle 42: sfq perturb 10
> >
> > tc filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip
protocol 1
> > 0xff flowid 2:1 tc filter add dev $DEV parent 1: protocol ip prio 1
u32
> > match ip tos 0x10 0xff flowid 2:1 tc filter add dev $DEV parent 1:
protocol
> > ip prio 1 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match
u16
> > 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 2:1 # Small ACKs
> >
> > tc filter add dev $DEV parent 1: protocol ip prio 2 handle 1022 fw
flowid
> > 40:1  # Bulk1 tc filter add dev $DEV parent 1: protocol ip prio 2
handle
> > 1027 fw flowid 40:2  # Bulk2
> >
> > tc filter add dev $DEV parent 1: protocol ip prio 3 u32 match ip
protocol 6
> > 0xff match u8 0x10 0xff at nexthdr+13 flowid 2:1  # All ACKs
> >
> > tc filter add dev $DEV protocol ip parent 1: prio 999 u32 match ip src
0/0
> > flowid 2:3  # Anything else goes into the Regular category

> But where is your catch all rule to put the packets in the 2:4 band?
Catchall rule? I only want fwmarked traffic in 2:4, and it gets in
there through 40:1 and 40:2.

> And you never put packets in the 2:2 band.
Yeah, that's yet to be filled, I was going to select traffic for that
once I had it up and running. But I don't yes, because I can't even
get the simple test case working properly, let alone this :-(

> An other question, why do you added that 4 bands prio?  You can do the same
> only with the htb qdisc.
How? I want the first band to have priority, always. I could make its
rate equal to its ceil, but that'd mean the other classes in the HTB
would have to have rate 0, and that'd mean the bandwidth that gets
left after the first band was depleted would get distributed evenly,
and I don't want that.

--
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2

> > But where is your catch all rule to put the packets in the 2:4 band?
>
> Catchall rule? I only want fwmarked traffic in 2:4, and it gets in
> there through 40:1 and 40:2.
Ok.

> > And you never put packets in the 2:2 band.
> Yeah, that's yet to be filled, I was going to select traffic for that
> once I had it up and running. But I don't yes, because I can't even
> get the simple test case working properly, let alone this :-(
Ok.

> > An other question, why do you added that 4 bands prio?  You can do the
> > same only with the htb qdisc.
>
> How? I want the first band to have priority, always. I could make its
> rate equal to its ceil, but that'd mean the other classes in the HTB
> would have to have rate 0, and that'd mean the bandwidth that gets
> left after the first band was depleted would get distributed evenly,
> and I don't want that.
It depends on what you want to achieve.  You create a very complicated setup
with 3 qdiscs.  If you only want speed up ACK, and other traffic, you can do
this with 1 htb qdisc only.  More qdiscs, means more queues so higher
latency, higher CPU usage.
It also depends on how mach traffic you put in the bands.  If you only want to
speed up ACK, you can also use a htb class with a higher priority.

So it just depends on what you want to do.  Maybe there is a cleaner solution.

Stef

--

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

On Tue, Apr 22, 2003 at 04:41:31PM +0200, Stef Coene wrote:
> It depends on what you want to achieve.  You create a very complicated
setup
> with 3 qdiscs.  If you only want speed up ACK, and other traffic, you can
do
> this with 1 htb qdisc only.  More qdiscs, means more queues so higher
> latency, higher CPU usage.
> It also depends on how mach traffic you put in the bands.  If you only want
to
> speed up ACK, you can also use a htb class with a higher priority.
So a class with a higher priority that isn't empty will always be
scheduled in front of one with a lower prio? That'd do the trick yes,
good.

> So it just depends on what you want to do.  Maybe there is a cleaner
solution.
Perhaps, but at the moment I'd be happy with just having filters work
properly. I'll try a clean, unpatched, straight-from-linus (or
marcelo) kernel later this week and see if it works on that.

--
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100            1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2

On Tuesday 22 April 2003 19:25, Frank v Waveren wrote:
> On Tue, Apr 22, 2003 at 04:41:31PM +0200, Stef Coene wrote:
> > It depends on what you want to achieve.  You create a very complicated
> > setup with 3 qdiscs.  If you only want speed up ACK, and other
traffic,
> > you can do this with 1 htb qdisc only.  More qdiscs, means more queues
so
> > higher latency, higher CPU usage.
> > It also depends on how mach traffic you put in the bands.  If you only
> > want to speed up ACK, you can also use a htb class with a higher
> > priority.
>
> So a class with a higher priority that isn't empty will always be
> scheduled in front of one with a lower prio? That'd do the trick yes,
> good.
Yes.  But if you send too much data in the higher priority class (so you
overlimit it), latency goes up.

> > So it just depends on what you want to do.  Maybe there is a cleaner
> > solution.
>
> Perhaps, but at the moment I'd be happy with just having filters work
> properly. I'll try a clean, unpatched, straight-from-linus (or
> marcelo) kernel later this week and see if it works on that.

--

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

=20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stef, remember the problem about DAP users? i have written a little =
scrip to create 255 classes each for an ip of my segment, what do you =
think, am i mistaken anywhere?
I am not sure i am getting the concept right. The idea is=20
Total BW is lets say 255kbit

                   root 1:0

User 192.168.1.1:
                         |
                        1:1 2kbit ceil 255kbit
                        / \ =20
                       /   \
 1kbit ceil 127kbit   1:2  1:4 1kbit ceil 128kbit
                       |    |
               pfifo  1:3  1:5 sfq

User 192.168.1.2
                         |
                        1:6 2kbit ceil 255kbit
                        / \ =20
                       /   \
 1kbit ceil 127kbit   1:7  1:8 1kbit ceil 128kbit
                       |    |
               pfifo  1:9  1:10 sfq                      =20

And soo on 255 times...

I now the rate of the classes add up to be more than the total BW but =
since i am doing that for 2 ADSL working with multipath (loadbalanding) =
routing, i think there will never be all users using one interface. Dont =
know if my assumption is right..

To end up i have to set up a hashing table to create all the filters. =
The script to create the structure is the one on the bottom. What do you =
think? Am i going in the right direction or did i just completly missed =
what you were having in mind..? ( I have not set up the hashing table =
for filters yet)

#!/bin/bash
UPLINK=3D300
DEV=3Deth0

IP=3D""

for ((a=3D1;a<255;a++))
do
 IP=3D$IP" "$a
done


b=3D1

for a in $IP
do
 let "c=3Db"

   tc class add dev $DEV parent 1: classid 1:$b htb rate 2kbit ceil =
300kbit
 let "b=3Db+1"

   tc class add dev $DEV parent 1:${c} classid 1:${b} htb rate 1kbit =
ceil 150kbit
 let "c=3Db"
 let "b=3Db+1"

   tc qdisc add dev $DEV parent 1:${c} handle ${b}: pfifo
 let "b=3Db+1"
 let "c=3Dc-1"

   tc class add dev $DEV parent 1:${c} classid 1:${b} htb rate 1kbit =
ceil 150kbit
 let "c=3Db"
 let "b=3Db+1"

  tc qdisc add dev $DEV parent 1:${c} handle ${b}: sfq perturb 10
 let "b=3Db+1"

done

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPqWFe37diNnrrZKsEQLqHACgyyMjyFuClTgT8CZFZRUF++sFHRYAoLjA
HOWpYCLIrIa0rW32Cjh4P6bd
=3DE4FN
-----END PGP SIGNATURE-----

On Tuesday 22 April 2003 20:10, GoMi wrote:
> Stef, remember the problem about DAP users? i have written a little scrip
> to create 255 classes each for an ip of my segment, what do you think, am i
> mistaken anywhere? I am not sure i am getting the concept right. The idea
> is
> Total BW is lets say 255kbit
>
>                    root 1:0
>
> User 192.168.1.1:
>
>                         1:1 2kbit ceil 255kbit
>                         / \
>                        /   \
>  1kbit ceil 127kbit   1:2  1:4 1kbit ceil 128kbit
>
>                pfifo  1:3  1:5 sfq
>
> User 192.168.1.2
>
>                         1:6 2kbit ceil 255kbit
>                         / \
>                        /   \
>  1kbit ceil 127kbit   1:7  1:8 1kbit ceil 128kbit
>
>                pfifo  1:9  1:10 sfq
>
> And soo on 255 times...
Ok.

> I now the rate of the classes add up to be more than the total BW but since
> i am doing that for 2 ADSL working with multipath (loadbalanding) routing,
> i think there will never be all users using one interface. Dont know if my
> assumption is right..
Nothing bad will hapen if you have wrong rates for the parent.

I have a remark.  You add the class directly to the root class.  It's better
to add 1 class to the root qdisc and add the other classes to that class.

> To end up i have to set up a hashing table to create all the filters. The
> script to create the structure is the one on the bottom. What do you think?
> Am i going in the right direction or did i just completly missed what you
> were having in mind..? ( I have not set up the hashing table for filters
> yet)
The idea is ok :)
But I can't remember why you give each IP 2 subclasses?  And why they can't
use the full bandwidth ?


Stef

--

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

=20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Because i want each IP to differ from interctive traffic and the rest. I =
have to change the ceil cuantity so they can get the full bw.
I dont get what you say about the root qdisc, i forgot to add to the =
script tc qdisc add dev $DEV root handle 1: htb :)


- -----Mensaje original-----
De: Stef Coene [mailto:stef.coene@docum.org]=20
Enviado el: martes, 22 de abril de 2003 20:53
Para: GoMi
CC: lartc@mailman.ds9a.nl
Asunto: Re: [LARTC] Lots amounts of classes to solve the DAP problem


On Tuesday 22 April 2003 20:10, GoMi wrote:
> Stef, remember the problem about DAP users? i have written a little=20
> scrip to create 255 classes each for an ip of my segment, what do you=20
> think, am i mistaken anywhere? I am not sure i am getting the concept=20
> right. The idea is Total BW is lets say 255kbit
>
>                    root 1:0
>
> User 192.168.1.1:
>
>                         1:1 2kbit ceil 255kbit
>                         / \
>                        /   \
>  1kbit ceil 127kbit   1:2  1:4 1kbit ceil 128kbit
>
>                pfifo  1:3  1:5 sfq
>
> User 192.168.1.2
>
>                         1:6 2kbit ceil 255kbit
>                         / \
>                        /   \
>  1kbit ceil 127kbit   1:7  1:8 1kbit ceil 128kbit
>
>                pfifo  1:9  1:10 sfq
>
> And soo on 255 times...
Ok.

> I now the rate of the classes add up to be more than the total BW but=20
> since i am doing that for 2 ADSL working with multipath=20
> (loadbalanding) routing, i think there will never be all users using=20
> one interface. Dont know if my assumption is right..
Nothing bad will hapen if you have wrong rates for the parent.

I have a remark.  You add the class directly to the root class.  It's =
better=20
to add 1 class to the root qdisc and add the other classes to that =
class.

> To end up i have to set up a hashing table to create all the filters.=20
> The script to create the structure is the one on the bottom. What do=20
> you think? Am i going in the right direction or did i just completly=20
> missed what you were having in mind..? ( I have not set up the hashing =

> table for filters
> yet)
The idea is ok :)
But I can't remember why you give each IP 2 subclasses?  And why they =
can't=20
use the full bandwidth ?


Stef

- --=20

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


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPqWQ8n7diNnrrZKsEQKuAwCfRsaAc0/yj15O8fy4t6V6SqdK8CAAoMzw
/MeQzjUfx2pPj+ehrgB2u984
=3DvNCD
-----END PGP SIGNATURE-----

On Tuesday 22 April 2003 20:58, GoMi wrote:
> Because i want each IP to differ from interctive traffic and the rest. I
> have to change the ceil cuantity so they can get the full bw. I dont get
> what you say about the root qdisc, i forgot to add to the script tc qdisc
> add dev $DEV root handle 1: htb :)
I mean this :

1:
  1:1 with rate = ceil = link bandwidth
     1:2 IP1
     1:3 IP2
     etc

Stef

--

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

=20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have finally worked a solution for egress traffic, but now i am a bit =
troubled with ingress with IMQ due to SNAT
Here is my script, i have tried lots of combinations but with IMQ, the =
filters do not filter to the classes at all.=20
I am pretty sure its because of the SNAT i am doing. Any one nows how to =
work around this problem?

I attach the script:

UPLINK=3D300
DEV=3Deth2=20
IDEV=3Dimq1=20
IQDEV=3D1

tc qdisc add dev $DEV root handle 1:0 htb default 766
tc class add dev $DEV parent 1:0 classid 1:1 htb rate 300kbit ceil =
300kbit

tc qdisc add dev ${IDEV} handle 1: root htb default 766
tc class add dev ${IDEV} parent 1: classid 1:1 htb rate 1900kbit ceil =
1900kbit

echo "Qdisc primario 1:1 [OK]"

for ((a=3D2;a<766;a=3Da+3))
do
   tc class add dev $DEV parent 1:1 classid 1:$a htb rate 2kbit ceil =
300kbit
   tc class add dev ${IDEV} parent 1:1 classid 1:$a htb rate 2kbit ceil =
1900kbit

done

for ((a=3D2,b=3D3;a<766;a=3Da+3,b=3Db+3))
do
   tc class add dev $DEV parent 1:$a classid 1:$b htb rate 1kbit ceil =
300kbit
   tc qdisc add dev $DEV parent 1:$b handle $b: pfifo

   tc class add dev ${IDEV} parent 1:$a classid 1:$b htb rate 1kbit ceil =
1900kbit
   tc qdisc add dev ${IDEV} parent 1:$b handle $b: pfifo

done
echo "Clases interactivas y Qdiscs [OK]"

for ((a=3D2,b=3D4;a<766;a=3Da+3,b=3Db+3))
do
   tc class add dev $DEV parent 1:$a classid 1:$b htb rate 1kbit ceil =
300kbit
   tc qdisc add dev $DEV parent 1:$b handle $b: sfq perturb 10

   tc class add dev ${IDEV} parent 1:$a classid 1:$b htb rate 1kbit ceil =
1900kbit
   tc qdisc add dev ${IDEV} parent 1:$b handle $b: sfq perturb 10

done
echo "Clases no-interactivas y Qdiscs [OK]"

for ((a=3D2,b=3D3,c=3D4;a<256;a++,b=3Db+3,c=3Dc+3))
 do
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p icmp -j MARK =
--set-mark $b
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p tcp --dport =
:1024 -j MARK --set-mark $b
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p tcp --dport =
1024: -j MARK --set-mark $c
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p udp --dport =
:1024 -j MARK --set-mark $b
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p udp --dport =
1024: -j MARK --set-mark $c

  iptables -t mangle -A PREROUTING -d 192.168.2.$a -p icmp -j MARK =
--set-mark $b
  iptables -t mangle -A PREROUTING -d 192.168.2.$a -p tcp --sport :1024 =
-j MARK --set-mark $b
  iptables -t mangle -A PREROUTING -d 192.168.2.$a -p tcp --sport 1024: =
-j MARK --set-mark $c
  iptables -t mangle -A PREROUTING -d 192.168.2.$a -p udp --sport :1024 =
-j MARK --set-mark $b
  iptables -t mangle -A PREROUTING -d 192.168.2.$a -p udp --sport 1024: =
-j MARK --set-mark $c

  tc filter add dev $DEV protocol ip parent 1:0 handle $b fw flowid 1:$b
  tc filter add dev $DEV protocol ip parent 1:0 handle $c fw flowid 1:$c

  tc filter add dev $IDEV protocol ip parent 1:0 handle $b fw flowid =
1:$b
  tc filter add dev $IDEV protocol ip parent 1:0 handle $c fw flowid =
1:$c

done
echo "MANGLE y FILTROS [OK]" DEV=3Deth0

iptables -t mangle -A POSTROUTING -o eth3 -j IMQ --todev ${IQDEV}

ip link set ${IDEV} up
ip link set ${DEV} txqueue 30


- -----Mensaje original-----
De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En =
nombre de Stef Coene
Enviado el: martes, 22 de abril de 2003 21:06
Para: GoMi
CC: lartc@mailman.ds9a.nl
Asunto: Re: [LARTC] Lots amounts of classes to solve the DAP problem


On Tuesday 22 April 2003 20:58, GoMi wrote:
> Because i want each IP to differ from interctive traffic and the rest. =

> I have to change the ceil cuantity so they can get the full bw. I dont =

> get what you say about the root qdisc, i forgot to add to the script=20
> tc qdisc add dev $DEV root handle 1: htb :)
I mean this :

1:
  1:1 with rate =3D ceil =3D link bandwidth
     1:2 IP1
     1:3 IP2
     etc

Stef

- --=20

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/

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPqaK637diNnrrZKsEQI0LgCgwVy/IzJ8JYiSRbfKNGLf8kXMIhwAoPae
nzZ18637z02Pedi4NXSleWNg
=3DGbCa
-----END PGP SIGNATURE-----

On Wednesday 23 April 2003 14:45, GoMi wrote:
> I have finally worked a solution for egress traffic, but now i am a bit
> troubled with ingress with IMQ due to SNAT Here is my script, i have tried
> lots of combinations but with IMQ, the filters do not filter to the classes
> at all. I am pretty sure its because of the SNAT i am doing. Any one nows
> how to work around this problem?
So the filters for the eth2 device are working?
Mhh.  You put all packets leaving eth3 in the imq1 device?  Why not shaping on
the eth3 device???

I have some other remarks.  You will get some warnings in your kernel log
about quantum too low.  That's because you have 1kbit rate.  You can solve
this by specifying a quantum if you add the htb class.  The minimum quantum
is MTU bytes.
Also the pfifo.  I'm not sure how and if this will work.  It's possbile that
the default size of the pfifo is too small.

I snipped your almost perfect script to save some bandwidth :)

> ip link set ${IDEV} up
> ip link set ${DEV} txqueue 30
I'm not sure if this is going to change anything.  As fas as I can remember,
you replaced the default queue with something else so the inital depth of
that queue doesn't mather anymore.

Stef

--

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

=20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stef, let me explain the full scenario:

Two 2mbit adsl's with to ethernets to them eth0 and eth2
A third ethernet card going to my switch eth3

I red you last email, and i set up a configuration to shape eth3 as well =
unstead of using IMQ

I attach the three scripts for all the interfaces. The thing is, when =
the DAP programs start to download,
The interactive traffic does not get the rate guarated, i am really =
falling into desesperation here :(
Thanks for your patience :)

#!/bin/bash
UPLINK=3D300
DEV=3Deth0

tc qdisc add dev $DEV root handle 1:0 htb default 766
tc class add dev $DEV parent 1:0 classid 1:1 htb rate 300kbit ceil =
300kbit

echo "Qdisc primario 1:1 [OK]"

for ((a=3D2;a<766;a=3Da+3))
do
   tc class add dev $DEV parent 1:1 classid 1:$a htb rate 2kbit ceil =
300kbit
done

for ((a=3D2,b=3D3;a<766;a=3Da+3,b=3Db+3))
do
   tc class add dev $DEV parent 1:$a classid 1:$b htb rate 1kbit ceil =
300kbit
   tc qdisc add dev $DEV parent 1:$b handle $b: pfifo
done
echo "Clases interactivas y Qdiscs [OK]"

for ((a=3D2,b=3D4;a<766;a=3Da+3,b=3Db+3))
do
   tc class add dev $DEV parent 1:$a classid 1:$b htb rate 1kbit ceil =
300kbit
   tc qdisc add dev $DEV parent 1:$b handle $b: sfq perturb 10
done
echo "Clases no-interactivas y Qdiscs [OK]"

for ((a=3D2,b=3D3,c=3D4;a<256;a++,b=3Db+3,c=3Dc+3))
 do
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p icmp -j MARK =
--set-mark $b

  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p tcp --dport =
:1024 -j MARK --set-mark $b
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p tcp --dport =
1024: -j MARK --set-mark $c

  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p udp --dport =
:1024 -j MARK --set-mark $b
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p udp --dport =
1024: -j MARK --set-mark $c

  iptables -t mangle -I PREROUTING -s 192.168.2.$a -i eth3 -p tcp -m tcp =
--tcp-flags SYN,RST,ACK SYN -j MARK --set-mark $b

  tc filter add dev $DEV protocol ip parent 1:0 handle $b fw flowid 1:$b
  tc filter add dev $DEV protocol ip parent 1:0 handle $c fw flowid 1:$c
done
echo "MANGLE y FILTROS [OK]"

######################################

#!/bin/bash
UPLINK=3D300
DEV=3Deth2

tc qdisc add dev $DEV root handle 1:0 htb default 766
tc class add dev $DEV parent 1:0 classid 1:1 htb rate 300kbit ceil =
300kbit

echo "Qdisc primario 1:1 [OK]"

for ((a=3D2;a<766;a=3Da+3))
do
   tc class add dev $DEV parent 1:1 classid 1:$a htb rate 2kbit ceil =
300kbit
done

for ((a=3D2,b=3D3;a<766;a=3Da+3,b=3Db+3))
do
   tc class add dev $DEV parent 1:$a classid 1:$b htb rate 1kbit ceil =
300kbit
   tc qdisc add dev $DEV parent 1:$b handle $b: pfifo
done
echo "Clases interactivas y Qdiscs [OK]"

for ((a=3D2,b=3D4;a<766;a=3Da+3,b=3Db+3))
do
   tc class add dev $DEV parent 1:$a classid 1:$b htb rate 1kbit ceil =
300kbit
   tc qdisc add dev $DEV parent 1:$b handle $b: sfq perturb 10
done
echo "Clases no-interactivas y Qdiscs [OK]"

for ((a=3D2,b=3D3,c=3D4;a<256;a++,b=3Db+3,c=3Dc+3))
 do
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p icmp -j MARK =
--set-mark $b

  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p tcp --dport =
:1024 -j MARK --set-mark $b
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p tcp --dport =
1024: -j MARK --set-mark $c

  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p udp --dport =
:1024 -j MARK --set-mark $b
  iptables -t mangle -A FORWARD -s 192.168.2.$a -i eth3 -p udp --dport =
1024: -j MARK --set-mark $c

  iptables -t mangle -I PREROUTING -s 192.168.2.$a -i eth3 -p tcp -m tcp =
--tcp-flags SYN,RST,ACK SYN -j MARK --set-mark $b

  tc filter add dev $DEV protocol ip parent 1:0 handle $b fw flowid 1:$b
  tc filter add dev $DEV protocol ip parent 1:0 handle $c fw flowid 1:$c
done
echo "MANGLE y FILTROS [OK]"

##########################################

#!/bin/bash
UPLINK=3D4000
DEV=3Deth3

tc qdisc add dev $DEV root handle 1:0 htb default 766
tc class add dev $DEV parent 1:0 classid 1:1 htb rate 4mbit ceil 4mbit

echo "Qdisc primario 1:1 [OK]"

for ((a=3D2;a<766;a=3Da+3))
do
   tc class add dev $DEV parent 1:1 classid 1:$a htb rate 10kbit ceil =
2mbit
done

for ((a=3D2,b=3D3;a<766;a=3Da+3,b=3Db+3))
do
   tc class add dev $DEV parent 1:$a classid 1:$b htb rate 5kbit ceil =
2mbit
   tc qdisc add dev $DEV parent 1:$b handle $b: pfifo
done
echo "Clases interactivas y Qdiscs [OK]"

for ((a=3D2,b=3D4;a<766;a=3Da+3,b=3Db+3))
do
   tc class add dev $DEV parent 1:$a classid 1:$b htb rate 5kbit ceil =
2mbit
   tc qdisc add dev $DEV parent 1:$b handle $b: sfq perturb 10
done
echo "Clases no-interactivas y Qdiscs [OK]"

for ((a=3D2,b=3D3,c=3D4;a<256;a++,b=3Db+3,c=3Dc+3))
 do
  iptables -t mangle -A FORWARD -d 192.168.2.$a -i eth3 -p icmp -j MARK =
--set-mark $b

  iptables -t mangle -A FORWARD -d 192.168.2.$a -i ! eth3 -p tcp --sport =
:1024 -j MARK --set-mark $b
  iptables -t mangle -A FORWARD -d 192.168.2.$a -i ! eth3 -p tcp --sport =
1024: -j MARK --set-mark $c

  iptables -t mangle -A FORWARD -d 192.168.2.$a -i ! eth3 -p udp --sport =
:1024 -j MARK --set-mark $b
  iptables -t mangle -A FORWARD -d 192.168.2.$a -i ! eth3 -p udp --sport =
1024: -j MARK --set-mark $c

  iptables -t mangle -I PREROUTING -s 192.168.2.$a -i ! eth3 -p tcp -m =
tcp --tcp-flags SYN,RST,ACK SYN -j MARK --set-mark $b

  tc filter add dev $DEV protocol ip parent 1:0 handle $b fw flowid 1:$b
  tc filter add dev $DEV protocol ip parent 1:0 handle $c fw flowid 1:$c
done
echo "MANGLE y FILTROS [OK]"

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPqcACH7diNnrrZKsEQKvcQCgp05O299MzoOaaXo2SeY7RWjetU8AoIjM
QR4cewMIL+r/u0mZZlivwNa/
=3DBFSa
-----END PGP SIGNATURE-----

=20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there stef, since it does not work with the set up i sent you, i am =
thinking in changing the qdiscs to esfq. I will try that today and see =
what happens. Another question.. With the scripts i sent to the mailing =
list, there is an enormous amount of rules in the PREROUTING mangle =
section. Since each user has 1 class and those classes 2 marks to =
distinguish between interactive and noninteractive traffic. Thats more =
than 500 entries. I am not sure if thats a bit "too mutch" so i
thought =
adding filters on eth0 and eth2 in the root qdisc and then based on the =
src address send it to the class, and there have tc filtres based on =
marks, that way i would have 250 filters on the root chain to a their =
class, and then 2 more filters in each class, having only 2 -J MARK =
entries in the mangle chain to mark pachets. The problem is i am doing =
SNAT and the EGRESS QDISC is applied after the SNAT so the tc filter =
based on src address do not work at all. Any idea how to solve that?

- -----Mensaje original-----
De: Stef Coene [mailto:stef.coene@docum.org]=20
Enviado el: mi=E9rcoles, 23 de abril de 2003 22:29
Para: GoMi
CC: lartc@mailman.ds9a.nl
Asunto: Re: [LARTC] Lots amounts of classes to solve the DAP problem


On Wednesday 23 April 2003 14:45, GoMi wrote:
> I have finally worked a solution for egress traffic, but now i am a=20
> bit troubled with ingress with IMQ due to SNAT Here is my script, i=20
> have tried lots of combinations but with IMQ, the filters do not=20
> filter to the classes at all. I am pretty sure its because of the SNAT =

> i am doing. Any one nows how to work around this problem?
So the filters for the eth2 device are working?
Mhh.  You put all packets leaving eth3 in the imq1 device?  Why not =
shaping on=20
the eth3 device???

I have some other remarks.  You will get some warnings in your kernel =
log=20
about quantum too low.  That's because you have 1kbit rate.  You can =
solve=20
this by specifying a quantum if you add the htb class.  The minimum =
quantum=20
is MTU bytes.
Also the pfifo.  I'm not sure how and if this will work.  It's possbile =
that=20
the default size of the pfifo is too small.

I snipped your almost perfect script to save some bandwidth :)

> ip link set ${IDEV} up
> ip link set ${DEV} txqueue 30
I'm not sure if this is going to change anything.  As fas as I can =
remember,=20
you replaced the default queue with something else so the inital depth =
of=20
that queue doesn't mather anymore.

Stef

- --=20

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


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPqfwy37diNnrrZKsEQK8VgCeMeBT6yB4P7yRzXjPNxJOtelmLX8AnAmP
W2MMkuC/CU2KeqiK+dHx8MSG
=3DHy+u
-----END PGP SIGNATURE-----

On Thursday 24 April 2003 16:12, GoMi wrote:
> Hi there stef, since it does not work with the set up i sent you, i am
> thinking in changing the qdiscs to esfq. I will try that today and see what
> happens. Another question.. With the scripts i sent to the mailing list,
> there is an enormous amount of rules in the PREROUTING mangle section.
> Since each user has 1 class and those classes 2 marks to distinguish
> between interactive and noninteractive traffic. Thats more than 500
> entries. I am not sure if thats a bit "too mutch" so i thought
adding
> filters on eth0 and eth2 in the root qdisc and then based on the src
> address send it to the class, and there have tc filtres based on marks,
> that way i would have 250 filters on the root chain to a their class, and
> then 2 more filters in each class, having only 2 -J MARK entries in the
> mangle chain to mark pachets. The problem is i am doing SNAT and the EGRESS
> QDISC is applied after the SNAT so the tc filter based on src address do
> not work at all. Any idea how to solve that?
You can only solve that problem with the fw filter.  But you can use the fw
filter in a special way.  If you add 1 fw filter with no options, the mark is
used to classify the packets.  So if you have a packet with mark 10, it will
placed in class x:10.  So you only have the 500 iptables rules and only 1
filter rule.

Stef

--

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

Hi Stef,

On April 25, 2003 13:53 pm, Stef Coene wrote:
> You can only solve that problem with the fw filter.  But you can use the fw
> filter in a special way.  If you add 1 fw filter with no options, the mark
> is used to classify the packets.  So if you have a packet with mark 10, it
> will placed in class x:10.  So you only have the 500 iptables rules and
> only 1 filter rule.

You mean instead of a zillion of these:
$tc filter add dev $extif parent 1:0 protocol ip handle $var fw flowid 1:$var

It's just one of:
$tc filter add dev $extif parent 1:0 protocol ip fw
?

I see it doesn't error, but I haven't tried it on the real thing yet.

Also, could I then add further filters *with* options and would they be
honored? It'd be very cool if so.

I totally missed that info. Time to revisit ahu's doc I guess; I didn't see it
on your site.

--
Regards, Paul Evans

On Saturday 26 April 2003 06:50, Paul Evans wrote:
> Hi Stef,
>
> On April 25, 2003 13:53 pm, Stef Coene wrote:
> > You can only solve that problem with the fw filter.  But you can use
the
> > fw filter in a special way.  If you add 1 fw filter with no options,
the
> > mark is used to classify the packets.  So if you have a packet with
mark
> > 10, it will placed in class x:10.  So you only have the 500 iptables
> > rules and only 1 filter rule.
>
> You mean instead of a zillion of these:
> $tc filter add dev $extif parent 1:0 protocol ip handle $var fw flowid
> 1:$var
>
> It's just one of:
> $tc filter add dev $extif parent 1:0 protocol ip fw
> ?
>
> I see it doesn't error, but I haven't tried it on the real thing yet.
It works.  If you add that filter, packets with mark 11 will end in class
1:11.  Actually you use a bery fast hash key so you don't need to check all
the filters.
But be aware.  Mark and classid is in hex.  So somtimes 10 is translated in to
A.  So it's better to specify 0x10 for the mark so you are sure it's in hex.

> Also, could I then add further filters *with* options and would they be
> honored? It'd be very cool if so.
Yes.  You can iuse the fw filter to put the packets in a class.  And you can
add extra filters to that class to classify the packets in sub classes :
1:0
  1:1
    1:10
    1:11

$tc filter add dev $extif parent 1:0 protocol ip handle $var fw
$tc filter add dev $extif parent 1:10 blabla flowid 1:10
$tc filter add dev $extif parent 1:11 blabla flowid 1:11


> I totally missed that info. Time to revisit ahu's doc I guess; I didn't see
> it on your site.
I know it can be done, but I never checked it my self.  So if it works, let me
know :)  And if it works, I create an extra fas and update the howto.

Stef

--

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