Help needed with PXE booting

Hi Experts,

We are in the process of setting up a PXE boot in our environment and currently creating an implementation plan. This is what I have understood so far (I have a fair bit of understanding of PXE)

A typical TPMFOSD architecture is composed of the following nodes:

i) a DHCP server that works as a PXE client

ii) Tivoli Provisioning Manager for OS Deployment server that can be installed on the same machine as the DHCP or on another machine. This server acts as the PXE server
iii) A Database (MS Access Type) also embedded into the installation - Bare Metal server needs a DB to store information like Client Inventory (for automatic driver injection based on PCI discovery from BIOS) and Deployment Objects (images, drivers, packages, WinPE…).
iv) A WebUI installed on the TPMFOSD server for administration purposes

The network boot sequence goes through the following steps:

i) Remote Computer Boot up either using a startup event or manually
ii) Network Boot: Press F12 to instruct the computer to boot on the network
iii) IP address discovery: The client broadcasts a DHCP request for an IP address. Any DHCP server that knows the target (that is, recognizes its hardware address) or which has a pool of freely distributable dynamic addresses, sends an IP address. The client takes the first answer and confirms it to the server. In addition to the IP address, the server gives some other network parameters to the target and information about the boot procedure to follow.

iv) OS deployment server discovery: In the case of PXE remote-boot, the client machine then proceeds to the discovery of the OS deployment server.

The OS deployment server/PXE Boot Server is responsible for delivering a network boot program to the client.The client responds to the first OS deployment server, which replies and downloads a NBP (Network Boot Program) When the PXE boot server is contacted, it provides:

  • complete file path to the Network Bootstrap Program (NBP)
  • PXE Boot Server type

The NBP is is transferred via TFTP and loaded into RAM and NBP is executed.

**This file detects the hardware architecture on the machine and this information is later used at the time of boot image download typically from an administrator defined location. (Which location?)

The client machine now downloads the Boot image, bootmgr.exe and BCD store. BootMGR and BCD store are used to initialize the WINPE environment. Boot image downloaded here would be dependent on the result of the architecture detection done earlier by the NBP file.

OS booting: When instructed by the OS configuration, the deployment engine removes itself from memory. The computer starts the operating system as if the target is booting from the hard disk.

Considerations: Use of IP helpers

If the DHCP and TPMOFSD are on different subnets, we can configure the router to use IP helpers.

I would like to know if there are any other considerations for setting up the PXE server, Any design best practices? What settings need to be done on the TPMFOSD server/ PXE server and most importantly which is the default boot file location which is returned after architecture detection and downloaded by the client. Can this be specified by the administrator?

Folks, please help me here with your inputs if you have already set this up in your environment and feel free to correct me if my understanding is incorrect!

Hi,

We have, mainly, general purposes environments only so they are not based on IP Helpers. However we can say that several customers are using them in their environments. To note, however, that each network has its own peculiarities and settings that needs to be configured carefully.
Inside our documentation it is important to provide attention to the options 60 and 43 for the DHCP server. Below I’ve reported a free documentation excerpt.

To note that configuring your DHCP infrastructure to support PXE servers is usually limited to adding option 60 depending on where the PXE server is located.
In order to support PXE clients on a network, the DHCP server is usually configured in one of the following three modes:

  1. Option 60 not set, Option 43 not set
  2. Option 60 set to ‘PXEClient’, Option 43 not set
  3. Option 60 set to ‘PXEClient’, Option 43 set

----When option 60 nor option 43 is set, PXE clients will have no clue where the PXE server is, and they will therefore wait until a PXE server contacts them. In this mode, the PXE server must listen to DHCP discovery packets sent by PXE clients and answer at the same time as the DHCP server does. This mode of operation is called DHCPProxy. Communication between client, DHCP, and Tivoli Provisioning Manager for OS Deployment server in this case has the following steps:

  1. The PXE enabled NIC on the client machine broadcasts the DHCP request to the network.
  2. The DHCP server recognizes the request and replies to the client. Since option 60 is not set, the client waits to be contacted by Tivoli Provisioning Manager for OS Deployment server.
  3. At the same time the server recognizes the DHCP request and sends the PXE parameters to the client.
  4. The client contacts Tivoli Provisioning Manager for OS Deployment server using the address received by the Tivoli Provisioning Manager for OS Deployment server. It initiates TFTP file transfer to download the Tivoli Provisioning Manager for OS Deployment client.
  5. The Tivoli Provisioning Manager for OS Deployment client is downloaded to client machine using TFTP.

It is obvious that this mode of operation can only be used when Tivoli Provisioning Manager for OS Deployment server is able to listen to the client’s DHCP broadcasts. If the server is in a different VLAN (virtual LAN) separated by a firewall and so on and can’t hear the client’s broadcasts, you will have to use option 43 and option 60 as described as follows.

