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

Configuring DHCP Servers

Table Of Contents

Configuring DHCP Servers

Configuring a DHCP Server

General Configuration Guidelines

Choosing the Server Interface

Configuring Server Policies

Types of Policies

Policy Reply Options

Creating a Policy

Adding DHCP Options for the Policy

BOOTP and DHCP Reply Options

Supporting Vendor-Specific DHCP Options

Editing a Policy

Defining Advanced Server Parameters

Setting Advanced DHCP Server Parameters

Deferring Lease Extensions

Configuring Custom DHCP Options

Adding a Custom Option

Editing and Removing a Custom Option

BOOTP Relay

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. The Network Registrar Web UI Guide explains how to accomplish these tasks using the Web-based interface.

Table 7-1 DHCP Server Configuration Topics 

If you want to...
See...

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

"BOOTP Relay" section

Configure DHCP forwarding

"DHCP Forwarding" section

Integrate Windows System Management Server (SMS) with DHCP

"Integrating Windows System Management Server" section

Use 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 DHCP server's IP address.

One or more policies, to specify, at a minimum, the lease times for the addresses—See the "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—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.

Lease times—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. In the absence of specific deployment requirements, a good rule of thumb is to set the DHCP lease times to at least four days. See the "Creating a Policy" 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.

Network Registrar uses the default interface to provide configurable default values for interfaces that the DHCP server discovers automatically.


Caution Do not delete the default interface.

By default, the DHCP server uses the operating system support to automatically enumerate the active interfaces on the machine and listens on all of them. You can also manually configure the server interface. You should statically configure all the IP addresses assigned to NIC cards on the machine where the DHCP server resides. The machine should not be a BOOTP or DHCP client.

Using the Web UI

This function is not currently available in the Web UI.

Using the CLI


Step 1 Use the dhcp-interface command to manually control which network interface cards' IP addresses the DHCP server will listen on for DHCP clients. By default, the DHCP server automatically 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 
100 Ok 
192.168.41.3/24: 
addr = 192.168.41.3 
ignore = 
mask = 255.255.255.0 

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 
100 Ok 
192.168.41.3/24: 
addr = 192.168.41.3 
ignore = 
mask = 255.255.255.0 
nrcmd> dhcp-interface list 
100 Ok 
192.168.41.3/24: 
addr = 192.168.41.3 
ignore = 
mask = 255.255.255.0 
default: 
addr = 0.0.0.0 
ignore = 
mask = 0.0.0.0 
nrcmd> dhcp-interface 192.168.41.3/24 set addr=192.168.41.4 
100 Ok 
192.168.41.4/24: 
addr = 192.168.41.4 
ignore = 
mask = 255.255.255.0 
nrcmd> dhcp-interface 192.168.41.4/24 set mask=255.255.255.192 
100 Ok 
192.168.41.4/26: 
addr = 192.168.41.4 
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.4/26 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.

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, named, and embedded policies:

System default (system_default_policy)—Provides a single location for setting default values on certain options for all scopes. Use the system default policy to define standard DHCP options that have common values for all clients on all the networks that the DHCP server supports. 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-2). 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-2 System Default Policy Option Values 

System Default Option
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


Named—Policies you explicitly define by name. Named policies are usually named after their associated scope or client grouping. For example, they might be assigned options that are unique to a subnet, such as for its routers, and then be assigned to the appropriate scope.


Tip Network Registrar includes a default policy when you install the DHCP server. The server assigns this policy to newly created scopes. You can modify the default policy or assign another one to the scope.


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 Web UI and CLI. See the "Configuring an Embedded Policy for the Scope" section.

Policy Reply Options

To eliminate any conflicting option values that are set at these various levels, the Network Registrar DHCP server uses a local priority method. It adopts 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 this 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.

Then, the server looks through the policies for a reply-options list. It looks for bootp- or dhcp-reply-options, depending on the client. The server uses the first list it finds. For each option in the list, the server looks through all of the policies, in order, and returns the data from the first policy that has a matching option.

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 a:

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 Web UI


Step 1 On the Primary Navigation bar, click the DHCP tab. See the Network Registrar Web UI Guide for details.

Step 2 On the Secondary Navigation bar, click the Policies tab to open the List DHCP Policies page. There will be two policies initially listed—default and system_default_policy.

Step 3 To add an additional policy, click Add Policy to open the Add DHCP Policy page.

Step 4 Give the policy a unique name and either accept the offer timeout and grace period defaults or set them differently.

Step 5 See the "Adding DHCP Options for the Policy" section for adding options for the policy.

Step 6 Click Add Policy to add the policy.


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 not case-sensitive.

nrcmd> policy policyPC create grace-period=1d 
100 Ok 
grace-period=24h 
policyPC: 
allow-client-a-record-update = disabled 
allow-dual-zone-dns-update = [default=disabled] 
allow-lease-time-override = enabled 
bootp-reply-options = 
dhcp-reply-options = 
grace-period = 24h 
...

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

nrcmd> policy policyPC enable permanent-leases 
100 Ok 
permanent-leases=enabled 

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

nrcmd> policy policyPC setOption domain-name example.com. 
nrcmd> policy policyPC setOption domain-name-servers 192.168.40.2 
nrcmd> policy policyPC setOption 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 
100 Ok 
2d12h 
nrcmd> policy policyPC listOptions 
100 Ok 
(51)dhcp-lease-time: 21600

A policy contains two lease times—the client lease time and the server lease time.

Client—You set the client lease time through the setLeaseTime keyword. This lease time determines how long the client believes its lease is valid.

Server—You set the server lease time through the server-lease-time attribute. This lease time determines how long the server considers the lease valid. Note that the server lease time is independent of the lease's grace period. The server does not allocate the lease to another client until after the lease time and grace period expire.

You can establish these two different lease times if you want to retain information about clients' DNS names and yet have them renew their leases frequently. When you use a single lease time and it expires, the server no longer keeps that client's DNS name. However, if you use a short client lease time and a longer server lease time, then the client information is retained even after the client's lease expires.


Caution Although Network Registrar supports the use of two lease times for special situations, Cisco Systems generally recommends that you not use the server-lease-time attribute.

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 
100 Ok 
subnet-mask=255.255.255.0 
nrcmd> dhcp enable get-subnet-mask-from-policy 
100 Ok 
get-subnet-mask-from-policy=true 
nrcmd> dhcp unset get-subnet-mask-from-policy 
100 Ok 
nrcmd> dhcp disable get-subnet-mask-from-policy 
100 Ok 
get-subnet-mask-from-policy=false 
nrcmd> dhcp reload 
100 Ok


Using the GUI


Step 1 In the DHCP Server Properties dialog box for a selected server, click the Policies tab.

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.

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

Step 4 In the Copy from field, choose:

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

<None> when you do not want to base the new policy on any existing one—This policy has no preset properties or options.

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 Web UI


Step 1 Create a policy, as described in the "Creating a Policy" section.

Step 2 Add DHCP options to the policy by clicking their numbers and names in the Number drop-down list. The selections indicate the datatype of the option value. Add the appropriate option value in the Value field. The Web UI does error checking based on the value entered. For example, to add the lease time for the policy, click the [51] dhcp-lease-time (unsigned time) option in the Number drop-down list, then add a lease time value in the Value field.

Step 3 Click Add Option for each option. You must supply a value or you cannot add the option.

Step 4 Click Add Policy to add the policy. See the Network Registrar Web UI Guide for details.


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 
100 Ok 
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 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.

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.


BOOTP and DHCP Reply Options

BOOTP and DHCP reply options provide a way to supply a client with information that it has not yet requested. There is no requirement that the data from the server must come from the same policy as the reply options list. If the server finds a reply options list, it looks for each option in the list individually, and searches all the related policies if necessary.

Also, you do not need to have the options mentioned in a reply-options list present in the policy containing the list. You can enter a string that can name any option. The Network Registrar GUI, however, presents a special dialog box for adding a reply-options attribute to a policy that restricts you to the options already configured in the policy. This is a GUI-only restriction; the server does not impose this restriction.

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 or Web UI do not support option 43, but the CLI does.

Using the Web UI

