[openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT distributed?

Carl Baldwin carl at ecbaldwin.net
Tue Mar 29 16:07:35 UTC 2016


On Mon, Mar 28, 2016 at 7:25 PM, Wang, Yalei <yalei.wang at intel.com> wrote:
> Someone is working on full distributed SNAT, like this:
>
> https://www.openstack.org/summit/tokyo-2015/videos/presentation/network-node-is-not-needed-anymore-completed-distributed-virtual-router
>
> From: Zhi Chang [mailto:changzhi at unitedstack.com]
> Sent: Saturday, March 26, 2016 1:53 PM
> To: openstack-dev
> Subject: [openstack-dev] [neutron][dvr]Why keep SNAT centralized and DNAT
> distributed?
>
> hi all.
>
>     I have some questions about NAT in DVR.
>
>     In Neutron, we provide two NAT types. One is SNAT, we can associate a
> floating ip to router so that all vms attached this router can connect
> external network. The other NAT types is DNAT, we can connect a vm which
> associated floating ip from external network.
>
>      Question A, Why keep SNAT centralized? We put the SNAT namespace in
> compute node which running DVR l3 agent, don't we?

The reason it was kept distributed was to maintain the current
behavior of a Neutron router where SNAT is through a single address
associated with the router.  Many other models were discussed on an
etherpad [1] long ago but I couldn't really get good consensus or
traction on any of the alternatives.

Folks were generally polarized around the idea of centralizing SNAT
around a compute host rather than a router.  Some people thought that
this was the obvious solution.  Yet others saw this as a non-starter
because it would mix traffic from different tenants on the same SNAT
address.

>      Question B, Why keep DNAT distributed? I think we can keep snat
> namespace and fip namespace in one node. Why not keep DNAT and SNAT
> together?

The whole point of distributing north/south traffic was to distribute
DNAT for floating IPs.  Maybe I don't understand your question.

Carl

[1] https://etherpad.openstack.org/p/decentralized-snat



More information about the OpenStack-dev mailing list