settingsLogin | Registersettings

Re: [Openstack-operators] Instances not getting DHCP Lease

0 votes

What I usually do, and this might not be easiest/best, is, given you
do have console access, to manually set the IP in the cirrus node.

Then I enter the ip name space for the dhcp server on the network node
(sudo ip netns exec qdhcp- bash), and see if I can ping
the cirrus node and vice-versa, things like that. Making sure to add a
security group rule to at least allow ICMP. See if you can at least
get an arp entry for the virtual machine's IP.

Usually if there is no connectivity at all it's b/c a vlan is missing
for the physical interface on the switch (not sure how your deployment
is setup), or the also neutron configuration settings are incorrect in
terms of bridge mappings and such, usually something simple like that.

Another option is to reboot or retry dhcp on the cirrus vm and tcpdump
on the physical interface the dhcp server is on and watch for dhcp
traffic, and you could do that on the compute node as well, looking
for both request and response, again to validate basic connectivity.

If you still are having issues, let us know how you deployed openstack
(distro?) and what kind of network you are using (vxlan, vlan?),
whether it's linux bridge or ovs, things like that.

Thanks,
Curtis.

I have deployed the nodes using a virtual box & set up nat 2 nat networks ,
configured the neutron service according to self service network guide . I
have doubled checked the neutron configuration . I do agree to fact the

Although i can't make out whether there is connectivity between the nodes.
I get the following output when i run the tcp dump on the controller node .

listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
12:48:26.488533 IP 192.168.10.10.22 > 192.168.10.2.58970: Flags [P.], seq
1408700411:1408700519, ack 23895, win 40080, length 108
12:48:26.488719 IP 192.168.10.10.22 > 192.168.10.2.58970: Flags [P.], seq
108:144, ack 1, win 40080, length 36

Output on the compute node .

listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
12:59:21.558954 IP 192.168.10.20.22 > 192.168.10.10.60664: Flags [P.], seq
1404672109:1404672297, ack 639164055, win 312, options [nop,nop,TS val
677134 ecr 715780], length 188
12:59:21.559252 IP 192.168.10.10.60664 > 192.168.10.20.22: Flags [.], ack
188, win 1444, options [nop,nop,TS val 715791 ecr 677134], length 0


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
asked Sep 2, 2017 in openstack-operators by Divneet_Singh (300 points)   4 4 4

5 Responses

0 votes

you can check if it is really the dhclient failing to have an address.

checking http://169.254.169.254/2009-04-04/instance-id
failed 1/20: up 188.93. request failed
failed 2/20: up 191.21. request failed
failed 3/20: up 193.36. request failed
failed 4/20: up 195.54. request failed
failed 5/20: up 197.68. request failed
failed 6/20: up 199.83. request failed
failed 7/20: up 201.97. request failed
failed 8/20: up 204.13. request failed
failed 9/20: up 206.31. request failed
failed 10/20: up 208.48. request failed
failed 11/20: up 210.63. request failed
failed 12/20: up 212.89. request failed
failed 13/20: up 215.06. request failed
failed 14/20: up 217.21. request failed

Regards


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Sep 2, 2017 by Divneet_Singh (300 points)   4 4 4
0 votes

checking http://169.254.169.254/2009-04-04/instance-id
failed 1/20: up 188.93. request failed
failed 2/20: up 191.21. request failed
failed 3/20: up 193.36. request failed
failed 4/20: up 195.54. request failed
failed 5/20: up 197.68. request failed
failed 6/20: up 199.83. request failed
failed 7/20: up 201.97. request failed
failed 8/20: up 204.13. request failed
failed 9/20: up 206.31. request failed
failed 10/20: up 208.48. request failed
failed 11/20: up 210.63. request failed
failed 12/20: up 212.89. request failed
failed 13/20: up 215.06. request failed
failed 14/20: up 217.21. request failed

Hello,

this is the metadata service failing, it is not DHCP. Does the
instance get an ip address from DHCP or not ?

