| date | draft | weight | title |
|---|---|---|---|
2016-05-09 |
false |
09 |
Lab 09 - Neutron Networks |
| Mon | Mon | Mon | Mon | Tue | Tue | Tue | Tue | Wed | Wed | Wed | Thur | Thur | Thur | Thur |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 |  |
10 | 11 | 12 | 13 | 14 |
The Neutron service can not be well controlled from the OpenStack Horizon dashboard. However, visually minded individuals may find it helpful to use the Horizon dashboard to examine current network configuration as it does produce very clear illustrations of current network configuration. At the conclusion of this lab, students should feel comfortable creating and modifying network settings with Neutron at the CLI.
Scroll horizontally
<SOME COMMAND> | less -S
Create a directory for recording output
mkdir ~/myopenstack
Pipe output to review later
<SOME COMMAND> | tee ~/myopenstack/FILENAME
In this section, we'll create a network for a tenant (acme_inc), so that you can compare and contrast the differences between working with the OpenStack Horizion dashboard, and the CLI commands.
-
Log into the OpenStack Horizon dashboard on the controller as
aliceanderson//fa5tpa55w0rd -
Navigate to Project > Network > Network Topology and click "+ create network"
-
Fill out the pop up box with the following information:
NetworkName: acme-inc-network AdminState: UP -
Fill out the next screen with the following information:
CreateSubnet: (checked) SubnetName: acme-inc-network-subnet-10 NetworkAddress: 10.10.0.0/24 IPVersion: IPv4 GatewayIP: 10.10.0.1
-
Hit ENTER or click NEXT.
-
The last screen is "Subnet Details". All the defaults here are fine (Enable DHCP should be checked, Allocation Pools should be empty, DNS Name server should be empty, and Host Routes should be empty). Just press the "Create" button to create your new network!
-
Now click the "Create Router" button
The Network Topology screen you are on should change to reflect the creation of this new network.
-
Let's create a router to connect our new network acme-inc-network to the network public. Click on the "+Create Router" button in the upper right corner.
-
After clicking on the "+Create Router" button, fill out pop up box with the following information:
RouterName: acme-inc-router AdminState: UP ExternalNetwork: publicThe Network Topology page should now display the new router connected to the network public.
-
All that is left is to connect this router to the acme-inc-network. Start by navigating to Project > Network > Routers
-
Click on the router named acme-inc-router
-
Now click on the tab labeled "Interfaces"
-
Finally click on the button "+ Add Interface" in the upper right corner.
-
After clicking on the "+ Add Interface", fill out the pop up box with the following information:
Subnet: acme-inc-network: 10.10.0.0/24 IPAddress: 10.10.0.1 RouterName: acme-inc-router RouterID: -
Finally, navigate back to Project > Network > Network Topology
-
The Network Topology screen should appear like the following screenshot:
Because the user chestercopperpot is part of a different project (vault_tek), he should not be able to see the newly created network (acme_inc_network). Let's confirm this...
-
Log out of the OpenStack Horizon dashboard, and log back in as
chestercopperpot//fa5tpa55w0rd -
Navigate to Project > Network > Network Topology
The user chestercopperpot should only see the public and private networks.
In this section, we'll create almost the same network for a different tenant (vault_tek), so that you can compare and contrast the differences between working with the OpenStack Horizion dashboard and the CLI commands.
-
Create a network called vault-tek-network
[root@controller]#source keystonerc_chestercopperpot[root@controller]#printenv | grep OS_Check that your environmental variables match those below:OS_REGION_NAME=RegionOne OS_PASSWORD=fa5tpa55w0rd OS_AUTH_URL=http://192.168.0.10:5000/v2.0/ OS_USERNAME=chestercopperpot OS_TENANT_NAME=vault_tekIf OK, then continue, otherwise edit keystonerc_chestercopperpot to match above variables
[root@controller] ~(keystone_chestercopperpot)# neutron net-create vault-tek-network -
Create a vault-tek-network subnet
[root@controller] ~(keystone_chestercopperpot)#neutron subnet-create --name vault-tek-network-subnet-10 --gateway 10.10.0.1 vault-tek-network 10.10.0.0/24NOTE: The command listed above line wraps, so be sure to include the second line as well, or an error stating "too few arguments" will occur.
-
Create a vault-tek-network router
[root@controller] ~(keystone_chestercopperpot)# neutron router-create vault-tek-router+-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | admin_state_up | True | | external_gateway_info | | | id | 5fddef2e-5cf4-4bb9-8617-57c2b9be8489 | <--This is the <ROUTER-ID> below | name | vault-tek-router | | routes | | | status | ACTIVE | | tenant_id | f2b7cc476b904fe0adb5855281038598 | +-----------------------+--------------------------------------+ -
Connect vault-tek-router to the public network.
[root@controller] ~(keystone_chestercopperpot)#neutron router-gateway-set vault-tek-router publicShow the router using less with horizontal scrolling
[root@controller] ~(keystone_chestercopperpot)#neutron router-show <ROUTER-ID> | less -SJust for fun, show the router WITHOUT using less
[root@controller] ~(keystone_chestercopperpot)#neutron router-show <ROUTER-ID> -
Connect the vault-tek-router to vault-tek-network-subnet-10
[root@controller] ~(keystone_chestercopperpot)# neutron router-interface-add vault-tek-router vault-tek-network-subnet-10 -
Check out the router now:
[root@controller] ~(keystone_chestercopperpot)#neutron router-show <ROUTER-ID> | less -S -
Hmmm, I don't see the new interface, try this!
[root@controller] ~(keystone_chestercopperpot)#neutron router-port-list <ROUTER-ID>+--------------------------------------+------+-------------------+----------------------------------------------------------------------------------+ | id | name | mac_address | fixed_ips | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------------+ | 07a17c22-478a-40d8-a01b-38cc78d29333 | | fa:16:3e:9a:83:b6 | {"subnet_id": "36ac8b4a-296f-4992-8248-dfccf2125da0", "ip_address": "10.10.0.1"} | +--------------------------------------+------+-------------------+----------------------------------------------------------------------------------+ -
Log into the OpenStack Horizon dashboard as
chestercopperpot//fa5tpa55w0rd -
Navigate to Project > Network > Network Topology
-
Navigate to Project > Network > Networks
Note that this network is not a shared network (see the big red arrow on the above screenshot), therefore it cannot be seen by other projects (tenants). Let's confirm this.
-
Log out of the OpenStack Horizon dashboard, log back in as a different user (admin, aliceanderson, or bobbarker) and navigate back to ( Project > Network > Networks ). You should no longer see vault-tek-network. After you've confirmed that the network is indeed private, log back into the OpenStack Horizon dashboard as
chestercopperpot//fa5tpa55w0rd. -
Navigate to Project > Network > Routers
-
Click on the router instance vault-tek-router.
-
IMPORTANT: On the screen you are currently on, look for a value called "ID" which is highlighted yellow in the figure above. It is second down on the overview tab. Write down the first 6 or so characters. These will be helpful later.
-
Review the rest of the information being presented. Note that the router is connected to a Gateway (public). Now explore the Overview and Interfaces tabs. Within the Interfaces tab, you will find a list of associated interfaces connected to the router. The screenshot below is what is displayed after clicking on the Interfaces tab. Note that this router has a fixed IP address (10.10.0.1), which connects it to the 10.10.0.0/24 network we just created.
- You are looking at the interface on the vault-tek-router
-
List the subnetworks you created this week.
[root@controller] ~(keystone_chestercopperpot)#source keystonerc_admin[root@controller ~(keystone_admin)]#neutron subnet-list+--------------------------------------+-----------------------------+-----------------+--------------------------------------------------+ | id | name | cidr | allocation_pools | +--------------------------------------+-----------------------------+-----------------+--------------------------------------------------+ | a71c27e2-a79e-4c2e-9ee5-06261376fb42 | acme-inc-network-subnet-10 | 10.10.0.0/24 | {"start": "10.10.0.2", "end": "10.10.0.254"} | | 36ac8b4a-296f-4992-8248-dfccf2125da0 | vault-tek-network-subnet-10 | 10.10.0.0/24 | {"start": "10.10.0.2", "end": "10.10.0.254"} | | ba02f29e-de66-4f21-84c4-777ce7e863c4 | public_subnet | 172.24.4.224/28 | {"start": "172.24.4.226", "end": "172.24.4.238"} | | 86e6e695-7775-46ef-827f-64c4306bb69f | private_subnet | 10.0.0.0/24 | {"start": "10.0.0.2", "end": "10.0.0.254"} | +--------------------------------------+-----------------------------+-----------------+--------------------------------------------------+[root@controller ~(keystone_admin)]#neutron subnet-show vault-tek-network-subnet-10+-------------------+----------------------------------------------+ | Field | Value | +-------------------+----------------------------------------------+ | allocation_pools | {"start": "10.10.0.2", "end": "10.10.0.254"} | | cidr | 10.10.0.0/24 | | dns_nameservers | | | enable_dhcp | True | | gateway_ip | 10.10.0.1 | | host_routes | | | id | 36ac8b4a-296f-4992-8248-dfccf2125da0 | | ip_version | 4 | | ipv6_address_mode | | | ipv6_ra_mode | | | name | vault-tek-network-subnet-10 | | network_id | 854e1cb3-9234-43ce-b467-47d5bfdf3539 | | subnetpool_id | | | tenant_id | f2b7cc476b904fe0adb5855281038598 | +-------------------+----------------------------------------------+
Now that we know a bit about security groups and networks, let's launch a new instance, and see if we can SSH into it!
-
Navigate to Project > Compute > Instances
-
Click on the "Launch Instance" button
-
Fill out the Details tab as follows:
-
Now click on the Access & Security tab so we can add our security group
- Check the box http-ssh
- Uncheck the box default
-
Now click on the Networking tab and click the + sign beside the vault-tek-network. Shown below are the before and after screen shots.
BEFORE
Install only the vault-tek-networking
-
Great! Now click the "Launch" button and you will notice the instance "Spawning", then "Running". See the screen shots below
vt2 is Spawning
vt2 is Running
- Wait until the machine spawns and comes up as ACTIVE and Running before going to the next step
-
Before we SSH to the Neutron server, type the following command to check out your new instance:
source keystonerc_chestercopperpot(In case you may still be sourced as keystonerc_admin)[root@controller] ~(keystone_chestercopperpot)#nova show vt2+--------------------------------------+----------------------------------------------------------+ | Property | Value | +--------------------------------------+----------------------------------------------------------+ | OS-DCF:diskConfig | AUTO | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-STS:power_state | 1 | | OS-EXT-STS:task_state | - | | OS-EXT-STS:vm_state | active | | OS-SRV-USG:launched_at | 2015-10-28T20:43:59.000000 | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | config_drive | | | created | 2015-10-28T20:42:53Z | | flavor | m1.tiny (1) | | hostId | 1f9d27fe57644512f82655d7339f19ae4c86a026c80f4db3a786ed39 | | id | 53ad58a5-4fae-45f7-a03b-d82a64e3452f | | image | cirros (8a724f78-2673-4ea1-b607-373626a15afb) | | key_name | - | | metadata | {} | | name | vt2 | | os-extended-volumes:volumes_attached | [] | | progress | 0 | | security_groups | http-ssh | | status | ACTIVE | | tenant_id | 41773a923b924ef7934e8aea532c0680 | | updated | 2015-10-28T20:43:59Z | | user_id | 7198d60229d14888914d6e1ef5d0ef2b | | vault-tek-network network | 10.10.0.3 | +--------------------------------------+----------------------------------------------------------+- Look at the VERY bottom of the output. It should say, "vault-tek-network network" followed by an IP address. It is likely something like 10.0.0.2, 10.0.0.3, 10.10.0.2, or 10.10.0.3. It doesn't matter what it is, just record it. We'll need it to SSH to this VM instance (vt2)
-
Navigate back to the CLI, time to SSH into the machine. In order to do this, we'll need to access that machine's namespace. In order to do this, we'll SSH to the neutron server. Type the following:
[root@controller] ~(keystone_chestercopperpot)#ssh root@neutron[root@neutron ~]# -
Fantastic. We are now in a Neutron node. If you're confused, click back to Lab 00, and check out the picture of the network. Remember that this is a dedicated node just for Neutron. Networking takes resources! Let's take a look at the namespaces the neutron node knows about. Type the following command:
[root@neutron ~]#ip netns listqrouter-b1579da2-d5a4-40ec-b6a5-606413f1738e qdhcp-cfe3722a-f584-4150-a6ae-1a178677ac78 qrouter-c9a2b225-bab6-4965-9c98-417d9a53ba3c qdhcp-3288dfae-a262-42c2-92b2-1b6ae652fa5b qdhcp-20ca30a2-e3fb-4e62-bd78-08dc471e93ed
-
The above command is going to create some output. Look near the top of the output. We're looking for a match that begins qrouter-, but notice that there are many qrouter- entries. We want the one that is followed by the same characters you recorded back in step "2.13"
-
Once you've found this value, copy it to the clipboard with your mouse
-
Now we're going to tell Ubuntu to allow us access to access that router's namespace. After we're in the namespace, we'll have SSH access to the VM we just created. If it works, you'll be prompted to log into the VM instance you just created (vt2). Keep reading through this step for the username / password of the cirros machine.
[root@neutron ~]#ip netns exec <<NAMESPACE>> ssh cirros@<<IP_ADDRESS_of_vt2>>EXAMPLE ONLY: ip netns exec qrouter-b1579da2-d5a4-40ec-b6a5-606413f1738e ssh cirros@10.10.0.3
- NOTE 1: The name space should include qrouter- portion in front of the ID
- NOTE 2: The IP_address_of_vt2 was obtained in step 7 when you issued the command "nova show vt2" on the controller.
- NOTE 3: The username and password for all cirros machines is cirros and cubswin:) by default. Don't forget the smiley!
The authenticity of host '10.10.0.3 (10.10.0.3)' can't be established. RSA key fingerprint is 26:6b:23:9c:ab:bb:eb:b5:3a:18:b5:8e:72:ba:b4:4f. Are you sure you want to continue connecting (yes/no)? yes <- Type YES then enter Warning: Permanently added '10.10.0.3' (RSA) to the list of known hosts. cirros@10.10.0.3's password: cubswin:) <- The password to all cirros images is cubswin:) -
There you go! If it worked, you'll be inside of the little VM you just started! This lab was heavy lifting, so if you don't understand something, ask the instructor.
-
There isn't much to see inside of a CirrOS VM, so once your curiosity is satisfied, type the following to return to root@controller
$exit[root@neutron ~]#exit -
Run the nova list command and shut off vt2, as well as any other VMs that are started and running.
[root@controller ~(keystone_chestercopperpot)]# nova list[root@controller ~(keystone_chestercopperpot)]# nova stop vt2 -
Repeat the above step until all VMs are shutdown. Finally, type the following to start a new bash shell and return to root@controller.
[root@controller ~(keystone_chestercopperpot)]#source .bashrc[root@controller ~]#This will put you back to root. Done!