Cisco CNS Network Registrar User's Guide, 6.0
Configuring BOOTP
Downloads: This chapterpdf (PDF - 175.0 KB) The complete bookPDF (PDF - 7.06 MB) | Feedback

Configuring BOOTP

Table Of Contents

Configuring BOOTP


Enabling BOOTP for a Scope

Moving or Decommissioning a BOOTP Client

Using Dynamic BOOTP

Configuring BOOTP

BOOTP (the BOOTstrap Protocol) was originally created for loading diskless computers. It was later used to allow a host to obtain all the required TCP/IP information to use the Internet. Using BOOTP, a host can broadcast a request on the network and get information required from a BOOTP server. The BOOTP server is a computer that listens for incoming BOOTP requests and generates responses from a configuration database for the BOOTP clients on that network. BOOTP differs from DHCP in that it has no concept of lease or lease expiration. All IP addresses that a BOOTP server allocates are permanent.

You can configure Cisco CNS Network Registrar to act like a BOOTP server. In addition, although BOOTP normally requires static address assignments, you can choose to either reserve IP addresses (and, therefore, use static assignments) or have IP addresses dynamically allocated for BOOTP clients.

Table 12-1 lists the BOOTP configuration tasks described in this chapter and the sections where you can find more information about them. The Network Registrar Web UI Guide explains how to accomplish these tasks using the Web-based interface.

Table 12-1 BOOTP Configuration Topics

If you want to...

Know more about the Network Registrar DHCP server BOOTP support

"About BOOTP" section

Know more about how Network Registrar configures BOOTP packets

"Enabling BOOTP for a Scope" section

Move or decommission a BOOTP client

"Moving or Decommissioning a BOOTP Client" section

Use dynamic BOOTP

"Using Dynamic BOOTP" section


When you configure the DHCP server to return a BOOTP packet, be aware that BOOTP requires information in the DHCP packet in fields other than the option space. BOOTP devices often need information in the bootfile (file), server's IP address (siaddr), and server's host name (sname) fields of the DHCP packet (see RFC 2131).

Every Network Registrar DHCP policy has fields where you can configure the information you want returned directly in the file, siaddr, or sname fields. The Network Registrar DHCP server also supports a configuration parameter with which you can configure the policy options and determine which of the file, sname, or siaddr values you want returned to the BOOTP device.

Network Registrar supports an analogous configuration parameter with which you can configure the options and file, sname, or siaddr values you want returned to the DHCP client. This is in addition to any options requested by the DHCP clients in the dhcp-parameter-request option in the DHCP request. Thus, you can configure both the BOOTP and DHCP response packets appropriately for your devices.

Step 1 Decide the values that you want in the BOOTP packet reply fields:

file—Name of the bootfile

siaddr—Server's IP address

sname—Optional server host name

Step 2 Decide the list of options and their values that you want returned to the BOOTP client.

Step 3 Set these values in the policy you want associated with the BOOTP request:

Fields—Packet-siaddr, packet-file-name, packet-server-name to send to the BOOTP client.

Option values, such as the server addresses and domain name to return to the BOOTP client.

List of fields and options you want returned to the BOOTP client.

Step 4 Enable the associated scope or scopes for BOOTP processing.

Step 5 Enable dynamic BOOTP processing if you want to have this scope provide an address for any BOOTP client that requests one. If you do not enable dynamic BOOTP, you must make reservations for each BOOTP client for which you want this scope to provide an address.

Enabling BOOTP for a Scope

You can enable BOOTP processing for a scope.

Using the Web UI or CLI

Set certain attributes and BOOTP reply options for a created policy in the Web UI, or use the policy name create and policy name set commands in the CLI, to configure BOOTP. Set the policy attributes and options as a comma-separated list. The attributes are entities to use in a client's boot process:

packet-siaddr—IP address of the next server

packet-file-name—Name of the boot file

packet-server-name—Host name of the server

In the CLI:

nrcmd> policy policyPC create packet-siaddr= packet-file-name=mybootfile.bin 
100 Ok
allow-client-a-record-update = disabled
allow-dual-zone-dns-update = [default=disabled]
allow-lease-time-override = enabled

The server looks through the bootp-reply-options list to find any matches for these attributes. In the Web UI, click the options in the BOOTP Compatible section of the Options drop-down list. The options are the same as in the CLI:

nrcmd> policy policyPC set 
100 Ok

After setting attributes, set the correct option values. In the Web UI, click and set the options from the Options drop-down list and in the attributes. In the CLI, the policy name setOption command requires spaces (not equal signs) before values. Also, enable BOOTP and dynamic BOOTP, if desired, and ensure that the DHCP server updates the DNS server with BOOTP requests. The options are:

nrcmd> policy policyPC setOption dhcp-lease-time 604800 
100 Ok
nrcmd> scope examplescope1 enable bootp 
100 Ok
nrcmd> scope examplescope1 enable dynamic-bootp 
100 Ok
nrcmd> dhcp enable update-dns-for-bootp 
100 Ok
nrcmd> scope examplescope1 enable update-dns-for-bootp 
100 Ok

Using the GUI

Step 1 In the Policies tab of the DHCP Server Properties dialog box, configure a packet to contain the information that BOOTP requires.

Step 2 In the Edit Options dialog box, select the options you want.

Step 3 Click the Send to BOOTP clients check box.

Step 4 If you check the Always send to DHCP clients box, the DHCP server sends an option back in the DHCP reply packet regardless of whether the client requested the option.

Step 5 Click OK.

Step 6 In the Advanced tab of the DHCP Scope Properties dialog box, select the Enable BOOTP check box.

Step 7 If you want dynamic IP address assignment, select the check box, otherwise create reservations. (For details on making reservations, see the "Reserving a Lease" section.)

Step 8 Click OK.

Step 9 Reload the DHCP server.

Moving or Decommissioning a BOOTP Client

When you move or decommission a BOOTP client, you can reuse its lease. To decommission a BOOTP client, you must remove its lease reservation from the scope and force its lease to be available.

Using the Web UI or CLI

Force the lease available in the Web UI, or set the Use the scope name removeReservation and lease ipaddr force-available commands in the CLI.

nrcmd> scope examplescope1 removeReservation 
100 Ok
nrcmd> lease force-available 
100 Ok

Using the GUI

Step 1 From the Server Manager window, choose the scope for which you want to move or decommission a BOOTP client.

Step 2 On the Leases tab, choose the de-activated lease that you want to re-activate.

Step 3 Click Lease Properties (or double-click the lease) to open the Lease Properties dialog box.

Step 4 Click Force available.

Step 5 Uncheck the Deactivate lease box.

Step 6 Click OK.

Step 7 Click Refresh list.

Step 8 O n the Reservations tab, choose the reserved BOOT client lease, then click Remove.

Step 9 Click OK.

Using Dynamic BOOTP

When you use dynamic BOOTP, there are additional restrictions placed on the address usage in such scopes, because BOOTP clients are allocated IP addresses permanently and receive leases that never expire.

If you are using DHCP failover, when a server whose scope does not have the dynamic-bootp option enabled goes into PARTNER-DOWN state, it can allocate any available IP address from that scope, no matter whether it was initially available to the main or backup server. However, when the dynamic-bootp option is enabled, the main server and backup servers can only allocate their own addresses. Consequently scopes that enable the dynamic-bootp option require more addresses to support failover.

Using the Web UI or CLI

When using dynamic BOOTP:

1. Segregate dynamic BOOTP clients to a single scope. Disable DHCP clients from using that scope. In the Web UI, under the BOOTP attributes for the scope, disable the dhcp attribute. In the CLI, use the scope name disable dhcp command.

2. If you are using DHCP failover, set the failover-dynamic-bootp-backup-percentage attribute for the DHCP server to allocate a greater percentage of addresses to the backup server for this scope. This percentage can be as much as 50 percent higher than a regular backup percentage.