[PATCH] 802.1p priority (fixed)
brooks at one-eyed-alien.net
Sat Jan 22 12:33:28 PST 2005
On Sat, Jan 22, 2005 at 04:25:46PM +0100, Jeremie Le Hen wrote:
> > 2. Mark 802.1p at PF/IPFW level. But we shold foresee a keyword to trust
> > application level information or override it. For example
> > ipfw add 802.1p trust 6 on any to any ssh <-- this trust application
> > level information and set 802.1p to 6 if it is omitted
> > ipfw add 802.1p override 6 on any to any ssh <-- this silently set
> > 802.1p == 6, regardless of application
> I'm not a 802.1q guru, but I think it would be relevant to be able to
> match against the 802.1p, at least when firewalling on layer 2 (bridging).
> Furthermore I would like to point out that we are going to introduce an
> extremely new feature into ipfw which will allow us to *modify* a packet.
> AFAIK, this is not possible for the moment, except when diverting to a
> socket. What I mean is that if I can set the 802.1p header then why
> wouldn't I be able to set the TOS value ? I think we should carefully
> choose a flexible way to extend ipfw syntax if we choose to go this way.
The nice thing about ipfw2 is that extension is easy. I envision that
we won't actually touch the packet at all in the 801.1p case and will
just add, modify, or delete a tag that the ethernet layer uses when
sending. Setting TOS values could be done in place since we have the
header at that point.
> Having the possibility to test and set the 802.1p or TOS values
> separately would avoid making a "trust"/"override" subtlety and will
> obviously make it more flexible.
I agree on this point. The one thing to be careful of is that 802.1p
priorities and TOS values work rather differently in that TOS values fit
in to an existing field of the packet and 802.1p values require
modifications to the header and adding data between the header and the
real body, possiably with a resuling reduction in MTU (though what
you're doing trying to use 802.1p priority with crappy nic I don't know
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20050122/8bc5c5ca/attachment.bin
More information about the freebsd-net