[Openstack-operators] DVR and public IP consumption

Tomas Vondra vondra at czech-itc.cz
Thu Feb 4 12:41:51 UTC 2016


Carl Baldwin <carl at ...> writes:

> You're right, the IP in the fip namespace doesn't ever get written in
> to any packets or used as an arp destination.  It is currently
> meaningless.  That will change with BGP's capability to routed DVR
> traffic in Mitaka because that IP will be used as a next hop.
> However, it still doesn't need to be a public IP.  The routed networks
> work that I'm doing in Newton will allow us to eventually make these
> private IPs instead of public so that public IPs are not wasted.
> 
> I've given these things a lot of thought but haven't had time to
> pursue any such thoughts yet except to implement routed networks as
> groundwork.  Here are a few old links [1][2] but they are really out
> of date.  I need to write another spec following the first routed
> networks spec explaining how these things will work.
> 
> Here is an etherpad [3] that I put together a couple of years ago
> trying to compare different approaches to getting rid of centralized
> SNAT too.  We just never got any traction on any of these approaches.
> Also, without the routed networks work in Newton, many of them are
> difficult to accomplish.
> 
> Let me know if anything resonates with you.  We might be in a better
> position to do some of this work when routed networks is under way.
> For example, one thing that routed networks may allow is using private
> IPs for the router's address.  I think that was in one of the above
> blueprints somewhere.  Let me go write a new spec and post it.  I'll
> update this thread when I've got it up.
> 
> Carl
> 
> [1]
https://review.openstack.org/#/c/174657/2/specs/liberty/eliminate-dvr-fip-ns.rst
> [2] https://review.openstack.org/#/c/175517/1/specs/liberty/no-router-ip.rst
> [3] https://etherpad.openstack.org/p/decentralized-snat
> 

Hi Carl,
sorry for the late reply, but these links of yours expanded to about 12 tabs
in my browser, most with serveral pages of text. "Given lots of thought" may
be an understatement.

Both the specs sound very resonable to me. The second one is exactly what I
was saying here before. (Evidently I was not the first.) Why was it not
accepted? It seems quite easy to implement in contrast to full routed networks.

The work on routed networks will be beneficial mainly for large deployments,
whose needs exceed the capacity of a few L2 domains. Small public deployers
are working on the scale of tens of boxes, but hundreds of tenants. Each
tenant gets a virtual router, which eats an IP. I only have 1024 IPs from
RIPE and will probably get no more. If most of the tenants are small and
only use a one or two VMs, I'm wasting up to 50% addresses and it is
severely limiting my growth potential.

I do not really understand why routed networks would be a prerequisite to
using private IPs for router interfaces. I'm aiming at the last point from
the Etherpad - Carrier grade NAT. Do you think that I could use the "Allow
setting a tenant router's external IP" function and disable any checks if
the specified IP is in the network defined as external? I already have a
private subnet on the same L2 segment, that is NATted by the datacenter
routers. The API is admin-only, so it would not create a risk. I would
pre-create a router for each tenant and everyone would be happy. Floating
IPs are taken care of at the compute nodes in DVR.
Tomas




More information about the OpenStack-operators mailing list