If you want multiple OpenVMS Cluster nodes to share the same CLIENT.PCY file, and the nodes have identical interface names, a conflict will arise if you simply define TCPIP$DHCP_CONFIG to a common directory shared between the systems.

For example, if two systems in a cluster have an interface named SE0 that is under DHCP control, configure for this situation in the following way:

1. Define the system logical TCPIP$DHCP_CONFIG as a search list that points first to a system-specific directory that you create for the DHCP client and then to the common directory.
2. Place the CLIENT.PCY file in the common directory.
3. If you want, place the HOSTNAME file into the SYS$SPECIFIC: directory. The ifname.DHC files will be created in the SYS$SPECIFIC:[] directory. For completeness, you might want to make the default device and directory for the TCPIP$DHCP account the SYS$SPECIFIC:[] directory, too.

You can use the TCPIP$DHCP_SIGNAL utility to signal the DHCP client to:

• Translate utility logicals and read configuration files.
• Shut down the DHCP client.
• Dump the diagnostic state of the DHCP client to a file.

Table 9-5 shows the commands available with the TCPIP$DHCP_SIGNAL utility.

Table 9-5 DHCP Signal Commands

Command	Description
DHCPSIGHUP	Causes the ASCII configuration files to be read again and then translates the TCPIP$DHCP_DEBUG and TCPIP$DHCP_LOG_LEVEL logicals.
DHCPSIGTERM	Causes an orderly shutdown of DHCP client. Use this command cautiously, as active lease and timer information is lost when you signal the DHCP client to shutdown. As a consequence, when you again start up the DHCP client, the system could be running with an expired lease.
DHCPSIGUSR1	Causes diagnostic state information to be written to the TCPIP$DHCP_CLIENT_RUN.LOG file.

9.5 TCP/IP Management Commands

You can use TCP/IP management commands to:

• Temporarily put an interface under DHCP control.
• Permanently put an interface under DHCP control.

The TCP/IP command SET INTERFACE temporarily puts an interface under DHCP control. It does not make any change to the TCPIP$CONFIGURATION data base.

The format of the command is:

SET INTERFACE ifname/DHCP [/[NO]PRIMARY]

In this format, ifname is the name of the interface; for example, SE0.

You must enter the SET NOINTERFACE command on the interface before you enter the SET INTERFACE/DHCP command.

After you enter the SET INTERFACE/DHCP command, the interface receives a new IP address from the DHCP server, but the information stored in the TCPIP$CONFIGURATION.DAT file is unchanged. For example, if you issue the TCP/IP command SHOW CONFIGURATION INTERFACE for the interface you see the IP address you had set up for the interface before you temporarily configured the interface. In addition, when you stop and restart TCP/IP Services, the interface will have the previously assigned IP address.

Use the TCPIP$CONFIG.COM command procedure to place the interface permanently under DHCP control, or follow the procedure described in Section 9.5.2.

9.5.2 Permanently Configuring Interfaces

The TCP/IP command SET CONFIGURATION INTERFACE /DHCP configures an interface to be under DHCP control by adding or changing an entry in the TCPIP$CONFIGURATION database. After entering this command, every time TCPIP$STARTUP.COM is run the DHCP client is invoked to configure the interface.

The format of the command is:

SET CONFIGURATION INTERFACE ifname/DHCP [/[NO]PRIMARY]

In this format, ifname is the name of the interface; for example, SE0.

The optional qualifier /PRIMARY indicates that the interface is to be the primary DHCP client interface. (For a description of the DHCP client primary interface, see Section 9.1.1.) TCP/IP Services issues an error if one of the other interfaces has the primary designation.

/NOPRIMARY indicates that the interface is no longer to be marked as the primary DHCP client interface. Because a primary DHCP interface is not required, no error occurs if turning off this option leaves no primary DHCP interface.

Note that this command does not change the current run-time configuration of the interface. For any changes to the TCPIP$CONFIGURATION database to take effect, you must run restart TCP/IP Services, or enter the START COMMUNICATION/INITIALIZE command.

9.6 Using the SHOWDHC Utility

TCP/IP Services provides the SHOWDHC utility for displaying the contents of an interface parameter file.

The SHOWDHC utility displays data stored in an ifname.DHC file.

The format of the SHOWDHC utility command is as follows:

SHOWDHC filename

In this format, filename is the name of an ifname.DHC file.

