When using this approach, boot servers typically have configuration content that allows them to respond to a set of MAC addresses. For HP-UX servers, the /etc/bootptab file is used to identify the clients to respond to. Listed MAC addresses will receive a response using the client-specific details in the bootptab file. For more information, see Chapter 3 (page 31).

Some non-HP-UX boot servers may be configured to ignore a set of network addresses and respond to others. Note that HP-UX does not support this capability.

NOTE: HP Virtual Connect (VC) network technology allows MAC addresses to be changed via profiles. It is possible to allocate a range of MAC addresses for different boot servers, configure an HP-UX server to manage that block of MAC addresses, and then use profiles to select the boot server. Thus, instead of changing the boot server configuration content, the MAC addresses of a system can be changed with VC profiles to effectively choose the correct boot server.

Control network boot via response timing

Since a client system uses the first network boot response it receives, response timing may be used to help select the boot server. One boot server that responds to any MAC address may be configured to respond only after a delay, while all other servers are configured to respond to specific MAC addresses.

Because a number of factors might influence network boot response timing, and servers might respond more slowly in some cases, this approach has a risk of intermittent failures caused when the delayed server responds first because the delay is set too short.

Care is required in deciding the appropriate response delay. Note that a one-to-two second delay for other boot server responses might be large enough to cause an HP-UX server responding to a specific MAC address to normally win. However, a larger delay of eight seconds or more is recommended. You will need to decide the correct delay for your subnets and servers. These recommendations are intended to emphasize that the delay must not be set to “just large enough to work” based on limited testing.

Install remote clients through a network router

By default, Ignite configures IINSTALLFS configuration content without network routing information. If the Ignite server and depot server are on a remote subnet accessed via gateway, and registered IP addresses are used instead of DHCP, the IINSTALLFS configuration content must include network routing information.

The server keyword specifies the IP address for your Ignite-UX server. It refers to a specific LAN interface on the Ignite-UX server. The same is true for the sd_server keyword that specifies the depot server IP address for any depots needed for installation.

server = "10.2.1.11" sd_server = "10.2.1.11"

54 Complex networks: challenges and solutions