12
Wed, Jun
4 New Articles

Automate TCP/IP Addressing with BOOTP

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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



Automate_TCP-_IP_Addressing_with_BOOTP06-00.png 904x604





Automate_TCP-_IP_Addressing_with_BOOTP06-01.png 904x604

Figure 2: Change BOOTP Attributes command panel


 Figure 3: Work with BOOTP Table panel





Automate_TCP-_IP_Addressing_with_BOOTP07-00.png 904x604





Automate_TCP-_IP_Addressing_with_BOOTP08-00.png 904x604

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

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$0.00 Raised:
$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: