Cisco CNS Network Registrar User's Guide, 5.5
Configuring DHCP Servers
Downloads: This chapterpdf (PDF - 360.0KB) The complete bookPDF (PDF - 5.45MB) | Feedback

Configuring DHCP Servers

Table Of Contents

Configuring DHCP Servers

Configuring a DHCP Server

General Configuration Guidelines

DHCP Server Properties in the GUI

Choosing the Server Interface

Configuring Server Policies

Types of Policies

Creating a Policy

Adding DHCP Options for the Policy

Supporting Vendor-Specific DHCP Options

Editing a Policy

Defining Advanced Server Parameters

Setting Advanced DHCP Server Parameters

Configuring Custom DHCP Options

Adding a Custom Option

Editing and Removing a Custom Option

Configuring Multiple Servers and BOOTP Relay

Configuring a Second DHCP Server

Configuring a BOOTP Relay Router

DHCP Forwarding

Integrating Windows System Management Server

Using Extensions to Affect DHCP Server Behavior

Troubleshooting DHCP Servers


Configuring DHCP Servers


The Dynamic Host Configuration Protocol (DHCP) is an industry-standard protocol for automatically assigning IP configuration to workstations. DHCP uses a client/server model for address allocation. As administrator, you can configure one or more DHCP servers to provide IP address assignment and other TCP/IP-oriented configuration information to your workstations. DHCP frees you from having to manually assign an IP address to each client. The DHCP protocol is described in RFC 2131.

This chapter describes how to set up a DHCP server and its policies. Before clients can use DHCP for address assignment, you must add at least one scope (dynamic address pool) to the server. This is described in "Configuring DHCP Scopes and Leases."

Table 7-1 lists the topics found in this chapter and their associated sections.

Table 7-1 DHCP Server Configuration Topics 

If you want to...
Go to the...

Learn about DHCP and how Network Registrar implements it

"Dynamic Host Configuration Protocol" section

Configure the general properties of a DHCP server

"Configuring a DHCP Server" section

Configure policies for the server

"Configuring Server Policies" section

Configure DHCP options for the policy

"Adding DHCP Options for the Policy" section

Support vendor-specific DHCP options

"Supporting Vendor-Specific DHCP Options" section

Set advanced server parameters, such as custom DHCP options

"Defining Advanced Server Parameters" section

Configure a second DHCP server and a router for BOOTP Relay

"Configuring Multiple Servers and BOOTP Relay" section

Configure DHCP forwarding

"DHCP Forwarding" section

Integrating Windows System Management Server (SMS) with DHCP

"Integrating Windows System Management Server" section

Using extension scripts to affect server behavior

"Using Extensions to Affect DHCP Server Behavior" section

Troubleshoot DHCP servers

"Troubleshooting DHCP Servers" section


Configuring a DHCP Server

When configuring a DHCP server, you must configure the server properties, policies, and associated DHCP options. Network Registrar needs the following information:

The DHCP server's IP address

One or more policies, to specify, at a minimum, the lease times for the addresses—See "Configuring Server Policies" section

One or more scopes—See "Configuring DHCP Scopes and Leases"

General Configuration Guidelines

Here are some guidelines to consider before configuring a DHCP server:

Separate the DHCP server from secondary DNS servers used for DNS updating—Because writing a full zone to disk can take some time, performance can be slow when a DHCP server transfers large zones to a secondary DNS server. To ensure that the DHCP server is not adversely affected during large zone transfers, it should run on a different cluster than your secondary DNS servers.

Configure a separate DHCP server to run in remote segments of the wide area network (WAN)—Ensure that the DHCP client can consistently send a packet to the server in under a second. The DHCP protocol dictates that the client receive a response to a DHCPDISCOVER or DHCPREQUEST packet within four seconds of transmission. Many clients, notably early releases of the Microsoft DHCP stack, actually implement a two-second timeout.

Set DHCP lease times in a policy to about four to ten days—To prevent leases from expiring when the DHCP client is turned off, overnight or over long weekends, set the DHCP lease time longer than the longest period of expected downtime. A lease time of ten days should be sufficient. See the "Creating a Policy" section.

DHCP Server Properties in the GUI

The DHCP Server Properties dialog box of the GUI includes tabs that relate to configuring the DHCP server. These tabs and where they are described in this user's guide are defined in Table 7-2.

Table 7-2 DHCP Server Properties in the GUI 

This tab...
Configures...
Is described in...

General

Internal name and network interface of the DHCP server

"Choosing the Server Interface" section

Policies

Policies defined at the server level, including associated lease times and DHCP options

"Configuring Server Policies" section

Advanced DNS

Properties related to the DHCP server's communication with a DNS server for dynamic updates

"Configuring Dynamic DNS Update"

Scope Selection Tags

Client-classing scope selection tags

"Configuring Clients and Client-Classes"

Client Classes

Client classes for the DHCP server

"Configuring Clients and Client-Classes"

Clients

Client definitions for client-classing

"Configuring Clients and Client-Classes"

Advanced

Advanced server settings, including custom DHCP options

"Defining Advanced Server Parameters" section


Choosing the Server Interface

To configure the DHCP server, accept Network Registrar's defaults or supply the data explicitly:

Network interface—Ethernet card IP address, which must be static and not assigned by DHCP.

Subnet mask—Identifies the interface's network membership. The subnet mask is usually based on the network class of the interface address, in most cases 255.255.255.0.


Tip Network Registrar uses the default interface to provide configurable default values for interfaces that the DHCP server discovers automatically. Be careful not to delete this default interface.

If you enable automatic interface discovery, the DHCP server uses the operating system support to enumerate the active interfaces on the machine and tries to listen on all of them. The server otherwise listens only on the interface you specify, as long as it does not have the ignore attribute set to true.


