Classify target

Classify target

[Franck Joncourt]

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

Hello,

I am looking for a set of rules in order to allow me to set priority on
traffic. I mean, when I use ftp my full bandwidth is used, and waiting
for a result on google for a minute is not a pleasure.

So, by now, I have found the classify match could be of interest to me.

Here is an example fom the iptables tutorial :

iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j CLASSIFY
- --set-class 20:10

I have read quickly the lartc howto (15.10.1) and it does not seem that
easy. I suppose I have to create two classes, one for ftp traffic and
another one for the main traffic.

Could anyone confirm that the way I have to do ? If not, do you have a
clue or a link ?

- --
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF  9A3C C490 534E 75C0 89FE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFzyR3xJBTTnXAif4RAhBWAJwNKl53L4v1tG98zfaeY0uvw2f1twCgk6nQ
jD7nJQS75jGg3EZvsCOUiSg=
=BR6n
-----END PGP SIGNATURE-----

		
___________________________________________________________ 
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal 
http://uk.docs.yahoo.com/nowyoucan.html

Re: CLASSIFY target

[Patrick McHardy]

Chip Schweiss wrote:
> Is there a technical reason why the CLASSIFY target can only be called
> from the POSTROUTING chain of the mangle table?  
> 
> It seems rather wasteful to repeat all the logic necessary to classify a
> packet in the POSTROUTING chain that in most case will already be done
> in the filter table.

It can also be called in the FORWARD and OUTPUT chains, but thats not
the point of course. Technically there is no reason for this, its more
of a convention to do packet mangling in the mangle table. The only
case where it is really necessary is marking packets for routing by
fwmark in the output chain, since these packets need to be rerouted.

I guess we could remove this restriction.

> Besides, in my testing the overhead of classifying
> packets in the mangle table seems to be many magnitudes greater than in
> the filter table.

How did you test this? Please post numbers if you have any.

> Would it be possible to simply remove the checks if the rule is being
> added in the POSTROUTING chain of mangle table from the kernel &
> iptables sources and have the CLASSIFY target work from the filter
> table?

Feel free so send a patch, but please also do this for all other
targets restricted to the mangle table and update the manpage.

CLASSIFY target

[Chip Schweiss]

Is there a technical reason why the CLASSIFY target can only be called
from the POSTROUTING chain of the mangle table?  

It seems rather wasteful to repeat all the logic necessary to classify a
packet in the POSTROUTING chain that in most case will already be done
in the filter table.  Besides, in my testing the overhead of classifying
packets in the mangle table seems to be many magnitudes greater than in
the filter table.

Would it be possible to simply remove the checks if the rule is being
added in the POSTROUTING chain of mangle table from the kernel &
iptables sources and have the CLASSIFY target work from the filter
table?

Chip Schweiss

Re: CLASSIFY target

[Patrick McHardy]

Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> Thank you for your response. I did manage to finally find the code I was
> looking for. I also just posted a new description to LARTC with a new
> class/qdisc layout. Essentially, what I have now is:
> 
> dev wivl4 HFSC Qdisc root
>   |
>   |-> HFSC Class
>   |
>   |-> HFSC Class
>   ...etc...
> 
> And I'm doing a classify directly to those classes. They have no sub
> qdiscs or sub classes. Yet, it still will not work. Any additional
> thoughts?

No, please show the classids and commands uses.

RE: CLASSIFY target

[Eliot, Wireless and Server Administrator, Great Lakes Internet]

Thank you for your response. I did manage to finally find the code I was
looking for. I also just posted a new description to LARTC with a new
class/qdisc layout. Essentially, what I have now is:

dev wivl4 HFSC Qdisc root
  |
  |-> HFSC Class
  |
  |-> HFSC Class
  ...etc...

And I'm doing a classify directly to those classes. They have no sub
qdiscs or sub classes. Yet, it still will not work. Any additional
thoughts?

 
Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and System Engineer
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, Worth Township, and Sandusky. Call for details.

