Public bug reported:

[Existing problem]
Currently, when the User wants to allow multiple VMs to access external 
networks (e.g. internet), he can either assign a floating IP to each VM (DNAT), 
or assign just one floating IP to the router that he uses as a default gateway 
for all the VMs (SNAT).

The downside of DNAT is that the number of external IP addresses is very
limited, and therefore it requires that the User either "switch"
floating IPs between VMs (complicated), or obtain enough external IPs
(expensive).

The downside of SNAT is that all outbound traffic from the VMs that use
it as default gateway will go through the server that hosts the router
(a Neutron Network Node), effectively creating a network bottleneck and
single point of failure for multiple VMs.

[Proposal]
Add an additional SNAT model (henceforth referred to as "Local SNAT") that 
places the NAT/PAT on each Compute Node, and lets the underlying networking 
infrastructure decide how to handle the outbound traffic. In order for this 
design to work in a real world deployment, the underlying networking 
infrastructure needs to allow Compute Nodes to access the external network 
(e.g. WWW).

When the Compute Node can route outbound traffic, VMs hosted on it do
not need to be routed through the Network Node. Instead, they will be
routed locally from the Compute Node.

This will require changes to the local routing rules on each Compute
Node.

The change should be reflected in Neutron database, as it affects router
Ports configuration and should be persistent.

[Benefits]
Improvement is to be expected, since outbound traffic is routed locally and not 
through the Network Node effectively reducing network bottleneck on Network 
Node. 


[Functionality difference]
The main functionality difference between the Neutron reference implementation 
of SNAT and "Local SNAT", is that with Neutron SNAT the User reserves an 
external IP address (from a limited pre-allocated pool), which is used to 
masquerade multiple VMs of that same user (therefore, sharing the same external 
IP).

With the "Local SNAT" solution, in contrast, the User may not reserve
any external IP in Neutron, and the "external IP" from which each VM
will go out is arbitrarily selected by the underlying networking
infrastructure (similar to the way external IPs are allocated to home
internet routers, or to mobile phones).

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

** Summary changed:

- Add support for local SNAT
+ [RFE] Add support for local SNAT

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1639566

Title:
  [RFE] Add support for local SNAT

Status in neutron:
  New

Bug description:
  [Existing problem]
  Currently, when the User wants to allow multiple VMs to access external 
networks (e.g. internet), he can either assign a floating IP to each VM (DNAT), 
or assign just one floating IP to the router that he uses as a default gateway 
for all the VMs (SNAT).

  The downside of DNAT is that the number of external IP addresses is
  very limited, and therefore it requires that the User either "switch"
  floating IPs between VMs (complicated), or obtain enough external IPs
  (expensive).

  The downside of SNAT is that all outbound traffic from the VMs that
  use it as default gateway will go through the server that hosts the
  router (a Neutron Network Node), effectively creating a network
  bottleneck and single point of failure for multiple VMs.

  [Proposal]
  Add an additional SNAT model (henceforth referred to as "Local SNAT") that 
places the NAT/PAT on each Compute Node, and lets the underlying networking 
infrastructure decide how to handle the outbound traffic. In order for this 
design to work in a real world deployment, the underlying networking 
infrastructure needs to allow Compute Nodes to access the external network 
(e.g. WWW).

  When the Compute Node can route outbound traffic, VMs hosted on it do
  not need to be routed through the Network Node. Instead, they will be
  routed locally from the Compute Node.

  This will require changes to the local routing rules on each Compute
  Node.

  The change should be reflected in Neutron database, as it affects
  router Ports configuration and should be persistent.

  [Benefits]
  Improvement is to be expected, since outbound traffic is routed locally and 
not through the Network Node effectively reducing network bottleneck on Network 
Node. 

  
  [Functionality difference]
  The main functionality difference between the Neutron reference 
implementation of SNAT and "Local SNAT", is that with Neutron SNAT the User 
reserves an external IP address (from a limited pre-allocated pool), which is 
used to masquerade multiple VMs of that same user (therefore, sharing the same 
external IP).

  With the "Local SNAT" solution, in contrast, the User may not reserve
  any external IP in Neutron, and the "external IP" from which each VM
  will go out is arbitrarily selected by the underlying networking
  infrastructure (similar to the way external IPs are allocated to home
  internet routers, or to mobile phones).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1639566/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to