Open Stack

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.haley at 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: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
> >
> 
> 
> _____________________________________________________________________
> _____
> 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