Showing posts with label network namespace. Show all posts
Showing posts with label network namespace. Show all posts

Tuesday, June 17, 2014

My attempt at setting up ssh key pairs for an Openstack VM

In my quest to learn more about Openstack I've decided to test out the ssh key-pair authentication method. I'm not much of a Unix guy so this attempt may be the wrong approach. But hey, learning is all about experimenting, so my failures may one day lead to success.

 I've read the RDO quick install on setting up the key-pair, but I could not get it to work using the Horizon webui. The documentation is a little sparse with no examples. It says I should be able to access the VM from my host. But after a few attempts I couldn't get it to work. So I've decided to try it a different way.

First I had to figure out how to ssh from my host to the VM.

pinging the VM didn't work.

[root@centos-6-5-openstack .ssh]$ ping 192.168.251.12
PING 192.168.251.12 (192.168.251.12) 56(84) bytes of data.
^C
--- 192.168.251.12 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4659ms

Then I remembered that I had to use network namespaces.

[root@centos-6-5-openstack .ssh(keystone_admin)]# ip netns list
qrouter-ed4afc1b-06ab-417e-a7e2-d5be13b822af
qdhcp-4dc834f5-e759-4d79-acf0-780768f1fa86
qdhcp-0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48
qdhcp-a5958652-7348-436f-8aff-2c9ebd7dd9f7
qdhcp-dc49c1a5-07d0-4225-bea5-02316aec3a42

[root@centos-6-5-openstack .ssh(keystone_admin)]# ip netns exec qdhcp-a5958652-7348-436f-8aff-2c9ebd7dd9f7 ip a
31: tapcb867d96-a4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:ce:a5:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.251.11/24 brd 192.168.251.255 scope global tapcb867d96-a4
    inet6 fe80::f816:3eff:fece:a57e/64 scope link
       valid_lft forever preferred_lft forever
35: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

[root@centos-6-5-openstack .ssh(keystone_admin)]# ip netns exec qdhcp-a5958652-7348-436f-8aff-2c9ebd7dd9f7 ping 192.168.251.12
PING 192.168.251.12 (192.168.251.12) 56(84) bytes of data.
64 bytes from 192.168.251.12: icmp_seq=1 ttl=64 time=3.33 ms
64 bytes from 192.168.251.12: icmp_seq=2 ttl=64 time=0.436 ms
^C
--- 192.168.251.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1065ms
rtt min/avg/max/mdev = 0.436/1.885/3.334/1.449 ms

Awesome. That worked. So next I tried sshing to the VM.





[root@centos-6-5-openstack .ssh(keystone_admin)]# ip netns exec qdhcp-a5958652-7348-436f-8aff-2c9ebd7dd9f7 ssh -l cirros 192.168.251.12
The authenticity of host '192.168.251.12 (192.168.251.12)' can't be established.
RSA key fingerprint is 80:bc:58:4c:04:a6:a7:a4:0e:58:e1:0b:8d:55:e0:45.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.251.12' (RSA) to the list of known hosts.
cirros@192.168.251.12's password:
$

Good I'm in.

$ exit







Next I looked for a public key I already generated from my host machine

[root@centos-6-5-openstack .ssh(keystone_admin)]# ls
authorized_keys  id_rsa  id_rsa.pub  known_hosts










So now all I did was scp the file to the authorized_keys directory of the VM

[root@centos-6-5-openstack .ssh(keystone_admin)]# ip netns exec qdhcp-a5958652-7348-436f-8aff-2c9ebd7dd9f7 scp id_rsa.pub cirros@192.168.251.12:.ssh/authorized_keys
cirros@192.168.251.12's password:
id_rsa.pub                                                                              100%  407     0.4KB/s   00:00   

Now I can ssh with the key-pair without having to type in my password.

[root@centos-6-5-openstack .ssh(keystone_admin)]# ip netns exec qdhcp-a5958652-7348-436f-8aff-2c9ebd7dd9f7 ssh -l cirros 192.168.251.12

$ whoami
cirros

I'm still going to try to figure this out. Hopefully I'll be able to work this out the regular way.

Thursday, May 15, 2014

