On 02/02/2015 05:47 PM, Brian Haley wrote:
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?
If by "dnsmasq is restarted" you mean "dnsmasq is restarted and therefore
has its lease database deleted", then the RFC says that if a server gets a
renewal for an unknown lease, it should return DHCPNAK. That's what dnsmasq
does _unless_ --dhcp-authoritative is set, when instead it quietly
re-creates the lease.
Yes, your assumption is correct, as --leasefile-ro is used it knows of no
current leases, and by default get a DHCPNAK.
dhcp-authoritative gives permission to dnsmasq to violate the RFC in a way
which is useful in certain circumstances.
Thanks, it does seem to do what I want with my initial testing.
Hi Simon,
Replying to my old thread since using --dhcp-authoritative seems to have
introduced an issue where a DHCP client can get a NAK when using multiple
dnsmasq servers on the same subnet (they both have the same host information, >1
running just to get HA).
Short story is that both dnsmasq's return the same lease info, but when the
client ACKs (sending to broadcast), one agent ACKs and the other agent NAKs.
The tcpdump shows this better than I'm describing:
https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html
Does that seem like normal operation to you? Does this second dnsmasq assume
this response is from a rogue server and NAKs since it didn't send out the offer?
Thanks,
-Brian
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
