Open Stack

Hi,

I found this message in my backlog from when I was at the summit.
Sorry for the delay in responding.

The "default SNAT" or "dynamic SNAT" use case is one of the last
details being worked in the DVR subteam.  That may be why you do not
see any code around this in the patches that have been submitted.
Outbound traffic that will use this SNAT address will first enter the
IR on the compute host.  In the IR, it will not match against any of
the static SNAT addresses for floating IPs.  At that point the packet
will be redirected to another port belonging to the central component
of the DVR.  This port has an IP address  different from the default
gateway address (e.g. 192.168.1.2 instead of 192.168.1.1).  At this
point, the packet will go back out to br-int and but tunneled over to
the network node just like any other intra-network traffic.

Once the packet hits the central component of the DVR on the network
node it will be processed very much like default SNAT traffic is
processed in the current Neutron implementation.  Another
"interconnect subnet" should not be needed here and would be overkill.

I hope this helps.  Let me know if you have any questions.

Carl

On Fri, May 16, 2014 at 1:57 AM, Wuhongning <wuhongning at huawei.com> wrote:
> Hi DVRers,
>
> I didn't see any detail documents or source code on how to deal with routing
> packet from DVR node to SNAT gw node. If the routing table see a outside ip,
> it should be matched with a default route, so for the next hop, which
> interface will it select?
>
> Maybe another standalone "interconnect subnet" per DVR is needed, which
> connect each DVR node and optionally, the SNAT gw node. For packets from dvr
> node->snat node, the interconnect subnet act as the "default route" for this
> host, and the next hop will be the snat node.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>