Neutron Network Namespaces

Warning: The following is a rant of my observations about Openstack neutron.

They shouldn't call it Network Namespaces. They should call it overly complex naming convention.
I've been trying to wrap my head around the networking portion, aka Neutron, of OpenStack. What I've noticed is how ridiculously lousy the Horizon GUI is when trying to troubleshoot any issues. Almost anything useful is accessible through the CLI. What's the purpose of Cloud computing if you have to fallback to the cli to do anything?

When I build a VM, say VM1 on network net1 , I have no visibility about the virtual interfaces that it uses.

For example: Say I want to ping the virtual interface the VM created from the Openstack server. It should be pretty simple right? You should be able to do something like ping <network-name> ip address.

In order to do this you have to use this command:

ip netns - which I believe is short for network namespace

First, you need to know what the networkUUID.

You can list the network objects that were created by the namespace as follows:

# ip netns list
qrouter-ed4afc1b-06ab-417e-a7e2-d5be13b822af
qdhcp-4dc834f5-e759-4d79-acf0-780768f1fa86
qdhcp-0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48
qdhcp-a5958652-7348-436f-8aff-2c9ebd7dd9f7
qdhcp-dc49c1a5-07d0-4225-bea5-02316aec3a42

The structure of the networkUUID looks like this

qdhcp-<networkUUID>

WHAT the hell? That's not a useful name. That's an ID.

You can find this under this directory:

[root@centos-6-5-openstack ~(keystone_admin)]# ls /var/lib/neutron/dhcp/
0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48  a5958652-7348-436f-8aff-2c9ebd7dd9f7
4dc834f5-e759-4d79-acf0-780768f1fa86  dc49c1a5-07d0-4225-bea5-02316aec3a42

and then peer into it's contents

[root@centos-6-5-openstack ~(keystone_admin)]# cat /var/lib/neutron/dhcp/0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48/host
fa:16:3e:b8:98:40,host-20-20-0-11.openstacklocal,20.20.0.11
fa:16:3e:b5:6f:26,host-20-20-0-10.openstacklocal,20.20.0.10

You can also try to do this via this command:

[root@centos-6-5-openstack ~(keystone_admin)]# ip netns exec qdhcp-0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48 ip a
30: tapafe229a7-2e: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:b8:98:40 brd ff:ff:ff:ff:ff:ff
    inet 20.20.0.11/24 brd 20.20.0.255 scope global tapafe229a7-2e
    inet6 fe80::f816:3eff:feb8:9840/64 scope link
       valid_lft forever preferred_lft forever
33: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

It won't give show you the VM's ip, but should show you the subnet it's on.

One other place to look:

[root@centos-6-5-openstack ~(keystone_admin)]# neutron net-list
+--------------------------------------+---------+-------------------------------------------------------+
| id                                   | name    | subnets                                               |
+--------------------------------------+---------+-------------------------------------------------------+
| 0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48 | net1   | d4bf516f-135c-4c7f-ba7e-363cb6c7d307 20.20.0.0/24     |
| 1f438ff9-43cf-4eb4-8b92-a385dc1dff8d | public  | 8942189b-8fbf-44e9-adbb-d62dd0d27015 192.168.250.0/24 |
| dc49c1a5-07d0-4225-bea5-02316aec3a42 | private | 6d67e2de-7f63-454d-9e88-fe33e6121b7b 10.0.0.0/24      |
+--------------------------------------+---------+-------------------------------------------------------+

So once I have the network id I can issue the following command:

[root@centos-6-5-openstack ~(keystone_admin)]# ip netns exec qdhcp-0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48 ping 20.20.0.10
PING 20.20.0.10 (20.20.0.10) 56(84) bytes of data.
64 bytes from 20.20.0.10: icmp_seq=1 ttl=64 time=29.5 ms
64 bytes from 20.20.0.10: icmp_seq=2 ttl=64 time=15.0 ms
^C
--- 20.20.0.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1534ms
rtt min/avg/max/mdev = 15.079/22.301/29.523/7.222 ms

This is such a pain. What if the number of tenants, networks and VMs is huge? Why can't Openstack utilize the network name as part of the network UUid?