Mindmajix

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.

Getting ready

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:

export OS_TENANT_NAME=cookbook 
export OS_USERNAME=admin export
 OS_PASSWORD=openstack
export OS_AUTH_URL=http://172.16.0.200:5000/v2.0/
export OS_NO_CACHE=1

How to do it…

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=$(keystone tenant-list \
| awk '/\ cookbook\ / {print $2}')
  • We then use this value to create the layer 2 network for this tenant as follows:
quantum net-create \ --tenant-id ${TENANT_ID} \ cookbookNet
  • With the network in place, we now allocate a subnet using CIDR format (200.0.0/24) to this network:
quantum subnet-create \ --tenant-id ${TENANT_ID} \ --name cookbookSubnet \ cookbookNet \ 10.200.0.0/24
  • 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:
quantum router-create \ --tenant-id ${TENANT_ID} \ cookbookRouter
  • We add this router to our subnet:
quantum router-interface-add \ cookbookRouter \ cookbookSubnet
  • Boot an instance and the address assigned to it will come from our new subnet:
nova boot \ --flavor 1 \
--image 5047209f-9545-4d2c-9f16-720f1d7197ef \
--key_name demo \ test1
  • 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 ssh network
  • Once on the Network node, we can interrogate what is known as Network namespaces:
sudo ip netns list

This returns information as follows:

qdhcp-36169ae7-476e-487c-9d9d-e10ad3c94a23 
qrouter-f0a5c988-6eb2-4593-8b15-90896fd55d3a
  • 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):
quantum net-list

This brings back information as the following screenshot:

Screenshot_644

quantum router-list

And the preceding command brings back information as the following screesnhot:

Screenshot_645

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

Screenshot_646

  • To access our instance, that has an IP address on our cookbookNet we perform this via the matching network namespace as follows:
sudo ip netns exec qdhcp-36169ae7-476e-487c-9d9d-e10ad3c94a23 \ ping 10.200.0.2

How it works…

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:
quantum net-create \ --
tenant-id TENANT_ID \
NAME_OF_NETWORK
  • Create subnet as follows:
quantum subnet-create \ --
tenant-id TENANT_ID \ --
name NAME_OF_SUBNET \
NAME_OF_NETWORK \
CIDR

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:

quantum router-create \ --
tenant-id TENANT_ID \
NAME_OF_ROUTER

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

quantum router-interface-add \
ROUTER_NAME \
SUBNET_NAME

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:

sudo ip netns exec qdhcp-network-uuid {normal Bash command to run}

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:

vagrant ssh controller

Ensure you have set the following credentials:

export OS_TENANT_NAME=cookbook
 export OS_USERNAME=admin export 
OS_PASSWORD=openstack
export OS_AUTH_URL=http://172.16.0.200:5000/v2.0/
export OS_NO_CACHE=1

How to do it…

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=$(keystone tenant-list \
awk '/\ cookbook\ / {print $2}')
  • 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:

Screenshot_647

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

This produces output as the following screenshot:

Screenshot_648

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

Screenshot_649

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

Screenshot_650

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:
ROUTER_ID=$(quantum router-list \
| awk '/\ cookbook_router_1\ / {print $2}')
SUBNET_ID=$(quantum subnet-list \
| awk '/\ cookbook_subnet_1\ / {print $2}')
quantum router-interface-delete \ ${ROUTER_ID} \
${SUBNET_ID}
  • 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

How it works…

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:
quantum router-interface-delete \ ROUTER_ID \
SUBNET_ID
  • 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


 

0 Responses on Creating and Deleting a Neutron network – OpenStack"

Leave a Message

Your email address will not be published. Required fields are marked *

Copy Rights Reserved © Mindmajix.com All rights reserved. Disclaimer.
Course Adviser

Fill your details, course adviser will reach you.