Re: [openstack-dev] [Neutron] What are problems of Distributed SNAT?
Hi, Brian Haley This is a huge increase in IP consumption from today though, which is only [number of tenants], I'm not sure most deployers have [tenants * compute nodes] IPs at their disposal. And in the worst-case this becomes Assign a Floating IP to all VMs. Before suggest my proposal, I considered following proposal: * True Distributed SNAT * Carrier Grade NAT These proposal listed on etherpad. These can solve IP consumption problem. However, these need configure on upstream router to send to the correct node. It is no precedent in Neutron. And these have other problems: * True Distributed SNAT I don't understand how to distinguish l3-agents of same IP address. If using BGP, in my understanding, BGP can't establish peers of same IP address. * Carrier Grade NAT This proposal use ISP shared address on external network. There is also affect on floating IP. Therefore, I suggested my proposal. In ideal case, this proposal can be reduction of IP consumption. However, in some case, this proposal occur high IP consumption as you mentioned. So I also think this proposal is not good. And I can't think best proposal right away... I was considered network performance and avoid single point of failure. Then, I considered case of operate only using floating IP. If can tuning default value of enable_snat we can limit SNAT. Therefore we can operate only using floatingIP. Alternative proposal of Distributed SNAT consider again on or after Mitaka, then I'd like to add tuning parameter of SNAT(enable_snat) in liberty. Best regards, Takanori Miyagishi -Original Message- From: Brian Haley [mailto:brian.ha...@hp.com] Sent: Saturday, July 25, 2015 2:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] What are problems of Distributed SNAT? On 07/24/2015 08:17 AM, Miyagishi, Takanori wrote: Dear Carl, Thank you for your information! I checked the etherpad, and I propose a new idea of Distributed SNAT implementation. Following figure is my idea, Shared SNAT Address per Tenant per Compute Node. I think this is the One IP Address per Router per Host item in the etherpad since each distributed router will consume one IP. +---+---+--+ | |eth| TenantA : TenantB | | +-+-+ : external-network| | | : 10.0.0.0/24 | | +--++--- | || : || ||10.0.0.100: |10.0.0.101 | |+---+ +-+-+ +---+ : +--+---+ +---+ | ++ || R | | SNAT| | R | : | SNAT | | R | | | | |+-+-+ +-+---+-+ +-+-+ : +--+---+ +-+-+ | ... | | | | | | |: | || | | | | | | |: | || ++ | ---+--+--+-- --+--+--+--- : ---+---+--- | Compute Node N | | | : || | +--+--+ +--+--+: +--+--+ | | | VM1 | | VM2 |: | VM3 | | | +-+ +-+: +-+ | +--+ Compute Node 1 * R = Router This picture doesn't look right, there should only be one Router for TenantA even with two VMs on a compute node. You can verify this by looking at how many qrouter namespaces are created, but I only see one on my system. In this idea, SNAT will be created for each tenant. So, IP consumption of this case is: [number of tenant] * [number of compute node] Therefore, this idea can be reduction in IP consumption than create per router per compute node. This is a huge increase in IP consumption from today though, which is only [number of tenants], I'm not sure most deployers have [tenants * compute nodes] IPs at their disposal. And in the worst-case this becomes Assign a Floating IP to all VMs. -Brian And, can be avoid security concerns because don't share SNAT between tenant. I'd like to implement SNAT for Liberty cycle with this idea. Best regards, Takanori Miyagishi -Original Message- From: Carl Baldwin [mailto:c...@ecbaldwin.net] Sent: Tuesday, July 07, 2015 2:29 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] What are problems of Distributed SNAT? Hi, There was some discussion a while back on this subject. Some alternatives were captured on etherpad [1] with pros and cons. Sorry for the delay in responding. The initial implementation of DVR went with centralized SNAT to reduce the scope of the effort and because of a lack consensus around which alternative to choose. Carl
Re: [openstack-dev] [Neutron] What are problems of Distributed SNAT?
Dear Carl, Thank you for your information! I checked the etherpad, and I propose a new idea of Distributed SNAT implementation. Following figure is my idea, Shared SNAT Address per Tenant per Compute Node. +---+---+--+ | |eth| TenantA : TenantB | | +-+-+ : external-network| | | : 10.0.0.0/24 | | +--++--- | || : || ||10.0.0.100: |10.0.0.101 | |+---+ +-+-+ +---+ : +--+---+ +---+ | ++ || R | | SNAT| | R | : | SNAT | | R | | || |+-+-+ +-+---+-+ +-+-+ : +--+---+ +-+-+ | ... || | | | | |: | || || | | | | |: | || ++ | ---+--+--+-- --+--+--+--- : ---+---+--- | Compute Node N | | | : || | +--+--+ +--+--+: +--+--+ | | | VM1 | | VM2 |: | VM3 | | | +-+ +-+: +-+ | +--+ Compute Node 1 * R = Router In this idea, SNAT will be created for each tenant. So, IP consumption of this case is: [number of tenant] * [number of compute node] Therefore, this idea can be reduction in IP consumption than create per router per compute node. And, can be avoid security concerns because don't share SNAT between tenant. I'd like to implement SNAT for Liberty cycle with this idea. Best regards, Takanori Miyagishi -Original Message- From: Carl Baldwin [mailto:c...@ecbaldwin.net] Sent: Tuesday, July 07, 2015 2:29 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] What are problems of Distributed SNAT? Hi, There was some discussion a while back on this subject. Some alternatives were captured on etherpad [1] with pros and cons. Sorry for the delay in responding. The initial implementation of DVR went with centralized SNAT to reduce the scope of the effort and because of a lack consensus around which alternative to choose. Carl [1] https://etherpad.openstack.org/p/decentralized-snat On Fri, Jun 26, 2015 at 5:02 AM, Miyagishi, Takanori miyagish...@jp.fujitsu.com wrote: Hi all, I'm Takanori Miyagishi. I and Yushiro Furukawa, my co-worker, are planning to implement Distributed SNAT in Liberty cycle. So, I looking for information about Distributed SNAT implementation. For now, I got some information from openstack-dev ML[1][2][3] and etherpad[4]. Would you please let me know if you have any other information. Best regards, Takanori Miyagishi [1] Fwd: [Neutron][DVR]Neutron distributed SNAT: http://lists.openstack.org/pipermail/openstack-dev/2015-February/0564 1 5.html [2] About DVR limit: http://lists.openstack.org/pipermail/openstack-dev/2015-January/05440 7 .html [3] [neutron] dvr l3_snat: http://lists.openstack.org/pipermail/openstack-dev/2014-November/0498 9 3.html [4] https://etherpad.openstack.org/p/YVR-nova-network _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] What are problems of Distributed SNAT?
Hi all, I'm Takanori Miyagishi. I and Yushiro Furukawa, my co-worker, are planning to implement Distributed SNAT in Liberty cycle. So, I looking for information about Distributed SNAT implementation. For now, I got some information from openstack-dev ML[1][2][3] and etherpad[4]. Would you please let me know if you have any other information. Best regards, Takanori Miyagishi [1] Fwd: [Neutron][DVR]Neutron distributed SNAT: http://lists.openstack.org/pipermail/openstack-dev/2015-February/056415.html [2] About DVR limit: http://lists.openstack.org/pipermail/openstack-dev/2015-January/054407.html [3] [neutron] dvr l3_snat: http://lists.openstack.org/pipermail/openstack-dev/2014-November/049893.html [4] https://etherpad.openstack.org/p/YVR-nova-network __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