Using the CLI


Step 1 Use the dhcp-interface command to manage your network interface cards' IP addresses. By default, the DHCP server uses all your server's network interfaces, so use this command to be more specific about which ones to use. In Network Registrar, the interface name syntax is the IP address and subnet mask with the /n suffix, reflecting the number of bits of the network part of the address. For example, a subnet mask in IP format 255.255.255.0 translates into a suffix of /24 (24 bits of network address); the IP mask 255.255.255.192 translates into a subnet mask suffix of /26, and so on. Be sure that both the address and subnet mask are accurate. Check using a utility like ipconfig in Windows or ifconfig in UNIX.

Step 2 Network Registrar uses the distinguished interface named default to provide configurable default values for interfaces that the DHCP server discovers automatically. Use the dhcp-interface default show command to view the default interface properties. In most cases, you would use a dhcp-interface ipaddr create command to create a secondary interface for the host.

nrcmd> dhcp-interface 192.168.41.3/24 create 

Step 3 You can delete the interface. If you delete the default interface, the DHCP server uses hardcoded default values for port numbers and socket buffer sizes for the interfaces that it autodiscovers. You can also show and list interfaces, and unset or reset the address and mask values of a nondefault interface.

nrcmd> dhcp-interface 192.168.41.3/24 show 
nrcmd> dhcp-interface list 
nrcmd> dhcp-interface 192.168.41.3/24 set addr=192.168.41.4 
nrcmd> dhcp-interface 192.168.41.4/24 set mask=255.255.255.192 
100 Ok
192.168.41.3/26:
    addr = 192.168.41.3
    ignore =
    mask = 255.255.255.192

Step 4 By default, Network Registrar discovers the interfaces on your server automatically. To disable this attribute, use the dhcp disable discover-interfaces command. To have the DHCP server temporarily ignore an interface in a list of defined ones, use the dhcp-interface ipaddr set ignore=true command. If you enable the discover-interfaces attribute, the DHCP server consults the interface list for all defined interfaces with the ignore attribute set to false, and tries to listen on each of them.

nrcmd> dhcp-interface 192.168.41.3/24 set ignore=false 
100 Ok
ignore=disabled


Using the GUI


Step 1 In the Server Manager window, double-click the DHCP server you want to configure. This opens the DHCP Server Properties dialog box. The General tab should be active (Figure 7-1).

Figure 7-1 General Tab (DHCP Server Properties Dialog Box)

Step 2 The Name field identifies the internal (but not necessarily the official) name of the DHCP server. You can change this name without affecting how the server functions. Network Registrar actually uses the server's IP address for official name lookups and dynamic DNS updating.

The dialog box also identifies the cluster the server is on and the DHCP server software version. You cannot change these values in the dialog box.

Step 3 Decide if you want Network Registrar to discover the interface cards on the server host, known as network interface cards (NICs) on Ethernet and Token Ring networks:

If you choose the Discover interfaces button, the DHCP server finds all the interface cards on the host and processes DHCP requests that it receives from any of them. However, it only offers addresses to requests from subnets for which you define a valid scope with available addresses.

Choose the Use interface button only if you want Network Registrar to use one interface address in a multihomed system. If you check this option, you must also enter the address and network mask of the interface.


Configuring Server Policies

Every DHCP server must have one or more policies defined for it. Policies define lease duration, gateway routers, and other configuration parameters, in what are called DHCP options. Policies are especially useful if you have multiple scopes, because you need only define a policy once and apply it to the multiple scopes.

You can define named policies with specific option definitions or you can use system defaults. This section describes how to configure a policy both ways.

Types of Policies

There are three types of policies—system default, user-defined, and embedded:

System default (system_default_policy)—Provides a single location for setting default values on certain options for all scopes. Use the system default policy for scopes that you want to define with standard DHCP option values. You can modify the system default options and their values, but you cannot delete the policy using the GUI. If you delete a system default policy, it re-appears using its original list of options and their system-defined values (see Table 7-3). These options are visible when using the policy name listOptions command in the CLI, and in the GUI on the Policies tab of the DHCP server properties dialog box.

Table 7-3 System Default Policy Option Values 

This system default option...
Has the predefined value...

all-subnets-local

False

arp-cache-timeout

60 seconds

broadcast-address

255.255.255.255

default-ip-ttl

64

default-tcp-ttl

64

dhcp-lease-time

604800 seconds (7d)

ieee802.3-encapsulation

False

interface-mtu

576 bytes

mask-supplier

False

max-dgram-reassembly

576 bytes

non-local-source-routing

False

path-mtu-aging-timeout

6000 seconds

path-mtu-plateau-tables

68, 296, 508, 1006, 1492, 2002, 4352, 8166, 17914, 32000

perform-mask-discovery

False

router-discovery

True

router-solicitation-address

224.0.0.2

tcp-keepalive-garbage

False

tcp-keepalive-interval

0 seconds

trailer-encapsulation

False


User-defined—Policies you explicitly define by name or assign the default policy. The default policy contains only one option by default, dhcp-lease-time, which has the same default value as in the system_default_policy (see Table 7-3). User-defined policies are usually object-specific and named after their associated scope or client grouping. They are usually assigned options that are unique to a subnet, such as for its routers. These options are visible in the GUI on the Policies tab of the DHCP server properties dialog box, and on a session visibility 3 or lower level in the CLI.

Embedded—A policy embedded in (and limited to) a named scope, client, or client-class. An embedded policy is implicitly created (or removed) when you add (or remove) the corresponding object, such as a scope. However, the embedded policy options have no default values and are initially undefined. Managing embedded policies is available through the CLI only. See the "Configuring an Embedded Policy for the Scope" section.

