Open Stack

On Jun 29, 2016, at 8:05 PM, Turbo Fredriksson wrote:

> Could that be because DHCP offers doesn't reach the instance? Shouldn't
> the router/dhcp namespaces/interfaces be reversed?


Something is seriously amiss! I accidentally took a look at the
"Instance Console Log", the full log.

And noticed this:

----- s n i p -----
Starting network...
udhcpc (v1.20.1) started
Sending discover...
Sending select for 192.168.69.226...
Lease of 192.168.69.226 obtained, lease time 43200
cirros-ds 'net' up at 3.70
checking http://169.254.169.254/2009-04-04/instance-id
failed 1/20: up 3.71. request failed
failed 2/20: up 8.91. request failed
failed 3/20: up 20.93. request failed
failed 4/20: up 25.93. request failed
failed 5/20: up 28.93. request failed
failed 6/20: up 33.94. request failed
failed 7/20: up 45.96. request failed
failed 8/20: up 50.97. request failed
failed 9/20: up 53.97. request failed
failed 10/20: up 65.98. request failed
failed 11/20: up 70.99. request failed
failed 12/20: up 73.99. request failed
failed 13/20: up 78.99. request failed
failed 14/20: up 81.99. request failed
failed 15/20: up 87.00. request failed
failed 16/20: up 90.00. request failed
failed 17/20: up 95.01. request failed
failed 18/20: up 98.01. request failed
failed 19/20: up 103.02. request failed
failed 20/20: up 106.02. request failed
failed to read iid from metadata. tried 20
[..]
=== network info ===
if-info: lo,up,127.0.0.1,8,::1
if-info: eth0,up,192.168.69.226,24,fe80::f816:3eff:fe4d:7bb5
if-info: eth1,down,,24,
ip-route:default via 192.168.69.1 dev eth0 
ip-route:192.168.69.0/24 dev eth0  src 192.168.69.226 
----- s n i p -----

The 192.168.69.0/24 network is the physical network CIDR
and is provided by a DHCP server on the site firewall/gateway
(192.168.69.1).

That host have, on the internal leg, the following networks
(among others): 192.168.69.0/24 (everything not-Openstack)
and 10.0.0.0/16, where the physical Compute and Control node
resides.

BUT, the Openstack interfaces is supposed to have limits
against that (right?), only allowing DHCP requests/offers
from the designated OS DHCP servers which Neutron starts.
However, their ports is in "Down" state. Not exactly sure
why..


What's good news however, is that when I created the network(s),
I setup a IP pool on the physical network and a bunch of
floating addresses.

So when I created the instance, I selected one such IP.
That, I assume, was supposed to be "eth1" (which don't
have an address - OS isn't setting it for some reason).

But if I set that manually, I can ping that IP from
the rest of the network, including the physical one!


So the question(s) are (in order of importance I think):

1. Why doesn't the OS DHCP servers/ports/interfaces (?)
   start properly? All the dnsmasq process are all there,
   and judging from the command line, they're all good.

2. Why do the instance get an IP from the site-global
   DHCP server at all? Isn't that supposed to be blocked?

3. Why isn't the floating IP being set in the instance?
--
You know, boys, a nuclear reactor is a lot like a woman.
You just have to read the manual and press the right buttons
- Homer Simpson