Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

DHCP problem in grizzly

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


johanna.heinonen at nsn

May 19, 2013, 11:51 PM

Post #1 of 23 (480 views)
Permalink
DHCP problem in grizzly

Hi,

I have installed grizzly with quantum and ovs-plugin. It seems that grizzly allocates the third address of each subnet for dhcp. (In folsom it was the second address). This means that the VMs will get addresses .2, .4, .5, ...

In my setup the first VM always boots fine and gets the address x.x.x.2. This can be seen in the syslog:

May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2

The problem comes when I start the second VM. Nova shows that the x.x.x.4 is allocated

root [at] grizzly-23:~# nova list
+--------------------------------------+----------+--------+------------------------+
| ID | Name | Status | Networks |
+--------------------------------------+----------+--------+------------------------+
| c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE | tenant1-net=10.20.30.2 |
| 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE | tenant1-net=10.20.30.4 |
+--------------------------------------+----------+--------+------------------------+

But from syslog I see that the answer to the DHCPDISCOVER is "no address available"

May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]: DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address available
May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]: DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address available

When I restart the quantum-dhcp-server the problem disappears. This can be seen from the syslog:

May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59 cachesize 150
May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options: IPv6 GNU-getopt DBus i18n DHCP TFTP conntrack IDN
May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream servers configured
May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static leases only on 10.20.30.0, lease time 2m
May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPNAK(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2

May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a
May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a
May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a
May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4


What could be the problem? Have you seen similar behavior? If yes, how did you fix this?

Best regards,
Johanna


kaergel at b1-systems

May 20, 2013, 12:08 AM

Post #2 of 23 (476 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi Johanna,

I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
noticed that new hosts have correct entries in the dnsmasq config-files.
The dnsmasq processes get a HUP signal by DHCP-Agent, but simply refuse
to deliver the new address. Instead dnsmasq logs claim "no address
available". Exactly like in your description.
What distrubtion and exact dnsmasq-versions are in use on your environment?
I assume dnsmasq is not rereading its configs correctly on signal HUP.
dnsmasq logs claim it has reread configs, but it still does not deliver
the new adresses in host-file.
Manually trying to sigHUP dnsmasq had no effect. The only way to get out
of this state seems to be restarting DHCP-agent.

Best regards
Thomas

Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> Hi,
>
> I have installed grizzly with quantum and ovs-plugin. It seems that
> grizzly allocates the third address of each subnet for dhcp. (In folsom
> it was the second address). This means that the VMs will get addresses
> .2, .4, .5,
>
> In my setup the first VM always boots fine and gets the address x.x.x.2.
> This can be seen in the syslog:
>
> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5)
> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>
> The problem comes when I start the second VM. Nova shows that the
> x.x.x.4 is allocated
>
> root [at] grizzly-23:~# nova list
> +--------------------------------------+----------+--------+------------------------+
> | ID | Name | Status |
> Networks |
> +--------------------------------------+----------+--------+------------------------+
> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
> tenant1-net=10.20.30.2 |
> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
> tenant1-net=10.20.30.4 |
> +--------------------------------------+----------+--------+------------------------+
>
> But from syslog I see that the answer to the DHCPDISCOVER is no address
> available
>
> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> available
> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> available
>
> When I restart the quantum-dhcp-server the problem disappears. This can
> be seen from the syslog:
>
> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59
> cachesize 150
> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options: IPv6
> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream servers
> configured
> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static leases only
> on 10.20.30.0, lease time 2m
> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPNAK(tapdbcef145-f5)
> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>
> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
>
>
> What could be the problem? Have you seen similar behavior? If yes, how
> did you fix this?
>
> Best regards,
> Johanna
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>


--
Thomas Krgel
Linux Consultant
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Attachments: signature.asc (0.54 KB)


johanna.heinonen at nsn

May 20, 2013, 1:21 AM

Post #3 of 23 (457 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi Thomas,

I am using Ubuntu12.04 and the dnsmasq version is 2.59

BR
Johanna


-----Original Message-----
From: Openstack [mailto:openstack-bounces+johanna.heinonen=nsn.com [at] lists] On Behalf Of ext Thomas Krgel
Sent: Monday, May 20, 2013 10:09 AM
To: openstack [at] lists
Subject: Re: [Openstack] DHCP problem in grizzly

Hi Johanna,

I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
noticed that new hosts have correct entries in the dnsmasq config-files.
The dnsmasq processes get a HUP signal by DHCP-Agent, but simply refuse
to deliver the new address. Instead dnsmasq logs claim "no address
available". Exactly like in your description.
What distrubtion and exact dnsmasq-versions are in use on your environment?
I assume dnsmasq is not rereading its configs correctly on signal HUP.
dnsmasq logs claim it has reread configs, but it still does not deliver
the new adresses in host-file.
Manually trying to sigHUP dnsmasq had no effect. The only way to get out
of this state seems to be restarting DHCP-agent.

Best regards
Thomas

Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> Hi,
>
> I have installed grizzly with quantum and ovs-plugin. It seems that
> grizzly allocates the third address of each subnet for dhcp. (In folsom
> it was the second address). This means that the VMs will get addresses
> .2, .4, .5, .
>
> In my setup the first VM always boots fine and gets the address x.x.x.2.
> This can be seen in the syslog:
>
> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5)
> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>
> The problem comes when I start the second VM. Nova shows that the
> x.x.x.4 is allocated
>
> root [at] grizzly-23:~# nova list
> +--------------------------------------+----------+--------+------------------------+
> | ID | Name | Status |
> Networks |
> +--------------------------------------+----------+--------+------------------------+
> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
> tenant1-net=10.20.30.2 |
> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
> tenant1-net=10.20.30.4 |
> +--------------------------------------+----------+--------+------------------------+
>
> But from syslog I see that the answer to the DHCPDISCOVER is "no address
> available"
>
> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> available
> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> available
>
> When I restart the quantum-dhcp-server the problem disappears. This can
> be seen from the syslog:
>
> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59
> cachesize 150
> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options: IPv6
> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream servers
> configured
> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static leases only
> on 10.20.30.0, lease time 2m
> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPNAK(tapdbcef145-f5)
> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>
> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
>
>
> What could be the problem? Have you seen similar behavior? If yes, how
> did you fix this?
>
> Best regards,
> Johanna
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>


--
Thomas Krgel
Linux Consultant
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


kaergel at b1-systems

May 20, 2013, 1:36 AM

Post #4 of 23 (455 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi,

thx for the interesting info, Johanna: dnsmasq version is also 2.59 on
my environment. Can you can confirm that manually sigHUPing all running
dnsmasq processes has no effect?
(dnsmasq claims to have reread the configs in syslog, but still refuses
to deliver the new addresses.)
Maybe updating dnsmasq to a more recent release would solve our problem.
Current stable is 2.66. I'll give it a try when i get back to office
tomorrow.

Best regards

Thomas


Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> Hi Thomas,
>
> I am using Ubuntu12.04 and the dnsmasq version is 2.59
>
> BR
> Johanna
>
>
> -----Original Message-----
> From: Openstack [mailto:openstack-bounces+johanna.heinonen=nsn.com [at] lists] On Behalf Of ext Thomas Krgel
> Sent: Monday, May 20, 2013 10:09 AM
> To: openstack [at] lists
> Subject: Re: [Openstack] DHCP problem in grizzly
>
> Hi Johanna,
>
> I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
> noticed that new hosts have correct entries in the dnsmasq config-files.
> The dnsmasq processes get a HUP signal by DHCP-Agent, but simply refuse
> to deliver the new address. Instead dnsmasq logs claim "no address
> available". Exactly like in your description.
> What distrubtion and exact dnsmasq-versions are in use on your environment?
> I assume dnsmasq is not rereading its configs correctly on signal HUP.
> dnsmasq logs claim it has reread configs, but it still does not deliver
> the new adresses in host-file.
> Manually trying to sigHUP dnsmasq had no effect. The only way to get out
> of this state seems to be restarting DHCP-agent.
>
> Best regards
> Thomas
>
> Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
>> Hi,
>>
>> I have installed grizzly with quantum and ovs-plugin. It seems that
>> grizzly allocates the third address of each subnet for dhcp. (In folsom
>> it was the second address). This means that the VMs will get addresses
>> .2, .4, .5, .
>>
>> In my setup the first VM always boots fine and gets the address x.x.x.2.
>> This can be seen in the syslog:
>>
>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5)
>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>>
>> The problem comes when I start the second VM. Nova shows that the
>> x.x.x.4 is allocated
>>
>> root [at] grizzly-23:~# nova list
>> +--------------------------------------+----------+--------+------------------------+
>> | ID | Name | Status |
>> Networks |
>> +--------------------------------------+----------+--------+------------------------+
>> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
>> tenant1-net=10.20.30.2 |
>> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
>> tenant1-net=10.20.30.4 |
>> +--------------------------------------+----------+--------+------------------------+
>>
>> But from syslog I see that the answer to the DHCPDISCOVER is "no address
>> available"
>>
>> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
>> available
>> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
>> available
>>
>> When I restart the quantum-dhcp-server the problem disappears. This can
>> be seen from the syslog:
>>
>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59
>> cachesize 150
>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options: IPv6
>> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream servers
>> configured
>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static leases only
>> on 10.20.30.0, lease time 2m
>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPNAK(tapdbcef145-f5)
>> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>>
>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
>> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
>>
>>
>> What could be the problem? Have you seen similar behavior? If yes, how
>> did you fix this?
>>
>> Best regards,
>> Johanna
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>
>


--
Thomas Krgel
Linux Consultant
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Attachments: signature.asc (0.54 KB)


johanna.heinonen at nsn

May 20, 2013, 3:25 AM

Post #5 of 23 (454 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi,

You are right. Manually doing kill -HUP <PID> has just the effect you mentioned. In the syslog you can see

May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts


But the problem stays. Only 'service quantum-dhcp-agent restart' fixes the problem.
If you try the newer version of the qnsmasq, I'd be interested to hear the results.

BR
Johanna



-----Original Message-----
From: ext Thomas Krgel [mailto:kaergel [at] b1-systems]
Sent: Monday, May 20, 2013 11:37 AM
To: Heinonen, Johanna (NSN - FI/Espoo)
Cc: openstack [at] lists
Subject: Re: [Openstack] DHCP problem in grizzly

Hi,

thx for the interesting info, Johanna: dnsmasq version is also 2.59 on
my environment. Can you can confirm that manually sigHUPing all running
dnsmasq processes has no effect?
(dnsmasq claims to have reread the configs in syslog, but still refuses
to deliver the new addresses.)
Maybe updating dnsmasq to a more recent release would solve our problem.
Current stable is 2.66. I'll give it a try when i get back to office
tomorrow.

Best regards

Thomas


Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> Hi Thomas,
>
> I am using Ubuntu12.04 and the dnsmasq version is 2.59
>
> BR
> Johanna
>
>
> -----Original Message-----
> From: Openstack [mailto:openstack-bounces+johanna.heinonen=nsn.com [at] lists] On Behalf Of ext Thomas Krgel
> Sent: Monday, May 20, 2013 10:09 AM
> To: openstack [at] lists
> Subject: Re: [Openstack] DHCP problem in grizzly
>
> Hi Johanna,
>
> I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
> noticed that new hosts have correct entries in the dnsmasq config-files.
> The dnsmasq processes get a HUP signal by DHCP-Agent, but simply refuse
> to deliver the new address. Instead dnsmasq logs claim "no address
> available". Exactly like in your description.
> What distrubtion and exact dnsmasq-versions are in use on your environment?
> I assume dnsmasq is not rereading its configs correctly on signal HUP.
> dnsmasq logs claim it has reread configs, but it still does not deliver
> the new adresses in host-file.
> Manually trying to sigHUP dnsmasq had no effect. The only way to get out
> of this state seems to be restarting DHCP-agent.
>
> Best regards
> Thomas
>
> Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
>> Hi,
>>
>> I have installed grizzly with quantum and ovs-plugin. It seems that
>> grizzly allocates the third address of each subnet for dhcp. (In folsom
>> it was the second address). This means that the VMs will get addresses
>> .2, .4, .5, .
>>
>> In my setup the first VM always boots fine and gets the address x.x.x.2.
>> This can be seen in the syslog:
>>
>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5)
>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>>
>> The problem comes when I start the second VM. Nova shows that the
>> x.x.x.4 is allocated
>>
>> root [at] grizzly-23:~# nova list
>> +--------------------------------------+----------+--------+------------------------+
>> | ID | Name | Status |
>> Networks |
>> +--------------------------------------+----------+--------+------------------------+
>> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
>> tenant1-net=10.20.30.2 |
>> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
>> tenant1-net=10.20.30.4 |
>> +--------------------------------------+----------+--------+------------------------+
>>
>> But from syslog I see that the answer to the DHCPDISCOVER is "no address
>> available"
>>
>> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
>> available
>> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
>> available
>>
>> When I restart the quantum-dhcp-server the problem disappears. This can
>> be seen from the syslog:
>>
>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59
>> cachesize 150
>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options: IPv6
>> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream servers
>> configured
>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static leases only
>> on 10.20.30.0, lease time 2m
>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPNAK(tapdbcef145-f5)
>> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>>
>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
>> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
>>
>>
>> What could be the problem? Have you seen similar behavior? If yes, how
>> did you fix this?
>>
>> Best regards,
>> Johanna
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>
>