To eliminate any conflicting option values set at these various levels, the Network Registrar DHCP server uses a local priority method. It picks up the more locally defined option values first, ignores the ones defined on a more global level, and includes any default ones not otherwise defined. Before returning option values to a DHCP client, the server prioritizes the option values in the following order:

1. Client embedded policy

2. Client assigned policy

3. Client-class embedded policy

4. Client-class assigned policy

5. Scope embedded policy for clients, or address block embedded policy for subnets

6. Scope assigned policy for clients, or address block assigned policy for subnets

7. System default policy

Creating a Policy

This section describes how to create a policy at the DHCP server level and then allow a specific scope or scopes to reference it. A policy can consist of the following components:

Name—Must be unique, even if the character case is different.

Permanent lease option—A permanent lease never expires.

Lease time—How long a client can use an assigned lease before having to renew the lease with the DHCP server (not available for an embedded policy). The default lease time for both system default and default policies is seven days (604800 seconds).

Lease grace period—Time period after the lease expires that it is unavailable for re-assignment (not available for an embedded policy).

DHCP options and their defined values—See "DHCP Options"

Using the CLI


Step 1 Use the policy name create command to create the policy and the policy set attribute command to set the lease options (in this example, the lease grace period). Policy names are case-insensitive.

nrcmd> policy policyPC create grace-period=1D 

Step 2 To set permanent leases for the policy, use the policy name enable permanent-leases command.

nrcmd> policy policyPC enable permanent-leases 

Step 3 To set the policy's domain name, name server, and routers, use the policy name setOption command.

nrcmd> policy policyPC set0ption domain-name example.com. 
nrcmd> policy policyPC set0ption domain-name-servers 192.168.40.2 
nrcmd> policy policyPC set0ption routers 192.168.40.1 

Step 4 To set the policy's lease time, use the policy name setLeaseTime command. To verify it, use the policy name listOptions, or policy name getOption dhcp-lease-time, command.

nrcmd> policy policyPC setLeaseTime 3600m 
nrcmd> policy policyPC listOptions 
100 Ok
<51>dhcp-lease-time: 604800

Step 5 To set the subnet mask, you have to use a combination of the policy name setOption subnet-mask command and the dhcp enable get-subnet-mask-from-policy command. To remove the subnet mask from the policy, either unset the attribute or disable it. Finally, reload the DHCP server.

nrcmd> policy policyPC setOption subnet-mask 255.255.255.0 
nrcmd> dhcp enable get-subnet-mask-from-policy 
nrcmd> dhcp unset get-subnet-mask-from-policy 
nrcmd> dhcp disable get-subnet-mask-from-policy 
nrcmd> dhcp reload 


Using the GUI


Step 1 In the DHCP Server Properties dialog box for a selected server, click the Policies tab (Figure 7-2).

Figure 7-2 Policies Tab (DHCP Server Properties Dialog Box)

Step 2 The name that appears in the Policy field is the one you are currently configuring. The Policy field initially appears with the word default in it. If there are other policies defined, you can choose one from the scroll-down list. This then becomes the one you are configuring.

You can edit an existing default policy or you can create a named one. In most cases, you would want to leave the defaults alone and create named policies, especially if you want to associate them with particular scopes and clients. (You can always base a named policy on an existing one.)

To create a new policy, click New to open the New Policy dialog box (Figure 7-3).

Figure 7-3 New Policy Dialog Box (from Policies Tab of DHCP Properties Dialog Box)

Step 3 In the Name field, enter the new policy's name; for example, policyPC. Policy names are case-insensitive, so that policyPC is the same as policypc.

Step 4 In the "Copy from" field, either:

Choose an existing policy on which to base your new one. You can choose default, system_default_policy, or an existing one.

Choose <None> when you do no want to base the new policy on any existing one. This policy has no preset properties or options; you have to specify them from scratch.

Step 5 Click OK.

Step 6 On the Policies tab, choose whether you want the leases to be permanent (never expire), or have a specified duration (lease time). In most cases, you would uncheck the "Leases are permanent" box.

If setting nonpermanent leases, set the duration of the lease in the "Lease time" fields. The default in most cases is seven days. For guidance, see the "Guidelines for Lease Times" section.

For nonpermanent leases, also set the duration of the lease grace period in the "Grace period" fields. This is how long the lease remains in the DHCP server's database after it expires. This grace period protects a client's lease when the client and server are in different time zones, their clocks are not synchronized, or the client was off the network when the lease expired. The lease grace period is usually five minutes.


Adding DHCP Options for the Policy

DHCP options supply configuration parameters automatically to DHCP clients, such as their domain, and their name server and subnet router addresses. See "DHCP Options."

You can view, set, unset, and edit individual option values. When you set an option value, the DHCP server replaces any existing value or creates a new one, as needed for the given option name. Network Registrar DHCP options are grouped into categories to aid you in identifying options that you must set in various usage contexts. Table B-11 describes the categories. You can also create custom options. The "Adding a Custom Option" section describes these options.

Using the CLI

You can view option values with the policy name getOption, and policy name listOptions commands, set them with the policy name setOption command, and unset them with the policy name unsetOption command. When you set an option value, the DHCP server replaces any existing value or creates a new one, as needed, for the given option name. For a list of the options, use the help dhcp-option command.

nrcmd> policy policyPC setOption dhcp-lease-time 3600 


Tip The policy name setOption command requires a space, not an equal sign, before the attribute value.


Using the GUI


Step 1 On the Policies tab (Figure 7-2) of the DHCP Server Properties dialog box for your selected DHCP server, go to the Policy field and choose the policy for which to add DHCP options.

