BOOTP enables computers on a TCP/IP network to extract a number of configuration values automatically from one or more servers on the network, and it optionally boots the computer’s operating system (OS) from these servers. This ability can eliminate manual configuration errors, allow users to transparently attach to a TCP/IP network, and simplify network administration.

TCP/IP has clearly revolutionized network computing. Not only has it brought us the Internet and all that goes with it, but it has brought the midrange community a simple and inexpensive method of universal connectivity. Although TCP/IP has given us an absolutely standardized and extremely efficient method of connecting clients to the AS/400, it also brings with it some challenges, especially in the area of addressing. The Bootstrap Protocol (BOOTP) can significantly lessen the complexity of TCP/IP addressing (see reference book TCP/IP Fastpath Setup) by allowing network managers to assign a TCP/IP address to a client on installation and then use BOOTP to rediscover this address every time the client connects to the host. In this article, I’ll describe BOOTP, detail its function in TCP/IP addressing, and show you how to configure BOOTP on the AS/400.

The Need for Automatic IP Addressing Spawns a Standard

In the early 1980s, TCP/IP was slowly making the transition from college campuses and government installations to the world of business computing. Like many technologies originally designed for purely academic use, TCP/IP had much to offer the business community, which at that time had many disparate networking techniques that didn’t work well together. The business community embraced TCP/IP as a possible means of standardizing communications between its many heterogeneous networks.

At about the same time, a new technology centered around the use of diskless, stripped-down computers was being investigated as a possible means of reducing the cost of maintaining large computer networks. Business analysts realized that having a fully functional PC on every desk, while functionally robust, was bringing capital expenditures to a dangerous level. Farsighted technicians soon saw the potential of using the new “thin

clients,” or network computers (NCs), in tandem with TCP/IP to reduce networking costs. Although NCs and the new networking protocol looked to be a neat solution to high networking overhead, there were some drawbacks to this new paradigm, especially in the area of configuration. These two new technologies were each based on Internet Protocol (IP) addressing, and it was soon apparent that some sort of mechanism to automatically distribute IP addresses was needed both to simplify TCP/IP network administration and to enable the easy use of diskless workstations (see reference book LAN Concepts and Products: LAN Architecture).

The first system proposed by the Internet Engineering Task Force (IETF) for automatically distributing IP addresses was Reverse Address Resolution Protocol (RARP), which uses a RARP server that contains a table linking LAN addresses with corresponding IP addresses. Although it was never implemented on the AS/400, RARP technology led to the introduction of a new, more flexible IETF standard—BOOTP. Since the Request for Comments (RFC951) was first submitted in 1985, BOOTP has been available to aid administrators in IP address configuration and the automatic loading of computer operating systems. Like RARP, BOOTP uses a server that contains a table that points to the client’s IP address, but, unlike RARP, the table can also contain these elements:

• The subnet mask
• The gateway address
• The Domain Name System (DNS)
• The boot file name
• The boot file path While RARP solved the problem of IP address distribution, BOOTP took this model one step further, allowing automatic configuration of many different attributes, including the location of the OS that a diskless workstation should use at boot time. The BOOTP table uses the medium access control (MAC) address of the client as its key. This unique address is “burned” into the communications hardware of each network interface card; in the case of my PC, the MAC address is in the Ethernet card. BOOTP uses this MAC address to find the client IP address and any other configuration variables being used. When properly set up, BOOTP allows one server to handle the configuration demands of an entire network (redundant servers can also be used to ensure availability of service). Along with its newest relative, the Dynamic Host Configuration Protocol (DHCP)—see “Technology Spotlight,” MC, March 1998—BOOTP has helped streamline the process of IP address assignment and simplified network maintenance.

The BOOTP Broadcast

Using BOOTP is the recommended way of attaching IBM Network Stations (one brand of NC) to the AS/400. In this article, I will be using the IBM Network Station (see reference book IBM Network Station Use) in my examples, but most other NC vendors support BOOTP. You can use this technique to configure most NCs to use the AS/400 BOOTP facilities.

BOOTP services use a standard series of actions to automatically obtain addressing information from a host:

1. When turned on, the BOOTP client copies its MAC address into a BOOTP packet and broadcasts this information across the LAN.

2. If the BOOTP client and server are not on the same network, a local BOOTP relay agent is needed to reroute the packet to the defined server(s) or to the next relay agent.

3. The BOOTP server receives the request and tries to match the MAC address with one of the entries in the BOOTP table. If it finds an entry in the table that matches the

request, it will send back to the client a reply containing the client’s IP address, subnet mask, BOOTP server name, and any other configuration values it contains.

4. The client uses the reply information to obtain its IP address, the boot file name, and the boot file path.

With the information obtained from the BOOTP broadcast, the NC can boot and configure itself without operator intervention. The information that is sent from the server to the client may vary, depending on the NC vendor, but the BOOTP sequence of events remains essentially the same for all NC implementations.

