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

The structure of the networkUUID looks like this


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

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 brd 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 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     |
| 1f438ff9-43cf-4eb4-8b92-a385dc1dff8d | public  | 8942189b-8fbf-44e9-adbb-d62dd0d27015 |
| dc49c1a5-07d0-4225-bea5-02316aec3a42 | private | 6d67e2de-7f63-454d-9e88-fe33e6121b7b      |

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
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=29.5 ms
64 bytes from icmp_seq=2 ttl=64 time=15.0 ms
--- 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?

No comments:

Post a Comment