[RFE] There should be a way to set ethertype for the vlan_transparent networks

Bug #1915151 reported by Slawek Kaplonski
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
New
Wishlist
Slawek Kaplonski

Bug Description

Networks with enabled vlan_transparency can be any of any type available in Neutron (vxlan, vlan, flat in case of Linuxbridge, etc.). In most cases it is fine when packets in such case have ethertype 0x8100 (802.1q).
The same ethertype is configured always for vlan network with vlan_transparent=True. But in such case as we have 2 vlans already (S-Tag and C-Tag) it is really QinQ. Neutron still configures ethertype to be 0x8100 in such case and it works for most of the cases.
But in case of some hardware it needs to be 0x8a88 (802.1ad) which is real QinQ type.

So I think that it would be good to add operators possibility to configure what ethertype will be used in such case.
It could be simple config option and all vlan networks with enabled vlan transparency would use it.
Default value of that option would be 0x8100 to be compatible with what we have now.

Revision history for this message
sean mooney (sean-k-mooney) wrote :

i dont really think is is valid.

vlan transparancy and QinQ transparnace are two different things
so really i think you should have two seperate extentions.

if you were to extend it to QinQ then vlan_transparent=qinq or vlan_transparent=0x8a88 might be valid

the current way that neutron extension are reported is also kind of problematic.

neutron currently reports all available extension not just enabled extensions so you cant as an end user determine if the cloud support an extension by look at the extension list.
you have to actually try to use it which can lead to very strange behaviour due to how the correct port create logic works. on in this case network create.

the response form the api is not guaranteed to match the value in the db depending on how the extension was implemented.

im not sure exposing the Ethernet type as something the operator set is really what we want to do. it really should be configured by the tenant. the operator might want a value to say which ones are allowed but i think it would be better for each ml2 driver to report what it supports and fail to bind ports to then network if it can fullfil that requirement.

it really sucks to get the failure that late but i think that the best approach we could do today.
if the operator has an api level config value like the allowed vnic_types to specify allowed Ethernet types you could reject it at the api level instead.

alternately if you have a separate qinq extension and you only report it if the extension driver is listed then operators can control enabling it via the extension driver config option in the ml2_conf.ini and end-user can detect it by looking at the extension list. this also allows individual ml2 drivers to opt into support.

i think ^ is a much better approach as all the other approach that extend the existing extension are config driver api behaviour that causes interoperate issues between clouds.

e.g. how would you detect if two cloud both support QinQ if you extend the vlan transparency extension instead of adding a new QinQ transparency extension. as an end user you cannot.

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Thx Sean for Your input,

I agree that qinq is really different thing than vlan transparency.
So IIUC Your proposal is to do new extension which will be similar to vlan_transparency and will work only for vlan networks. So user can then do something like:

neutron net-create qinq-network --qinq True

And in such case ethtype for such network would be 0x8a88 instead of 0x8100 and user would be able to control directly in VM C-Tag. S-Tag would be still controlled by Neutron, as it is now for vlan networks.
If my understanding is correct, I like that solution :) We can move in that direction IMO.

Revision history for this message
sean mooney (sean-k-mooney) wrote :

yep exactly add a new extension for qinq
i don't know if you want to also allow the user to control the s-tag if they requested both?

im not sure if the use case is for the tenant to be able to send fully encapulated qinq packets where they have contoler of both or just to use QinQ as an overly.

there have been seperate proposal for added a QinQ segmenation type in the past which to me was a different usecase. in the qinq segmenation type it was a way to have neutron contol both the S-tag and C-tag so that you increase teh number of network you could support on a phsynet without needing to use l3 tunnel encapsulation.

my understanding of the vlan_transparent extenion is that vlan transparent network allow user to send singly tagged vlan packets. transitivly i would have infered a qinq_transparent network would have allowed tenants to send double tagged packets contoling both the S and C tags.
neutron would then have layered another level of encaplolation over that for tenant isolation based on the segmentation type of the neutron network.

does that make sense?

having neutron conrtol the S-tag basically shoudl very similar to the current vlan-aware-vms feature aka trunk ports so for me i think it add much less value then instead allowing the tenatn to set both tags.

Revision history for this message
sean mooney (sean-k-mooney) wrote :

by the way both are valid e.g. tenant control of S-tag or neutron contol. it just depend on the usecase you wanted to enable. i dont really object to either approch although i would probly lean towards tenat contol to make this feature sufficently different form the exsiting vlan transparend networks and vlan aware vms features.

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

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?

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

On our last drivers meeting we discussed that RFE: http://eavesdrop.openstack.org/meetings/neutron_drivers/2021/neutron_drivers.2021-02-19-14.00.log.html#l-15 and we decided to approve it.

tags: added: rfe-approved
removed: rfe-triaged
Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Ohh, I forgot to mention. Next step is to propose spec for it.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron-specs (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-specs/+/798704

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron-specs (master)

Reviewed: https://review.opendev.org/c/openstack/neutron-specs/+/798704
Committed: https://opendev.org/openstack/neutron-specs/commit/40f6c1663d045fbb23dcb64f4fc0227f6f063dd4
Submitter: "Zuul (22348)"
Branch: master

commit 40f6c1663d045fbb23dcb64f4fc0227f6f063dd4
Author: Slawek Kaplonski <email address hidden>
Date: Tue Jun 29 17:46:46 2021 +0200

    Neutron VLAN networks with QinQ enabled

    Related-Bug: #1915151
    Change-Id: I4ebac838df82a64a5a6f2c773d69050ade5668ce

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers