OpenStack Networking: Tutorial and Course

OpenStack Networking

• OpenStack Networking: Overview
• OpenStack Networking: Facts and Information
• OpenStack Networking: Tutorial and Course
• OpenStack Networking: References

OpenStack Networking: Overview

Tutorial and Course for OpenStack Networking is the ultimate SEO tutorial and course created by SEO University to help you to learn and understand OpenStack Networking and other related technologies.

OpenStack Networking: Facts and Information

OpenStack supports three modes of networking in the current Essex release. These are Flat networking, Flat networking with DHCP, and VLAN Manager. The latter, 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 the Flat networking modes, isolation between tenants is done at the Security Group level. In all of the available modes, OpenStack presents two networks associated with an instance: a private address range and a public address range. The private address, also referred to as the fixed IP address, is the address an instance gets assigned for the lifetime of that instance. The public address, also referred to as the floating IP address, is an address an instance gets that makes that instance available to the public, (or in many private cloud installations, routed to the rest of your network). This public (floating) address can be associated with or disassociated from an instance at any time, meaning that you can assign any particular IP on your public (floating) range to any instance. Network Address Translation (NAT) handles the communication flow of traffic to and from the instances, as it traverses the public and private network spaces.

OpenStack Networking: Tutorial and Course

OpenStack Networking: Configuring Flat Networking

In Flat networking, the IP addresses for our instances are injected from a defined subnet of IP addresses at launch. To make this work, a network bridge is configured the same on each compute and network host in our cloud environment.

Only Linux distributions that keep their network information under /etc/network/interfaces support Flat networking.

To begin with, ensure you're logged into the OpenStack API server.

If using the openstack1 host, 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/8)

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.

To configure our OpenStack environment to use Flat networking, carry out the following steps:

1. 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:

 sudo apt-get update sudo apt-get -y install bridge-utils 

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

 # The primary network interface auto eth0 iface eth0 inet dhcp # eth1 public auto eth1 iface eth1 inet static address 172.16.0.1 netmask 255.255.0.0 network 172.16.0.0 broadcast 172.16.255.255 # eth2 private auto br100 iface br100 inet manual bridge_ports eth2 bridge_stp off bridge_maxwait 0 bridge_fd 0 up ifconfig eth2 up 

3. We then restart our network service to pick up the changes, as follows:

 sudo /etc/init.d/networking restart 

4. 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:

 --network_manager=nova.network.manager.FlatManager --flat_network_bridge=br100 --flat_interface=eth2 --public_interface=eth1 

5. Restart the required OpenStack Compute services to pick up the changes:

 sudo restart nova-compute sudo restart nova-network 

6. We now create a private (fixed) network that OpenStack Compute can use, as follows:

 sudo nova-manage network create --fixed_range_v4=10.0.1.0/24 --label flat --bridge br100 

7. With this in place, we now have a bridge from our eth2 interface and our internal network assigned to our instances. To ensure this works in a multi-network device host, run the following command to enable IP forwarding:

 sudo sysctl -w net.ipv4.ip_forward=1 

8. We can now create our floating public range, which we will use to connect to our running instances, as follows:

 sudo nova-manage floating create --ip_range=172.16.1.0/24 

9. When an instance spawns now, an address is injected from our address space into our instance. We can then access this, as before, by assigning a public floating IP to this instance, which associates this IP address with our instance's private IP address.

FlatManager networking is useful for small proof-of-concept environments. They only work for Linux systems that support networking set in /etc/network/interfaces and are limited to a single network and project.

In order to make FlatManager work, we must manually configure our hosts with the same bridging, which is set to br100, as specified in /etc/nova/nova.conf:

 --flat_network_bridge=br100 

When our instance spawns, it will be given an address in the range that we have specified: 10.0.1.0 - 10.0.1.254, which we specified with the following command:

 nova-manage network create --fixed_range_v4=ip_range --label label --bridge bridge 

Note that we also don't assign an IP address to the interface that acts as our bridge—in our case, eth2.

OpenStack Networking: 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.

To begin with, ensure you're logged in to the OpenStack API server.

If using the openstack1 host, 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/8)

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.

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

