In an environment with DVR, a VM with floating IP is not reachable (through its floating IP) by another VM with floating IP, while both are on the same private network and same hypervisor.

Bug #1640555 reported by Maxim V. Yefimov
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
neutron
Invalid
Undecided
Unassigned
Nominated for Mitaka by Eugene Nikanorov
Nominated for Newton by Eugene Nikanorov

Bug Description

SSH, HTTP and other services are not accessible from VM1 to VM2 if both these VMs have floating IP assigned, spawned on the same host and on same private network. From VM1, ping to VM2 floating IP is successful, but looks like it isn't reaching VM2 and stops on qr interface.

Steps to reproduce:

VM1 and VM2 runs on the same host.

VM1 has fixed IP of 10.10.3.5, floating-ip=10.17.1.44
VM2 has fixed IP of 10.10.3.17 floating-ip=10.17.1.46

Logged into VM1

# curl 10.17.1.46
curl: (7) Failed to connect to 10.17.1.46 port 80: Connection refused
# ssh 10.17.1.46
connect to host 10.17.1.46 port 22: Connection refused

Same commands are successful from hypervisor console.
Same commands are successful from VM1 if we use private IP (10.10.3.17) for VM2.

Security group

ALLOW IPv4 80/tcp from 0.0.0.0/0
ALLOW IPv4 to 0.0.0.0/0
ALLOW IPv4 22/tcp from 0.0.0.0/0
ALLOW ICMP any from 0.0.0.0/0

Singular case:

VM with floating IP couldn't reach itself by SSH via its floating IP

tags: added: l3-dvr-backlog
Revision history for this message
Atze de Vries (atze-devries) wrote :

This bug is affecting our environment. I would like to add that the same issues exists when VM1 has no floating ip.

Revision history for this message
Atze de Vries (atze-devries) wrote :

Please for now skip my note on isssue without floating ip, it might be causes by a different issue.

Revision history for this message
Andreas Scheuring (andreas-scheuring) wrote :

I can't reproduce this on a fresh devstack. I did the following on my devstack single node:
- Created 2 VMs on the same network
- assigned each a floating ip
- removed all security group rules for the tenant and applied the following:
Ingress IPv4 port 22 from 0.0.0.0/0
Egress IPv4 to 0.0.0.0/0

- logged into the first instance via my floating ip from the hpyervisor
- logged into the second instance from the first instance using the floating ip
- logged into the first instance from the first instance using my the first instances floating ip

Setting this to "Incomplete" as I cannot reproduce it! Maybe I'm missing something in my config. If so, let me know!

Changed in neutron:
status: New → Incomplete
Changed in neutron:
status: Incomplete → Confirmed
Revision history for this message
Rodion Tikunov (rtikunov) wrote :

If connect to VM1 by floatIP it is able to connect to VM2's floatIP but it is unable to connect to VM2's IP [0].

But if connect to VM1 by IP it is unable to connect to VM2's floatIP and able to connect to VM2's IP [1]

[0] http://paste.openstack.org/show/588906/
[1] http://paste.openstack.org/show/588908/

Revision history for this message
Andreas Scheuring (andreas-scheuring) wrote :

Thanks for the paste. I tried it again on devstack master - using the following security groups rules

openstack security group rule create --ingress --dst-port 80 --src-ip 0.0.0.0/0 336f1304-5f1a-4d5d-a23e-3c6ced4dd8ab
openstack security group rule create --egress --src-ip 0.0.0.0/0 336f1304-5f1a-4d5d-a23e-3c6ced4dd8ab
openstack security group rule create --ingress --dst-port 22 --src-ip 0.0.0.0/0 336f1304-5f1a-4d5d-a23e-3c6ced4dd8ab

I couldn't reproduce that! Accessing port 80 worked fine all the time. I once saw the "Connection refused" message, as I was exiting telnet with "e" which terminated the nc on the other end. But after starting netcat again it was working.

The only devstack setting I made was "Q_DVR_MODE=dvr_snat" - Nothing else (besides setting passwords and logfile dirs)

Setting this to Incomplete until the following is provided:

- exact Neutron version that is facing this issue

Changed in neutron:
status: Confirmed → Incomplete
Revision history for this message
Andreas Scheuring (andreas-scheuring) wrote :

@Eugene: If you were able to reproduce that, please share the information how - thanks!

Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

I'm sorry for the confusion, the bug has been found on mitaka, not on master.
You can close it

Changed in neutron:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.