Complex Network Solutions

Automating HP-UX OS Version Selection

During HP-UX boot for installation, it is necessary to select the HP-UX OS version to be installed. It might be desirable to set up an Ignite server or boot helper to provide different default settings for client systems in order to help automate installation.

The boot loader AUTO file controls the menu of HP-UX OS versions and the default selection. The Ignite server may be configured to use separate AUTO files for each HP-UX OS release, as shown below.

The B.11.23 and B.11.31 AUTO files should be edited to have different boot defaults. It is recommended you keep the other boot menu entries so users have the ability to interactively select their desired HP-UX OS version during boot. Alternatively, it is possible to constrain boot options via this approach.

To use this approach, modify bootptab entries to use the appropriate boot loader. The boot loader will use the AUTO file in the same directory where nbp.efi is located.

Ignite requires the HP-UX version of the install kernel and install file system to match the HP-UX OS version to be installed. By having different defaults in the AUTO files, the correct install kernel and file system will be automatically selected.

Limit Network Response by System Class

A subnet might include a variety of systems and devices. Systems that cannot run HP-UX, such as x86 systems and printers, might request network boot. If the subnet includes various systems and devices, HP-UX boot servers should be configured to respond only to device classes they can support.

Note that this approach does not resolve issues with handling client systems that are able to successfully boot and install from different boot servers. The device class is a constant attribute of the system. Thus, this approach will not help resolve issues with multiple boot and installations servers intended to support Integrity systems, since all Integrity systems report the same device class.

For information on how to configure this solution for booting, see “Ignite-UX Server and Boot Helper Setup for DHCP”.

For information on how to configure this solution for networking IP address allocation, see “Isolating Ignite-UX From Noncontrollable DHCP Servers ”.

Directed Boot

If client system firmware supports directed network boot, that is a simple way to avoid complex network boot issues. Directed boot support is not available in some older Integrity systems. Also, directed boot requires interaction with the system console. Finally, directed boot requires specifying the network configuration. In most cases, this configuration needs to be consistent with DHCP or boot server configuration for the client.

Directed boot is provided by the EFI commands dbprofile and lanboot. These commands make it possible to specify the network configuration to be used for boot (IP address, netmask, gateway, etc.). For convenience, a dbprofile may be associated with one or more EFI boot menu options so subsequent boot for installation from the master Ignite server is simplified. Because the direct boot profile may include a gateway, it is possible to directly boot from an Ignite server on a separate subnet without using a local subnet boot helper.

For detailed information on directed boot, see “Direct Boot Profiles for Itanium-Based Systems”.

Server Selection

PA-RISC clients can specify the boot server to use for DHCP/bootp services and ignore all other boot offers. The client system network configuration is supplied by the boot helper or Ignite server located on the same subnet. It is also possible for PA-RISC systems to “search” for network boot options and build a list that may be used to select the desired boot server. For more information, see “Booting PA-RISC Clients from the Console ”.

Limit Network Boot Response by Network Interface Address

When a system broadcasts a request for boot, the request includes the NIC network address (also known as the MAC address).

Boot servers are often configured to respond to all systems that broadcast a boot request since that approach simplifies administration. However, most boot servers have the ability to selectively respond to boot requests.

You can typically configure boot servers to use the network address to decide whether to respond to the client system or not. If the server responds, the network address is typically used to determine the correct client-specific network configuration (IP address, netmask, gateway, etc.).

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.

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 could 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 should 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 should 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.

If DHCP is used, this should not be needed since the DHCP server should provide appropriate routing information.

	IMPORTANT: The sd_server IP address setting in the installation file system will be overridden by sd_server settings in configuration files created by make_config. To use IINSTALLFS to control the sd_server setting you must comment-out or remove the sd_server settings within each sw_source clause in the affected configuration files.

For more information about changing IINSTALLFS content, see instl_adm(1M) and instl_adm(4).

Multiple NICs Attach the Ignite Server to Multiple Subnets

It is possible to connect one Ignite server to multiple subnets using multiple network interface cards (NICs). The Ignite server can then be used to support network boot and installation on each of these separate subnets. The following diagram is an example of a multiple subnet complex network.

There are some special Ignite configuration considerations for supporting multiple subnets from one server. You must be careful to configure the server so it sends the client correct networking information for its subnet, and you must configure the client so it contacts the correct Ignite-UX server.

Having the Client Contact the Correct Server

The server keyword in the IINSTALLFS configuration information 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.

If a client is on a subnet that does not have a route to the IP address specified by server, then it will not be able to contact the server after it boots.

For performance reasons, you might want to use the IP address of the Ignite-UX server LAN interface directly connected to the same subnet as the client.

If packets are not routed between different subnets connected to the Ignite-UX server, the client must use the IP address of the Ignite-UX server LAN interface on the same subnet.

Individual clients might use different IP addresses to access the Ignite server due to performance reasons or routing reasons as described in “Install Remote Clients Through a Network Router”. To customize the IP address used to access the Ignite server on a per client basis, use the LLA keyword as described below.

Workarounds to specify the IP address of the Ignite server are:

• Correct the server's IP address on the Ignite-UX network setup screen that appears on the client console when you boot the client.

• Change the configuration content in IINSTALLFS to select the Ignite-UX server and depot server IP addresses connected to their local subnet.

  server = "10.1.1.11" sd_server = "10.1.1.11" LLA[] == "00306E4A03C2" {server = "10.1.1.11" sd_server = "10.1.1.11"} LLA[] == "00306E4A03C3" {server = "10.2.1.11" sd_server = "10.2.1.11"}

	IMPORTANT: The sd_server IP address setting in the installation file system will be overridden by sd_server settings in configuration files created by make_config. To use IINSTALLFS to control the sd_server setting you must comment-out or remove the sd_server settings within each sw_source clause in the affected configuration files.

For more information about changing IINSTALLFS content, see instl_adm(1M) and instl_adm(4).

Ignite-UX bootp Boot Helper

An HP-UX server may be used as a boot helper to support boot on a subnet while installation is accomplished via a master Ignite server connected to a different subnet.

A system with Ignite software installed may be located on each subnet to support initial boot. This subnet-local Ignite server may be set up with IINSTALLFS configuration content to specify the single Ignite master server.

Using this approach, all the HP-UX installation and recovery content may be managed on one system. However, each local subnet Ignite boot helper server must be configured to support network boot for all the clients on that subnet. The boot helper server may be configured for promiscuous network boot or via selective MAC address response.

The advantage of this approach is there can be a single Ignite server that handles all HP-UX installation and recovery content. A significant disadvantage of this approach is that Ignite software must be installed on each boot helper. The version of Ignite installed on these boot helpers must always match the version installed on the master Ignite server.

The Ignite product content located in /opt/ignite/boot must be present on the Ignite boot helper so it may be used to accomplish network boot.

Follow these steps to set up an Ignite-UX boot helper system on the local subnet:

HP-UX DHCP PXE Next Server Boot Helper for Integrity Systems

To support Integrity systems, a lightweight Next Server boot helper may be set up on each subnet. A DHCP PXE response includes a Server Address (SiAddr) field that indicates where to get additional network boot content. Normally, the value in a response informs the client to get subsequent boot content from the same boot server. The /etc/bootptab file can be configured to inform the client to switch to the master Ignite server for other boot content. The bootptab sa option is used to indicate the value. This is commonly described as a Next Server value, since the Server Address value is typically only given when the value differs from the initial boot server. The master Ignite server IP address should be used.

In this approach, each subnet must have a DHCP PXE server, but Ignite does not need to be installed on that system. Therefore, there is no need to have multiple systems with the same Ignite software version installed on them. The HP-UX bootp server may use the Next Server field to direct the client system to get the HP-UX OS content from an Ignite server on a different subnet.

Using this approach, all the HP-UX installation and recovery content may be managed on one system. However, each local subnet Next Server DHCP PXE boot helper must be configured to support network boot for all the clients on that subnet. The boot helper server may be configured for promiscuous network boot or selective response using client-specific network configurations.

Note that this Next Server boot helper does not have to be an HP-UX system. If it's not an HP-UX system, care must be taken to make sure the PXE response is consistent with the Ignite server. In particular, the boottab bf option provided from the Next Server boot helper must be consistent with where the boot content is located on the master Ignite server. Symbolic links may be used to allow a nonstandard location to be supported on the master Ignite server, if needed.

Configuring a Next Server Boot Helper for Integrity systems

A Next Server boot helper does not require Ignite-UX software.

If the DHCP PXE server is an HP-UX system, it must be running 11i v2 (B.11.23) or later. If 11i v2 is used, PHNE_36209 or a superseding bootpd patch must be used to enable the configuration of Next Server response.

The nbp.efi boot loader file must be present on the Next Server boot helper:

# cp /usr/lib/efi/EFI/HPUX/nbp.efi /opt/ignite/boot/nbp.efi

If the Next Server boot helper is a PA-RISC system, this boot loader file will have to be copied from an Integrity system. Note that the Ignite-UX product may be installed instead of copying this file in place.

The Next Server response is configured in /etc/bootptab using the sa option. The IP address given with the sa option should be the DHCP PXE Next Server (SiAddr) IP address for additional boot content.

This example configuration is for the following complex network diagram.

A sample /etc/bootptab for Next Server boot helper configuration follows:

next-server:\ bf=/opt/ignite/boot/nbp.efi:\ ht=ethernet:\ hn=:\ bs=48:\ dn=xyzco.com:\ gw=15.1.128.1:\ sm=255.255.255.0:\ ds=10.2.1.11 hpuxsysa:\ tc=next-server:\ ha=00306E4A03C2: ip=10.4.1.140:\ sa=10.2.1.11:\

During DHCP PXE boot, the boot helper server provides the network configuration (IP address, netmask, gateway, etc.). The boot helper also provides the initial boot loader (nbp.efi ). All other boot content is taken from the master Ignite-UX server. Thus, this boot helper server requires no Ignite-UX product content.

Note that the bf option path must match the path where other boot content is located on the master Ignite server. The bf path must be valid on the boot helper and the Ignite master server.

Make sure the correct server is set and any network routing is configured as described in “Having the Client Contact the Correct Server” and “Install Remote Clients Through a Network Router”.

Forwarding Boot Requests via bootp Relay

The HP-UX bootp server has the ability to forward boot requests. With this approach, each subnet must have a bootp relay boot helper, but that system does not need to have Ignite software installed. Therefore, there is no need to have multiple systems with the same Ignite software version on them.

When a client system broadcasts a request for network boot, the bootp relay boot helper will forward the request to the master bootp server indicated in the bootptab. The master bootp server will respond to the bootp relay boot helper, which will then forward the response back to the client system. The master Ignite boot server and master bootp server should be the same system.

The bp option must be specified in the bootp relay boot helper's /etc/bootptab file to forward boot requests to the master bootp server. The bp value should be the IP address of the master bootp server. The ip option must not be specified since that value will be provided from the master bootp server. Often an hm option is also specified so a single bootptab relay configuration may be used for many or any clients. The hm option is a MAC address mask used to determine if the MAC address of the requestor matches the MAC address of the ha bootptab option.

ha=000000000000:\ hm=000000000000:\ bp=10.2.1.11

Note that care is needed if the system is connected to multiple subnets, since the bootp relay helper will respond to boot requests detected on any NIC. Make sure the correct server is set and any network routing is configured as described in “Having the Client Contact the Correct Server” and “Install Remote Clients Through a Network Router”

See bootpd(1M) for details of configuration.

Note that this approach works for PA-RISC systems but might not work for Integrity systems. For Integrity systems, the HP-UX boot loader configures the bootp relay boot helper as a gateway system for network configuration. If that system does not route packets between subnets, this might impede successful use of this approach. If the system routes packets, it will be attached to multiple subnets and therefore respond to boot requests detected on multiple subnets.

Ignite-UX software does not have to be installed on the bootp boot helper.

The following is an example of a local bootp relay boot helper /etc/bootptab content to respond to any client MAC address:

bootp-relay:\ ht=ether:\ ha=000000000000:\ hm=000000000000:\ bp=15.2.1.11

The following is an example of selective, MAC-specific /etc/bootptab content:

hpfcixa: ht=ether:\ ha=001083352de5:\ bp=15.2.1.11

A block of MAC addresses may be specified using the ha and hm options. This approach might be very useful with HP systems supporting HP Virtual Connect technology.

The master Ignite server needs to have entries for the client system boot requests forwarded from the bootp forward boot helper:

ignite-defaults:\ bf=/opt/ignite/boot/nbp.efi:\ ht=ethernet:\ hn:\ bs=48:\ dn=xyzco.com:\ gw=10.4.1.1:\ sm=255.255.255.0:\ ds=10.2.1.11 hpfcixa:\ ht=ignite-defaults:\ ha=001083352de5:\ ip=10.4.1.100:\ bp=10.2.1.11

To use the bootp relay boot helper with PA-RISC systems, boot using standard ports, such as:

boot lan.10.2.1.11

The installation option to use HP-UX specific network ports might not work:

boot lan.10.2.1.11 install

Multi-Capable Subnet Boot Server

It is possible to set up a boot server that supports boot for multiple operating systems, including HP-UX. The multi-capable boot server may be an HP-UX system or a non-HP-UX system. If this boot server is an HP-UX system, the challenge becomes: how do I configure the HP-UX boot server to support non-HP-UX boot and installation. If the system is not an HP-UX system, the challenge becomes: how do I set up HP-UX boot and installation on the non-HP-UX system.

The information in this section is intended to provide general information to assist those setting-up a multi-capable boot server to initiate or fully support the installation of a variety of systems, including HP-UX installation. There is no general recipe for configuring these systems. In all cases, expertise is required to adapt these approaches to practical solutions.

For more detailed information about setting up specific types of boot/installation servers to support specific operating systems, see Chapter 6.