Ask Your Question
0

Why is it that CirrOS instances connect, but others don't?

asked 2019-08-23 18:10:47 -0600

dabovard gravatar image

Hello everyone, I am new to OpenStack and have been learning the ropes (rather slowly). I have spent the past week trying to troubleshoot why my instances aren't establishing a connection to the network I have created. I have a minimal 2 node architecture and I was successfully able to establish connection between two CirrOS images I created. The two CirrOS images get assigned an IP and establish connection, however everything else doesn't.

I had installed the proper VirtIO drivers and was able to get them running locally on my Virtual Machine Manager where I run my 2 nodes. I thought maybe it was because I had not configured a security group at all. After configuring the security group to allow traffic for ICMP and other TCP/UDP protocols such as DHCP/DNS/HTTP/etc, I am still not able to establish a connection with images that I create whether its CentOS7 or Windows XP/7 (with cloudbase-init). I have tried many different combinations of starting instances with/without cloudbase and/or using sysprep.

No matter which guide I follow to create and upload an image to OpenStack, I can never seem to get an instance fully up and running with network connectivity. With so many people successful at creating images/uploading images/running instances, I must be missing something fundamental about OpenStack image creation and/or network configuration. Whether it be that the instances are run extremely slow or not, I still can't get connectivity on anything other than a CirrOS instance.

Does anybody have any advice? I doubt anybody has a fix or outright solution for me. Perhaps someone could point me in the direction of some cohesive guides/turorials. Thanks for any help, and I apologize for the long-winded explanation.

edit retag flag offensive close merge delete

Comments

1

You don't provide any details of your instances' network connections, neither Cirros nor the others. You also don't say from where to where you try to connect, how you try to connect, and what the symptoms are (error message, timeout, command just hangs ...). Also, where do the images come from?

Bernd Bausch gravatar imageBernd Bausch ( 2019-08-23 22:37:37 -0600 )edit
1

One advice is to check instances' console logs. They should tell you whether an instance actually acquires the IP address. If not, there should be error messages about DHCP not being successful etc.

You can also enter the DHCP server namespace on the controller and try to connect.

Bernd Bausch gravatar imageBernd Bausch ( 2019-08-23 22:39:14 -0600 )edit
1

Maybe it's not the image or instance, maybe it's your network, how did you set it up? What type, self service or provider network?, Is it flat, vxlan/vlan, gre?

vblando gravatar imagevblando ( 2019-08-25 13:36:01 -0600 )edit

My apologies for not providing more information. I am running a self-service network structure that was detailed in the neutron installation guide, which I believe uses a VXLAN network overlay. I am not able to ping any of the CirrOS (working) machines, and the IP is not being assigned.

dabovard gravatar imagedabovard ( 2019-08-26 11:49:17 -0600 )edit

The systems can function in every way except connect to the private network I have created. It is a very simple subnet with 3 computers on it. I will check out the neutron logs. Is there a part of the configuration where you choose the type of network you use? Whether it is vlan/vxlan/flat/gre?

dabovard gravatar imagedabovard ( 2019-08-26 11:54:21 -0600 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2019-08-28 14:19:13 -0600

dabovard gravatar image

While the fix is inconsistent, I managed to figure out what the problem was. The problem was due to the neutron agents not being able to communicate properly with the internal rabbitMQ messaging queue and mariaDB database over ports 5672 and 3306 respectively. I had added rules to accept traffic over these ports, except for some reason I could not get the iptables rules to persist after a reboot despite changing the settings in /etc/sysconfig/iptables-config. So I added the rules:

  1. "iptables -A INPUT -p tcp -m tcp --dport 5672 -j ACCEPT"

  2. "iptables -A INPUT -p tcp -m tcp --dport 3306 -j ACCEPT"

and saved the rules to a file using: "iptables-save > /etc/iptables.conf", and then added "iptables-restore < /etc/iptables.conf" to the /etc/rc.d/rc.local file to start upon a system reboot.

To get any of my instances to connect I still have to manually restart all of the neutron services (still looking for a fix to this). But my initial problem was connectivity and I have solved that, the other problems that came subsequently are for a separate question. Thanks everyone for the pointers, it helped me find my own solution.

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: 2019-08-23 18:10:47 -0600

Seen: 42 times

Last updated: Aug 28