OpenStack deployment – OpenStack Networking

If you want to learn more about the OpenStack environment preparation, deployment, please have a look at our previous blog posts.

 

Let’s try to do some operations with graphical interface for less demanding and working faster actions, like Xubuntu. 

We can install Xubuntu from ISO image using this guide. It requires to have cinder service enabled. We described cinder service already, however, if you didn’t enabled it yet, let’s use this as exercise for more experienced users. Of course, if we don’t have Cinder service enabled, we can still install Xubuntu like VM by creating Ubuntu server and then install Xubuntu desktop packages on top of it. The process looks similar to Windows 10 instance creation, but there are some differences. We will use cloud image which can be downloaded from here, and uploaded to Openstack as QCOW2 format, then launch new instance. 

^{Figure 1: Launch instance} 

Ubuntu cloud image is designed to work in the cloud. As depicted below, we can provide configuration parameters for the instance with cloud-init script. There are many more options to configure the VM (more information can be found here). In our case we set the password for default user “ubuntu”. 

^{Figure 2: Launch instance parameters} 

Now, we can connect to the app instance console, however there is more convenient and faster way. Ubuntu has built-in SSH server, so why not use it and connect using regular SSH client? 

By default, all OpenStack instances are not visible for external networks. To make them visible we need to create and associate with the instance so called “Floating IP”. 

^{Figure 3: Adding floating IP} 

Click “+” button: 

^{Figure 4: Allocate floating IP} 

 

Then “Allocate IP”, and finally click "Associate”: 

^{Figure 5: Associate floating IP} 

Note: your IP address may differ from above, however the whole process stays the same.

^{Figure 6: Instances overview} 

When IP is associated, we need to create port forwarding rule in VirtualBox to connect to the instance. Go to OpenStack VM settings -> Network -> Adapter -> Advanced and click “Port forwarding”: 

^{Figure 7: Port forwarding} 

You can connect to your instance using SSH client at 127.0.0.1:9022. Now you can install graphical interface as below: 

Now (after installation is done) we can reboot Ubuntu VM and get it started with graphical interface. 

^{Figure 8: Internet access} 

If you want to play more with OpenStack but you suffer from slow VMs, this is a sign you need to get better physical machine or move to command line console like SSH which is much faster and uses less resources, crucial in nested virtualization environment. Let’s use SSH then. 

To save resources let’s shutdown/delete all VMs we have started so far. First, we need to check what VMs we have active (running).

Note: using command line you can do more than is possible from Openstack Web UI. Check it out via  openstack help command. 

After some time check all the VMs are SHUTOFF: 

Let’s now create network resources for new VMs. To understand network topology use its graphical representation. Go to OpenStack UI -> Network -> Network topology. 

^{Figure 9: Network topology} 

Legend: 

• public1 - represents external network which can connect to the Internet 
• demo-net – internal network not accessible from external world 
• demo-router – it’s a bridge between networks. In this case traffic from internal networks to external are limited. When external network is connected, it converts internal IP addresses to external (NAT) 
• demo1 – CirrOS instance 
• myubuntu – Ubuntu Bionic Server based on cloud image 

All the resources (except myubuntu) have been created by Kolla-Ansible post-deployment scripts. It’s time to create some own resources. Let’s keep external network (public1) as is. Being behind the external network we can do a lot, we can create own network topology with multiple routers, networks and instances connected. For more insights look at the tutorials: sessions 1,2,3,4,5,6

Moving in the direction from external networks to internal we need to create two routers in a way below:

^{Figure 10: Router parameters} 

Finally we get:

^{Figure 11: Routers overview} 

Now, we need to connect routers to the networks: 

^{Figure 12: External network connection} 

^{Figure 13: Routers connections topology} 

Next, let’s create networks, one network for each router: 

^{Figure 14: Networks creation} 

Each network needs to have a subnet with specific IP address space:

^{Figure 15: Subnets creation} 

Each subnet can have enabled DHCP for automatic IP address assignments from defined pool:

^{Figure 16: DHCP enabling} 

^{Figure 17: Router connection} 

To connect a router to specific network we need to add desired interface:

^{Figure 18: Router connection to external network} 

Select the subnet and click on “Submit” button:

^{Figure 19: Adding interface} 

^{Figure 20: Updated networks architecture} 

As a network config is ready,  now it’s time to create some VMs.

^{Figure 21: New instance creation}

Let’s create two instances (one per network) based on Ubuntu cloud image.

^{Figure 22: New instance launching} 

^{Figure 23: Updated topology}

Note: Using CLI we can speed up whole infrastructure creation process and automate it. Here is list of the commands that allow you to create this infrastructure: 

^{Figure 24: Updated instances dashboard} 

Now, it is time to check connectivity: login to myinstance1 (connect using SSH as described earlier) and ping myinstance2 and internet address. 

Internet connectivity works fine, but there is no response from myinstance2. Let’s do the same steps for myinstance2. 

We can reach Internet but not myinstance1. As both instances are in different networks, they cannot communicate to each other, one of the way to enable network communication is to associate Floating IP for each of them (not recommended). Let’s assume each instance represents servers from different departments in your company. You want to enable communication between them but internally, as internal traffic must not go through external networks. In this case you need to connect both networks using additional router and set proper routes on each of the servers or create additional network and add static routes, so you don’t need to change anything on servers. Like mynetwork3 below: 

^{Figure 25: Routing network} 

Add interface to myrouter1 and connect it to mynetwork3, do same thing for myrouter2. For myrouter2 you need to enter IP address manually, as default IP (192.168.3.1) has been already assigned to myrouter1. 

^{Figure 26: Adding routing interface} 

We need also to check IP addresses assigned for each route in mynetwork3, then add a static route on each of them to enable network traffic:

^{Figure 27: Adding static route for myrouter1}

 

And for myrouter2: 

^{Figure 28: Adding static route for myrouter2} 

 

Let’s check the connectivity between instances:

It works, on both now! 

^{Figure 29: Updated topology} 

In some cases we may want to bypass the routers and make direct connection between two servers. In that case we can just add additional interface to each instance connected to separate network without any routers. 

In that case create network mynetwork4 then click on each instance Actions button to attach the network to it. 

^{Figure 30: Intra routing network} 

^{Figure 31: Instance’s interface assignment} 

 

Let’s verify connectivity now. The ping will fail because the IP address displayed on screen above is just a DHCP reservation for each instance, but instances itself are not configured to obtain IP address from DHCP. 

^{Figure 32: myinstance1 eth interfaces status} 

Let's make our instances to get DHCP IP address now. 

To make this change permanent you need to add such configuration to netplan files.

Now we can check if the instances can communicate directly: 

Now it works! 

^{Figure 33: Final network topology} 

In this article We’ve showed very basic networking features of OpenStack. Many additional config parameters can be added to /etc/kolla/globals.yml file. Each time you change the config file re-install or reconfigure the Openstack VM is necessary.

Good luck! 

Do you feel inspired? If so, we encourage you to get to know us better. Don’t hesitate to approach us via Tietoevry Careers or LinkedIn. You will have the opportunity to work with enthusiasts who share their knowledge. Due to the dynamic growth in demand for OpenStack skills, we are constantly seeking for talented engineers in this area. Currently, we are on the lookout for a candidate for the positions of Junior DevOps Engineer and Senior Cloud Engineer. 

References: 

OpenStack 

• https://docs.openstack.org/ussuri/ 

Ubuntu 

• https://ubuntu.com/tutorials 
• https://help.ubuntu.com/18.04/serverguide/index.html