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.
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.
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:
To create a private Neutron network for a particular tenant, follow these steps:
Log on to the network node. If this was created with Vagrant, issue the following from our host computer:
This returns information as follows:
This brings back information as the following screenshot:
This brings back information as the following screenshot:
Frequently Asked OpenStack Interview Question & Answers
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:
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:
To remove a Neutron network, we follow a similar set of steps to how we create the network.
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:
To create a Neutron network for a particular tenant, follow these steps:
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:
quantum subnet-list
This produces output as the following screenshot:
quantum port-list
This produces output as the following screenshot:
nova list
This produces output as the following screenshot:
Here we see we have an instance on the network, cookbook network1 want to delete.
nova delete test1
quantum subnet-delete cookbook_subnet_1
quantum net-delete cookbook_network_1
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.
quantum net-list
quantum subnet-list
Listing used Neutron Ports:
quantum port-list
quantum subnet-delete NAME_OF_SUBNET
quantum subnet-delete NAME_OF_NETWORK
Name | Dates | |
---|---|---|
OpenStack Training | Oct 15 to Oct 30 | View Details |
OpenStack Training | Oct 19 to Nov 03 | View Details |
OpenStack Training | Oct 22 to Nov 06 | View Details |
OpenStack Training | Oct 26 to Nov 10 | View Details |
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.