This function is not currently available in the Web UI.

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" 
100 Ok 
device1_vso: 
name = device1_vso 
read-only = disabled 
vendor-class-id = 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 
100 Ok 
device1_suboption_8: 
name = device1_suboption_8 
read-only = disabled 
nrcmd> option-datatype device1_suboption_8 defineField boot_server_type 1 WORD 
100 Ok 
device1_suboption_8: 
name = boot_server_type 
number = 1 
type = WORD 
flags = 
nrcmd> option-datatype device1_suboption_8 defineField boot_server_IP_list 2 IPADDR_ARRAY 
counted-array 
100 Ok
device1_suboption_8: 
name = boot_server_ip_list 
number = 2 
type = IPADDR_ARRAY 
flags = counted-array 
nrcmd> option-datatype device1_suboption_8 enable read-only 
100 Ok 
read-only=enabled 

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. (If undefining or redefining fields, first disable read-only for the suboption.)

nrcmd> option-datatype device1_suboption_8 show 
100 Ok 
device1_suboption_8: 
name = device1_suboption_8 
read-only = enabled 
nrcmd> option-datatype list 
100 Ok 
...
device1_suboption_8: 
...
nrcmd> option-datatype listnames 
100 Ok 
...
device1_suboption_8 
...
nrcmd> option-datatype device1_suboption_8 listFields 
100 Ok 
boot_server_type(1) : WORD 
boot_server_ip_list(2) : IPADDR_ARRAY(counted-array) 
nrcmd> option-datatype device1_suboption_8 disable read-only 
100 Ok 
read-only=disabled 
nrcmd> option-datatype device1_suboption_8 undefineField boot_server_type 
100 Ok 
nrcmd> option-datatype device1_suboption_8 delete 
100 Ok

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 create "device1:Arch:xxxxxx:UNDI:yyyaaa" 
100 Ok 
standard_type: 
name = standard_type 
read-only = disabled 
vendor-class-id = device1:Arch:xxxxxx:UNDI:yyyaaa 
nrcmd> vendor-option standard_type defineSuboption suboption_1 1 IPADDR 
100 Ok 
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. (Because you deleted the suboption in the previous step, you need to recreate it.) The array flag allows setting the multiple instances of the suboption in Step 5.

nrcmd> option-datatype device1_suboption_8 create 
100 Ok 
device1_suboption_8: 
fields = 
name = device1_suboption_8 
read-only = disabled 
nrcmd> vendor-option device1_vso defineSuboption suboption_8 8 device1_suboption_8 array 
100 Ok 
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. This example uses the standard STRING data type for the suboption:

nrcmd> vendor-option no_opt create "device1:Arch:xxxxxx:UNDI:yyyxxx" 
100 Ok 
no_opt: 
name = no_opt 
read-only = disabled 
vendor-class-id = device1:Arch:xxxxxx:UNDI:yyyxxx 
nrcmd> vendor-option no_opt defineSuboption suboption_1 1 STRING no-suboption-opcode 
100 Ok 
suboption_1(1) : string(no-suboption-opcode) 

You can also undefine a suboption.

nrcmd> vendor-option no_opt undefineSuboption suboption_1 
100 Ok

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" 
100 Ok 
standard_type suboption_2[0](2) STRING(1) = string-data 
nrcmd> policy default listVendorOptions 
100 Ok 
standard_type suboption_2[0](2) STRING(1) = string-data 

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 
100 Ok 
device1_vso suboption_8[0](8) boot_server_type(1) = 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 
100 Ok 
device1_vso suboption_8[0](8) boot_server_ip_list(2) = 192.168.25.4,192.168.25.5 
nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[1]} 
boot_server_type 8 
100 Ok 
device1_vso suboption_8[1](8) boot_server_type(1) = 8 
nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[1]} 
boot_server_IP_list 192.168.25.6 
100 Ok 
device1_vso suboption_8[1](8) boot_server_ip_list(2) = 192.168.25.6 

In the example, the network-1.2.3 policy sets these 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 
100 Ok 
device1_vso 
standard_type 
no-opt 
nrcmd> vendor-option list 
100 Ok 
device1_vso: 
name = device1_vso 
read-only = disabled 
vendor-class-id = device1:Arch:xxxxxx:UNDI:yyyzzz 
standard_type: 
...
nrcmd> vendor-option standard_type show 
100 Ok 
standard_type: 
name = standard_type 
read-only = disabled 
vendor-class-id = device1:Arch:xxxxxx:UNDI:yyyaaa 
nrcmd> vendor-option no_opt delete 
100 Ok 
nrcmd> vendor-option standard_type enable read-only 
100 Ok 
read-only=enabled 


Editing a Policy

You can edit an existing policy, as well as delete it entirely. Before deleting a policy, 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 Web UI


Step 1 Create a policy, as described in the "Creating a Policy" section.

Step 2 Click the policy name on the List DHCP Policies page to open the Edit DHCP Policy page.

Step 3 Change or unset any attribute values.

Step 4 Add or delete any options.

Step 5 Click Modify Policy. See the Network Registrar Web UI Guide for details.


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 
100 Ok 
policyPC: 
allow-client-a-record-update = disabled 
allow-dual-zone-dns-update = [default=disabled] 
allow-lease-time-override = enabled 
bootp-reply-options = 
...
nrcmd> policy policyPC get grace-period 
100 Ok 
grace-period=24h 
nrcmd> policy policyPC set grace-period=2d 
100 Ok 
grace-period=2d 
nrcmd> policy policyPC unset grace-period 
100 Ok 
nrcmd> policy policyPC delete 
100 Ok 

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

nrcmd> policy policyPC unsetOption dhcp-lease-time 
100 Ok 

Using the GUI


Step 1 On the Policies tab of the DHCP Server Properties dialog box, 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-3 describes the advanced parameters that you can set in the GUI for DHCP servers, with their Web UI and CLI attribute equivalents. See the Network Registrar Web UI Guide for details on their use in the Web UI.

Table 7-3 DHCP Advanced Parameters 

Advanced Parameter
Description

Number of DHCP requests
(max-dhcp-requests)

Controls the number of buffers that the DHCP server allocates for receiving packets from DHCP clients and failover partners. If this setting is too large, a burst of DHCP activity can clog the server with requests that become stale before being processed. This results in an increasing processing load that can severely degrade performance as clients try to obtain a new lease. A low buffer setting throttles requests and could affect server throughput.

In a nonfailover deployment, the default setting is sufficient. In a failover deployment, you can increase it to 1000 if the DHCP logs indicate a consistently high number of request buffers in use. You should then also modify the number of DHCP responses (see the max-dhcp-responses parameter) to four times the request buffers.

When using LDAP client lookups, buffers should not exceed the LDAP lookup queue size defined by the total number of LDAP connections and the maximum number of requests allowed for each connection. Set the LDAP queue size to match the LDAP server's capacity to service client lookups.

Required. The default is 500.

Number of DHCP responses
(max-dhcp-responses)

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

In a non-failover deployment, the default setting of twice the number of request buffers is sufficient. In a failover deployment, you can increase this so that it is four times the number of request buffers. In general, increasing the number of response buffers is not harmful, while reducing it to below the previously recommended ratios might be harmful to server responsiveness.

Required. The default is 1000.

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 value 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.

Required. The default is 1536.

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. See the "Deferring Lease Extensions" section.

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

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


Using the Web UI

On the Primary Navigation bar, click the DHCP tab. On the Secondary Navigation bar, click the DHCP Server tab and the name of the server. This opens the Edit DHCP Server page. Add or modify attributes on this page. Click Modify Server to make the changes. See the Network Registrar Web UI Guide for a description of the attributes.

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-3 for guidelines.

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

Using the GUI

The Advanced tab contains the advanced parameter fields and functions.


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-3.

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.


Deferring Lease Extensions

The defer-lease-extensions attribute allows the DHCP server to optimize its response to a sudden flood of DHCP traffic. The parameter is enabled by default. An example of a network event that could result in such a traffic spike is a power failure at a cable internet service provider (ISP) data center that results in all of its cable modem termination systems (CMTS) rebooting at once. If this were to happen, the devices attached to the CMTSs produce a flood of DHCP traffic as they quickly come back online.

When you enable the defer-lease-extensions attribute, a DHCP client that renews a lease that is less than halfway to its expiration will not have its lease extended to the full lease time. Instead, the client receives a lease corresponding to the remaining time on its existing lease. Because the absolute lease expiration time does not change, the server can avoid database updates that result in a significantly higher server throughput.

If a client is more than halfway to its expiration, this setting has no effect, and the lease is extended to the full configured lease interval as usual, including the database writes.


Note This feature significantly increases the server's performance while remaining in compliance with the DHCP RFC, which stipulates that client binding information is committed to persistent storage when the lease changes.


