After migrating all of our DHCP helpers to Infoblox in the past few weeks, one of the annoyances we had was having to override the bootfile name in the DHCP lease for new hosts that were being built. Since all new server hardware purchases have UEFI enabled by default, in order to PXE boot from your TFTP server, you have to pass it a different bootfile (bootx64.efi) than you would if you were using a traditional BIOS-based system. Some of our admins were either manually overriding the host record in Infoblox to use bootx64.efi as its bootfile (instead of pxelinux.0 if you’re using syslinux), or, even worse, putting the machine into legacy BIOS mode in order to kickstart the box. What I needed was a way for Infoblox to automatically present the needed boot file without any extra steps in the provisioning process.
Redhat has a doc that outlines a tidy method to set up a conditional in your DHCP server if you’re using dhcpd. However, with Infoblox it’s a little more difficult. While Infoblox still uses dhcpd under the covers, you can’t touch it directly (although you can view dhcpd.conf if you poke around), so setting up this conditional is a little trickier.
Infoblox has a feature called IPv4 filters that will do pretty much this same thing. The tricky bit is determining the format for the filter. Infoblox doesn’t currently (as of NIOS 7.2) allow for setting up a filter on DHCP option 93, or “arch” which is how a UEFI client would advertise itself. However, it does support filtering on option 60, which is the vendor class identifier. The tricky bit is figuring out the vendor class identifier you want to filter on, since Redhat’s docs specify the “arch” option in dhcpd.conf.
This post on the syslinux forums gave me the bit I needed. The entire “vendor-class-identifier” option is passed to the server during a DHCPDISCOVER request, which is what Infoblox can filter on. This took me a bit to figure out, since I set up the filter in Infoblox and it didn’t work right away. This led me to believe that the format of the vendor-class-identifier string used in this syslinux forum post didn’t match what my client was using. Fortunately, wireshark set me straight, so running a packet capture on the DHCP interface on the proper Infoblox member showed me exactly what was in the request.
As it turns out, I should have believed what Spike had posted all along. The initial trouble was on my side – I set up the substring to look at offset 15, length 4, of “PXEClient:Arch:00007:UNDI:003016”. Since the first character offset is zero, not one, this returned “0000” and not “0007” like I had set up in my filter. The fix was to change the length to 5 characters and match on “00007” instead.
In a nutshell:
– In Infoblox, within DHCP Data Management, create a new IPv4 DHCP Option Filter
– Give it a name, and make it global if you so choose (otherwise you’ll need to apply it per network later)
– Create a matching rule so that it should match subtring offset 15, length 5 of the vendor-client-identifier filter to ‘00007’
– Assign the DHCP option you want this filter to return on a match. In this example, you want the boot file to be “bootx64.efi” (which is under advanced options, BOOTP)
– Save and close, then restart your services
Here are some screenshots of what the end result should look like.
