Cisco Network Registrar

Release Notes for Cisco CNS Network Registrar 3.5.1


Table Of Contents

Release Notes for Cisco Network Registrar 3.5(1)


System Requirements

Software Compatibility

User Interface and Server Interoperability

What's New in This Release

DHCP Failover Tool Documentation Corrections

Using the DHCP Failover Configuration Tool

Error Codes Documentation Correction

DNS Documentation Correction

LDAP Documentation Correction

Microsoft Systems Management Server (SMS) Documentation Corrections

For the Network Registrar CLI Reference Guide

For the Network Registrar User's Guide

DHCP Extension Point Response Dictionary Corrections


Using Thread-safe Extensions

Cisco Connection Online

Documentation CD-ROM

Special Considerations

Reverting to a Previous Version from Release 3.5 or higher

Resolved and Unresolved Bugs for 3.5(1)

Release Notes for Cisco Network Registrar 3.5(1)

These release notes describe the caveats, new features, and documentation corrections for Cisco Network Registrar 3.5(1).

Warning   The upgrade procedures for Solaris have changed from earlier revisions. Read Chapter 1 of the Getting Started with Network Registrar before proceeding. Do not run the Solaris pkgrm command before reviewing these instructions. The pkgrm command may delete your data.

This document contains the following sections. (The page number is listed after each item.)

Introduction     2

System Requirements     2

Software Compatibility     3

User Interface and Server Interoperability     3

What's New in This Release     3

DHCP Failover Tool Documentation Corrections     4

Error Codes Documentation Correction     8

DNS Documentation Correction     9

LDAP Documentation Correction     9

Microsoft Systems Management Server (SMS) Documentation Corrections     9

DHCP Extension Point Response Dictionary Corrections     10

Cisco Connection Online     12

Documentation CD-ROM     13

Special Considerations     13

Resolved and Unresolved Bugs for 3.5(1)     13


The release of Cisco Network Registrar 3.5(1) contains the following components:

CD-ROM containing the software

Network Registrar Concepts Guide

Getting Started with Network Registrar

Network Registrar CLI Reference Guide

Network Registrar User's Guide

Cisco Network Registrar 3.0 AIX Installation

Cisco Network Registrar 3.0 HP-UX Installation

Network Registrar Web GUI Installation Instructions

Release Notes for Cisco Network Registrar 3.5(1)

System Requirements

Network Registrar 3.5(1) runs on Windows NT 4.0, Windows 2000, Solaris 2.5.1, Solaris 2.6, and Solaris 7. Network Registrar's 3.5(1) GUI also runs on Windows 95 and Windows 98.

For all OS platforms, Cisco recommends that you install the current service pack (Windows) or recommended patch cluster (Solaris, AIX, HP-UX).

Windows NT 4.0 must be run with service pack 3, or for Y2K compliance, service pack 4 or 5.

Refer to the following sources about Y2K patch clusters:

— Solaris 2.5.1, Solaris 2.6, and Solaris 7 have been tested with the current Sun patch cluster. For up-to-date information, refer to the Cisco Y2K site, For information about the latest Solaris patches, see
— For AIX (4.3), see
— For HPUX, see

lists the server platforms under which Cisco Network Registrar operates and specifies whether each has a protocol server, CLI, or GUI.

Table 1 Network Registrar Platforms

Protocol Servers?

Windows NT
















You can run the servers and the associated user interfaces on the same platform, or you can run the servers on one platform and the user interfaces on another.

Software Compatibility

Network Registrar 3.5(1) is compatible with the following:

DHCP clients—All RFC 1954, 2131, and 2132 compliant DHCP and BOOTP clients

DNS servers—Any DNS server compliant with RFC 2136 Dynamic DNS Updates and RFC 1995 and 1996 (IXFR and NOTIFY)

LDAP servers—Any LDAP v2 or v3 server, including servers from Netscape, Sun Microsystems, and Lucent Technologies

There is a known problem on Solaris that may cause the DHCP server to hang during initialization. The problem is described by Sun RFE 4071167. You can encounter the deadlock in the Solaris name resolver client by installing a linked set of patches from Sun, including 103663-08, and disabling host name caching in nscd (to improve name resolver client performance), which is recommended by Sun in RFE 1243174.

To avoid this problem, do one of the following:

Do not install the linked patch set.

Do not disable "nscd" host name caching.

Install patch 103663-11 (Solaris 2.5.1) or 105755-01 (Solaris 2.6).

User Interface and Server Interoperability

describes the typical outcome when you run different versions of the user interface and the servers:

Table 2 Network Registrar Interoperability




Network Registrar runs successfully.



Network Registrar UI displays the error message "Unsupported version number." The server is unaffected.

What's New in This Release

The following sections describe the new features in Cisco Network Registrar Release 3.5(1). Features incorporated between Release 3.0 and Release 3.5(1) have the release number in which they first appeared noted in parentheses. These features are listed in order of importance.

Improved DHCP server performance, especially an ability to respond effectively to bursts of DHCP client activity (3.0T).

DNS force transfer allows a site to manually force a secondary server to request a zone transfer when the primary server has newer information (3.0(1)T).

CNR DHCP previously supported only 10 network interfaces. The limit is now based on what the OS supports (3.5).

The single interface restriction for DHCP on AIX and HP-UX was removed. HP-UX and AIX versions now have the same capabilities for multiple interfaces as other supported platforms (3.5).

Messages were added that indicate progress by the DHCP server in accessing an LDAP server. This feature makes it easier to diagnose problems interfacing to LDAP (3.0(1)T).

Support for Solaris 7 was added (3.0T).

The DHCP Failover Configuration tool performs two primary tasks. First, it compares the configuration of two servers set up as a failover pair and reports configuration differences. Second, it reads the configuration of one server and generates an nrcmd command file that, when executed, produces a configuration for the other server in a failover pair (3.5).

Logging can be disabled when an extension instructs the DCHP server to drop a packet (3.5).

The DHCP server can be configured to discard all but the most recent n packets (where n is configurable) out of a queue of packets from a given client. This feature can reduce performance problems when dealing with malfunctioning DHCP clients that flood the server with packets (3.5).

The send-reservation command adds a DHCP reservation without requiring a server reload (3.5).

SMS integration enables the CNR DHCP server to send information about leased addresses to a Microsoft SMS server (3.5).

The read-only user interface capability allows a site to have one user interface in use with full read/write privileges and a several user interfaces with just read privileges (3.0(1)T).

DHCP lease query allows a Cisco uBR to discover the mapping between DHCP clients' IP and MAC addresses. This is necessary in some customer environments to prevent theft of service on a cable data network (3.0(1)T).

There is improved support for large numbers of DHCP scopes (3.0(1)T).

The TFTP server was integrated into the CNR server framework, along with enhancements to the CNR user interfaces to support the TFTP server (3.0T).

Giaddr identification was added to the log message that specifies no leases are available so that when the incoming packet log setting is disabled, you can determine which scope is out of addresses (3.5).

All log messages now have unique error codes. These codes also show up in those log messages placed in the NT event log (3.0T).

DHCP Failover Tool Documentation Corrections

Chapter 10 of the Network Registrar User's Guide contains instructions about the DHCP Failover Configuration tool. Additional capabilities were added to this tool after the documentation was printed. Replace the "Using the DHCP Failover Configuration Tool" section beginning on page 10-27 with the following text.

Using the DHCP Failover Configuration Tool

To ensure proper failover operation, both servers must have identical configurations for all scopes participating in failover. The DHCP Failover Configuration tool ensures that users can duplicate configurations without having to manually type the configurations on the backup machine, saving time and preventing errors. To accomplish this task, it uses the cnrFailoverConfig command.

The types of configuration options currently supported are:

Policy properties and dhcp-options

Scope properties and ranges

DHCP server properties

Reservation lists


Scope selection tags

Note   This tool does not compare or export client entries, either in MCD or in LDAP.

This tool easily allows duplication and comparison of a simple main and backup failover configuration. It can facilitate configuring a symmetric or backoffice failover configuration. You may have to edit the output of the cnrFailoverConfig -clone command.

The three main steps in the failover configuration process are the following:

1 Make a copy of the main server's configuration in the form of an nrcmd batch file, using the cnrFailoverConfig -clone command.

2 Load the nrcmd batch file on the backup server.

3 Check to make sure both servers are identical, using the cnrFailoverConfig -compare command.

The following sections explain these steps.

Step 1: Cloning the Main Server's Configuration

The following procedure shows how to clone the main server's configuration:

Step 1 Set up the main server's configuration.

Step 2 Save the configuration.

nrcmd> save

Step 3 Reload the main server.

nrcmd> server DHCP reload

Step 4 Create a clone file on the main server from the NT or Solaris command line.

cnrFailoverConfig -clone -mc main_cluster_name -mu main_user_name -mp 
main_password -o output_filename

Note   The DHCP server allows you to create a shortcut of the failover configuration by configuring only the name of the partner server and omitting the local server's name. If you use this shortcut, the file produced by the cnrFailoverConfig -clone command will not work when loaded on the backup server. You must manually configure the name of the main server on the backup server.

Table 10-3 describes the cnrFailoverConfig -clone commands.

Table 10-3 cnrFailoverConfig -Clone Commands 



Invokes the cloning operation.


Specifies the name of the main server.


Specifies the name of the user on the main server.


Specifies the password of the main user.


Specifies the name of the output file.

Step 2: Loading the Batch File on the Backup Server

Perform these steps to load the batch file on the backup server.

Step 1 Switch to the backup server and pipe the batch file you created in the previous section to the backup server from the DOS command line.

nrcmd -b < output_filename

Step 2 Save the configuration.

nrcmd> save

Step 3 Reload.

nrcmd> server DHCP reload

Step 4 Wait a few minutes and issue the getRelatedServers command to verify that the two servers are in sync.

nrcmd> server DHCP getRelatedServers

For more information about this command, see the "Monitoring Failover Server Status" section on page 10-18.

Step 3: Comparing the Configurations of the Main and Backup Servers

Perform these steps to compare the configurations of the main and backup servers.

Step 1 Navigate to the window where you can display the configuration of the main server.

Step 2 Invoke the compare command from your system's command line.

cnrFailoverConfig -compare -mc main_cluster_name -mu main_user_name -mp 
main_password  -bc backup_cluster_name  -bu backup_user_name -bp backup_password 
-verbose -o output_filename

Step 3 Display the output file for discrepancies. Since configuration differences between the two servers are marked with the word "difference," you can search for that word within your text editor. Also, if you do not specify the -verbose switch, only the differences appear in the output file.

Note   If you have a symmetric failover configuration, you must compare twice. alternating main and backup.

If there are differences, go back to the "Step 1: Cloning the Main Server's Configuration" section on page 10-28 and correct the problem.

Table 10-4 describes the cnrFailoverConfig -compare commands.

Table 10-4 cnrFailoverConfig -Compare Commands 



Invokes the compare operation.


Specifies the name of the main server.


Specifies the name of the user on the main server.


Specifies the password of the main user.


Specifies the name of the backup server.


Specifies the name of the user on the backup server.


Specifies the password of the backup user.


Specifies the name of the output file.


Creates verbose output for the output file. If you do not specify this switch, the output is be summarized in a few lines, detailing only where the difference is found.

Benign Comparison Errors

When you use the cnrFailoverConfig -compare command after using the cnrFailoverConfig -clone command to create a configuration on a partner server, the compare sometimes correctly detects a benign comparison error. In versions of CNR prior to 3.5(1), the system_default_policy was configured by default with an incorrect value for the rarely used path-mtu-plateau-tables option. This option had an odd number of values, while it should have only an even number of values. When the output from a database with this older incorrect value for path-mtu-plateau-tables is imported into a CNR 3.5(1) system, it will be rejected. The default value for the path-mtu-plateau-tables in a CNR 3.5 system has the correct, even number of values.

The following comparison failure then displays:

612 Compare policy properties - policy(system_default_policy) on main(sfo5)
to backup(sfo6)
623 Policy difference - policy(system_default_policy) option

This comparison failure does not signal a serious problem. You can correct it by resetting the value of the path-mtu-plateau-tables option on the system that is the source of the -clone operation so that it matches that of its partner.

Warning   If you use the script produced by the -clone function of the cnrFailoverConfig command as input to a version of nrcmd prior to 3.5, the incorrect values in the path-mtu-plateau-tables option will cause nrcmd to slightly corrupt the DHCP configuration database, resulting in some options in the system_default_policy being deleted. This will result in considerable -compare failures. You can either add the missing options by hand, or edit the script produced by the -clone function to remove the path-mtu-plateau-tables, then rerun.

Error Codes Documentation Correction

In the Network Registrar CLI Reference Guide, please replace Table B-1 with the following table:

Table B-1 Error Codes 





Some lease requests failed


Invalid RR


Possibly leftover lock


No Server Found


Not Found


Read only property


No Policy Found


Too many


Unknown command


Unknown keyword


Unknown parameter


Too many arguments


Too few arguments


No response to lease request


Unexpected response from server


No match


Duplicate object


Import Failure




Open failed


No MAC Address Found


No Lease Found


Generic error


Login Failure


Permission denied


Could not lock database


Login Required


Connection Failure


Server Failure

DNS Documentation Correction

Page 2-57 of the Network Registrar CLI Reference Guide should contain this information in the Exception Method section:

In the early versions of CNR, when the global forwarding option is set, any query for the subzone delegation went to the forwarder, not to the server that was authoritative for that subzone.

In this release, the resolution exception now covers subzone delegations. If the global forwarding is set and a subzone is in the resolution exception list, the query for that subzone goes to the name server that appears in the exception list, not to the forwarder.

LDAP Documentation Correction

Page 7-1 of the Network Registrar Concepts Guide contains this note:

Note   Network Registrar ships with the LDAP version 1.0 libraries.

It should read:

