group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1707999@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package ipxe - 1.0.0+git-20150424.a25a16d-
1ubuntu1.2

---------------
ipxe (1.0.0+git-20150424.a25a16d-1ubuntu1.2) xenial-proposed; urgency=medium

  * debian/patches/handle-dhcp-nack.patch: Handle DHCP NAK and send a
    re-discover. (LP: #1707999)

 -- Andres Rodriguez <andreserl@xxxxxxxxxx>  Mon, 20 Nov 2017 13:13:41
-0500

** Changed in: ipxe (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1707999

Title:
  [SRU] iPXE doesn't handle NAK requests when multiple DHCP server's
  offer

Status in MAAS:
  Invalid
Status in MAAS 2.2 series:
  Invalid
Status in ipxe package in Ubuntu:
  Fix Released
Status in ipxe source package in Xenial:
  Fix Released
Status in ipxe source package in Zesty:
  Fix Committed
Status in ipxe source package in Artful:
  Fix Released
Status in ipxe source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  When there are multiple DHCP servers on the network, iPXE doesn't handle NAK's for the DHCP servers. This causes iPXE to get blocked without attempting to re-discover, hence, never obtaining an IP address.

  For example, in a MAAS HA environment with a DHCP master/slave
  configuration, the machine fails to PXE boot because at a certain
  point, the DHCP server is not fully in sync, which causes iPXE to get
  a NAK request. This prevents the machine from PXE booting.

  [Test case]
  The easiest way:
  1. Install MAAS with two rack controllers
  2. Configure HA
  3. PXE boot KVM's.

  [Regression Potential]
  Minimal. This only ensures that iPXE attempts to re-discover the network when it receives a NACK.

  [Original bug report]
  A VM failed to PXE boot after receiving multiple DHCP offers.

  You can see this here on a log from the secondary controller:
  http://paste.ubuntu.com/25221939/

  The node is offered both 10.245.208.201 and 10.245.208.120, tries to
  get 10.245.208.120, and is refused.

  One strange thing is that it seems like the DHCP server on both the primary controller and the secondary controller are responding.  The primary controller's log doesn't have the offer for 10.245.208.120 - only the offer for 10.245.208.201:
  http://paste.ubuntu.com/25221952/

  This is in an HA setup: region API's are at 10.245.208.30,
  10.245.208.31 and 10.245.208.32. We're using hacluster to load
  balance, and a VIP in front at 10.245.208.33. There are rack
  controllers on 10.245.208.30 and 10.245.208.31. For the untagged vlan
  this VM is trying to boot from, 10.245.208.30 is set as the primary
  controller, and 10.245.208.31 is set as the secondary.

  Primary postgres is on 10.245.208.30, it's being replicated to backup
  postgres on 10.245.208.31. It has a VIP at 10.245.208.34.

  We don't hit this everytime - on this deployment only one machine out
  of about 30 hit this.

  We've also seen this on single node MAAS setups - non HA.  So, it's
  not an HA specific issue.

  I've attached logs from the maas servers.

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