private instance IPs can only reach public IPs in other regions, not the same region

Bug #1022612 reported by Nick Moffitt
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Opinion
Undecided
Unassigned
nova (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Take three instances in two regions (A and B) such that they are named A1, A2, and B1. A1 is the only instance with a public IP: A2 and B1 only have the standard private IPs they were given. In this situation:

  A1 can reach both of its own interfaces.
  B1 can reach A1's public IP, but not its private IP.
  A2 can reach A1's private IP, but not its public IP.

This last line is counter-intuitive, as B1 can reach A1's public IP just fine. In fact, if we bring a public IP up on B1, A2 can reach B1's public IP without trouble.

Traceroutes halt right out of the gate, which may or may not indicate that this is enforced by nova-network itself.

Tags: canonistack
Revision history for this message
Sidnei da Silva (sidnei) wrote :

FTR, actually A1 can't reach it's public IP either.

Revision history for this message
James Page (james-page) wrote :

Confirmed; instances within a region don't appear to be able to contact public addresses for either themselves or other instances in the same region.

Changed in nova (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Revision history for this message
James Page (james-page) wrote :

This may be pertinent:

http://docs.openstack.org/trunk/openstack-compute/admin/content/associating-public-ip.html

"Note that you cannot SSH to an instance with a public IP from within the same server as the routing configuration won't allow it."

This would explain the reason why 'a1' can't see its own public address; is it possible that a1/a2 are on the same server?

Changed in nova (Ubuntu):
importance: High → Medium
Revision history for this message
Tom Haddon (mthaddon) wrote :

From http://docs.openstack.org/folsom/openstack-compute/admin/content/associating-public-ip.html:

"""
Traffic between VMs using floating IPs:

Note that due to the way floating IPs are implemented using a source NAT (SNAT rule in iptables), inconsistent behaviour of security groups can be seen if VMs use their floating IP to communicate with other virtual machines - particularly on the same physical host. Traffic from VM to VM accross the fixed network does not have this issue, and this is the recommended path. To ensure traffic doesn't get SNATed to the floating range, explicitly set dmz_cidr=x.x.x.x/y. x.x.x.x/y is the range of floating ips for each pool of floating ips you define. This configuration is also necessary to make source_groups work if the vms in the source group have floating ips.
"""

This might help...

Revision history for this message
Joe Gordon (jogo) wrote :

Are a1/a2 on the same host? what version of nova etc?

Changed in nova:
status: New → Incomplete
Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

Joe Gordon: Are you unable to reproduce this? We found documentation of this behaviour in openstack's official Web pages. Is that not enough?

Revision history for this message
Nick Moffitt (nick-moffitt) wrote :

If anything, this looks related to bug #1178745

Revision history for this message
Joe Gordon (jogo) wrote :

Nick, no documentation of the behavior does not mean the behavior still exists in the code, so it is not enough.

Revision history for this message
Joe Gordon (jogo) wrote :

AFAIK this is a design issue with nova-network that isn't easy to fix. The preffered way forward is to Neutron.

Joe Gordon (jogo)
Changed in nova:
status: Incomplete → Opinion
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.