Now that we've explored some of the intricacies of what's happening under the hood, let's actually use Neutron to create a network by performing the following steps:
- Log in to your control node and source your
overcloudrcfile; use the non-administrative user for this. The command to create a virtual network is as follows:undercloud# openstack network create internal undercloud# neutron subnet-create internal 192.168.37.0/24
That is it. You just created a virtual network. I know that for the length of the introduction we just covered, that was pretty anticlimactic. Note that when you create the subnet, you are adding it to the network named
internalthat you just created. It is important to note the difference in the two commands. The first uses the command structure that has been used thus far. The second one calls a command named after the component being configured, Neutron. OpenStack has been going through a slow transition from having a command-line client for each component to a converged CLI that standardizes the syntax for OpenStack command-line actions. You will see other places in this book that use the component's client instead of the converged client. This just means that the functionality being used has not been added to the converged CLI yet. Neutron is one of the components that have not been fully implemented and we will use the neutron-client instead of the openstack-client for the rest of the chapter.The final argument to the
subnet-createcommand is the Classless Inter-Domain Routing (CIDR) notation. If you are not familiar with it, you will have to search the Internet for an explanation of it. There are plenty of good ones. Also, search for the CIDR calculator; there are plenty of CIDR calculators on the Internet too.Note
You can find a couple of examples of CIDR calculators at http://jodies.de/ipcalc and http://www.subnet-calculator.com/cidr.php.
In a CIDR calculator, you can type in the CIDR mentioned earlier and it will give you the usable IP range that it signifies. The CIDR that I've used,
192.168.37.0/24, identifies a range of IP addresses from192.168.37.1to192.168.37.254with192.168.37.255as the broadcast address. This means that we can allocate IP addresses in this range for things on our network. - Next, let's list the network that we just created; you can also list the subnet. Here's how:
undercloud# openstack network list undercloud# openstack subnet list
The subnet could have been created with a name. If it was, we could have updated it by referring to its name. Since one wasn't passed, the subnet's ID will have to be used, as follows:
undercloud# neutron subnet-create internal 192.168.37.0/24 --name internal_subnet - Let's update the subnet by adding a Domain Name System (DNS) name server. The properties of a subnet and a network can be passed at the time of creation or updated later. Refer to the Neutron command-line help for more details. Here is how we update the subnet by adding a DNS name:
undercloud# neutron subnet-update {subnet-id-hash} --dns-nameservers list=true 8.8.4.4 8.8.8.8In Chapter 3, Image Management, we mentioned cloud-init. Cloud-init is the service that runs when an instance is booted and connects back to
169.254.169.254to get metadata. SSH keys and post-boot scripts are two examples of what can be provided via metadata. This IP address is provided by Neutron and proxies the call from cloud-init to the metadata service. - Next, let's create a router and add the internal network as an interface to it:
undercloud# neutron router-create my_router undercloud# neutron router-interface-add my_router {subnet-id-hash}
Here again, had we passed the --name argument and given the subnet a name, we could have used that name instead of the subnet ID.