Neutron VLAN networks with QinQ support

Launchpad Bug: https://bugs.launchpad.net/neutron/+bug/1915151

Neutron supports networks with vlan transparency but in case where it is used with VLAN networks, there is no way to use it as QinQ which is different ethertype (e.g. 0x8a88) than regular vlan ethertype (0x8100).

Problem Description

Networks with enabled vlan transparency can be of any type available in Neutron (vxlan, vlan, flat, etc.). In most cases it is fine when packets sent from the node and have ethertype 0x8100 (802.1q). But in such case as we have 2 vlans already (S-Tag and C-Tag) there are some use cases where it should be sent as QinQ which is slightly different standard and have different ethertype (0x8a88) [1].

Proposed Change

Add new API extension to extend network resource in Neutron with qinq attribute. This new attribute would be valid only for vlan networks and in case of that networks would work similary to what current VLAN transparency extension [2]. The difference between vlan transparency and new qinq extensions would be in the ethertype configured for packets in such network send from the node. In case of qinq=True S-Tag and C-Tag will work in same way like it is now for the networks with enabled vlan transparency. C-Tag is configured directly in the instance by user and S-Tag is configured and controlled by Neutron. The difference will be that ethertype of the packets sent from the node will be 0x8a88. Attributes vlan_transparent and qinq will be mutually exclusive. Only one of them can be set to True for the network.

Server side changes

A new API extension of Neutron will be added with new attribute for the network resource. This new attribute will be called qinq:

RESOURCE_ATTRIBUTE_MAP = {
    network.COLLECTION_NAME: {
        "qinq": {
            'allow_post': True,
            'allow_put': False,
            'convert_to': converters.convert_to_boolean,
            'default': constants.ATTR_NOT_SPECIFIED,
            'is_visible': True,
            'is_filter': True
        }
    }
}

Note

Attribute qinq will have effect only for vlan networks.

Note

Attributes vlan_transparent and qinq would be mutually exclusive. Only one of them can be set to True.

Agent side changes

Currently linuxbridge, ovn and SR-IOV backends supports VLAN transparency and QinQ will be supported by the same backends. In case of linuxbridge and ovn backends correct ethertype will need to be set on the nodes so correct ethertype will be set for the packets. In case of the SR-IOV backend support for that feature will depend on the hardware and its driver and that will need to be tested separately.

DB Impact

Extend the networks table with boolean column qinq.

REST API Impact

None.

Client Impact

Relevant changes in osc and openstacksdk to add support for new network’s attribute. To enable it for network, it should be something like:

openstack network create --qinq

and to disable it:

openstack network create --no-qinq

Testing

  • Unit tests.

  • Fullstack test.

  • Tempest tests in neutron-tempest-plugin.

Assignee(s)

References