The format of the SHOWDHC output is a single line in the format of the DHCPCAP. file. For more information about the format of the DHCPCAP. file, see Section 8.2.2.2. Example 9-2 shows typical output from the SHOWDHC utility.

Example 9-2 SHOWDHC Sample Output

$ SHOWDHC SE0.DHC se0.dhc: ht=1:ha=08.00.2b.2a.de.a8:sa=10.10.2.3:yi=10.10.2.101:sm=255.255.255.0:gw=10.10. 2.66:ds=10.10.2.11:ho=rufus:dn=lkg.dec.com:ba=10.10.2.255:lt=1200:sv=10.10.2.3: t1=600:t2=1050:

The Bootstrap Protocol (BOOTP) server answers network bootstrap requests from diskless workstations and other network devices such as routers, terminal servers, and network switching equipment. When it receives such a request, the BOOTP server looks up the client's address in the BOOTP database file.

The Trivial File Transfer Protocol (TFTP) handles the file transfer from a TFTP server to a diskless client or other remote system. The client initiates the file transfer. TFTP is described in Chapter 11.

Because BOOTP is a subset of DHCP, you cannot enable both BOOTP and DHCP on the same host.

This chapter reviews key concepts and describes:

• How to plan for configuring BOOTP ( Section 10.2)
• How to configure the BOOTP service ( Section 10.3)
• How to manage the BOOTP service ( Section 10.4)
• Create the BOOTP database and populate it with client entries ( Section 10.5)
• Solve BOOTP problems ( Section 10.6)

The BOOTP server answers client requests for diskless client configuration by sending address and file name information to the client. When the client receives this information from the BOOTP server, it initiates a file transfer using the TFTP protocol.

The BOOTP server performs the following steps to accomplish a bootstrap:

1. The BOOTP server receives a configuration request from a client. A broadcast request goes out to all potential servers on the subnetwork or is directed to a predetermined known server address.
2. The BOOTP server reads information in the BOOTP database to get information about the client. The identity of the client is based on the network hardware address contained in the request.
3. BOOTP identifies the network client.
4. BOOTP constructs a response that contains all of the information in the BOOTP database for that client. The client information in the database includes:
   • Client's IP address
   • Client's host name (usually)
   • Name and size of the client's system load file
   • IP address of the TFTP server storing this file
   • IP addresses of the hosts offering common network services, such as a log server or a print (LPD) server
5. When the client receives the configuration information in the BOOTP response, it sends a request to the TFTP server host named in the response. This request is necessary only if the client must retrieve the load file.
6. If the client sends a read request (RRQ) to the TFTP server, the TFTP server attempts to locate this file. If it finds the file, the server transfers it to the client.

When planning BOOTP, you need to make decisions about the network configuration and the local BOOTP service.

10.2.1 Network Configuration Decisions

Before you start to set up BOOTP, answer the following questions:

• What clients will access the BOOTP server? For each client, obtain the following information:
  • System image and location from where it can be copied
  • Additional information requested
  • Hardware address
  • IP address
• What hosts in your network will run the BOOTP server?
• Will gateways be used for downloading? Gateways let you specify a specific path for the data transfer.
• Do you want to limit client access to specific server directories?

Before you start to configure BOOTP, consider the following:

• Default priority for the TCPIP$BOOTP server account in the user authorization file (UAF)
  For optimal performance, use the default priority level for the TCPIP$BOOTP user account.
  In a large or active subnetwork, clients might generate several broadcast requests per minute. The server continues to process all incoming requests, even those for which it lacks information in its database.
  In most cases, all this processing does not create system performance problems. However, it does use, perhaps unnecessarily, system resources. A different network configuration might avoid wasted system overhead.
• Segmented subnetworks
  To reduce large volumes of BOOTP request traffic to a specific server, segment very large subnetworks with filtering bridges.
  If you configure multiple servers, each server competes to provide the requested configuration information. For efficient use of each server, partition the database with a subset of the overall client population designated to each server.
• Separate directory for each client
  To avoid writing over the same file name with configuration information from multiple clients, create a separate subdirectory for each client in the TCPIP$TFTP_ROOT directory tree.
  Some BOOTP clients, such as routers and terminal servers, can store configuration options on the BOOTP server host. In a network with two or more of these clients, the clients can use the same file name to store the configuration information with TFTP.
• Security needs
  Identify your system's security needs (see Section 10.2.3).

