<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 11, 2016 at 6:26 PM, Clark Boylan <span dir="ltr"><<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Oct 11, 2016, at 05:14 PM, Carl Baldwin wrote:<br>
> I found this [1] added here [2]. Since the provider is using <a href="http://10.0.0.0/8" rel="noreferrer" target="_blank">10.0.0.0/8</a><br>
> on<br>
> the public interface, and the subnet pool is also <a href="http://10.0.0.0/8" rel="noreferrer" target="_blank">10.0.0.0/8</a> the call to<br>
> ip<br>
> route replace eliminates the route through the public interface.<br>
<br>
</span>It is also an issue if you have multiple subnets within 10/8 and rely on<br>
your default route to route to them (though I don't think we currently<br>
have any of these in the gate currently since rackspace sets more<br>
specific routes for the subnets used for private networking there). This<br>
would be the case if using a neutron setup with tenant networking and<br>
floating IPs like we had with the old hpcloud.<br></blockquote><div><br></div><div>Any time we fiddle with the host's routing table with address ranges that we make up, we run the risk of clashing with something "real". What do we do? I guess we can try our best to pick ranges that shouldn't clash and try to minimize how much of the space we use up. Then, for those that get a clash, we provide the option to override. That's kind of what we've been doing, right? We could try other tricks to pick more obscure IP ranges that shouldn't be used anywhere (like <a href="http://100.64.0.0/10">100.64.0.0/10</a> or the ranges reserved for documentation, which we do for ipv6) but with so many people competing for such a small space, I don't know if we can ever pick anything that won't ever clash. It just doesn't feel like there is a good answer.</div><div><br></div><div>Could we instead modify devstack to use a different network namespace (as in ip nets) to represent the "external" network? I think the real problem is that we're trying to use the host's real network as the "external network" for our testing. We are combining any combination of real world subnets with made up hard-coded default address ranges. If we separated the two, then there would be no chance for conflict. I'm just thinking out loud here. There could be all kinds of difficulty with this idea.</div><div><br></div><div>Carl</div></div></div></div>