DHCP, boot server race?

[Jay Tanner]

We are developing a system consisting of many XPe blade servers, a boot
server resident on a blade, and an ethernet switch blade that also
provides a DHCP server. For minimal boot time we tried booting the
switch (runs embedded Linux) and the boot server (currently XP Pro) in
parallel. In this case we find that the blade servers get IP addresses
from the switch/DHCP server but they do not get images from the boot
server. If we boot the switch/DHCP server before the boot server then
the blade servers get IP addresses and images.

Does the boot server, which has a static IP, have a requirement that a
DHCP service be available prior to it being initialized? One scenario
that I can imagine being responsible for our failure is that the boot
server may be ready before the DHCP server is ready and the boot server
observes that there is no response to the initial DHCP requests so it
decides that it will not provide an image. If this decision is
"latched" then the boot server may not provide an image even after the
DHCP server becomes ready and provides an IP address. Does this make
any sense?

JT

 

[KM]

Jay,

Before going into analysis of your message could you clarify a few terms you used?

"XPe blade server"?
"boot server"? (RBS?)
"a boot server resident on a blade"?

That could be my poor English but I could not interpret your message properly.

If your XPe devices leverage PXe to boot the image, you will need DHCP (or at least BOOTP) server running on the network.
But you probably knew this as you would have had to set up RBS/DHCP environment for booting the clients.

 

[Jay Tanner]

KM,
Thanks for answering and I'm sorry for not being clear enough.

All system elements are Compact PCI (cPCI) and are plugins in a PICMG
2.16 chassis. This simply means everything is a blade and all blades
are networked via paths that are integral to the chassis backplane. In
this context,
XPe blade server -> a general purpose blade computer on which we will
execute a dedicated function operating under XP Embedded.
boot server -> a similar blade as described above but running a disk
based OS, e.g. XP-Pro or Win Server 2003 and running the RBS packaged
with XP Embedded. This is the same device as "a boot server on a blade"
and it has a static IP.
switch/DHCP server -> a PICNG 2.16 ethernet switch. Such switches
typically include a DHCP server that can assign slot specific IP
addresses. For example, it can be desirable to have a mapping of IP
address to chassis slot number for physical identification of failed blades.

We are using PXE and we do have DHCP as supported by the "switch/DHCP
server" element. The question is whether this device, particularly the
DHCP service, can engage in a race with the RBS if both are booted in
parallel such that a race outcome might be that clients can get IP
addresses but not be served boot images under PXE.

 

[KM]

Jay,

Thanks for the clarifications. It is clear now.

Well.. you probably realize that RBS is not DHCP server. It works rather as Proxy DHCP in the PXE boot scenario.
The client initial DHCP request has to be responded by DHCP (offers an IP) and Proxy DHCP (replies with boot server IP). Then there
is BINL and then TTFP requests to the boot server (and to TFTP server if separated).

So, I am not sure how PXe can work if one of the parts is not there.

Read through this doc: http://www.3com.com/other/pdfs/infra/corpinfo/en_US/pxe.pdf

Anyway, what PXe timeout is set on your client machine? I meant how long it sends the PXe requests (DHCP requests with PXEClient
option set) out? If it is only 5 seconds, it may be not enough for both servers to boot up and get working. You can higher the
timeout value, though.
If you can't, you can switch to other PXE implementations (up to DOS based PXe on a floppy disk).