--
Thomas Krgel
Linux Consultant
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


dara2002-openstack at yahoo

May 20, 2013, 3:39 AM

Post #6 of 23 (457 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

the reference to 10.0.2.15 is strange. This happens to be the address the VirtualBox DHCP server gives to its VMs configured for NAT. Are you using VirtualBox? Even so I have never found this to be a problem because a Quantum DHCP namespace is isolated from the main one. Can you provide the 'ip address' from the main namespace and the dhcp namespace. 



>________________________________
> From: "Heinonen, Johanna (NSN - FI/Espoo)" <johanna.heinonen [at] nsn>
>To: "openstack [at] lists" <openstack [at] lists>
>Sent: Monday, 20 May 2013, 7:51
>Subject: [Openstack] DHCP problem in grizzly
>
>
>
>
>Hi,

>I have installed grizzly with quantum and ovs-plugin. It seems that grizzly allocates the third address of each subnet for dhcp. (In folsom it was the second address). This means that the VMs will get addresses .2, .4, .5, …

>In my setup the first VM always boots fine and gets the address x.x.x.2. This can be seen in the syslog:

>May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
>May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2

>The problem comes when I start the second VM. Nova shows that the x.x.x.4 is allocated

>root [at] grizzly-23:~# nova list
>+--------------------------------------+----------+--------+------------------------+
>| ID                                   | Name     | Status | Networks               |
>+--------------------------------------+----------+--------+------------------------+
>| c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test   | ACTIVE | tenant1-net=10.20.30.2 |
>| 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE | tenant1-net=10.20.30.4 |
>+--------------------------------------+----------+--------+------------------------+

>But from syslog I see that the answer to the DHCPDISCOVER is “no address available”

>May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]: DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address available
>May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]: DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address available

>When I restart the quantum-dhcp-server the problem disappears. This can be seen from the syslog:

>May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59 cachesize 150
>May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options: IPv6 GNU-getopt DBus i18n DHCP TFTP conntrack IDN
>May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream servers configured
>May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static leases only on 10.20.30.0, lease time 2m
>May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
>May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
>May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
>May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPNAK(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
>May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
>May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2

>May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a
>May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a
>May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a
>May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4


>What could be the problem? Have you seen similar behavior? If yes, how did you fix this?

>Best regards,
>Johanna

>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack [at] lists
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp
>
>
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


kaergel at b1-systems

May 21, 2013, 11:05 PM

Post #7 of 23 (446 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi Johanna,

sure, I'll report my results, but this can take a while. The last time
this issue occurred on my environment is May 10th. It occurs quite
sporadic and i don't know how to manually reproduce this issue yet (i
have to be very careful with my experiments since the environment is
running productive already). Maybe you should also give dnsmasq 2.66 a
try, because you wrote that you can manually reproduce this behavior.


Best Regards,
Thomas


Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> Hi,
>
> You are right. Manually doing kill -HUP <PID> has just the effect you mentioned. In the syslog you can see
>
> May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
> May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
> May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
>
>
> But the problem stays. Only 'service quantum-dhcp-agent restart' fixes the problem.
> If you try the newer version of the qnsmasq, I'd be interested to hear the results.
>
> BR
> Johanna
>
>
>
> -----Original Message-----
> From: ext Thomas Krgel [mailto:kaergel [at] b1-systems]
> Sent: Monday, May 20, 2013 11:37 AM
> To: Heinonen, Johanna (NSN - FI/Espoo)
> Cc: openstack [at] lists
> Subject: Re: [Openstack] DHCP problem in grizzly
>
> Hi,
>
> thx for the interesting info, Johanna: dnsmasq version is also 2.59 on
> my environment. Can you can confirm that manually sigHUPing all running
> dnsmasq processes has no effect?
> (dnsmasq claims to have reread the configs in syslog, but still refuses
> to deliver the new addresses.)
> Maybe updating dnsmasq to a more recent release would solve our problem.
> Current stable is 2.66. I'll give it a try when i get back to office
> tomorrow.
>
> Best regards
>
> Thomas
>
>
> Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
>> Hi Thomas,
>>
>> I am using Ubuntu12.04 and the dnsmasq version is 2.59
>>
>> BR
>> Johanna
>>
>>
>> -----Original Message-----
>> From: Openstack [mailto:openstack-bounces+johanna.heinonen=nsn.com [at] lists] On Behalf Of ext Thomas Krgel
>> Sent: Monday, May 20, 2013 10:09 AM
>> To: openstack [at] lists
>> Subject: Re: [Openstack] DHCP problem in grizzly
>>
>> Hi Johanna,
>>
>> I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
>> noticed that new hosts have correct entries in the dnsmasq config-files.
>> The dnsmasq processes get a HUP signal by DHCP-Agent, but simply refuse
>> to deliver the new address. Instead dnsmasq logs claim "no address
>> available". Exactly like in your description.
>> What distrubtion and exact dnsmasq-versions are in use on your environment?
>> I assume dnsmasq is not rereading its configs correctly on signal HUP.
>> dnsmasq logs claim it has reread configs, but it still does not deliver
>> the new adresses in host-file.
>> Manually trying to sigHUP dnsmasq had no effect. The only way to get out
>> of this state seems to be restarting DHCP-agent.
>>
>> Best regards
>> Thomas
>>
>> Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
>>> Hi,
>>>
>>> I have installed grizzly with quantum and ovs-plugin. It seems that
>>> grizzly allocates the third address of each subnet for dhcp. (In folsom
>>> it was the second address). This means that the VMs will get addresses
>>> .2, .4, .5, .
>>>
>>> In my setup the first VM always boots fine and gets the address x.x.x.2.
>>> This can be seen in the syslog:
>>>
>>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
>>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5)
>>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>>>
>>> The problem comes when I start the second VM. Nova shows that the
>>> x.x.x.4 is allocated
>>>
>>> root [at] grizzly-23:~# nova list
>>> +--------------------------------------+----------+--------+------------------------+
>>> | ID | Name | Status |
>>> Networks |
>>> +--------------------------------------+----------+--------+------------------------+
>>> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
>>> tenant1-net=10.20.30.2 |
>>> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
>>> tenant1-net=10.20.30.4 |
>>> +--------------------------------------+----------+--------+------------------------+
>>>
>>> But from syslog I see that the answer to the DHCPDISCOVER is "no address
>>> available"
>>>
>>> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
>>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
>>> available
>>> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
>>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
>>> available
>>>
>>> When I restart the quantum-dhcp-server the problem disappears. This can
>>> be seen from the syslog:
>>>
>>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59
>>> cachesize 150
>>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options: IPv6
>>> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
>>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream servers
>>> configured
>>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static leases only
>>> on 10.20.30.0, lease time 2m
>>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
>>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
>>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
>>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
>>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
>>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPNAK(tapdbcef145-f5)
>>> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
>>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
>>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
>>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>>>
>>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
>>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>>> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
>>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
>>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
>>> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
>>>
>>>
>>> What could be the problem? Have you seen similar behavior? If yes, how
>>> did you fix this?
>>>
>>> Best regards,
>>> Johanna
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>
>>
>
>


--
Thomas Krgel
Linux Consultant
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Attachments: signature.asc (0.54 KB)


mail.colombomarco at gmail

May 22, 2013, 12:55 AM

Post #8 of 23 (442 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi All,
i have the same problem with Grizzly, Ubuntu 12.04 and Dnsmasq 2.59
"killall dnsmasq && service quantum-dhcp-agent restart" fixes the problem
temporarily

Best Regards,
Marco




2013/5/22 Thomas Krgel <kaergel [at] b1-systems>

> Hi Johanna,
>
> sure, I'll report my results, but this can take a while. The last time
> this issue occurred on my environment is May 10th. It occurs quite
> sporadic and i don't know how to manually reproduce this issue yet (i
> have to be very careful with my experiments since the environment is
> running productive already). Maybe you should also give dnsmasq 2.66 a
> try, because you wrote that you can manually reproduce this behavior.
>
>
> Best Regards,
> Thomas
>
>
> Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> > Hi,
> >
> > You are right. Manually doing kill -HUP <PID> has just the effect you
> mentioned. In the syslog you can see
> >
> > May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
> > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
> /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
> > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
> /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
> >
> >
> > But the problem stays. Only 'service quantum-dhcp-agent restart' fixes
> the problem.
> > If you try the newer version of the qnsmasq, I'd be interested to hear
> the results.
> >
> > BR
> > Johanna
> >
> >
> >
> > -----Original Message-----
> > From: ext Thomas Krgel [mailto:kaergel [at] b1-systems]
> > Sent: Monday, May 20, 2013 11:37 AM
> > To: Heinonen, Johanna (NSN - FI/Espoo)
> > Cc: openstack [at] lists
> > Subject: Re: [Openstack] DHCP problem in grizzly
> >
> > Hi,
> >
> > thx for the interesting info, Johanna: dnsmasq version is also 2.59 on
> > my environment. Can you can confirm that manually sigHUPing all running
> > dnsmasq processes has no effect?
> > (dnsmasq claims to have reread the configs in syslog, but still refuses
> > to deliver the new addresses.)
> > Maybe updating dnsmasq to a more recent release would solve our problem.
> > Current stable is 2.66. I'll give it a try when i get back to office
> > tomorrow.
> >
> > Best regards
> >
> > Thomas
> >
> >
> > Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> >> Hi Thomas,
> >>
> >> I am using Ubuntu12.04 and the dnsmasq version is 2.59
> >>
> >> BR
> >> Johanna
> >>
> >>
> >> -----Original Message-----
> >> From: Openstack [mailto:openstack-bounces+johanna.heinonen=
> nsn.com [at] lists] On Behalf Of ext Thomas Krgel
> >> Sent: Monday, May 20, 2013 10:09 AM
> >> To: openstack [at] lists
> >> Subject: Re: [Openstack] DHCP problem in grizzly
> >>
> >> Hi Johanna,
> >>
> >> I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
> >> noticed that new hosts have correct entries in the dnsmasq config-files.
> >> The dnsmasq processes get a HUP signal by DHCP-Agent, but simply refuse
> >> to deliver the new address. Instead dnsmasq logs claim "no address
> >> available". Exactly like in your description.
> >> What distrubtion and exact dnsmasq-versions are in use on your
> environment?
> >> I assume dnsmasq is not rereading its configs correctly on signal HUP.
> >> dnsmasq logs claim it has reread configs, but it still does not deliver
> >> the new adresses in host-file.
> >> Manually trying to sigHUP dnsmasq had no effect. The only way to get out
> >> of this state seems to be restarting DHCP-agent.
> >>
> >> Best regards
> >> Thomas
> >>
> >> Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> >>> Hi,
> >>>
> >>> I have installed grizzly with quantum and ovs-plugin. It seems that
> >>> grizzly allocates the third address of each subnet for dhcp. (In folsom
> >>> it was the second address). This means that the VMs will get addresses
> >>> .2, .4, .5, .
> >>>
> >>> In my setup the first VM always boots fine and gets the address
> x.x.x.2.
> >>> This can be seen in the syslog:
> >>>
> >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
> >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]: DHCPACK(tapdbcef145-f5)
> >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> >>>
> >>> The problem comes when I start the second VM. Nova shows that the
> >>> x.x.x.4 is allocated
> >>>
> >>> root [at] grizzly-23:~# nova list
> >>>
> +--------------------------------------+----------+--------+------------------------+
> >>> | ID | Name | Status |
> >>> Networks |
> >>>
> +--------------------------------------+----------+--------+------------------------+
> >>> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
> >>> tenant1-net=10.20.30.2 |
> >>> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
> >>> tenant1-net=10.20.30.4 |
> >>>
> +--------------------------------------+----------+--------+------------------------+
> >>>
> >>> But from syslog I see that the answer to the DHCPDISCOVER is "no
> address
> >>> available"
> >>>
> >>> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> >>> available
> >>> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> >>> available
> >>>
> >>> When I restart the quantum-dhcp-server the problem disappears. This can
> >>> be seen from the syslog:
> >>>
> >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59
> >>> cachesize 150
> >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options: IPv6
> >>> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
> >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream servers
> >>> configured
> >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static leases
> only
> >>> on 10.20.30.0, lease time 2m
> >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
> >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> >>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
> >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> >>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPNAK(tapdbcef145-f5)
> >>> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]: DHCPACK(tapdbcef145-f5)
> >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> >>>
> >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
> >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPACK(tapdbcef145-f5)
> >>> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
> >>>
> >>>
> >>> What could be the problem? Have you seen similar behavior? If yes, how
> >>> did you fix this?
> >>>
> >>> Best regards,
> >>> Johanna
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack [at] lists
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>
> >
> >
>
>
> --
> Thomas Krgel
> Linux Consultant
> Mail: kaergel [at] b1-systems
> B1 Systems GmbH
> Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


--
Marco Colombo


kaergel at b1-systems

May 22, 2013, 1:01 AM

Post #9 of 23 (442 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi Marco,

can you also reproduce it?

If so i would suggest to give dnsmasq 2.66 a try. Since i'm not able to
reproduce this behavior on the environment i'm woking on it will take
weeks to get to an really conclusive result.

Best regards
thomas


