[openstack-dev] [Neutron] What are problems of Distributed SNAT?

Miyagishi, Takanori miyagishi.t at jp.fujitsu.com
Fri Jul 24 12:17:10 UTC 2015


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



More information about the OpenStack-dev mailing list