Re: [LARTC] Problems setting up nested qdisc, feedback to LARTC HOWTO

["Georg C. F. Greve" <greve@fsfeurope.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3690 bytes --]

 || On Sat, 16 Jul 2005 01:14:48 -0400
 || Jody Shumaker <jody.shumaker@gmail.com> wrote: 

 js> When I read this earlier I thought of offering the same, i'm
 js> using a mix of -j mark and tc filters to do my routing into
 js> nexted qdiscs.  Seems more like i'd consider this a bug of
 js> classify that should be fixed, and maybe a note in the howto that
 js> it is broken for now.

I fully agree with your classification of this behaviour as a bug.

Also I agree that ideally it should be fixed.

Do the authors know this bug exists? Where would it have to be filed?


Until then, what about adding something to section 12, "Advanced
filters for (re-)classifying packets" about this? My suggestion would
be to add a subsection

 12.X Nested qdiscs: complex classification using MARK and CLASSIFY

 12.X.1 Classification problems

        In environments with nested qdiscs, the iptables CLASSIFY
        target or tc filters on root qdisc level do not work as one
        might expect: classification to assign a packet to a qdisc in
        a nested structure is ignored.

        Consider the following example:

        generate a prio qdisc, all traffic going to band 3 (which is a
        somewhat inconsistent numerical 2 in priomap, see prio qdisc
        section for more information):
          # tc qdisc add dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

        now add a htb qdisc at band 1 of the prio qdisc:
          # tc qdisc add dev eth0 parent 1:1 handle 10: htb default 40
          # tc class add dev eth0 parent 10: classid 10:1 htb rate 500kbit
          # tc class add dev eth0 parent 10:1 classid 10:10 htb rate 100kbit
          # tc class add dev eth0 parent 10:1 classid 10:20 htb rate 100kbit
          # tc class add dev eth0 parent 10:1 classid 10:30 htb rate 100kbit
          # tc class add dev eth0 parent 10:1 classid 10:40 htb rate 100kbit

        All unclassified traffic goes into band 3 of the prio qdisc,
        traffic classified for target 1:2 goes into band 2, as
        expected. But if traffic is classified for 10:10, 10:20, 10:30
        or 10:40, all of it goes into band 3 of the prio qdisc,
        classification is ignored!

        Yes, this looks like a bug. Fortunately, there is a
        workaround.

 12.X.2 Combining MARK and CLASSIFY

        In the above example, classifying traffic for 1:1 works as
        expected: traffic goes into the htb, all traffic ending up in
        the default bucket, 10:40. This is obviously not very useful,
        but allows us to now *attach a filter to the htb qdisc*:

          # tc filter add dev eth0 protocol ip parent 10:0 prio 1 handle 1 fw classid 10:10

        Which puts all packets marked with handle 1 into the first
        bucket: Marking packets is done in iptables with the MARK
        target. And naturally, you can also place other filters into
        the htb qdisc.

        So for packets to be distributed in a nested hierarchy, you
        have to CLASSIFY that traffic for the root qdisc minor device
        that contains the nested structure and then add filters inside
        that nested structure which subdivide the traffic.

        The MARK target works very well for this.


Naturally, feel free to edit/improve.

Could the appropriate section author please add this? I think it would
be very helpful.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 309 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc