Tackle OpenStack networking woes with SUSE OpenStack Cloud Crowbar


By far, the most difficult aspect of successfully deploying OpenStack is getting the networking right, a challenge that has caused many a well-intentioned IT team to throw up its hands and toss in the towel. Fortunately, SUSE OpenStack Cloud removes much of that pain by automating most of the network deployment and dramatically simplifying custom network set-ups.

So many networks, so little time

Much of the complexity in OpenStack networking revolves around the need to segregate traffic for optimal performance. SUSE OpenStack Cloud Crowbar tackles this by creating eight separate networks, all defined in the /etc/crowbar/network.json file that describes everything so Chef can automate the deployments.

It starts by creating an admin node and network, which it uses to communicate with each worker node in the cluster. By default, the Crowbar installation sets the admin network to a Class C (/24 or, and all but one of the other eight networks are similarly limited. If you don’t change them, the size of your cluster will therefore be limited by the number of addresses available on the subnets you define. For example, a /24 will place a hard limit at about 250 nodes. As you plan your deployment, keep these limits in mind; it is extremely painful to change network settings after you deploy with Crowbar.

Out of the box, Crowbar creates the following networks, viewed here from the YaST tool, and provides some handy default IP ranges for each. Here are the key networks:

admin ( – A private network used by the Crowbar admin node for all communication among Compute, Controller, Storage and all other nodes. PXE booting is done on this network, too.

nova_fixed ( – A private network reserved for compute-related traffic. This network is used internally to give your OpenStack instances IP addresses.

nova_floating ( – A public network that can be reached from outside your OpenStack cluster. These IPs are used to assign floating IPs to your OpenStack instances so they can be reached from the outside world.

os_sdn ( – A private network OpenStack can use for Generic Routing Encapsulation (GRE) or Virtual Extensible LAN (VXLAN)  traffic.

public ( – A public network, which can be used to access your OpenStack cluster externally. Nodes also use this to communicate with the outside world, so you should provide an external router on this network.

storage ( – A private network OpenStack uses for storing images, volumes and instance data (block, file or object) if you’re not using external storage like Ceph.

bastion – A network you can configure to give yourself access to the SUSE OpenStack Cloud Crowbar admin server. This doesn’t show up in the main network view above, but it’s set in Network Mode (via YaST) or in /etc/crowbar/network.json.

Note that I’ve added an external network, too, ( and given it a VLAN ID of 10. In your configuration, this external network might represent a preexisting subnet unique to your environment.

For this example, I added the following to /etc/crowbar/network.json to define the “external” network, which I’ll use for my SUSE Enterprise Storage cluster:

       "external": {
          "add_bridge": false,
          "vlan": 10,
          "broadcast": "",
          "netmask": "",
          "conduit": "intf1",
          "subnet": "",
          "use_vlan": true,
          "router": "",
          "ranges": {
            "host": {
              "start": "",
              "end": ""

Here, I’ve defined the network, given it a VLAN tag and designated the IP ranges. Of course, you can define multiple external networks (given they each have unique names) and create configurations that match your needs and existing network. Assigning a VLAN isn’t strictly required, but I’ve added it because this example deployment uses just a single NIC. I also have everything connected to a switch that supports Layer 3 (802.1q) networking.

Since Crowbar handles all the network configurations for your OpenStack cluster, you need to make edits to your /etc/crowbar/network.json file before you deploy. That way, the networks are available and can be assigned to any node you want later.

Keep in mind that any manual network configurations on your admin node (and elsewhere) will be overwritten once Crowbar deploys, so it’s important to take the time to make sure you define your subnets, VLANs and other network topology before running systemctl start crowbar-init and crowbarctl database create.

Finalizing external networks

By itself, SUSE OpenStack Cloud Crowbar won’t automatically assign your custom networks to nodes, but the built-in Chef automation tooling will do it for you with a few simple commands issued on the admin node.

After your nodes are up and running and you’ve applied roles to them with Barclamps, you can use the following commands to assign your networks (including your custom ones like “external”) to your nodes:

First, you can assign the external network to the Admin node:

admin># crowbar network allocate_ip default `hostname -f` external host

Then, add an IP from the external network on the hosts that need them with crowbar network allocate_ip default <hostname> <network> host:

admin># crowbar network allocate_ip default d2a-a8-dc-88-fa-83 external host

Finally, run chef-client to apply the changes:

admin># chef-client

Here, “external” defines the network I want on all nodes. This will apply the configuration to all nodes that have the DNS and NTP Barclamp applied, and give them a address in the range I defined.

When I later use the script that automates integration with SUSE Enterprise Storage, that process will generate the necessary keys and addresses I need to complete the OpenStack integration on my external network. See my previous blog post about that here: https://www.suse.com/c/want-to-quickly-connect-openstack-and-ceph-suse-openstack-cloud-has-you-covered.



(Visited 1 times, 1 visits today)

Leave a Reply

Your email address will not be published. Required fields are marked *

No comments yet

John S. Tonello
John S. Tonello

John S. Tonello is SUSE’s Global Technical Marketing Manager responsible for helping you understand software-defined infrastructure. You can follow him @johntonello.