1. 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:

 sudo apt-get update sudo apt-get -y install bridge-utils 

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

 # The primary network interface auto eth0 iface eth0 inet dhcp # eth1 public auto eth1 iface eth1 inet static address 172.16.0.1 netmask 255.255.0.0 network 172.16.0.0 broadcast 172.16.255.255 # eth2 private auto br100 iface br100 inet manual bridge_ports eth2 bridge_stp off bridge_maxwait 0 bridge_fd 0 up ifconfig eth2 up 

3. We then restart our network service to pick up the changes, as follows:

 sudo /etc/init.d/networking restart 

4. 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:

 --dhcpbridge_flagfile=/etc/nova/nova.conf --dhcpbridge=/usr/bin/nova-dhcpbridge --network_manager=nova.network.manager.FlatDHCPManager --flat_network_dhcp_start=10.0.1.2 --flat_network_bridge=br100 --flat_interface=eth2 --flat_injected=False --public_interface=eth1 

5. Restart the required OpenStack Compute services, to pick up the changes:

 sudo restart nova-compute sudo restart nova-network 

6. 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:

 keystone tenant-list 

7. We now create a private (fixed) network—that OpenStack Compute can use—for that particular tenant, as follows:

 sudo nova-manage network create --fixed_range_v4=10.0.1.0/24 --label cookbook --bridge 

8. We can now create our floating public range that we will use to connect to our running instances. We do this as follows:

 sudo nova-manage floating create --ip_range=172.16.1.0/24 

9. With this in place, we now have a bridge from our eth2 network and our internal network assigned to our instances. To ensure this works in a multi-network device host, run the following command to enable IP forwarding:

 sudo sysctl -w net.ipv4.ip_forward=1 

10. When an instance spawns now, a private address is injected from our fixed address range into our instance. We then access this as before, by assigning a public floating IP to this instance, which associates this floating IP address with our instance's fixed IP address.

FlatDHCPManager networking is a common option for networking, as it provides a flat network that is only limited by the IP address range assigned. It doesn't require a Linux operating system and the /etc/network/interfaces file in order to operate correctly through the use of standard DHCP for assigning addresses.

In order to make FlatDHCPManager work, we manually configure our hosts with the same bridging, which is set to br100, as specified in /etc/nova/nova.conf:

 --flat_network_bridge=br100 

Once set up, we configure our network range, where we can specify in our /etc/nova/nova.conf configuration file the start of this range that our instances get when they start:

 --flat_network_dhcp_start=10.0.1.2 

When creating the fixed (private) range using nova-manage network create, we assign this fixed range to a particular tenant (project). This allows us to have specific IP ranges that are isolated from different projects in a multi-tenant environment.

When our instance boots up, our dnsmasq service that is running on our nova-network host assigns an address from its dhcp pool to the instance.

Also note that we don't assign an IP address to the interface that we connect to our bridge, in our case eth2. We simply bring this interface up so we can bridge to it (and therefore forward traffic to the instance interfaces that are bridged to it).

OpenStack Networking: Configuring VLAN Manager Networking

VLAN Manager networking is the default networking mode in OpenStack. When VLAN mode is configured, each project (or tenancy) has its own VLAN and network assigned to it. Any intermediary physical switches must however support 802.1q VLAN tagging, for this to operate.

To begin with, ensure you're logged in to the OpenStack API server.

If using the openstack1 host, 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/8)

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.

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

1. 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. As we are also configuring VLANs, the required package to support VLANs must also be installed:

 sudo apt-get update sudo apt-get -y install bridge-utils vlan 

2. The networking on our host is as follows:

 # The primary network interface auto eth0 iface eth0 inet dhcp # eth1 public auto eth1 iface eth1 inet static address 172.16.0.1 netmask 255.255.0.0 network 172.16.0.0 broadcast 172.16.255.255 # eth2 private auto eth2 iface eth2 inet manual up ifconfig eth2 up 

3. We then restart our network service to pick up the changes, as follows:

 sudo /etc/init.d/networking restart 

