Comment 5 for bug 1915151

Hi Sean,

Yes, this RFE is exactly about use case as You described in comment #3 - so Neutron will control S-Tag, in similar way like it is now in vlan networks and user will be able to control C-Tag on their own in the VM.
So from VM PoV it will be single tagged packet but neutron will add another vlan id for it. That is use case which we currently have and wants to address :)

According to the Akihiro's question from last drivers meeting I did some comparison about how ethertypes looks currently in case of trunks and network with vlan_transparent=True.

- vlan_transparent = True, packet captured on the compute node looks like:

fa:16:3e:80:36:be > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 10, p 0, ethertype 802.1Q, vlan 100, p 0, ethertype ARP, Request who-has 192.168.100.92 tell 192.168.100.94, length 28

So double 802.1Q as ethertype.

- trunk

16:13:36.793004 fa:16:3e:90:ee:fd > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 10, p 0, ethertype 802.1Q, vlan 1500, p 0, ethertype ARP, Request who-has 192.168.50.223 tell 192.168.50.117, length 28

So again, 802.1Q as ethertype.

This is all based on the linuxbridge agent.
I then changed eth1.10 interface to be 0x8a88 like this RFE actually propose and packet looked like:

15:58:05.373213 fa:16:3e:80:36:be > ff:ff:ff:ff:ff:ff, ethertype 802.1Q-QinQ (0x88a8), length 50: vlan 10, p 0, ethertype 802.1Q, vlan 100, p 0, ethertype ARP, Request who-has 192.168.100.92 tell 192.168.100.94, length 28

As You can see, "outer" ethertype is 0x88a8 and "inner" ethertype is still 802.1Q.

And that is basically whole this RFE about. To be able to change this "outer" ethertype to QinQ.
Does it makes sense for You?