-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/02/2015 03:30 PM, Simon Kelley wrote:
>
> On 02/02/15 19:50, Brian Haley wrote:
>> Hi,
>
>> There have been a number of people chasing an issue in Openstack where
>> dnsmasq was sending DHCPNAK's after it was restarted since it's being
>> started with --leasefile-ro (https://launchpad.net/bugs/1345947).
>
> I guess the first question is why you're giving yourself these problems in
> the first place? If you allow dnsmasq to have a lease file, or keep a lease
> database otherwise, then you'll have solved the source of the problem.
I don't have the complete changelog or discussion on why it was changed (lost
during project re-name), but can take a guess:
1) Neutron didn't want to store this info in it's own DB since it's updated
too often by too many processes
2) You can migrate where the DHCP server lives, or restart it, so without #1
there's no point seemingly in keeping such info, as the "host" file
contains the things we need to know about
>> The first solution was to create a script that could be called to
>> re-populate the database inside dnsmasq based on the current contents of
>> the "hosts" file that had been created
>> (https://review.openstack.org/#/c/108272/).
>
>
>> But then today someone else found the --dhcp-authoritative option
>> (https://review.openstack.org/#/c/152080/) that seems to be an even
>> easier solution. Since when Openstack is managing the DHCP service it
>> *is* the authoritative server, this seems like the correct fix. Does
>> anyone see any problem with this approach even when there are multiple
>> dnsmasq processes being run (for HA), since both are under control of the
>> same DHCP authority?
>
>
> It will probably be fine. The client first unicasts to the DHCP server, and
> --dhcp-authoritative means that the server will re-create the lost lease,
> rather then erroring. The problem is if the client broadcasts a renewal. In
> that case _both_ instances would reply. Exactly what happens in that case
> I'm not quite clear, I guess it would depend on the client. Maybe worth an
> experiment.
In this HA case with >1 dnsmasq both will already respond to broadcast
anyways, and it seems to work today - the first response is chosen.
The one thing I'm curious about is if dnsmasq is restarted while a VM holds a
lease, how will it respond? As someone else has pointed-out to me - isc-dhcp
will respond with a DHCPNAK in that case, and wondered why there would be a
difference with dnsmasq. Different interpretation of an RFC?
I'll test it anyways.
- -Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUz/grAAoJEIYQqpVulyUowr4H/2mKbwlpEfy+HtWsCRzKULUE
R4Uj5wRRDitur0wFX1ZKBfg10+B/9cLNwB9NLRdC/ZjEzfLiqt3tFoxQmTnTNeRF
m83m2OnP7HOHYBtyENThiRBxZUhz8AVns6wbHatuU4lLM3OjhQfp8+10gGOejoLm
maXs8WE+uh7LzVSy+Sa7zVvszF9KwzG/oyUdccCecG9iOtzsWFOjWSGMXjXGwIMw
XKTCSuDe5cwFmHiEdBn+p+5FvWNNddowQdBGvo4lJnh8Z/Uu8XNnBsAqlXFRRt40
h0ysI0nlr+EKh6tPqU1HT3KQCXa6wCGa1B0lq6jIHIEcbkwQhtHwTq2/YLXn1H8=
=BkGO
-----END PGP SIGNATURE-----
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
