Revision as of 01:22, 12 October 2015

General

To make network booting for several different client platforms possible you'd have to offer adequate boot images for those clients. To be able to distinguish between varying platforms the DHCP server needs to utilize the information sent by the clients. According to RFC 4578 "the following pre-boot architecture types have been requested" (by the RFC):

           Type   Architecture Name
           ----   -----------------
             0    Intel x86PC
             1    NEC/PC98
             2    EFI Itanium
             3    DEC Alpha
             4    Arc x86
             5    Intel Lean Client
             6    EFI IA32
             7    EFI BC (EFI Byte Code)
             8    EFI Xscale
             9    EFI x86-64

Using Linux DHCP

According to this post there are (at least) three different ways to configure ISC DHCP server that way: http://www.syslinux.org/archives/2014-October/022683.html

Edit /etc/dhcp/dhcpd.conf and add the 'authoritative' option to your subnet definition and the following classes anywhere in the config:

subnet ... {
    authoritative;
    ...
}
...

class "pxeclient" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";

    if substring (option vendor-class-identifier, 15, 5) = "00000" {
        # BIOS client 
        filename "undionly.kpxe";
    }
    elsif substring (option vendor-class-identifier, 15, 5) = "00006" {
        # EFI client 32 bit
        filename   "ipxe32.efi";
    }
    else
        # default to EFI 64 bit
        filename   "ipxe.efi";
    }
}

Example 1

Here's a complete configuration example where TFTP and DNS is on the same Server. No router is defined in this configuration but can easily be added by changing X.X.X.X and un-commenting the line.

option space PXE;
option PXE.mtftp-ip    code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16; # RFC4578

use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
next-server 192.168.1.1;


subnet 192.168.1.0 netmask 255.255.255.0 {
        authoritative;
        option subnet-mask              255.255.255.0;
        range dynamic-bootp 192.168.1.10 192.168.1.254;
        default-lease-time 21600;
        max-lease-time 43200;
        option domain-name-servers      192.168.1.1;
    #option routers      x.x.x.x;
 
    class "UEFI-32-1" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
    filename "i386-efi/ipxe.efi";
    }

    class "UEFI-32-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
     filename "i386-efi/ipxe.efi";
    }

    class "UEFI-64-1" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
     filename "ipxe.efi";
    }

    class "UEFI-64-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
    filename "ipxe.efi";
    }

    class "UEFI-64-3" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
     filename "ipxe.efi";
    }

    class "Legacy" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
    filename "undionly.kkpxe";
    }

    }

Example 2

Here is another complete example setup for a 10.0.0.0/24 network where 10.0.0.3 is the TFTP server, 10.0.0.1 is the router, and 10.0.0.1 is the DNS Server. The range for this configuration is set to 10.0.0.20 through 10.0.0.254.

option space PXE;
option PXE.mtftp-ip    code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16; # RFC4578

use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
next-server 10.0.0.3;


subnet 10.0.0.0 netmask 255.255.255.0 {
        option subnet-mask              255.255.255.0;
        range dynamic-bootp 10.0.0.20 10.0.0.254;
        default-lease-time 21600;
        max-lease-time 43200;
        option domain-name-servers      10.0.0.1;
        option routers      10.0.0.1;
 
    class "UEFI-32-1" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
    filename "i386-efi/ipxe.efi";
    }

    class "UEFI-32-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
     filename "i386-efi/ipxe.efi";
    }

    class "UEFI-64-1" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
     filename "ipxe.efi";
    }

    class "UEFI-64-2" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
    filename "ipxe.efi";
    }

    class "UEFI-64-3" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
     filename "ipxe.efi";
    }

    class "Legacy" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
    filename "undionly.kkpxe";
    }

    }

When you have Mac OS clients as well you might want to check out this: FOG_on_a_MAC#architecture

Restart the DHCP service and you are good to go!

Building custom DHCP Classes for co-existence with FOG

It's possible and easy to configure ISC-DHCP to support network booting with FOG and IP Phone configurations at the same time on the same network. You would simply use Wireshark to examine the DHCP Request broadcast from the IP phone and examine it's option 060. This will be a string. You'd then create a class as shown above just for that model of phone and supply it with the correct next-server (option 066) and if necessary a file name as well.

In the above classes for PXEClient architures, you see 0, 20, this means to start the string comparison at character zero and end 20 characters after the starting place. You may begin at 15 or even 20, but the next digit defines how much further to compare.

For example, Legacy clients send this in their DHCP Request option 060:

PXEClient:Arch:00000

To match this string with a class, any of these will work:

match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";

match if substring(option vendor-class-identifier, 15, 5) = "00000";

match if substring(option vendor-class-identifier, 19, 1) = "0";

Obviously the less you use to compare, the more chances you'll have of DHCP handing out incorrect options to the various devices on your network due to mismatches.

For example, This line would (incorrectly) match this IP Phone's option 060:

match if substring(option vendor-class-identifier, 19, 1) = "0";

"Cisco VOIP phone 000562"

It would also match this string (correctly):

"PXEClient:Arch:00000"

Because the 20th character is a zero, this IP phone using the above configuration would be matched and given the defined options instead of the correct options. I made up this example just to show the possibility of a class mismatch if the matching is limited too much.

ISC-DCHP static IP address and other things

Here are a few examples of exclusively defined options based on MAC addresses. These would be placed at the very end of your dhcpd.conf file. You may use MAC matching to hand out static IP address or specific boot options.


#Just set a static IP based on MAC address. The "Optiplex380" doesn't do anything, it just helps you keep track of what the entries are.
host Optiplex380 {
                        hardware ethernet F0:4D:A2:22:6E:2C;
                        fixed-address 10.0.0.6;
                }


#Define a static IP and a specific boot file for this computer.
host FOG {
                        hardware ethernet 00:13:72:AB:FD:7C;
                        fixed-address 10.0.0.3;
                        filename "My_Custom_Boot_File.kkpxe";
                }


#Make this access point use Google's DNS.
host TP-Link-Access-point {
                        hardware ethernet C4:E9:84:7D:F0:2E;
                        option domain-name-servers 8.8.8.8;
                }

Using ProxyDHCP (dnsmasq)

There are powerful matching rules in dnsmasq's configuration syntax. Here is an example of how this could be used to distingush between BIOS and UEFI. Note: This will only work in non proxy mode!!

dhcp-match=set:bios,60,PXEClient:Arch:00000
dhcp-option-force=tag:bios,66,x.x.x.x           # TFTP/FOG server ip
dhcp-option-force=tag:bios,67,"undionly.kpxe"

dhcp-match=set:efi32,60,PXEClient:Arch:00006
dhcp-option-force=tag:efi32,66,x.x.x.x          # TFTP/FOG server ip
dhcp-option-force=tag:efi32,67,"i386-efi/ipxe.efi"

dhcp-match=set:efibc,60,PXEClient:Arch:00007
dhcp-option-force=tag:efibc,66,x.x.x.x          # TFTP/FOG server ip
dhcp-option-force=tag:efibc,67,"ipxe.efi"

dhcp-match=set:efi64,60,PXEClient:Arch:00009
dhcp-option-force=tag:efi64,66,x.x.x.x          # TFTP/FOG server ip
dhcp-option-force=tag:efi64,67,"ipxe.efi"

Using Windows Server 2012 (r1 and later) DHCP Policy

The below method assumes that your normal Scope options 066 and 067 are set for BIOS boot files. The below DHCP policy will only apply to UEFI based network booting. Regular BIOS based network booting will still use the default scope options set in the scope.