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