Re: [was] addition to ipfw (read vlans from bridge)..

On Fri, Dec 29, 2006 at 10:59:53AM -0800, Julian Elischer wrote:
Yar Tikhiy wrote:
On Tue, Dec 26, 2006 at 11:27:44AM -0800, Julian Elischer wrote:
Yar Tikhiy wrote:

If what you are suggesting is that we pass into ipfw an 'offset'
into the packet as well as the packet, then yes I like that idea,
but I didn't see Andre suggest it.
Do you consider only ideas by Andre? ;-) By Andre's opinion I
meant this:

Please have the ipfw code examine the vlan tag in the mbuf instead of
fiddling with the mbuf contents.
At the moment I plan the ipfw code to be unaware of vlan headers.
the plan is:
Add an argument to ipfw which is the offset in the packet where
the IP header may be found. Change the L2 users of ipfw to
leave the packet alone, but calculate the correct offset to pass to
ipfw. IPFW will make no assumptions as to what packet contents come
before the offset. Bridge and L2 callers of ipfw will
set the offset to non-0 values where the IP callers will set it to
0. The non IP callers may make some MAC information available to the
ipfw code my some separate method, as it does at the moment. How this
is done will depend if we want to support Q-n-Q, and if so, how much..

Sounds very resonable to me.

If we want ipfw to know of L2, then examining the VLAN tag in it
is OK. If not really, then ipfw (or any pfil filter) can get just
the offset of IP.
What vlan tag? what if it's from an interface with no VLAN capacity..
What we need to do is make a convention so that vlan tags are always
created at the lowest layer, even if HW vlan tagging is not supported,
so that all packets look as if they have come from HW capable packets,
and add code so that all non WH capable interfaces interpret Van tags at
the lowest level, that way vlan packets always look the same.

It depends. As of now, a network interface driver passes up, e.g.,
to ether_input(), just what it has got. I.e., a driver in VLAN_HWTAG
mode reads the tag from a hardware register and stores it in
m_pkthdr.ether_vtag while a driver unaware of VLANs just passes up
an 802.1q tagged frame it received. Perhaps it's ether_input() that
should fix the things up for us so that we don't have to modify every
VLAN-ignorant driver.

However, converting the in-band tag to the out-of-band tag will
take 1 m_pullup() call and 1 bcopy() call and 1 m_adj() call per
tagged frame received:

but that gets done anyhow later when we convert it..

Indeed, the main burden there should be the m_pullup() call, which
cannot be avoided.


if ((m->m_flags & M_VLANTAG) == 0) {
m_pullup(m, sizeof(struct ether_vlan_header));
evh = mtod(m, struct ether_vlan_header *);

if (evh->evl_ncap_proto == ETHERTYPE_VLAN) {

m->m_pkthdr.ether_vtag = ntohs(evh->evl_tag);
m->m_flags |= M_VLANTAG;
bcopy((char *)evh, (char *)evh + ETHER_VLAN_ENCAP_LEN,
ETHER_HDR_LEN - ETHER_TYPE_LEN);
m_adj(m, ETHER_VLAN_ENCAP_LEN);
}

}

Now I cannot tell if there will be a noticable impact on performance
relative to the approach when we just do things conditionally
depending on M_VLANTAG being set or unset, e.g.:

if (m->m_flags & M_VLANTAG) {
tag = m->m_pkthdr.ether_vtag;
} else {
m_pullup(m, sizeof(struct ether_vlan_header));
evh = mtod(m, struct ether_vlan_header *);
tag = ntohs(evh->evl_tag);
}
/* now do things based on tag, e.g., filtering... */


Infinity. Why to introduce such a hard limit?

Because an infinite limit complicates things?

Not necessarily. It depends on what we are trying to do with the
tags. E.g., if we want to find the IP header offset, computing it
by skipping over an unlimited number of VLAN headers won't be more
complex than skipping over just 1-2 of them as we need a loop
already.

2 is not a loop if they are different.. note that the standard
talks about 2 different ethertypes. Also how do we currently

And switch vendors use even more ethertypes for Q-in-Q frames, e.g.,
0x9100 and 0x9200, but fortunately they should be configurable.
For now, a Q-in-Q switch theoretically can interoperate with FreeBSD
if using 0x8100 for service VLAN tags.

cope with multiple vlan tags considering that Andre has just
incorporated a single vlan tag into the mbuf? (and what happens
if we use old mtags and have multiple vlan tags? it is not defined what
happens when there are multiple mtags with the same type. How do you
get the 2nd one?)

On the input path, 802.1q headers are processed one at a time.
I.e., ether_input() calls vlan_input(), which in turn strips off
one 802.1q header or clears the M_VLAN flag, and then calls
ether_input(). Perhaps it will be an optimization to strip off all
contiguous VLAN tags at once, but that is likely to break such
things as the counters on the intermediate VLAN interfaces -- and
bridging on them. I'm still seem to be dreaming of >2 nested VLANs.
:-)

--
Yar
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: addition to ipfw..
    ... I would like to add something similar in the case where a vlan ... tag is also on the packet.. ... Then the vlan header is also held back so that the packet can be ... The ipfw will be ignoring the vlan contents.. ...
    (freebsd-net)
  • expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?
    ... the complete packet with vlan tag included as the driver simply calls ... thing vlan tag included and sends this through the socket. ... The packet socket gets everything including the vlan tag as I'd ...
    (Linux-Kernel)
  • Re: addition to ipfw..
    ... I would like to add something similar in the case where a vlan ... tag is also on the packet.. ... Then the vlan header is also held back so that the packet can be ... This allows me to filter packets that are traversing my bridge, ...
    (freebsd-net)
  • Re: [was] addition to ipfw (read vlans from bridge)..
    ... I have redone this patch in a different manner. ... Basically if it is a vlan packet, take off the whole vlan header instead ... fiddling with the mbuf contents in favour of teaching ipfw (or the ... to handle vlan tags as well. ...
    (freebsd-net)
  • Re: [was] addition to ipfw (read vlans from bridge)..
    ... If what you are suggesting is that we pass into ipfw an 'offset' ... into the packet as well as the packet, then yes I like that idea, ... What vlan tag? ...
    (freebsd-net)