Browse Prior Art Database

Post-Boot PXE Client

IP.com Disclosure Number: IPCOM000015538D
Original Publication Date: 2002-Feb-26
Included in the Prior Art Database: 2003-Jun-20
Document File: 3 page(s) / 60K

Publishing Venue

IBM

Abstract

Disclosed is a method for extending the use of Pre eXecution boot Environment (PXE) to allow systems to determine whether any actions on a PXE server are pending for a given system without rebooting the system. This method enables the PXE protocol to be used from within a running operating system to periodically query PXE servers, check for a series of newly defined op-codes, and take appropriate action. This disclosure also provides mechanisms that allow running systems to make use of the PXE protocol, even on systems without the built-in Network Interface Card (NIC) hardware support for PXE. Today, PXE is a momentary hook that occurs only at boot time of the client system and only in the event that the system has PXE enabled NIC hardware and boot sequence set appropriately. Thus, once systems have been booted, there is no way for the PXE server to gain control of them unless the operator either forces a reboot, shuts the machine off (so Wake on LAN can turn it back on), or uses a systems management agent (e.g. IBM Director, Tivoli, SMS, CA Unicenter, HP OpenView, etc.) to remotely control the system. Even if the administrator has a way to remotely reboot the system, he cannot necessarily be certain that the hardware and configured boot sequence will enable the system to boot to the network. Furthermore, there is no simple way to tie a 3rd party management application (e.g. Microsoft SMS) into a PXE-based server application such as IBM's LANClient Control Manager (LCCM) software. For example if an administrator desires to update the BIOS on numerous systems via LCCM, there is no way for LCCM to tell the clients to reboot. One could develop a plug in for the various 3rd party Systems Management products that could coordinate the agent-based management to the PreBoot management, but this would be a never ending job and would require significant resources to maintain. This disclosure introduces the concept of a "PXE client" that runs from a protected mode operating system (e.g. Windows NT, 2000, 98, Linux, etc.) that allows a system to be managed via a PXE server without requiring integration into a 3rd party management agent. The Post-Boot PXE Client issues a PXE request to the network. This includes asking for a DHCP address and listening for a valid PXE Client Extension Tag as defined in the specification. The Post-Boot PXE Client will ignore the DHCP offer for an IP address, and instead use the active IP address of the running operating system. The Post-Boot PXE Client will then continue with the PXE protocol including the TFTP Download of the bootstrap file.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 44% of the total text.

Page 1 of 3

Post-Boot PXE Client

Disclosed is a method for extending the use of Pre eXecution boot Environment (PXE) to allow systems to determine whether any actions on a PXE server are pending for a given system without rebooting the system. This method enables the PXE protocol to be used from within a running operating system to periodically query PXE servers, check for a series of newly defined op-codes, and take appropriate action. This disclosure also provides mechanisms that allow running systems to make use of the PXE protocol, even on systems without the built-in Network Interface Card (NIC) hardware support for PXE.

Today, PXE is a momentary hook that occurs only at boot time of the client system and only in the event that the system has PXE enabled NIC hardware and boot sequence set appropriately. Thus, once systems have been booted, there is no way for the PXE server to gain control of them unless the operator either forces a reboot, shuts the machine off (so Wake on LAN can turn it back on), or uses a systems management agent (e.g. IBM Director, Tivoli, SMS, CA Unicenter, HP OpenView, etc.) to remotely control the system. Even if the administrator has a way to remotely reboot the system, he cannot necessarily be certain that the hardware and configured boot sequence will enable the system to boot to the network.

Furthermore, there is no simple way to tie a 3rd party management application (e.g. Microsoft SMS) into a PXE-based server application such as IBM's LANClient Control Manager (LCCM) software. For example if an administrator desires to update the BIOS on numerous systems via LCCM, there is no way for LCCM to tell the clients to reboot. One could develop a plug in for the various 3rd party Systems Management products that could coordinate the agent-based management to the PreBoot management, but this would be a never ending job and would require significant resources to maintain.

This disclosure introduces the concept of a "PXE client" that runs from a protected mode operating system (e.g. Windows NT, 2000, 98, Linux, etc.) that allows a system to be managed via a PXE server without requiring integration into a 3rd party management agent. The Post-Boot PXE Client issues a PXE request to the network. This includes asking for a DHCP address and listening for a valid PXE Client Extension Tag as defined in the specification. The Post-Boot PXE Client will ignore the DHCP offer for an IP address, and instead use the active IP address of the running operating system. The Post-Boot PXE Client will then continue with the PXE protocol including the TFTP Download of the bootstrap file.

The PXE specification as defined at ftp://download.intel.com/ial/wfm/pxespec.pdf describes how a system can perform a Remote Boot of an operating system via the network prior to an operating system being up and running. This protocol is shown below in Figure 1.

1

Page 2 of 3

Figure 1

The Post-Boot PXE Client can be executed from any Systems Management a...