<div dir="ltr">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.<div>While DVR clearly does a lot more than multi host, keeping SNAT centralized only might not fully satisfy this requirement.</div>
<div>Indeed nova-network offers SNAT at the compute node thus achieving distribution of N-S traffic.</div><div><br></div><div>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.</div>
<div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>Salvatore</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 July 2014 10:45, Zang MingJie <span dir="ltr"><<a href="mailto:zealot0630@gmail.com" target="_blank">zealot0630@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Although the SNAT DVR has some trade off, I still think it is<br>
necessary. Here is pros and cons for consideration:<br>
<br>
pros:<br>
<br>
save W-E bandwidth<br>
high availability (distributed, no single point failure)<br>
<br>
cons:<br>
<br>
waste public ips (one ip per compute node vs one ip per l3-agent, if<br>
double-SNAT implemented)<br>
different tenants may share SNAT source ips<br>
compute node requires public interface<br>
<br>
Under certain deployment, the cons may not cause problems, can we<br>
provide SNAT DVR as a alternative option, which can be fully<br>
controlled by could admin ? The admin chooses whether use it or not.<br>
<div class="im HOEnZb"><br>
>> To resolve the problem, we are using double-SNAT,<br>
><br>
>> first, set up one namespace for each router, SNAT tenant ip ranges to<br>
>> a separate range, say <a href="http://169.254.255.0/24" target="_blank">169.254.255.0/24</a><br>
><br>
>> then, SNAT from <a href="http://169.254.255.0/24" target="_blank">169.254.255.0/24</a> to public network.<br>
><br>
>> We are already using this method, and saved tons of ips in our<br>
>> deployment, only one public ip is required per router agent<br>
><br>
> 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.<br>

><br>
> 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:<br>

><br>
> 1. N-S traffic is usually much less than W-E traffic, do we really need distribute N-S traffic besides W-E traffic?<br>
> 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)<br>
><br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>