Open Stack

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:carl at 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
>> <miyagishi.t at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>