Introduction
The OpenStack Networking service provides an API that allows users to set up and define network connectivity and addressing in the cloud. OpenStack supports three modes of networking in the current Grizzly release. These are Flat networking, VLAN Manager, and the very latest, Software Defined Networking (SDN). Software Defined Networking is an approach to networking in which Network Administrators and Cloud Operators can programmatically define virtual network services. The Software Defined Network component of OpenStack Networking is called Neutron. This project code name is widely used in the OpenStack community to describe the SDN mode of OpenStack Networking and was previously known as Quantum but due to copyright reasons, the codename Quantum had to be replaced. As a result, this project is now known as Neutron. At present, during the Grizzly release, the paths and service names still refer to Quantum but will change in future releases.

With SDN, we can describe complex networks in a secure multi-tenant environment that overcomes the issues often associated with the Flat and VLAN OpenStack networks. For Flat networks, as the name describes, all tenants live within the same IP subnet regardless of tenancy. VLAN networking overcomes this by separating the tenant IP ranges with a VLAN ID, but VLANs are limited to 4096 IDs, which is a problem for larger installations, and the user is still limited to a single IP range within their tenant to run their applications. With both these modes, ultimate separation of services is achieved through effective Security Group rules.

SDN in OpenStack is also a pluggable architecture, which means we are able to plug-in and control various switches, firewalls, load balancers and achieve various functions as Firewall as a Service—all defined in software to give you the fine grain control over your complete cloud infrastructure.

VLAN Manager is the default in OpenStack and allows for a multi-tenant environment where each of those separate tenants is assigned an IP address range and VLAN tag that ensures project separation. In Flat networking mode, isolation between tenants is done at the Security Group level.

To gain in-depth knowledge and be on par with practical experience, then explore OpenStack Training course.
Configuring Flat networking with DHCP
In Flat networking with DHCP, the IP addresses for our instances are assigned from a running DHCP service on the OpenStack Compute host. This service is provided by dnsmasq. As with Flat networking, a bridge must be configured manually in order for this to function.

Getting ready
To begin with, ensure you’re logged into the controller. If this was created using Vagrant we can access this using the following command:

vagrant ssh controller
If you are using the controller host created in Starting Openstack Compute, we will have three interfaces in our virtual instance:

eth0 is a NAT to the host running VirtualBox
eth1 is our floating (public) network (172.16.0.0/16)
eth2 is our fixed (private) network (10.0.0.0/
In a physical production environment, that first interface wouldn’t be present, and references to this NATed eth0 in the following section can be ignored.

How to do it…
To configure our OpenStack environment to use Flat networking with DHCP, carry out the following steps:

OpenStack requires bridging in order for any of the network modes to work. The bridge tools are installed as dependencies when installing the OpenStack nova-network package, but if they aren’t installed you can issue the following commands:


We first need to configure our network bridge (br100) by editing /etc/network/interfaces, as follows:



We then restart our network service to pick up the changes, as follows:
sudo /etc/init.d/networking restart
We now configure OpenStack Compute to use the new bridged interface as part of our Flat network. Add the following lines to /etc/nova/nova.conf:



Restart the required Openstack Compute Services, to pick up the changes:
sudo restart nova-compute sudo restart nova-network
In order to separate private ranges per project (tenant), we get the ID of our tenant, that we will use when creating the network. On a client machine with the keystone client installed, run the following command:

Do you know of any openstack deployment in Nigeria? I am curious to know if and how openstack is being used in this country.

Lianamelissa:
Introduction
The OpenStack Networking service provides an API that allows users to set up and define network connectivity and addressing in the cloud. OpenStack supports three modes of networking in the current Grizzly release. These are Flat networking, VLAN Manager, and the very latest, Software Defined Networking (SDN). Software Defined Networking is an approach to networking in which Network Administrators and Cloud Operators can programmatically define virtual network services. The Software Defined Network component of OpenStack Networking is called Neutron. This project code name is widely used in the OpenStack community to describe the SDN mode of OpenStack Networking and was previously known as Quantum but due to copyright reasons, the codename Quantum had to be replaced. As a result, this project is now known as Neutron. At present, during the Grizzly release, the paths and service names still refer to Quantum but will change in future releases.

With SDN, we can describe complex networks in a secure multi-tenant environment that overcomes the issues often associated with the Flat and VLAN OpenStack networks. For Flat networks, as the name describes, all tenants live within the same IP subnet regardless of tenancy. VLAN networking overcomes this by separating the tenant IP ranges with a VLAN ID, but VLANs are limited to 4096 IDs, which is a problem for larger installations, and the user is still limited to a single IP range within their tenant to run their applications. With both these modes, ultimate separation of services is achieved through effective Security Group rules.

SDN in OpenStack is also a pluggable architecture, which means we are able to plug-in and control various switches, firewalls, load balancers and achieve various functions as Firewall as a Service—all defined in software to give you the fine grain control over your complete cloud infrastructure.

VLAN Manager is the default in OpenStack and allows for a multi-tenant environment where each of those separate tenants is assigned an IP address range and VLAN tag that ensures project separation. In Flat networking mode, isolation between tenants is done at the Security Group level.

To gain in-depth knowledge and be on par with practical experience, then explore OpenStack Training course.
Configuring Flat networking with DHCP
In Flat networking with DHCP, the IP addresses for our instances are assigned from a running DHCP service on the OpenStack Compute host. This service is provided by dnsmasq. As with Flat networking, a bridge must be configured manually in order for this to function.

Getting ready
To begin with, ensure you’re logged into the controller. If this was created using Vagrant we can access this using the following command:

vagrant ssh controller
If you are using the controller host created in Starting Openstack Compute, we will have three interfaces in our virtual instance:

eth0 is a NAT to the host running VirtualBox
eth1 is our floating (public) network (172.16.0.0/16)
eth2 is our fixed (private) network (10.0.0.0/
In a physical production environment, that first interface wouldn’t be present, and references to this NATed eth0 in the following section can be ignored.

How to do it…
To configure our OpenStack environment to use Flat networking with DHCP, carry out the following steps:

OpenStack requires bridging in order for any of the network modes to work. The bridge tools are installed as dependencies when installing the OpenStack nova-network package, but if they aren’t installed you can issue the following commands:


We first need to configure our network bridge (br100) by editing /etc/network/interfaces, as follows:



We then restart our network service to pick up the changes, as follows:
sudo /etc/init.d/networking restart
We now configure OpenStack Compute to use the new bridged interface as part of our Flat network. Add the following lines to /etc/nova/nova.conf:



Restart the required Openstack Compute Services, to pick up the changes:
sudo restart nova-compute sudo restart nova-network
In order to separate private ranges per project (tenant), we get the ID of our tenant, that we will use when creating the network. On a client machine with the keystone client installed, run the following command: