[LARTC] can't understand strange PRIO behaviour

[LARTC] can't understand strange PRIO behaviour

[Viktor Horvath]

[-- Attachment #1: Type: text/plain, Size: 3209 bytes --]

Hello everybody,

sorry for bothering you, but after some hours, I'm stuck. I'm living in
a student's foundation where I want to connect lots of people to a tiny
DSL link. We have exactly four types of traffic. We want a really hard
PRIO solution (as I promised to someone that group X will only use the
link capacity which isn't used by group Y). I could make a PRIO with
four classes, but as I want to separate first by MAC address in two
groups and separate each group another time afterwards, I decided to put
two PRIOs after the main one:

	   PRIO 1:
	  /       \
	 /         \
   PRIO 10:        PRIO 20:
    /   \           /     \
   /     \         /       \
SFQ 110: SFQ 120: SFQ 210: SFQ 220:

My problem now is, that my filters don't work. In fact, I wrote only
one, and all packages get elsewhere, but not in the flow I commanded.
Strangely, tc says that my rule is successfully matched. Here are the
proofs, my rule filters to flowid 10:2, but everything goes to 20:1.
Have I made an error? Am I missing some kernel feature? My versions:
Kernel 2.6.10 and newest iproute from Debian unstable (20041019-2).

Thank you for reading,
Viktor.




                --------> CONFIGURATION SCRIPT <--------

# Create the main PRIO qdisc
tc qdisc add dev ppp0 root handle 1: prio bands 2 priomap 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0
# Create the two PRIO sub-qdiscs
tc qdisc add dev ppp0 parent 1:1 handle 10: prio bands 2 priomap 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
tc qdisc add dev ppp0 parent 1:2 handle 20: prio bands 2 priomap 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
# Create the four subclasses
tc qdisc add dev ppp0 parent 10:1 handle 110: sfq
tc qdisc add dev ppp0 parent 10:2 handle 120: sfq
tc qdisc add dev ppp0 parent 20:1 handle 210: sfq
tc qdisc add dev ppp0 parent 20:2 handle 220: sfq
# Filters for classifying
# catch-all
tc filter add dev ppp0 protocol ip parent 1: prio 2 u32 match ip src
0.0.0.0/0 flowid 10:2



         --------> OUTPUT "tc -s qdisc show dev ppp0" <--------

qdisc prio 1: bands 2 priomap  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 Sent 5321336 bytes 9407 pkts (dropped 0, overlimits 0) 
qdisc prio 10: parent 1:1 bands 2 priomap  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
 Sent 2160 bytes 2 pkts (dropped 0, overlimits 0) 
qdisc prio 20: parent 1:2 bands 2 priomap  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
 Sent 5319176 bytes 9405 pkts (dropped 0, overlimits 0) 
qdisc sfq 110: parent 10:1 limit 128p quantum 1452b 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 
qdisc sfq 120: parent 10:2 limit 128p quantum 1452b 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 
qdisc sfq 210: parent 20:1 limit 128p quantum 1452b 
 Sent 5319176 bytes 9405 pkts (dropped 0, overlimits 0) 
qdisc sfq 220: parent 20:2 limit 128p quantum 1452b 
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)



  --------> OUTPUT "tc -s filter show dev ppp0" (bit later) <--------

filter parent 1: protocol ip pref 2 u32 
filter parent 1: protocol ip pref 2 u32 fh 800: ht divisor 1 
filter parent 1: protocol ip pref 2 u32 fh 800::800 order 2048 key ht
800 bkt 0 flowid 10:2  (rule hit 13430 success 13430)
  match 00000000/00000000 at 12 (success 13430 )

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [LARTC] can't understand strange PRIO behaviour

[Jason Boxman]

On Tuesday 01 February 2005 22:46, Viktor Horvath wrote:
> Hello everybody,
>
> sorry for bothering you, but after some hours, I'm stuck. I'm living in
> a student's foundation where I want to connect lots of people to a tiny
> DSL link. We have exactly four types of traffic. We want a really hard
> PRIO solution (as I promised to someone that group X will only use the
> link capacity which isn't used by group Y). I could make a PRIO with
> four classes, but as I want to separate first by MAC address in two
> groups and separate each group another time afterwards, I decided to put
> two PRIOs after the main one:

Could you perhaps replace your root prio with a classful tbf from recent 
kernel?

<snip>
> My problem now is, that my filters don't work. In fact, I wrote only
> one, and all packages get elsewhere, but not in the flow I commanded.
> Strangely, tc says that my rule is successfully matched. Here are the
> proofs, my rule filters to flowid 10:2, but everything goes to 20:1.
> Have I made an error? Am I missing some kernel feature? My versions:
> Kernel 2.6.10 and newest iproute from Debian unstable (20041019-2).

Strange.

<snip>


-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] can't understand strange PRIO behaviour

[Andreas Klauer]

On Wednesday 02 February 2005 04:46, Viktor Horvath wrote:
> tc qdisc add dev ppp0 root handle 1: prio bands 2 priomap 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0
> # Create the two PRIO sub-qdiscs
> tc qdisc add dev ppp0 parent 1:1 handle 10: prio bands 2 priomap 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0
> tc qdisc add dev ppp0 parent 1:2 handle 20: prio bands 2 priomap 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0
[...]
> # catch-all
> tc filter add dev ppp0 protocol ip parent 1: prio 2 u32 match ip src
> 0.0.0.0/0 flowid 10:2

I don't know if it is a bug or whatever, but PRIO doesn't like alien 
filters. You may only put traffic into a class of the qdisc you attached 
the filter to. At least this is how it works on my machine (2.4 kernel).

So using these filter rules should work as expected:

tc filter add dev ppp0 protocol ip parent 1: prio 2 u32 match ip src 
0.0.0.0/0 flowid 1:1
tc filter add dev ppp0 protocol ip parent 10: prio 2 u32 match ip src 
0.0.0.0/0 flowid 10:2

HTH
Andreas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] can't understand strange PRIO behaviour

[Viktor Horvath]

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]

On Wed, 2005-02-02 at 04:50 +0100, Andreas Klauer wrote:
[...]
> I don't know if it is a bug or whatever, but PRIO doesn't like alien 
> filters. You may only put traffic into a class of the qdisc you attached 
> the filter to. At least this is how it works on my machine (2.4 kernel).

Thanks a lot for this help! It's exactly as you described it, and your
rules work fine. 

On Tue, 2005-02-01 at 22:16 -0500, Jason Boxman wrote:
[...] 
> Could you perhaps replace your root prio with a classful tbf from recent 
> kernel?

It would certainly be better. However, I want a strict hierarchy, so
that first PRIO is always served before the second one. Probably I'll
have to use CBQ instead of HTB or TBF, as after reading the howto, it
seems to me you can only there add priorities for the subclasses.

Some little suggestions for the howto:

(1) Maybe one could include Andreas' sentence to the PRIO section:
"You may only put traffic into a class of the qdisc you attached the
filter to." One could add that subclasses are not possible in PRIO (this
is quite evident, but some newbies could think of it ;-)

(2) The third filter command ("catch-all") in section 9.6.1

# tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2

does not work as it doesn't use a filter. One has to use something like

# tc filter add dev eth0 protocol ip parent 10: prio 2 u32 match ip src 
0.0.0.0/0 flowid 10:2

instead.


Thanks a lot!
Viktor.

P.S. Is there a German translation going on?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]