In a complex network configuration,
it is often preferable to manage one master Ignite server and use
that server to support installation for all subnets. A central server
simplifies administration and helps ensure all systems are managed
with consistent installation and recovery. The challenge is to have
a central Ignite server support network boot for all your required
subnets, handle installation, and coexist with any other network boot
servers.
The following diagram illustrates a complex network with multiple
subnets (10.1.1 and 10.2.1) connected to the Ignite server (hpignite), remote systems (hpuxsysa and hpuxsysb) that use a boot helper system (iuxboot), a system (hpuxsysz) on a separate subnet without a boot helper, and another boot server
(sysrdp) on the same subnet as the Ignite
server. Systems on the same subnet (10.1.1 or 10.2.1) as the Ignite server are HP-UX
systems (hpuxsys1, hpuxsys2, and hpuxsysx), a Linux system (linuxsys2) and a Windows system (winsys1). This diagram will be used as an example network configuration
throughout the complex network chapters.
Multiple Subnets |
 |
The challenge with an Ignite server connected to multiple subnets
is ensuring the server is correctly configured to handle client network
interfaces for boot and installation on the different subnets. If
subnets are isolated or performance is a concern, you will need to
ensure that installation traffic is correctly routed to the Ignite
server.
The following diagram shows the example systems used when outlining
solutions for a complex network with multiple subnets.
Remote Systems |
|
Network boot is based on broadcast protocols. These broadcasts
are normally constrained to one subnet. When client systems are on
a subnet that is not directly connected to an Ignite server broadcast
network, packets used for boot will not be able to reach the Ignite
server. If there are remote systems on other subnets (hpuxsysa and hpuxsysb), you
must determine how network boot will be supported on each subnet for
these systems. You will also need to ensure that installation traffic
is correctly routed.
The following diagram shows the systems that will be referenced
when solutions for remote systems are discussed.
Multiple Boot Servers |
|
If there are multiple servers that support boot and installation
on a subnet (sysrdp and hpignite), these systems are very likely to interfere with each other. This
is common when systems running different operating systems coexist
on the same subnet and network installation is used to manage these
systems.
Network boot and installation servers are typically designed
with the assumption that they are the only such server on the subnet.
Product documentation generally does not include details on how to
have multiple servers coexist.
Note that PXE has been designed to assume multiple boot servers
provide redundant, identical functionality. The first server to respond
to a boot request will be used for system boot. In general, it is
not possible to predict which server will respond first.
Often, an administrator wants separate boot and installation
servers to provide, for example, different operating systems. In this
case, using the correct server is important. As a result, some means
of selecting the correct boot and installation server is vital. There
is not a simple solution using basic DHCP PXE functionality.
Great care is required to properly set up a network configuration
where there are multiple boot servers on a subnet. Each boot server
must be configured to correctly coexist with other boot servers and
support the desired overall administration solution.
Printable version
