In this post, we are going take a quick look at how OpenStack does networking, along the process we are going to mention the important agents involved.

What is a layer 2 network?

It is a network that does require any routing hops (e.g., traffic in the same subnet).

What is Nova-Network?                                                                                                 

It is the primitive way of doing networking in OpenStack.  It does the following:

What are Nova-network Models? Capture

Problems in Nova-Networking?

From precious posts it is about SDN it is highlighted that Abstraction is a key element for a Software-Defined technology, and it is clear that Nova-network is not doing that abstraction very well, we need something else clearly…. Neutron to the rescue.

What is Neutron?

Neutron is an API wrapper. It basically receives commands / calls to perform traditional networking and relay it to the network plugin of choice (e.g. NSX). With this, abstraction is achieved.

What are the main components of Neutron?

Neutron runs along-side a controller node on what is referred to as the network node.  On the network node, the following services are running:


Basically, the OVS plugin communicates with the OVS-agent which in turn configures the flows and tunnles on the underlying bridges. The ovs-agents are installed on all the nodes (compute and network). When the traffic is forwarded it gets tunneled in the bridge through the configuration applied to by the OVS agent.

Note: This is not a completely software-defined pattern as we still have the control-plane coupled in our virtual network. By adding a controller we could better comply with the software-defined pattern (will address that in a different post).

Nova Meta-data service

A Metadata services provides important information to the guest instance for correct communication, these include:

In previous versions of Neutron (e.g., Folsom), the dhcp-agent used to provide a static routing option to add static routes to “” (i.e., dhcp-agent host), IPtables on the dhcp-agent hosts then NATs the request either to the local met-data server or to a meta-data services which is remotely installed. This method however has no support for overlapping IPs in different projects / Tenants.


In later versions of OpenStack (e.g., Grizzly, Havana, Icehouse, Juno, etc.) the problem was solved by dedicating two services (quantum-ns-metadata-proxy and quantum-metadata-proxy). Meta-data requests are then forwarded by the N-L3-Agent to the quantum-ns-metadata-proxy in the tenant namespace and then forwards it to the quantum-metadata-proxy service via a dedicated internal socket, and adding two headers that identifies the tenant namespace (X-Forward-For and X-Quantum-Router-ID) and this solving the overlapping IP problem previously existed. Since the metadata-proxy is the only service that can reach to the management network, it will be used to forward the request to the nova-metadata which could be installed on one of the nodes in the management network.



In this post we reviewed nova-networking (deprecated) that was used before neutron, we also highlighted the problems that led to the development of Neutron. With Neutron, many extra functionalities were added (e.g., tunneling and improved multi-tenancy through the usage of IDs and headers), it should be noted that we did not address all the aspects of Neutron only those of major importance. In future writings, we will be tackling deeper topics and we will be looking more into the other components of OpenStack.