Salvatore, There is FIP distribution at the agent level, in the sense the N/S of FIP for a VM will be hosted on the same compute node. We centralized SNAT from feedback by others. The current design and code only supports centralized SNAT for DVR routers. The design could be modified to allow for distributed SNAT as an option but would be a tough task to get in for the first release of DVR support. We wanted to come in with the basic support first.
Yours, Michael Smith Hewlett-Packard Company HP Networking R&D 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747 PC Phone: 916 540-1884 Ph: 916 785-0918 Fax: 916 785-1199 From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Thursday, July 03, 2014 3:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut 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 <zealot0...@gmail.com<mailto:zealot0...@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<http://169.254.255.0/24> > >> then, SNAT from 169.254.255.0/24<http://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<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
