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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
