[openstack-dev] [Neutron] DVR SNAT shortcut

Wuhongning wuhongning at huawei.com
Fri Jun 27 02:05:46 UTC 2014


________________________________________
From: Zang MingJie [zealot0630 at gmail.com]
Sent: Thursday, June 26, 2014 6:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut

On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack <jack.mccann at hp.com> wrote:
>> >> If every compute node is
>> >> assigned a public ip, is it technically able to improve SNAT packets
>> >> w/o going through the network node ?
>>
>> It is technically possible to implement default SNAT at the compute node.
>>
>> One approach would be to use a single IP address per compute node as a
>> default SNAT address shared by all VMs on that compute node.  While this
>> optimizes for number of external IPs consumed per compute node, the downside
>> is having VMs from different tenants sharing the same default SNAT IP address
>> and conntrack table.  That downside may be acceptable for some deployments,
>> but it is not acceptable in others.

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


>>
>> Another approach would be to use a single IP address per router per compute
>> node.  This avoids the multi-tenant issue mentioned above, at the cost of
>> consuming more IP addresses, potentially one default SNAT IP address for each
>> VM on the compute server (which is the case when every VM on the compute node
>> is from a different tenant and/or using a different router).  At that point
>> you might as well give each VM a floating IP.
>>
>> Hence the approach taken with the initial DVR implementation is to keep
>> default SNAT as a centralized service.
>>
>> - Jack
>
>> -----Original Message-----
>> From: Zang MingJie [mailto:zealot0630 at gmail.com]
>> Sent: Wednesday, June 25, 2014 6:34 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut
>>
>> On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong <gongysh at unitedstack.com> wrote:
>> > Hi,
>> > for each compute node to have SNAT to Internet, I think we have the
>> > drawbacks:
>> > 1. SNAT is done in router, so each router will have to consume one public IP
>> > on each compute node, which is money.
>>
>> SNAT can save more ips than wasted on floating ips
>>
>> > 2. for each compute node to go out to Internet, the compute node will have
>> > one more NIC, which connect to physical switch, which is money too
>> >
>>
>> Floating ip also need a public NIC on br-ex. Also we can use a
>> separate vlan to handle the network, so this is not a problem
>>
>> > So personally, I like the design:
>> >  floating IPs and 1:N SNAT still use current network nodes, which will have
>> > HA solution enabled and we can have many l3 agents to host routers. but
>> > normal east/west traffic across compute nodes can use DVR.
>>
>> BTW, does HA implementation still active ? I haven't seen it has been
>> touched for a while
>>
>> >
>> > yong sheng gong
>> >
>> >
>> > On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie <zealot0630 at gmail.com> wrote:
>> >>
>> >> Hi:
>> >>
>> >> In current DVR design, SNAT is north/south direction, but packets have
>> >> to go west/east through the network node. If every compute node is
>> >> assigned a public ip, is it technically able to improve SNAT packets
>> >> w/o going through the network node ?
>> >>
>> >> SNAT versus floating ips, can save tons of public ips, in trade of
>> >> introducing a single failure point, and limiting the bandwidth of the
>> >> network node. If the SNAT performance problem can be solved, I'll
>> >> encourage people to use SNAT over floating ips. unless the VM is
>> >> serving a public service
>> >>
>> >> --
>> >> Zang MingJie
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list