Inconsistent connectivity between instances with floating IPs

[Brent Eagles]

Communication between instances on the same fixed network using assigned floating IP addresses does not behave in a consistent fashion. In all-in-one and (possibly) multi-host deployments, creating connections using floating IPs appear to work (at least within the confines of the security groups). However, with standalone compute nodes, instances that are on the same compute node cannot successfully create a connection. Routing and matching endpoints seem to be at the core of this issue.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/grizzly
Review: https://review.openstack.org/29268

[Vish Ishaya (vishvananda)]

Master patch: https://review.openstack.org/#/c/28815/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/28815
Committed: http://github.com/openstack/nova/commit/314c419323ddd512babc4504ef8a4be1e04f2af7
Submitter: Jenkins
Branch: master

commit 314c419323ddd512babc4504ef8a4be1e04f2af7
Author: Brent Eagles <email address hidden>
Date: Fri May 10 14:26:24 2013 -0230

    Reverse path SNAT for DNAT floating-ip.

    This patch applies a reverse SNAT rule to allow instances that have an
    assigned floating IP to communicate with other instances in the same
    OpenStack deployment, security group rules permitting. The patch
    allows members of the same private network to communicate with each
    other using their floating-ips in a more consistent fashion. The rule
    also addresses the situation where the target is on another private
    network.

    This will only work for interaction between two servers that both have
    floating IPs assigned to them.

    Specifically, this patch solves the problem where a target server
    "sees" the private address of the client. By SNAT'ing to the client's
    floating-IP, the "sees" the correct reply address and the reverse
    route follows the same path that an actual external connection would
    take. The SNAT ONLY occurs if a DNAT occurred before hand, allowing
    communication on private networks using private IPs to remain fully
    private and internal. The limitation is of course if a DNAT occurs for
    other reasons, there may be issues.

    Resolves bug 1178745

    Change-Id: I55b7131cff5fd5a2ebf826945370d4d550e74136

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/29268
Committed: http://github.com/openstack/nova/commit/b8c434630d31f49ae0e9686ddfac8f25acf117b1
Submitter: Jenkins
Branch: stable/grizzly

commit b8c434630d31f49ae0e9686ddfac8f25acf117b1
Author: Brent Eagles <email address hidden>
Date: Fri May 10 14:26:24 2013 -0230

    Reverse path SNAT for DNAT floating-ip.

    This patch applies a reverse SNAT rule to allow instances that have an
    assigned floating IP to communicate with other instances in the same
    OpenStack deployment, security group rules permitting. The patch
    allows members of the same private network to communicate with each
    other using their floating-ips in a more consistent fashion. The rule
    also addresses the situation where the target is on another private
    network.

    This will only work for interaction between two servers that both have
    floating IPs assigned to them.

    Specifically, this patch solves the problem where a target server
    "sees" the private address of the client. By SNAT'ing to the client's
    floating-IP, the "sees" the correct reply address and the reverse
    route follows the same path that an actual external connection would
    take. The SNAT ONLY occurs if a DNAT occurred before hand, allowing
    communication on private networks using private IPs to remain fully
    private and internal. The limitation is of course if a DNAT occurs for
    other reasons, there may be issues.

    Resolves bug 1178745

    Change-Id: I55b7131cff5fd5a2ebf826945370d4d550e74136
    (cherry picked from commit 314c419323ddd512babc4504ef8a4be1e04f2af7)

[John Kim (kotux)]

The branch has been pending for a few weeks. Can someone review it?