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 _______________________________________________ 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