These three specific situations are described from the server's point of view:

Client retries—When the server gets behind, it is possible for a client to retransmit requests. The DHCP server does not maintain enough information to recognize these as retransmissions, and processes each to completion, granting a full lease duration again and updating the database. When the server is already behind, doing extra work worsens the situation. To prevent this, the DHCP server does not extend leases that are less than 30 seconds old, regardless of the state of the defer-lease-extensions attribute.

Client reboots—The effective renew time for a client's lease is really the minimum of the configured renew time and the time between client reboots. In many installations this may mean that clients get fresh leases one (in a typical enterprise) or two (in a typical cable network) times per day, even if the renew time is set for many days. Setting the defer-lease-extensions attribute can prevent these early renews from causing database traffic.

Artificially short renewal times—Because there is no way for a DHCP server to proactively contact a DHCP client with regard to a lease, you might configure fairly short client renewals to provide a means of doing network renumbering, address re-allocation, or network reconfiguration (for example, a change in DNS server address) in a timely fashion. The goal is to allow you to do this without incurring unacceptable database update overhead.

As a complication, the server also keeps track of the time when it last heard from the client. Known as the last transaction time, sites sometimes use this information as a debugging aid. Maintaining this time robustly requires a write to the database on every client interaction. The last-transaction-time-
granularity
attribute is the one to set. It is the time, in seconds, that Network Registrar guarantees that the last transaction time is accurate.

Do not set this granularity lower than the default of 60 seconds. For optimal performance, set it to a value that is greater than half of your lease interval. Because the last transaction time is not integral to the protocol, you need not update it synchronously. Also, because it is primarily a debugging aid, it need not be entirely accurate. Furthermore, because the in-memory copy is always accurate, you can use the export leases -server command to display the current information, even if the data is not up-to-date in the database. See the "Exporting Lease Information" 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 Web UI

This function is not currently available in the Web UI.

Using the CLI

Use the custom-option name create command to create a custom option. For example, to create the option myoption, mapped to number 100 and of type BYTE, enter:

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


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.

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

Step 3 In the Add Custom Option dialog box, 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.

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 Web UI

This function is not currently available in the Web UI.

Using the CLI

Use the custom-option name set command to change the option type (opttype) or description (desc). To change a 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" 
100 Ok 
desc="This option applies to all external users" 

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

nrcmd> custom-option myoption delete 
100 Ok

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.

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.


BOOTP Relay

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.


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.

You can forward DHCP traffic from one DHCP server to another under the control of a Network Registrar extension. The DHCP forwarding attribute is important in situations where the other server is not one that you manage. This is most likely to occur in environments where multiple vendors supply DHCP services for clients on the same virtual LAN.

The DHCP forwarding attribute works like this:

1. When DHCP is initialized, the server opens a UDP socket, which it uses to send forwarded packets. To support servers with multiple IP addresses, the socket address pair consists of INADDR_ANY and any port number. This enables clients to use any one of the server's IP addresses.

2. When the DHCP server receives a request from a client, it processes these extension point scripts:

post-packet-decode

pre-client-lookup

post-client-lookup

As the DHCP server processes these scripts, it checks the environment dictionary for this string:

cnr-forward-dhcp-request 

3. When it finds that string and it has the value true (enabled), the server calls its forwarding code.

4. The forwarding code checks the environment dictionary for a string with this key:

cnr-request-forward-address-list 

It expects a list of comma-separated IP addresses with an optional colon-delimited port number, as in this example:

192.168.168.15:1025,192.168.169.20:1027 

By default, the server forwards to port 67. It sends a copy of the entire client request to each IP address and port in turn. If any element in the list is invalid, the server stops trying to parse the list.

5. After the forwarding code returns, the server stops processing the request. In the post-client-lookup extension point script, however, this might create an optional log message with client-entry details.

The following example of a portion of a TCL extension script tells the DHCP server to forward a request to another server based on the information in the request. You can use such a script if there are multiple device provisioning systems in the same environment. In this case, you would run the extension script on the DHCP server to which routers forward broadcast requests. The script would determine which (if any) other server or servers should handle the request, and tell the original server to forward the request.

The sample script uses a static mapping of MAC address prefix to send modems from a specific vendor to a specific system.

proc postPktDecode {req resp env} { 
set mac [$req get chaddr] 
set addrs "" 
;# Very simple, static classifier that forwards all requests from devices 
;# with a vendor-id of 01:0c:10 to the DHCP servers at 10.1.2.3 and 10.2.2.3: 
switch -glob -- $mac { 
01:0c:10* { 
    set addrs "10.1.2.3,10.2.2.3" 
} 
} 
;# If we decide to forward the packet, the $addrs var will have the IP addresses 
;# where to forward the packet: 
if {$addrs != ""} { 
;# Tell the DHCP server to forward the packet... 
$env put cnr-forward-dhcp-request true 
;# ...and where to forward it: 
$env put cnr-request-forward-address-list $addrs 
;# No more processing is required. 
return 
} 
} 

A more flexible script could use a per-client configuration object, such as the Network Registrar client entry, to indicate which DHCP server should get the request.

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 if the:

SMS client installation and initialization step is complete.

Network Registrar Server Agent is set to run under a login account with sufficient privileges.

SMS site ID is correct and matches that of the SMS server.

Using the Web UI or CLI

These steps describe how to integrate Windows SMS into Network Registrar. See the Network Registrar Web UI Guide for details on the implementation in the Web UI.


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 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 (or the sms-library-path attribute under the Microsoft Systems Management Server category on the Edit DHCP Server page of the Web UI) 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 /conf/dll 
100 Ok 
sms-library-path=/conf/dll 

When you install the Microsoft BackOffice Resource Kit, the system path is not updated to reflect the location of the SMS data link library (DLL). Use one of these methods to configure this attribute:

Set the attribute to the relative path.

To set the attribute to relative path, add this line to the system path on the DHCP server machine:

sms-install-directory\diagnose 

Then, set this attribute to the name of the DLL:

nrcmd> dhcp set sms-library-path smsrsgen.dll 
100 Ok 
sms-library-path=smsrsgen.dll 

You can also accept the system default:

nrcmd> dhcp unset sms-library-path 
100 Ok

Set the attribute to the absolute path.

If you do not want to change the system path, enter this command to set this attribute to the absolute path of the DLL location:

nrcmd> dhcp set sms-library-path 
	"\\Program Files\\Resource Kit\\sms\\diagnose\\smsrsgen.dll" 
100 Ok 
sms-library-path="\\Program Files\\Resource Kit\\sms\\diagnose\\smsrsgen.dll" 

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

nrcmd> dhcp set sms-network-discovery=1 
100 Ok 
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. (In the Web UI, set the sms-site-code attribute on the Edit DHCP Server page.) The default string is empty, but for data discovery to be successful, you must provide the site code.

nrcmd> dhcp set sms-site-code=sitecode1 
100 Ok 
sms-site-code=sitecode1 

Step 8 Enter the SMS lease interval value using the dhcp set sms-lease-interval command. (In the Web UI, set the sms-lease-interval attribute.) 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 
100 Ok
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 
100 Ok

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 
100 Ok
nrcmd> dhcp restart 
100 Ok


Using Extensions to Affect DHCP Server Behavior

Network Registrar provides the 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 these 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:

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. Dictionaries used: environment only.

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

3. post-class-lookup—Used to evaluate the result of a client-class-lookup-id operation on the client-class. Dictionaries used: request and environment.

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

5. 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. Dictionaries used: request and environment.

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

7. lease-state-change—Used to determine when the lease state changes this only with extreme care. Dictionaries used: response and environment.

8. 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. Dictionaries used: request, response, and environment.

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

10. 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. Dictionaries used: request, response, and environment.

This is an introduction to extensions and extension points. For details on how to implement them, see "Using Extension Points."

To extend the DHCP server, do the following:


Step 1 Write the extension in Tcl, C or C++ and install it in the server extensions directory, on:

UNIX—For Tcl this is /opt/nwreg2/extensions/DHCP/tcl
For C or C++ this is /opt/nwreg2/extensions/DHCP/dex

Windows—For Tcl this is \program files\Network Registrar\extensions\dhcp\tcl
For C or C++ this is \program files\Network Registrar\extensions\dhcp\dex

It is best to place these extensions in the appropriate directory for TCL or C/C++ extensions. Then, when configuring the filename, just enter the filename itself, without slash (/) or backslash (\).