Step 2 Click Edit options to open the Edit Options dialog box (Figure 7-4).

Figure 7-4 Edit Options Dialog Box

The Available field includes all the available DHCP options organized in categories. Click the plus sign next to a category to view the member options. The options that are preset for the policy type, if any, appear in bold type and also appear in the Active field.

Step 3 Choose the option you want to configure for the policy. For example, expand the DHCP Packet Fields category in the Available field, then choose the packet-file-name option.

Step 4 Click Add >>> to add the option to the Active field.

The option settings appear at the bottom of the dialog box. For example, for the packet-file-name option, enter the text /docsis/mac-%@mac-addr% in the "Option value(s)" field. The "Send to BOOTP clients" and "Always send to DHCP clients" options are described in the "Enabling and Disabling BOOTP for a Scope" section.

Step 5 Click OK and commit the changes on a confirmation dialog box. The option now appears in the Active field of the DHCP Server Properties dialog box, with its value in the "Value(s)" field.

Step 6 Add additional options in the same way by repeating steps 2 to 5.

Step 7 To edit or remove a DHCP option:

a. Choose the option in the Active list.

b. Click Edit options to open the Edit Options dialog box.

c. Overtype the text or check a box in the "Option value(s)" field, or click <<< Remove to remove the option from the Active field.

d. Click OK.

Step 8 Click Close.

Step 9 Reload the DHCP server.


Supporting Vendor-Specific DHCP Options

You can send vendor-specific option data to accommodate DHCP clients that request them. The server sends vendor-encapsulated options in DHCP option 43. Each vendor has a special syntax for the data part of the option. The Network Registrar GUI does not support option 43, but the CLI does.

Using the CLI

There are four main steps (and their commands) in configuring vendor-specific options for a client:

1. Create the vendor-specific option—vendor-option name create

2. Create and define any vendor-specific data types—option-datatype name create and defineField

3. Define the required suboptions with the data types—vendor-option name defineSuboption

4. Set the vendor option values inside a policy—policy name setVendorOption


Step 1 See your DHCP client device vendor's manual for the device's class identifier string that the client sends in DHCP option 60. Use this string in the vendor-option name create command. The following command creates the device1_vso vendor option, using the exact string that the vendor uses for the device's class identifier. The class identifier must be unique to each vendor option.

nrcmd> vendor-option device1_vso create "device1:Arch:xxxxxx:UNDI:yyyzzz" 

Step 2 Identify the format of the DHCP option 43 data the DHCP client device requires. The format could range from a simple IP address to several suboptions. Each suboption has a data type and corresponding data. Network Registrar arranges the suboption data in sequence, using the suboption number, to form the packet returned to the client. The suboptions can have standard DHCP data types or more complex vendor-specific ones.

List all the suboption numbers and their data types. If you use standard data types, such as BYTE, STRING, and INT, go to Step 4. If you use multiple or more complex vendor data types, you must define an option-datatype. For example, suboption_8 holds an array of boot server addresses available to the device and requires a special array data type.

First create the option-datatype using the option-datatype name create command. Then, use option-datatype name defineField command to define the data type fields. For the example of the device1_suboption_8 data type to be applied to suboption_8, the first field, boot_server_type, has a WORD data type. The second field, boot_server_IP_list, has an IPADDR data type in a counted array. The enable read-only attribute in the last command prevents further changes to the definition.

nrcmd> option-datatype device1_suboption_8 create 
nrcmd> option-datatype device1_suboption_8 defineField boot_server_type 1 WORD 
nrcmd> option-datatype device1_suboption_8 defineField boot_server_IP_list 2 IPADDR_ARRAY 
       counted-array 
nrcmd> option-datatype device1_suboption_8 enable read-only 

Note that you can only use these complex option-datatypes with the vendor-option command in the next step, not with the custom-option command.

Step 3 Confirm your settings by showing or listing the data type or its fields. If necessary, undefine or redefine a field, or delete the data type and start over again.

nrcmd> option-datatype device1_suboption_8 show 
nrcmd> option-datatype list 
nrcmd> option-datatype listnames 
nrcmd> option-datatype device1_suboption_8 listFields 
nrcmd> option-datatype device1_suboption_8 undefineField boot_server_type 
nrcmd> option-datatype device1_suboption_8 delete 

Step 4 Based on the suboption numbers you listed, use the vendor-option name defineSuboption command to define each suboption and map it to its appropriate data type. If the suboption has a standard data type, you can use a simpler version of the command with the standard data type specified.

nrcmd> vendor-option standard_type defineSuboption suboption_1 1 IPADDR 

In the device_1_vso example, however, the client expects the server to return several suboptions as an array. In this case, define suboption_8 with the special device1_suboption_8 option-datatype you created in Step 2. The array flag allows setting the multiple instances of the suboption in Step 5.

nrcmd> vendor-option device1_vso defineSuboption suboption_8 8 device1_suboption_8 array 

Note that although some DHCP clients do not request suboptions, you should still define a single suboption, at number 1. Then, use the no-suboption-opcode flag to prevent adding additional ones. The following example uses the standard STRING data type for the suboption.

nrcmd> vendor-option no_opt defineSuboption suboption_1 1 STRING no-suboption-opcode 

You can also undefine a suboption.

nrcmd> vendor-option no_opt undefineSuboption suboption_1 

Step 5 Set each suboption value in a policy. Use the policy name setVendorOption command to set the values and policy name unsetVendorOption command to unset them. For created suboptions with standard data types, you can set the suboption directly with a value. Then, list the vendor options.

nrcmd> policy default setVendorOption standard_type suboption_2 "string-data" 
nrcmd> policy default listVendorOptions 

In the more complex array example, you need to include the array index value. The array definition requires the special braced and square-bracketed suboption-index syntax: {suboption[index]}.

nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[0]} 
       boot_server_type 2 
nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[0]} 
       boot_server_IP_list 192.168.25.4,192.168.25.5 
nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[1]} 
       boot_server_type 8 
nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[1]} 
       boot_server_IP_list 192.168.25.6 

In the example, the network-1.2.3 policy sets the following suboption_8 array element values for device1_vso:

a. Array element 0 boot_server_type field—Type 2 (Microsoft Windows boot server)

b. Array element 0 boot_server_IP_list field—List of Windows boot server addresses

c. Array element 1 boot_server_type field—Type 8 (HP OpenView boot server)

d. Array element 1 boot_server_IP_list field—List of OpenView boot server addresses

Step 6 Show or list the results. If they are not what you expected, delete the vendor option and start over again. Vendor options are write-enabled by default. You can change each vendor option to be read-only.

nrcmd> vendor-option listnames 
nrcmd> vendor-option list 
nrcmd> vendor-option standard_type show 
nrcmd> vendor-option no-opt delete 
nrcmd> vendor-option standard_type enable read-only 


Editing a Policy

You can edit an existing policy, as well as delete it entirely. This can be tricky, because you have to consider the effect on any of the scopes or clients that use that policy.


Caution If you delete a policy, Network Registrar removes it from all scopes, clients, and client-classes.

Using the CLI

Use the policy name show or policy name get attribute command to show the value of an attribute. Then use the policy name set attribute command to change an attribute, or the policy name unset attribute command to unset any optional attribute. If you need to delete a policy, use the policy name delete command, remembering that this removes the policy from all scopes, clients, and client-classes.

nrcmd> policy policyPC show 
nrcmd> policy policyPC get grace-period 
nrcmd> policy policyPC set grace-period=2d 
nrcmd> policy policyPC unset grace-period 
nrcmd> policy policyPC delete 

Use the policy name unsetOption command to remove an option from a policy.

nrcmd> policy policyPC unsetOption dhcp-lease-time 

Using the GUI


Step 1 On the Policies tab of the DHCP Server Properties dialog box (Figure 7-2), choose the name of the policy you want to edit or delete.

To edit the policy, overtype (or reselect) the entries or options in the Leases area, then click Edit options to add more options or edit (or remove) existing ones.

To delete the policy, click Delete at the top of the dialog box.

Step 2 Click OK in the Edit Options dialog box.

Step 3 Click OK in the DHCP Server Properties dialog box.

Step 4 Reload the DHCP server.


Defining Advanced Server Parameters

You can set advanced DHCP server parameters, including custom DHCP options.

Setting Advanced DHCP Server Parameters

Table 7-4 describes the advanced parameters that you can set in the GUI for DHCP servers, with their CLI attribute equivalents.

Table 7-4 DHCP Advanced Parameters 

This advanced parameter...
Does the following...

Number of DHCP requests (max-dhcp-requests)

Controls the number of request buffers that the DHCP server allocates for receiving packets from DHCP clients (the peak load the server handles). If more packets arrive from clients than there are request buffers available to service them, they are dropped. The default number of DHCP request buffers is 500.

The amount of memory that the DHCP server consumes is related to the number of allocated request and response buffers. Because the server pre-allocates these buffers during initialization, give careful thought to their values. The correct ratio of request to response buffers is in the "Number of DHCP responses" parameter.

Number of DHCP responses (max-dhcp-responses)

Controls the number of response buffers the DHCP server allocates for responding to DHCP clients and performing failover communication between DHCP partners. The default number of DHCP response buffers is 1000.

The number of allocated response buffers should be a ratio of the value set for the "Number of DHCP requests" option. A good rule of thumb is that there should be 50 percent more response buffers if the number of request buffers is less or equal to 2000; otherwise, 20% more.

UDP packet size
(udp-packet-size)

Controls the maximum size, in bytes, of the packets that the DHCP server transmits. The packet size should be at least as large as the maximum DHCP packet that the DHCP server should be expected to serve.

The default UDP packet size is 1536. It should not be smaller than 576, and it could be as large as the maximum transfer unit (MTU) of the networks on which the DHCP server operates. It should not be over 2048.

Number of ping packets (max-ping-packets)

If you enable the "Ping address before offering it" option at the scope level, packet buffers are used to send and receive ICMP messages. See the "Pinging a Host Before Offering an Address" section. If you enable pinging, you should have enough ping packets allocated to handle the peak load of possible ping requests. The default is 500 ping packets.

Old states to keep
(old-states-to-keep)

When the DHCP server is running, it records state information in the database. The state includes the current leases. When you start the server, Network Registrar examines the previous state to update its in-memory cache. It then writes new information to the state as necessary. Use this value to adjust how many of the most recent old states Network Registrar keeps. The default is to keep five states.

Enable Unicast
(hardware-unicast)

Controls whether the DHCP server sends unicast rather than broadcast responses when a client indicates that it can accept a unicast. This feature is only available on Windows NT, Windows 2000, and Solaris platforms; other operating systems broadcast instead. The default is enabled.

Defer Lease Extensions (defer-lease-extensions)

Controls whether the DHCP server extends leases that are less than half expired. The default is checked or true. This means that a client renewing a lease less than halfway through it can only get the remaining part of it and not be extended.

Last Transaction Time Granularity (last-transaction-time-granularity)

Specifies the number of seconds that guarantees the last transaction time to be accurate. The default is 30 seconds in the GUI, and there is no default in the CLI. Do not set this lower than 30 seconds. For optimal performance, set it to a value that is greater than half the lease interval.


Using the CLI

Use the dhcp show, and dhcp get commands to show the current server parameters, then use the dhcp set, and dhcp unset commands to change them. See Table 7-4 for guidelines.

nrcmd> dhcp set max-dhcp-responses=400 max-dhcp-requests=400 max-ping-packets=250 
nrcmd> dhcp enable hardware-unicast 
nrcmd> dhcp enable defer-lease-extensions 
nrcmd> dhcp set last-transaction-time-granularity=1800 
nrcmd> dhcp enable mac-address-only 
nrcmd> dhcp enable one-lease-per-client 
nrcmd> dhcp set scope-selection-tags=tSubscribers,tCableModems 
nrcmd> dhcp enable drop-packet-on-extension-failure 
nrcmd> dhcp set drop-old-packets=10 

Using the GUI

The Advanced tab contains the advanced parameter fields and functions (Figure 7-5).

Figure 7-5 Advanced Tab (DHCP Server Properties Dialog Box)


Step 1 Double-click the DHCP server for which you want to set advanced parameters. This opens the DHCP Server Properties dialog box.

Step 2 Click the Advanced tab.

Step 3 Modify the field values for the parameters in Table 7-4.

Step 4 Check the Enable Unicast box if you want the DHCP server to send broadcast responses only, a feature that may not be available on all operating systems.

Step 5 Check the Defer Lease Extensions box if you want to control whether the DHCP server should extend leases that are less than half expired.

Step 6 Click OK or add custom options. See the "Configuring Custom DHCP Options" section.


Configuring Custom DHCP Options

Along with assigning values to predefined DHCP options, you can create your own custom options.

Adding a Custom Option

You can add a custom option to a policy and assign or edit its value.

Using the CLI

Use the custom-option name create command to create a custom option. For example, to create the option red, mapped to number 100 and of type IPADDR (IP address), enter:

nrcmd> custom-option myoption create 100 BYTE desc="custom option 100" 


Tip Do not map numbers to options that DHCP or BOOTP already uses. For a list of pre-assigned numbers, see "DHCP Options." Ensure that the option number is set to the same one requested by the client.


Use the custom-option name [show] command to show an option's values, and the custom-option list command to show all the custom options, or list just the names. Use the custom-option name get command to show individual properties of the custom option. You can also unset a custom option.

nrcmd> custom-option myoption 
100 Ok
myoption:
    desc = "custom option 100" 
    number = 100 
    type = BYTE 

nrcmd> custom-option myoption get desc 
100 Ok
desc="custom option 100" 

Using the GUI


Step 1 Double-click the DHCP server for which you want to set advanced parameters. This opens the DHCP Server Properties dialog box. Click the Advanced tab (Figure 7-5).

Step 2 Click Custom Options to open the Custom Options dialog box, then click Add.

Step 3 In the Add Custom Option dialog box (Figure 7-6), choose an option number from the drop-down list. The numbers in the selection list intentionally do not map to any existing DHCP options. See "DHCP Options." Ensure that the client and server use the same option number.

Figure 7-6 Add Custom Option Dialog Box (off Custom Options Dialog Box)

Step 4 Enter a name in the Option Name field. This name should also match the one that the client assigns.

Step 5 From the Option Data Type drop-down list, choose an option type.

If the data type involves array elements, check the Data is Array? box.

Step 6 Enter a description for the option, if desired.

Step 7 Click OK to finish, or Apply to continue adding custom options.

Step 8 Click Close in the Custom Options dialog box.

Step 9 Click the Policies tab, then click Edit Options. The new options that you added should appear when you expand the Custom category in the Available list.


Editing and Removing a Custom Option

You can edit or remove custom options.


Caution Changing custom option properties or deleting the option altogether can have unexpected side effects on policies. If you delete a custom option, also remove it from the policies that include it.

Using the CLI

Use the custom-option name set command to change the option type (opttype) or description (desc). To change an custom option's number, you must delete the option and recreate it with the new number.

nrcmd> custom-option myoption set desc="This option applies to all external users" 

Use the custom-option name delete command to delete an option.

nrcmd> custom-option myoption delete 

After you delete a custom option, also unset it from all policies that include it by using the policy name unsetOption command.

Using the GUI


Step 1 On the Advanced tab of the DHCP Server Properties dialog box for the selected server, click Custom Options (Figure 7-5).

Step 2 From the Custom Options dialog box, choose the option that you want to edit or remove.

Step 3 Click Edit to edit the option or Remove to remove it:

Edit—Opens the Edit Custom Option dialog box, where you can make changes to any of the fields other than the Option Number. Click OK after you make the edits.

Remove—Opens a confirmation dialog box where you click OK. If you remove the option, also remove it from all policies that include it. See the "Editing a Policy" section.

Step 4 Click Close in the Custom Options dialog box.


Configuring Multiple Servers and BOOTP Relay

You should install more than one DHCP server so that if one fails, clients can continue to get addresses. Because DHCP does not provide for DHCP servers to cooperate, you must divide the IP address pool among the servers to prevent duplicate address assignments. For details on how to set up DHCP failover servers, see "Configuring DHCP Failover."

Configuring a Second DHCP Server

You can configure two DHCP servers to distribute the load and handle the leases if the first server goes down. You must configure the second server on a different cluster than the first.

For each DHCP server, configure a scope that contains some mixture of local and remote cluster clients, such as 60% of the address pool for local clients and 40% for clients on another subnet. See "Configuring DHCP Scopes and Leases."

If both servers are on the same subnet, you do not need to configure routers. If they are on different subnets, configure the routers (relay agents) so that they deliver requests between the two servers.

After you set up both servers, the local DHCP server responds to requests from local DHCP clients most of the time. The remote DHCP server assigns addresses to clients on the other subnet only when the local server is unavailable or without addresses.

