Open Stack

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:sorlando at 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 <zealot0630 at gmail.com<mailto: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<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 at lists.openstack.org<mailto: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/007ebb80/attachment.html>