And now let's see how this is done in practice.
We start with a router already connected to the external network,
and a disconnected network, titan network.
How can we manage several subnets? To explore this, I'm now creating
a second subnet on the titan network. I call it titan-200,
that's a reference to its IP address range.
And let's list our two subnets, here they are.
Remember the three-tiered application, it's not uncommon that more
than one router is connected to the same subnet, and this can lead to a problem.
I will illustrate it by creating a second router.
I connect this router to the new subnet, titan-200.
It's always good to check that in the network topology.
Yeah, as you can see, we now have a second router connected to the titan network.
The topology doesn't show me which subnet it is, but you can see that
from the IP address. So I also want to connect titan-200 to the titan
router, so that I can access my application from outside.
Whoops, why does that fail? We could add the --debug option to get
perhaps more information about this error, --debug shows me all the
API requests that I made, and here you can see the IP address .1 is
already allocated, it belongs to the second router, in fact.
So the problem is that by default, Neutron uses the address .1 for
routers, and if we want to use another address, we have to do something.
And what we do is we create a port on the subnet, and then we will
later connect that port to the router, rather than the subnet to the router.
You can see here the --fixed-ip option, which ensures that the port is
in fact created on that subnet, and not just a subnet,
that is selected by Neutron. And now that the port exists,
I can connect it to the router. You can see the connection has been
made, and the titan network is now connected to both routers.
You can see also the 2 addresses, 1 router has address 9,
and the other one has address 1. Next, I want to launch an instance.
How can I be certain that it will be connected to the subnet titan-200?
I could select an IP address directly. This is a sub option to the --nic option.
Now that's fine, it's connected to subnet titan-200, the problem is
that I had to specify the IP address, so I have to manage IP addresses.
And if I don't want to do that, it's not a good solution.
So the other solution is to use a subnet, but for that I first have to
create a port on that subnet, just like I did for the router.
The IP address here, .6, was created by Neutron, and Neutron manages
IP addresses in this case, and not myself.
And now that I have this port, I can connect the next instance to it.
So that's the situation now, our titan network has two instances,
it's connected to two routers, and one of the routers connects it to
the external network named public.
This brings us to the end of this module and also the end of this
first part of the Red Hat OpenStack Certification course.
Let's quickly summarize what we learned in this module.
You learned that in addition to Neutron, there is still an older
network management system named Nova Network, but we are not going to
cover this at all in this class. We looked at a network in a data
center, what are the components, what are the requirements.
Then we enumerated Neutron's concepts, and in particular, we looked at
ports, subnets, networks, and the non-core concept of routers.
And obviously we saw how to use all these concepts in practice.