SUSE Cloud: How to limit the range of dynamically allocated VLANs

This article refers to the SUSE Cloud 5 documentation. The Deployment Guide recommends to stick with the defaults when you want to deploy a cloud infrastructure. But how do you integrate a new cloud into an existing infrastructure, especially if you have to limit the VLAN ranges used by the cloud?

Background

Our cloud environment consists of three nodes, all of them running on SLES11-SP3. After all nodes are installed and configured, you want to deploy the services. Following the documentation, I deployed all services with the default settings except neutron. You have to choose the right settings corresponding to your network configuration in the production network. So I modified the barclamp in the section “Networking Plugin” to use the ml2-plugin and “linuxbridge” as “Modular Layer 2 mechanism drivers” which supports VLANs only (which is what I need). I didn’t touch the “Maximum number of VLANs” of 2000, no need to modify that, I thought.
In the network.json I defined the cloud networks to use custom VLAN-IDs and added one external network, resulting in this network configuration:

Possible problems

But you should be aware of the impact this “Maximum number of VLANs” has on your cloud network. As long as I only created VMs in the existing networks, I had no problems. The VM was created in the network “nova_fixed”, got an IP and could be associated with a floating IP, so far so good.
But when I created a new network within the cloud and started an instance in this network, the VMs eth0 had no IP assigned and therefore it couldn’t be accessed via SSH. The reason was simple: the cloud created a new VLAN with an undefined ID in our network, the output of brctl show shows the new VLAN116:

root@d0c-c4-7a-06-71-f0:~ # brctl show
 bridge name     bridge id               STP enabled     interfaces
 brq414c4cfb-82          8000.0cc47a0671f0       no              bond0.116
                                                         tap25790be5-40
 brqfc276b86-ff          8000.0cc47a0671f0       no              bond0.115
                                                         tap32ec3a1e-53
                                                         tapa62d16e3-8e
                                                         tapf0d2a64b-8c

The VLAN-ID 116 was not considered in our network.json or on our physical switch, so the question was: how does the cloud choose the VLAN-ID? So I searched the web and found several posts on how to change the vlan range and edited the file /etc/neutron/plugins/ml2/ml2_conf.ini on control node which contains this part:

[ml2_type_vlan]
# network_vlan_ranges =
# Example: network_vlan_ranges = physnet1:1000:2999,physnet2
network_vlan_ranges = physnet1:115:2114

So I edited the range and re-deployed neutron, but the changes were overwritten by chef. This was obviously not the right spot to look at. I kept searching and found an interesting paragraph in http://robhirschfeld.com/2013/10/16/openstack-neutron-using-linux-bridges-technical-explanation/:

Note that this parameter is set by the Crowbar Neutron chef recipe.  The VLAN range is configured to start at whatever the “vlan” attribute in the nova_fixed network in the bc-template-network.json is set to.  The VLAN range end is hard coded to end at the VLAN start plus 2000.

I looked up the /opt/dell/chef/cookbooks/neutron/recipes/server.rb and found this piece of code:

vlan_start = node[:network][:networks][:nova_fixed][:vlan]
num_vlans = node[:neutron][:num_vlans]
vlan_end = [vlan_start + num_vlans - 1, 4094].min

This explains the defined range from 115 to 2014. Our nova_fixed-ID is 115, num_vlans is 2000 as default:

115 + 2000 - 1 = 2014

Solution

Obviously, that’s the right spot! But how do you change these settings without changing the code? Of course, the “Maximum number of VLANs” (or num_vlans)! I went back to the crowbar ui and edited the value for num_vlans in the neutron barclamp to 65

num_vlans

and got the correct range in the ml2.conf.ini file:

[ml2_type_vlan]
# network_vlan_ranges =
# Example: network_vlan_ranges = physnet1:1000:2999,physnet2
network_vlan_ranges = physnet1:115:179

To test this new configuration, our network admin created a new vlan range and configured the switch ports corresponding to this range. It worked! Every newly created network is associated to a VLAN from our defined range.

At this point I have to comment on the statement in the blog mentioned above:

Networks are assigned the next available VLAN tag as they are created.  For instance, the first manually created network will be assigned VLAN 501, the next VLAN 502, etc.

When I tested the custom vlan range from 115 to 179 and created a new network, I observed an interesting behavior: not the first available VLAN116 was assigned to it but the last available VLAN179 . Although I have to admit that I have not been able to reproduce that, all my recent attempts confirm that statement, but I wanted to share this anyway.