Am 22.05.2013 09:55, schrieb Marco Colombo:
> Hi All,
> i have the same problem with Grizzly, Ubuntu 12.04 and Dnsmasq 2.59
> "killall dnsmasq && service quantum-dhcp-agent restart" fixes the
> problem temporarily
>
> Best Regards,
> Marco
>
>
>
>
> 2013/5/22 Thomas Krgel <kaergel [at] b1-systems
> <mailto:kaergel [at] b1-systems>>
>
> Hi Johanna,
>
> sure, I'll report my results, but this can take a while. The last time
> this issue occurred on my environment is May 10th. It occurs quite
> sporadic and i don't know how to manually reproduce this issue yet (i
> have to be very careful with my experiments since the environment is
> running productive already). Maybe you should also give dnsmasq 2.66 a
> try, because you wrote that you can manually reproduce this behavior.
>
>
> Best Regards,
> Thomas
>
>
> Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> > Hi,
> >
> > You are right. Manually doing kill -HUP <PID> has just the effect
> you mentioned. In the syslog you can see
> >
> > May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
> > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
> /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
> > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
> /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
> >
> >
> > But the problem stays. Only 'service quantum-dhcp-agent restart'
> fixes the problem.
> > If you try the newer version of the qnsmasq, I'd be interested to
> hear the results.
> >
> > BR
> > Johanna
> >
> >
> >
> > -----Original Message-----
> > From: ext Thomas Krgel [mailto:kaergel [at] b1-systems
> <mailto:kaergel [at] b1-systems>]
> > Sent: Monday, May 20, 2013 11:37 AM
> > To: Heinonen, Johanna (NSN - FI/Espoo)
> > Cc: openstack [at] lists
> <mailto:openstack [at] lists>
> > Subject: Re: [Openstack] DHCP problem in grizzly
> >
> > Hi,
> >
> > thx for the interesting info, Johanna: dnsmasq version is also 2.59 on
> > my environment. Can you can confirm that manually sigHUPing all
> running
> > dnsmasq processes has no effect?
> > (dnsmasq claims to have reread the configs in syslog, but still
> refuses
> > to deliver the new addresses.)
> > Maybe updating dnsmasq to a more recent release would solve our
> problem.
> > Current stable is 2.66. I'll give it a try when i get back to office
> > tomorrow.
> >
> > Best regards
> >
> > Thomas
> >
> >
> > Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> >> Hi Thomas,
> >>
> >> I am using Ubuntu12.04 and the dnsmasq version is 2.59
> >>
> >> BR
> >> Johanna
> >>
> >>
> >> -----Original Message-----
> >> From: Openstack [mailto:openstack-bounces+johanna.heinonen
> <mailto:openstack-bounces%2Bjohanna.heinonen>=nsn.com [at] lists
> <mailto:nsn.com [at] lists>] On Behalf Of ext Thomas Krgel
> >> Sent: Monday, May 20, 2013 10:09 AM
> >> To: openstack [at] lists
> <mailto:openstack [at] lists>
> >> Subject: Re: [Openstack] DHCP problem in grizzly
> >>
> >> Hi Johanna,
> >>
> >> I'm facing the same behavior on a Folsom-installation on SLES11SP2. I
> >> noticed that new hosts have correct entries in the dnsmasq
> config-files.
> >> The dnsmasq processes get a HUP signal by DHCP-Agent, but simply
> refuse
> >> to deliver the new address. Instead dnsmasq logs claim "no address
> >> available". Exactly like in your description.
> >> What distrubtion and exact dnsmasq-versions are in use on your
> environment?
> >> I assume dnsmasq is not rereading its configs correctly on signal
> HUP.
> >> dnsmasq logs claim it has reread configs, but it still does not
> deliver
> >> the new adresses in host-file.
> >> Manually trying to sigHUP dnsmasq had no effect. The only way to
> get out
> >> of this state seems to be restarting DHCP-agent.
> >>
> >> Best regards
> >> Thomas
> >>
> >> Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> >>> Hi,
> >>>
> >>> I have installed grizzly with quantum and ovs-plugin. It seems that
> >>> grizzly allocates the third address of each subnet for dhcp. (In
> folsom
> >>> it was the second address). This means that the VMs will get
> addresses
> >>> .2, .4, .5, .
> >>>
> >>> In my setup the first VM always boots fine and gets the address
> x.x.x.2.
> >>> This can be seen in the syslog:
> >>>
> >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
> >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> DHCPACK(tapdbcef145-f5)
> >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> >>>
> >>> The problem comes when I start the second VM. Nova shows that the
> >>> x.x.x.4 is allocated
> >>>
> >>> root [at] grizzly-23:~# nova list
> >>>
> +--------------------------------------+----------+--------+------------------------+
> >>> | ID | Name | Status |
> >>> Networks |
> >>>
> +--------------------------------------+----------+--------+------------------------+
> >>> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
> >>> tenant1-net=10.20.30.2 |
> >>> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
> >>> tenant1-net=10.20.30.4 |
> >>>
> +--------------------------------------+----------+--------+------------------------+
> >>>
> >>> But from syslog I see that the answer to the DHCPDISCOVER is "no
> address
> >>> available"
> >>>
> >>> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> >>> available
> >>> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
> >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> >>> available
> >>>
> >>> When I restart the quantum-dhcp-server the problem disappears.
> This can
> >>> be seen from the syslog:
> >>>
> >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59
> >>> cachesize 150
> >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options:
> IPv6
> >>> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
> >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream
> servers
> >>> configured
> >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static
> leases only
> >>> on 10.20.30.0, lease time 2m
> >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
> >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> >>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
> >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> >>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPNAK(tapdbcef145-f5)
> >>> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPACK(tapdbcef145-f5)
> >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> >>>
> >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
> >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> DHCPACK(tapdbcef145-f5)
> >>> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
> >>>
> >>>
> >>> What could be the problem? Have you seen similar behavior? If
> yes, how
> >>> did you fix this?
> >>>
> >>> Best regards,
> >>> Johanna
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>
> >
> >
>
>
> --
> Thomas Krgel
> Linux Consultant
> Mail: kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>
> B1 Systems GmbH
> Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> Marco Colombo


--
Thomas Krgel
Linux Consultant
Tel.: +49 172 2037945
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Attachments: signature.asc (0.54 KB)


mail.colombomarco at gmail

May 22, 2013, 5:33 AM

Post #10 of 23 (439 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi Thomas,
i have upgrade dnsmasq to version 2.66, but the problem persist.
If you need more log/information, i'm able to reproduce the problem.

Thanks
Best Regards


2013/5/22 Thomas Krgel <kaergel [at] b1-systems>

> Hi Marco,
>
> can you also reproduce it?
>
> If so i would suggest to give dnsmasq 2.66 a try. Since i'm not able to
> reproduce this behavior on the environment i'm woking on it will take
> weeks to get to an really conclusive result.
>
> Best regards
> thomas
>
>
> Am 22.05.2013 09:55, schrieb Marco Colombo:
> > Hi All,
> > i have the same problem with Grizzly, Ubuntu 12.04 and Dnsmasq 2.59
> > "killall dnsmasq && service quantum-dhcp-agent restart" fixes the
> > problem temporarily
> >
> > Best Regards,
> > Marco
> >
> >
> >
> >
> > 2013/5/22 Thomas Krgel <kaergel [at] b1-systems
> > <mailto:kaergel [at] b1-systems>>
> >
> > Hi Johanna,
> >
> > sure, I'll report my results, but this can take a while. The last
> time
> > this issue occurred on my environment is May 10th. It occurs quite
> > sporadic and i don't know how to manually reproduce this issue yet (i
> > have to be very careful with my experiments since the environment is
> > running productive already). Maybe you should also give dnsmasq 2.66
> a
> > try, because you wrote that you can manually reproduce this behavior.
> >
> >
> > Best Regards,
> > Thomas
> >
> >
> > Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> > > Hi,
> > >
> > > You are right. Manually doing kill -HUP <PID> has just the effect
> > you mentioned. In the syslog you can see
> > >
> > > May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
> > > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
> > /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
> > > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
> > /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
> > >
> > >
> > > But the problem stays. Only 'service quantum-dhcp-agent restart'
> > fixes the problem.
> > > If you try the newer version of the qnsmasq, I'd be interested to
> > hear the results.
> > >
> > > BR
> > > Johanna
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: ext Thomas Krgel [mailto:kaergel [at] b1-systems
> > <mailto:kaergel [at] b1-systems>]
> > > Sent: Monday, May 20, 2013 11:37 AM
> > > To: Heinonen, Johanna (NSN - FI/Espoo)
> > > Cc: openstack [at] lists
> > <mailto:openstack [at] lists>
> > > Subject: Re: [Openstack] DHCP problem in grizzly
> > >
> > > Hi,
> > >
> > > thx for the interesting info, Johanna: dnsmasq version is also
> 2.59 on
> > > my environment. Can you can confirm that manually sigHUPing all
> > running
> > > dnsmasq processes has no effect?
> > > (dnsmasq claims to have reread the configs in syslog, but still
> > refuses
> > > to deliver the new addresses.)
> > > Maybe updating dnsmasq to a more recent release would solve our
> > problem.
> > > Current stable is 2.66. I'll give it a try when i get back to
> office
> > > tomorrow.
> > >
> > > Best regards
> > >
> > > Thomas
> > >
> > >
> > > Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> > >> Hi Thomas,
> > >>
> > >> I am using Ubuntu12.04 and the dnsmasq version is 2.59
> > >>
> > >> BR
> > >> Johanna
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Openstack [mailto:openstack-bounces+johanna.heinonen
> > <mailto:openstack-bounces%2Bjohanna.heinonen>=
> nsn.com [at] lists
> > <mailto:nsn.com [at] lists>] On Behalf Of ext Thomas Krgel
> > >> Sent: Monday, May 20, 2013 10:09 AM
> > >> To: openstack [at] lists
> > <mailto:openstack [at] lists>
> > >> Subject: Re: [Openstack] DHCP problem in grizzly
> > >>
> > >> Hi Johanna,
> > >>
> > >> I'm facing the same behavior on a Folsom-installation on
> SLES11SP2. I
> > >> noticed that new hosts have correct entries in the dnsmasq
> > config-files.
> > >> The dnsmasq processes get a HUP signal by DHCP-Agent, but simply
> > refuse
> > >> to deliver the new address. Instead dnsmasq logs claim "no address
> > >> available". Exactly like in your description.
> > >> What distrubtion and exact dnsmasq-versions are in use on your
> > environment?
> > >> I assume dnsmasq is not rereading its configs correctly on signal
> > HUP.
> > >> dnsmasq logs claim it has reread configs, but it still does not
> > deliver
> > >> the new adresses in host-file.
> > >> Manually trying to sigHUP dnsmasq had no effect. The only way to
> > get out
> > >> of this state seems to be restarting DHCP-agent.
> > >>
> > >> Best regards
> > >> Thomas
> > >>
> > >> Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> > >>> Hi,
> > >>>
> > >>> I have installed grizzly with quantum and ovs-plugin. It seems
> that
> > >>> grizzly allocates the third address of each subnet for dhcp. (In
> > folsom
> > >>> it was the second address). This means that the VMs will get
> > addresses
> > >>> .2, .4, .5, .
> > >>>
> > >>> In my setup the first VM always boots fine and gets the address
> > x.x.x.2.
> > >>> This can be seen in the syslog:
> > >>>
> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> > DHCPACK(tapdbcef145-f5)
> > >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> > >>>
> > >>> The problem comes when I start the second VM. Nova shows that the
> > >>> x.x.x.4 is allocated
> > >>>
> > >>> root [at] grizzly-23:~# nova list
> > >>>
> >
> +--------------------------------------+----------+--------+------------------------+
> > >>> | ID | Name | Status |
> > >>> Networks |
> > >>>
> >
> +--------------------------------------+----------+--------+------------------------+
> > >>> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
> > >>> tenant1-net=10.20.30.2 |
> > >>> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
> > >>> tenant1-net=10.20.30.4 |
> > >>>
> >
> +--------------------------------------+----------+--------+------------------------+
> > >>>
> > >>> But from syslog I see that the answer to the DHCPDISCOVER is "no
> > address
> > >>> available"
> > >>>
> > >>> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no
> address
> > >>> available
> > >>> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no
> address
> > >>> available
> > >>>
> > >>> When I restart the quantum-dhcp-server the problem disappears.
> > This can
> > >>> be seen from the syslog:
> > >>>
> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started, version 2.59
> > >>> cachesize 150
> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time options:
> > IPv6
> > >>> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no upstream
> > servers
> > >>> configured
> > >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static
> > leases only
> > >>> on 10.20.30.0, lease time 2m
> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
> > >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> > >>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
> > >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> > >>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > DHCPNAK(tapdbcef145-f5)
> > >>> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > DHCPACK(tapdbcef145-f5)
> > >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> > >>>
> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> > DHCPACK(tapdbcef145-f5)
> > >>> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
> > >>>
> > >>>
> > >>> What could be the problem? Have you seen similar behavior? If
> > yes, how
> > >>> did you fix this?
> > >>>
> > >>> Best regards,
> > >>> Johanna
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Mailing list: https://launchpad.net/~openstack
> > >>> Post to : openstack [at] lists
> > <mailto:openstack [at] lists>
> > >>> Unsubscribe : https://launchpad.net/~openstack
> > >>> More help : https://help.launchpad.net/ListHelp
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > Thomas Krgel
> > Linux Consultant
> > Mail: kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>
> > B1 Systems GmbH
> > Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
> > GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB
> 3537
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack [at] lists
> > <mailto:openstack [at] lists>
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
> > --
> > Marco Colombo
>
>
> --
> Thomas Krgel
> Linux Consultant
> Tel.: +49 172 2037945
> Mail: kaergel [at] b1-systems
> B1 Systems GmbH
> Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>
>


--
Marco Colombo


kaergel at b1-systems

May 22, 2013, 8:05 AM

Post #11 of 23 (442 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi Marco,

thanks for the interesting information. I think we can be sure now that
this is a bug in dnsmasq. I'll go ahead and report this bug to the
dnsmasq-developers tomorrow morning. Hopefully they can fix this issue soon.
I'll report the details when the bugreport is open. Maybe they want more
infos from us...

Best regards
Thomas

Am 22.05.2013 14:33, schrieb Marco Colombo:
> Hi Thomas,
> i have upgrade dnsmasq to version 2.66, but the problem persist.
> If you need more log/information, i'm able to reproduce the problem.
>
> Thanks
> Best Regards
>
>
> 2013/5/22 Thomas Krgel <kaergel [at] b1-systems
> <mailto:kaergel [at] b1-systems>>
>
> Hi Marco,
>
> can you also reproduce it?
>
> If so i would suggest to give dnsmasq 2.66 a try. Since i'm not able to
> reproduce this behavior on the environment i'm woking on it will take
> weeks to get to an really conclusive result.
>
> Best regards
> thomas
>
>
> Am 22.05.2013 09:55, schrieb Marco Colombo:
> > Hi All,
> > i have the same problem with Grizzly, Ubuntu 12.04 and Dnsmasq 2.59
> > "killall dnsmasq && service quantum-dhcp-agent restart" fixes the
> > problem temporarily
> >
> > Best Regards,
> > Marco
> >
> >
> >
> >
> > 2013/5/22 Thomas Krgel <kaergel [at] b1-systems
> <mailto:kaergel [at] b1-systems>
> > <mailto:kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>>>
> >
> > Hi Johanna,
> >
> > sure, I'll report my results, but this can take a while. The
> last time
> > this issue occurred on my environment is May 10th. It occurs quite
> > sporadic and i don't know how to manually reproduce this issue
> yet (i
> > have to be very careful with my experiments since the
> environment is
> > running productive already). Maybe you should also give
> dnsmasq 2.66 a
> > try, because you wrote that you can manually reproduce this
> behavior.
> >
> >
> > Best Regards,
> > Thomas
> >
> >
> > Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> > > Hi,
> > >
> > > You are right. Manually doing kill -HUP <PID> has just the
> effect
> > you mentioned. In the syslog you can see
> > >
> > > May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
> > > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
> > /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
> > > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
> > /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
> > >
> > >
> > > But the problem stays. Only 'service quantum-dhcp-agent restart'
> > fixes the problem.
> > > If you try the newer version of the qnsmasq, I'd be
> interested to
> > hear the results.
> > >
> > > BR
> > > Johanna
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: ext Thomas Krgel [mailto:kaergel [at] b1-systems
> <mailto:kaergel [at] b1-systems>
> > <mailto:kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>>]
> > > Sent: Monday, May 20, 2013 11:37 AM
> > > To: Heinonen, Johanna (NSN - FI/Espoo)
> > > Cc: openstack [at] lists
> <mailto:openstack [at] lists>
> > <mailto:openstack [at] lists
> <mailto:openstack [at] lists>>
> > > Subject: Re: [Openstack] DHCP problem in grizzly
> > >
> > > Hi,
> > >
> > > thx for the interesting info, Johanna: dnsmasq version is
> also 2.59 on
> > > my environment. Can you can confirm that manually sigHUPing all
> > running
> > > dnsmasq processes has no effect?
> > > (dnsmasq claims to have reread the configs in syslog, but still
> > refuses
> > > to deliver the new addresses.)
> > > Maybe updating dnsmasq to a more recent release would solve our
> > problem.
> > > Current stable is 2.66. I'll give it a try when i get back
> to office
> > > tomorrow.
> > >
> > > Best regards
> > >
> > > Thomas
> > >
> > >
> > > Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
> > >> Hi Thomas,
> > >>
> > >> I am using Ubuntu12.04 and the dnsmasq version is 2.59
> > >>
> > >> BR
> > >> Johanna
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Openstack [mailto:openstack-bounces+johanna.heinonen
> <mailto:openstack-bounces%2Bjohanna.heinonen>
> > <mailto:openstack-bounces%2Bjohanna.heinonen
> <mailto:openstack-bounces%252Bjohanna.heinonen>>=nsn.com [at] lists
> <mailto:nsn.com [at] lists>
> > <mailto:nsn.com [at] lists
> <mailto:nsn.com [at] lists>>] On Behalf Of ext Thomas Krgel
> > >> Sent: Monday, May 20, 2013 10:09 AM
> > >> To: openstack [at] lists
> <mailto:openstack [at] lists>
> > <mailto:openstack [at] lists
> <mailto:openstack [at] lists>>
> > >> Subject: Re: [Openstack] DHCP problem in grizzly
> > >>
> > >> Hi Johanna,
> > >>
> > >> I'm facing the same behavior on a Folsom-installation on
> SLES11SP2. I
> > >> noticed that new hosts have correct entries in the dnsmasq
> > config-files.
> > >> The dnsmasq processes get a HUP signal by DHCP-Agent, but
> simply
> > refuse
> > >> to deliver the new address. Instead dnsmasq logs claim "no
> address
> > >> available". Exactly like in your description.
> > >> What distrubtion and exact dnsmasq-versions are in use on your
> > environment?
> > >> I assume dnsmasq is not rereading its configs correctly on
> signal
> > HUP.
> > >> dnsmasq logs claim it has reread configs, but it still does not
> > deliver
> > >> the new adresses in host-file.
> > >> Manually trying to sigHUP dnsmasq had no effect. The only
> way to
> > get out
> > >> of this state seems to be restarting DHCP-agent.
> > >>
> > >> Best regards
> > >> Thomas
> > >>
> > >> Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN -
> FI/Espoo):
> > >>> Hi,
> > >>>
> > >>> I have installed grizzly with quantum and ovs-plugin. It
> seems that
> > >>> grizzly allocates the third address of each subnet for
> dhcp. (In
> > folsom
> > >>> it was the second address). This means that the VMs will get
> > addresses
> > >>> .2, .4, .5, .
> > >>>
> > >>> In my setup the first VM always boots fine and gets the
> address
> > x.x.x.2.
> > >>> This can be seen in the syslog:
> > >>>
> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
> > DHCPACK(tapdbcef145-f5)
> > >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> > >>>
> > >>> The problem comes when I start the second VM. Nova shows
> that the
> > >>> x.x.x.4 is allocated
> > >>>
> > >>> root [at] grizzly-23:~# nova list
> > >>>
> >
> +--------------------------------------+----------+--------+------------------------+
> > >>> | ID | Name | Status |
> > >>> Networks |
> > >>>
> >
> +--------------------------------------+----------+--------+------------------------+
> > >>> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
> > >>> tenant1-net=10.20.30.2 |
> > >>> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
> > >>> tenant1-net=10.20.30.4 |
> > >>>
> >
> +--------------------------------------+----------+--------+------------------------+
> > >>>
> > >>> But from syslog I see that the answer to the DHCPDISCOVER
> is "no
> > address
> > >>> available"
> > >>>
> > >>> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a
> no address
> > >>> available
> > >>> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a
> no address
> > >>> available
> > >>>
> > >>> When I restart the quantum-dhcp-server the problem disappears.
> > This can
> > >>> be seen from the syslog:
> > >>>
> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started,
> version 2.59
> > >>> cachesize 150
> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time
> options:
> > IPv6
> > >>> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no
> upstream
> > servers
> > >>> configured
> > >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static
> > leases only
> > >>> on 10.20.30.0, lease time 2m
> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
> > >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> > >>>
> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
> > >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
> > >>>
> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > DHCPNAK(tapdbcef145-f5)
> > >>> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
> > DHCPACK(tapdbcef145-f5)
> > >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> > >>>
> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
> > DHCPACK(tapdbcef145-f5)
> > >>> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
> > >>>
> > >>>
> > >>> What could be the problem? Have you seen similar behavior? If
> > yes, how
> > >>> did you fix this?
> > >>>
> > >>> Best regards,
> > >>> Johanna
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Mailing list: https://launchpad.net/~openstack
> > >>> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> > <mailto:openstack [at] lists
> <mailto:openstack [at] lists>>
> > >>> Unsubscribe : https://launchpad.net/~openstack
> > >>> More help : https://help.launchpad.net/ListHelp
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > Thomas Krgel
> > Linux Consultant
> > Mail: kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>
> <mailto:kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>>
> > B1 Systems GmbH
> > Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
> > GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG:
> Ingolstadt,HRB 3537
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> > <mailto:openstack [at] lists
> <mailto:openstack [at] lists>>
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
> > --
> > Marco Colombo
>
>
> --
> Thomas Krgel
> Linux Consultant
> Tel.: +49 172 2037945
> Mail: kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>
> B1 Systems GmbH
> Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>
>
>
>
> --
> Marco Colombo


--
Thomas Krgel
Linux Consultant
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Attachments: signature.asc (0.54 KB)


kaergel at b1-systems

May 23, 2013, 12:35 AM

Post #12 of 23 (433 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi,

the bug report is open and can be viewed at:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q2/007212.html

I used some of your logs in order to add more details to my description.
Hopefully someone can help us solving this issue.

Best regards
thomas

Am 22.05.2013 17:05, schrieb Thomas Krgel:
> Hi Marco,
>
> thanks for the interesting information. I think we can be sure now that
> this is a bug in dnsmasq. I'll go ahead and report this bug to the
> dnsmasq-developers tomorrow morning. Hopefully they can fix this issue soon.
> I'll report the details when the bugreport is open. Maybe they want more
> infos from us...
>
> Best regards
> Thomas
>
> Am 22.05.2013 14:33, schrieb Marco Colombo:
>> Hi Thomas,
>> i have upgrade dnsmasq to version 2.66, but the problem persist.
>> If you need more log/information, i'm able to reproduce the problem.
>>
>> Thanks
>> Best Regards
>>
>>
>> 2013/5/22 Thomas Krgel <kaergel [at] b1-systems
>> <mailto:kaergel [at] b1-systems>>
>>
>> Hi Marco,
>>
>> can you also reproduce it?
>>
>> If so i would suggest to give dnsmasq 2.66 a try. Since i'm not able to
>> reproduce this behavior on the environment i'm woking on it will take
>> weeks to get to an really conclusive result.
>>
>> Best regards
>> thomas
>>
>>
>> Am 22.05.2013 09:55, schrieb Marco Colombo:
>> > Hi All,
>> > i have the same problem with Grizzly, Ubuntu 12.04 and Dnsmasq 2.59
>> > "killall dnsmasq && service quantum-dhcp-agent restart" fixes the
>> > problem temporarily
>> >
>> > Best Regards,
>> > Marco
>> >
>> >
>> >
>> >
>> > 2013/5/22 Thomas Krgel <kaergel [at] b1-systems
>> <mailto:kaergel [at] b1-systems>
>> > <mailto:kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>>>
>> >
>> > Hi Johanna,
>> >
>> > sure, I'll report my results, but this can take a while. The
>> last time
>> > this issue occurred on my environment is May 10th. It occurs quite
>> > sporadic and i don't know how to manually reproduce this issue
>> yet (i
>> > have to be very careful with my experiments since the
>> environment is
>> > running productive already). Maybe you should also give
>> dnsmasq 2.66 a
>> > try, because you wrote that you can manually reproduce this
>> behavior.
>> >
>> >
>> > Best Regards,
>> > Thomas
>> >
>> >
>> > Am 20.05.2013 12:25, schrieb Heinonen, Johanna (NSN - FI/Espoo):
>> > > Hi,
>> > >
>> > > You are right. Manually doing kill -HUP <PID> has just the
>> effect
>> > you mentioned. In the syslog you can see
>> > >
>> > > May 20 13:09:41 grizzly-236 dnsmasq[6170]: cleared cache
>> > > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
>> > /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/host
>> > > May 20 13:09:41 grizzly-236 dnsmasq-dhcp[6170]: read
>> > /var/lib/quantum/dhcp/d5879bbb-ada6-4323-a7b1-87b5db244513/opts
>> > >
>> > >
>> > > But the problem stays. Only 'service quantum-dhcp-agent restart'
>> > fixes the problem.
>> > > If you try the newer version of the qnsmasq, I'd be
>> interested to
>> > hear the results.
>> > >
>> > > BR
>> > > Johanna
>> > >
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: ext Thomas Krgel [mailto:kaergel [at] b1-systems
>> <mailto:kaergel [at] b1-systems>
>> > <mailto:kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>>]
>> > > Sent: Monday, May 20, 2013 11:37 AM
>> > > To: Heinonen, Johanna (NSN - FI/Espoo)
>> > > Cc: openstack [at] lists
>> <mailto:openstack [at] lists>
>> > <mailto:openstack [at] lists
>> <mailto:openstack [at] lists>>
>> > > Subject: Re: [Openstack] DHCP problem in grizzly
>> > >
>> > > Hi,
>> > >
>> > > thx for the interesting info, Johanna: dnsmasq version is
>> also 2.59 on
>> > > my environment. Can you can confirm that manually sigHUPing all
>> > running
>> > > dnsmasq processes has no effect?
>> > > (dnsmasq claims to have reread the configs in syslog, but still
>> > refuses
>> > > to deliver the new addresses.)
>> > > Maybe updating dnsmasq to a more recent release would solve our
>> > problem.
>> > > Current stable is 2.66. I'll give it a try when i get back
>> to office
>> > > tomorrow.
>> > >
>> > > Best regards
>> > >
>> > > Thomas
>> > >
>> > >
>> > > Am 20.05.2013 10:21, schrieb Heinonen, Johanna (NSN - FI/Espoo):
>> > >> Hi Thomas,
>> > >>
>> > >> I am using Ubuntu12.04 and the dnsmasq version is 2.59
>> > >>
>> > >> BR
>> > >> Johanna
>> > >>
>> > >>
>> > >> -----Original Message-----
>> > >> From: Openstack [mailto:openstack-bounces+johanna.heinonen
>> <mailto:openstack-bounces%2Bjohanna.heinonen>
>> > <mailto:openstack-bounces%2Bjohanna.heinonen
>> <mailto:openstack-bounces%252Bjohanna.heinonen>>=nsn.com [at] lists
>> <mailto:nsn.com [at] lists>
>> > <mailto:nsn.com [at] lists
>> <mailto:nsn.com [at] lists>>] On Behalf Of ext Thomas Krgel
>> > >> Sent: Monday, May 20, 2013 10:09 AM
>> > >> To: openstack [at] lists
>> <mailto:openstack [at] lists>
>> > <mailto:openstack [at] lists
>> <mailto:openstack [at] lists>>
>> > >> Subject: Re: [Openstack] DHCP problem in grizzly
>> > >>
>> > >> Hi Johanna,
>> > >>
>> > >> I'm facing the same behavior on a Folsom-installation on
>> SLES11SP2. I
>> > >> noticed that new hosts have correct entries in the dnsmasq
>> > config-files.
>> > >> The dnsmasq processes get a HUP signal by DHCP-Agent, but
>> simply
>> > refuse
>> > >> to deliver the new address. Instead dnsmasq logs claim "no
>> address
>> > >> available". Exactly like in your description.
>> > >> What distrubtion and exact dnsmasq-versions are in use on your
>> > environment?
>> > >> I assume dnsmasq is not rereading its configs correctly on
>> signal
>> > HUP.
>> > >> dnsmasq logs claim it has reread configs, but it still does not
>> > deliver
>> > >> the new adresses in host-file.
>> > >> Manually trying to sigHUP dnsmasq had no effect. The only
>> way to
>> > get out
>> > >> of this state seems to be restarting DHCP-agent.
>> > >>
>> > >> Best regards
>> > >> Thomas
>> > >>
>> > >> Am 20.05.2013 08:51, schrieb Heinonen, Johanna (NSN -
>> FI/Espoo):
>> > >>> Hi,
>> > >>>
>> > >>> I have installed grizzly with quantum and ovs-plugin. It
>> seems that
>> > >>> grizzly allocates the third address of each subnet for
>> dhcp. (In
>> > folsom
>> > >>> it was the second address). This means that the VMs will get
>> > addresses
>> > >>> .2, .4, .5, .
>> > >>>
>> > >>> In my setup the first VM always boots fine and gets the
>> address
>> > x.x.x.2.
>> > >>> This can be seen in the syslog:
>> > >>>
>> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> > >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:2d:0d:e0
>> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> > >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> > >>> May 20 08:29:23 grizzly-236 dnsmasq-dhcp[2190]:
>> > DHCPACK(tapdbcef145-f5)
>> > >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>> > >>>
>> > >>> The problem comes when I start the second VM. Nova shows
>> that the
>> > >>> x.x.x.4 is allocated
>> > >>>
>> > >>> root [at] grizzly-23:~# nova list
>> > >>>
>> >
>> +--------------------------------------+----------+--------+------------------------+
>> > >>> | ID | Name | Status |
>> > >>> Networks |
>> > >>>
>> >
>> +--------------------------------------+----------+--------+------------------------+
>> > >>> | c112ccbb-5039-4d05-b414-b53a1eafa2d8 | q-test | ACTIVE |
>> > >>> tenant1-net=10.20.30.2 |
>> > >>> | 4f26975c-995d-403d-88b0-e7bbf189baad | q-test-2 | ACTIVE |
>> > >>> tenant1-net=10.20.30.4 |
>> > >>>
>> >
>> +--------------------------------------+----------+--------+------------------------+
>> > >>>
>> > >>> But from syslog I see that the answer to the DHCPDISCOVER
>> is "no
>> > address
>> > >>> available"
>> > >>>
>> > >>> May 20 08:33:34 grizzly-236 dnsmasq-dhcp[2190]:
>> > >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a
>> no address
>> > >>> available
>> > >>> May 20 08:33:52 grizzly-236 dnsmasq-dhcp[2190]:
>> > >>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a
>> no address
>> > >>> available
>> > >>>
>> > >>> When I restart the quantum-dhcp-server the problem disappears.
>> > This can
>> > >>> be seen from the syslog:
>> > >>>
>> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: started,
>> version 2.59
>> > >>> cachesize 150
>> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: compile time
>> options:
>> > IPv6
>> > >>> GNU-getopt DBus i18n DHCP TFTP conntrack IDN
>> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: warning: no
>> upstream
>> > servers
>> > >>> configured
>> > >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: DHCP, static
>> > leases only
>> > >>> on 10.20.30.0, lease time 2m
>> > >>> May 20 09:01:40 grizzly-236 dnsmasq[7235]: cleared cache
>> > >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
>> > >>>
>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/host
>> > >>> May 20 09:01:40 grizzly-236 dnsmasq-dhcp[7235]: read
>> > >>>
>> /var/lib/quantum/dhcp/e6f27330-be41-478c-b4d2-49ed4ce0af00/opts
>> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> > DHCPNAK(tapdbcef145-f5)
>> > >>> 10.20.30.2 fa:16:3e:2d:0d:e0 lease not found
>> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> > >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:2d:0d:e0
>> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> > >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.2 fa:16:3e:2d:0d:e0
>> > >>> May 20 09:02:19 grizzly-236 dnsmasq-dhcp[7235]:
>> > DHCPACK(tapdbcef145-f5)
>> > >>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>> > >>>
>> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> > >>> DHCPDISCOVER(tapdbcef145-f5) fa:16:3e:fc:1f:9a*
>> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> > >>> DHCPOFFER(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
>> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> > >>> DHCPREQUEST(tapdbcef145-f5) 10.20.30.4 fa:16:3e:fc:1f:9a*
>> > >>> *May 20 09:03:39 grizzly-236 dnsmasq-dhcp[7235]:
>> > DHCPACK(tapdbcef145-f5)
>> > >>> 10.20.30.4 fa:16:3e:fc:1f:9a 10-20-30-4*
>> > >>>
>> > >>>
>> > >>> What could be the problem? Have you seen similar behavior? If
>> > yes, how
>> > >>> did you fix this?
>> > >>>
>> > >>> Best regards,
>> > >>> Johanna
>> > >>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> Mailing list: https://launchpad.net/~openstack
>> > >>> Post to : openstack [at] lists
>> <mailto:openstack [at] lists>
>> > <mailto:openstack [at] lists
>> <mailto:openstack [at] lists>>
>> > >>> Unsubscribe : https://launchpad.net/~openstack
>> > >>> More help : https://help.launchpad.net/ListHelp
>> > >>>
>> > >>
>> > >>
>> > >
>> > >
>> >
>> >
>> > --
>> > Thomas Krgel
>> > Linux Consultant
>> > Mail: kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>
>> <mailto:kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>>
>> > B1 Systems GmbH
>> > Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
>> > GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG:
>> Ingolstadt,HRB 3537
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack [at] lists
>> <mailto:openstack [at] lists>
>> > <mailto:openstack [at] lists
>> <mailto:openstack [at] lists>>
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help : https://help.launchpad.net/ListHelp
>> >
>> >
>> >
>> >
>> > --
>> > Marco Colombo
>>
>>
>> --
>> Thomas Krgel
>> Linux Consultant
>> Tel.: +49 172 2037945
>> Mail: kaergel [at] b1-systems <mailto:kaergel [at] b1-systems>
>> B1 Systems GmbH
>> Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
>> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>>
>>
>>
>>
>> --
>> Marco Colombo
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp


--
Thomas Krgel
Linux Consultant
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Attachments: signature.asc (0.54 KB)


kaergel at b1-systems

May 23, 2013, 2:18 AM

Post #13 of 23 (438 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi,

can somebody help to gather the desired informations? Since I'm not
able to reproduce our problem i cannot answer Simons questions:

>> The above mechanism is working fine in most cases. But lately there were
>> a few reports (4 afaik) that this mechanism is not working entirely
>> reliable.
>> Dnsmasq re-reads it's configs but still claims that no address is
>> available for the specific mac-address, while other clients are still
>> receiving their adresses fine.
>> The new entries in hostsfile do not get served until dnsmasq is killed
>> and restarted.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This might be significant, since the process on re-read a hostfile is
>
> 1) Throw away all entries which came from a hostsfile in the past.
> 2) Read the hostsfile and insert all the entries found there.
>
> It's difficult to see how that process could distinguish between new and old entries except if some hosts already have leases. Can you Explore this a bit more? Maybe release a DHCP lease on an old host, and then see if it can get a lease back again?
>

and...

>> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
>> May 20 09:04:34 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
>> available
>> May 20 09:04:52 grizzly-236 dnsmasq-dhcp[2190]:
>> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
>> available
>
>
> This is definitely "static address only on this network, unknown host"
>
>
> It may be worth setting --log-dhcp for the extra information that can give us.




Am 23.05.2013 09:35, schrieb Thomas Krgel:
> Hi,
>
> the bug report is open and can be viewed at:
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q2/007212.html
>
> I used some of your logs in order to add more details to my description.
> Hopefully someone can help us solving this issue.
>
> Best regards
> thomas
>


Bets regards
thomas
--
Thomas Krgel
Linux Consultant
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Attachments: signature.asc (0.54 KB)


mail.colombomarco at gmail

May 23, 2013, 6:06 AM

Post #14 of 23 (437 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi Thomas,
here you can find some logs required by dnsmasq devs.

http://paste.openstack.org/show/37668/

For this answer, "Maybe release a DHCP lease on an old host, and then see
if it can get a lease back again?" :
When the problem appears, the VM can't get lease back.

Should you have any further question please don't hesitate to contact me.
Thanks
Best Regards


2013/5/23 Thomas Krgel <kaergel [at] b1-systems>

> Hi,
>
> can somebody help to gather the desired informations? Since I'm not
> able to reproduce our problem i cannot answer Simons questions:
>
> >> The above mechanism is working fine in most cases. But lately there were
> >> a few reports (4 afaik) that this mechanism is not working entirely
> >> reliable.
> >> Dnsmasq re-reads it's configs but still claims that no address is
> >> available for the specific mac-address, while other clients are still
> >> receiving their adresses fine.
> >> The new entries in hostsfile do not get served until dnsmasq is killed
> >> and restarted.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > This might be significant, since the process on re-read a hostfile is
> >
> > 1) Throw away all entries which came from a hostsfile in the past.
> > 2) Read the hostsfile and insert all the entries found there.
> >
> > It's difficult to see how that process could distinguish between new and
> old entries except if some hosts already have leases. Can you Explore this
> a bit more? Maybe release a DHCP lease on an old host, and then see if it
> can get a lease back again?
> >
>
> and...
>
> >> 10.20.30.2 fa:16:3e:2d:0d:e0 10-20-30-2
> >> May 20 09:04:34 grizzly-236 dnsmasq-dhcp[2190]:
> >> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> >> available
> >> May 20 09:04:52 grizzly-236 dnsmasq-dhcp[2190]:
> >> DHCPDISCOVER(tapdbcef145-f5) 10.0.2.15 fa:16:3e:fc:1f:9a no address
> >> available
> >
> >
> > This is definitely "static address only on this network, unknown host"
> >
> >
> > It may be worth setting --log-dhcp for the extra information that can
> give us.
>
>
>
>
> Am 23.05.2013 09:35, schrieb Thomas Krgel:
> > Hi,
> >
> > the bug report is open and can be viewed at:
> >
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q2/007212.html
> >
> > I used some of your logs in order to add more details to my description.
> > Hopefully someone can help us solving this issue.
> >
> > Best regards
> > thomas
> >
>
>
> Bets regards
> thomas
> --
> Thomas Krgel
> Linux Consultant
> Mail: kaergel [at] b1-systems
> B1 Systems GmbH
> Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>
>


--
Marco Colombo


kaergel at b1-systems

May 23, 2013, 8:19 AM

Post #15 of 23 (435 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi,

thank you very much, Marco. I posted your logs on dnsmasq-mailing-list
and will report back when i receive an answer.

Best regards
Thomas

