Configuring an Ignite Server to Boot Anonymous Itanium-Based Clients

Working With DHCP

Even on a simple network, there could be devices such as printers requesting network boot. This section describes the challenges involved and solutions for DHCP booting and then acquiring IP addresses for networking.




	NOTE: If you are using your Ignite-UX server for DHCP booting, you can set DHCP boot IP addresses from the Ignite-UX GUI by selecting OptionsServer Configuration as described in “Configuring Server Options”.

Understanding PXE Booting of Itanium-Based Systems

When an Itanium-based system boots over the network, it sends out a PXE boot request. The PXE protocol is built on top of DHCP. This can cause confusion if there is more than one DHCP server configured to respond to PXE boot requests.

It is not possible for an Itanium-based system to specify the server from which to accept DHCP boot services, ignoring boot offers from all other servers. In other words, there is not an Itanium-based equivalent for the PA-RISC boot command, boot lan.192.10.10.10 install, which causes the system to ignore any response except from the IP address 192.10.10.10. This functionality is known as server selection.

It is possible for many Itanium-based systems to perform directed boot, where server and client networking information is stored in client firmware and DHCP is not used. For more information on directed boot, see “Direct Boot Profiles for Itanium-Based Systems”.

When an Itanium-based system sends out a PXE boot request, it tries to boot from the first PXE response it gets. If no PXE responses are received within a certain time, the system uses the first DHCP response it gets. If any of these responses are inadequate for network booting, the PXE boot attempt fails and an error message is displayed on the console of the requesting system. The information displayed with PXE errors is usually not explicit enough to determine the cause of the problem (see “Common Network Booting Errors”).

For any network where there will be PXE boot requests from Itanium-based systems, only DHCP servers that can supply enough information for a successful boot should be configured to respond. If you have a DHCP server that responds to every DHCP request, regardless of whether it is a PXE request or not, it almost definitely interferes with PXE boot requests from Itanium-based servers. The boot request fails when a normal DHCP response is received in response to a PXE boot request.

In addition to boot failure, the inability to select a boot server can lead to installation of the wrong operating system. Having PXE servers that respond with different boot content on the same network can cause confusion. For example, if there is a system supporting Linux boot and a system supporting HP-UX boot on the same network, they can each send a response to a PXE boot request, and the first server to respond will be used. It is not predictable which server would be used for boot.

Interference with a PXE request from a DHCP server is a configuration issue on the DHCP server side. This issue is not specific to HP-UX or Ignite-UX, but rather is related to the way firmware performs a PXE boot.




	IMPORTANT: When you configure DHCP servers, make sure there is only one DHCP server on the network that is configured to respond to Itanium-based system PXE boot requests, and that the server is running HP-UX if you want to install HP-UX.

Ignite-UX Server and Boot Helper Setup for DHCP

HP-UX 11i v3 and 11i v2 supports dhcp_device_group options that improve anonymous client DHCP booting for Itanium-based clients. The two configuration keywords re and ncid are used in a DHCP device pool group for this purpose.

Make sure that at a minimum, HP-UX 11i v2 is installed on your Ignite-UX server or boot helper system.

Add your device pool group entry to the /etc/dhcptab file on your Ignite-UX server or boot helper system.

You should not need to restart bootpd if it is already running. When a new bootp DHCP request is received, bootp checks to see whether it must reread any configuration files. If you want to force bootp to reread the configuration file, send it the SIGHUP signal.

The following example DHCP device group is the best way to support anonymous Itanium-based clients:

dhcp_device_group:\ 
    re:\ 
    ncid:\ 
    class-id="PXEClient:Arch:00002":\ 
    lease-time=300:\ 
    subnet-mask=255.255.255.0:\ 
    addr-pool-start-address=192.168.1.10:\ 
    addr-pool-last-address=192.168.1.20:\
    bf=/opt/ignite/boot/nbp.efi

The options in the dhcp_device_group clause are:

dhcp_device_group

Starts a DHCP device pool group for allocating a range of IP addresses to assign to clients with a matching class-id in their boot requests.

re

A binary option that sets regular expression matching on the class-id rather than a default literal match. This is a new option for HP-UX 11i v2.

ncid

A binary option that sets removal of the class-id from message responses. Since bootpd does not support the full Intel Preboot Execution Environment (PXE) protocol, it must not send back a class-id in the response. This is a new option for HP-UX 11i v2.

class-id

Different kinds of systems may make PXE boot requests. For example, Itanium-based systems and industry standard servers such as HP ProLiant servers may each make a PXE boot request. It is unlikely the same configuration could be used for these different requests. The class-id may be used to respond to PXE requests from the correct clients, while ignoring the wrong ones.

All Itanium-based servers send a 32 character PXE boot request in the following format:

PXEClient:Arch:00002:UNDI:xxxyyy

where xxxyyy are major and minor numbers for the Universal Network Device Interface revision.

An industry standard server, such as an HP ProLiant server, sends a PXE boot request in this format:

PXEClient:Arch:00000:UNDI:xxxyyy

where xxxyyy are the same as described above.

The class-id in the dhcp_device_group example above tells the bootpd daemon to respond only to clients with a boot request containing PXEClient:Arch:00002. Requests from industry standard servers are ignored.

A DHCP server or boot helper system configured to respond to any DHCP boot request containing PXEClient will respond to both Itanium-based servers and industry standard servers. A PXE response suitable for an industry standard server is unlikely to allow an Itanium-based system to boot.

lease-time

How long in seconds the IP address may be used to boot a system. The example value is 300 seconds (5 minutes) but you may need more time if your network is a busy one. Booting on high-traffic networks may take 10 or 15 minutes since the install kernel and install file system must be downloaded. The problem with increasing the lease-time is the possibility of running out of IP addresses to use for booting. If you increase this number, make sure you have enough IP addresses in the pool to accommodate systems that might boot simultaneously.

subnet-mask

The subnet mask used by clients.

addr-pool-start-address

The first IP address for this address pool.

addr-pool-last-address

The last IP address for this address pool.




	IMPORTANT: The use of the `ncid` option is critical because it instructs the DHCP server to exclude the DHCP `class-id` in the response to the client’s boot request. If a DHCP server responds to a PXE boot request with the DHCP `class-id` in the response, the booting PXE client attempts to communicate with a PXE proxy server on the same host. Since HP-UX does not supply a PXE proxy server, the boot fails. The `ncid` option resolves this issue.

With the device pool group added to the /etc/dhcptab file, your HP-UX 11i v2 or 11i v3 Ignite-UX server is now configured to respond to anonymous Itanium-based clients.




	IMPORTANT: The server that sends the response to the PXE boot request is the system that the PXE client will attempt to tftp the boot file from. If you are not using an HP-UX system to reply to an Itanium-based PXE request, you must make the required boot files available and current with new releases of Ignite-UX. HP does not provide support for this kind of configuration.

Isolating Ignite-UX From Noncontrollable DHCP Servers

Once Ignite-UX starts running, a DHCP request will be used to obtain an IP address used for installation or recovery if needed. Ignite-UX can be configured to specify a class-id for this request.

For more information see Appendix B and bootpd(1M).

If you have DHCP servers on your network that you have no control over, it is possible to completely isolate Ignite-UX from them. This is done by adding a class-id to the dhcp_class_id keyword in the install file system. See instl_adm(1M) and instl_adm(4) for additional information.

When the network boot process completes and the install kernel is running, Ignite-UX will use DHCP again to obtain an IP address. This is done because Ignite-UX has no way to determine the IP address used by firmware.

If you are running HP-UX 11i v2 or 11i v3 and have configured a DHCP device group for Itanium-based server PXE requests, you can reuse this device group for isolation purposes. If you added the following into the install file system:

dhcp_class_id="IgniteDHCPDeviceGroup",

you can change the class-id in the DHCP device group that responds to anonymous Itanium–based PXE boot requests to read:

class-id="PXEClient:Arch00002|IgniteDHCPDeviceGroup"




	IMPORTANT: The `class-id` entry above is a regular expression designed to allow a response to a `class-id` of an Itanium-based system performing a network boot or an `IgniteDHCPDeviceGroup` in `/etc/dhcptab`. This is not a valid `class-id` for use in an Ignite-UX install file system. Systems using a DHCP device group for installing anonymous Itanium-based systems should have `is_net_info_temporary` set to `TRUE` to prevent systems from using the IP address gained via DHCP after installation.

Since regular expression matching is used, | means "or" and allows response to an incoming class-id that matches either expression. This example entry would support responding to the initial Itanium-based system boot request as well as subsequent DHCP requests during Ignite-UX operation.

The DHCP servers that respond to any DHCP class-id must be reconfigured or isolated to a different subnet.

The information in this section will not help you isolate a system booting Ignite-UX from other DHCP or PXE boot servers when attempting to network boot from EFI. This information does help you stop other DHCP servers from communicating with the installed system after it has already performed a network boot and downloaded an install kernel and install file system.

If you wish to only accept DHCP offers from a specific server after the install kernel and file system loads, consider using the dhcp_server keyword in the install file system. The use of the dhcp_server keyword has no effect on the EFI/PXE boot process.

Replacing bootpd with instl_bootd

If your Itanium-based system is not running DHCP services, replacing the daemon bootpd with the daemon instl_bootd allows network booting for registered and anonymous clients, and both Itanium-based and PA-RISC clients. See Figure 2-2 “Decision Tree When Configuring a Server for Booting Itanium-Based Systems” and the subsequent discussions for more information.




	IMPORTANT: Do not replace bootpd with instl_bootd if your server is currently providing DHCP services. This procedure configures your Ignite-UX server to run instl_bootd instead of bootpd. Performing the steps in the following section will prevent the system from providing DHCP services.

Using instl_bootd on an Ignite-UX server requires that the bootpd daemon is not running on the server. The instl_bootd daemon responds to all boot requests from clients. The instl_bootd daemon normally runs on a set of unique network ports, 1067/1068, which are used only for booting PA-RISC clients. However, in this implementation, the instl_bootd runs on the standard bootpd ports, 67/68.

If you are running bootp with DHCP on your network, do not perform these steps. The instl_bootd daemon will answer DHCP requests as if the system were requesting a network boot. Consider other alternatives if you have bootp with DHCP running on your network.

Follow these steps to configure your Ignite-UX server to run instl_bootd as a replacement for bootpd:

After you have set up your Ignite-UX server, ensure that bootpd is disabled on ports 67/68 by commenting out the following line in the /etc/inetd.conf file:
bootps dgram udp wait root /usr/lbin/bootpd bootpd
Enable the instl_bootd daemon on ports 67/68 by adding the following line to /etc/inetd.conf:
bootps dgram udp wait root /opt/ignite/lbin/instl_bootd \ instl_bootd
Restart the Internet daemon, inetd, to implement the port changes made in step 2:
/usr/sbin/inetd -c

Your Ignite-UX server is now configured to respond to anonymous clients. For more information, see instl_bootd(1M) and inetd(1M).

Configuring an Ignite Server to Boot Anonymous Itanium-Based Clients

Technical documentation

» Table of Contents

» Glossary

» Index

Working With DHCP

Understanding PXE Booting of Itanium-Based Systems

Ignite-UX Server and Boot Helper Setup for DHCP

Isolating Ignite-UX From Noncontrollable DHCP Servers

Replacing bootpd with instl_bootd