Configuring BOOTP on the AS/400

The first step in configuring BOOTP on the AS/400 is to make sure TCP/IP is up and running (see “Configuring Your AS/400 to Use TCP/IP,” MC, October 1997). Since this facility is used to configure IP addresses, it has no use for a non-IP-based network. Once you’ve verified that TCP/IP is up and running, type GO CMDBP at a command line and press Enter to access the BOOTP Commands panel shown in Figure 1. This menu contains all the commands you’ll need to set up BOOTP on your system.

Configuring BOOTP on the AS/400 is not difficult, but it’s important to take your time and enter the correct values the first time. If you do make a mistake in the numbering schemes, finding the error can be a tiresome process. Option 1 on the BOOTP Commands menu (you have to hit Enter twice to get to the commands from this option) is totally redundant: It merely brings up the Configure TCP/IP BOOTP (CFGTCPBP) menu, which contains the same commands as options 2 and 3 on the current menu. The Change BOOTP Attributes (CHGBPA) command shown in Figure 2 is accessed through option 2 on the BOOTP Commands menu. This command allows you to set BOOTP to start automatically when TCP/IP is started. As shown in Figure 2, you can set the autostart value to *YES if you want to start BOOTP every time TCP/IP is started, to *SAME if you want to keep any previously set value, or to *NO if you’re not going to use BOOTP. (If you have DHCP set to autostart, you can’t also set BOOTP to autostart, since they are mutually exclusive.)

Option 3 on the BOOTP Commands menu executes the Work with BOOTP Table (WRKBPTBL) command. This is the most important and complex function you’ll have to deal with when configuring BOOTP. When you press option 3, a blank screen appears with the command at the top, and a message informs you that “No parameters to show; press Enter to run.…” Why OS/400 is designed like this is puzzling, but pressing Enter on this screen brings up the real Work with BOOTP Table panel shown in Figure 3. This display, which follows OS/400 menu standards, allows you to add, change, delete, or display entries in your BOOTP table. Normally, each NC on a network that uses the AS/400 as a host has one entry in the BOOTP table. If you add or remove an NC from your network, you add or remove the corresponding entry in the BOOTP table. Figure 4 shows the Add BOOTP Table Entry panel, which is accessed by typing 1 on the top line of the Work with BOOTP Table panel (Figure 3) and pressing Enter.

Here, you set the values that the NC with the corresponding MAC address will use at boot time:

• The client host name
• The NC’s MAC address in the form of nn.nn.nn.nn.nn.nn where n represents a hex number

• The IP address the NC will use on the network
• The hardware type: 1 for Ethernet, 6 for Token-Ring
• The gateway IP address of the network the client resides on
• A valid subnet mask for the network the client resides on

• The boot type that is used to determine the actual NC hardware type
• The name of the file the client will boot from
• The fully qualified path to the boot file The IBMNSM boot type and corresponding boot values shown in Figure 4 are used to configure the IBM Network Station. (NCs from other vendors use different boot values, but the other configuration values remain the same.) In this scenario, when the NC with a MAC address of 00.AC.E5.68.57.42 is turned on, it broadcasts its address to the AS/400, which responds with the NC’s IP address and other values. The user doesn’t need to know what the configuration values are or where they come from. The NC boots and configures itself.

Options 2, 4, and 5 of the Work with BOOTP Table display can be used to change, remove, or display BOOTP table entries respectively (oddly, there is no option 3 on this panel).

The Big Picture

The BOOTP table uses tags to identify client configuration values. Some tags identify mandatory entries that appear on the BOOTP table panel, and some tags identify optional values.

Figure 5 shows the default QATODBTP file supplied with OS/400. Each line of text represents one record in the file. At the bottom of the file, you can see the entry I added for MCRISC (it is normally on one line but was too long to show in that format). You can use the optional sa tag to specify which server on your network to use for downloading the OS to an NC, but for some reason, IBM does not include this option on the BOOTP table display. To add this tag to the QUSRSYS/QATODBTP file, use the Update Data (UPDDTA) command, and add the tag in the format sa=server (see reference book AS/400—IBM Network Station—Getting Started for details). Although you can use UPDDTA to maintain all the information in a BOOTP table, this technique bypasses the OS/400 error-checking facility and increases the chance of configuration errors. I suggest you use the OS/400 menu system to manipulate all tags except the sa option.

