<tt><font size=2>> From: Mike Spreitzer/Watson/IBM@IBMUS</font></tt>
<br><tt><font size=2>> <br>
> > From: Jacob Godin <jacobgodin@gmail.com> <br>
> > <br>
> > Ah, gotcha. So you're not using overlapping subnets then. <br>
> > <br>
> > Unfortunately that hack wouldn't work in our environment, but
<br>
> > definitely something that others might consider using. <br>
> <br>
> Right, the solution I am using now imposes address constraints <br>
> between tenants that share a router.  I need to eliminate <br>
> constraints between tenants, so I have to abandon the solution I am
<br>
> using.  So I, too, am looking for different solution. <br>
> <br>
> I want to support a lot of tenants doing fairly unrestricted stuff,
<br>
> so all the connections --- from their Compute Instances that do NOT
<br>
> have a floating IP --- to public servers is more than I want to SNAT<br>
> onto a *single* public address. <br>
</font></tt>
<br><tt><font size=2>I found a few tantalizing leads in </font></tt><a href="http://specs.openstack.org/openstack/neutron-specs/index.html"><tt><font size=2 color=blue>http://specs.openstack.org/openstack/neutron-specs/index.html</font></tt></a>
<br><tt><font size=2>I can not check them out fully right now because review.openstack.org
is temporarily down.</font></tt>
<br>
<br><a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/specify-router-ext-ip.html"><tt><font size=2 color=blue>http://specs.openstack.org/openstack/neutron-specs/specs/kilo/specify-router-ext-ip.html</font></tt></a>
<br><tt><font size=2>"Allow the external IP address of a router to
be specified"</font></tt>
<br>
<br><tt><font size=2>If you, like I, are intermediating the calls on Neutron
and can transform a less specific call by the tenant into a precise formulation
of your choosing (as either admin or the tenant, on a case by case basis),
you can use the following solution.</font></tt>
<br>
<br><tt><font size=2>Let the "external" network known to Neutron
not be the actual public network but rather some other private network.
 Using control over the router's IP on that other private network,
scrunch all the router IP addresses into a dense range that is not in the
allocation range.  Thus, the router IP addresses and the tenants'
floating IP addresses are separated - you can put them in distinct large
CIDR blocks.  Using some other router that connects that other private
network to the actual public network, masquerade the router IP addresses
onto however many public addresses you like, while doing 1:1 bidirectional
NAT for the tenants' floating IP addresses.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>