4. By default, if we don't specify a Network Manager in our /etc/nova/nova.conf file, OpenStack Compute defaults to VLAN networking. To explicitly state this, so there are no ambiguities, we put the following in /etc/nova/nova.conf specifying our VLAN details:

 --network_manager=nova.network.manager.VlanManager --vlan_start=100 --vlan_interface=eth2 --public_interface=eth1 --dhcpbridge_flagfile=/etc/nova/nova.conf --dhcpbridge=/usr/bin/nova-dhcpbridge 

5. Restart the required OpenStack Compute services, to pick up the changes:

 sudo restart nova-compute sudo restart nova-network 

6. 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:

 . keystonerc keystone project-list 

7. We now create a private network that OpenStack can use, which we are assigning to a project, as follows:

 sudo nova-manage network create --fixed_range_v4=10.0.3.0/24 --label cookbook --vlan=100 --project 950534b6b9d740ad887cce62011de77a 

8. Once created, we can configure our public network address space, which we will use to connect to our instances:

 sudo nova-manage floating create --ip_range=172.16.1.0/24 

9. When we launch an instance now, the private address is assigned to the VLAN interface. We can assign floating IP addresses to this instance, and they get forwarded to the instance's internal private IP address.

VLAN Manager networking is the default and, for a private cloud environment in networks accustomed to VLANs, this option is the most flexible. It allows for per-project and secure networking by using VLANs. If you do not have a --network_manager flag in your /etc/nova/nova.conffile, OpenStack Compute will default to VlanManager.

Creating the network is no different in any of the managers; in this instance, with VlanManager, the private network is assigned to a VLAN that is specified in the --vlan=100 option. We then associate this network and VLAN with our cookbook project, by specifying the ID of that tenant, using the --project option.

On our OpenStack Compute host, this creates an interface named vlan100, which is the tagged interface to eth2, as specified in --vlan_interface from /etc/nova/nova.conf.

OpenStack Networking: Configuring Per-Project (Tenant) IP Ranges

Projects in Nova are a way of keeping user's cloud resources separate. In a project, there are a number of images, instances, and its own network resources assigned to it. When we create a project, we assign it its own VLAN with its own private and public ranges. For example, we may wish to create a development tenancy that is separate from the performance testing tenancy and live tenancies.

To begin with, ensure you're logged in to the OpenStack API server (our OpenStack VirtualBox Virtual Machine, openstack1, created in Chapter 1, Starting OpenStack Compute).

In order to configure per-project (tenant) IP ranges, carry out the following steps:

1. First, on our keystone client, list the current projects, as follows:

 # Use the admin token export ENDPOINT=172.16.0.1 export SERVICE_TOKEN=ADMIN export SERVICE_ENDPOINT=http://${ENDPOINT}:35357/v2.0 keystone tenant-list 

This returns a list of projects in our example.

2. Now, let's create another project named development; the project user will be demo. We do this as follows:

 keystone tenant-create --name=development 

3. This will return a project ID. Now let's create a fixed IP range for this project. We will create a fixed range of 10.0.4.0/24. To allocate this to our project, along with a new VLAN ID associated with this network, enter the following command:

 sudo nova-manage network create --label=development --fixed_range_v4=10.0.4.0/24 --p 

Creating IP address ranges for projects is done as part of creating new projects (tenants). We first create the project, which returns an ID that we use when creating that network, using the following syntax:

 sudo nova-manage network create --label=project_name --fixed_range_v4=ip_range --bridge_interface=interface --project_id=id --vlan=vlan_id 

OpenStack Networking: Automatically Assigning Fixed Networks To Tenants

When using VlanManager to separate tenants, we can manually assign VLANs and network ranges to them by creating a secure multi-tenant environment. We can, however, have OpenStack manage this association for us, so that when we create a project it automatically gets assigned these details.

To begin with, ensure you are logged in to the OpenStack API server as well as a client that can access the keystone environment.

1. Carry out the following steps to configure networking in OpenStack to automatically assign new tenants' individual VLANs and private (fixed) IP in the file /etc/nova/nova.conf, and ensure there is a flag called --vlan_start with a VLAN ID, for example:

 --vlan_start=100 

