dhcp server gives out the temporary IP instead of the permanent IP displayed in MAAS web UI for the node

[Darryl Weaver]

We regularly see on various MAAS deployments, some on the Orange Box, some in data centres a problem with the MAAS dhcp server giving out the wrong IP to the node when booting over PXE.

When you acquire and start a node, the node will be allocated a permanent IP and this is displayed in the node details in the MAAS UI. However, when the node boots with PXE it obtains a temporary IP for the node's HW address that is still listed in the DHCP leases file. Hence it boots with a different IP than the one displayed in the MAAS UI and the only way to find out the actual IP address being used is to check the dhcpd.leases file for multiple entries and try each IP listed.

This is a transient problem and is not repeatable reliably, but it happens often enough and is blocking reliable demos.

It could be related to recent enlistment as the temporary enlistment lease is still current in the leases file.
However, it also seems to happen on an Orange Box that hasn't had any new machines enlisted for a long time, so may not be related.

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=====================================================-===================================================-============-===============================================================================
ii maas 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS server all-in-one metapackage
ii maas-cli 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS command line API tool
ii maas-cluster-controller 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS server cluster controller
ii maas-common 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS server common files
ii maas-dhcp 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS DHCP server
ii maas-dns 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS DNS server
ii maas-proxy 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS Caching Proxy
ii maas-region-controller 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS server complete region controller
ii maas-region-controller-min 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS Server minimum region controller
ii python-django-maas 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS server Django web framework
ii python-maas-client 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS python API client
ii python-maas-provisioningserver 1.7.1+bzr3341-0ubuntu1~trusty1 all MAAS server provisioning libraries

[Sean Feole (sfeole)]

We were able to reproduce this issue today, while installing Windows on customer hardware via MaaS.

+1 to the description in the bug, the allocated IP address displayed in the maas UI did not match what the actual IPv4 assigned to windows.

"When you acquire and start a node, the node will be allocated a permanent IP and this is displayed in the node details in the MAAS UI. However, when the node boots with PXE it obtains a temporary IP for the node's HW address that is still listed in the DHCP leases file. Hence it boots with a different IP than the one displayed in the MAAS UI and the only way to find out the actual IP address being used is to check the dhcpd.leases file for multiple entries and try each IP listed."

After grepping syslog for dhcp address we could see that a new ip4v address was giving to the hw.

sfeole@bates:~$ sudo tail -f /var/log/syslog | grep f4:52:14:d6:70:98
Feb 19 15:32:04 bates dhcpd: DHCPDISCOVER from f4:52:14:d6:70:98 via em1
Feb 19 15:32:05 bates dhcpd: DHCPOFFER on 10.229.55.67 to f4:52:14:d6:70:98 (WIN-LVM8LRUP40F) via em1
Feb 19 15:32:05 bates dhcpd: DHCPREQUEST for 10.229.55.67 (10.229.0.101) from f4:52:14:d6:70:98 (WIN-LVM8LRUP40F) via em1
Feb 19 15:32:05 bates dhcpd: DHCPACK on 10.229.55.67 to f4:52:14:d6:70:98 (WIN-LVM8LRUP40F) via em1

[Gavin Panella (allenap)]

MAAS's network related code has changed enormously since this bug was filed, and continues to do so. I doubt we will fix this bug in 1.7.x, and it's unlikely that this bug manifests in recent releases (or, if it does, the cause is probably unrelated).