Open Stack

On Mon Feb 16 2015 at 9:37:22 PM Kevin Benton <blak111 at gmail.com> wrote:

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

(Just to continue this thought experiment)

The L3 agents that would need to forward ingress traffic to the right
hypervisor only need to know which [IP+port range] has been assigned to
which hypervisor.  This information is fairly static, so these forwarders
are effectively stateless and can be trivially replicated to deal with the
desired ingress volume and reliability.

When I've built similar systems in the past, the easy way to interface with
the rest of the provider network was to use whatever dynamic routing
protocol was already in use, and just advertise multiple ECMP routes for
the SNAT source IPs from the forwarders (ideally advertising from the
forwarders themselves, so they stop if there's a connectivity issue).  All
the "cleverness" then happens on the forwarding hosts (we could call them
"L3 agents").  It's simple and works well, but I agree we have no precedent
in neutron at present.

On Mon, Feb 16, 2015 at 12:33 AM, Robert Collins <robertc at robertcollins.net>
> wrote:
>>
>> Or a pool of SNAT addresses ~= to the size of the hypervisor count.
>
>
Oh yeah. If we can afford to assign a unique SNAT address per hypervisor
then we're done - at that point it really is just like floating-ips.

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150219/add0f927/attachment.html>