2. We can now create a range of networks, each with 256 addresses available, by issuing the following command:

 sudo nova-manage network create --num_networks=10 --network_size=256 --fixed_range_v4=10.0.0.0/8 --label=auto 

3. This creates 10 networks, with 256 IP addresses starting from 10.0.0.0/24 to 10.0.9.0/24 and starting from VLAN ID 100 to VLAN ID 110.

You can specify an alternative VLAN start ID on the command line by adding in the --vlan=id option, where id is a number.

By specifying the --num_networks option and specifying the --network_size option (the number of IPs in each of the created networks), we can tell our OpenStack environment to create multiple networks within the range specified by --fixed_range_v4. When projects are created now, rather than having to manually associate an address range with a tenant, they are automatically assigned a VLAN, starting from the --vlan_start ID, as specified in /etc/nova/nova.conf.

OpenStack Networking: Modifying A Tenant's Fixed Network

To ensure that our OpenStack environment is able to separate traffic from one tenant to another, we assign different fixed ranges to each. When a fixed network is no longer required, or we want to assign a particular tenant to a specific network, we can use the nova-manage command to modify these details.

To begin with, ensure you're logged in to the OpenStack API server as well as to a client that can access the keystone environment.

To assign a particular network to a tenant, carry out the following steps:

1. On a client that has access to the keystone command, run the following commands to list the projects available:

 # Use the admin token export ENDPOINT=172.16.0.1 export SERVICE_TOKEN=ADMIN export SERVICE_ENDPOINT=http://${ENDPOINT}:35357/v2.0 keystone tenant-list 

2. To view the list of networks and ranges available, issue the following command on an OpenStack API host:

 sudo nova-manage network list 

3. The output shown lists network ranges and their associated project IDs. From this, we can see we have 10.0.3.0/24 not assigned to a project (where it says None under the project column). To assign this network range to the development tenant, we issue the following commands:

 sudo nova-manage network modify --project=bfe40200d6ee413aa8062891a8270edb --fixed_range=10.0.3.0/24 

4. When we view the output now for that network range, we will have this project ID assigned to it and any instances spawned under this tenant will be assigned an address in this range.

When configuring tenants in our OpenStack environment, it is recommended (although not a requirement) to have their own private (fixed) range assigned to them. This allows for those instances in a particular tenant to be kept separated through their different ranges along with appropriately set security group rules.

The syntax to modify a network is as follows:

 nova-manage network modify --project=project_id --fixed_range=ip_range 

OpenStack Networking: Manually Associating Floating IPs To Instances

When an instance boots, it is assigned a private IP address. This IP range is only accessible within our virtual environment's network. To access this instance to serve the rest of the network or the public, we need to assign it a floating IP, which is the range we configure when we set up public IP ranges.

There are two ways to allocate floating IPs to instances: either automatically, as the instance is spawned, or manually through our client tools. In both cases, our tenancy must have a range of floating IPs assigned to it so they can be allocated.

While on the OpenStack API host, for example, openstack1, run the following command to list any floating ranges we have assigned:

 sudo nova-manage floating list 

This should list the IP range we originally set up when we first installed our openstack1 server.

 None 172.16.1.1 None nova eth1 None 172.16.1.2 None nova eth1 ... 

To allocate a floating IP to an instance, ensure you're logged in to a client that is running euca2ools or Nova Client.

To assign a floating (public) IP address to an instance using euca2ools, carry out the following steps:

1. To allocate one of the floating IP addresses available to our project, we run the following command:

 euca-allocate-address 

2. An address will appear from the pool of IPs we have available, for example, 172.16.1.1.

3. To associate this address to an instance, we issue the following commands:

 euca-associate-address -i i-00000002 172.16.1.1 

4. We are now able to communicate with that instance using this assigned floating IP address.

To assign a floating (public) IP address to an instance using Nova Client, carry out the following steps:

1. To allocate one of the floating IP addresses available to our project, we run the following command:

 nova floating-ip-create 

2. An address will appear from the pool of IPs we have available, for example 172.16.1.1.

3. To associate this address to an instance, we issue the following command:

 To associate this address to an instance, we issue the following command: 

We are now able to communicate with that instance using this assigned floating IP address.

