[openstack-dev] Fwd: [Neutron][DVR]Neutron distributed SNAT

Kevin Benton blak111 at gmail.com
Mon Feb 16 10:35:29 UTC 2015


>Or a pool of SNAT addresses ~= to the size of the hypervisor count.

This had originally come up as an option in the early DVR discussions. IIRC
it was going to be a tunable parameter since it results in a tradeoff
between spent public addresses and "distributed-ness". However, due to time
constraints and complexity, the burning of extra IPs to distribute SNAT
wasn't implemented because it required changes to the data model (multiple
IPs per router gateway interface) and changes to when IPs were assigned
(dynamically adding more IPs to the gateway interface as tenant ports were
instantiated on new nodes). Someone from the DVR team can correct me if I'm
missing the reasons behind some of these decisions.


>Conntrack synchronisation gets us HA on the SNAT node, but that's a long
way from distributed SNAT.

Definitely, I was not paying close attention and thought this thread was
just about the HA of the SNAT node.

>It's basically very much like floating IPs, only you're handing out a
sub-slice of a floating-IP to each machine - if you like.

This requires participation of the upstream router (L4 policy routing
pointing to next hops that distinguish each L3 agent) or intervention on
the switches between the router an L3 agents (a few OpenFlow rules would
make this simple). Both approaches need to adapt to L3 agent changes so
static configuration is not adequate. Unfortunately, both of these are
outside of the control of Neutron so I don't see an easy way to push this
state in a generic fashion.



On Mon, Feb 16, 2015 at 12:33 AM, Robert Collins <robertc at robertcollins.net>
wrote:

> On 16 February 2015 at 21:29, Angus Lees <gus at inodes.org> wrote:
> > Conntrack synchronisation gets us HA on the SNAT node, but that's a long
> way
> > from distributed SNAT.
> >
> > Distributed SNAT (in at least one implementation) needs a way to allocate
> > unique [IP + ephemeral port ranges] to hypervisors, and then some sort of
> > layer4 loadbalancer capable of forwarding the ingress traffic to that IP
> > back to the right hypervisor/guest based on the ephemeral port range.
> It's
> > basically very much like floating IPs, only you're handing out a
> sub-slice
> > of a floating-IP to each machine - if you like.
>
> Or a pool of SNAT addresses ~= to the size of the hypervisor count.
>
> -Rob
>
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __________________________________________________________________________
> 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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150216/981856e7/attachment.html>


More information about the OpenStack-dev mailing list