yahoo-eng-team team mailing list archive

[Brian Haley <1764481@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

We have seen issues downstream where calling dhcp_release didn't cause
the lease to be removed from the leases files used by dnsmasq.  There
are a couple of scenarios where this could happen:

1. The packet is simply lost, as it is UDP, even though it's being looped-back
2. dnsmasq is reloading, so there is noone to receive it when it arrives

For that reason we should make this more robust.  A couple of possible
solutions are:

1. Send the release more than once in succession.  It's probably OK to just send some small number of packets for each lease we want to release, it would easily increase the odds that one makes it through.
2. Check the leases file to make sure dnsmasq processed the release, and re-send for those addresses that were missed.  This method is slightly more complicated, but it should also increase the odds, and should do it with fewer packets being generated.

Each option has some overhead, but since the option is not releasing the
lease, it's worth it.

I have proposed option #2 already at
https://review.openstack.org/#/c/560703/ but wanted to make sure to get
feedback on other proposals that might also solve the issue.

** Affects: neutron
     Importance: Medium
     Assignee: Brian Haley (brian-haley)
         Status: Confirmed


** Tags: l3-ipam-dhcp

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1764481

Title:
  Sometimes dhcp_releasepackets don't reach dnsmasq

Status in neutron:
  Confirmed

Bug description:
  We have seen issues downstream where calling dhcp_release didn't cause
  the lease to be removed from the leases files used by dnsmasq.  There
  are a couple of scenarios where this could happen:

  1. The packet is simply lost, as it is UDP, even though it's being looped-back
  2. dnsmasq is reloading, so there is noone to receive it when it arrives

  For that reason we should make this more robust.  A couple of possible
  solutions are:

  1. Send the release more than once in succession.  It's probably OK to just send some small number of packets for each lease we want to release, it would easily increase the odds that one makes it through.
  2. Check the leases file to make sure dnsmasq processed the release, and re-send for those addresses that were missed.  This method is slightly more complicated, but it should also increase the odds, and should do it with fewer packets being generated.

  Each option has some overhead, but since the option is not releasing
  the lease, it's worth it.

  I have proposed option #2 already at
  https://review.openstack.org/#/c/560703/ but wanted to make sure to
  get feedback on other proposals that might also solve the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1764481/+subscriptions