Am 23.05.2013 15:06, schrieb Marco Colombo:
> Hi Thomas,
> here you can find some logs required by dnsmasq devs.
>
> http://paste.openstack.org/show/37668/
>
> For this answer, "Maybe release a DHCP lease on an old host, and then
> see if it can get a lease back again?" :
> When the problem appears, the VM can't get lease back.
>
> Should you have any further question please don't hesitate to contact me.
> Thanks
> Best Regards
>
> --
> Marco Colombo
Attachments: signature.asc (0.54 KB)


mail.colombomarco at gmail

Jun 10, 2013, 3:12 AM

Post #16 of 23 (320 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi Thomas,
any good news from dnsmasq dev?

Thanks


2013/5/23 Thomas Krgel <kaergel [at] b1-systems>

> Hi,
>
> thank you very much, Marco. I posted your logs on dnsmasq-mailing-list
> and will report back when i receive an answer.
>
> Best regards
> Thomas
>
> Am 23.05.2013 15:06, schrieb Marco Colombo:
> > Hi Thomas,
> > here you can find some logs required by dnsmasq devs.
> >
> > http://paste.openstack.org/show/37668/
> >
> > For this answer, "Maybe release a DHCP lease on an old host, and then
> > see if it can get a lease back again?" :
> > When the problem appears, the VM can't get lease back.
> >
> > Should you have any further question please don't hesitate to contact me.
> > Thanks
> > Best Regards
> >
> > --
> > Marco Colombo
>
>
>
>
>
>


--
Marco Colombo


kaergel at b1-systems

Jul 1, 2013, 11:09 PM

Post #17 of 23 (223 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi,

Unfortunately i was bussy with some other topics regarding the current
project im involved in, but I'm still trying to solve this issue.

A shot status update regarding dnsmasq issues we discovered:
-dnsmasq developers don't see the possibility that the behaviour we are
experiencing is caused by dnsmasq.
-I had some interesting discussions with some of the developers at my
office regarding the hostsfile and it's usage. We concluded with the
assumption that this behaviour may be caused by an old file handle. So
that dnsmasq is still reading old data from disc and not the updated
hostsfile.
-The next steps will be to check the filesystem handle of the hostfile
during runtime. One Option for a solution is to try to do an filesystem
sync bevor sighuping dnsmasq. Another option is to change the filesystem
on which the hostfile resides.

I hope with information we're able to hunt this problem down soon. I
would appreciate any help.

Best regards

Thomas


Am 10.06.2013 12:12, schrieb Marco Colombo:
> Hi Thomas,
> any good news from dnsmasq dev?
>
> Thanks
>
>
> 2013/5/23 Thomas Krgel <kaergel [at] b1-systems
> <mailto:kaergel [at] b1-systems>>
>
> Hi,
>
> thank you very much, Marco. I posted your logs on dnsmasq-mailing-list
> and will report back when i receive an answer.
>
> Best regards
> Thomas
>
> Am 23.05.2013 15:06, schrieb Marco Colombo:
> > Hi Thomas,
> > here you can find some logs required by dnsmasq devs.
> >
> > http://paste.openstack.org/show/37668/
> >
> > For this answer, "Maybe release a DHCP lease on an old host, and then
> > see if it can get a lease back again?" :
> > When the problem appears, the VM can't get lease back.
> >
> > Should you have any further question please don't hesitate to
> contact me.
> > Thanks
> > Best Regards
> >
> > --
> > Marco Colombo
>
>
>
>
>
>
>
>
> --
> Marco Colombo

--
Thomas Krgel
Linux Consultant
Mail: kaergel [at] b1-systems
B1 Systems GmbH
Osterfeldstrae 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Attachments: signature.asc (0.54 KB)


james.page at ubuntu

Jul 2, 2013, 6:01 AM

Post #18 of 23 (220 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

On 20/05/13 07:51, Heinonen, Johanna (NSN - FI/Espoo) wrote:
> Hi,
> I have installed grizzly with quantum and ovs-plugin. It seems that
> grizzly allocates the third address of each subnet for dhcp. (In folsom
> it was the second address). This means that the VMs will get addresses

This sound alot like
https://bugs.launchpad.net/ubuntu/+source/quantum/+bug/1189909; I'll
raise a task for dnsmasq as well.

Cheers

James

--
James Page
Ubuntu Core Developer
Debian Maintainer
james.page [at] ubuntu

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


chu.ducminh at gmail

Aug 2, 2013, 2:27 AM

Post #19 of 23 (96 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

Hi, i have the same problem when create -> terminate -> create instances.
This problem only occur when the new instances have the same IP as deleted
instances.

I check the dnsmasq's host file
/var/lib/quantum/dhcp/dbc59888-e2be-4b31-b579-0a4575159bb1/host,
sometimes it's not update.

I think this problem maybe not only related to Dnsmasq, it may related to
firewall rules (generated by Quantum) on compute-node too. Because i see
some dropped DHCP packet:
Aug 2 14:08:11 thor-compute-03 kernel: [95971.005423] IN=qbr23c67719-14
OUT=qbr23c67719-14 PHYSIN=qvb23c67719-14 PHYSOUT=tap23c67719-
14 MAC=ff:ff:ff:ff:ff:ff:fa:16:3e:34:72:05:08:00 SRC=0.0.0.0
DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 *PROTO=UDP
SPT=68 DPT=67* LEN=308
(DHCP Discovery packet?)
It dropped in chain quantum-openvswi-sg-fallback, then instance can't get
IP. Although in Dashboard i see instance got IP.

I tried many times, and got a strange case: duplicate IP in Dnsmasq's host
file:
fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
*fa:16:3e:78:b5:2f,10-2-1-10.openstacklocal,10.2.1.10*
fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
*fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*

My newest instance is *10.2.1.10*, and I can't ping it. In boot log of this
instance, i found:

cloudinitnonet waiting 120 seconds for a network device.
cloudinitnonet gave up waiting for a network device.
ciinfo: lo : 1 127.0.0.1 255.0.0.0 .
ciinfo: eth0 : 1 . . fa:16:3e:c7:ea:0c
route_info failed

Restart instance didn't make it work, but restart quantum-dhcp-agent on
Quantum-node make it work.
After restart, content of Dnsmasq's host file is:
fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
*fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*

I think it a serious problem, hope someone could fix it soon.. :)

Best Regards,


On Tue, Jul 2, 2013 at 8:01 PM, James Page <james.page [at] ubuntu> wrote:

> On 20/05/13 07:51, Heinonen, Johanna (NSN - FI/Espoo) wrote:
>
>> Hi,
>> I have installed grizzly with quantum and ovs-plugin. It seems that
>> grizzly allocates the third address of each subnet for dhcp. (In folsom
>> it was the second address). This means that the VMs will get addresses
>>
>
> This sound alot like https://bugs.launchpad.net/**
> ubuntu/+source/quantum/+bug/**1189909<https://bugs.launchpad.net/ubuntu/+source/quantum/+bug/1189909>;
> I'll raise a task for dnsmasq as well.
>
> Cheers
>
> James
>
> --
> James Page
> Ubuntu Core Developer
> Debian Maintainer
> james.page [at] ubuntu
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>


chu.ducminh at gmail

Aug 2, 2013, 2:45 AM

Post #20 of 23 (96 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

After i deleted 2 instances: 10.2.1.10 & 10.2.1.12
The Dnsmasq's hosts file is:
fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
*fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12* *<-- still exist,
problem?!*
fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9

BR,


On Fri, Aug 2, 2013 at 4:27 PM, Chu Duc Minh <chu.ducminh [at] gmail> wrote:

> Hi, i have the same problem when create -> terminate -> create instances.
> This problem only occur when the new instances have the same IP as deleted
> instances.
>
> I check the dnsmasq's host file
> /var/lib/quantum/dhcp/dbc59888-e2be-4b31-b579-0a4575159bb1/host,
> sometimes it's not update.
>
> I think this problem maybe not only related to Dnsmasq, it may related to
> firewall rules (generated by Quantum) on compute-node too. Because i see
> some dropped DHCP packet:
> Aug 2 14:08:11 thor-compute-03 kernel: [95971.005423] IN=qbr23c67719-14
> OUT=qbr23c67719-14 PHYSIN=qvb23c67719-14 PHYSOUT=tap23c67719-
> 14 MAC=ff:ff:ff:ff:ff:ff:fa:16:3e:34:72:05:08:00 SRC=0.0.0.0
> DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 *PROTO=UDP
> SPT=68 DPT=67* LEN=308
> (DHCP Discovery packet?)
> It dropped in chain quantum-openvswi-sg-fallback, then instance can't get
> IP. Although in Dashboard i see instance got IP.
>
> I tried many times, and got a strange case: duplicate IP in Dnsmasq's host
> file:
> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
> *fa:16:3e:78:b5:2f,10-2-1-10.openstacklocal,10.2.1.10*
> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
> fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
> *fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*
>
> My newest instance is *10.2.1.10*, and I can't ping it. In boot log of
> this instance, i found:
>
> cloudinitnonet waiting 120 seconds for a network device.
> cloudinitnonet gave up waiting for a network device.
> ciinfo: lo : 1 127.0.0.1 255.0.0.0 .
> ciinfo: eth0 : 1 . . fa:16:3e:c7:ea:0c
> route_info failed
>
> Restart instance didn't make it work, but restart quantum-dhcp-agent on
> Quantum-node make it work.
> After restart, content of Dnsmasq's host file is:
> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
> fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
> *fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*
>
> I think it a serious problem, hope someone could fix it soon.. :)
>
> Best Regards,
>
>
> On Tue, Jul 2, 2013 at 8:01 PM, James Page <james.page [at] ubuntu> wrote:
>
>> On 20/05/13 07:51, Heinonen, Johanna (NSN - FI/Espoo) wrote:
>>
>>> Hi,
>>> I have installed grizzly with quantum and ovs-plugin. It seems that
>>> grizzly allocates the third address of each subnet for dhcp. (In folsom
>>> it was the second address). This means that the VMs will get addresses
>>>
>>
>> This sound alot like https://bugs.launchpad.net/**
>> ubuntu/+source/quantum/+bug/**1189909<https://bugs.launchpad.net/ubuntu/+source/quantum/+bug/1189909>;
>> I'll raise a task for dnsmasq as well.
>>
>> Cheers
>>
>> James
>>
>> --
>> James Page
>> Ubuntu Core Developer
>> Debian Maintainer
>> james.page [at] ubuntu
>>
>>
>> ______________________________**_________________
>> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>>
>
>


thuleau at gmail

Aug 7, 2013, 7:46 AM

Post #21 of 23 (51 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

I think we have found (Sylvain and me) a problem that can explain this
trouble:

When the load is too heavy (update dnsmasq host file and send lease update)
on DHCP agent, the report state to Neutron server is delayed and the
Neutron sever considers that agent is down and doesn't sent the port
creation to the agent. So the dnsmasq host file isn't updated to serve that
IP port's.

Do you have this log in agent log file :
2013-08-07 13:21:46 WARNING [quantum.openstack.common.loopingcall] task
run outlasted interval by 2.375859 sec

You can increase the 'report_interval' flag on the agent and the
'agent_down_time' flag on the Neutron server side.
This problem should be corrected with this bp:
https://blueprints.launchpad.net/neutron/+spec/remove-dhcp-lease
Meanwhile, I think we should add log warning in the neutron server code to
prevent that it cannot notify any DHCP agent for a port creation. And
backport that on the Grizzly release.

What do you think ?

I had this comment on the bug
https://bugs.launchpad.net/neutron/+bug/1185916

douard.


On Fri, Aug 2, 2013 at 11:45 AM, Chu Duc Minh <chu.ducminh [at] gmail> wrote:

> After i deleted 2 instances: 10.2.1.10 & 10.2.1.12
> The Dnsmasq's hosts file is:
> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
> *fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12* *<-- still exist,
> problem?!*
>
> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
>
>
> BR,
>
>
> On Fri, Aug 2, 2013 at 4:27 PM, Chu Duc Minh <chu.ducminh [at] gmail>wrote:
>
>> Hi, i have the same problem when create -> terminate -> create instances.
>> This problem only occur when the new instances have the same IP as
>> deleted instances.
>>
>> I check the dnsmasq's host file
>> /var/lib/quantum/dhcp/dbc59888-e2be-4b31-b579-0a4575159bb1/host,
>> sometimes it's not update.
>>
>> I think this problem maybe not only related to Dnsmasq, it may related to
>> firewall rules (generated by Quantum) on compute-node too. Because i see
>> some dropped DHCP packet:
>> Aug 2 14:08:11 thor-compute-03 kernel: [95971.005423] IN=qbr23c67719-14
>> OUT=qbr23c67719-14 PHYSIN=qvb23c67719-14 PHYSOUT=tap23c67719-
>> 14 MAC=ff:ff:ff:ff:ff:ff:fa:16:3e:34:72:05:08:00 SRC=0.0.0.0
>> DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 *PROTO=UDP
>> SPT=68 DPT=67* LEN=308
>> (DHCP Discovery packet?)
>> It dropped in chain quantum-openvswi-sg-fallback, then instance can't get
>> IP. Although in Dashboard i see instance got IP.
>>
>> I tried many times, and got a strange case: duplicate IP in Dnsmasq's
>> host file:
>> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
>> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
>> *fa:16:3e:78:b5:2f,10-2-1-10.openstacklocal,10.2.1.10*
>> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
>> fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
>> *fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*
>>
>> My newest instance is *10.2.1.10*, and I can't ping it. In boot log of
>> this instance, i found:
>>
>> cloudinitnonet waiting 120 seconds for a network device.
>> cloudinitnonet gave up waiting for a network device.
>> ciinfo: lo : 1 127.0.0.1 255.0.0.0 .
>> ciinfo: eth0 : 1 . . fa:16:3e:c7:ea:0c
>> route_info failed
>>
>> Restart instance didn't make it work, but restart quantum-dhcp-agent on
>> Quantum-node make it work.
>> After restart, content of Dnsmasq's host file is:
>> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
>> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
>> fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
>> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
>> *fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*
>>
>> I think it a serious problem, hope someone could fix it soon.. :)
>>
>> Best Regards,
>>
>>
>> On Tue, Jul 2, 2013 at 8:01 PM, James Page <james.page [at] ubuntu> wrote:
>>
>>> On 20/05/13 07:51, Heinonen, Johanna (NSN - FI/Espoo) wrote:
>>>
>>>> Hi,
>>>> I have installed grizzly with quantum and ovs-plugin. It seems that
>>>> grizzly allocates the third address of each subnet for dhcp. (In folsom
>>>> it was the second address). This means that the VMs will get addresses
>>>>
>>>
>>> This sound alot like https://bugs.launchpad.net/**
>>> ubuntu/+source/quantum/+bug/**1189909<https://bugs.launchpad.net/ubuntu/+source/quantum/+bug/1189909>;
>>> I'll raise a task for dnsmasq as well.
>>>
>>> Cheers
>>>
>>> James
>>>
>>> --
>>> James Page
>>> Ubuntu Core Developer
>>> Debian Maintainer
>>> james.page [at] ubuntu
>>>
>>>
>>> ______________________________**_________________
>>> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>> Post to : openstack [at] lists
>>> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>>>
>>
>>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack [at] lists
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>


chu.ducminh at gmail

Aug 7, 2013, 10:52 PM

Post #22 of 23 (49 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

>
> Do you have this log in agent log file :
> 2013-08-07 13:21:46 WARNING [quantum.openstack.common.loopingcall] task
> run outlasted interval by 2.375859 sec
>
Yes, i have:
"WARNING [quantum.openstack.common.loopingcall] task run outlasted interval
by 4.738189 sec"

I set report_interval = 15 and agent_down_time = 30, then launch 50
instances simultaneously.
Now, every instances is ok, I can ping them all. But in Dashboard, I still
see a bug, some instanes have 2 IP addresses (screenshot attached) - and
ofcourse, with each instance I can only ping 1 IP address.

For example, with first instance in attached image, I check file Dnsmasq's
host, see 2 entries:
*fa:16:3e:7c:42:bb*,10-2-1-41.openstacklocal,10.2.1.41
fa:16:3e:0c:bc:4b,10-2-1-52.openstacklocal,10.2.1.52
Only can ping 10.2.1.52

I check Quantum DB, i saw that *fa:16:3e:7c:42:bb* still exist in 'ports'
table.
('6260622a6b324557bc9064698c8c03ed','*f3e79e1b-2236-4189-8516-fb18dc7e58a9*
','','dbc59888-e2be-4b31-b579-0a4575159bb1',*'fa:16:3e:7c:42:bb*
',1,'DOWN','8420f945-2d88-4204-8444-9c078491def0','compute:None')
Same result with quantum port-list:
| *f3e79e1b-2236-4189-8516-fb18dc7e58a9* | | fa:16:3e:7c:42:bb |
{"subnet_id": "4d238201-a8d5-4175-a9b4-c1d13efb5e2e", "ip_address":
"10.2.1.41"} |


Then, I check Nova DB, and found a record in *instance_info_caches* table:
| 2013-08-08 04:34:38 | 2013-08-08 04:38:19 | NULL | 2730 |
[.{"ovs_interfaceid": "43802d05-ee1f-401d-9d61-055444da8df4", "network":
{"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4,
"type": "fixed", "floating_ips": [], "address": "10.2.1.52"}], "version":
4, "meta": {"dhcp_server": "10.2.1.9"}, "dns": [], "routes": [], "cidr": "
10.2.1.0/24", "gateway": {"meta": {}, "version": 4, "type": "gateway",
"address": "10.2.1.1"}}], "meta": {"injected": false, "tenant_id":
"6260622a6b324557bc9064698c8c03ed"}, "id":
"dbc59888-e2be-4b31-b579-0a4575159bb1", "label": "net_minhcd_proj1"},
"devname": "tap43802d05-ee", "qbh_params": null, "meta": {}, "address":
"fa:16:3e:0c:bc:4b", "type": "ovs", "id":
"43802d05-ee1f-401d-9d61-055444da8df4", "qbg_params": null},
{"ovs_interfaceid": "*f3e79e1b-2236-4189-8516-fb18dc7e58a9*", "network":
{"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4,
"type": "fixed", "floating_ips": [], "address": "10.2.1.41"}], "version":
4, "meta": {"dhcp_server": "10.2.1.9"}, "dns": [], "routes": [], "cidr": "
10.2.1.0/24", "gateway": {"meta": {}, "version": 4, "type": "gateway",
"address": "10.2.1.1"}}], "meta": {"injected": false, "tenant_id":
"6260622a6b324557bc9064698c8c03ed"}, "id":
"dbc59888-e2be-4b31-b579-0a4575159bb1", "label": "net_minhcd_proj1"},
"devname": "tapf3e79e1b-22", "qbh_params": null, "meta": {}, "address":
"fa:16:3e:7c:42:bb", "type": "ovs", "id": "*
f3e79e1b-2236-4189-8516-fb18dc7e58a9*", "qbg_params": null}] |
8420f945-2d88-4204-8444-9c078491def0 | 0 |

In quantum-server.log:
2013-08-08 11:30:14 DEBUG [quantum.openstack.common.rpc.amqp] received
{u'_context_roles': [u'admin'], u'_context_read_deleted': u'no',
u'_context_tenant_id': None, u'args': {u'network_id':
u'dbc59888-e2be-4b31-b579-0a4575159bb1', u'lease_remaining': 0, u'host':
u'thor-quantum-01.localdomain', u'ip_address': u'10.2.1.41'},
u'_unique_id': u'49f419ee040d4d77822ecf696533e484', u'_context_is_admin':
True, u'version': u'1.0', u'_context_project_id': None,
u'_context_timestamp': u'2013-08-08 04:26:09.092921', u'_context_user_id':
None, u'method': u'update_lease_expiration'}
2013-08-08 11:30:16 DEBUG [quantum.db.dhcp_rpc_base] Updating lease
expiration for 10.2.1.41 on network dbc59888-e2be-4b31-b579-0a4575159bb1
from thor-quantum-01.localdomain.
2013-08-08 11:33:53 DEBUG [quantum.db.db_base_plugin_v2] Recycle
10.2.1.41
2013-08-08 11:33:53 DEBUG [quantum.db.db_base_plugin_v2] Recycle:
updated last 10.2.1.39-10.2.1.41
2013-08-08 11:33:53 DEBUG [quantum.db.db_base_plugin_v2] Delete
allocated IP 10.2.1.41
(dbc59888-e2be-4b31-b579-0a4575159bb1/4d238201-a8d5-4175-a9b4-c1d13efb5e2e)
2013-08-08 11:33:53 DEBUG [quantum.db.db_base_plugin_v2] Recycle: last
match for 10.2.1.39-10.2.1.41
2013-08-08 11:35:29 DEBUG [quantum.db.db_base_plugin_v2] Allocated IP -
10.2.1.41 from 10.2.1.41 to 10.2.1.42
2013-08-08 11:35:29 DEBUG [quantum.db.db_base_plugin_v2] Allocated IP
10.2.1.41
(dbc59888-e2be-4b31-b579-0a4575159bb1/4d238201-a8d5-4175-a9b4-c1d13efb5e2e/f3e79e1b-2236-4189-8516-fb18dc7e58a9)
(seem normal?)

And when i deleted all instances, some entries still exists in Dnsmasq's
host file --> can't ping on next launching.
Maybe I need to increase report_interval more, because I still see the
message "WARNING [quantum.openstack.common.loopingcall] task run outlasted
interval by X seconds" on high stressed test.

But the question is, how much is enough?
Could i fix this bug thoroughly? (apply patch? but need to rename
Quantum<->Neutron first)

Thank you very much!


On Wed, Aug 7, 2013 at 9:46 PM, douard Thuleau <thuleau [at] gmail> wrote:

> I think we have found (Sylvain and me) a problem that can explain this
> trouble:
>
> When the load is too heavy (update dnsmasq host file and send lease
> update) on DHCP agent, the report state to Neutron server is delayed and
> the Neutron sever considers that agent is down and doesn't sent the port
> creation to the agent. So the dnsmasq host file isn't updated to serve that
> IP port's.
>
> Do you have this log in agent log file :
> 2013-08-07 13:21:46 WARNING [quantum.openstack.common.loopingcall] task
> run outlasted interval by 2.375859 sec
>
> You can increase the 'report_interval' flag on the agent and the
> 'agent_down_time' flag on the Neutron server side.
> This problem should be corrected with this bp:
> https://blueprints.launchpad.net/neutron/+spec/remove-dhcp-lease
> Meanwhile, I think we should add log warning in the neutron server code to
> prevent that it cannot notify any DHCP agent for a port creation. And
> backport that on the Grizzly release.
>
> What do you think ?
>
> I had this comment on the bug
> https://bugs.launchpad.net/neutron/+bug/1185916
>
> douard.
>
>
> On Fri, Aug 2, 2013 at 11:45 AM, Chu Duc Minh <chu.ducminh [at] gmail>wrote:
>
>> After i deleted 2 instances: 10.2.1.10 & 10.2.1.12
>> The Dnsmasq's hosts file is:
>> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
>> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
>> *fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12* *<-- still exist,
>> problem?!*
>>
>> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
>>
>>
>> BR,
>>
>>
>> On Fri, Aug 2, 2013 at 4:27 PM, Chu Duc Minh <chu.ducminh [at] gmail>wrote:
>>
>>> Hi, i have the same problem when create -> terminate -> create instances.
>>> This problem only occur when the new instances have the same IP as
>>> deleted instances.
>>>
>>> I check the dnsmasq's host file
>>> /var/lib/quantum/dhcp/dbc59888-e2be-4b31-b579-0a4575159bb1/host,
>>> sometimes it's not update.
>>>
>>> I think this problem maybe not only related to Dnsmasq, it may related
>>> to firewall rules (generated by Quantum) on compute-node too. Because i see
>>> some dropped DHCP packet:
>>> Aug 2 14:08:11 thor-compute-03 kernel: [95971.005423] IN=qbr23c67719-14
>>> OUT=qbr23c67719-14 PHYSIN=qvb23c67719-14 PHYSOUT=tap23c67719-
>>> 14 MAC=ff:ff:ff:ff:ff:ff:fa:16:3e:34:72:05:08:00 SRC=0.0.0.0
>>> DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 *PROTO=UDP
>>> SPT=68 DPT=67* LEN=308
>>> (DHCP Discovery packet?)
>>> It dropped in chain quantum-openvswi-sg-fallback, then instance can't
>>> get IP. Although in Dashboard i see instance got IP.
>>>
>>> I tried many times, and got a strange case: duplicate IP in Dnsmasq's
>>> host file:
>>> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
>>> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
>>> *fa:16:3e:78:b5:2f,10-2-1-10.openstacklocal,10.2.1.10*
>>> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
>>> fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
>>> *fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*
>>>
>>> My newest instance is *10.2.1.10*, and I can't ping it. In boot log of
>>> this instance, i found:
>>>
>>> cloudinitnonet waiting 120 seconds for a network device.
>>> cloudinitnonet gave up waiting for a network device.
>>> ciinfo: lo : 1 127.0.0.1 255.0.0.0 .
>>> ciinfo: eth0 : 1 . . fa:16:3e:c7:ea:0c
>>> route_info failed
>>>
>>> Restart instance didn't make it work, but restart quantum-dhcp-agent on
>>> Quantum-node make it work.
>>> After restart, content of Dnsmasq's host file is:
>>> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
>>> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
>>> fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
>>> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
>>> *fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*
>>>
>>> I think it a serious problem, hope someone could fix it soon.. :)
>>>
>>> Best Regards,
>>>
>>>
>>> On Tue, Jul 2, 2013 at 8:01 PM, James Page <james.page [at] ubuntu>wrote:
>>>
>>>> On 20/05/13 07:51, Heinonen, Johanna (NSN - FI/Espoo) wrote:
>>>>
>>>>> Hi,
>>>>> I have installed grizzly with quantum and ovs-plugin. It seems that
>>>>> grizzly allocates the third address of each subnet for dhcp. (In folsom
>>>>> it was the second address). This means that the VMs will get addresses
>>>>>
>>>>
>>>> This sound alot like https://bugs.launchpad.net/**
>>>> ubuntu/+source/quantum/+bug/**1189909<https://bugs.launchpad.net/ubuntu/+source/quantum/+bug/1189909>;
>>>> I'll raise a task for dnsmasq as well.
>>>>
>>>> Cheers
>>>>
>>>> James
>>>>
>>>> --
>>>> James Page
>>>> Ubuntu Core Developer
>>>> Debian Maintainer
>>>> james.page [at] ubuntu
>>>>
>>>>
>>>> ______________________________**_________________
>>>> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>>> Post to : openstack [at] lists
>>>> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>>> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack [at] lists
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
Attachments: Grizzly_DHCP_error1.png (49.7 KB)


thuleau at gmail

Aug 8, 2013, 11:30 PM

Post #23 of 23 (44 views)
Permalink
Re: DHCP problem in grizzly [In reply to]

I cannot reproduce this problem.
Do you changed the DHCP lease time ?

douard.


On Thu, Aug 8, 2013 at 7:52 AM, Chu Duc Minh <chu.ducminh [at] gmail> wrote:

> Do you have this log in agent log file :
>> 2013-08-07 13:21:46 WARNING [quantum.openstack.common.loopingcall] task
>> run outlasted interval by 2.375859 sec
>>
> Yes, i have:
> "WARNING [quantum.openstack.common.loopingcall] task run outlasted
> interval by 4.738189 sec"
>
> I set report_interval = 15 and agent_down_time = 30, then launch 50
> instances simultaneously.
> Now, every instances is ok, I can ping them all. But in Dashboard, I still
> see a bug, some instanes have 2 IP addresses (screenshot attached) - and
> ofcourse, with each instance I can only ping 1 IP address.
>
> For example, with first instance in attached image, I check file Dnsmasq's
> host, see 2 entries:
> *fa:16:3e:7c:42:bb*,10-2-1-41.openstacklocal,10.2.1.41
> fa:16:3e:0c:bc:4b,10-2-1-52.openstacklocal,10.2.1.52
> Only can ping 10.2.1.52
>
> I check Quantum DB, i saw that *fa:16:3e:7c:42:bb* still exist in 'ports'
> table.
> ('6260622a6b324557bc9064698c8c03ed','*f3e79e1b-2236-4189-8516-fb18dc7e58a9
> *','','dbc59888-e2be-4b31-b579-0a4575159bb1',*'fa:16:3e:7c:42:bb*
> ',1,'DOWN','8420f945-2d88-4204-8444-9c078491def0','compute:None')
> Same result with quantum port-list:
> | *f3e79e1b-2236-4189-8516-fb18dc7e58a9* | | fa:16:3e:7c:42:bb |
> {"subnet_id": "4d238201-a8d5-4175-a9b4-c1d13efb5e2e", "ip_address":
> "10.2.1.41"} |
>
>
> Then, I check Nova DB, and found a record in *instance_info_caches* table:
> | 2013-08-08 04:34:38 | 2013-08-08 04:38:19 | NULL | 2730 |
> [.{"ovs_interfaceid": "43802d05-ee1f-401d-9d61-055444da8df4", "network":
> {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4,
> "type": "fixed", "floating_ips": [], "address": "10.2.1.52"}], "version":
> 4, "meta": {"dhcp_server": "10.2.1.9"}, "dns": [], "routes": [], "cidr": "
> 10.2.1.0/24", "gateway": {"meta": {}, "version": 4, "type": "gateway",
> "address": "10.2.1.1"}}], "meta": {"injected": false, "tenant_id":
> "6260622a6b324557bc9064698c8c03ed"}, "id":
> "dbc59888-e2be-4b31-b579-0a4575159bb1", "label": "net_minhcd_proj1"},
> "devname": "tap43802d05-ee", "qbh_params": null, "meta": {}, "address":
> "fa:16:3e:0c:bc:4b", "type": "ovs", "id":
> "43802d05-ee1f-401d-9d61-055444da8df4", "qbg_params": null},
> {"ovs_interfaceid": "*f3e79e1b-2236-4189-8516-fb18dc7e58a9*", "network":
> {"bridge": "br-int", "subnets": [{"ips": [{"meta": {}, "version": 4,
> "type": "fixed", "floating_ips": [], "address": "10.2.1.41"}], "version":
> 4, "meta": {"dhcp_server": "10.2.1.9"}, "dns": [], "routes": [], "cidr": "
> 10.2.1.0/24", "gateway": {"meta": {}, "version": 4, "type": "gateway",
> "address": "10.2.1.1"}}], "meta": {"injected": false, "tenant_id":
> "6260622a6b324557bc9064698c8c03ed"}, "id":
> "dbc59888-e2be-4b31-b579-0a4575159bb1", "label": "net_minhcd_proj1"},
> "devname": "tapf3e79e1b-22", "qbh_params": null, "meta": {}, "address":
> "fa:16:3e:7c:42:bb", "type": "ovs", "id": "*
> f3e79e1b-2236-4189-8516-fb18dc7e58a9*", "qbg_params": null}] |
> 8420f945-2d88-4204-8444-9c078491def0 | 0 |
>
> In quantum-server.log:
> 2013-08-08 11:30:14 DEBUG [quantum.openstack.common.rpc.amqp] received
> {u'_context_roles': [u'admin'], u'_context_read_deleted': u'no',
> u'_context_tenant_id': None, u'args': {u'network_id':
> u'dbc59888-e2be-4b31-b579-0a4575159bb1', u'lease_remaining': 0, u'host':
> u'thor-quantum-01.localdomain', u'ip_address': u'10.2.1.41'},
> u'_unique_id': u'49f419ee040d4d77822ecf696533e484', u'_context_is_admin':
> True, u'version': u'1.0', u'_context_project_id': None,
> u'_context_timestamp': u'2013-08-08 04:26:09.092921', u'_context_user_id':
> None, u'method': u'update_lease_expiration'}
> 2013-08-08 11:30:16 DEBUG [quantum.db.dhcp_rpc_base] Updating lease
> expiration for 10.2.1.41 on network dbc59888-e2be-4b31-b579-0a4575159bb1
> from thor-quantum-01.localdomain.
> 2013-08-08 11:33:53 DEBUG [quantum.db.db_base_plugin_v2] Recycle
> 10.2.1.41
> 2013-08-08 11:33:53 DEBUG [quantum.db.db_base_plugin_v2] Recycle:
> updated last 10.2.1.39-10.2.1.41
> 2013-08-08 11:33:53 DEBUG [quantum.db.db_base_plugin_v2] Delete
> allocated IP 10.2.1.41
> (dbc59888-e2be-4b31-b579-0a4575159bb1/4d238201-a8d5-4175-a9b4-c1d13efb5e2e)
> 2013-08-08 11:33:53 DEBUG [quantum.db.db_base_plugin_v2] Recycle: last
> match for 10.2.1.39-10.2.1.41
> 2013-08-08 11:35:29 DEBUG [quantum.db.db_base_plugin_v2] Allocated IP -
> 10.2.1.41 from 10.2.1.41 to 10.2.1.42
> 2013-08-08 11:35:29 DEBUG [quantum.db.db_base_plugin_v2] Allocated IP
> 10.2.1.41
> (dbc59888-e2be-4b31-b579-0a4575159bb1/4d238201-a8d5-4175-a9b4-c1d13efb5e2e/f3e79e1b-2236-4189-8516-fb18dc7e58a9)
> (seem normal?)
>
> And when i deleted all instances, some entries still exists in Dnsmasq's
> host file --> can't ping on next launching.
> Maybe I need to increase report_interval more, because I still see the
> message "WARNING [quantum.openstack.common.loopingcall] task run outlasted
> interval by X seconds" on high stressed test.
>
> But the question is, how much is enough?
> Could i fix this bug thoroughly? (apply patch? but need to rename
> Quantum<->Neutron first)
>
> Thank you very much!
>
>
> On Wed, Aug 7, 2013 at 9:46 PM, douard Thuleau <thuleau [at] gmail> wrote:
>
>> I think we have found (Sylvain and me) a problem that can explain this
>> trouble:
>>
>> When the load is too heavy (update dnsmasq host file and send lease
>> update) on DHCP agent, the report state to Neutron server is delayed and
>> the Neutron sever considers that agent is down and doesn't sent the port
>> creation to the agent. So the dnsmasq host file isn't updated to serve that
>> IP port's.
>>
>> Do you have this log in agent log file :
>> 2013-08-07 13:21:46 WARNING [quantum.openstack.common.loopingcall] task
>> run outlasted interval by 2.375859 sec
>>
>> You can increase the 'report_interval' flag on the agent and the
>> 'agent_down_time' flag on the Neutron server side.
>> This problem should be corrected with this bp:
>> https://blueprints.launchpad.net/neutron/+spec/remove-dhcp-lease
>> Meanwhile, I think we should add log warning in the neutron server code
>> to prevent that it cannot notify any DHCP agent for a port creation. And
>> backport that on the Grizzly release.
>>
>> What do you think ?
>>
>> I had this comment on the bug
>> https://bugs.launchpad.net/neutron/+bug/1185916
>>
>> douard.
>>
>>
>> On Fri, Aug 2, 2013 at 11:45 AM, Chu Duc Minh <chu.ducminh [at] gmail>wrote:
>>
>>> After i deleted 2 instances: 10.2.1.10 & 10.2.1.12
>>> The Dnsmasq's hosts file is:
>>> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
>>> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
>>> *fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12* *<-- still
>>> exist, problem?!*
>>>
>>> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
>>>
>>>
>>> BR,
>>>
>>>
>>> On Fri, Aug 2, 2013 at 4:27 PM, Chu Duc Minh <chu.ducminh [at] gmail>wrote:
>>>
>>>> Hi, i have the same problem when create -> terminate -> create
>>>> instances.
>>>> This problem only occur when the new instances have the same IP as
>>>> deleted instances.
>>>>
>>>> I check the dnsmasq's host file
>>>> /var/lib/quantum/dhcp/dbc59888-e2be-4b31-b579-0a4575159bb1/host,
>>>> sometimes it's not update.
>>>>
>>>> I think this problem maybe not only related to Dnsmasq, it may related
>>>> to firewall rules (generated by Quantum) on compute-node too. Because i see
>>>> some dropped DHCP packet:
>>>> Aug 2 14:08:11 thor-compute-03 kernel: [95971.005423]
>>>> IN=qbr23c67719-14 OUT=qbr23c67719-14 PHYSIN=qvb23c67719-14
>>>> PHYSOUT=tap23c67719-
>>>> 14 MAC=ff:ff:ff:ff:ff:ff:fa:16:3e:34:72:05:08:00 SRC=0.0.0.0
>>>> DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 *PROTO=UDP
>>>> SPT=68 DPT=67* LEN=308
>>>> (DHCP Discovery packet?)
>>>> It dropped in chain quantum-openvswi-sg-fallback, then instance can't
>>>> get IP. Although in Dashboard i see instance got IP.
>>>>
>>>> I tried many times, and got a strange case: duplicate IP in Dnsmasq's
>>>> host file:
>>>> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
>>>> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
>>>> *fa:16:3e:78:b5:2f,10-2-1-10.openstacklocal,10.2.1.10*
>>>> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
>>>> fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
>>>> *fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*
>>>>
>>>> My newest instance is *10.2.1.10*, and I can't ping it. In boot log of
>>>> this instance, i found:
>>>>
>>>> cloudinitnonet waiting 120 seconds for a network device.
>>>> cloudinitnonet gave up waiting for a network device.
>>>> ciinfo: lo : 1 127.0.0.1 255.0.0.0 .
>>>> ciinfo: eth0 : 1 . . fa:16:3e:c7:ea:0c
>>>> route_info failed
>>>>
>>>> Restart instance didn't make it work, but restart quantum-dhcp-agent on
>>>> Quantum-node make it work.
>>>> After restart, content of Dnsmasq's host file is:
>>>> fa:16:3e:01:d1:70,10-2-1-1.openstacklocal,10.2.1.1
>>>> fa:16:3e:71:6a:4e,10-2-1-11.openstacklocal,10.2.1.11
>>>> fa:16:3e:cf:0f:c1,10-2-1-12.openstacklocal,10.2.1.12
>>>> fa:16:3e:35:a1:72,10-2-1-9.openstacklocal,10.2.1.9
>>>> *fa:16:3e:c7:ea:0c,10-2-1-10.openstacklocal,10.2.1.10*
>>>>
>>>> I think it a serious problem, hope someone could fix it soon.. :)
>>>>
>>>> Best Regards,
>>>>
>>>>
>>>> On Tue, Jul 2, 2013 at 8:01 PM, James Page <james.page [at] ubuntu>wrote:
>>>>
>>>>> On 20/05/13 07:51, Heinonen, Johanna (NSN - FI/Espoo) wrote:
>>>>>
>>>>>> Hi,
>>>>>> I have installed grizzly with quantum and ovs-plugin. It seems that
>>>>>> grizzly allocates the third address of each subnet for dhcp. (In
>>>>>> folsom
>>>>>> it was the second address). This means that the VMs will get addresses
>>>>>>
>>>>>
>>>>> This sound alot like https://bugs.launchpad.net/**
>>>>> ubuntu/+source/quantum/+bug/**1189909<https://bugs.launchpad.net/ubuntu/+source/quantum/+bug/1189909>;
>>>>> I'll raise a task for dnsmasq as well.
>>>>>
>>>>> Cheers
>>>>>
>>>>> James
>>>>>
>>>>> --
>>>>> James Page
>>>>> Ubuntu Core Developer
>>>>> Debian Maintainer
>>>>> james.page [at] ubuntu
>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>>>> Post to : openstack [at] lists
>>>>> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
>>>>> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openstack [at] lists
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>>
>>
>

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.