Ignite-UX Administration Guide for HP-UX 11i (B3921-90080, November 2013)

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 (page 31) and
Chapter 4 (page 43).
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” (page 60).
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.
Avoiding Complex Network Issues 51