Neutron networking question with openstack-base

[Daniel Bidwell]

In juju-gui have have the ext-port set to eth3, my public nic.

With all networks and routers deleted, "juju get neutron-gatway | grep
ext-port" returns "ext-port:", nothing, yet juju-gui still have the
correct eth3 value.

I add the provider-router and ext_net with:
./neutron-ext-net -g 143.207.94.1 -c 143.207.94.0/24 -f
143.207.94.10:143.207.94.254 ext_net

ext_net_subnet says that it is UP and active
The port associated with the ext_net_subnet is UP, but the status is
down and "juju get neutron-gateway | fgrep ext-port" still returns no
nic.

juju set neutron-gateway ext-port=eth3 now returns
WARNING the configuration setting "ext-port" already has the value
"eth3" even though the get doesn't return it and the port is still down.

But I can now ping the ext_net interface IP address and the rest of my
physical machines that are on the 143.207.94.0/24 network, just not the
floating-ip.

The internal network has 2 ports, the compute:None which is UP and
Active, and the network:router_interface which is UP and Down.  This is
probably where my problem lies, but I am not sure how to go about fixing
it.

The provider-router has 2 interfaces, on the ext_net and internal, both
have an Admin State of UP, but a status of down.  My vm has a
floating-ip of 143.207.94.11, but I can't ping it or ssh to it.

When the vm boots, but appears to have failed to get an IP address.  The
ci-info console line says that eth0 is up, but has no address or mask.
I don't think I can get into the vm from the console.

How do I tell the exact version of OpenStack that I am running?  I have
Ubuntu 14.04.3 LTS installed and have installed openstack with the
openstack-base juju charm.

On Mon, 2015-10-19 at 11:10 +0100, Liam Young wrote:
> Hi Daniel,
> 
> Have you set 'ext-port' in the neutron-gateway charm?  ext-port 
> specifies the external port the neutron-gateway charm should use for 
> routing of instance traffic to the external public network. If eth1 on 
> the neutron-gateway is plumbed into 143.207.94.0/24 network then you 
> would set it with:
> 
> juju set neutron-gateway ext-port=eth1
> 
> I'd also take a look at the Network Topology page in the horizon 
> dashboard and check that ext_net and your private net are both plumbed 
> into your router and that your instances are plumbed into your private 
> network. I'm not sure which version of Openstack you are deploying but 
> certainly in Icehouse I have seen horizon claim the state of 
> network:router_gateway to be 'down' when it is actually working.
> 
> Do you see the floating IPs that you have assigned your instance(s) 
> listed when you look at the 'Attached Devices' in the detail tab of 
> ext_net ?
> 
> Also check that when the instance booted DHCP succeeded. You can do this 
> through horizon by going to Compute -> Instances -> Click on Instance 
> Name -> Log tab. The message you are looking for will differ depending 
> on the image you booted the instance from but something like:
> 
> ci-info: eth0  : 1 192.168.0.4     255.255.255.0   fa:16:3e:ef:d8:53
> 
> or
> 
> Lease of 192.168.0.2 obtained, lease time 86400
> 
> Thanks,
> Liam Young
> 
> On 15/10/15 20:49, Daniel Bidwell wrote:
> > I have installed a small openstack cloud with the openstack-base charm.
> >
> > After everything came up I ran the neutron-ext-net and
> > neutron-tenant-net.  I ran neutron-ext-net with -g 143.207.94.1 -c
> > 143.207.94.0/24 -f 143.207.94.10:143.207.94.254 ext_net
> >
> > Each machine in my cloud has an interface on the 143.207.94.0/24
> > network.  When I look at the horizon dashboard, under
> > admin->networks->ext_net it says that the port on 143.207.94.x as
> > network:router_gateway has an admin state of UP, but a Status of Down
> > and I have now access from the external addresses on 143.207.94.0 to the
> > internal addresses on the 143.207.94.0 network.  I have tried to set the
> > access rules for ping and ssh, but nothing goes through.
> >
> > How do I find out why the two different networks don't connect?  How do
> > I make them connect?
> 

-- 
Daniel Bidwell <drbidwell at gmail.com>