Guest

Cisco Network Registrar

Release Notes for Cisco Network Registrar, 7.0.1

  • Viewing Options

  • PDF (440.4 KB)
  • Feedback
Release Notes for Cisco Network Registrar 7.0.1

Table Of Contents

Release Notes for Cisco Network Registrar 7.0.1

Contents

Introduction

Before You Begin

System Requirements

Network Registrar Communications Security Option

Software and Standards Compatibility

Interoperability

Installation and Upgrade Notes

General Installation

Red Hat Linux Installation

Upgrade Considerations

Moving Network Registrar to a New Machine

SDK Installation

Installing on Linux or Solaris

Installing on Windows

Testing Your Installation

New and Changed Features

Implementation Notes

Chatty Client Filter

Consistency Rules Reporting Tool

Lease History Database Compression Utility

General Comments on Running cnr_leasehist_compress

Running Compression on Solaris and Linux

Running Compression on Windows

Failover Pair Renaming

New DHCP Extensions

New Data Items in the Request Dictionary

New Data Items in the Response Dictionary

Limitations and Restrictions

Documentation Errata

System Requirements

Configuration File (cnr.conf) Changes

Linux Silent Installation

Lightweight Directory Access Protocol

DHCP Reply Options

Lease Import Function

Using Expressions

Creating Expressions

HA DNS Server Pair

DHCP Extensions in Response Dictionary

DHCP Failover Configuration

Simple Network Management

Reverse Zones

Vendor Option 43

Caveats

Related Documentation

Notices

OpenSSL/Open SSL Project

License Issues

Obtaining Documentation and Submitting a Service Request


Release Notes for Cisco Network Registrar 7.0.1


September 12, 2008

These release notes are for Cisco Network Registrar Release 7.0.1. This document describes system requirements, installation and upgrade notes, new features and implementation, and caveats.

Contents

These release notes cover the following topics:

Introduction

Before You Begin

Software and Standards Compatibility

Interoperability

Installation and Upgrade Notes

New and Changed Features

Implementation Notes

Limitations and Restrictions

Documentation Errata

Caveats

Related Documentation

Notices

Obtaining Documentation and Submitting a Service Request

Introduction

This release of Network Registrar resolves a number of customer-reported issues with earlier releases and includes additional enhancements.

Before You Begin

Review the following sections before installing Network Registrar 7.0.1.

System Requirements

Review these system requirements before installing the Network Registrar 7.0.1 software:

Java—You must have the Java Runtime Environment (JRE) 5.0 (1.5.0_06) or later, or the equivalent Java Development Kit (JDK), installed on your system. (The JRE is available from Sun Microsystems on its website.)

Operating system—Cisco recommends that your Network Registrar machine run on the Windows, Solaris, or Linux operating systems as described in Table 1. Network Registrar must run on 32-bit operating systems.

User interfaces—Network Registrar currently includes two user interfaces: a web UI and a command-line interface (CLI):

Web UI—Runs on a minimum of Microsoft Internet Explorer 6.0 (Service Pack 2), Mozilla Firefox 1.5, or Netscape 7.0 and requires JRE 5.0 (1.5.0_06).

CLI—Runs in a Windows, Solaris, or Linux command window.


Tip Include a network time service (such as NTP) in your configuration to avoid time differences between the local and regional clusters, so that aggregated data appears consistently at the regional server.


Table 1 Network Registrar System Recommendations 

Operating System
Solaris
Linux
Windows
Component
     

OS version1

Solaris 9 or Solaris 102

Red Hat Enterprise Linux ES 4.0 only

Windows Server 2003

Disk space3

2 x 73/146 SAS4 drives

With basic DHCP and optimal hardware configuration:

SATA5 drives with 7500 RPM drive > 500 leases/second

SAS drives with 15K RPM drive > 1000 leases/second

(Recommended hard drive 146 GB)

Memory6

16 GB

4 GB (small networks), 8 GB (average networks), or 16 GB (large networks)

1 Network Registrar must run on 32-bit operating systems.

2 Network Registrar 7.0.1 supports 128-KB block sizes in the Solaris 10 ZFS.

3 Higher I/O bandwidth usually results in higher average leases per second.

4 Serial Attached SCSI.

5 Serial Advanced Technology Attachment (Serial ATA).

6 Faster CPU and more memory typically result in higher peak leases per second. More than two cores for Linux or Windows do not typically result in higher performance.



Note Network Registrar no longer supports Red Hat 3.0, and Solaris 8. If you are running one of these operating systems, you must upgrade to Red Hat 4.0, or Solaris 9 or 10 before installing or upgrading Network Registrar 7.0.1. (See the "Installation and Upgrade Notes" section.)


Network Registrar Communications Security Option

The Network Registrar Communications Security Option release 2.0 and earlier will fail to install on Windows for Network Registrar 7.0.1. You need to upgrade to the Security Option release 2.0.1. If you install Security Option Release 2.0, you will see an error message similar to:

Failed to change file permissions in the `C:\Program Files\Network Registrar\Local 
directory'

Software and Standards Compatibility

This release of Network Registrar complies with the applicable Request for Comments (RFCs), protocols, standards, and Internet Engineering Task Force (IETF) drafts of earlier releases.

With the features introduced in this release, the software conforms to these additional documents:

Dynamic Host Configuration Protocol (DHCP) clients—Comply with RFCs 4388 (Leasequery DHCPv4) and 5007 (Leasequery DHCPv6), 4776 (Option for Civic Addresses Configuration Information), 4833 (Timezone Options), 4280 (Options for Broadcast and Multicast Control Servers), 4174 (IPv4 DHCP Option for Internet Storage Name Service)

Domain name servers (DNS) servers—Comply with 4703 (Resolution of Fully Qualified Domain Name [FQDN] Conflicts), 4701 (DNS Resource Record for Encoding DHCP Information [DHCID RR]), and 4704 (DHCPv6 Client FQDN Option).

DHCPv6 functionality—Comply with 4580 (DHCPv6 Relay Agent Subscriber-ID Option), 4649 (DHCPv6 Relay Agent Remote-ID Option), and 4994 (DHCPv6 Relay Agent Echo Request Option).


Note Network Registrar 7.0.1 is compatible with Cisco Broadband Access Center 4.0.


Interoperability

The Network Registrar 7.0 and later protocol servers interoperate with 6.0 and later protocol servers. However, the 7.0.x high-availability (HA) DNS server interoperates only with the 6.2 and 6.3 HA DNS servers.

When configuring DNS updates from DHCPv6 lease activity, Cisco strongly recommends that you use Network Registrar 7.0 or later DNS servers because these updates use the new DHCID resource record to identify the client using the name or address.

Only Network Registrar 7.0 and later support the DHCID resource record (RR) feature. DNS updates from DHCPv4 lease activity still use TXT RRs; and, therefore, you can use earlier versions of the Network Registrar DNS server with DHCPv4.

The regional Central Configuration Management (CCM) server interoperates with earlier versions of Network Registrar.

Installation and Upgrade Notes

Review the following notes before installing Network Registrar 7.0.1 or upgrading from a previous release. For full installation and upgrade procedures, see the Cisco Network Registrar Installation Guide.

This section covers:

General Installation

Red Hat Linux Installation

Upgrade Considerations

Moving Network Registrar to a New Machine

SDK Installation

General Installation

Review these points before beginning a new installation or an upgrade:

Network Registrar 7.0 and later implement the FLEXlm licensing mechanism; therefore, you must obtain a FLEXlm license file.

The installation program prompts you for the license file. You can defer submitting a license file during the upgrade, but you must provide one when you invoke the web UI or the CLI. License keys obtained for pre-7.0 versions of Network Registrar no longer function.

The Network Registrar installation program for Windows does not try to modify ACLs to restrict access to installed files and directories. If you want to restrict access to these files and directories, use the native Microsoft utilities cacls and icacls to manually change file and directory permissions. For more information, see the Cisco Network Registrar Installation Guide 7.0.

Windows, Solaris, and Linux installations occur through:

Windows—Windows-based InstallShield setup program.

Solaris—The pkgadd command.

Linux—The install_cnr script that uses RPM Package Manager (RPM).

On Windows, close all currently running applications, including any antivirus software.

On Windows, ensure that you uncheck the Dr. Watson Visual Notification check box. If checked, this option prevents the servers from restarting automatically if a failure occurs until you respond to a pop-up dialog box. The Visual Notification check box in Dr. Watson is checked by default.

Execute C:\WINNT\system32\DRWTSN32.exe, uncheck the Visual Notification check box, and click OK. (You can perform this step after installation.)

Due to changes in the behavior of the Windows installer, you now require a new silent installation response file to successfully perform unattended installations of Network Registrar. The installer will fail to perform unattended installations properly if you use a response file that was generated for Network Registrar 7.0.

To avoid losing the most recent log entries when the Application Event Log is full in the Windows Event Viewer, check the Overwrite Events as Needed check box in Event Log Settings for the Application Log. If the installation process detects that this option is not checked, it displays a warning message advising corrective action.

Because Network Registrar maintains lock files in the \Temp directory on Windows and the /tmp directory on Solaris or Linux, do not delete these directories when Network Registrar is running.

You cannot run the Network Registrar DNS, DHCP, or TFTP servers concurrently with any other DNS, DHCP, and TFTP servers. In many Windows 2000 and 2003 server systems, these services are enabled and running by default. If the Network Registrar installation process detects that a conflict exists, it displays a warning message. Before installing Network Registrar, take the appropriate action to disable the conflicting servers.

Network Registrar includes a list of informational, activity, warning, and error messages that it logs during certain operating conditions. Obtain this list in HTML files for each component as links from a MessageIdIndex.html file, which, by default, is in:

Windows—C:\Program Files\Network Registrar\
{Local | Regional}\docs\msgid\MessageIdIndex.html

Solaris and Linux/opt/nwreg2/{local | regional}/docs/msgid/MessageIdIndex.html

Red Hat Linux Installation

Installing Network Registrar on Red Hat Linux requires that the 32-bit OpenLDAP library be installed; otherwise, the DHCP server may fail to start.

To verify if openldap is installed, enter:

# rpm -ql openldap | more

If the openldap package is installed, Cisco copyright and version information should appear; otherwise, an error message will appear, indicating a missing LDAP library (with the .so file extension).

To install the openldap package, enter:

# yum install compat-openldap.i386

Upgrade Considerations

Network Registrar 7.0.1 supports upgrades from releases 6.1.x, 6.2.x, 6.3.x and 7.0. When you install the software, the installation program automatically detects an existing version and upgrades the software to the latest release. The program first prompts you to archive existing Network Registrar data. If the program encounters errors during the upgrade, it restores the software to the earlier release.


Note If you are upgrading from a version earlier than 7.0, review the Release Notes for any intervening Network Registrar versions before upgrading, to fully understand all of the changes incorporated in this release. The 7.0.1 Release Notes document only the changes since 7.0.


Network Registrar no longer supports the Red Hat 3.0 and Solaris 8 operating systems. Back up your Network Registrar data and upgrade your operating system before installing this latest release. (See Table 1 for currently supported operating systems.)

During an upgrade, Network Registrar now displays any pre-existing HTTPS configuration defaults for the keystore filename and password to enable a secure connection for web UI logins (CSCee14992). If you have enabled HTTPS, and are unaware of the keystore filename and password at the time of the upgrade, you can preserve HTTPS connectivity during the upgrade, and re-enter the defaults when prompted.


Note The default keystore filename and password appear only if you are upgrading from 6.3.1 or later versions, or reinstalling the 7.0.1 version.


To upgrade to Network Registrar 7.0.1:


Step 1 Ensure that your environment meets the current system requirements. (See the "System Requirements" section.)

Step 2 Use the currently installed release to complete any configuration changes in progress, so that the existing database is consistent before you perform the upgrade.

Step 3 Ensure that no pending database tasks result from recent edits. You can confirm that the task lists are empty by viewing the CCM and MCD Tasks pages under the Administration menu in the web UI. Wait until both lists are empty before proceeding with the update.

Step 4 Stop the Network Registrar server agent and back up the existing database:

Windows—net stop nwreglocal

Solaris and Linux—/etc/init.d/nwreglocal stop

Step 5 Copy the data directory in your installation path to a .zip file.

Step 6 Upgrade your operating system, if necessary.

Step 7 Upgrade Network Registrar. Note that:

The recommended practice is to upgrade the regional cluster before upgrading any local clusters, because an older version of a regional cluster cannot connect to newer local clusters (CSCsm61420).

For upgrades from version 6.1 of DHCP failover servers, upgrade the main server before the backup server, because mixed-mode failover synchronization back to version 6.1 (which is needed for the period until the backup is also upgraded) is supported only from main to backup.


Note When upgrading (especially a pre-6.2 cluster) to 7.0.1, the upgrade process typically occurs in two distinct phases:

During the installation. This phase ends when the Installation completed successfully message appears.

When the CCM server (and the DNS server, as in the case of an upgrade from 6.1) run for the first time after an installation. This phase may take an extended period of time to end, especially with large DNS configurations. If the upgrade is in progress, you will not be able to access Network Registrar from the web UI, the CLI, or the SDK; the server also will not respond to service requests during this process.

You can monitor the progress of the upgrade by tailing the ccm_startup_log and name_dns_1_log log files. Then, check for a message similar to:
ccm_startup Info Server 0 06006 server started.

This message indicates that the upgrade is complete and that you can now access Network Registrar.


Step 8 If the upgrade fails for any reason, you can revert to the earlier Network Registrar version. The Network Registrar installation program provides the capability of archiving the existing product configuration and data when upgrading to a newer version of the product. If you chose this option, and the upgrade process fails, use the following procedure to revert to the earlier product version and configuration:


Caution To complete this process, you must have access to the product installer and license key or license file for the earlier Network Registrar version. Any attempt to proceed otherwise may destabilize the product.

If the installer had successfully performed the upgrade but you want to roll back to the earlier version at some later point, this procedure can result in network destabilization and data loss; for example, you will lose updates made to the Network Registrar database after the upgrade, including DHCP lease data and DNS dynamic updates.

a. Verify that the archive directory (cnr_archive.tar) that you specified during the upgrade process exists and is valid. These examples assume the default archive location provided during installation. Ensure that the path to the cnr_archive.tar file reflects the value of the archive directory that you specified during installation. If you are using:

Windows—C:\Program Files\Network Registrar\
{Local.sav | Regional.sav}

Solaris and Linux—/opt/nwreg2/{local.sav | regional.sav}

b. Uninstall Network Registrar using the procedure described in the Cisco Network Registrar Installation Guide.

c. Other than the contents of the specified archive directory, delete any remaining files and directories in the Network Registrar installation paths.

d. Reinstall the original version of Network Registrar. Ensure that you follow the reinstallation procedure described in the Cisco Network Registrar Installation Guide that is specific to the original product version.

e. After the installation ends successfully, stop the Network Registrar server agent:

Windows—net stop nwreglocal

Solaris and Linux—/etc/init.d/nwreglocal stop

f. Delete the contents of the Network Registrar install-path/data subdirectory.

g. Extract the contents of the backup file to the newly reinstalled version of Network Registrar.

1. Change to the root directory of the filesystem. On Windows, this directory would be the base drive (such as C:\); on Solaris and Linux, it would be /.

2. Using the fully qualified path to the archive directory containing the cnr_archive.tar file, extract the archive. These examples assume the default archive location provided during installation. Ensure that the paths to the tar executable and cnr_archive.tar file reflect the value of the archive directory that you specified during installation.

Windows—"C:\Program Files\Network Registrar\{Local.sav | Regional.sav}\tar.exe"
xf "//C/Program Files/Network Registrar/{Local.sav | Regional.sav}/cnr_archive.tar"


Note Running the tar executable requires that you change the directory delimiters for the tar filepath to forward slashes (/) and that the drive letter be specified using double slashes (//) without the colon (:).


Solaris and Linux—/opt/nwreg2/{local.sav | regional.sav}/tar -xf /opt/nwreg2/
{local.sav | regional.sav}/cnr_archive.tar

h. Start the Network Registrar server agent:

Windows—net start nwreglocal

Solaris and Linux—/etc/init.d/nwreglocal start

i. Verify if the previous configuration, including scopes and zones, is intact.


See also the "CCM Database Index Repair" section.

Moving Network Registrar to a New Machine

You might want to move an existing Network Registrar installation to a new machine. By following this procedure, you can preserve your original data on the old machine if a problem arises during installation on the new machine (CSCso06297):


Step 1 Ensure that the new machine runs the same operating system (Windows, Solaris, or Red Hat Linux) as the old machine.

Step 2 Stop the server agent on the old machine:

Windows—net stop nwreglocal

Solaris and Linux—/etc/init.d/nwreglocal stop

Step 3 Zip the data directory on the old machine.

Step 4 Copy the .zip file to the same location on the new machine.

Step 5 Install Network Registrar on the new machine (on Solaris and Linux, use the -a option for an upgrade; for example: pkgadd -a install-path/solaris/nwreg2/install/cnradmin -d install-path/solaris nwreg2). The installation will detect an upgrade and will do so based on the copied data.

Step 6 Ensure that any IP address references in Network Registrar are updated to reflect the IP address of the new server.

The data from the old machine is now migrated to the new machine.


SDK Installation

This section documents how to install the Network Registrar SDK on the Linux, Solaris, and Windows platforms. Before installing the SDK, ensure that you have Java Runtime Environment (JRE) 5.0 (1.5.0_06) or later, or the equivalent Java Development Kit (JDK), installed on your system.

Installing on Linux or Solaris

To install the Network Registrar SDK on a Linux or Solaris platform:

1. Extract the contents of the distribution .tar file.

a. Create the SDK directory:

% mkdir /cnr-sdk 

b. Change to the directory that you just created and extract the .tar file contents:

% cd /cnr-sdk
% tar xvf sdk_tar_file_location/cnrsdk.tar 

2. Export your LD_LIBRARY_PATH and CLASSPATH environment variable:

% export LD_LIBRARY_PATH=/cnr-sdk/lib
% export CLASSPATH=/cnr-sdk/classes/cnrsdk.jar:. 

Installing on Windows

To install the Network Registrar SDK on a Windows platform:

1. Extract the contents of the distribution .tar file.

a. Create the SDK directory:

> md c:\cnr-sdk

b. Change to the directory that you just created and extract the .zip file contents:

> c:
> cd \cnr-sdk
> tar xvf sdk_tar_file_location\cnrsdk.tar

You may optionally use Winzip to extract cnrsdk.tar to the C:\cnr-sdk directory.

2. Set your PATH and CLASSPATH variables:

> set PATH=%PATH%;c:\cnr-sdk\lib
> set CLASSPATH=c:\cnr-sdk\classes\cnrsdk.jar;.

Testing Your Installation

On Linux or Solaris, the following test program verifies that you have set your PATH or LD_LIBRARY_PATH correctly:

% java -jar /cnr-sdk/classes/cnrsdk.jar

On Windows, the following test program verifies that you have set your CLASSPATH correctly:

> java -jar c:\cnr-sdk\classes\cnrsdk.jar

New and Changed Features

Table 2 briefly describes new or modified features in the 7.0.1 release. The detailed implementation notes for some of these features is described in the "Implementation Notes" section.

Table 2 New and Changed Features 

Feature
Summary

CCM Database Index Repair

In rare circumstances, CCM database index definitions might be lost for a given class of objects. You might notice this issue when the object list appears empty, but you know that the configuration exists. This release resolves this issue so that the upgrade repairs the database. A standalone utility, rebuild_indexes, is also available to repair the database if you cannot resolve this issue through an upgrade (CSCsm89823).


Caution Stop the Network Registrar server agent and ensure that the CCM server is not running before you run the rebuild_indexes utility.

You can run this utility from:

Windows—...\{local | regional}\bin\rebuild_indexes.exe

Solaris and Linux—...{local | regional}/usrbin/rebuild_indexes

The syntax for the rebuild_indexes utility is:

rebuild_indexes -d path [options]

-d path—Specifies the path to the existing CCM database, which is the Network Registrar installation directory.

options are:

-c—Checkpoints the database before exiting.

-z {letters}=level—Enables debugging at a specified level, by using the standard Network Registrar debug tracing syntax.

The rebuild_indexes utility checks and updates:

1. The configuration database and ensures that all needed index definitions are present, then adds any missing ones.

2. Indexes for dangling references to objects not found in the object database, then removes these references.

3. All objects for missing index entries, then adds the missing ones.

Chatty Client Filter

The Chatty Client Filter was enhanced with the ability to drop DHCPRELEASE packets (CSCsm18078). For more information, see the "Chatty Client Filter" section.

DNS Scavenging Process

If you enable scavenging for the DNS server, ensure that the top of zone (@) namesets are protected. In releases that predate Network Registrar 6.3.1, scavenging could remove these namesets, thereby rendering the zones useless. This issue was resolved and these namesets are no longer removed (CSCsm90243). However, scavenging may remove other unprotected resource records, so ensure that you protect resource records to prevent scavenging.

List Consistency Rules in the Web UI

The List Consistency Rules page was modified to include some new consistency rules and remove ones no longer deemed useful (CSCsm62824). The rules were also renamed and the option of selecting all rules and clearing the selections was added. Running the rules opens the Consistency Rules Violations page that has a clearer, more categorized display of the results and offers the option to convert to an even-spaced font. You can also toggle to a more detailed view that includes the object classes for the violations.

Last Transaction Time Granularity

The default value of the last-transaction-time-granularity attribute has changed from 60 seconds to 1 week. The previous default value (60 seconds) caused unnecessary disk I/O (and failover binding updates) when a client communicated with the server beyond the last-transaction-time-granularity seconds ago, and no other significant lease changes, such as extending the lease expiration time, occurred (CSCso93326). This behavior meant that events such as head-end reboots or power failures resulted in significant disk I/O (and failover binding updates) because these events caused clients to return before the normal lease-renewal time.

With the default changed to 1 week, this behavior is less likely. This new default, however, means that the client-last-transaction-time may not accurately reflect the last time the client communicated with the server (under the conditions outlined previously). And, if your deployment depended on this attribute being updated whenever the client communicated with the server, you may need to explicitly set the last-transaction-time-granularity attribute to a value appropriate for the deployment.

Note The last-transaction-time-granularity attribute is effectively not used when you have disabled defer-lease-extensions. Therefore, if you have disabled defer-lease-extensions, this change in the default value does not impact you.

When the server is heavily loaded and has run low on request or response buffers, it temporarily sets the last-transaction-time-granularity value to 1 year to reduce its load.

Consistency Rules Reporting Tool

You can now use the new cnr_rules consistency rules tool from the command line to check for database inconsistencies (CSCso69958). Earlier versions of Network Registrar provide this functionality only from the web UI. For more information, see the "Consistency Rules Reporting Tool" section.

Lease History Database Compression Utility

The cnr_leasehist_compress utility was added to Network Registrar to compress regional cluster lease history databases (CSCsl75914). This utility does not compress the data directly in the databases, but copies the existing data into new databases that are optimized to be as compact as possible. For more information, see the "Lease History Database Compression Utility" section.

Dynamic DNS Update

We recommend that you do not enable the update-dns-first attribute because:

The DHCP server cannot send a DHCPACK message until the DNS server is updated. This update could take a long time because of the large number of requests that may be pending and the latency in addressing those requests.

If the DNS server is down or unresponsive, the DHCP server cannot send the DHCPACK.

The previous conditions are compounded if certain clients do not allot enough time for the DHCP server to respond with a DHCPACK and restart the DHCP state machine at DHCPDISCOVER (CSCso31677).

Failover Pair Renaming

Network Registrar is now more flexible if you must rename failover-pair objects (CSCsm69817). For more information, see the "Failover Pair Renaming" section.

Resource Records Generation on BIND Imports

Support for the $GENERATE directive was added so that you can generate resource records when importing data from a BIND file (CSCeh30526).

Multiple Interface Users

The Network Registrar user interfaces support multiple, concurrent users. However, if two users try to access the same object record, a Modified object error will occur for the second user (CSCso16056). If you receive this error while editing data, do the following:

Web UI—Cancel the edit, refresh the list to view the latest changes, then redo the edit, if it is still valid after the other user's changes.

CLI—Use the session cache refresh command to clear the current edits, view the changes, make changes if they are still valid after the other user's changes.

Pushing Subnets to Cisco uBR10000 Routers

The issue of not being able to push subnets to Cisco 10K routers with Cisco IOS version 12.0 was resolved in this release (CSCsk08605). When pushing a subnet to a Router Interface Configuration (RIC) server of type Cable Interface, Network Registrar first checks for a bundle-id attribute value of Router Interface; if the value exists, it pushes the associated subnet to the bundle interface. If the bundle-id value does not exist, it creates a bundle interface based on data from the physical router, then pushes the subnet to the bundle interface. Note that this action could involve some additional processing time.

New DHCP Extensions

There are now new data items for the extensions dictionary (CSCsh45882). For a list of new data items in the request and response dictionary, see the "New DHCP Extensions" section.

Scopes and Selection Tags in Network Tree

The network tree page functionality is restored to display the relationship between primary and secondary subnets, and also to display the related primary and secondary scopes and selection tags (CSCsi56243). The tree contains links to view or edit subnets and, at the local server, links to view or edit the scopes.

For more information on primary and secondary subnets and scopes, see the "Configuring Multiple Subnets on a Network" section in the Cisco Network Registrar User's Guide 7.0.

DNS Resource Records Filter

When you perform a search for resource records from all the listed zones in the DNS Search page, Network Registrar might not return results by using the Zone List filter type (CSCsl13353). Therefore:

To search for a single zone, use the complete zone name as the value for the Regular Expression filter type.

To retrieve results for multiple zones:

a. Use the complete zone name of each zone in the list as the value for the Regular Expression filter type.

b. Manually merge the results of each zone search.

CableLabs Option Definitions

The CableLabs option definitions that are shipped in Network Registrar have been updated to be in line with the latest CableLabs specification (CSCso83648). Refer to the CableLabs website for more information.

CLI Prompt Change

When you use the session set current-vpn=name command to set the VPN used for subsequent operations from the global (default) VPN to the specified VPN, the nrcmd prompt changes. In Network Registrar 7.0.1, the VPN name is appended to the nrcmd prompt when the current VPN is not the default (global VPN). For example:

nrcmd> session set current-vpn=example1
nrcmd [VPN=example1]>

Implementation Notes

This section describes the implementation notes for these features:

Chatty Client Filter

Consistency Rules Reporting Tool

Lease History Database Compression Utility

Failover Pair Renaming

New DHCP Extensions

Chatty Client Filter

The Chatty Client Filter was enhanced with the ability to drop DHCPRELEASE packets (CSCsm18078). The Chatty Client Filter is the ChattyClientFilter.cpp file located in the examples/dhcp/dex directory of the installation path. It can be used in a DHCP extension environment for service-provider networks where the subscriber's home network might be using a variety of uncontrolled devices. Some of these devices have known issues such as repeatedly generating a sequence of DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, and after 30 seconds, DHCPRELEASE messages. The devices repeat this cycle and cause a significant unproductive load on the DHCP server and DNS updates, because:

A new lease history record is created for each cycle, impacting lease history.

The DNS server removes the Resource Records and then adds them back for every cycle.

Clients in this network send a large number of packets.

The Chatty Client Filter monitors client requests, based on the MAC address, and disables the client if it generates more than a certain number of packets in a certain duration. However, the server re-enables the client and accepts incoming packets if the client adheres to the configured threshold.

You can now use the Chatty Client Filter to drop DHCPRELEASE packets sent from a DHCPv4 client. Dropping the packets prevents the lease history database from growing out of bounds, which can be the case with certain home gateways in the service-provider network where firmware errors occur. The implementation uses the -d option, which specifies the packet count of DHCPRELEASE packets in a given number of seconds. The setup on a Solaris/Linux system might be:

nrcmd> extension dexChattyClientFilter create dex libdexextension.so 
dexChattyClientFilter init-entry=dexChattyClientFilterInitEntry init-args="-d 2 120" 


Note For Windows, replace libdexextension.so with dexextension.dll.


nrcmd> dhcp attachextension post-packet-decode dexChattyClientFilter 

In such a setup, the server drops DHCPRELEASE packets if it receives more than two of these packets from the same client in a 120-second interval, and resumes DHCPRELEASE processing when the client does not send a DHCPRELEASE for at least 120 seconds. To ensure that the server does not process DHCPRELEASE packets, configure the time interval to be at least (packet-count + 2) * 30 seconds.


Note If you want to use this version of the Chatty Client Filter on an older version of Network Registrar, you can download the ChattyClientFilter_v1_3.tar file from the Cisco Network Registrar downloads at the CCO Software Center.


Table 3 describes the qualifying options available with the Chatty Client Filter.

Table 3 Chatty Client Filter Options 

Option
Description
Default

-d packets seconds

Drops DHCPRELEASE packets if more than the specified count is received in the specified time interval. Once the client sends more than the packets number of DHCPRELEASEs in the given seconds interval, the server drops the packets. The server keeps dropping future DHCPRELEASEs until the client suspends sending them for the seconds interval. (DHCPv4 clients only.)

Disabled

-h packet-count

Sample hits to disable.

15 packets

-i seconds

Sample time interval.

30 seconds

-l packet-count

Quiet hits to leave disabled.

5 packets

-q seconds

Quiet time interval.

10 seconds

-s

Silently discards dropped packets.

Disabled

-n

Enables DHCPNAK. The server sends a DHCPNAK packet to a disabled client if it attempts to renew a lease with a DHCPREQUEST. When the client restarts its DHCP machine and sends a DHCPDISCOVER, the server enables the client.

Note When you use this option, ensure that you attach the Chatty Client Filter to the check-lease-acceptable extension point.

Disabled

-r seconds

Controls the statistics reporting interval.

300 seconds (5 minutes)


Consistency Rules Reporting Tool

You can now use the new cnr_rules consistency rules tool from the command line to check for database inconsistencies (CSCso69958). Earlier versions of Network Registrar provide this functionality only from the web UI. You can also use the command-line tool to capture the results of the rule in a text or XML file.

The cnr_rules tool is located at:

Windows—...\bin\cnr_rules.bat

Solaris and Linux—.../usrbin/cnr_rules

To run the cnr_rules tool, enter:

> cnr_rules -N username -P password [options]

where:

-N username—Authenticates using the specified username.

-P password—Authenticates using the specified password.

options—Describes the qualifying options for the tool, as described in Table 4. If you do not enter any options, the command usage appears.

Table 4 cnr_rules Options 

Option
Description

-list

Lists the available consistency rules.

Note The list of available commands is tailored to the permissions of the administrator specified in the value of the -N option.

For example, enter:

> cnr_rules -N admin -P changeme -list 

-run [rule-match]

Run the available rules. Optionally, you can run a subset of the available rules by applying a case-insensitive rule-match string.

For example:

To run all rules, enter:

> cnr_rules -N admin -P changeme -run

To run only the rules whose names contain the string dhcp, enter:

> cnr_rules -N admin -P changeme -run dhcp

Tip To match a string containing spaces, enclose the string using double-quotation marks ("). For example:
> cnr_rules -N admin -P changeme -run "router interface"

-details

Includes details of the database objects that violate consistency rules in the results.

For example, to run the DNS rules and include details of the database object in the results, enter:

> cnr_rules -N admin -P changeme -run DNS -details

-xml

Generates rule results in an XML file.

Note When using the -xml option, the -details option is ignored because the XML file includes all the detailed information.

For example, enter:

> cnr_rules -N admin -P changeme -run -xml

-path classpath

Changes the Java classpath that is searched to locate the available consistency rules (optional). Use this option only at the direction of a support engineer to run a new, custom consistency rule.

-interactive

Runs the tool in an interactive session.

For example, enter:

> cnr_rules -N admin -P changeme -run -interactive
RuleEngine [type ? for help] > ?
Commands:
  load <class>     // load the specified rule class
  run <rule-match> // run rules matching a string, or '*' for all
  list             // list rules by name
  xml              // toggle xml mode
  detail           // toggle detail mode (non-xml only)
  quit             // quit RuleEngine

You can redirect the output of any of these preceding commands to another file. To capture the rule results in a:

Text file:

> cnr_rules -N username -P password -run -details > filename.txt

XML file:

> cnr_rules -N username -P password -run -xml > filename.xml

Lease History Database Compression Utility

The cnr_leasehist_compress utility was added to Network Registrar to compress regional cluster lease history databases (CSCsl75914). This utility does not compress the data directly in the databases, but copies the existing data into new databases that are optimized to be as compact as possible.


Caution Use the cnr_leasehist_compress utility only with the regional cluster lease history database, and when you suspect that the database grew significantly, particularly because of DHCPRELEASE packets.

During the copy operation, you can use this utility to:

Trim records that are older than a certain interval of time—You would typically use the -t option. The interval that you specify with this option uses the Network Registrar time interval format; for example, 30d for 30 days or 1y for 1 year.

Merge records that belong to the same lease and client—You use the cnr_leasehist_compress utility to merge records that belong to clients who have reclaimed the lease on an IP address after releasing it. You would typically use the -m option. The interval that you specify with this option uses the Network Registrar time interval format; for example, 120s for 120 seconds or 2m for 2 minutes.

While merging records, the utility also corrects lease history records that were terminated abruptly or have an incorrect binding end time (that may have resulted from a subsequent lease operation). This option of merging records also addresses the vast number of records that are created by certain router configurations that introduce an additional load on the servers.

Before you run the cnr_leasehist_compress utility:

Stop the Network Registrar regional cluster; it does not operate on an active regional cluster database.

Note that you can use it to compress existing lease history data alone; it does not alter how the regional cluster collects future lease history records. If you suspect chatty clients, ensure that the DHCP server does not process DHCPRELEASE messages, because this results in rapid growth of lease history data. In such instances, you may need to run the utility periodically.

Note that you can use it if you are a service provider and suspect that the regional lease history in your network grew because some devices have known issues, such as repeatedly generating a sequence of DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, and after 30 seconds, DHCPRELEASE messages. You can choose to drop all DHCPRELEASE messages or those that belong to clients that exceed a configured threshold.

Note that it writes the new database in the most optimal manner. The new database can initially grow at a considerable rate, but it tapers back to normal after the additional lease history records are collected.

General Comments on Running cnr_leasehist_compress


Caution Follow every step in this procedure carefully. If you skip any step, you might lose lease history data. Note the lease history database that each task involves. Depending on the number of lease history records and the time taken to trim or merge the records, this utility may take several hours or days to run. You can interrupt the utility while it is running if the server reboots before the run is completed. You can resume it later; however, you must specify the same options that you have used in the previous run.

The install-path is the path in which you install Network Registrar.

Table 5 describes the qualifying options for the cnr_leasehist_compress utility.

Table 5 cnr_leasehist_compress Options 

Option
Description

-a

Appends all the lease history records in the temporary active database to those in the new database.

-c

Generates a report when more than a specified number of records are merged for a client. When used with the -f option, these records are transferred to a log file.

-d

Specifies a new destination database that contains the compressed lease history records.

-e attrlist

Overwrites the excluded merge attribute list.

-f file

Redirects most lease history record warnings to a log file.

-g

Uses the dbtxn-seq and dbtxn-generation attributes to generate a new sequence in the numbers that are assigned to all lease history records, which are written into the destination database.

-i ipaddr

Transfers the records of a particular IP address to a log file.

-l limit

Purges log files after the database reaches the preset limit of 20 files.

-m time-int

Merges lease records where the binding-start-time of a particular lease falls in the duration of the binding-end-time of the previous lease. The recommended value for this option is 120s.

-n

Compares adjacent records without merging them.

-p

Drops detailed lease history records. You can use this option only if you have enabled detailed lease history.

-q records

Sets an interval for a periodic progress report that is generated while the utility runs. The default value is 100000. For example:

+00:00:18 Read 100000 records (0 bad); trimmed 6717; merged 73370; 19912 
written (19.91%)

-r records

Limits the number of records that are read from the source database.

-s path

Specifies the source database from where the data is copied to a new database.

-t age

Specifies a value for trimming records that are older than a certain interval of time. Use the standard Network Registrar time interval for this option, such as 1y for 1 year or 30d for 30 days.

-v

Emits the version and exits.

-w

Limits the number of records that are written into the destination database.

-y

Alters the width of the dump of lease history records. This option is not recommended; however, you can use the value 132 30 for a 132-column output.

-z {letters}=level

Debugs the database, specified by using the standard Network Registrar debug tracing syntax.


Running Compression on Solaris and Linux

To run the cnr_leasehist_compress utility on Solaris and Linux:


Step 1 Add install-path/lib to the LD_LIBRARY_PATH to provide the utility with access to the Network Registrar libraries:

$ bash
# export LD_LIBRARY_PATH=install-path/lib:$LD_LIBRARY_PATH

Step 2 Stop the Network Registrar regional cluster:

# /etc/init.d/nwregregion stop

Step 3 Rename the original install-path/data/leasehist directory as install-path/data/oldleasehist. The /leasehist directory becomes the original database:

# mv install-path/data/leasehist \
# install-path/data/oldleasehist

Step 4 Create a new leasehist directory, which becomes the temporary active database:

mkdir install-path/data/leasehist

Step 5 Run the cnr_leasehist_compress utility to allow the regional cluster to resume activity:

# install-path/bin/cnr_leasehist_compress \
> -r 0 \
> -s install-path/data/oldleasehist \
> -d install-path/data/leasehist \
> -p


Caution Running these commands does not compress the original database. The -r 0 option is critical as it instructs the utility to create the temporary active database. The regional cluster remains active while the utility compresses the original database.

Step 6 Restart the Network Registrar regional cluster.

/etc/init.d/nwregregion start

You cannot, however, obtain lease history data from the original database at this time. The regional cluster collects new lease history data and transfers it to the temporary active database. The utility then merges the new lease history data into the new database.

Step 7 Create a new directory called install-path/data/newleasehist. This /newleasehist directory becomes the new lease history database:

mkdir install-path/data/newleasehist


Tip After the regional cluster populates the new database, you can optionally create this new directory on a different partition and copy it to the final location.


Step 8 Run the cnr_leasehist_compress utility to trim, merge, and compress the original database into the new database:

# install-path/bin/cnr_leasehist_compress \
> -s install-path/data/oldleasehist \
> -d install-path/data/newleasehist \
> -t trim-time-interval \
> -m merge-time-interval \
> -f /tmp/cnr-compress.log

If the original database contains any detailed lease history records, you must use the -p option to acknowledge that it is acceptable for the utility to not transfer these records into the new database. Otherwise, the utility does not run.

Step 9 Perform the following tasks to append any fresh lease history records to the new database after the utility processes the entire original database.


Note Do not restart the regional cluster until you have completed the following procedure. If the system reboots during the following procedure, repeat these steps.


a. Stop the Network Registrar regional cluster:

# /etc/init.d/nwregregion stop

b. Run the cnr_leasehist_compress utility to append new lease history records to the new database:

# install-path/bin/cnr_leasehist_compress \
> -a \
> -s install-path/data/leasehist \
> -d install-path/data/newleasehist \
> -m merge-time-interval \
> -f /tmp/cnr-append.log


Caution The -a option is critical as it indicates that the utility should append the lease history records in the temporary active database to those in the new database. We recommend that you use the same merge-time-interval value that you used for the original database.

c. After the utility completes the task of appending the newly collected lease history records, rename the temporary active database directory, install-path/data/leasehist, as install-path/data/tmpleasehist:

# mv install-path/data/leasehist \
install-path/data/tmpleasehist

d. Rename the new database directory, install-path/data/newleasehist, as install-path/data/leasehist:

# mv install-path/data/newleasehist \
# install-path/data/leasehist

Step 10 Start the Network Registrar regional cluster:

# /etc/init.d/nwregregion start

Step 11 Verify the regional lease history data by using the Network Registrar web UI.

Step 12 Archive the original database, in install-path/data/oldleasehist, and the temporary active database, in install-path/data/tmpleasehist. Ensure that you include all subdirectories and files when you archive the database.

Step 13 Delete the original database and temporary active database:

# rm -rf install-path/data/oldleasehist
# rm -rf install-path/data/tmpleasehist


Running Compression on Windows

To run the cnr_leasehist_compress utility on Windows:


Step 1 Stop the Network Registrar regional cluster:

> net stop nwregregion

Step 2 Rename the original install-path\data\leasehist directory as install-path\data\oldleasehist. This leasehist directory becomes the original database:

> rename install-path\data\leasehist install-path\data\oldleasehist


Tip You can move the original database to a different partition. Ensure that you copy the entire original /leasehist directory (including all its subdirectories and files) before you remove it.


Step 3 Create a new leasehist directory, this new leasehist directory becomes the temporary active database:

> mkdir install-path\data\leasehist

Step 4 Run the cnr_leasehist_compress utility to allow the regional cluster to resume activity:

> install-path\cnr_leasehist_compress -r 0 -s install-path\data\oldleasehist 
-d install-path\data\leasehist -p

Caution Running these commands, however, does not compress the original database. The -r 0 option is critical as it instructs the utility to create the temporary active database. The regional cluster remains active while the utility compresses the original database.

Step 5 Restart the Network Registrar regional cluster. However, you cannot obtain lease history data from the original database at this time. The regional cluster collects any new lease history data and transfers it to the temporary active database. The utility then merges the new lease history data into the new database:

> net start nwregregion

Step 6 Create a new directory called install-path\data\newleasehist. This newleasehist directory becomes the new lease history database:

> mkdir install-path\data\newleasehist


Tip After the regional cluster populates the new database, you can optionally create this new directory on a different partition and copy it to the final location.


Step 7 Run the cnr_leasehist_compress utility to trim, merge, and compress the original database into the new database:

> install-path\cnr_leasehist_compress -s install-path\data\oldleasehist 
-d install-path\data\newleasehist -t trim-time-interval -m merge-time-interval 
-f  c:\temp\cnr-compress.log

If the original database contains any detailed lease history records, you must use the -p option to acknowledge that it is acceptable for the utility to not transfer these records into the new database. Otherwise, the utility does not run.

Step 8 Perform the following tasks to append any fresh lease history records to the new database after the utility processes the entire original database.


Note Do not restart the regional cluster until you have completed the following procedure. If the system reboots during the following procedure, repeat these steps:


a. Stop the Network Registrar regional cluster:

> net stop nwregregion

b. Run the cnr_leasehist_compress utility to append new lease history records to the new database:

> install-path\cnr_leasehist_compress -a -s install-path\data\leasehist 
-d install-path\data\newleasehist -m merge-time-interval 
-f c:\temp\cnr-append.log

Caution The -a option is critical as it indicates that the utility should append the lease history records in the temporary active database to those in the new database. We recommend that you use the same merge-time-interval value that you used for the original database.

c. After the utility completes the task of appending the newly collected lease history records, rename the temporary active database directory, install-path\data\leasehist, as install-path\data\tmpleasehist:

> rename install-path\data\leasehist install-path\data\tmpleasehist

d. Rename the new database directory, install-path\data\newleasehist, as install-path\data\leasehist:

> rename install-path\data\newleasehist install-path\data\leasehist

Step 9 Start the Network Registrar regional cluster:

> net start nwregregion

Step 10 Verify the regional lease history data by using the Network Registrar web UI.

Step 11 Archive the original database, in install-path\data\oldleasehist, and the temporary active database, in install-path\data\tmpleasehist. Ensure that you include all subdirectories and files when you archive the database.

Step 12 Delete the original database and temporary active database:

> del/s install-path\data\oldleasehist
> del/s install-path\data\tmpleasehist


Failover Pair Renaming

Network Registrar is now more flexible when you rename failover-pair objects (CSCsm69817). The DHCP server uses the following algorithm to locate existing failover state information:

If a state exists for the failover-pair name and the local role (main or backup) in the state matches that of the failover pair, the server uses the state and does not create a new one. This situation allows for partner address changes.

If a state does not exist for the failover-pair name, but another state exists with the same local server role and backup address as defined for the failover pair, the server uses the state and does not create a new one. This situation allows for failover-pair name changes, when the partner address is not changed.

Otherwise, if a single failover state exists along with a single failover pair and the local server role matches, the server uses the state and does not create a new one. We recommend simple failover because the process of address and name changes are easy in simple failover configurations.

The behavior of failover pair objects differ based on the version of Network Registrar:

In the 6.2 releases, 6.3 releases earlier than 6.3.1, and the 7.0 release, any change in the failover-pair name invalidates the old failover-state. When you rename a failover pair, the servers assume that it is a new failover pair and failover partners lose earlier failover state information. Subsequently, when you restart the DHCP servers, the servers are in a mutual RECOVER-DONE mode in which there is no data in the server's stable storage. The servers continue to remain in this state until you restart them again.

In the 6.3.1 and 7.0.1 releases, the server supports changing the name or address for a failover pair, but not both simultaneously. If however, you change the role of the servers from backup to main or vice-versa, the server invalidates the old failover state.


Caution Do not change the partner address and failover-pair name at the same time by using a single DHCP reload if you want to retain the failover state in multiple failover relationships. To change the partner address and failover-pair name, change one parameter first, reload the DHCP server, then change the other parameter, and reload the DHCP server. We recommend that you ensure that the failover partners are in the NORMAL/NORMAL mode before reloading the server.

To rename failover-pair objects when upgrading from pre-6.2 releases, refer to CSCsm69817 for details as to whether the defect applies to the Network Registrar version and if any workaround exists.

New DHCP Extensions

This section describes new data items for the extensions dictionary (CSCsh45882).

New Data Items in the Request Dictionary

Table 6 lists the new data items in the request dictionary.

Table 6 Request Dictionary Specific Data Items 

Data Item
Value (Protocol: v4=DHCPv4, v6=DHCPv6)

override-client-id-data-type

string (v4, v6, read-only)

Returns the data type of the override-client-id, either nstr for string or blob for blob.

override-client-id-string

string (v4, v6)

Current client-id value in string format that replaces any client-id from the incoming packet (although both values are kept in the lease state database). For a get, if the override-client-id is not a string, the binary data is formatted as blob data, which is then returned as the string.


New Data Items in the Response Dictionary

Table 7 lists the new data items in the response dictionary.

Table 7 Response Dictionary Specific Data Items 

Data Item
Value (Protocol: v4=DHCPv4, v6=DHCPv6)

client-override-client-id-data-type

string (v4, v6, read-only)

Returns the data type of the client-override-client-id, either nstr for string or blob for blob.

client-override-client-id-string

string (v4, v6, read-only)

Current client-id value in string format that replaces any client-id from the incoming packet (although both values are kept in the lease state database). For a get, if the client-override-client-id is not a string, the binary data is formatted as blob data, which is then returned as the string.


See also the "DHCP Extensions in Response Dictionary" section.

Limitations and Restrictions

This section describes limitations and restrictions that you might encounter when using Network Registrar 7.0.1. They are:

When a DHCPv6 server supports clients with multiple leases, the demand on server memory increases. DHCPv4 supports only one lease per client, while DHCPv6 supports multiple leases. Therefore, a DHCPv6 server cannot support as many leases (clients) as can the same server running DHCPv4. For example, one DHCPv6 client might require 2,500 bytes of space compared to 1,000 bytes per DHCPv4 client. This comparison means that a machine that would support one million DHCPv4 clients will only support 400,000 DHCPv6 clients. We recommend that you allow three times the memory for DHCPv6 clients as you would for DHCPv4. As a result, you must:

Know how many prefixes per link are configured. If the configuration has two prefixes on a link, then with default configuration parameters, you have to cut in half the number of clients.

Use care if you enable inhibit-all-renews. When enabled, each client would use at least two leases, and perhaps three, depending on the grace and affinity times per prefix.

Be aware that the max-client-leases value is now preset to 50. A known issue exists, and if clients renew rapidly, you quickly reach the limit of 50 leases per client; thereby, consuming much more memory.

Another known issue is when Network Registrar 7.0.1 attempts to push a subnet to cable interface on a Cisco 10000 series uBR running Cisco IOS 12.2(8.22.34). Network Registrar can push subnets to Ethernet and GigaEthernet interfaces on the Cisco 10000 series, but it cannot push subnets to cable interfaces. Push subnets to bundled cable interfaces, instead.

Documentation Errata

This section covers:

System Requirements

Configuration File (cnr.conf) Changes

Linux Silent Installation

Lightweight Directory Access Protocol

DHCP Reply Options

Lease Import Function

Using Expressions

Creating Expressions

HA DNS Server Pair

DHCP Extensions in Response Dictionary

DHCP Failover Configuration

Simple Network Management

Reverse Zones

Vendor Option 43

System Requirements

This section described in Table 1 of the Release Notes for Cisco Network Registrar 6.3.1 is erroneously mentioned as "Network Registrar Minimum Requirements and Recommendations," instead of "Network Registrar System Recommendations."

Configuration File (cnr.conf) Changes

The cnr.conf file contains important configuration information. In rare cases, you might want to modify the file; for example, to exclude certain data from daily backups due to capacity issues. To do this, you need to add the appropriate settings manually. This information was not available when user documentation was completed (CSCsj57046).


Caution In most situations, we recommend that you use the default settings in this file. If you must change these settings, do so only in consultation with the Cisco Technical Assistance Center (TAC) or the Network Registrar development team.

The following settings are supported:

cnr.backup-dest—Specify the destination to place backed-up databases. Defaults to cnr.datadir if not specified.

cnr.backup-dbs—Provide a comma-separated list of the databases you want to back up. For a local cluster the default is ccm,dhcp,dns,mcd,cnrsnmp. For a regional cluster it is ccm,leasehist,subnetutil,replica.


Note The Raima (MCD) database is always included in a backup.


cnr.backup-files—Provide a comma-separated list of files and the complete path to the files that you want copied as part of the backup. Files are copied to cnr.backup-dest. The default action is to copy install/conf/mcdschema.txt.

cnr.dbrecover-backup—Specify whether to run db recover and db verify on a backed-up Sleepy Cat database. The default value is enabled. This setting is used for daily backups only, and manual backups ignore this setting. Disabling the automatic operation means that you must run the operation manually, preferably on a separate machine, or at a time when the Network Registrar servers are relatively idle.

cnr.daily-backup—Specify whether to run the daily backup. The default is enabled.

Linux Silent Installation

A Network Registrar silent installation or upgrade allows for unattended installation. When doing a silent installation on the Linux operating system, you must enter configuration values in a silent installation response file as described in Table 8 (CSCso43074).


Caution You must use a clean install mode silent-response file for fresh installations, and an "upgrade" mode silent-response file for product upgrades. The configuration values specified in the silent-response files are specific to a particular installation or upgrade environment, and cannot be mixed and matched. Unpredictable results occur if you attempt to use a silent-response file that does not exactly match the installation or upgrade system configuration.

Table 8 Silent-Response File Entries for Linux 

Silent-Response File Entry
Description and Value

BACKUPDIR=

Path in which to store the current Network Registrar installation files, but only if PERFORM_BACKUP=y (see PERFORM_BACKUP=); for example, /opt/nwreg2.sav.

CCM_PORT=

CCM port; default value is:

1234 if CNR_CCM_MODE=local

1244 if CNR_CCM_MODE=regional

CNR_CCM_MODE=

CCM mode; set to local or regional.

CNR_CCM_TYPE=

Introduced in Network Registrar 7.0; always set to cnr.

CNR_EXISTS=

If set to y (recommended), tries to delete any open CLI connections when installing or upgrading; otherwise, basically deprecated.

CNR_LICENSE_FILE=

For Network Registrar 7.x and later only, the fully qualified path to the license file.

DATADIR=

Fully qualified path to the data directory; for example, /opt/nwreg2/regional/data.

JAVADIR=

Fully qualified path to the Java installation (JRE 1.5.0_06 or later); for example, /usr/java/jdk1.5.0_06.

KEYSTORE_FILE=

If USE_HTTPS=y (see USE_HTTPS=), the fully qualified path to the keystore file.

KEYSTORE_PASSWORD=

If USE_HTTPS=y (see USE_HTTPS=), the password used when generating the keystore file.

LOGDIR=

Fully qualified path to the log file directory; for example, opt/nwreg2/regional/logs.

PERFORM_BACKUP=

For backing up the current installation files, if present. Can be set to y even on a clean installation (see also BACKUPDIR=).

ROOTDIR=

Fully qualified installation path for the product files; contains bin, classes, cnrwebui, conf, docs, examples, extensions, lib, misc, schema, tomcat, and usrbin subdirectories.

START_SERVERS=

For starting the Network Registrar servers automatically at the end of the product installation. Set to y unless you explicitly want to manually start the servers.

TEMPDIR=

Fully qualified path to the /temp directory.

USE_HTTP=

Sets whether the web UI server listens for HTTP connections; one or both of USE_HTTP or USE_HTTPS must be set to y.

USE_HTTPS=

Sets whether the web UI server listens for HTTPS connections; one or both of USE_HTTP or USE_HTTPS must be set to y.

For USE_HTTPS, see also KEYSTORE_FILE= and KEYSTORE_PASSWORD=.

WEBUI_PORT=

Port number that the web UI uses for HTTP traffic; default value is:

8080 if CNR_CCM_MODE=local

8090 if CNR_CCM_MODE=regional

WEBUI_SEC_PORT=

Port number that the web UI uses for HTTPS traffic; default value is:

8443 if CNR_CCM_MODE=local

8453 if CNR_CCM_MODE=regional


Lightweight Directory Access Protocol

The "Using LDAP Updates" section in the "Configuring Client-Classes and Clients" chapter of the Cisco Network Registrar User's Guide 7.0 incorrectly describes updates to Lightweight Directory Access Protocol (LDAP) attributes (CSCsl67638). The last bullet in the section on page 24-27 should read:

LDAP attributes must come preconfigured in the LDAP schema at server installation or be created by some other means outside Network Registrar.

DHCP Reply Options

Because of the transition to DHCPv6 support as of release 6.2, the bootp-reply-options and dhcp-reply-options policy attributes were renamed v4-bootp-reply-options, v4-reply-options, and v6-reply-options. This change was not duly noted in previous Cisco Network Registrar Release Notes or other documentation (CSCso09058). Ensure that you set the values for the v4-reply-options (v4) or v6-reply-options (v6) when you use DHCP reply options.

Lease Import Function

The "Importing and Exporting Lease Data" section in the "Managing Leases" chapter of the Cisco Network Registrar User's Guide 7.0 inadequately describes lease times for imported leases (CSCsl63839). The "Lease Times in Import Files" subsection on page 22-7 should read:

For a lease import request, if the DHCP server is:

Enabled for import-mode and the lease is not already leased to the client, the server accepts any lease time the client specifies.

Enabled for import-mode, the lease is already leased to the client, defer-lease-extensions is enabled for the server (the default), and the request arrives before the renewal time (T1), the server uses the existing lease time. If the request arrives after T1, the server grants the client's request. (Note also that, within about 2 minutes of the expiration time, defer-lease-extensions is inoperative.)

Not enabled for import-mode, it never accepts a lease time longer than the server-configured one. If allow-lease-time-override is enabled for a policy applicable to the request, the server accepts a shorter lease time from the client (although you can set a server expert mode client-requested-min-lease-time attribute that creates a floor for the lease time). If allow-lease-time-override is not enabled for any applicable policy, the server ignores the dhcp-lease-time request in the incoming packet and uses the server setting.

Using Expressions

The following expression functions should not have appeared in Table 25-1 of the "Using Expressions" chapter in the Cisco Network Registrar User's Guide 7.0.

base32encode

decodeRFC1035

encodeRFC1035

mapcharacters

sha256

The following functions are limited to generating link template or prefix template attribute values and should have appeared in Table 20-1 in the "Using Expressions in Scope Templates" section of the "Configuring Scopes and Networks" chapter:

create-prefix

create-prefix-addr

create-prefix-range

create-v6-option

list

Creating Expressions

The example used in the "Creating Expressions" section of the Cisco Network Registrar User's Guide for 6.3 and 7.0 inadvertently omits characters.

The expression to include in an expression file that would describe the example in the "Typical Limitation Scenario" section would be:

// Begins the try function 
(try
 (or
  (if
   (equal (request option "relay-agent-info" "remote-id") (request chaddr))
   "cm-client-class")
  (if (equal (substring (request option "dhcp-class-identifier") 0 6) "docsis")
      "docsis-cm-client-class")
  (if (equal (request option "user-class") "alternative-class") "
      alternative-cm-client-class"))
 "<none>")
) 
// Ends the try function 

The example used in the "Expressions Functions" section of the Cisco Network Registrar User's Guide for 6.3 and 7.0 for the try expression should be:

Function
Example

(try expr failure-expr)

(try (try (expr) (complex-failure-expr)) "string-constant") 
ensures that the outer try never returns an error (because 
evaluating "string-constant" cannot fail).

HA DNS Server Pair

The "Configuring an HA DNS Server Pair" section in the Cisco Network Registrar User's Guide 7.0 in the "Configuring High-Availability DNS Servers" chapter inadvertently omits information on reloading the HA DNS server-pair after you synchronize the servers (CSCso43044). Step 9 on page 18-3 was added to read:

Reload both DNS servers to begin HA communication. The DNS servers synchronize things such as unprotected RRs themselves when they start communicating.

The "CLI Commands" subsection should include the following command:

nrcmd> dns reload


Note During a heavy load of DHCP client activity, and especially if the configured DNS server is an HA server performing a synchronization with its partner, the DHCP server may drop some DNS dynamic updates.


DHCP Extensions in Response Dictionary

The data items for DNS Updates in the response dictionary that Table 9 describes should have appeared in Table C-6 in the "Response Dictionary" section of the "DHCP Extension Dictionary" appendix in the Cisco Network Registrar User's Guide 7.0.

Table 9 Response Dictionary Specific Data Items 

Data Item
Value (Protocol: v4=DHCPv4, v6=DHCPv6)

lease-dns-forward-backup-server-address

IP address (v4, v6, read-only)

Address of the backup DNS server that receives DNS updates for the DHCPv4 and DHCPv6 lease if the server specified in lease-dns-forward-server-address is down.

lease-dns-forward-server-address

IP address (v4, v6, read-only)

Address of the DNS server that receives dynamic DNS updates for the DHCPv4 and DHCPv6 lease.

lease-dns-forward-update

string (v4, v6, read-only)

Name of the update configuration that determines which forward zones to include in DNS updates for the DHCPv4 and DHCPv6 lease. Returns TRUE if update-all or update-fwd-only is set.

lease-dns-forward-zone-name

string (v4, v6, read-only)

Name of an optional forward zone for DNS updates.

lease-dns-reverse-backup-server-address

IP address (v4, v6, read-only)

Address of the backup DNS server that receives DNS updates for a DHCPv4 and DHCPv6 lease if the server specified in lease-dns-reverse-server-address is down.

lease-dns-reverse-host-bytes

int (v4, read-only)

The number of bytes in a lease IP address for a reverse zone.

lease-dns-reverse-prefix-length

int (v6, read-only)

Prefix length of the reverse zone for ip6.arpa updates.

lease-dns-reverse-server-address

IP address (v4, v6, read-only)

Address of the DNS server address that receives dynamic DNS updates for the DHCPv4 and DHCPv6 lease.

lease-dns-reverse-update

string (v4, v6, read-only)

Name of the update configuration that determines which reverse zones to include in a DNS update for the DHCPv4 and DHCPv6 lease. Returns TRUE if update-all or update-fwd-only is set.

lease-dns-reverse-zone-name

string (v4, v6, read-only)

DNS reverse (in-addr.arpa and ip6.arpa) zone that is updated with PTR records.

lease-fqdn

string (v6, read-only)

Fully qualified domain name assigned to the DHCPv6 lease by the server (and possibly successfully entered into DNS). The lease-fqdn may be the name that is expected to be added to DNS for the lease or the actual name added. If host-name-in-dns is equal to true, the actual lease-fqdn is in DNS.

lease-requested-fqdn

string (v6, read-only)

Partial or fully qualified domain name most recently requested by the client for the DHCPv6 lease.


See also the "New DHCP Extensions" section.

DHCP Failover Configuration

Some of the text in the "Configuring DHCP Failover" chapter of the Cisco Network Registrar User's Guide 6.3 is somewhat misleading when it refers to automatic propagation to the backup server.

In the list of advantages under the "Simple Failover" subheading, the text indicates that "changes to the main server configuration are automatically propagated to the backup server." More accurately, changes "can be duplicated" on the backup server, which requires configuring a failover-pair object and synchronizing the partners.

Under the "Failover Checklist" section, the text indicates that the web UI "provides a way to automate" the process of duplicating network objects on the partner servers. More accurately, the web UI "provides a way to execute" the process by allowing synchronization of the failover partners.

Simple Network Management

The "Simple Network Management" section in the Cisco Network Registrar User's Guide 7.0 in the "Network Registrar Components" chapter provides an incorrect URL for the MIB support list (CSCsm13724).

Refer to the Management Information Base (MIB) for the details. The SNMP server supports only reads of the MIB attributes. Writes to the attributes are not supported. The following MIB files are required:

Traps—CISCO-NETWORK-REGISTRAR-MIB.my

DNS server—CISCO-DNS-SERVER-MIB.my

DHCPv4 server—CISCO-IETF-DHCP-SERVER-MIB.my

DHCPv4 server capability—CISCO-IETF-DHCP-SERVER-CAPABILITY.my

DHCPv4 server extensions—CISCO-IETF-DHCP-SERVER-EXT-MIB.my

DHCPv4 server extensions capability—CISCO-IETF-DHCP-SERVER-EXT-CAPABILITY.my

DHCPv6 server—CISCO-NETREG-DHCPV6-MIB.my (experimental)

These MIB files are available in the /misc directory of the Network Registrar installation path. With the exception of the experimental CISCO-NETREG-DHCPV6-MIB.my file, they are also included in the list at:

ftp://ftp.cisco.com/pub/mibs/supportlists/cnr/cnr-supportlist.html

The following dependency files are also required:

Dependency for DHCPv4 and DHCPv6—CISCO-SMI.my

Additional dependencies for DHCPv6—INET-ADDRESS-MIB.my

These dependency files are available along with all MIB files (except CISCO-NETREG-DHCPV6-MIB.my) at the following URL:

ftp://ftp.cisco.com/pub/mibs/v2/

To get the object identifiers (OIDs) for the MIB attributes, go to the equivalently named .oid file at:

ftp://ftp.cisco.com/pub/mibs/oid/

Reverse Zones

This section elaborates the "Add Reverse Zones as Zones" section in the Cisco Network Registrar User's Guide 7.0 to provide examples on creating reverse zones (CSCsl24523) by using:

An IPv4 subnet.

An IPv6 prefix.

The name of an IPv6 prefix.

Local Advanced and Regional Web UI

To create a reverse zone by using an IPv4 subnet or an IPv6 prefix:


Step 1 In DNS mode, click the Reverse Zones submenu.

Step 2 On the List/Add Reverse Zones page, enter these values in the Name field:

10.0.1.0/24—Creates a reverse zone by using an IPv4 subnet.

2001:db8:ff80:ff80::/64—Creates a reverse zone by using an IPv6 prefix.

Step 3 Click Add Zone to open the Add Reverse Zone page.

Step 4 Enter the required fields to create the reverse zone:

Nameserver—Enter ns1.example.com. (include the trailing dot).

Contact E-Mail—Enter hostmaster.example.com. (include the trailing dot).

Step 5 Click Add Zone to add the zone and return to the List/Add Reverse Zones page.


To create a reverse zone by using the name of an IPv6 prefix:


Step 1 Click DHCP v6, then Prefixes.

Step 2 Enter a prefix name (for example, prefix-1) and address (for example, 2001:db8:ff80:ff80::).

Step 3 Choose a prefix length from the drop-down list (for example, 64).

Step 4 Click Add Prefix, which should add the prefix to the list.

Step 5 To create a reverse zone from the prefix, click the Create icon () in the Reverse Zone column to open the Create Reverse Zone(s) for Prefix page. On this page, you can select a zone template, click Report, then Run.

Click Return to return to the List DHCPv6 Prefixes page. The icon in the Reverse Zone column changes to the View icon (), which you can click to open the List/Add Reverse Zones page.


CLI Commands

To create a reverse zone by using:

An IPv4 subnet, enter, for example:

nrcmd> zone 10.0.1.0/24 create primary ns1.example.com. hostmaster.example.com.

An IPv6 prefix, enter, for example:

nrcmd> zone 2001:db8::/64 create primary ns1.example.com. hostmaster.example.com.

The name of an IPv6 prefix, enter, for example:

nrcmd> prefix prefix-1 create 2001:db8:ff80:ff80::/64 
nrcmd> zone prefix-1 create primary ns1.example.com. hostmaster.example.com.

Vendor Option 43

The example used in the "Using Vendor-Specific Option Definitions" section of the Cisco Network Registrar User's Guide for 6.3 inadequately describes how to configure vendor option 43 for LWAPP (CSCso96625).

Using option 43 for Lightweight Access Point Protocol (LWAPP) Access Points requires vendor option 43 if you are using Network Registrar as the DHCP server. You can configure option 43 from the Web UI or CLI.


Note The example that this procedure uses is specific to the Cisco Aironet 1130 series. You can modify the example to configure option 43 for other vendor options, such as:

Cisco Aironet 1200 series

Cisco Aironet 1240 series


Creating Vendor Option Set and Vendor Option Values from the Web UI

Use the Local Advanced Web UI to create vendor option set and vendor option values. To configure option 43 from the Web UI:


Step 1 Click DHCP, then Options to open the List DHCP Option Definition Sets page.

Step 2 Click Add Option Definition Set.

Step 3 In the Add DHCP Option Definition page that appears, enter values for the following attributes:

Attribute
Value

Name

Name of the option definition set; for example, AP1130.

DHCP Type

Byte size of the type identifiers for all children in this set. You must choose DHCPv4 from the drop-down list.

Vendor Option String

The exact vendor class identifier string from option-60 that the DHCP client device vendor provides; for example, "Cisco AP c1130".


Step 4 Click Add Option Definition Set.

Step 5 Click AP1130, the name of the option definition set that appears in the List DHCP Option Definition Sets page.

Step 6 In the Edit DHCP Option Definition Set AP1130 page that appears, click Add/Edit Option Definitions, then Add Option Definition.

Step 7 In the Add DHCP Option Definition page, enter values for the following attributes:

Attribute
Value

Number

Number of the option code. You must enter 43.

Name

Name of this attribute; for example, "ap1130-option-43".

Type

The datatype for the option value. You must choose "binary" from the drop-down list.


Step 8 Click Add Option Definition. Note that clicking this button does not save the changes that you make to the option definition set; it only lists the option definition set on the List DHCP Option Definitions page.

Step 9 In the List DHCP Option Definitions page, click the name of the new option definition ("ap1130-option-43"), then Add Sub-Option Definition.

Step 10 In the Add DHCP Option Definition page, enter values for the following attributes:

Attribute
Value

Number

The option code for this suboption. For this example, you must enter 241.

Name

Name of this attribute; for example, "ap1130-suboption-241".

Type

The datatype for the suboption value. For this example, you must choose "IP address" from the drop-down list.

Repeat

The repeat count for this type. For this example, you must choose 1+ from the drop-down list.


Step 11 Click Add Option Definition, then Modify Option Definition Set.

Step 12 Click DHCP, then Policies to open the List DHCP Policies page.

Step 13 Choose the policy for which to set this option; or, add a new policy in the Advanced mode.

Depending on your selection, the Edit DHCP Policy policy_name or the Add DHCP Policy page appears.

Step 14 From the DHCPv4 Vendor Options drop-down list, choose the name of the option definition set (AP1130), and click Select.

Step 15 Choose the option definition from the Name drop-down list ("ap1130-option-43") and, in the Value field, enter, for example:

(241 3.3.3.3,4.4.4.4)

Step 16 Click Add Option, then, click Modify Policy or Add Policy.

Step 17 Reload the DHCP server.


Creating Vendor Option Set and Vendor Option Values from the CLI

To configure option 43 from the CLI:


Step 1 Create a .txt file with the following content, and save it as OptionSetCiscoAP.txt at the following location:

Windows—\Program Files\Network Registrar\Local\bin

Solaris and Linux—/opt/nwreg2/local/usrbin


Note The example that this procedure uses is specific to the Cisco Aironet 1130 series. You can modify the example to configure option 43 for other vendor options, such as:

Cisco Aironet 1200 series

Cisco Aironet 1240 series


#
# Version: 1
#  6.2+ Option-set example for Option 43 with suboptions for Cisco APs 
#
#  NOTE: Need to edit vendor option string to Exact match AP Model string in Option-60.
#
#        For compatibility with pre-6.2 vendor options ensure that
#        name=vendor-option-string. (Not True in this test example.)
#  ======================================================================
{
  ( id-range = 1 )
  ( vendor-option-string = Cisco AP c1130 )
  ( name = APtest )
  ( children = [
    {
      ( id = 43 )
      ( name = pxe-sample )
      ( desc =  )
      ( base-type = AT_BLOB )
      ( children = [
        {
          ( id = 241 )
          ( name = controller )
          ( desc = ap controller )
          ( base-type = AT_IPADDR )
          ( repeat = ONE_OR_MORE )
        } ]
      )
    } ]
  ) 
}

Step 2 From the CLI, run the import option-set file command to import the file.

For example:

nrcmd> import option-set OptionSetCiscoAP.txt
# 100 Ok

Step 3 Set the vendor-specific option data on the policy using the policy name setVendorOption opt-name-or-id opt-set-name value command.

For example:

nrcmd> policy test setVendorOption 43 APtest "(241 3.3.3.3,4.4.4.4)"
# 100 Ok

Step 4 Reload the DHCP server.


Caveats

You can find the complete list of resolved and known bugs in the cnr_7_0_1-buglist.html file included with the release. Refer to this list especially for information about fixes to customer-reported issues.

Related Documentation

See also the following documents for important information about installing, configuring, and managing Network Registrar:

For Network Registrar installation procedures, see the Cisco Network Registrar Installation Guide.

To become familiar with Network Registrar features, see the Quick Start Guide for Cisco Network Registrar.

For configuration and management procedures, see the Cisco Network Registrar User's Guide.

For details about commands available through the command-line interface (CLI), see the Cisco Network Registrar CLI Reference Guide that is now delivered as an HTML document that you can view in your web browser when you install the software.

To use the CLI reference guide:


Step 1 Open the directory or filesystem where you installed the software.

Step 2 On Windows, go to \Network Registrar\Local\docs. The path is similar on Solaris and Linux.

Step 3 Click CLIContents.html.

Your web browser displays the Contents page for the document.


Notices

The following notices pertain to this software license.

OpenSSL/Open SSL Project

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).

This product includes cryptographic software written by Eric Young (eay@cryptsoft.com).

This product includes software written by Tim Hudson (tjh@cryptsoft.com).

License Issues

The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact openssl-core@openssl.org.

OpenSSL License:

Copyright © 1998-2007 The OpenSSL Project. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)".

4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact openssl-core@openssl.org.

5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written permission of the OpenSSL Project.

6. Redistributions of any form whatsoever must retain the following acknowledgment:

"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)".

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT "AS IS"' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson (tjh@cryptsoft.com).

Original SSLeay License:

Copyright © 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved.

This package is an SSL implementation written by Eric Young (eay@cryptsoft.com).

The implementation was written so as to conform with Netscapes SSL.

This library is free for commercial and non-commercial use as long as the following conditions are adhered to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com).

Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. All advertising materials mentioning features or use of this software must display the following acknowledgement:

"This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)".

The word `cryptographic' can be left out if the routines from the library being used are not cryptography-related.

4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: "This product includes software written by Tim Hudson (tjh@cryptsoft.com)".

THIS SOFTWARE IS PROVIDED BY ERIC YOUNG "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution license [including the GNU Public License].

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html