<tt><font size=2>Mark Kirkwood <mark.kirkwood@catalyst.net.nz> wrote
on 10/07/2014 02:50:01 AM:<br>
<br>
> On 07/10/14 19:44, Mike Spreitzer wrote:<br>
> > Mark Kirkwood <mark.kirkwood@catalyst.net.nz> wrote on
10/07/2014<br>
> > 02:23:36 AM:<br>
> ><br>
> >  > I think why this is not documented is the usual use-case
for devstack is<br>
> >  > development setups where real external ips for the
VMs is usually not a<br>
> >  > point of interest.<br>
> >  ><br>
> >  > For instance I never need this...I do sometimes want
the VMs to be able<br>
> >  > to access the internet, and that is pretty easy:<br>
> >  ><br>
> >  > $ sudo sysctl -w net.ipv4.ip_forward=1<br>
> >  > $ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE<br>
> >  ><br>
> >  > For access the other way, yes it's more complex. As
others have posted,<br>
> >  > you need real ip ranges available in your external
network and<br>
> >  > (probably) an additional nic in your test box that
can be<br>
> >  > designated/mapped as br-ex<br>
> >  > so that the various routers/gateways in the neutron
setup use it.<br>
> ><br>
> > Thanks, Mark.  As I mentioned in my original post, I have
a block of IP<br>
> > addresses that I can use as I see fit --- I have a subnet that
I<br>
> > control.  I do not see why an additional NIC on the host
would be<br>
> > needed, it already has a NIC connected to a subnet that I control
(I am<br>
> > trying to make it easy here).<br>
> ><br>
> <br>
> True, you can just assign another ip to your nic (in the appropriate
<br>
> subnet range) and use that as br-ex - yes, I'm being old fashioned
and <br>
> would prefer another nic to make it clear to me what was happening
:-)<br>
</font></tt>
<br>
<br><font size=2 face="sans-serif">So I tried using DevStack with FLOATING_RANGE
and PUBLIC_NETWORK_GATEWAY matching the initial network config of my lab
machine, and with Q_FLOATING_ALLOCATION_POOL set to keep Neutron from allocating
IPs already in use on my subnet.  I found that DevStack ruined my
machine, by setting PUBLIC_NETWORK_GATEWAY as the address of br-ex.  There
is an existing bug for this: </font><a href="https://bugs.launchpad.net/devstack/+bug/1339982"><font size=2 color=blue face="sans-serif">https://bugs.launchpad.net/devstack/+bug/1339982</font></a><font size=2 face="sans-serif">
.  What mystifies me is that it is marked as affecting only three
people.  Are there really only three people who use DevStack on service
machines (rather than personal ones) and try to get inside/outside communication
working as Neutron intended it?  Our CI checking uses DevStack on
service machines, right?  Perhaps there is no problem there because
checking does not attempt inside-outside communication?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Mike</font>
<br>
<br><tt><font size=2><br>
</font></tt>