Avoiding Complex Network Issues

An Ignite-UX Server for Each Subnet

If your organization has separate groups that have distinct needs and compute resources, the simplest approach to deal with complex networks might in fact be to manage distinct subnets rather than set up a central Ignite server.

An Ignite server can be placed on each subnet. You may manage each server separately. This avoids the complexities of multiple subnets. Similarly, boot servers for other operating systems can have their own subnets.

Note that newer Integrity systems support HP Virtual Connect technology that permits the remote “rewiring” of network connectivity. This allows systems to be “moved” between subnets via VC profiles, which include network switch configurations. These may be used to avoid issues with managing multiple Ignite servers and subnets.

For information on configuring an Ignite server for a simple subnet, see Chapter 3 and Chapter 4.

A Multi-Capable Server for Each Subnet

Issues with multiple boot servers on a subnet might be avoided or resolved by having only one boot server on each subnet. Normally, that implies the subnet would have limited boot and installation support for one operating system instead of the ability to support various types of installations.

Depending on the boot server ability for nonstandard configuration, it might be possible to configure a single boot server to initiate or even fully support the installation of a variety of operating systems including HP-UX. Such a configuration is clearly complex and requires expertise in the details of boot and installation support for all the systems and operating systems involved. For more information, see “Multi-Capable Subnet Boot Server”.

Extend the Local Subnet

In some cases, it is possible to avoid multiple subnet issues by changing the network topology related to network boot functionality. It might be possible to use network tunneling or configure routers to forward some broadcast packets beyond the local subnet.

This results in a larger, single subnet instead of multiple subnets and very effectively avoids issues with multiple subnets. Changing the network topology might work well if data center policies allow and one group manages this larger subnet.

Take care to consider how any network products change network performance and timing, as they might cause boot and installation issues in some cases.

This guide does not include details regarding network infrastructure hardware and software products, and their use. Consult network hardware and software products' information used to extend the local subnet.

Using Virtual LANs Properly for Ignite-UX

If you use Virtual Local Area Networks (VLANs) and you encounter problems during network boot, you need to discover how the VLANs are configured between your Ignite server and client. It is possible to configure VLANs in multiple ways, and some methods might cause issues for Ignite-UX.

The simplest, and possibly the most common, configuration is a single VLAN presented to a single LAN interface where all traffic, including any untagged traffic, travels on the one VLAN. (This method of configuring VLANs is often used to limit the size of a broadcast domain.) This type of configuration does not cause any problems for Ignite-UX because it logically appears as if the client and Ignite server were connected via a switch. The Ignite server will have access to all the network traffic that originates with the client.

A slightly less common, but equally valid, configuration has multiple VLANs configured on a network switch port. Untagged traffic can be presented to only one VLAN, often called the native VLAN. The native VLAN is defined in the configuration of the switch. In this situation, the Ignite server might not have access to the native VLAN of the client.

If the Ignite server does not have access to the native VLAN, it will not have access to any of the untagged traffic from the client. This becomes a problem, since during an Ignite-UX installation or recovery, no network traffic is tagged until the session is complete and the final system is running. This includes two-step media recovery.

Problems with VLAN configuration can be difficult to detect, since a system could be configured to use a nonnative VLAN when the operating system is running. This would, for example, allow you to create a recovery archive for the client on an Ignite server, but not allow you to recover the client from that same Ignite server.

To remedy this problem, you must provide routing between the VLANs for systems that use nonnative VLANs.