Mark Kirkwood <mark.kirkw...@catalyst.net.nz> wrote on 10/07/2014 02:50:01 AM:
> On 07/10/14 19:44, Mike Spreitzer wrote: > > Mark Kirkwood <mark.kirkw...@catalyst.net.nz> wrote on 10/07/2014 > > 02:23:36 AM: > > > > > I think why this is not documented is the usual use-case for devstack is > > > development setups where real external ips for the VMs is usually not a > > > point of interest. > > > > > > For instance I never need this...I do sometimes want the VMs to be able > > > to access the internet, and that is pretty easy: > > > > > > $ sudo sysctl -w net.ipv4.ip_forward=1 > > > $ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > > > > > > For access the other way, yes it's more complex. As others have posted, > > > you need real ip ranges available in your external network and > > > (probably) an additional nic in your test box that can be > > > designated/mapped as br-ex > > > so that the various routers/gateways in the neutron setup use it. > > > > Thanks, Mark. As I mentioned in my original post, I have a block of IP > > addresses that I can use as I see fit --- I have a subnet that I > > control. I do not see why an additional NIC on the host would be > > needed, it already has a NIC connected to a subnet that I control (I am > > trying to make it easy here). > > > > True, you can just assign another ip to your nic (in the appropriate > subnet range) and use that as br-ex - yes, I'm being old fashioned and > would prefer another nic to make it clear to me what was happening :-) 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: https://bugs.launchpad.net/devstack/+bug/1339982 . 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? Thanks, Mike
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