Instances are not instantly accessible outside of the OpenStack host unless a public IP address is attached to it. Manually associating an address consists of the following two steps:

• Allocating an address from the available IP range.
• Associating the address with an instance.

This is an important concept, as it allows you to control the allocation of IP addresses as well as allocating specific addresses to specific instances, which is very much like Amazon's Elastic IP feature.

OpenStack Networking: Manually Disassociating Floating IPs From Instances

In our cloud environment, we have the ability to add and remove access to and from the instance publicly by adding or removing a floating IP address to or from it. This flexibility allows us to move services seamlessly between instances. To the outside world it would appear to be the same instance, as their access to it via that IP has not changed to them.

To begin with, ensure you are logged in to a client machine running euca2ools or Nova Client.

To disassociate a public (floating) address from an instance using euca2ools, carry out the following steps:

1. We first list the instances in our environment, to identify the instance we wish to remove the public IP address from, as follows:

 euca-describe-instances 

2. Once we have identified the instance we wish to disassociate the IP from, we execute the following command:

 euca-disassociate-address 172.16.1.1 

3. This instantly removes the association between this address and the instance.

If we no longer require that floating IP address for our project, we can remove it from our project's pool by issuing the following command:

 euca-release-address 172.16.1.1. 

To disassociate a public (floating) address from an instance using Nova Client, carry out the following:

1. We first list the instance in our environment, to identify the instance we wish to remove the public IP address from, as follows:

 nova list 

2. Once we have identified the instance we wish to disassociate the IP from, we execute the following command:

 nova remove-floating-ip 2abf8d8d-6f45-42a5-9f9f-63b6a956b74f 172.16.1.1 

3. This instantly removes the association with this address from the instance.

If we no longer require that floating IP address for our project, we can remove it from our project's pool by issuing the following command:

 nova floating-ip-delete 172.16.1.1 

Removing a floating IP address is very straightforward. When using euca2ools, we use the euca-disassociate-address command or, when using Nova Client, we use the remove-floating-ip option to the nova command.

OpenStack Networking: Automatically Assigning Floating IPs

When an instance boots, it is assigned a private IP address. This private IP address is only accessible within our virtual environment's network. To access this instance to serve the rest of the network or the public, we need to assign it a floating IP, which is the range we configure when we set up public IP ranges.

Automatically assigning floating IPs to instances gives us the ability, in our environment, to have access to all instances on our network. Although there are times when we might want to manually assign addresses (for example, where we have a limited number of IPs assigned to a tenancy), the convenience of having this done for you is very beneficial and makes our OpenStack environment operate much closer to how Amazon EC2 operates.

To begin with, ensure you are logged in to the OpenStack API server. We will also be using the client machine, so log in to your client that is running euca2ools or Nova Client.

To ensure each of the instances gets a public (floating) IP address assigned to it when it is launched, carry out the following steps:

1. While on our OpenStack API host, run the following command to list any floating ranges we have assigned:

 sudo nova-manage floating list 

An example of the output when listing the floating IPs is shown as follows, truncated for brevity:

 None 172.16.1.1 None nova eth1 None 172.16.1.2 None nova eth1 ... 

2. The values indicate we have a floating range available for use. Rather than using client tools to assign addresses to instances, a flag in our /etc/nova/nova.conf file ensures our instances are always allocated an address:

 --auto_assign_floating_ip 

3. With this added to our nova.conf configuration file, we restart our nova-network and nova-compute services, to pick up the change:

 sudo restart nova-network sudo restart nova-network 

4. When an instance spawns, it will automatically be assigned a public floating IP address that we can instantly use to gain access.

Instances aren't instantly accessible outside of the OpenStack host unless a public IP address is assigned to them. Configuring our OpenStack environment so that each instance is assigned an address on launch makes the instances instantly accessible.

OpenStack Networking: References

• On-Page SEO
• Off-Page SEO
• Website Performance Optimization
• SEO Tutorials and Courses
• SEO Books and eBooks
• SEO Glossary and Dictionary
• OpenStack Networking Cookbook
• Learning OpenStack Networking
• Mastering OpenStack