yahoo-eng-team team mailing list archive

[Rodolfo Alonso <1639566@xxxxxxxxxxxxxxxxxx>]

Bug closed due to lack of activity, please feel free to reopen if
needed.

** Changed in: neutron
       Status: Triaged => Won't Fix

-- 
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:
  Won't Fix

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