NUC/vPro using DHCP-allocated IP will fail after install provides static IP to host

[Christian Reis]

When using the Intel NUCs or any system which shares the MAC address between the BMC and the host (AIUI vPro does), there is an inherent race in MAAS that will make the BMC IP change upon installation. Here's how it works:

  - When powered up for the first time, BMC acquires IP from MAAS DHCP dynamic range
  - When the machine comes up to enlist the same IP is provided for the host
  - We enter that IP address and the MAC in the AMT configuration for the host; at this point the BMC is reachable
  - Upon installation, an IP from the static range is granted to the host, and a static host map entry is created
  - When the BMC comes back to renew its lease, it will now receive the static IP
  - As that IP differs from the IP we configured in the AMT configuration, the host goes unreachable

I realize using DHCP in a situation like this is daft, but users are likely to at least try it at first (and perhaps thus they can find this bug). And perhaps there is a way to address this by somehow matching on the client information the BMC passes to the DHCP server and providing it the original IP address granted dynamically.

[Raphaël Badin (rvb)]

Marking this as high because, as you said, although it is a bad idea to use DHCP to configure the BMCs' IP, the failure mode here is particularly horrible.
I had a look at the kind of DHCP request that AMT does and it doesn't seem to contain anything obvious that we could use to identify the DHCP request (and have isc-dhcpd treat it differently from the request that comes from the host): http://paste.ubuntu.com/9676611/. There is no Vendor class identifier (option 60) or anything useful in the request.

[Christian Reis (kiko)]

That's a shame, as I was hoping there was something we could use to distinguish. I take it the client hostname isn't consistently provided in all the other DHCP requests, so we could identify AMT via exclusion?

If this is unworkable, we should have a way of indicating that AMT is set up to use DHCP so we can change the AMT IP when the host IP changes; do you think that could be a solution?

[Michael Davies (mrda)]

Have you looked at setting "ignore-client-uids true;"? I think this might work around the issue - the Client UIDs are different, which might be causing the problem.

[Christian Reis (kiko)]

Well, AFAIK we set that option already, but I believe that option isn't what we are looking for, as the issue in this case is that the MAC address for both the AMT "virtual NIC" and the NIC itself are one and the same.

In fact, if the client UIDs were different we might have a way to address this bug. Does anyone have a NUC and is able to look at the two DHCP requests, perhaps in wireshark, to see if there is something we could match on?

[Andres Rodriguez (andreserl)]

It seems that this is no longer an issue. We have several users and orange boxes that use a NUC and this issues hasn't come up again. I'm marking this as invalid, but if you still see this issue, please re-open the bug report or file a new one.