Configuring a BOOTP Relay Router

Any router that supports BOOTP relay usually has an address that points to the DHCP server. For example, if you are using a Cisco router, it uses the term IP helper-address, which contains an address for a specific machine. In this case, use this address to forward all BOOTP (and therefore DHCP) broadcast packets. Be sure that you configure this address on the router closest to your host.


Tip If your clients do not receive addresses, the router might be configured with another DHCP server, where the Network Registrar DHCP server cannot see it. If so, configure a second helper address so that the server can also respond to the packets. You can also set up your server to ignore clients' requests for other servers by using the dhcp enable ignore-requests-for-other-servers command.


DHCP Forwarding

You can use Network Registrar to forward DHCP traffic from one DHCP server to another. For example, you might want to redirect address requests from certain clients, with specific MAC address prefixes, to another DHCP server. This can be useful and important in situations where the server being forwarded to is not one that you manage. This occurs in environments where multiple service providers supply DHCP services for clients on the same virtual LAN.

Enabling the DHCP forwarding feature requires implementing an extension script. The DHCP server intercepts the specified clients and calls its forwarding code, which checks the specified list of forwarded server addresses. It then forwards the requests rather than process them itself. You attach and detach extensions to and from the DHCP server using the dhcp attachExtension, and dhcp detachExtension commands. For details on the extension script processing, see the Network Registrar CLI Reference Guide, in the "DHCP Forwarding" usage guidelines of the dhcp command section.

Integrating Windows System Management Server

You can have the DHCP server interact with the Microsoft System Management Server (SMS) so that SMS is current with DHCP changes. Normally, SMS pulls updated data through a DHCPDISCOVER request from the server about any new clients that joined the network. Network Registrar, however, pushes these updates to SMS when you use the dhcp updateSms command. Before you do, check:

Is the SMS client installation and initialization step complete?

Is the Network Registrar Server Agent set to run under a login account with sufficient privileges?

Is the SMS site ID correct; does it match that of the SMS server?

Using the CLI

The following steps describe how to integrate Windows SMS into Network Registrar.


Step 1 Install the Microsoft BackOffice 4.5 Resource Kit on the same machine as the Network Registrar DHCP server. Follow the installation instructions and select the default settings.

Step 2 After the installation, modify the User Variable search path on the Environment tab of the System control panel to:

\program files\ResourceKit\SMS\diagnose 

Step 3 If the DHCP and SMS servers are on different machines, install the SMS client on the same machine as the DHCP server. The SMS library has the necessary API calls to communicate with the SMS server. You must assign the correct site code from the DHCP server machine. In your Network Neighborhood, go to the following path:

\\SMS-servername\SMSLOGON\x86.bin\00000409\smsman.exe 

Run the program and follow the instructions, using the default settings. The program creates two icons that you can use later from the control panel, marked SMS and Remote Control.

Step 4 Stop and then restart the Network Registrar Server Agent under a trusted domain account with sufficient privileges. Both the DHCP and SMS servers must be aware of this account. Use this short procedure:

a. Click Stop on the Startup tab of the Server Agent 2.0.

b. Configure the account under which the Network Registrar services run. Create an account name that is a member of both the trusted SMS site server group and a member of the DHCP server machine's administrator group, with the corresponding password.

c. Restart the Server Agent.

Step 5 Use the dhcp set sms-library-path command to configure the DHCP server to push lease information to SMS. Include the full path to the SMSRsGen.dll. If you omit a value, the path defaults to the internal server default location of this file.

nrcmd> dhcp set sms-library-path path-to-dll 

Step 6 Turn SMS network discovery on using the dhcp set sms-network-discovery=1 command. If you use the default of 0, you disable SMS network discovery.

nrcmd> dhcp set sms-network-discovery=1 

Step 7 Enter the SMS site code that you entered in Step 3 using the dhcp set sms-site-code command. The default string is empty, but for data discovery to be successful, you must provide the site code.

nrcmd> dhcp set sms-site-code=sitecode 

Step 8 Enter the SMS lease interval value using the dhcp set sms-lease-interval command. The lease interval is the time between sending addresses to SMS, or how long, in milliseconds, the DHCP server should wait before pushing the next lease to the SMS server when you execute the server dhcp updateSms command. Early versions of the SMSRsGen.dll file (SMS Version 2.0) did not allow SMS to reliably receive multiple updates within a one-second window (1000 ms); the default value, therefore, was set to 1.1 second (1100 ms). If you install a future version of the Microsoft BackOffice Resource Kit, which might contain an enhanced version of the SMSRsGen.dll file, then reduce this interval or set it to 0 to increase performance.

nrcmd> dhcp set sms-lease-interval=1100 

Step 9 Reload the DHCP server and check the name_dhcp_1_log file for a successful load.

nrcmd> dhcp reload 

Step 10 Use the server dhcp updateSms command to initiate SMS processing. This command can take an optional all keyword to send all leased addresses from the DHCP server to SMS. If you omit this keyword, the DHCP server sends only new leases activated since the last time the command ran. (If you reload the DHCP server while processing the command, reloading does not resume until after you restart the DHCP server). Then, verify that both the DHCP and SMS logs indicate successful completion.

nrcmd> dhcp updateSms all 
nrcmd> dhcp restart 


Using Extensions to Affect DHCP Server Behavior

Network Registrar provides the unique ability to alter and customize the operation of the DHCP server through extensions, programs that you can write in TCL or C/C++.

For example, you might have an unusual routing hub that uses BOOTP configuration. This device issues a BOOTP request with an Ethernet hardware type (1) and MAC address in the chaddr field. It then sends out another BOOTP request with the same MAC address, but with a hardware type of Token Ring (6). The DHCP server normally distinguishes between a MAC address with hardware type 1 and one with type 6, and considers them to be different devices. In this case, you might want to write an extension that prevents the DHCP server from handing out two different addresses to the same device.

