Creating and Deleting a Neutron network – OpenStack

Only the operators and instances of a given tenant have access to a Neutron network when it is made private. It is vital to use this shared network feature carefully in order to maintain security amongst tenants when it is tagged as shared. Creating and deleting a Neutron network will be explained in this blog.

 

Creating a Neutron network

Now that we have our OpenStack network configured for Neutron, we can now use this to create networks within our OpenStack environment. Networks are created per tenant and once created we can use these to connect to our VMs. Neutron networks can either be private or shared. When a Neutron network is private, only the operators and instances of that tenant can utilize these networks. When they are marked as shared, all instances can attach to this shared network so it is important to utilize this shared network feature carefully to ensure security between tenants. When using shared networks, we implement Security Group rules to ensure traffic flow matches our security requirements.

If you would like to build your career with an OpenStack certified professional, then visit Mindmajix - A Global online training platform: “OpenStack Online Training” Course. This course will help you to achieve excellence in this domain.

Creating A Neutron Network Using Vagrant

Ensure you are logged on to the controller node in our environment. If you created this using Vagrant, you can issue the following command:

vagrant ssh controller

Ensure you have set the following credentials set:

credentials set

How to Create Private Neutron Network 

To create a private Neutron network for a particular tenant, follow these steps:

  • We first need to get the tenant ID that we can reference when creating the network information for that particular tenant. To do so issue the following:

tenant ID

  • We then use this value to create the layer 2 network for this tenant as follows:

tenant

  • With the network in place, we now allocate a subnet using CIDR format (200.0.0/24) to this network:

CIDR format

  • We will now create a router on this network that we can use to act as the default gateway for our instances. Adding routers is optional—they are a design consideration, allowing you to route from one network that we create to another. This option avoids multi-homing instances with multiple interfaces and networks. This router will be used to allow us to assign an IP from our physical host range allowing us access to our instances:

router

  • We add this router to our subnet:

router subnet

  • Boot an instance and the address assigned to it will come from our new subnet:

new subnet

  • At this point, although our instance receives an IP address, it is only accessible from other instances on that same network, and from our network host only. To test access, providing a Security Group rule has the allowed access (for example, ability to ping and SSH from any network), we can issue the following.

Log on to the network node. If this was created with Vagrant, issue the following from our host computer:
Vagrant

  • Once on the Network node, we can interrogate what is known as Network namespaces:

Network namespaces
This returns information as follows:

returns information

  • The formats of these namespaces are qdhcp-network-uuid and qrouter-router-uuid and these match the output of the following commands (perform this on the controller host where our environment has been set to view our OpenStack information):

net list
This brings back information as the following screenshot:

information sheet
router list

Data

  • And the preceding command brings back information as the following screesnhot:We view which IP our instance has been assigned using the familiar nova list command as follows:

nova list
This brings back information as the following screenshot:
ID

  • To access our instance, that has an IP address on our cookbookNet we perform this via the matching network namespace as follows:

Frequently Asked OpenStack Interview Question & Answers

Creating a network with Defined Subnet 

What we have done here is created a network with a defined subnet that our VMs utilize when they are started up. The steps to create this are as follows:

  • Create network as follows:

Network Creation

  • Create subnet as follows:

Create subnet

Routers are optional on networks and the function is to route traffic from one subnet to another. In a Neutron Software Defined Network, this is no different. Layer 3 (L3) Routers allow you to configure gateways and routes to other networks on-demand. If we only require our instances to communicate between each other on the same subnet, there is no requirement to have a router as there would be no other network required to be routed to or from. The syntax for creating routers is as follows.

Adding a router is optional:

Adding a router

Add the (optional) router to our Subnet (used to allow routes from one network (physical or software defined):

Subnet

With our network in place, when we start up our VM up now, as no other networks currently exist, it will use this network to get its IP address when it gets created.

At this moment, though, this instance has an IP assigned in our Neutron environment that is only accessible via our Network node using namespaces. Namespaces provides further isolation between our ranges at the Linux network stack level. By utilizing namespaces it allows us to have overlapping IP ranges so that users of our tenants can assign arbitrary ranges without any conflicts with matching ranges in another tenant. To troubleshoot our instances at this point, we log into our network node that has the namespace information and access our instance through that particular namespace as follows:
instances

MindMajix Youtube Channel

Deleting a Neutron network

To remove a Neutron network, we follow a similar set of steps to how we create the network.

Getting ready

Ensure that you are logged on to the controller node in our environment. If you created this using Vagrant, you can issue the following command:Normal Bash command
Ensure you have set the following credentials:

credentials

Creating a Neutron Network for Particular Tenant…

To create a Neutron network for a particular tenant, follow these steps:

  • We first need to get the tenant ID that we can reference when creating the network information for that particular tenant. To do so issue the following:

Tenant ID

We can now list the networks for this tenant. We do this with the following command:

quantum net-list

This produces output as the following screenshot:Subnets

  • And to list the subnets, we issue a similar command:
quantum subnet-list

This produces output as the following screenshot:Allocation polls

  • To delete a networks and subnets, we must first ensure that there are no instances and services using the networks and subnets we are about to delete. To check what ports are connected to our network we query the port list in Neutron as follows:
quantum port-list

This produces output as the following screenshot:fixed ips

  • We can also look at the running instances and the networks that they are attached to by issuing the following command:
nova list

This produces output as the following screenshot:Network

Here we see we have an instance on the network, cookbook network1 want to delete.

  • We need to stop any instances that are running on this network, for example:
nova delete test1
  • With any instances now stopped on our network that we want to remove, we can now remove any router interfaces attached to this network with the following commands:

Instance Commands

  • With the router interface removed, we can proceed to delete the subnet as follows:
quantum subnet-delete cookbook_subnet_1
  • With the subnet remove, we can delete the network as follows:
quantum net-delete cookbook_network_1
Explore OpenStack Sample Resumes! Download & Edit, Get Noticed by Top Employers!  Download Now!

Steps to Remove a Network

What we have done here is run through a series of steps to remove a network. This involves first removing any (virtual) devices attached to this network such as instances and routers, before removing the subnet that has been attached to that network, then lastly removing the underlying network itself.

  • Listing networks:
quantum net-list
  • Listing Subnets:
quantum subnet-list

Listing used Neutron Ports:

quantum port-list
  • Removing a router interface from a subnet:

Router Subnet

  • Removing a subnet:
quantum subnet-delete NAME_OF_SUBNET
  • Removing a subnet:
quantum subnet-delete NAME_OF_NETWORK

HTTP://DOCS.OPENSTACK.ORG/USER-GUIDE/SDK_NEUTRON_APIS.HTML

Course Schedule
NameDates
OpenStack TrainingOct 15 to Oct 30View Details
OpenStack TrainingOct 19 to Nov 03View Details
OpenStack TrainingOct 22 to Nov 06View Details
OpenStack TrainingOct 26 to Nov 10View Details
Last updated: 03 Apr 2023
About Author

Ravindra Savaram is a Technical Lead at Mindmajix.com. His passion lies in writing articles on the most popular IT platforms including Machine learning, DevOps, Data Science, Artificial Intelligence, RPA, Deep Learning, and so on. You can stay up to date on all these technologies by following him on LinkedIn and Twitter.

read less
  1. Share:
OpenStack Articles