Vlan network with vlan_id outside of available ranges for physical network can be created always

[Slawek Kaplonski]

When creating provider networks of type vlan with openstack or neutron api(s) one can specify a vlan ID or provider segment which exceeds the range as set network_vlan_ranges parameter in the ml2 configuration.

Here are some examples from the lab:

+++
[root@overcloud-ctrleaf0-0 ~]# egrep -v '^$|^#' /var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/openvswitch_agent.ini
[ovs]
bridge_mappings=datacentre:br-ex << bridge_mappings; physical network name is datacentre
integration_bridge=br-int
tunnel_bridge=br-tun
local_ip=172.25.1.10
[agent]
l2_population=False
arp_responder=False
enable_distributed_routing=False
drop_flows_on_start=False
extensions=qos
tunnel_csum=False
tunnel_types=vxlan
vxlan_udp_port=4789
[securitygroup]
firewall_driver=iptables_hybrid
+++

+++
 egrep -v '^$|^#' /var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/ml2_conf.ini
[DEFAULT]
[l2pop]
[ml2]
type_drivers=vxlan,vlan,flat,gre
tenant_network_types=vxlan,vlan
mechanism_drivers=openvswitch
extension_drivers=qos,port_security
path_mtu=0
overlay_ip_version=4
[ml2_type_flat]
flat_networks=datacentre
[ml2_type_geneve]
[ml2_type_gre]
tunnel_id_ranges=1:4094
[ml2_type_vlan]
network_vlan_ranges=datacentre:1:1000 << network_vlan_ranges says that datacentre physcial network should allow vlans 1-1000
[ml2_type_vxlan]
vni_ranges=1:4094
vxlan_group=224.0.0.1
[securitygroup]
firewall_driver=iptables_hybrid
+++

Yet one can specify vlan ID(s) like 1500 or 2000 which are far beyond the range set in the configuration:

(overcloud) [stack@undercloud13-leaf-0 ~]$ openstack network create --provider-network-type vlan --provider-physical-network datacentre --provider-segment 2000 ext_net_epsilon
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | |
| availability_zones | |
| created_at | 2019-08-28T08:43:06Z |
| description | |
| dns_domain | None |
| id | 7153c256-2014-4d4a-a9c3-cd7ba5907819 |
| ipv4_address_scope | None |
| ipv6_address_scope | None |
| is_default | False |
| is_vlan_transparent | None |
| mtu | 1500 |
| name | ext_net_epsilon |
| port_security_enabled | True |
| project_id | e965ba459d574bd09ec59e513b8255ba |
| provider:network_type | vlan |
| provider:physical_network | datacentre |
| provider:segmentation_id | 2000 |
| qos_policy_id | None |
| revision_number | 3 |
| router:external | Internal |
| segments | None |
| shared | False |
| status | ACTIVE |
| subnets | |
| tags | |
| updated_at | 2019-08-28T08:43:08Z |
+---------------------------+--------------------------------------+

(overcloud) [stack@undercloud13-leaf-0 ~]$ neutron net-create ext_net_alpha --provider:network_type vlan --provider:segmentation_id 1500 --provider:physical_network datacentre
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Created a new network:
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| availability_zone_hints | |
| availability_zones | |
| created_at | 2019-08-28T08:38:34Z |
| description | |
| id | 0c868950-3183-4c85-a678-f02550e23f0b |
| ipv4_address_scope | |
| ipv6_address_scope | |
| is_default | False |
| l2_adjacency | True |
| mtu | 1500 |
| name | ext_net_alpha |
| port_security_enabled | True |
| project_id | e965ba459d574bd09ec59e513b8255ba |
| provider:network_type | vlan |
| provider:physical_network | datacentre |
| provider:segmentation_id | 1500 |
| qos_policy_id | |
| revision_number | 3 |
| router:external | False |
| shared | False |
| status | ACTIVE |
| subnets | |
| tags | |
| tenant_id | e965ba459d574bd09ec59e513b8255ba |
| updated_at | 2019-08-28T08:38:34Z |
+---------------------------+--------------------------------------+

So basically there is no validation check to ensure that the segmentation ID that is being provided to the command line client is within the bounds specified by the config.

It happens becasue in https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/type_vlan.py#L245 to validate segmentation_id is always used function from neutron-lib (https://opendev.org/openstack/neutron-lib/src/branch/master/neutron_lib/plugins/utils.py#L49) and this function always checks only if vlan tag is between 1 and 4094.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/679425

[James Denton (james-denton)]

My understanding was always that network_vlan_ranges would apply to vlans that could be allocated by Neutron when tenant_network_type == vlan. As a provider, I don’t want to have to update the Neutron configuration when I create a new provider network to ensure that segmentation ID is in the list, nor do I want to have to worry about the ID potentially being auto-allocated to a tenant. Perhaps that wasn’t the intended design, but it is expected behavior since Havana. Thoughts?

[Slawek Kaplonski (slaweq)]

@James: so according to what You are saying, it's more like documentation issue probably than real bug.
But I don't have so much "historical" background on this so maybe Brian or Miguel can take a look and check how it should works than.

[Donny Davis (donny-g)]

@James I do believe you are correct. That range is for tenant networks. Provider / cloud admins can do what they want by design.

[Miguel Lavalle (minsel)]

This is not a bug. Please read carefully the doc string for the network_vlan_ranges config option: https://github.com/openstack/neutron/blob/78aae12a88e8b3cc0609c830527533b8a8a92d60/neutron/conf/plugins/ml2/drivers/driver_type.py#L71-L77. In particular, please note the last part of that doc string: "as well as ranges of VLAN tags on each available for allocation to tenant networks." Furthermore, please look in the same module at the doc strings of range config options for other network types (gre, vxlan, geneve). They always indicate that the ranges configured are "available for tenant network allocation".

Our docs state the same: https://docs.openstack.org/neutron/latest/admin/config-ml2.html#project-network-types.

Finally it has been like this since the first ML2 commit from the Quantum days: https://review.opendev.org/#/c/20105/9/quantum/plugins/ml2/drivers/type_vlan.py@40

As a consequence, I am marking this bug as invalid

[OpenStack Infra (hudson-openstack)]

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.opendev.org/679425
Reason: It's working as it was designed so no need to change anything :)

[Slawek Kaplonski (slaweq)]

Thx James and Miguel for Your comments. I abandoned my patch now. It is indeed not a bug :)