You can solve the problem of the two IP addresses by writing either of the following extensions:

One that causes the DHCP server to drop the Token Ring (6) hardware type packet.

One that changes the Token Ring packet to an Internet packet and then switches it back again on exit. Although this extension would be more complex, the DHCP client could thereby use either return from the DHCP server.

You can write extensions in TCL or C/C++:

TCL—Makes it a bit easier and quicker to write an extension. If the extension is short, the interpreted nature of TCL does not have a serious effect on performance. When you write an extension in TCL, you are less likely to introduce a bug that can crash the server.

C/C++—Provides the maximum possible performance and flexibility, including communicating with external processes. However, the complexity of the C/C++ API is greater and the possibility of a bug in the extension crashing the server is more likely than with TCL.

You create extensions at specific extension points. Extension points include three types of dictionaries—request, response, and environment. Each extension point can use one or more of these dictionaries. The extension points are as follows:

1. init-entry—Extension point that the DHCP server calls when it configures or unconfigures the extension. This occurs when starting, stopping, or reloading the server. This entry point has the same signature as the others for the extension. Dictionary used: environment only.

2. post-packet-decode—Used to rewrite the input packet. Dictionary used: request or environment.

3. pre-client-lookup—Used to affect the client being looked up, possibly by preventing the lookup or supplying data that overrides the existing data. Dictionary used: request or environment.

4. post-client-lookup—Used to review the operation of the client-class lookup process, such as examining the internal server data structures filled in from the client-class processing. You can also use it to change any data before the DHCP server does additional processing. Dictionary used: request or environment.

5. check-lease-acceptable—Used to change the results of the lease acceptability test. Do this only with extreme care. Dictionary used: request, response, or environment.

6. pre-packet-encode—Used to change the data sent back to the DHCP client in the response, or change the address to which to send the DHCP response. Dictionary used: request, response, or environment.

7. pre-dns-add-forward—Used to alter the name used for the DNS forward (A record) request. Dictionary used: environment only.

8. post-send-packet—Used after sending a packet for processing that you want to perform outside of the serious time constraints of the DHCP request-response cycle. Dictionary used: request, response, or environment.

This is merely an introduction to extensions and extension points. For details on how to implement them, see the CLI Reference Guide.

Troubleshooting DHCP Servers

Be sure to follow any server property changes with a reload.

nrcmd> dhcp reload 

Helpful hints in tuning your DHCP performance include:

Set the request and response buffers for optimal throughput. There should be about three times as many response buffers as request buffers. Shorter lease times require more response buffers.

nrcmd> dhcp set max-request-buffers=500 max-response-buffers=1500 

Keep the defer-lease-extensions attribute enabled. This reduces writes to the database.

nrcmd> dhcp enable defer-lease-extensions 

Set the last-transaction-time-granularity attribute to at least 30 seconds, optimally a value greater than half your lease interval.

nrcmd> dhcp set last-transaction-time-granularity=30 

Disable the allow-lease-time-override attribute for policies offering production leases.

nrcmd> policy prod1 disable allow-lease-time-override 

Choose from the DHCP log settings to give you greater control over existing log messages. Use the dhcp set log-settings command in the CLI with one or more of these attributes:

activity-summary—Enables logging a summary message every five minutes (useful if the following no- type flags are set), showing the activity in the previous interval (you can adjust this interval using the dhcp set-activity-summary-interval command)

default—Displays a low level of DHCP logging (the default setting)

dropped-waiting-packets—Logs packets dropped after you set the max-waiting-packets attribute to a non-zero value (the value is zero by default)

incoming-packets—Logs a separate line for each incoming DHCP packet (the default)

incoming-packet-detail—The same as incoming-packets, but in human-readable form

outgoing-packet-detail—Logs each incoming DHCP packet in a human-readable form

leasequery—Logs a message for every ACK- or NAK-responded lease query packet

minimal-config-info—Reduces the number of configuration messages in the log

missing-options—Displays missing policy options expected by a client (the default)

no-success-messages—Inhibits logging successful outgoing response packets

no-dropped-dhcp-packets—Inhibits logging dropped DHCP packets

no-dropped-bootp-packets—Inhibits logging dropped BOOTP packets

no-invalid-packets—Inhibits logging invalid packets

no-reduce-logging-when-busy—Inhibits reducing logging when receive buffers reach 66%

no-timeouts—Inhibits logging time-outs of leases and offers

Note that there are additional log settings useful specifically for dynamic DNS update, failover, clients, and client-classes. For details, see the appropriate chapters in this guide.

Keep busy optimization enabled for the server. An attribute called inhibit-busy-optimization is disabled by default and is best kept that way. Usually, when the server determines that it is heavily loaded and that the load is increasing, it tries to recover from the congestion by performing several optimizations. (A server determines that it is heavily loaded when the number of request packets in use reaches two-thirds of the total allocated. It resets that condition when it drops to one-third of those allocated. It logs a message for each.) In busy optimization, the server relaxes the requirements to keep a client's last transaction time updated to the granularity specified by the last-transaction-time-granularity attribute, 30 seconds by default. If the inhibit-busy-optimization attribute is enabled, the server does not perform any optimization.

Adjust the MCD blobs-per-bulk-read attribute value to tune DHCP start and reload times. Generally, a higher blobs-per-bulk-read attribute value results in faster server start and reload times, at the cost of using more memory. Values can be set to any number between 1 and 2500 using the dhcp set mcd-blobs-per-bulk-read command. The current default is 256 blobs.