On Wed, Feb 10, 2016 at 5:06 AM, Neil Jerram <neil.jer...@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. Carl _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
