Ask Your Question
1

DevStack with Neutron: Cannot ping twice

asked 2013-10-07 10:31:30 -0500

Torsten Schlabach gravatar image

I encounter some very strange behaviour in a test setup using DevStack inside a VM. My VM is Ubuntu 12.04.3 and I have been using these guides:

  • http://devstack.org/guides/single-vm.html
  • https://wiki.openstack.org/wiki/NeutronDevstack

My goal is to launch an instance, associate a floating IP to it and be able to access that instance.

So I have created my internal network, router, set the public network as the gateway for the router, launched my instance (connected to the internal network), associated a floating IP, all fine so far.

I end with a floating IP of 172.24.4.229 in my example.

So I try to ping my instance using the floating IP:

devstack@devstack-VirtualBox:~$ ping 172.24.4.229
64 bytes from 172.24.4.229: icmp_req=932 ttl=64 time=0.168 ms
64 bytes from 172.24.4.229: icmp_req=933 ttl=64 time=0.153 ms
64 bytes from 172.24.4.229: icmp_req=934 ttl=64 time=0.166 ms
64 bytes from 172.24.4.229: icmp_req=935 ttl=64 time=0.135 ms
64 bytes from 172.24.4.229: icmp_req=936 ttl=64 time=0.153 ms

I can let that ping go on forever; I have tried 10+ minutes, keeps answering.

Now comes the fun part. I press <ctrl><c> and try again:</c></ctrl>

devstack@devstack-VirtualBox:~$ ping 172.24.4.229
PING 172.24.4.229 (172.24.4.229) 56(84) bytes of data.
^C
--- 172.24.4.229 ping statistics ---
445 packets transmitted, 0 received, 100% packet loss, time 445536ms

In other words, as soon as I interrupt the ping, I cannot start over again unless I disassociate the floating IP and associate it again.

I also tried to start a second ping in a new window while the first ping was ongoing: No luck.

So I wanted to know if this is only about ping, so I looked at SSH, starting out without the floating IP:

ssh: connect to host 172.24.4.229 port 22: No route to host

Agree. Now let's associate the floating IP and try again:

devstack@devstack-VirtualBox:~$ ssh 172.24.4.229
ssh: connect to host 172.24.4.229 port 22: Connection refused

I am wondering a bit about the "Connection refused" as my instance should have SSH enabled, but never mind. Just immediately try again:

devstack@devstack-VirtualBox:~$ ssh 172.24.4.229
ssh: connect to host 172.24.4.229 port 22: Connection timed out

Any thoughts about that strange kind of behavior?

Anything to try?

edit retag flag offensive close merge delete

Comments

Very interesting. Your ping times are really low - I'm pretty sure it was not the instance that send the replies. Does the l3-agent screen show any problems? How recent is the devstack clone? What is your localrc?

darragh-oreilly gravatar imagedarragh-oreilly ( 2013-10-07 11:59:59 -0500 )edit

Indeed, ping well below 1 ms, I did not see that myself.

Torsten Schlabach gravatar imageTorsten Schlabach ( 2013-10-07 13:41:21 -0500 )edit

l3-agent screen? Actually a **lot** of activity there, : amqp [-] using channel_id: 1 from (pid=351) __init__ /usr/local/lib/python2.7/dist-packages/amqp/channel.py:70 amqp [-] Channel open from (pid=351) _open_ok /usr/local/lib/python2.7/dist-packages/amqp/channel.py:420

Torsten Schlabach gravatar imageTorsten Schlabach ( 2013-10-07 13:41:37 -0500 )edit

The DevStack clone is exactly from last tuesday; so less than a week old.

Torsten Schlabach gravatar imageTorsten Schlabach ( 2013-10-07 13:42:27 -0500 )edit

localrc: DATABASE_PASSWORD=Stack RABBIT_PASSWORD=Stack SERVICE_TOKEN=Stack SERVICE_PASSWORD=Stack ADMIN_PASSWORD=Stack disable_service n-net enable_service q-svc enable_service q-agt enable_service q-dhcp enable_service q-l3 enable_service q-meta enable_service neutron # O enable_service tempest

Torsten Schlabach gravatar imageTorsten Schlabach ( 2013-10-07 13:44:34 -0500 )edit

2 answers

Sort by ยป oldest newest most voted
0

answered 2013-10-09 04:53:40 -0500

Torsten Schlabach gravatar image

Finally made it work, despite I am still not 100% sure what exactly made the difference.

For sure, watch your Security Group settings. When it says:

Security Groups 
default 
ALLOW IPv4 to 0.0.0.0/0 
ALLOW IPv6 from default 
ALLOW IPv6 to ::/0 
ALLOW IPv4 from default

you may be tempted to think this means "all Ports open in both directions". But it doesn't mean that. I haven't found out yet what "default" means, but it does by no means mean "any". In some newer versions of the Horizon dashboard and / or Neutron networking there are two new terms: Egress and Ingress, which means outbound traffic (originating from the VM instance) and inbound traffic (coming to the VM instance), respectively. The default security group is setup for allowing all outbound traffic but somewhat restricting inbound traffic. And it's not too helpful that the display of the rules is different in different places, so to be on the save side, define your own "allow everything" rules at least for the initial testing purposes.

Second, interestingly enough, it doesn't seem to matter if br-int is up or not, even after taking it down using

ifconfig br-int down

it still worked fine.

So going over the long dialogue with darragh-oreilly the question about ML2 versus OpenVSwitch plugin remains open.

In other words: It works, but I still feel a bit uneasy as I am just not sure why it works now and why exactly it did not work initially. For sure, debugging a Neutron setup should be somehow made easier. Just I don't know yet how.

edit flag offensive delete link more
0

answered 2013-10-09 10:52:28 -0500

darragh-oreilly gravatar image

Each tenant automatically gets their own security group named 'default'. It has rules (by default) that allow all egress traffic from ports assigned to it, and to accept all ingress traffic coming from other ports that are also assigned to it. So if a user boots two instances on the same network with their ports assigned to the default security group, then the two instances will be able to make any outward connection, and they will have full unrestricted access to each other. The default policy is deny, so everything else will be blocked.

Also note that if two different tenants each boot an instance to a shared network with their 'default' group, then the instances won't be able to talk.

https://wiki.openstack.org/wiki/Neutron/SecurityGroups

http://docs.openstack.org/trunk/openstack-network/admin/content/securitygroups.html

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-10-07 10:31:30 -0500

Seen: 1,235 times

Last updated: Oct 09 '13