Due to an unfortunate incident involving sleep mode and an overheated backpack I had the “opportunity” to rebuild my laptop. Since this meant reinstalling OpenStack I used this as an excuse to finally move to the ML2 network plugin for Neutron. I was attempting to add an external network using the normal incantation: neutron net-create external – –router:external=true \ –provider:network_type=flat \ –provider:physical_network=physnet1 While this command completed successfully, I was left without any connectivity between br-int and br-ex, despite having in my /etc/neutron/plugins/ml2/ml2_conf.

I’ve put together a few tools to help gather information about your Neutron and network configuration and visualize it in different ways. All of these tools are available as part of my neutron-diag repository on GitHub. In this post I’m going to look at a tool that will help you visualize the connectivity of network devices on your system. mk-network-dot There are a lot of devices involved in your Neutron network configuration.

Heat is a template-based orchestration mechanism for use with OpenStack. With Heat, you can deploy collections of resources – networks, servers, storage, and more – all from a single, parameterized template. In this article I will introduce Heat templates and the heat command line client. Writing templates Because Heat began life as an analog of AWS CloudFormation, it supports the template formats used by the CloudFormation (CFN) tools. It also supports its own native template format, called HOT (“Heat Orchestration Templates”).

The documentation for configuring Neutron recommends that a network controller has three physical interfaces: Before you start, set up a machine to be a dedicated network node. Dedicated network nodes should have the following NICs: the management NIC (called MGMT_INTERFACE), the data NIC (called DATA_INTERFACE), and the external NIC (called EXTERNAL_INTERFACE). People occasionally ask, “why three interfaces? What if I only have two?”, so I wanted to provide an extended answer that might help people understand what the interfaces are for and what trade-offs are involved in using fewer interfaces.