emBoot - Network Boot FAQ

Network Boot FAQ

General

1. What is network booting?
2. Why should I consider network booting?
3. What boot protocols do you support?
4. What network adapters do you support?
5. Do you have plans for other network adapters?
6. What are the differences between BOOTP, DHCP, and PXE?
7. Is network booting secure?

Platform-Related

8. What processors do you support?
9. Do you have any specific BIOS requirements?
9b. Do you support BIOSes that offer console redirection via VT100, ANSI terminal or terminal emulator?
10. How can I add network boot to my client device?
11. What is the size of your client boot firmware?
12. Do I need to have more RAM in my client to support network boot?

Client OS-Related

13. What client OSes can I network boot?
14. How large is a client boot image?
15. Do I have to load the entire OS boot image into client RAM?
16. Is there any specific support for RDP clients?
17. Is network booting fully supported by virtual machine software such as VMware or Connectix?

Network-Related

18. What are network requirements for implementing network boot?
19. Can I network boot using Gigabit and 10-Gigabit Ethernet adapters? What about iSCSI?
20. What if I already have a PXE server on the network?
21. I will be booting many clients simultaneously; will that cause problems?
22. Do you have any support for fault-tolerant network connections?
23. What about network booting over wireless links?
24. Can I network boot a client over a WAN?

Server OS-Related

25. What kind of server OS do I need to support network boot?
26. What components or services do I need to load at the server?
27. What applications out there use network boot? For what purpose?

1. What is network booting?

Network booting works by using client software (boot agent), usually in the form of firmware, that makes the network look like a bootable device. The client device is configured to use the boot agent to boot from the network, such that, when the client device is powered on, a boot image file is downloaded from the server into the devices memory and executed.

The client OS/app can be downloaded as an "execute in place" RAM image, or as a RAM drive. This boot image file can contain the operating system for the embedded device or a pre-OS agent that performs client management tasks. The client then boots from the downloaded image.

2. Why should I consider network booting?

Lower build cost than local hard drive or Flash
Increased device reliability
Ease of management / update
Flexible storage capacity
In some cases, enhanced security

3. What boot protocols do you support?

emBoot's Managed PC Boot Agent (MBA) supports the following boot protocols:

PXE
DHCP
BOOTP
RPL
NetWare NCP/IPX

4. What network adapters do you support?

For a complete list of supported network adapters, please see http://www.emboot.com/SupportedNICs.htm

5. Do you have plans for other network adapters?

Yes, emBoot adds support for network adapters on a regular basis, based on customer or market demand. If your adapter is not supported, contact us and we'll be happy to discuss your requirements.

6. What are the differences between BOOTP, DHCP, and PXE?

All of these are based on well established TCP/IP specifications, but there are some differences between them:

BOOTP uses static IP addressing, manually assigned, and is frequently used in embedded implementations
DHCP is similar to BOOTP, but offers dynamic IP address assignment which simplifies configuration
PXE is similar to DHCP, and extends DHCP by offering client-specific information

7. Is network booting secure?

There are provisions within the PXE specification for an optional component (BIS) that can be used to ensure that boot images came from an authenticated server, and that they were not tampered with along the way. emBoot's PXE clients offer support for BIS. Network booting itself can often enhance security, by centralizing the persistent storage of sensitive information.

8. What processors do you support?

Our network boot clients support the Intel x86-family of processors (including compatible processors manufactured by AMD, Cyrix, National, Transmeta, and others.

9. Do you have any specific BIOS requirements?

Most contemporary BIOSes are supported without any problems. It is recommended that the BIOS supports the Phoenix "Bios Boot Specification" (BBS). To reduce extended memory requirements, support for the Phoenix "Post Memory Manager" (PMM) specification is also recommended. For further information on the BBS specification, see http://www.phoenix.com/resources/specs-bbs101.pdf . For further information on the PMM specification, please see http://www.phoenix.com/resources/specs-pmm101.pdf

9b. Do you support BIOSes that offer console redirection via VT100, ANSI terminal or terminal emulator?

Yes, this is possible if you order a customized version of our boot client.

10. How can I add network boot to my client device?

Any of the following methods can be used to add network boot support to your client device:

BIOS integrated firmware
Separate NIC option ROM
Compact Flash, Disk on Module, or similar device
CD or floppy

11. What is the size of your client boot firmware?

Typically, the network boot client is approximately 57KB in size. If the client is integrated into a BIOS which supports option ROM compression, the actual BIOS payload will be about 50% smaller.

12. Do I need to have more RAM in my client to support network boot?

This depends on several things, but mostly on how the client OS boot image is loaded into memory. In many cases (including Linux, WinCE, and others), the OS image is loaded from the network and is placed in client RAM, just as it would have been if the OS image was loaded from local storage. In this case, no additional RAM is required.

In some cases, the network boot implementation creates a local RAM drive from which the OS image is loaded. In this case, your client will require additional RAM in order to host the RAM disk image.

Finally, in some cases, the client OS is accessed via disk emulation over the network; the data is accessed on a sector by sector basis. In this case, no additional workstation RAM is required, except perhaps to host a local cache file to minimize network traffic.

13. What client OSes can I network boot?

Just about everything:

Linux, and Linux-variants
VxWorks
QNX
LynxOS
NetBSD
WindowsCE.net
XP and XPe
Windows NTe
Windows 2000
Windows 2000 / 2003 Server
Windows XP Pro
DOS

14. How large is a client boot image?

This depends on the OS, and whether the boot image includes any client applications. DOS images can be as small as a few hundred KB, Linux images are somewhat larger than this. WinCE images are typically 5-10MB in size, while XPe images can be several hundred MB in size.

15. Do I have to load the entire OS boot image into client RAM?

Not necessarily; some OS environments support "sector by sector" emulation, where the boot drive is accessed over the network as needed.

16. Is there any specific support for RDP clients?

RDP clients are used to provide access to Microsoft's Windows Terminal Services. Microsoft provides 32-bit Windows RDP clients only. While there are open-source Linux based RDP clients available, emBoot offers the only DOS and Linux-based RDP client support by network boot available, with features exceeding those of the open-source alternative. When combined with our network boot technology and software, you can enable your diskless workstations, POS devices and aging PCs to quickly and easily run Microsoft Windows NT, 2000, XP and 2003-based applications.

Some features:

Super-fast DOS 16-bit and Linux 32-bit RDP clients
Automatic detection of Network Interface Cards
Quick setup
Pre-configured boot images
High color, sound and local printing support (Linux RDP client)
Local Drive mapping (Linux RDP client)
Serial Port Mapping (Linux RDP client)

17. Is network booting fully supported by virtual machine software such as VMware or Connectix?

Yes, network booting is fully supported for use in Virtual Machine software by both VMware's VMware Workstation, ESX and GSX Servers, and Connectix's Virtual PC software. emBoot's MBA on Disk for VM products provide PXE and other boot protocol support with little or no configuration required for the emulated AMD and Digital network adaptors used by these vendors. The combination of emBoot's network boot products enabled for virtual machine technology makes great sense for technical marketing demos, development and support engineers - the typical server/client network boot requirement of 2 distinct machines can now be reduced to a single hardware platform!

18. What are network requirements for implementing network boot?

In the most typical situation, network boot clients are situated on the same network segment as the boot server. Due to bandwidth requirements, this should be at least a 10Mbps link (could be less if client OS is small). If the boot server is not on the same segment as the boot client, all intervening routers will need to have DHCP forwarding (sometimes known as IP helper addresses) configured correctly.

19. Can I network boot using Gigabit and 10-Gigabit Ethernet adapters? What about iSCSI?

Yes, emBoot supports network boot on several different gigabit chipsets, and is currently in development with several vendors on adding support for 10-Gigabit Ethernet support.

As for iSCSI, our PXE boot agents can download an iSCSI bootstrap so that clients (hosts) can boot from an iSCSI target. netBoot/i provides the ability to network boot Windows Servers and Desktops from an iSCSI target remotely located over a standard IP network. Click here to learn more about netBoot/i.

20. What if I already have a PXE server on the network?

If multiple PXE servers are running on the same network, standard PXE clients will either boot from the PXE server running on the same system as the DHCP server (because it has the highest priority), or they will boot from whichever other PXE server was the first to respond. This results in unpredictability as to which PXE server should be configured for each client and which PXE server should host the boot-related files for each client.

emBoot has addressed this shortcoming in PXE by introducing a special extension to PXE, known as PXE Server Directory Service, or PXESDS. With PXESDS, network administrators can specify which PXE server a client will boot from, and thus only need to configure and maintain that client's boot -related files on the designated PXE server. Contact emBoot for further information on PXESDS.

21. I will be booting many clients simultaneously; will that cause problems?

This depends on a number of factors, including:

Number of clients
Effective throughput of the server delivering the boot files
Effective throughput of the network
Size of the boot files being delivered
Whether or not multicast TFTP is being used

Contact emBoot for further details if you have any concerns about booting multiple clients simultaneously.

22. Do you have any support for fault-tolerant network connections?

The PXE specification itself was not designed to support multiple network boot devices within the same device, at least not with a BIOS-integrated client. Thus, if the device failed to complete its network boot on one link, it cannot be guaranteed that booting will continue normally on the second link. Fortunately, emBoot has developed an extension to the PXE specification that offers a seamless fail-over onto the second link should the boot attempt on the first link fail.

23. What about network booting over wireless links?

emBoot has developed boot client support for the 802.11b specification. Naturally, there are some restrictions on distance and speed when compared to Ethernet, but the capability exists. Faster implementations, such as 802.11g are recommended.

24. Can I network boot a client over a WAN?

See the question about network requirements earlier on in this section of this FAQ.

25. What kind of server OS do I need to support network boot?

This depends on which network boot protocol you will be implementing. When implementing PXE, DHCP, or BOOTP on Windows-based servers, several products exist, including emBoot's Network Boot Tools. For most Linux distributions, PXE and BOOTP are supported.

26. What components or services do I need to load at the server?

Again, this depends on the boot protocol being deployed. For PXE, you will typically need to load a PXE boot service, along with a TFTP server.

27. What applications out there use network boot? For what purpose?

Some vendors use network boot for specific, focused applications, whereas others include it as part of an overall framework in managing corporate desktops. We provide the list below as a cross-sampling of these - it is by no means exhaustive.

OS installation:
. Microsoft Remote Installation Services / WINPE
. Rembo Auto-Deploy Disaster Recovery
. Winternals Remote Recover
Diskless Workstations:
. VenturCom BXP
. Qualystem LAN-PC
. Linux Terminal Server Project
Hard drive imaging / application deployment:
. Symantec Ghost Enterprise
. PowerQuest Deploy Center Library
Desktop management:
. Altiris Client Management Suite
. On Technology CCM
. Novell ZENworks
. LANDesk Management Suite
Enterprise Desktop Management:
. IBM Tivoli
. CA Unicenter
. HP Openview

iSCSI boot

Boot from IP SAN using standard Ethernet NICs.

netBoot/i provides the ability to network boot Windows Servers and Desktops from an iSCSI target remotely located over a standard IP network.

SimplyRDP

Reduce new hardware costs by implementing a thin client solution using existing desktops.

Contact