----When option 60 is set to ‘PXEClient’, it means that the DHCP server knows where the PXE server is. If option 43 is not set, the PXE server is on the same computer as the DHCP server (same IP address). Communication between the client, the DHCP, and Tivoli Provisioning Manager for OS Deployment
server in this case has the following steps:

  1. The PXE enabled NIC on the client machine broadcasts DHCP request to network.
  2. The DHCP server recognizes the request and replies to the client. Option 60 is set to PXEClient. Since option 43 is not set, the Tivoli Provisioning Manager for OS Deployment server must be on the same IP as the DHCP server.
  3. The client contacts the Tivoli Provisioning Manager for OS Deployment server using the DHCP server address. It initiates TFTP file transfer to download the Tivoli Provisioning Manager for OS Deployment client.
  4. The Tivoli Provisioning Manager for OS Deployment client is downloaded to the client machine using TFTP.

----If option 43 is set, PXE clients must decode option 43 to know how to reach the PXE server. In most situations, option 43 does not need to be set up, because the PXE server will either listen to the DHCP discovery packets (DHCPProxy) or be on the same computer as the DHCP server. However, if the PXE server is on a separate subnet (it cannot listen to DHCP discovery packets) or if there are several PXE servers on the same subnet, option 43 is the only viable solution to instruct PXE clients on what to do.

Communication between the client, the DHCP, and the Tivoli Provisioning Manager for OS Deployment server in this case has the following steps:

  1. The PXE enabled NIC on the client machine broadcasts the DHCP request to the network.
  2. The DHCP server recognizes the request and replies to the client. Option 60 is set to PXEClient. Option 43 is set as well, telling the client where to look for the Tivoli Provisioning Manager for OS Deployment server.
  3. The client contacts the Tivoli Provisioning Manager for OS Deployment server using the address specified in option 43. It initiates TFTP file transfer to download the Tivoli Provisioning Manager for OS Deployment client.
  4. The Tivoli Provisioning Manager for OS Deployment client is downloaded to the client machine using TFTP. Option 43 is a binary buffer, containing a list of sub-options. Sub-options are packed in the binary buffer in no specific order. Most sub-options are optional. An exhaustive list of sub-options can be found in the PXE specifications.

Please review and verify the DHCP server to use the options 60 and 43 properly


Thanks
Gianluca

1 Like

Thanks for your response Gianluca… However, what still remains unanswered is how can we configure the architecture specific boot file location. Is there a default directory? Can we specify the settings somewhere?

The TPMfOSD manages internally every file involved at PXE boot. So, if I have correctly understood your question, I can say that there isn’t any specific boot file location to configure.
Only DHCP options have to be configured (just to remember that some UEFI targets are not able to correctly process option 43. For those targets it is necessary to set option 66 and 67 too).

Hi,

Thanks for getting back. As far as my understanding goes the tpmfosd server could have the bootfiles located at no specific location but at an administrator chosen place and there could be several copies. When you say TPMfOSD manages all files internally i am really interested to understand, once the architecture detection of the client is done how does it determine from which location to return the architecture specific boot file.

Any further inputs, anyone? Has none implemented this in their environment?

Hello, Gianluca is out of office.
Anyway, the boot file that is downloaded can be pxelinux (for machines configured to boot in BIOS mode) or a proprietary UEFI program (for machines configured to boot in UEFI mode). In both cases, the boot program is embedded in the Bare Metal server and is downloaded automatically. This should have nothing to do with your network configuration or DHCP options.

Thanks
Alessandro

Hi,

I had installed OSD server in bigfix relay machine, DHCP server was an another machine, all the configuration was done, but if I run a client with network boot mode, I get an error like "PXE55 proxyDHCP services did not reply to request on port 4011"
is there any solution on this?

Thanks,
Nagarajan,

Can you share your DHCP options?

Hi,
DHCP server and OSD server are not running on same host, like DHCP IP=172.16.10.10 and OSD IP=172.16.5.31

Regards,
Nagaraj.

Get the DHCP Configuration Helper tool at https://www-304.ibm.com/software/brandcatalog/ismlibrary/details?catalog.label=1TW10OS03# (click the “Download” link, you’ll need an IBM ID).

That tool is an HTML GUI where you will supply the IP address of your TPMfOSD server, and it will build the binary string that you need to use to configure Option 43 on your DHCP server to forward PXE clients to the TPMfOSD server.

You may find it useful to read the PDF that @Gianluca references at http://www-01.ibm.com/support/docview.wss?uid=swg27027022&aid=1

Hi,

Thanks for your updates,
In my scenario I have multiple subnet range like 172.16.2.0, 172.16.3.0, 172.16.5.0, 172.16.10.0, 172.16.8.0,
My DHCP server range is 172.16.10.0, also TPMOSD server range 172.16.5.0,
so I have configured option=43 using the tool, in this tool shall I configure option=6 means “PXE option 6 (06) PXE_DISCOVERY_CONTROL”?
may i know the meaning of "Use PXE_BOOT_SERVERS list, disable multicast and broadcast
discovery.” in my environment subnet range, please share the details.

Thanks,
Nagaraj.

Hi,

if i configure option=6, it any other subnet range will be blocking, like I connected a target machine subnet range 172.16.3.0 means is that any blocking?

Thanks,
Nagaraj.