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 <andres...@ubuntu.com> 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
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
