This
document describes common scenarios for implementing DHCP in relation
to PXE boot with particular focus on Configuration Manager.
Assumptions and audience
Audience must familiar with basic IP networking principles.
The background
In
order for a client to perform a PXE boot, there must be a DHCP service
available, this is not required to be a Microsoft DHCP service. Any DHCP
server is good.
The following diagram shows a typical network setup
In
this case the client and the server is on the same network, which is
the simplest setup you will come across, normally the setup will be more
advanced, but in order to explain the basics, we will start with this
simple model.
The DHCP Process
During a normal DHCP process the following happens:
- The client sends out a DHCP broadcast on the network
- The broadcast is picked up by the server
- The server replies with a broadcast containing the MAC address of the client and a suggested IP address
- The client replies back to the server, indicating that it will use the provided address
The PXE Boot process
When
a client initiates a PXE boot (often by pressing a key of selecting a
particular boot option during start-up) the process changes a little
bit:
- The client sends out a DHCP broadcast on the network, with a flag stating that it needs to PXE boot
- The broadcast is picked up by the server
The server replies with a broadcast containing the MAC address of the client and a suggested IP address
- If the server configuration has any information on how to PXE boot, this information is included in the reply to the client.
- The client replies back to the server, indicating that it will use the provided address
- The
client then contacts the PXE boot server (is this case the same server)
and requests the bootfile specified in the boot information sent back
from the server
- The file is loaded and launched.
PXE Configuration on the DHCP server
Traditionally
the PXE configuration has been made on the DHCP by setting either
server or scope options, typically Option 66 and 67 are used, option 66
specifies the server to contact, 67 is the name of the file to request.
Another
method of providing the boot information is to have a service listen
for the DHCP request coming from the client and then send an additional
reply back to the client. This is commonly known as dynamic PXE boot.
PXE booting from Configuration Manager Distribution Point
Configuration Manager provides dynamic PXE boot using the WDS service (available in Windows Server)
A typical simple setup could look like the following
The PXE server is installed on the SCCM DP (the WDS service).
Now the boot process is as follows:
- The client sends out a DHCP broadcast on the network, with a flag stating that it needs to PXE boot
- The broadcast is picked up by the server
- The server replies with a broadcast containing the MAC address of the client and a suggested IP address
- The WDS service also replies back to the client with information on how to PXE boot
- The client replies back to the server, indicating that it will use the provided address
- The
client then contacts the PXE boot server (is this case the SCCM DP
server) and requests the bootfile specified in the boot information sent
back from the server
- The file is loaded and launched.
This
method has the great advantage that it is dynamic and therefore it can
send back information based on the type of client requesting a PXE boot,
whereas a setup using options configured on the DHCP cannot.
Why is this important in this case?
A
PXE boot on a BIOS based system is using one method, whereas UEFI based
systems are using another, therefore the PXE server must be able to
dynamically provide different information according to the client type.
Also note: For UEFI PXE boot to work correctly with SCCM DPs the underlying OS must be Windows Server 2012 R2 or later.
Additional scenarios
Given
that a typical network setup today is a lot more complex than the
examples given above I will go through some of these to illustrate how
to successfully implement PXE boot in such environments
Multiple subnets
The
common method of setting up networks today is to have multiple subnets
connected by routers or switches providing router-like functionality.
A typical setup could look like the following:
In this setup the DHCP server is in one subnet, the SCCM DP in another and the client is connected to a third network.
Given
that DHCP traffic is based primarily on broadcasts, and broadcasts are
normally contained within a subnet (in order to control spamming of the
network). As such DHCP and also PXE will not work in a setup like this.
The way to fix this is to implement IP Helpers.
IP
Helpers is a function implemented in routers to allow broadcast traffic
to pass between networks in a controlled manor. It is important to note
that IP Helpers typically forwards a specific type of traffic to a
specific target (IP address).
In the given example an IP Helper
must forward DHPC requests from subnet 10.10.30.0 to 10.10.10.10 to
allow the client to obtain an IP address from the DHCP server.
For
PXE boot requests to be answered correctly by the SCCM DP server, an
additional IP Helper must also forward the request to 10.10.20.10.
The resulting setup looks like this
Note
that in the case where the DHCP Server and the SCCM DP is on the same
subnet, there must still be two IP Helpers implemented as IP Helpers are
directed to a specific IP Address.
Special cases: 1E Nomad with PXE Everywhere
In
some scenarios special features like 1E Nomad and PXE Everywhere may be
implemented, and that may change the way you should implement DHCP and
PXE boot.
There are two typical setups for this approach.
Central DHCP Server
A typical setup for Nomad with PXE Everywhere would be like to following:
The
DHCP Server is placed in a central location, and will provide DHCP
addresses to clients, using an IP Helper. However, the PXE functionality
is provided by local clients running the PXE Everywhere component. In
this case there must not be an IP Helper that forwards the DHCP request
to the SCCM DP, as we intend for PXE boot requests to be serviced
locally. If the IP Helper was setup the client would attempt to contact
the SCCM DP to PXE boot.
So but not having the additional IP
Helper the DHCP request is forwarded only to the DHCP which provides an
IP Address to the client, and the PXE Everywhere service will reply to
the same DHCP request to provide PXE boot information.
For this to
work successfully the DHCP Server should not provide any PXE
information either dynamically or using static option as that will cause
confusion for the client trying to PXE boot.
Local DHCP Server
In
some Nomad scenarios there may not be a central DHCP server to provide
IP addresses to clients. The can be done by the local router, maybe a
SOHO (Small Office Home Office) router. These routers are typically not
able to provide any PXE boot information, which in this case is a good
thing. The client will follow the normal process to obtain an IP address
and the PXE Everywhere service will reply to the DHCP with the required
PXE Boot information.
The following shows a setup for this case:
Conclusion
- Never use DHCP options, BIOS and UEFI based devices require different replies from PXE Server
- In routed networks use IP Helpers to both the DHCP server and the PXE server
- Do not install DHCP and PXE service on the same server unless it REALLY makes sense
- It is safe to rely on local DHCP functionality but may require an IP Helper pointing to the PXE Server if this is not local
- Windows Server 2012 R2 or later is required for UEFI boot to work correctly
Page source:
http://blog.coretech.dk/rja/dhcp-guide/
