[Openstack-operators] Anyone using Project Calico for tenant networking?

Carl Baldwin carl at ecbaldwin.net
Wed Feb 10 22:50:23 UTC 2016

On Wed, Feb 10, 2016 at 5:06 AM, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:
> In terms of how floating IPs are represented in the Neutron data model:
> currently they require a relationship between an external Network, a
> Router and a tenant Network.  The floating IP pool is defined as a
> subnet on the external Network; each allocated floating IP maps onto one
> of the fixed IPs of the tenant network; and the agent that implements
> the Router does the inbound DNAT between those two.
> As you've written, floating IPs are interesting for external or provider
> networks too, so we'd be interested in an enhancement to the Neutron
> model to allow that, and I believe there are other interested parties
> too.  But that will take time to agree, and it isn't one of my own
> priorities at the moment.

This very thing has been on my mind for a while now.  I have had it on
my list to write a spec for this.  My latest thinking is that it would
be good to be able to mark certain subnets on the network as
'floating' and keep them apart from other subnets on the network.
Then, there are certain cases where floating IPs should work without
the router and the tenant network.

One big complication with doing this is whether the instance will
somehow know that it has the floating IP or will we need to do some
sort of NAT at the port.  I've talked with GoDaddy about how they do
it.  Their instances all understand what a floating IP is and when
they have one so that they can accept traffic to the floating IP
without any bind of address translation.

Another benefit to separating the floating IP pool from the other
addresses on the network is that we could use private addresses for
the non-floating pool so that routers connecting to a
"router:external" network could use them and not consume public IP
addresses.  This has been requested countless times.  This would also
solve the problem that DVR has where it is consuming public IP
addresses for no good reason.

It might be as simple as adding a flag to the subnet called
"is_floating" and then look through where IP allocations are done to
make sure that they come from (or at least *prefer* in some cases) the
appropriate pool.


More information about the OpenStack-operators mailing list