Creating and Deleting a Neutron network – OpenStack

 

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:

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:

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

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

• 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:

• We add this router to our subnet:

• Boot an instance and the address assigned to it will come from our 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:

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

• 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):

• 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:

• 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:

• Create subnet as follows:

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:

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

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:

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:
Ensure you have set the following 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:

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:

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

quantum subnet-list

This produces output as the following screenshot:

• 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:

• 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:

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:

• 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

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:

• 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