For security purposes, the server runs as an unprivileged image that can access only the directories and files for which it has read access.

HP recommends that you safeguard your system's normal file protection mechanisms from unauthorized access. In particular, ensure the security of system files.

The BOOTP server runs as the nonprivileged OpenVMS user account TCPIP$BOOTP. When you set up BOOTP, follow these security procedures:

• Ensure that neither server has automatic access to any files.
  To make files accessible to the BOOTP server, grant appropriate access to its account. Use the normal OpenVMS file protection procedures. To display the current file protection settings on a directory, enter the DCL command DIRECTORY/SECURITY.
• Prevent unauthorized access to sensitive system or user data. Before you enable BOOTP, ensure that you have set up all the necessary file protections.
• Give the TCPIP$BOOTP user account read access to the files in the TCPIP$TFTP_ROOT: directory tree that might be used for downloading.
• Some clients first send a BOOTP request for the name of the file that they need downloaded. On receipt, BOOTP opens the file for read access and retrieves its size. BOOTP needs access to confirm that the file exists and to provide the size of the file to the client in the BOOTP response.
  Ensure that BOOTP has access to this file.

To set up the BOOTP server software, run TCPIP$CONFIG (see the HP TCP/IP Services for OpenVMS Installation and Configuration manual).

The procedure creates:

• BOOTP user account
• Service records in the services database
• Default directories
• Empty TCPIP$BOOTP database file

The following sections describe how to manage the BOOTP service.

10.4.1 Enabling and Disabling BOOTP

To enable and disable BOOTP, use these commands:

• On the running system:
  • ENABLE SERVICE BOOTP
  • DISABLE SERVICE BOOTP
• In the configuration database:
  • SET CONFIGURATION ENABLE SERVICE BOOTP
  • SET CONFIGURATION ENABLE NOSERVICE BOOTP

To check whether these services are enabled or disabled, enter the following commands:

• SHOW SERVICE BOOTP
• SHOW CONFIGURATION ENABLE SERVICE BOOTP

The following examples show how to use the SHOW SERVICE command to get information about BOOTP.

1. To display information about the BOOTP server processes, enter the SHOW SERVICE command. For example:

   TCPIP> SHOW SERVICE BOOTP Service Port Proto Process Address State BOOTP 67 UDP TCPIP$BOOTP 0.0.0.0 Enabled

2. To display BOOTP service settings and statistics, include the /FULL qualifier. For example:

   TCPIP> SHOW SERVICE BOOTP /FULL Service: BOOTP State: Enabled Port: 67 Protocol: UDP Address: 0.0.0.0 Inactivity: 5 User_name: TCPIP$BOOTP Process: TCPIP$BOOTP Limit: 1 Active: 1 Peak: 1 File: TCPIP$SYSTEM:TCPIP$BOOTP_RUN.COM Flags: Listen Socket Opts: Rcheck Scheck Receive: 0 Send: 0 Log Opts: Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimeO Addr File: SYS$SYSDEVICE:[TCPIP$BOOTP]TCPIP$BOOTP_RUN.LOG Security Reject msg: not defined Accept host: 0.0.0.0 Accept netw: 0.0.0.0

Table 10-1 summarizes the BOOTP management commands.

Table 10-1 BOOTP Management Commands

Command	Function
CONVERT/VMS BOOTP	Populates an existing BOOTP database with entries from a UNIX /etc/bootptab file.
CREATE BOOTP	Creates an empty BOOTP database.
SET BOOTP	Adds or modifies client entries to the BOOTP database.
SHOW BOOTP	Displays client information from the BOOTP database.
ENABLE SERVICE BOOTP	Dynamically enables the BOOTP service.
DISABLE SERVICE BOOTP	Dynamically disables the BOOTP service.
SET CONFIGURATION ENABLE SERVICE BOOTP
	Sets the configuration database to enable BOOTP at product startup.
SET CONFIGURATION DISABLE SERVICE BOOTP
	Sets the configuration database to disable BOOTP at product startup.
SET SERVICE BOOTP	Configures the BOOTP service in the services database.
SET NOSERVICE BOOTP	Disables the BOOTP service in the configuration database.
SHOW SERVICE BOOTP	Displays BOOTP server information stored in the services database.

10.4.3 BOOTP Logical Names

Table 10-2 lists the logical names you can use to manage the BOOTP software.

Table 10-2 BOOTP and TFTP Logical Names

