Possible speed up for DHCP serving - dhcp-authoritative & no-ping

Bug #1629316 reported by Nell Jerram
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
networking-calico
New
Undecided
Unassigned

Bug Description

Moved here from https://github.com/projectcalico/felix/issues/43:

neiljerram commented on 11 Nov 2014

Felix Schüren writes at http://lists.projectcalico.org/pipermail/calico/2014-November/000051.html:

In order to speed up DHCP replies for new VMs (and thus VM boot time), I
think adding
--dhcp-authoritative
--no-ping
to dnsmasq should be safe & sane.

--dhcp-authoritative
Should be set when dnsmasq is definitely the only DHCP server on a
network. For DHCPv4, it changes the behaviour from strict RFC
compliance so that DHCP requests on unknown leases from unknown hosts
are not ignored. This allows new hosts to get a lease without a tedious
timeout under all circumstances. It also allows dnsmasq to rebuild
its lease database without each client needing to reacquire a lease, if
the database is lost. For DHCPv6 it sets the priority in replies to 255
(the maximum) instead of 0 (the minimum).

--no-ping
(IPv4 only) By default, the DHCP server will attempt to ensure that an
address in not in use before allocating it to a host. It does this by
sending an ICMP echo request (aka "ping") to the address in question. If
it gets a reply, then the address must already be in use, and another is
tried. This flag disables this check. Use with caution.
@neiljerram neiljerram added the question label on 11 Nov 2014
@neiljerram neiljerram self-assigned this on 11 Nov 2014
@localpref
localpref commented on 12 Nov 2014

Btw, I think this might be an upstream thing and not even calico-related?

Lukasa commented on 12 Nov 2014

It's definitely upstream right now. What's interesting to think about is whether it will remain upstream forever or whether we'll subsume the function.

neiljerram commented on 28 Nov 2014

@Lukasa My impression is that dnsmasq is good at retaining features, once it has them, so I doubt these options will disappear.

@localpref I wonder if there's any relationship between your suggestions here and another piece of dnsmasq investigation that I'm currently working on, which is described at http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q4/008997.html ? I'll look at your suggestions once I have my next test rig up and running. By the way if you happen to know already about the multiple instances behaviour, I'd appreciate hearing your input on that.

Lukasa commented on 28 Nov 2014

@neiljerram Sorry, I meant 'upstream' in the sense of 'in openstack', not in the sense of 'in dnsmasq'.

nbartos commented on 9 Feb 2015

I agree, this sounds like a good idea.

fasaxc commented on 20 May 2015

Since DHCP has been a bottleneck, should we look into this again?

fasaxc commented on 23 Jul 2015

I believe --dhcp-authoritative is incorrect for Calico. When we have multiple networks configured, we currently bridge together the DHCP agents (or, more precisely, tell them to behave as if they are bridged). This means that they are not authoritative.

neiljerram commented just now

Note: For deployments using the Calico DHCP agent (as opposed to the reference Neutron one), @fasaxc's last comment doesn't apply, and so --dhcp-authoritative would be correct.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.