Note   Network Registrar ships with the LDAP version 3.0 client libraries.

Microsoft Systems Management Server (SMS) Documentation Corrections

Add the following information to the respective pages of the Network Registrar CLI Reference Guide and the Network Registrar User's Guide about System Management Server, Version 2.0.

For the Network Registrar CLI Reference Guide

sms-lease-interval Property

Add this new DHCP property to Table 2-12 on page 2-35:

sms-lease-interval—Used to set the time interval between sending addresses to SMS. After you install a future release of Microsoft BackOffice Resource Kit (which will contain an enhanced version of smsrsgen.dll), reduce this interval or set it to 0.

updateSms Command

Add this information to the updateSms command in Table 2-45 on page 2-132:

The updateSms command has been modified to take an optional parameter "all," which sends out all leased addresses from the DHCP server to SMS. If this parameter is not provided, only those addresses leased since the last time this command was run are sent.

If you reload the DHCP server when updateSms is processing, it stops the command. Note that the command does not resume after the DHCP server is brought back up again.

Performing Network Discovery

Add this section to page 2-133:

To use the updateSms command on NT, you follow these preparatory steps:

Step 1 In the Startup tab of AIC Server Agent 2.0, turn on "This Account."

Step 2 Provide the name of the administrator account of the domain and the corresponding password

Step 3 Start the service.

For the Network Registrar User's Guide

sms-network-discovery and DHCP Failover

Add the following note after the first paragraph of Chapter 10:

Note   On UNIX, if you are enabling DHCP failover, then you may want to set the sms-network-discovery property to enable the computing client os-type for leased addresses. This information may be useful if you are using an NT partner server and you want to use the updateSms command on that server.

DHCP Extension Point Response Dictionary Corrections

Appendix D of the Network Registrar CLI Reference Guide contains information about the response dictionary data items. Please incorporate these corrections.


In Table D-5 of the Network Registrar CLI Reference Guide, the entry for reply-ipaddress reads:

"The IP address to use when replying to the DHCP client. Read just after pre-packet encode."

It should read:

"The IP address to use when replying to the DHCP client. Read just after pre-packet-encode. If you change the value of this data item in the pre-packet-encode extension point, the IP address you place in this data item should be for a system that is able to respond to ARP queries for that IP address (unless the IP address is for a broadcast IP address). Even if unicast is enabled and the broadcast flag is not set in the DHCP request, the local ARP cache will not be set with a mapping from a new reply-ipaddress in the pre-packet-encode extension point to the MAC address in the DHCP request."

Using Thread-safe Extensions

All C/C++ extensions must be thread-safe, or the DHCP server will not operate correctly, and will crash in ways that are extremely difficult to diagnose. All libraries and library routines that these extensions use must also be thread-safe.

On several platforms make sure the runtime functions being used are really thread-safe. Check the platform documentation for each function. On several platforms special thread-safe versions are provided (often functionname_r). Since Windows NT provides different versions of libraries for multithreaded applications that are thread safe, this problem usually doesn't apply.

Be aware that if any thread makes a non thread-safe call, it affects all of the threads that are making the safe or locked version of the call. This can cause memory corruptions, crashes, and so on.

Diagnosing these problems is extremely difficult, since these failures are rarely apparent. To cause a crash, you need very high server loads or multiprocessor machines with many processors. Sometimes you need running times of several days.

Since some runtime or third-party libraries might be making non-thread-safe calls that you cannot detect, check your executables to see what externals are being linked in (nm on UNIX).

If any of the functions in the following list are called in the versions without the _r suffix by any thread on Solaris, the entire DHCP server process is compromised. Remember that the interfaces to the _r versions of these library routines may be different on different platforms. For example, ctime_r has a different number of arguments on AIX than on Solaris.

Reentrant Functions for Unsafe Interfaces:









































Cisco Connection Online

Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:





Modem:  From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.

For a copy of CCO's Frequently Asked Questions (FAQ), contact For additional information, contact

Note   If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or

Documentation CD-ROM

Cisco documentation and additional literature are available in a CD-ROM package shipped with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at,, or

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.

Special Considerations

This section contains information about special considerations for Network Registrar.

Reverting to a Previous Version from Release 3.5 or higher

If you install Network Registrar Release 3.5, then revert to a previous version, you must delete C:\Program Files\Network Registrar\Data\DB\vista.taf (Windows NT) or /var/nwreg2/data/db/vista.taf (Solaris) before loading nrcmd, ntwkreg, or any other program that accesses the database. Otherwise an error message displays.

Resolved and Unresolved Bugs for 3.5(1)

The list of resolved and unresolved bugs is available on the Cisco Network Registrar CD-ROM. To display it, navigate your browser to this file: CD-ROM Drive/docs/BugList.html.