If you want to place extensions in subdirectories, enter the filename with a path separator. These are different depending on the operating system on which your DHCP server is running.


Note When entering a filename that contains a backslash (\) character on Windows NT, you must enter it with a double-backslash (\\), because backslash (\) is an escape character in the CLI. For example, enter the filename debug\myextension.tcl as debug\\myextension.tcl.


Step 2 Use the extension command to configure the DHCP server to recognize this extension.

Step 3 Attach the configured extension to one or more DHCP extension points using the dhcp attachExtension command. For more information about choosing extension points and writing extensions, see "Using Extension Points."

Step 4 Reload the server.


Troubleshooting DHCP Servers

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

nrcmd> dhcp reload 
100 Ok

Helpful hints in tuning your DHCP performance include:

Set the request (max-dhcp-requests) and response (max-dhcp-responses) buffers for optimal throughput. See Table 7-3 for details.

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

nrcmd> dhcp enable defer-lease-extensions 
100 Ok 
defer-lease-extensions=true 

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

nrcmd> dhcp set last-transaction-time-granularity=60 
100 Ok 
last-transaction-time-granularity=60s 

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

nrcmd> policy examplepolicy1 disable allow-lease-time-override 
100 Ok 
allow-lease-time-override=disabled 

Choose from the DHCP log settings to give you greater control over existing log messages. Use the log-settings attribute for the DHCP server in the Web UI or the dhcp set log-settings command in the CLI with one or more of the attributes described in Table 7-4.

Table 7-4 DHCP Log Settings 

Log Setting
(Numeric Equivalent)
Description

default (1)

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

incoming-packets (2)

Logs a separate line for each incoming DHCP packet (the default).

missing-options (3)

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

incoming-packet-detail (4)

The same as incoming-packets, but in human-readable form.

outgoing-packet-detail (5)

Logs each incoming DHCP packet in a human-readable form.

unknown-criteria (6)

Logs whenever a client entry has a selection-criteria or selection-criteria-excluded that is not found in any scope appropriate for that client's current network location.

dns-update-detail (7)

Logs each sent and replied DNS update.

client-detail (8)

After every client-class client lookup operation, logs the composite of the data found for the client and its client-class. Useful when setting a client-class configuration and debugging problems in client-class processing.

client-criteria-processing (9)

Logs whenever a scope is examined to find an available lease or to determine if a lease is still acceptable for a client who already has one. Can be very useful when configuring or debugging client-class scope criteria processing. (Causes moderate amount of information to be logged and should not be left enabled as a matter of course.)

failover-detail (10)

Logs detailed failover activity.

ldap-query-detail (11)

Logs whenever the DHCP server initiates a query to an LDAP server, receives a response, and retrieves a result or error messages.

ldap-update-detail (12)

Logs whenever the DHCP server initiates an update lease state to the LDAP server, receives a response, and retrieves a result or error messages.

ldap-create-detail (13)

Logs whenever the DHCP server initiates a lease state entry create to the LDAP server, receives a response, and retrieves a result or error messages.

leasequery (14)

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

dropped-waiting-packets (15)

If the value of max-waiting-packets is non-zero, packets can be dropped if the queue length for any IP address exceeds the value. If dropped-waiting-packets is set, the server logs whenever it drops a waiting packet from the queue for an IP address.

no-success-messages (16)

Inhibits logging successful outgoing response packets.

no-dropped-dhcp-packets (17)

Inhibits logging dropped DHCP packets.

no-dropped-bootp-packets (18)

Inhibits logging dropped BOOTP packets.

no-failover-activity (19)

Inhibits logging normal activity and some warning messages logged for failover. However, serious error log messages continue to appear.

activity-summary (20)

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).

no-invalid-packets (21)

Inhibits logging invalid packets.

no-reduce-logging-when-
busy (22)

Inhibits reducing logging when receive buffers reach 66%.

no-timeouts (23)

Inhibits logging time-outs of leases and offers.

minimal-config-info (24)

Reduces the number of configuration messages in the log.

no-failover-conflict (25)

Logs conflicts between failover partners.


Adjust the mcd-blobs-per-bulk-read attribute value to tune DHCP start and reload times. Generally, a higher mcd-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.