|
|
These release notes contain information that you should read to ensure a smoothly running Cisco Network Registrar software.
The release notes contain the following sections:
Cisco provides technical support only for registered technical contacts with a current support agreement at each customer site. If you purchased the Cisco Network Registrar from an authorized Cisco distributor or partner, technical support is available directly from them.
If your site does not have a current support agreement, you may call Cisco's Technical Support department for a per-call fee. Please have a major credit card number handy when making this call. For customers in the warranty period, 90 days from the date of purchase, there is no charge for this call.
You can contact Technical Support as follows:
| Information about you | |
|---|---|
Your name |
|
Company |
|
Telephone |
|
Fax |
|
E-mail address |
|
| Information about your host configuration | |
Brand and model |
|
OS (VMS, Solaris, Windows NT, etc.) |
|
| Problem description |
|
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback on the toolbar, and then select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
Cisco Network Registrar 2.0 includes several new features, as well as several enhancements to the general operation of the product. They can be divided into the following categories:
Cisco Network Registrar 2.0 supports the DNS incremental transfer (IXFR) and NOTIFY protocols. In large domains with frequent updates, you will not be able to rely on normal DNS zone transfers to update secondary DNS servers. Zone transfers take too long to propagate information, because the secondary server only polls the primary server every couple of hours or so, and it is inefficient to transfer all the domain data when only a few records may have changed. If you try to reduce the update delays by configuring secondary servers to poll more often, you will have even more excess zone transfer traffic.
Cisco Network Registrar solves these problems by adding the IETF standard incremental transfer (RFC 1995) and NOTIFY (RFC 1996) protocols. Incremental transfer allows two DNS servers that both implement the protocol to transfer only the records that have changed, which minimizes network traffic while still maintaining a complete copy of the domain at the secondary server. The NOTIFY protocol also allows the primary server to alert secondary servers to changes it has made in the domain data, which minimizes propagation delays. To enable incremental zone transfer use the nrcmd command ixfr-enable, or from the Cisco Network Registrar GUI, click the Options tab in the DNS Server Properties dialog box and select the ixfr-enable option. To enable notify use the nrcmd command notify, or from the Cisco Network Registrar GUI, click the Options tab in the DNS Server Properties dialog box and select the notify option.
Cisco Network Registrar 2.0 supports round-robin processing of address records. When there are multiple address records for a single name, Cisco Network Registrar rotates the order of addresses each time it responds to a lookup for that name. This process offers a simple form of load-balancing across multiple addresses. To enable round-robin processing use the nrcmd command round-robin, or from the Cisco Network Registrar GUI, click the Options tab in the DNS Server Properties dialog box and select the round-robin option.
Cisco Network Registrar 2.0 supports the importing of named.boot BIND files. If you have an existing BIND server (4.x) you can easily migrate your configuration to Cisco Network Registrar. You can import your forward, reverse, and secondary zones with a single command. For more information on using the import command, see the Network Registrar CLI Reference Guide.
Cisco Network Registrar 2.0 introduces Class-of-Service configuration, which allows you to configure network clients differently depending on which class they belong to. (An early version of this capability was available in AIC Network Registrar Software Release 1.2p4.) Network administrators can define a number of service classes, then assign network clients to these classes based on MAC address. Alternately, an extension point can be used to write a small program to determine which class a client belongs to. Each class then defines the DHCP policy it will use, as well as selection criteria for appropriate address scopes. If desired, scope selection criteria, policies, or even a DNS hostname can be defined for individual clients. Cisco Network Registrar can even be configured to reject address requests from clients that are not configured in the system. A wide variety of automated network control capabilities can be built on top of the Cisco Network Registrar Class-of-Service configuration, including automated registration systems or differentiated network access privileges. For more information on configuring Class-of-Service, see the Network Registrar CLI Reference Guide, or from the Cisco Network Registrar GUI, click the Client and Client-Classes tabs in the DHCP Server Properties dialog box.
Cisco Network Registrar 2.0 is the first IP Address Management system to integrate IP address leasing with directory systems that implement the Lightweight Directory Access Protocol (LDAP). Cisco Network Registrar can update an existing LDAP object with up to 16 different parameters describing a lease, including IP address, DNS name, and lease expiration time. Cisco Network Registrar can also read client definitions for the Class-of-Service processing from an LDAP-enabled directory. For more information on configuring LDAP integration, see the Network Registrar CLI Reference Guide.
Cisco Network Registrar 2.0 also introduces the the registrar architecture's unique extension points, which allow customizing DHCP operations with administrator-supplied routines. These routines, known as extensions, can consist of loadable TCL code or C/C++ dynamic libraries, and are loaded into one of seven predefined extension points. The extension points defined in Cisco Network Registrar 2.0 allow more control of Class-of-Service logic and Dynamic DNS updates, as well as integration with other network services. For more information on configuring extension points, see the Network Registrar CLI Reference Guide.
Cisco Network Registrar 2.0 has been extended to support MCNS-compliant cable modems, and a wider range of legacy BOOTP devices. Cisco Network Registrar 2.0 also supports Dynamic DNS for BOOTP devices. (An early version of these capabilities was available in AIC Network Registrar 1.2p4.) For more information on configuring DHCP for MCNS cable modems, and configuring BOOTP, see the Network Registrar CLI Reference Guide.
Cisco Network Registrar 2.0 defines enhanced DHCP scope controls for special situations. A scope can now be deactivated, which means that no leases or renewals will be permitted from this scope. You might deactivate a scope while defining a new scope, before it is completely set up, or while decommissioning an old scope, until all outstanding leases have expired. A scope can also be put into a renew-only state, so that no new leases will be granted, but outstanding leases will be renewed. You might put a scope in a renew-only state when new clients are supposed to be directed into a newer scope. For more information on configuring DHCP scopes, see the Network Registrar CLI Reference Guide.
Cisco Network Registrar 2.0 supports a complete command-line interface (CLI), as a companion to the existing Windows and Solaris/Motif GUIs. The CLI runs on the supported versions of both Solaris and Windows NT, and is suitable for the nongraphical administration of Cisco Network Registrar and the scripting of common tasks.
One advanced capability of the CLI is the listaddr command, which exports address-status data for every address under Cisco Network Registrar management. The listaddr command reports a variety of information for each address, including its status (for example, available or statically configured), its DNS name (if any), and the MAC address of the client that holds the current lease.
For more information about listaddr and other CLI commands, see the Network Registrar CLI Reference Guide.
The following sections provide information you should be aware of when using Cisco Network Registrar:
Cisco Network Registrar 2.0 and later is compatible with the following software:
Cisco Network Registrar 2.0 runs on Windows 95, Windows NT 3.51, Windows NT 4.0, Solaris 2.5.1, and Solaris 2.6.
For all OS platforms, Cisco recommends that you install the following current service pack (Windows NT) or recommended patch cluster (Solaris):
103461-20 | 103558-11 | 103566-25 |
103582-15 | 103594-13 | 103603-06 |
103612-38 | 103622-09 | 103630-09 |
103640-17 | 103663-09 | 103680-01 |
103686-02 | 103690-05 | 103738-05 |
103743-01 | 103817-02 | 103866-05 |
103879-04 | 103900-01 | 103901-08 |
103934-06 | 103959-06 | 104010-01 |
104166-03 | 104212-09 | 104246-05 |
104266-01 | 104283-03 | 104317-01 |
104331-04 | 104334-01 | 104338-02 |
104433-06 | 104516-03 | 104533-03 |
104613-01 | 104650-02 | 104654-03 |
104692-01 | 104708-09 | 104736-03 |
104776-02 | 104795-02 | 104893-01 |
104935-01 | 104956-04 | 104958-01 |
104960-01 | 104968-02 | 104976-03 |
105004-09 | 105050-01 | 105092-01 |
105251-01 | 105299-01 | 105344-01 |
105352-01 | 105520-01 |
|
105216-01 | 105393-01 | 105518-01 |
105615-02 | 105621-01 | 105665-01 |
105667-01 | 105379-01 | 105786-01 |
105669-02 | 105558-01 | 105375-03 |
105357-01 | 105356-01 | 105407-01 |
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. The deadlock in the Solaris name resolver client can be encountered by installing a linked set of patches from Sun, including 103663-08, and disabling host name caching in nest (to improve name resolver client performance), which is recommended by Sun in RFE 1243174. To avoid this problem, you can do one of the following:
This software release of Cisco Network Registrar contains the following components:
Cisco Network Registrar includes Windows NT servers and GUI, and Solaris servers, and a Motif GUI.
Cisco Network Registrar 2.0 CD includes both platforms servers and GUIs.
When you install the Solaris servers without the Solaris GUI, the installer will default to just a server-only installation. It will not prompt you for a GUI-only or complete installation.
You can run the servers and the associated GUI on the appropriate platform, or you can run the servers on one platform and the GUI on another.
In addition to the hard-copy manuals, Adobe .pdf versions of the documentation are available. These files are located in the /docs directory on the Cisco Network Registrar 2.0 CD-ROM.
When you run the installation, it automatically detects an existing AIC Network Registrar 1.x installation, and asks if you would like to upgrade your database.
To upgrade from a previous software release of AIC Network Registrar, follow the instructions in Getting Started with Network Registrar.
When you upgrade, the following occurs:
The following changes were made between AIC Network Registrar and Cisco Network Registrar:
When upgrading from AIC Network Registrar 2.0 to Cisco Network Registrar 2.0, follow these steps to keep your database:
Step 1 Log in as root.
Step 2 Run the program pkgparam to list the variable settings:
pkgparam -v AICnwreg2 | grep DIR
Copy down the settings of the DATADIR, LOGDIR, and TEMPDIR.
Step 3 Run the pkgrm program:
pkgrm AICnwreg2
AIC Network Registrar services will be shut down if they are running.
Step 4 Install Cisco Network Registrar.
For complete installation instructions, see Getting Started with Network Registrar.
(a) When the installation program asks where to put the files, specify the settings you noted in step 2.
(b) When the installation program asks whether to overwrite the database, select no.
After you successfully complete the installation, the Cisco Network Registrar services will start up automatically.
The following sections describe information that is useful when running Cisco Network Registrar Software Release 2.0 and later versions.
You can upgrade some or all of your servers and GUIs. The only requirement is that the servers and GUIs are the same software release number.
Cisco Network Registrar now includes a check to see whether the GUI and server software release numbers match. If there is a mismatch, the GUI fails to attach and displays a dialog box that contains the message incorrect RPC version. When you upgrade your server to Software Release 2.0, you must also upgrade all GUIs that administer the server, or the old GUI versions will be unable to attach.
In previous software releases of AIC Network Registrar, this check was not included, and connecting to a Software Release 1.1 server from a Software Release 1.2 GUI, or vice-versa, could cause display cache corruption or actual data corruption.
The CLI provides a scripting interface for the configuration of Cisco Network Registrar.
username@machine-name.process-id-number
The following sections describe new DHCP features and implementation details that you should know about.
The DHCP server subsystem has been enhanced in several ways to make troubleshooting and debugging DHCP client problems more straightforward.
You can enable a built-in packet sniffer with the CLI using the DHCP server parameter log settings. This packet sniffer produces formatted dumps of all DHCP input packets and all output packets produced by the DHCP server in the DHCP server log file. Although this capability is not suitable for everyday use (because it rolls the log files too frequently as well as slowing down the DHCP server), this capability can greatly ease the process of troubleshooting DHCP problems.
In addition, there is an example extension distributed on the kit (called dextrace), which will look for a particular MAC address in every input packet. When it finds that MAC address, it will enable packet sniffing for just that input and any corresponding output packet. You can configure this extension using the CLI, and the configuration commands are in the example source file for dexextension.c. This extension places only a very small load on the server, and is suitable for long-term use when trying to diagnose some DHCP problem in which a troublesome MAC address is known, but it is not possible (or perhaps not convenient) to manually stimulate that DHCP client directly in order to find the problem.
Cisco Network Registrar Software Release 2.0 has significantly enhanced diagnostic capability to allow you to quickly resolve Class of Service configuration problems. Cisco Network Registrar now has two DHCP log-settings to help in diagnosing these problems. For more information, see the Network Registrar CLI Reference Guide.
In Cisco Network Registrar 2.0 support for secondary subnets has been generalized and extended. In previous software releases, all of the possible scopes on a subnet needed to be configured with the same capabilities (unless Class of Service support, or client-class, was used to direct client requests toward specific scopes).
In Cisco Network Registrar 2.0 when multiple scopes are available on a particular subnet (through the use of secondary subnet), the DHCP server will search through all of them looking for a scope that meets the needs and requirements of an incoming DHCP client request. For more information, see the Network Registrar CLI Reference Guide.
Cisco Network Registrar 2.0 offers improved dynamic DNS update from DHCP servers. In AIC Network Registrar 1.2, if the DHCP server could not update DNS because the DNS server was down or unreachable, it would retry the update only at lease renewal. In Cisco Network Registrar 2.0, the DHCP server stores all pending DNS update information on disk. If DHCP cannot communicate with a particular DNS server, it periodically tests if communications have been reestablished, and submits all pending updates when they have been. This test occurs typically once every 40 seconds until communication with DNS is reestablished.
host.example.com. MX 10 mail.example.com.
host.example.com. MX 10 Mail.EXAMPLE.Com.
alias.example.com. CNAME host.example.com.
alias.example.com. MX 10 mail.example.com.
alias.example.com. CNAME host.example.com.
alias.example.com. CNAME other.example.com.
You cannot print Solaris help topics.
Network Registrar's support of DNS and DHCP servers is highly flexible and scalable. Consequently its performance is affected by many factors, from the size of the client installation base to network topology. In order to optimize the performance of Network Registrar, the following general configuration and network management practices are recommended.
The driving factor in sizing your Network Registrar configuration is DHCP (and BOOTP) traffic. The number of devices on a network or the physical size of a network does not necessarily determine the amount of DHCP traffic. Many other factors, such as DHCP client configuration, usage patterns, DHCP lease duration, DHCP renew time, and DHCP rebind time all affect the volume of DHCP traffic. The following configuration guidelines are designed around low, moderate and high volume DHCP traffic.
If you anticipate relatively low DHCP traffic volume on your network, Network Registrar DNS and DHCP servers can run on the same cluster. The scope, or scopes in the DHCP server, if desirable, can be configured to perform Dynamic DNS updates to the appropriate zones (both forward and reverse) in the DNS server, on the same cluster. Clients can use this primary DNS for address resolution.
If your network has low DHCP volume, you can effectively run Network Registrar on a single-processor or dual-processor NT server.
If you anticipate moderate DHCP traffic volume, the DHCP server should run on one cluster. If you plan to use Dynamic DNS, configure the DHCP server to perform Dynamic DNS updates to a primary DNS for the forward zone (or zones) on a second cluster, and to a primary DNS for the reverse zone (or zones) on a third cluster. Collapse the name space into a single secondary DNS so that it receives zone transfers for both the forward and reverse zones. Clients can use this secondary DNS for name resolution.
If your network has moderate DHCP volume, you should run Network Registrar on dual-processor NT systems, or on single-processor Solaris systems.
If you anticipate high DHCP traffic, treat your network as multiple instances of the moderate DHCP traffic, described previously. At each logical division (for example, buildings, regions, subnets) create DNS subzones. Set up a central, zone-wide DNS server, with subzone delegation to the appropriate collapsed secondary DNS servers for the subzones. Clients will use this domain-wide primary DNS for name resolution.
The DHCP server running on a single cluster can contain scopes to support multiple subzones. You can also configure the DHCP server to perform Dynamic DNS updates to a forward zone (or zones), and to a reverse zone (or zones), residing on separate clusters. The collapsed secondary DNS for the forward and reverse zones would receive zone transfers from the forward and reverse DNS primary servers.
You can replicate this architecture for multiple subzones, thereby allowing Network Registrar to scale to the largest enterprises without incurring performance restrictions.
If your network has high DHCP transaction volume, you should run Network Registrar on high-end, multiple-processor NT systems, or on dual-processor Solaris systems. See Figure 3.
Posted: Thu Nov 18 16:25:47 PST 1999
Copyright 1989-1999©Cisco Systems Inc.