BOOTP is quite flexible and allows a variety of implementations. Large networks often have many servers of different hardware types. BOOTP is ideal for this type of network. Any server that recognizes the MAC address of an NC can answer a BOOTP request and provide the client with configuration values. The NC merely boots from the server that answers its request first. If you have more than one host at your site, you may want to split the BOOTP tables across two or more servers. This allows you to divide the boot process and interactive CPU usage across multiple hosts, equally distributing the use of resources. The use of multiple BOOTP hosts can also be advantageous in the case of a hardware failure. For instance, if you have your NCs split between two servers, half in one BOOTP table and half in another, you can also keep a BOOTP table that contains all the NC addresses on both servers in a renamed state. In the case of a server failure, you simply activate the complete BOOTP table on the functioning server and replace the partial table. When the hardware is repaired, just reactivate the partial table. A CL program can easily be written to take care of this situation (see reference book OS/400 CL Programming for details).

The Goal: Simplicity with Reliability

The goal of all administrators is to keep their users happy by giving them reliable equipment. Diskless workstations can enable user productivity while decreasing hardware costs. In the world of network computing, BOOTP can help give your users a reliable yet transparent network connection, allowing them to do their jobs efficiently with a minimum of network administration. The use of NCs can cut hardware expenses while BOOTP

services reduce the cost of networking personnel: a very attractive combination. As you’ve learned in this article, although BOOTP may appear intimidating at first, it is easy to set up on the AS/400 and very flexible in its implementation. While supplanted by DHCP in some shops, BOOTP’s proven track record, ease of use, and compatibility with a broad range of clients and hosts will keep this networking aid in the forefront of network computing for the next few years.

References AS/400 in Multiprotocol Networks, Redbook (SG24-4522-00, CD-ROM EZ30BZ00)

AS/400—IBM Network Station—Getting Started, Redbook (SG24-2153-00, CDROM SG242153)

Exploring the IBM Network Communications Suite, Redbook (SG24-2111-00, CD-ROM SG242153)

IBM Network Station Use V4R1 (SA41-0036-00, CD-ROM QBJADK00) LAN Concepts and Products: LAN Architecture, Redbook (SG24-4753-00, CDROM EZ331600)

LAN Concepts and Products: Routers and Gateways, Redbook (SG24-4755-00, CD-ROM EZ331800)

OS/400 CL Programming V4R2 (SC41-5721-01, CD-ROM QB3AUO01) OS/400 CL Reference V4R2 (SC41-5722-01, CD-ROM QB3AUP01) OS/400 TCP/IP Configuration and Reference V4R2 (SC41-5420-01, CD-ROM QB3ANL01)

TCP/IP Fastpath Setup V4R1 (SC41-5430-00, CD-ROM QB3A0K00)

Figure 1: BOOTP Commands menu

Figure 2: Change BOOTP Attributes command panel

Figure 4: Add BOOTP Table Entry panel

#**********************************************************************

# BOOTP database file format
# This data will reside in the file QATODBT
# member BOOTPTAB in library QSYS. This file is
# used as a default table if the file QATODBTP
# in library QUSRSYS does not exist.

#

# Legend:
#

# first field — client hostname
# (may be full domain name and probably should be)
#

# Following fields seperated by a “:” will contain the tags
# shown below followed by a string indicating the value of
# the parameter. There will be one entry per client and the
# maximum length of an entry is 1024 bytes.

#

# TAGS: The following tags will be supported by the BOOTP server.

# Most tags are optional but each client record must at a

# minimum have entries for the ‘ bf’, ‘bt’, ‘hd’, ‘ip’,

# ‘ht’, ‘ sm’ and ‘ha’ tags.

#

# NOTE1: The gateway (gw) tag is required if you are setting up

# to boot from a server that is not on the same subnet

# as the client. This is needed to tell the client how

# to find the path to the server.

# NOTE2: The hardware type tag (ht=) must appear in the record

# before the hardware address flag (ha=).

#

# bf — bootfile ( boot file name )
# bt — boot type (Terminal type and version tag ie. IBMNS3.7)
# gw — gateways
# ha — hardware address(i.e. MAC address)
# hd — home directory (Path to load file)

# ht — hardware type (1=ethernet etc. see RFC 1700 page 163)
# ip — host IP address
# sa — boot server
# sm — subnet mask
#*****************************************************************

# EXAMPLE Entry: (Must be all on one line up to 1024 characters long)
#

#host.dom:bt=IBMNSM:ht=:ha=:ip=xx.xx.xx.xx1:
# bf=kernel: hd=/QIBM/ProdData/NetworkStation:sm=255.255.255.0
#*****************************************************************

MCRISC:ip=200.210.50.3:bt=IBMNSM:ht=1:ha=00.AC.E5.68.57.42:sm=255.255.255.0:
gw=203.13.28.10:bf=kernel:hd=/QIBM/ProdData/NetworkStation/

Figure 5: The default BOOTP file: QATODBTP in QUSRSYS

Also Read

RPG Academy - Database Modernization: Entity Relationship Diagrams

RPG Academy - Database Modernization: A Bit of Database Theory

Talking About Modernization Isn’t Good Enough