Difference between revisions of "BIOS and UEFI Co-Existence"
m (→Building custom DHCP Classes for co-existence with FOG) |
m (→Using Linux DHCP: left brace missing) |
||
(24 intermediate revisions by 2 users not shown) | |||
Line 40: | Line 40: | ||
filename "ipxe32.efi"; | filename "ipxe32.efi"; | ||
} | } | ||
− | else | + | else { |
# default to EFI 64 bit | # default to EFI 64 bit | ||
filename "ipxe.efi"; | filename "ipxe.efi"; | ||
Line 65: | Line 65: | ||
subnet 192.168.1.0 netmask 255.255.255.0 { | subnet 192.168.1.0 netmask 255.255.255.0 { | ||
− | + | 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 | + | #option routers x.x.x.x; |
class "UEFI-32-1" { | class "UEFI-32-1" { | ||
Line 102: | Line 102: | ||
} | } | ||
− | + | } | |
</pre> | </pre> | ||
Line 127: | Line 127: | ||
subnet 10.0.0.0 netmask 255.255.255.0 { | 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" { | class "UEFI-32-1" { | ||
Line 164: | Line 164: | ||
} | } | ||
− | + | } | |
</pre> | </pre> | ||
Line 171: | Line 171: | ||
Restart the DHCP service and you are good to go! | Restart the DHCP service and you are good to go! | ||
− | |||
− | |||
== ISC-DCHP static IP address and other things == | == ISC-DCHP static IP address and other things == | ||
Line 180: | Line 178: | ||
<pre> | <pre> | ||
− | #Just set a static IP based on MAC address. The "Optiplex380" | + | #Just set a static IP based on MAC address. The "Optiplex380" is what is suggested as a hostname |
+ | # To my knowledge, only Linux respects this and offers it to the user for confirmation. | ||
+ | |||
host Optiplex380 { | host Optiplex380 { | ||
hardware ethernet F0:4D:A2:22:6E:2C; | hardware ethernet F0:4D:A2:22:6E:2C; | ||
Line 188: | Line 188: | ||
#Define a static IP and a specific boot file for this computer. | #Define a static IP and a specific boot file for this computer. | ||
+ | |||
host FOG { | host FOG { | ||
hardware ethernet 00:13:72:AB:FD:7C; | hardware ethernet 00:13:72:AB:FD:7C; | ||
Line 196: | Line 197: | ||
#Make this access point use Google's DNS. | #Make this access point use Google's DNS. | ||
+ | |||
host TP-Link-Access-point { | host TP-Link-Access-point { | ||
hardware ethernet C4:E9:84:7D:F0:2E; | hardware ethernet C4:E9:84:7D:F0:2E; | ||
Line 203: | Line 205: | ||
</pre> | </pre> | ||
+ | = Using ProxyDHCP (dnsmasq) = | ||
− | + | Related article: [[ProxyDHCP with 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 | + | 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 NOT work in proxy mode!!''' |
dhcp-match=set:bios,60,PXEClient:Arch:00000 | dhcp-match=set:bios,60,PXEClient:Arch:00000 | ||
− | dhcp- | + | dhcp-boot=tag:bios,undionly.kpxe,x.x.x.x,x.x.x.x # x.x.x.x = TFTP/FOG server IP |
− | |||
dhcp-match=set:efi32,60,PXEClient:Arch:00006 | dhcp-match=set:efi32,60,PXEClient:Arch:00006 | ||
− | dhcp- | + | dhcp-boot=tag:efi32,i386-efi/ipxe.efi,x.x.x.x,x.x.x.x # x.x.x.x = TFTP/FOG server IP |
− | |||
dhcp-match=set:efibc,60,PXEClient:Arch:00007 | dhcp-match=set:efibc,60,PXEClient:Arch:00007 | ||
− | dhcp- | + | dhcp-boot=tag:efibc,ipxe.efi,x.x.x.x,x.x.x.x # x.x.x.x = TFTP/FOG server IP |
− | |||
dhcp-match=set:efi64,60,PXEClient:Arch:00009 | dhcp-match=set:efi64,60,PXEClient:Arch:00009 | ||
− | dhcp- | + | dhcp-boot=tag:efi64,ipxe.efi,x.x.x.x,x.x.x.x # x.x.x.x = TFTP/FOG server IP |
− | |||
− | = Using Windows Server 2012 ( | + | = Using Windows Server 2012 (R1 and later) DHCP Policy = |
− | The below method assumes that your normal Scope options 066 and 067 are | + | The below method assumes that your normal Scope options 066 and 067 are already setup for BIOS based network booting (without these already set, the below steps will not result in success). 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. |
You may substitute whatever Vendor Class Identifier you need in the ASCII field on step 3. | You may substitute whatever Vendor Class Identifier you need in the ASCII field on step 3. | ||
Line 245: | Line 244: | ||
Here, The display name and description aren't really important but should describe what this does. | Here, The display name and description aren't really important but should describe what this does. | ||
− | What's important is the "ASCII" field. In this field, you would type this: | + | What's important is the "ASCII" field. In this field, you would type this, exactly, because it's case sensitive: |
<pre>PXEClient:Arch:00007</pre> | <pre>PXEClient:Arch:00007</pre> | ||
As you type this in, the ID and Binary fields will auto-update. When done, click Ok, ok, ok to finish this part of the procedure. | As you type this in, the ID and Binary fields will auto-update. When done, click Ok, ok, ok to finish this part of the procedure. | ||
+ | |||
+ | |||
+ | <font color="red">'''NOTE:'''</font> | ||
+ | There are many other UEFI architectures besides just "PXEClient:Arch:00007". | ||
+ | |||
+ | "PXEClient:Arch:00002" and "PXEClient:Arch:00006" both should get "i386-efi/ipxe.efi" as their option 067 boot file. | ||
+ | |||
+ | "PXEClient:Arch:00008", "PXEClient:Arch:00009", and "PXEClient:Arch:00007" should get "ipxe.efi" as their option 067 boot file. | ||
+ | |||
+ | "PXEClient:Arch:00007:UNDI:003016" should get "ipxe7156.efi" this file is specific to the Surface Pro 4. | ||
+ | |||
+ | In order to support these other architectures, just re-run through the Server 2012 steps for each one, Set the matching (step 3) and the boot file for each accordingly, and change the names to reflect what they are. | ||
+ | |||
[[File:Step 3.png]] | [[File:Step 3.png]] | ||
Line 334: | Line 346: | ||
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. | 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 | + | For example, This line would (incorrectly) match the below IP Phone's option 060: |
− | match if substring(option vendor-class-identifier, 19, 1) = "<font color="red">'''0''' | + | match if substring(option vendor-class-identifier, 19, 1) = "<font color="red">'''0'''</font>"; |
"Cisco VOIP phone 00<font color="red">'''0'''</font>562" | "Cisco VOIP phone 00<font color="red">'''0'''</font>562" |
Latest revision as of 10:25, 8 February 2020
Contents
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
There are different files that come with FOG that are pre-configured to work with these various architecture types. They are located in the /tftpboot directory usually. Here is more information on them: Filename Information
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; authoritative; subnet 192.168.1.0 netmask 255.255.255.0 { 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; authoritative; 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!
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" is what is suggested as a hostname # To my knowledge, only Linux respects this and offers it to the user for confirmation. 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)
Related article: ProxyDHCP with 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 NOT work in proxy mode!!
dhcp-match=set:bios,60,PXEClient:Arch:00000 dhcp-boot=tag:bios,undionly.kpxe,x.x.x.x,x.x.x.x # x.x.x.x = TFTP/FOG server IP dhcp-match=set:efi32,60,PXEClient:Arch:00006 dhcp-boot=tag:efi32,i386-efi/ipxe.efi,x.x.x.x,x.x.x.x # x.x.x.x = TFTP/FOG server IP dhcp-match=set:efibc,60,PXEClient:Arch:00007 dhcp-boot=tag:efibc,ipxe.efi,x.x.x.x,x.x.x.x # x.x.x.x = TFTP/FOG server IP dhcp-match=set:efi64,60,PXEClient:Arch:00009 dhcp-boot=tag:efi64,ipxe.efi,x.x.x.x,x.x.x.x # x.x.x.x = TFTP/FOG server IP
Using Windows Server 2012 (R1 and later) DHCP Policy
The below method assumes that your normal Scope options 066 and 067 are already setup for BIOS based network booting (without these already set, the below steps will not result in success). 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.
You may substitute whatever Vendor Class Identifier you need in the ASCII field on step 3.
Step 1
Right click IPv4, and pick "Define vendor class".
Step 2
Step 3
Here, The display name and description aren't really important but should describe what this does.
What's important is the "ASCII" field. In this field, you would type this, exactly, because it's case sensitive:
PXEClient:Arch:00007
As you type this in, the ID and Binary fields will auto-update. When done, click Ok, ok, ok to finish this part of the procedure.
NOTE:
There are many other UEFI architectures besides just "PXEClient:Arch:00007".
"PXEClient:Arch:00002" and "PXEClient:Arch:00006" both should get "i386-efi/ipxe.efi" as their option 067 boot file.
"PXEClient:Arch:00008", "PXEClient:Arch:00009", and "PXEClient:Arch:00007" should get "ipxe.efi" as their option 067 boot file.
"PXEClient:Arch:00007:UNDI:003016" should get "ipxe7156.efi" this file is specific to the Surface Pro 4.
In order to support these other architectures, just re-run through the Server 2012 steps for each one, Set the matching (step 3) and the boot file for each accordingly, and change the names to reflect what they are.
Step 4
Underneath IPv4 -> Scope -> Policies, right click on "Policies" and choose "New Policy..."
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Using Windows Server 2008 (and earlier) using DHCP Vendor Predefined options
This has been attempted unsuccessfully. The setup for Server 2008 is very similar to Windows Server 2012. You would create a Vendor Class and use the same vendor identifiers as used in Server 2012 and ISC-DHCP above, then you would set vendor predefined options for that class. The understanding is that you hard-code options 066 and 067 into your custom Vendor Class, and then can configure them after they are created for the class, and then later enable them on your server options or scope options.
However - Nobody in the FOG Community has succeeded with this as of yet. If you have it working, please let us know in the forums.
Here are some pictures of the unsuccessful steps taken, perhaps they can help out.
Right click to create the vendor class. Setup the class with the targeted vendor class identifier. Setup pre-defined options for the new class. Select the correct class in the drop down list and click add. Setup an option 66 and 67. After the options are created for the class, you can set their values in the Predefined options and values window. Enable these two options under the advanced tab of either scope options or server options.
Using OS X DHCP
Steps Here
Please list OS X steps here.'
Building custom DHCP Classes for co-existence with FOG
It's possible and easy to configure ISC-DHCP and Windows Server 2012 to support network booting with FOG and other devices (like IP Phones or Apple products) configurations at the same time on the same network. You would simply use Wireshark to examine the DHCP Request broadcast from the device and examine it's option 060. This will be a string. You'd then create a Vendor Class for that device and supply it with the correct option, in windows 066 and 067, in ISC-DHCP next-server and filename.
In the ISC-DHCP examples for IPXEClient 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 the below 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:
"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.
In Windows Server DHCP, you cannot match like you can in ISC-DHCP, however you can define a string value of your liking when you setup a Vendor Class.
Relevant Resources
Articles related to ISC-DHCP