Open Stack

I would just add that if I'm not mistaken the DVR work would also include
the features currently offered by nova network's 'multi-host' capability.
While DVR clearly does a lot more than multi host, keeping SNAT centralized
only might not fully satisfy this requirement.
Indeed nova-network offers SNAT at the compute node thus achieving
distribution of N-S traffic.

I agree with Zang's point regarding wasting public IPs. On the other hand
one IP per agent with double SNAT might be a reasonable compromise.
And in that case I'm not sure whether sharing SNAT source IPs among tenants
would have any security implications, so somebody else might comment there.

Summarizing, I think that distributing N-S traffic is important, but I
don't think that to achieve this we'd necessarily need to implement SNAT at
the compute nodes. I have reviewed the l3 agent part of the DVR work, it
seems that there will be floating IP distribution at the agent level - but
I could not understand whether there will be also SNAT distribution.

Salvatore



On 3 July 2014 10:45, Zang MingJie <zealot0630 at gmail.com> wrote:

> Although the SNAT DVR has some trade off, I still think it is
> necessary. Here is pros and cons for consideration:
>
> pros:
>
> save W-E bandwidth
> high availability (distributed, no single point failure)
>
> cons:
>
> waste public ips (one ip per compute node vs one ip per l3-agent, if
> double-SNAT implemented)
> different tenants may share SNAT source ips
> compute node requires public interface
>
> Under certain deployment, the cons may not cause problems, can we
> provide SNAT DVR as a alternative option, which can be fully
> controlled by could admin ? The admin chooses whether use it or not.
>
> >> To resolve the problem, we are using double-SNAT,
> >
> >> first, set up one namespace for each router, SNAT tenant ip ranges to
> >> a separate range, say 169.254.255.0/24
> >
> >> then, SNAT from 169.254.255.0/24 to public network.
> >
> >> We are already using this method, and saved tons of ips in our
> >> deployment, only one public ip is required per router agent
> >
> > Functionally it could works, but break the existing normal OAM pattern,
> which expecting VMs from one tenant share a public IP, but share no IP with
> other tenant. As I know, at least some customer don't accept this way, they
> think VMs in different hosts appear as different public IP is very strange.
> >
> > In fact I severely doubt the value of N-S distributing in a real
> commercialized production environment, including FIP. There are many things
> that traditional N-S central nodes need to control: security, auditing,
> logging, and so on, it is not the simple forwarding. We need a tradeoff
> between performance and policy control model:
> >
> > 1. N-S traffic is usually much less than W-E traffic, do we really need
> distribute N-S traffic besides W-E traffic?
> > 2. With NFV progress like intel DPDK, we can build very cost-effective
> service application on commodity x86 server (simple SNAT with 10Gbps/s per
> core at average Internet packet length)
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140703/15a0c901/attachment.html>