From: Devanshu Mehta <mehta@ll.mit.edu>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] IPv6 priority in tc filter
Date: Wed, 21 Dec 2005 18:58:29 +0000 [thread overview]
Message-ID: <43A9A5D5.1090705@ll.mit.edu> (raw)
In-Reply-To: <43A87716.4090801@ll.mit.edu>
As a follow-up to my previous email- it seems the current implementation
of ipv6 tc filters in iproute2 is based on the obsolete RFC 1883 in
which bits 4-7 of the IPv6 header were the 'priority'.
If this is the case, I would recommend the change suggested below or a
new filter for trafficclass that took the bits 4-11 into account for
matching against traffic class of the packet.
Devanshu
>
> ------------------------------------------------------------------------
>
> Subject:
> [LARTC] IPv6 priority in tc filter
> From:
> Devanshu Mehta <mehta@ll.mit.edu>
> Date:
> Tue, 20 Dec 2005 16:26:46 -0500
> To:
> lartc@mailman.ds9a.nl
>
> To:
> lartc@mailman.ds9a.nl
>
>
> Hi,
> I have recently started to use 'tc' on ipv6 traffic and have come
> across an issue with tc filter. As per tc_filter.c in iproute2-050816,
> to match 'priority' of an ipv6 packet, the u32 filter matches against
> the first 8 bits of the packet.
>
> From f_u32.c:
>
> if (strcmp(*argv, "priority") = 0) {
> NEXT_ARG();
> res = parse_u8(&argc, &argv, sel, 0, 0);
> goto done;
> }
>
> According to RFC2460 for IPv6 (http://www.ietf.org/rfc/rfc2460.txt),
> the first 4 bits of the packet are the version number and the
> subsequent 8 bits are the traffic class. Shouldn't the u32 filter be
> matching against the 8 bits of the traffic class, not the 4bit
> version+first 4bits of traffic class?
>
> The reason this is relevant is because I am trying to match EF traffic
> with a tc filter command:
> tc filter add dev eth2.1070 parent 10: protocol ipv6 prio 1 u32 match
> ip6 priority 0xb8 0xff flowid 10:1
>
> i.e. 0xb8 for EF. This, however, does not match my EF packets. If I
> send the following command:
> tc filter add dev eth2.1070 parent 10: protocol ipv6 prio 1 u32 match
> ip6 priority 0x6b 0xff flowid 10:1
>
> then it actually does match EF packets. That is, it matches the 4 bits
> of the version (IP v6) and the first 4 bits of the traffic class. I
> believe, the code above should actually read:
>
> if (strcmp(*argv, "priority") = 0) {
> NEXT_ARG();
> res = parse_u8(&argc, &argv, sel, 4, 0);
> goto done;
> }
>
> though I may be mistaken as to the actual syntax of parse_u8().
>
>------------------------------------------------------------------------
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
prev parent reply other threads:[~2005-12-21 18:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-20 21:26 [LARTC] IPv6 priority in tc filter Devanshu Mehta
2005-12-21 18:58 ` Devanshu Mehta [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43A9A5D5.1090705@ll.mit.edu \
--to=mehta@ll.mit.edu \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.