Saverio


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Sep 2, 2017 by Saverio_Proto (5,480 points)   1 4 6
0 votes

this is the metadata service failing, it is not DHCP. Does the
instance get an ip address from DHCP or not ?

Hello ,

The instance is not getting the ip adress from DHCP

Usage: /sbin/cirros-dhcpc <up|down>
No lease, failing
WARN: /etc/rc3.d/S40-network failed
cirros-ds 'net' up at 188.66


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Sep 2, 2017 by Divneet_Singh (300 points)   4 4 4
0 votes

On Sat, Sep 2, 2017 at 1:57 AM, Divneet Singh divneetsingh.ml@gmail.com wrote:

What I usually do, and this might not be easiest/best, is, given you
do have console access, to manually set the IP in the cirrus node.

Then I enter the ip name space for the dhcp server on the network node
(sudo ip netns exec qdhcp- bash), and see if I can ping
the cirrus node and vice-versa, things like that. Making sure to add a
security group rule to at least allow ICMP. See if you can at least
get an arp entry for the virtual machine's IP.

Usually if there is no connectivity at all it's b/c a vlan is missing
for the physical interface on the switch (not sure how your deployment
is setup), or the also neutron configuration settings are incorrect in
terms of bridge mappings and such, usually something simple like that.

Another option is to reboot or retry dhcp on the cirrus vm and tcpdump
on the physical interface the dhcp server is on and watch for dhcp
traffic, and you could do that on the compute node as well, looking
for both request and response, again to validate basic connectivity.

If you still are having issues, let us know how you deployed openstack
(distro?) and what kind of network you are using (vxlan, vlan?),
whether it's linux bridge or ovs, things like that.

Thanks,
Curtis.

I have deployed the nodes using a virtual box & set up nat 2 nat networks ,
configured the neutron service according to self service network guide . I
have doubled checked the neutron configuration . I do agree to fact the

A bit might have gotten cut off there. :)

At any rate, I'm not sure what nat 2 nat networks are in virtual box,
but I'm going to guess that you have a problem in your virtual box
networking setup. You'll have to investigate those networks and make
sure they are setup in a way that will work with your openstack
deployment. If you are just trying out openstack, perhaps a single
node devstack install would be a good place to start and then move to
more advanced deployments from there?

Thanks,
Curtis.

Although i can't make out whether there is connectivity between the nodes.
I get the following output when i run the tcp dump on the controller node .

listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
12:48:26.488533 IP 192.168.10.10.22 > 192.168.10.2.58970: Flags [P.], seq
1408700411:1408700519, ack 23895, win 40080, length 108
12:48:26.488719 IP 192.168.10.10.22 > 192.168.10.2.58970: Flags [P.], seq
108:144, ack 1, win 40080, length 36

Output on the compute node .

listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
12:59:21.558954 IP 192.168.10.20.22 > 192.168.10.10.60664: Flags [P.], seq
1404672109:1404672297, ack 639164055, win 312, options [nop,nop,TS val
677134 ecr 715780], length 188
12:59:21.559252 IP 192.168.10.10.60664 > 192.168.10.20.22: Flags [.], ack
188, win 1444, options [nop,nop,TS val 715791 ecr 677134], length 0

--
Blog: serverascode.com


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Sep 2, 2017 by Curtis (4,180 points)   2 4
0 votes

At any rate, I'm not sure what nat 2 nat networks are in virtual box,
but I'm going to guess that you have a problem in your virtual box
networking setup. You'll have to investigate those networks and make
sure they are setup in a way that will work with your openstack
deployment. If you are just trying out openstack, perhaps a single
node devstack install would be a good place to start and then move to
more advanced deployments from there?

This just hit me last night , setting up a vlan/vxlan on top of a nat
network isn't the way to go . I'm just going scrap this & start from
scratch on physical machines .

Thanks !
Divneet


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Sep 3, 2017 by Divneet_Singh (300 points)   4 4 4
...