A User’s Look at OpenStack Networking, Part 5

In this final installment, we access our web server by giving it a public IP.

This is the final post of a five-part series covering a user’s view of OpenStack networking. In this series, we’ve looked at some basic concepts, built a network, created a router and set up a security group (firewall rules).

Now for the final step. We must allow the world to access our web server by giving it a public IP.

In the physical world, this can be a complex process: acquiring a public IP, getting the public router configured for the IP, and ensuring that the DNAT tables are set up correctly. As has been the case so far, OpenStack makes the job easy.

Exploring the external network

An OpenStack environment should have an external network configured — providing access to the Internet and into the OpenStack environment. Access into and out of our private network goes through the router, which we created in one of the previous posts.

If you’re following along in OpenStack, at this point we will need an instance (virtual machine) running on our private network/subnet. Since this series is about managing networking in OpenStack, I am not covering instance creation, however, you’ll need an instance with a web server running if you want to try this at home.

Your external (public) network also should have a pool of public IPs available to be assigned to various instances. In cloud terminology, the available public IPs are referred to as floating IPs, since they float, waiting to be assigned to an instance. We will associate a floating IP to our instance and expect OpenStack to do all of the heavy lifting, configuring the router with the IP and creating the NAT tables for us.

The connection from our router to the external network was set up in part 3 of this series, so we are ready to allocate a floating IP to our project and assign it to our instance. Before we begin, to prevent confusion, I want to note that all work is done on the Ocata release of OpenStack. If you have an earlier release of OpenStack, you may find some slight differences in the location of items in the OpenStack web interface. For example, when using the Newton release, Security Groups and Floating IP are found in the Compute section, whereas in Ocata, they are found under the Network section. Let’s look at that section. On the left navigation area under the Network line you will see Floating IPs. If you click there you will see the Floating IP page as shown below:

To associate a floating IP to your project, click on the Allocate IP to Project button on the far right of the page. You will see an Allocate Floating IP popup as shown below:

Select your external network from the choices in the Pool pull down and click on the Allocate IP button in the bottom left of the window.

This will return us to the Floating IPs window, but now our new IP will show in the Floating IPs page. We now need to associate the IP to our instance and we will be finished. If we click on the Associate button on the far right of our new floating IP, we will see a Manage Floating IP Associations popup as shown:

Our IP address will be shown in the ‘IP Address’ box. We need to select the IP address of our instance in the ‘Port to be associated’ box. Here is where things can get a little tricky. Because of the way pull downs are created and the size of the box, you may only see the No ports available message. The part that is very easy to miss is that there will be a slider on the far right in the box. Grab it and slide until you see the IP (port) of your instance as shown below:

 

 

Select the port of your web server instance and click on the Associate button on the far right. OpenStack will now configure the floating IP on the router’s gateway interface and create all of the needed DNAT rules within the router. Since we have the security group rules created to allow TCP port 80 traffic to our web server, pointing a browser to the new floating IP will show our website.

At this point, we have finished configuring our network and setting up public access to our new website. But, there is one more issue/concept that we need to consider.

Multiple IPs

At times we may need to support multiple public IPs on our web server, and OpenStack handles this requirement in a way that isn’t immediately apparent because of the differences between the physical and virtual worlds.

In the physical world, to support multiple public IPs, we would create a sub-interface on the existing network interface card (NIC) in our server and assign the IP to the sub-interface. In the physical world, the number of NIC card slots in a chassis limits us in how many NIC cards can be inserted, so in cases like this we place multiple IPs on one card.

That isn’t done in OpenStack. In OpenStack, instances are not allowed to unilaterally take on a new IP address — security group rules are designed to prevent this sort of activity.

Fortunately, in the virtual world, an instance can have as many NIC cards as there are PCI bus addresses, and to make things even better, in the virtual world, NIC cards are free! As a result, we can add an additional NIC card (port) for each IP needed.

To accomplish this, for your instance, go to the Compute section and click on the line for your web server instance. On the far right, on the line of your instance, click on the pull down and go to the line attach interface and a popup similar to the one shown below will appear:

In the Network pull down, select the private network that we created (remember the earlier slider hint) and click on the Attach Interface button. Once completed, follow the allocate floating IP process from above, then associate the new floating IP to the new interface and you have the new IP on your web server.

This completes our series on using OpenStack networking. We have gone from creating a functional network, subnet, creating a virtual router for our network, setting up firewall rules and finally assigning a public IP to our virtual machine. It only took a few minutes to accomplish all these tasks by ourselves. The user view of networking in OpenStack is designed to be friendly, accessible, and easy — so much easier than it is in the physical world.

Rackspace remains the leading provider of OpenStack private clouds as a service. To learn more and ask questions about whether private cloud as a service might be a good fit for your organization, take advantage of a free strategy session with a private cloud expert — no strings attached. SIGN UP NOW.

Phil Hopkins is a principal engineer at Rackspace. He has an Electrical Engineering Degree from the University of South Florida and has been working on Linux systems for more than 15 years. In the past he has taught Cisco Networking classes and worked as a Cisco Admin as well as designing VOIP systems using Asterisk. He is active teaching and writing about OpenStack software defined networks (SDN). He has written and currently teaches an advanced class on OpenStack Networking. Phil has spoken about Cloud Technologies at a number of events including The Red Hat Summit in 2011, OpenStack Summits 2013 through 2016 and Linux Foundation CloudOpen 2014.

LEAVE A REPLY

Please enter your comment!
Please enter your name here