If I understand correctly, for southbound traffic there would be hair-pinning via the L3 agent that the upstream router happened to pick out of the ECMP group since it doesn't know where the hypervisors are. On the other hand northbound traffic could egress directly (assuming an l3 agent is running on each compute node in the DVR fashion).
If we went down this route, we would require a dynamic routing protocol to run between the agents and the upstream router. Additionally, we would have to tweak our addressing scheme a bit so the l3 agents could have separate addresses to use for their BGP session (or whatever routing protocol we choose) since the gateway address would be shared amongst them. Did I get what you were proposing correctly? On Wed, Feb 18, 2015 at 5:28 PM, Angus Lees <g...@inodes.org> wrote: > On Mon Feb 16 2015 at 9:37:22 PM Kevin Benton <blak...@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 < >> robe...@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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev