Which EtherTypes are recognized for 802.1AD / QinQ ?

Hi all,

802.1AD defines the EtherType / TPID as 0x88A8.
FreeBSD supports 802.1AD (QinQ tagging), see https://www.freebsd.org/cgi/man.cgi?ifconfig(8) -> vlanproto

Before IEEE passed 802.1AD , there were proprietary standards for VLAN stacking, often called 802.1QinQ or similar. Sometimes, vendors used 0x9100, 0x9200 or 0x9300 as EtherType for the "outer" tag, but some switches can also insert 0x8100 into another 0x8100.

Today, its still possible to buy switches with QinQ-capability with proprietary QinQ implementation which uses some non-802.1AD-compliant EtherTypes. Not all offer the ability to change the EtherType to 0x88A8 or define it by your own, so you have to deal with it.

I am wondering, which EtherTypes are assigned internally in FreeBSD to be handled as QinQ ?

I googled a bit and found this, but i am not sure if it will answer my question: https://reviews.freebsd.org/D21846

Thanks for helping to clarify this topic.

Kind regards
 
I googled a bit and found this, but i am not sure if it will answer my question: https://reviews.freebsd.org/D21846
The contrib/tcpdump/ethertype.h is for tcpdump(1) as far as I can tell. At the top of that file it mentions <netinet/if_ether.h>, that header file pulls in net/ethernet.h. This is the header file with all the defined ethertypes.

Code:
#define ETHERTYPE_QINQ          0x88A8  /* 802.1ad VLAN stacking */
{...}
#define ETHERTYPE_8021Q9100     0x9100  /* IEEE 802.1Q stacking (proprietary) */
{...}
#define ETHERTYPE_8021Q9200     0x9200  /* IEEE 802.1Q stacking (proprietary) */
#define ETHERTYPE_8021Q9300     0x9300  /* IEEE 802.1Q stacking (proprietary) */
 
Thanks for reply.

So, you answer was a bit to technical for my knowledge level. To be sure: Does this mean all four quotet EtherTypes are recognized as QinQ?
 
Does this mean all four quotet EtherTypes are recognized as QinQ?
I'm not a developer either, but yes, that's what I understood from it. You may want to ask on the freebsd-net mailing lists to be sure. There aren't a lot of FreeBSD developers here on the forums.
 
Thanks for reply.

So, you answer was a bit to technical for my knowledge level. To be sure: Does this mean all four quotet EtherTypes are recognized as QinQ?
Based on grepping for it in /sys/net, not by the kernel. I only see some code handling ETHERTYPE_QINQ, not the proprietary types.
 
Thanks for reply. So, this means, only 0x88A8 is recognized and proprietary QinQ will not work with FreeBSD.


Why are the other EtherTypes defined/described in this file?

Would it be possible to open a feature request for proprietary QinQ-support?

It would be nice if all alternative/proprietary EtherTypes used for QinQ would be recognized for vlanproto 802.1ad or
if users can specify one EtherType per device and/or a list of EtherTypes per device.

Because it could be possible, that Switches or Routers with different EtherTypes for QinQ can be connected to a device.
 
I only see some code handling ETHERTYPE_QINQ, not the proprietary types.
Yes, looking a little further I think that header file just defines the different ethertypes so FreeBSD recognizes them, not that it's actually supported. There are a whole bunch of weird and wonderful ethertypes defined and I'm fairly certain most of them aren't supported.

Would it be possible to open a feature request for proprietary QinQ-support?
The thing about proprietary protocols is that they're not documented, not openly in any case. Or have some IP or patents on it. So you would have to reverse engineer it. Which is going to make it unlikely someone will add support for it.
 
Would it be possible to open a feature request for proprietary QinQ-support?

It would be nice if all alternative/proprietary EtherTypes used for QinQ would be recognized for vlanproto 802.1ad or
if users can specify one EtherType per device and/or a list of EtherTypes per device.
You can open a feature request but I doubt it will go anywhere. [Just a guess]

I used to know this stuff 10 years ago.... I thought proper support for QinQ was more complicated than just recognizing ether types. Also, why would a terminal FreeBSD device see QinQ?
 
The thing about proprietary protocols is that they're not documented, not openly in any case. Or have some IP or patents on it. So you would have to reverse engineer it. Which is going to make it unlikely someone will add support for it.

I see the argument regarding implementation of proprietary protocolls.

But in this case, a lot of (or maybe the most) devices which support proprietary QinQ only use the wrong EtherType/TPID. For example, we have brand new Dell-Switches with OS6 as Operating system. Per default OS6 uses 0x9100 as Ethertype for QinQ, maybe because of historical reasons (maybe OS6 supported QinQ before IEEE passed 802.1AD). OS6 allows to change the EtherType to 0x88A8 or to a user specified value (even 0x8100 from 802.1Q would be possible), to make these compatible with exotic EtherTypes of third party QinQ-implementations.

If you compare frames of older/proprietary QinQ-implementations and the official 802.1AD, you will see that in most cases the only difference is the EtherType. Yes, there might be some implementations which a more different, but in my eyes, it would be definitively be a big benefit if FreeBSD would support more than only 0x88A8 as EtherType.

I used to know this stuff 10 years ago.... I thought proper support for QinQ was more complicated than just recognizing ether types. Also, why would a terminal FreeBSD device see QinQ?

Because FreeBSD is used as OS for OPNsense and pfsense. Two very powerful but easy to use and popular routing/firewall-distributions. And now you know why i am asking this ;-)
 
I am likely confusing 802.1ah (provider backbone bridge) with 802.1ad! Anyway, I'd hesitate to use a FreeBSD firewall in a QinQ set up!

[Edit] But don't let me demotivate you. You only have to convince a FreeBSD networking expert, not me! Make a clear case as to what exactly you want changed and who knows. Also, it may not be difficult for you to hack on the code in /sys/net. If you have proof of concept + test cases, it will definitely help your case.
 
Why? Would you use VLAN in FreeBSD? I am sure you would.

Whats so different between VLAN and QinQ?

I realy like how VLAN is working in opnsense. We have devices with over 40 VLANs on it.

QinQ is supported in opnsense since beginning of 2022, so i dont have experience with it yet. But i expect, that it will work like VLAN if we can solve the EtherType topic.
 
Back
Top