noun_Email_707352 noun_917542_cc noun_Globe_1168332 Map point Play Untitled Retweet

OpenStack deployment – OpenStack Networking

Marcin Nicpon / February 01, 2021

Continuing our journey, with this blog post we will do the deeper dive into OpenStack networking. Please note that all of this you can do at your home with VirtualBox deployment.

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 alreadyhowever, 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 hereand uploaded to Openstack as QCOW2 format, then launch new instance. 

image0o6ki.png

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”. 

image6o59m.png

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”. 

imagefhavj.png

Figure 3Adding floating IP 

Click “+” button: 

imagexu5ea.png

Figure 4Allocate floating IP 

 

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

image4qc0j.png

Figure 5Associate floating IP 

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

imagei748.png

Figure 6Instances 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”: 

image9gj2e.png

Figure 7Port forwarding 

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

imagefgp0l.png

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

imagerum0n.png

imageh2wi.png

Figure 8Internet 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).

image22fce.png

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: 

imagehvesi.png

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

imageh784e.png

Figure 9Network 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:

imagehmfpd.png

Figure 10Router parameters 

Finally we get:

image1r6tl.png

Figure 11Routers overview 

Now, we need to connect routers to the networks: 

imageoyx4n.png

Figure 12External network connection 

image2c16o.png

Figure 13Routers connections topology 

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

imagecep8i.png

Figure 14Networks creation 

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

imagex7sj9.png

Figure 15: Subnets creation 

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

imagee4ing.png

Figure 16: DHCP enabling 

imagej6gwf.png

Figure 17: Router connection 

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

image410fb.png

Figure 18: Router connection to external network 

Select the subnet and click on “Submit” button:

imagei048o.png

Figure 19: Adding interface 

imagebe05k.png

Figure 20: Updated networks architecture 

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

image0csen.png

Figure 21: New instance creation

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

imagepopyj.png

Figure 22: New instance launching 

imageaqecw.png

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: 

image5svj.png

images4no7.png

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. 

imagebm6q4.png

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

imageqn9tr.png

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: 

imagein34o.png

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. 

imagendsw.png

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:

imageof59c.png

Figure 27: Adding static route for myrouter1

 

And for myrouter2: 

imagemin4.png

Figure 28: Adding static route for myrouter2 

 

Let’s check the connectivity between instances:

imagee6i6.png

It works, on both now! 

image0zepl.png

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. 

imagevh4y.png

Figure 30: Intra routing network 

image4ox8.png

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. 

imagecnod.png

Figure 32: myinstance1 eth interfaces status 

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

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

Now we can check if the instances can communicate directly: 

imaged7k2s.png

Now it works! 

imageoenyp.png

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.

imagenx41n.png

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 

Ubuntu 

Marcin Nicpon
Telco Ecosystem Solutions Director

Marcin has more than 18 years of experience in Telco and Cloud delivering software solutions for OEMs, TEMs and Silicon vendors designing and optimizing mobile communications networks and cloud solutions. He is very strong in NFV area, including implementations of several ETSI based use-cases.

Author

Marcin Nicpon

Telco Ecosystem Solutions Director

Marcin Lis

Senior IT Systems Engineer / DevOps

Check out our open positions

Search for jobs

Share on Facebook Tweet Share on LinkedIn