-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Tuesday, May 30, 2006 3:22 PM
To: Eliot, Wireless and Server Administrator, Great Lakes Internet
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: CLASSIFY target

Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> I am attempting to classify packets in tc using the iptables classify
> target in the postrouting chain of the mangle table, but it does not
> work. I am looking through the code to try to find out what is going
on
> (whether I am doing something wrong, or whether the kernel module code
> is messed up). I have verified that the ipt_CLASSIFY.c file is
correctly
> building a handle and that it is storing the handle in the
skb->priority
> field. However, inside the packet scheduler code, I cannot find where
> the skb->priority field is being read so that the packets can be sent
to
> the correct class. Could someone please point me in the correct
> direction for viewing this section of the code? Thanks.


The *_classify functions of the individual schedulers use it. I see
you also posted a more detailed description of your problem to lartc:
you can't use classify to classify to multiple nested qdiscs. So
if you have something like:

         <1:0 (root) hfsc>
<1:1 hfsc class> <1:2 hfsc class>
         |
   <2:0 PRIO>
         |
<2:1 - 2:3 PRIO classes>


and say CLASSIFY --set-class 2:1, the upper HFSC qdisc had no idea
how to reach qdisc 2:0. You can either use CLASSIFY --class 2:0
and then attach more classifiers to the PRIO qdisc or manually
direct traffic from 1:0 -> 2:0 and use CLASSIFY --set-class 2:1.
CLASSIFY is really only useful if you have only a single level
of classful qdiscs.

Re: CLASSIFY target

[Patrick McHardy]

Eliot, Wireless and Server Administrator, Great Lakes Internet wrote:
> I am attempting to classify packets in tc using the iptables classify
> target in the postrouting chain of the mangle table, but it does not
> work. I am looking through the code to try to find out what is going on
> (whether I am doing something wrong, or whether the kernel module code
> is messed up). I have verified that the ipt_CLASSIFY.c file is correctly
> building a handle and that it is storing the handle in the skb->priority
> field. However, inside the packet scheduler code, I cannot find where
> the skb->priority field is being read so that the packets can be sent to
> the correct class. Could someone please point me in the correct
> direction for viewing this section of the code? Thanks.


The *_classify functions of the individual schedulers use it. I see
you also posted a more detailed description of your problem to lartc:
you can't use classify to classify to multiple nested qdiscs. So
if you have something like:

         <1:0 (root) hfsc>
<1:1 hfsc class> <1:2 hfsc class>
         |
   <2:0 PRIO>
         |
<2:1 - 2:3 PRIO classes>


and say CLASSIFY --set-class 2:1, the upper HFSC qdisc had no idea
how to reach qdisc 2:0. You can either use CLASSIFY --class 2:0
and then attach more classifiers to the PRIO qdisc or manually
direct traffic from 1:0 -> 2:0 and use CLASSIFY --set-class 2:1.
CLASSIFY is really only useful if you have only a single level
of classful qdiscs.

CLASSIFY target

[Eliot, Wireless and Server Administrator, Great Lakes Internet]

I am attempting to classify packets in tc using the iptables classify
target in the postrouting chain of the mangle table, but it does not
work. I am looking through the code to try to find out what is going on
(whether I am doing something wrong, or whether the kernel module code
is messed up). I have verified that the ipt_CLASSIFY.c file is correctly
building a handle and that it is storing the handle in the skb->priority
field. However, inside the packet scheduler code, I cannot find where
the skb->priority field is being read so that the packets can be sent to
the correct class. Could someone please point me in the correct
direction for viewing this section of the code? Thanks.

 
Eliot Gable
Certified Wireless Network Administrator (CWNA)
Certified Wireless Security Professional (CWSP)
Cisco Certified Network Associate (CCNA)
CompTIA Security+ Certified
CompTIA Network+ Certified
Network and System Engineer
Great Lakes Internet, Inc.
112 North Howard
Croswell, MI 48422
(810) 679-3395
(877) 558-8324
 
Now offering Broadband Wireless Internet access in Croswell, Lexington,
Brown City, Yale, Worth Township, and Sandusky. Call for details.