Understanding OpenStack Networking (Neutron) Components and It’s Concepts

As you all know I have started writing a series of blogs on components of OpenStack. In the last blog we learned about Compute (Nova) component of OpenStack in a blog: “Explanation of OpenStack Compute (nova) component”. So now today we will learn about Networking (Neutron) component of the OpenStack.

Before the introduction of Neutron, earlier there was a version called Quantum of the networking service. This Quantum service was used as one of the parts of the Folsom release of OpenStack. Initially, the Nova components’ networking was handled by Nova networking, which was an element of Nova. Then there was conflict in the trademark of Quantum; therefore its name was converted from Quantum to Neutron. Because the Quantum was a trademark name of tape-based backup system.

Thus if you require plain networking for your cloud, then you can use Neutron component also you can select Nova networking feature and can also completely neglect the Neutron networking service. But there is an advantage in selecting Neutron networking service, through which you can efficiently propose various services like a service called load balancing with the help of HA proxy and there is another service called VPN using openswan.

A component called “Neutron Server”, is present on the controller node of Neutron besides this, there are some group of agents and plugins which interact with each other with the help of a series of messages. Based on the kind of implementation, it is possible for you to select various agents as per your requirement.

Now a day Neutron includes few plugins but those are not restricted to NEC OpenFlow, Open vSwitch, Cisco switches, OpenDaylight plugin, PLUMgrid Director plugin, Midokura Midonet plugin, etc.

If possible you can opt for writing some more of these and each day the support is also extending therefore at the time of deploymenting it, your selected device dealer can offer you a Neutron plugin which can be useful to you.

Note:                            

If you want to check the improved list for different drivers and plugins then you can refer OpenStack wiki page.

Let’s learn about the architecture of Networking (Neutron) component of OpenStack:

Keep in mind that the architecture of Networking (Neutron) component o OpenStack is very simple, but it comes with different plugins and agents as mentioned earlier and this is where the actual magical things happen.

The following diagram represents the architecture of Neutron:

Let’s learn about the roles played by different components:

• The first component is the Neutron server:

It is formed by three different modules and the main role of this neutron server is to represent the complete environment of Neutron to the external world. The three modules of this component are as follows:

• REST service:

This service receives all the API requests from another component and discloses details of the entire internal working of ports, subnets, networks and stuff like that. REST service is basically a Web Server Gateway Interface application which is also known as WSGI application which is written down in Python and it utilizes port 9696 for the discussion.

• RPC service:

The role of RPC service is to converse with the messaging service and its task is to allow a two-way discussion.

• Plugin:

This module can be better explained as a set of Python modules which applies a common interaction that collects API calls and then attaches them to the subsequent devices. These plugins can be normal plugins or for the various classes of the devices they can apply different drivers.

The plugin module can be more over divided into core plugins that applies the basic Neutron API; it is a switching i.e. a Layer 2 networking and managing IP address. A plugin framework called Modular Layer 2 or in short ML 2 applies drivers and it can also carry out the same role throughout the Modular Layer 2 networking technology which is basically used in different datacenters. The ML2 plugin framework is used in installing process for working with Open vSwitch (OVS) as mentioned earlier.

The service plugin is a plugin which offers extra network services for example as mentioned earlier: – Load Balancing service, Firewall service and the stuff like that.

• The L2 agent:

This agent works on compute nodes component of OpenStack i.e. on the hypervisor and the main role of this agent is to connect new devices. In other words, we can say that this agent implements connections to the new servers in a suitable network section and it also enables notifications whenever any device is connected or disconnected. The OVS agent can be used here.

• The L3 agent:

These agents work on the network node and they are liable for IP forwarding, static routing and furthermore offers L3 features like DHCP.

Let’s try to understand the actual process of Neutron:

Following are the steps that take place at the Layer 2 stage when a new VM is booted by using Neutron:

1. First of all Boot VM start.
2. Then create a port and report the DHCP of this new port.
3. Then create a new device i.e. a virtualization library: libvirt.
4. Connect the VM to the new port.
5. Lastly, complete the boot.

Let’s learn about the concepts of networking (neutron):

The Networking (Neutron) component of OpenStack controls all the networking aspects required for the VNI which stands for Virtual Network Infrastructure and also controls the access layer features of the PNI which stand for Physical Networking Infrastructure, inside your OpenStack atmosphere. This component allows people to generate an advanced virtual network that may consist of various services like firewall, a load balancer, and VPN i.e. Virtual Private Network, etc.

As mentioned earlier this component offers networks, subnets, and routers as device extraction. Each of these extractions has tasks which imitate its correspondents like subnets or routers routing the traffic between various networks and subnets.

It is found that each networking neutron setup has a minimum one external network. This external network is not like other networks which are not just an implicitly defined network; rather it provides a perspective inside a physical and external network which can be accessed beside the OpenStack installation. Anybody can access the IP addresses present on the external networks physically through an outside network.

Further to external networks, all the other networking setups can have one or more than one internal networks. These networks attach directly to the VMs but the VMs only on any specific network or on subnet which is attached through interconnections to the same router can only access the VMs which are directly attached to that network.

Now remember that for accessing the VMs by the outside network and interchangeably, the routers are required between the networks. Each router is attached to an external network via one gateway and one or more than one subnets are connected to the internal networks. Similar to a physical router, a subnet can gain access to machines present on the other subnets which are attached to the similar router and also the machines can gain access to the outside networks via the gateway of that router.

Furthermore, you can assign IP addresses present on the external networks to the ports present on the internal networks. Every time something gets attached to a subnet, that attachment is known as a port. Thus you can attach IP addresses on the external networks with the ports on the VMs. Like this, the things present on the outside network can gain access to the VMs.

It is also found that Networking Neutron component of the OpenStack assists the security groups which allow the administrators to denote the rules for firewall in the groups. A VM can associate with one or more than one security groups and the Networking Neutron implements the rules to those security groups for blocking or unblocking ports or port ranges or different types of traffic for the required VM.

Every plugin in the specific Networking Neutron usage has its individual concepts. At the same time, it is not important for operating VNI and the atmosphere of the OpenStack, realizing these concepts will definitely help you while setting up a Networking. As discussed earlier, each and every Networking installations take the help of the core plugin and also of a security group plugin. Furthermore, we have seen a firewall as a service i.e. FWaas and Load Balancer as a service i.e. LBaas plugins are also accessible.

That’s it for today’s blog. I hope you find this information helpful. Please do not forget to leave a comment in the comment section below. See you soon with another blog on the components of OpenStack!

People also read-

• Concept of OpenStack: Complete Overview
• Smart way for entrepreneurs to choose the right hosting type.