Name	Function
TCPIP$BOOTP	Points to the location of the BOOTP database file.
TCPIP$TFTP_ROOT	Defines a concealed device. Points to the TFTP data storage tree, for example, SYS$SYSDEVICE:[TCPIP$TFTP_ROOT.].
TCPIP$BOOTP_TRACE	Displays the client hardware address for every incoming BOOTP request and response to requests.

10.4.4 BOOTP Startup and Shutdown

The BOOTP service can be shut down and started independently. This is useful when you change parameters or logical names that require the service to be restarted. The following files are provided:

• SYS$STARTUP:TCPIP$BOOTP_STARTUP.COM allows you to start up BOOTP.
• SYS$STARTUP:TCPIP$BOOTP_SHUTDOWN.COM allows you to shut down BOOTP.

To preserve site-specific parameter settings and commands, you can create the following files. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$BOOTP_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when BOOTP is started.
• SYS$STARTUP:TCPIP$BOOTP_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when BOOTP is shut down.

If you choose to configure BOOTP while configuring TCP/IP Services, TCPIP$CONFIG creates an empty BOOTP database.

If you need to create it manually, use the TCP/IP management command CREATE BOOTP. This command creates the file SYS$SYSTEM:TCPIP$BOOTP.DAT. The command uses the logical name TCPIP$BOOTP to point to the BOOTP database file. To create a separate database, perhaps in a different disk directory or with a different file name, modify this logical name.

To create a temporary, separate, and empty BOOTP file, you can use a process-specific logical name. However, HP does not recommend creating separate or private BOOTP databases because the TCPIP$BOOTP user account requires read access to the database file.

10.5.1 Populating the BOOTP Database

For each BOOTP client in the BOOTP database, use the SET BOOTP command to enter the following required information:

• Client's hardware address (required).
• Either the client's name or IP address (required).
• Network mask (required).
• Client's system image file name (required).
• Interim gateway (routing) systems.
• Either the name or IP address of other network servers. Some of the optional servers that you can specify are:
  • Cookie servers
  • IEN-116 name servers
  • IMPRESS network image servers
  • LPR print servers
  • MIT-LCS UDP logging servers
  • DNS (BIND) name servers
  • Resource location (RLP) servers
  • Network time servers

To populate the BOOTP database with client entries, use these commands:

• CONVERT/VMS BOOTP (adds UNIX client records; see Section 10.5.2))
• SET BOOTP (adds individual client records; see Section 10.5.3)

You can use the BOOTP client information in an existing UNIX boot file. The CONVERT/VMS BOOTP command populates the existing BOOTP database with entries from a BIND formatted UNIX /etc/bootptab file.

Before you enter CONVERT/VMS BOOTP, define the logical name TCPIP$BOOTP. The CONVERT/VMS BOOTP command uses it to determine the directory and file name for the database. Enter the following command:

$ DEFINE /SYSTEM TCPIP$BOOTP SYS$COMMON:[SYSEXE]TCPIP$BOOTP.DAT

If you do not define TCPIP$BOOTP, the database is created as [current_directory]TCPIP$BOOTP.DAT.

To populate the BOOTP database by using entries in a UNIX /etc/bootptab file, follow these steps:

1. Copy the /etc/bootptab file to your system.
2. Edit the output file. Examine the directory path for each client entry. Modify the UNIX path names to OpenVMS specifications. For example, change:

   :hd=/usr/apple/orange/bootptab:

   
   to

   :hd="DISK_BIRD2$:[USR.APPLE.ORANGE]BOOTPTAB.DAT":

   
   Note that this is a UNIX file and is not compatible with OpenVMS.

3. Enter the CONVERT command as follows:

   TCPIP> CONVERT /VMS BOOTP

   
   The command reads the entries in your edited output file and adds them to the BOOTP database. If it finds an existing record for a client with a converted record, and if the information differs, the command updates the existing record with the newer data.

The CONVERT/VMS BOOTP command has the following format:

CONVERT/VMS BOOTP source_file /ADD_HOST /FILE=sys_image_file

In this command format:

• source_file
  Specifies the name of the file you edited (the output from the COPY command). The default is ETC.BOOTPTAB.
• /ADD_HOST
  Adds client entries that are new to your system to the hosts database. The default is not to add client entries to the hosts database.
• /FILE=sys_image_file
  Specifies the download file. Use this parameter if you are adding new clients to the BOOTP database. All these new clients have the same download file.