Open Stack

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)
>