|
|
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.)
The release of Cisco Network Registrar 3.5(1) contains the following components:
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).
Table 1 lists the server platforms under which Cisco Network Registrar operates and specifies whether each has a protocol server, CLI, or GUI.
| Platform | Protocol Servers? | CLI? | GUI? |
Windows® NT | Y | Y | Y |
Solaris® | Y | Y | Y |
AIX® | Y | Y | N |
HP-UX® | Y | Y | N |
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.
Network Registrar 3.5(1) is compatible with the following:
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:
Table 2 describes the typical outcome when you run different versions of the user interface and the servers:
| GUI and CLI | Server | Outcome |
|---|---|---|
3.5 | 3.0 | Network Registrar runs successfully. |
3.0 | 3.5 | Network Registrar UI displays the error message "Unsupported version number." The server is unaffected. |
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.
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.
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:
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.
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
Table 10-3 describes the cnrFailoverConfig -clone commands.
| Command | Description |
|---|---|
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. |
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.
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.
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.
| Command | Description |
|---|---|
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. |
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 'path-mtu-plateau-tables': main(sfo5)=68,296,508,1006,1492,2002,4352,8166,17914,32000,65535 backup(sfo6)=68,296,508,1006,1492,2002,4352,8166,17914,32000cc
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. |
In the Network Registrar CLI Reference Guide, please replace Table B-1 with the following table:
| Number | Description |
|---|---|
100 | OK |
201 | Some lease requests failed |
202 | Invalid RR |
203 | Possibly leftover lock |
301 | No Server Found |
302 | Not Found |
303 | Read only property |
304 | No Policy Found |
305 | Too many |
306 | Unknown command |
307 | Unknown keyword |
308 | Unknown parameter |
309 | Too many arguments |
310 | Too few arguments |
311 | No response to lease request |
312 | Unexpected response from server |
313 | No match |
314 | Duplicate object |
315 | Import Failure |
316 | Invalid |
317 | Open failed |
318 | No MAC Address Found |
319 | No Lease Found |
320 | Generic error |
401 | Login Failure |
402 | Permission denied |
403 | Could not lock database |
404 | Login Required |
501 | Connection Failure |
502 | Server Failure |
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.
Page 7-1 of the Network Registrar Concepts Guide contains this note:
It should read:
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.
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.
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.
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.
Add the following note after the first paragraph of Chapter 10:
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."
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.
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:
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
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 http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
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.
This section contains information about special considerations for Network Registrar.
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.
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.
Posted: Thu Feb 3 11:10:37 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.