Guest

Cisco Network Registrar

Release Notes for Cisco Network Registrar 6.3.1

  • Viewing Options

  • PDF (347.3 KB)
  • Feedback
Release Notes for Cisco Network Registrar Release 6.3.1

Table Of Contents

Release Notes for Cisco Network Registrar Release 6.3.1

Contents

Introduction

Before You Begin

License Keys

System Requirements

Network Registrar Communications Security Option

Software and Standards Compatibility

Interoperability

Installation and Upgrade Notes

General Installation

Red Hat Linux Installation

Windows Installation

Upgrade Considerations

Moving Network Registrar to a New Machine

New Features and Implementation Notes

CCM Database Index Repair

DNS Resolution Queue Management

DNS Scavenging Process

Chatty Client Filter

Lease History Database Compression Utility

General Comments on Running cnr_leasehist_compress

Running Compression on Solaris and Linux

Running Compression on Windows

Warning About Updating DNS First

Failover Pair Renaming

High-Availability (HA) DNS Statistics

Generating Resource Records on BIND Imports

Multiple Interface Users

TFTP Block Sizes

Pushing Subnets to Cisco uBR10000 Routers

Caveats

Documentation Errata

Linux Silent Installation

Lease Import Function

Lightweight Directory Access Protocol

Simple Network Management

DHCP Failover Configuration

DHCP Reply Options

HA DNS Server Pair Reloads

Related Documentation

Notices

OpenSSL/Open SSL Project

License Issues

Obtaining Documentation, Obtaining Support, and Security Guidelines


Release Notes for Cisco Network Registrar Release 6.3.1


April 17, 2008

These release notes are for Cisco Network Registrar Release 6.3.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 Features and Implementation Notes

Caveats

Documentation Errata

Related Documentation

Notices

Obtaining Documentation, Obtaining Support, and Security Guidelines

Introduction

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

Before You Begin

Review the following sections before installing Network Registrar 6.3.1.

License Keys

Each Network Registrar software license key addresses a separate functional area. You enter these license keys during installation or in the web-based user interface (web UI) or command line interface (CLI). An upgrade now prompts for a license key only if it finds no valid license keys in the existing license file.

To determine if you need a new license key:

On initial installation of Network Registrar, use the license key provided with your shipment.

When upgrading from Network Registrar 6.1 or 6.2, use a license key from 6.1 or 6.2 for a local server upgrade. Although a 6.0 license key will work on the local server cluster, the regional cluster requires a new license key (introduced in 6.1) to view or change the server configuration data.

When upgrading from a release earlier than 6.1, first upgrade to 6.1 or 6.2. If you are upgrading from a release prior to 6.0, you must then add a new license key. License keys that were valid before 6.0 do not work.

DHCPv6 functionality requires a new IPv6 addressing license key, and you can now apply the Router management license key to the local cluster (see the "Overview" chapter of the Cisco Network Registrar Installation Guide for details on license keys).

System Requirements

Review these system requirements before installing the Network Registrar 6.3.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 web site.)

Operating system—Your Network Registrar machine must meet the minimum requirements of the Windows, Solaris, or Linux operating systems that appear 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 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 Minimum Requirements and Recommendations 

Operating System
Solaris
Linux
Windows
Component
     

OS version 1

Solaris 9 or Solaris 10 2

Red Hat Enterprise Linux ES 4.0 only

Windows 2003 server 3

CPU 4

4-core 1.2-GHz UltraSPARC T2 (Recommended T5220)

Cost-effective: Dual-core 1.86-GHz x86

High-performance: Dual-core 3-GHz x64

Disk space 5

2 x 73/146 SAS 6 drives

With basic DHCP and optimal hardware configuration:

SATA 7 drives with 7500 RPM drive > 500 leases/second

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

(Recommended hard drive 146 GB)

Memory

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 6.3.1 supports 128KB block sizes in the Solaris 10 Zettabyte File System (ZFS).

3 Windows installations require support for 16-bit compatibility mode.

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

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

6 Serial Attached SCSI.

7 Serial Advanced Technology Attachment (Serial ATA).



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 6.3.1. (See the "Upgrade Considerations" 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 6.3 and subsequent versions (CSCso00594). 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

The Network Registrar servers comply with the applicable Request for Comments (RFCs), protocols, standards, and Internet Engineering Task Force (IETF) drafts:

Domain name system (DNS) servers—Comply with RFCs 974, 1034, 1035 (with updates 1101 and 1183), 1995 (IXFR), 1996 (NOTIFY), 2136 (DNS Update), 2181 (Clarifications), 2308 (Negative Caching of DNS Queries), 2317 (Classless in-addr.arpa), 2782 (SRV), 2845 (Secret Key Transaction Authentication), and 2915 (NAPTR).

DHCP and Bootstrap protocol (BOOTP) clients—Comply with RFCs 951 (with updates 1497 and 1542), 1534, 2131, 2132, 2136, 3004, and 3046 (DHCP Relay Agent Information Option).

DHCP failover—Complies with draft-ietf-dhc-failover-03.txt. Also, RFC 3074 (DHC Load Balancing Algorithm).

TFTP—Complies with RFCs 1123 and 1350. Additional support was added for the BLOCK SIZE option contained in RFCs 2347 and 2348 (see the "TFTP Block Sizes" section).

Lightweight Directory Access Protocol (LDAP) servers—Operates with any LDAP version 2 or 3 server that complies with RFCs 1798, 2241, and 2254 (Extensible Filtering).

DHCPv6 functionality—Complies (all or in part) with RFCs 3315 (DHCP for IPv6), 3633 (IPv6 Prefix Options for DHCPv6), and 3736 (Stateless DHCP Service for IPv6).

DNSv6 functionality—Complies (all or in part) with RFC 3152 (Delegation of IP6.ARPA), 3363 (Representing IPv6 Addresses in DNS), and related RFCs.

Interoperability

The Network Registrar 6.3.1 and later protocol servers interoperate with 6.1 and later protocol servers. However, the 6.3.x DNS HA server interoperates only with the 6.2 server, which is the version in which the DNS HA server was introduced.

The regional Central Configuration Management (CCM) server interoperates with prior versions of Network Registrar. The regional cluster supports the features listed in Table 2 when it manages clusters running earlier versions of Network Registrar.

Table 2 Regional Cluster Features 

Feature
Local Cluster Version
6.1
6.1. x
6.2
6.3. x

Central push and pull:

Address space
Scope templates, policies, client-classes
Zone data and templates
Groups, owners, regions
Administrators, roles

x
x
x
x

x
x
x
x
x

x
x
x
x
x

x
x
x
x
x

Administrator:

Single sign-on
Password change

x

x
x

x
x

x
x

IP history reporting:

Central lease history
Detail lease history

x

x
x

x
x

x
x

Utilization reporting:

Central subnet utilization history
Current subnet and scope utilization

x

x
x

x
x

x
x


Installation and Upgrade Notes

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

General Installation

Review the following points before beginning a new installation or an upgrade:

Windows, Solaris, and Linux installations occur through these means:

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.

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 while Network Registrar is running.

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.

Also, be aware of compatibility issues when you install on Red Hat (RH) Linux:

Release 6.1.x supports RH 7.3, RH ES 2.1, and RH ES 3.0:

The linux download kit supports RH 7.3 and RH 2.1.

The linux3 download kit supports RH ES 3.0 for Network Registrar 6.1.2 and later.

Release 6.2.x supports RH ES 3.0 and RH ES 4.0:

The linux3 download kit supports RH ES 3.0.

The linux4 download kit supports RH ES 4.0.

Release 6.3.x supports RH ES 4.0 only.

Windows Installation

The Network Registrar 6.3.1 installation program for Windows no longer attempts 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. (Refer to Microsoft documentation about how to use the cacls and icacls utilities.)

Modifying the ACLs is strictly optional, and Network Registrar functions normally without making any changes to these files. However, if you want to change ACLs manually, control the settings so that the contents of the entire installation area are read-only to everyone except those in the Administrators system group. The following files and subdirectories contain sensitive data, and you might want to restrict access to them:

installdir\conf\cnr.conf

installdir\tomcat\conf\server.xml

installdir\conf\priv\

installdir\data\

Upgrade Considerations

Network Registrar 6.3.1 supports upgrades from releases 6.1.x. and 6.2.x. 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 rolls back the software to the earlier release.

Before you upgrade to Network Registrar 6.3.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:

Windowsnet 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 (see the following Note).


Note The recommended practice is to upgrade the regional cluster before upgrading any local clusters, because an older version 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. (See also the "Failover Pair Renaming" section.)


Step 8 If the upgrade fails for any reason, revert to the previous Network Registrar version:

a. Delete the possibly corrupted data directory.

b. Install the previous Network Registrar release.

c. Stop the server agent, as in Step 4.

d. Delete the data directory that the installation creates.

e. Replace the data directory with the zipped file from Step 5.

f. Restart the server agent:

Windowsnet start nwreglocal

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


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. The following procedure preserves your original data on the old machine should a problem arise during the installation on the new machine (CSCso06297):


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

Step 2 Stop the server agent on the old machine with:

Windowsnet stop nwreglocal

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

Step 3 Zip up the data directory on the old machine.

Step 4 Copy the zip file over 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). The installation will detect an upgrade and will do so based on the copied data.

Step 6 Fix any IP addresses that you need to change.


New Features and Implementation Notes

This section covers the following:

CCM Database Index Repair

DNS Resolution Queue Management

DNS Scavenging Process

Chatty Client Filter

Lease History Database Compression Utility

Warning About Updating DNS First

Failover Pair Renaming

High-Availability (HA) DNS Statistics

Generating Resource Records on BIND Imports

Multiple Interface Users

TFTP Block Sizes

Pushing Subnets to Cisco uBR10000 Routers

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 the configuration to exist. The current 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 CCIM server is not running before you run the rebuild_indexes utility.

The syntax for the rebuild_indexes utility is:

rebuild_indexes options 

where options are:

-d path—Path to the existing CCM database.

-c—Checkpoints the database before exiting.

-z {letters}=level—Enable debugging at a specified level, specified 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.

DNS Resolution Queue Management

In some cases, you might see that the resolution queue reaches its configured limit, in which case nonauthoritative queries might begin to time out (CSCsl65239). To relieve the network from such a condition, you can increase the DNS server attribute resolution-queue-max-size value (the preset value in this release is 5000 concurrent requests; the maximum value is 50000). For example:

nrcmd> dns set resolution-queue-max-size 10000 

However, you might have to monitor network traffic or consult the debug data to prevent this situation from reoccurring. You might also want to set the DNS server request-expiration-time to a lower value than its preset value of 90 seconds, to perhaps 30 seconds.

DNS Scavenging Process

If you enable scavenging for the DNS server, ensure that 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.

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 reenables 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 argument, 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 DHCPRELEASEs 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 DHCPRELEASEs, 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 options available with the Chatty Client Filter.

Table 3 Arguments for the Chatty Client Filter 

Argument
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

SampleHitsToDisable.

15 packets

-i seconds

SampleTimeInterval.

30 seconds

-l packet-count

QuietHitsToLeaveDisabled.

5 packets

-q seconds

QuietTimeInterval.

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 argument, 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)


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 (see also the "Chatty Client Filter" section).

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 input flag for this option. The interval that you specify with the flag 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 input flag for this option. The interval that you specify with the flag 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 DHCPRELEASEs, because this results in rapid growth of lease history data. In such instances, you might 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 drop all DHCPRELEASEs or those that belong to clients that exceed a configured threshold. (See also the "Chatty Client Filter" section.)

Note that the utility 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.

For information on the qualifying options for the cnr_leasehist_compress utility see Table 4.

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 flag 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 flag 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 flag 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. Cisco recommends 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 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 does not compress the original database. The -r 0 flag 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 flag 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 task 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 flag 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. Cisco recommends 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 


Table 4 describes the qualifying options for the cnr_leasehist_compress utility.

Table 4 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 which 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 twenty 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 using the standard Network Registrar debug tracing syntax.


Warning About Updating DNS First

We recommend that you do not enable the update-dns-first attribute for the following reasons:

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 in letting 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 releases earlier than 6.3.1, 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 releases 6.3.1 and later, the server detects name and address changes in a single failover based on an algorithm. 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. Cisco recommends that you ensure that the failover partners are in the NORMAL/NORMAL mode before reloading the server.

To rename failover pairs objects when upgrading from pre-6.2 to 6.2 or later:


Step 1 Disable startup on reboot for the DHCP server with:

nrcmd> dhcp disable start-on-reboot 

Step 2 Upgrade the server to any version earlier than Network Registrar 7.0.

Step 3 Change the failover-pair name. You should remove the object that the upgrade creates and then add it back.

Step 4 Enable startup on reboot for the DHCP server with:

nrcmd> dhcp enable start-on-reboot 

Step 5 Start the DHCP server to create the failover state between the servers.


High-Availability (HA) DNS Statistics

Table 5 lists the HA DNS statistics whose descriptions were modified to be more accurate (CSCsg59130):

Table 5 DNS Statistics 

Statistic
Description

ha-msg-connect-recv

Number of connection establishment request messages received (HA_DNS_ESTABLISH_CONNECTION).

ha-msg-connect-sent

Number of connection establishment request messages sent (HA_DNS_ESTABLISH_CONNECTION).

ha-msg-heartbeat-recv

Number of heartbeat request messages received (HA_DNS_HEARTBEAT).

ha-msg-heartbeat-sent

Number of heartbeat request messages sent (HA_DNS_HEARTBEAT).

ha-msg-reconcile-recv

Number of zone reconciliation request messages received (HA_DNS_RECONCILIATION).

ha-msg-reconcile-sent

Number of zone reconciliation request messages sent (HA_DNS_RECONCILIATION).

ha-msg-rrsync-recv

Number of rr-sync request messages received (HA_DNS_RR_SYNC).

ha-msg-rrsync-sent

Number of rr-sync request messages sent (HA_DNS_RR_SYNC).

ha-msg-rrupdate-recv

Number of rr-update request messages received (HA_DNS_RR_UPDATE).

ha-msg-rrupdate-sent

Number of rr-update request messages sent (HA_DNS_RR_UPDATE).

ha-msg-zonesync-recv

Number of zone synchronization request messages received (HA_DNS_ZONE_SYNC).

ha-msg-zonesync-sent

Number of zone synchronization request messages sent (HA_DNS_ZONE_SYNC).

ha-zone-mismatch

Number of zones reporting a mismatch error (HA_DNS_RESP_ERR_MISMATCH).

Note This statistic was renamed from ha-resp-mismatch (CSCei13309).


Generating Resource Records 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 it is still valid after the other user's changes.

TFTP Block Sizes

The TFTP server in Network Registrar supports the TFTP BLOCK SIZE option described in RFC 2348, which allows transfer of large files over 32 MB if the TFTP server and the client support the TFTP Block Size (blksize) extension (CSCsh29868). You can upload or download files with different block sizes, although the valid range of BLOCK SIZE supported is 8 through 65464 bytes. The default BLOCK SIZE is 512 bytes. The maximum size of the file is calculated as 65535 * BLOCK SIZE. Hence, setting a BLOCK SIZE of 65464, for example, can theoretically upload or download a file of nearly 4 GB.


Caution Be careful setting a BLOCK SIZE value greater than 1428 bytes in that it exceeds the Ethernet nonfragmentation block size, which can result in packet fragmentation and degraded performance.

To allow TFTP clients to use a BLOCK SIZE value larger than the default 512 bytes, you must configure the TFTP max-udp-packet-size attribute value to be 4 bytes (the TFTP header size) more than the BLOCK SIZE desired, then reload the TFTP server to apply the change:

nrcmd> session set visibility=3 
nrcmd> tftp set max-udp-packet-size=block-size+4 
nrcmd> tftp reload 

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

Caveats

You can find the complete list of resolved and known bugs (including customer-found ones) in the cnr_6_3_1-buglist.html file in the /docs directory of the Network Registrar CD-ROM or on the cisco.com download site at:

http://www.cisco.com/cgi-bin/Software/Tablebuild/tablebuild.pl/nr-eval.

Documentation Errata

This section covers the following:

Linux Silent Installation

Lease Import Function

Lightweight Directory Access Protocol

Simple Network Management

DHCP Failover Configuration

DHCP Reply Options

HA DNS Server Pair Reloads

Linux Silent Installation

A Network Registrar silent installation allows for unattended installation and upgrading. When doing a silent installation on the Linux operating system, you are required to enter entries in a silent-response file. The entries for the silent-response file which are provided in Table 6 were not adequately described in the Cisco Network Registrar Installation Guide for 6.3 (CSCso43074).

To create a text silent-response file, include the entries in Table 6, then invoke the silent installation or upgrade for each instance:

install_cnr -r response-file 

Table 6 Silent-Response File Entries for Linux 

Silent-Response File Entry
Set to Value

BACKUPDIR=

Path where to store the current Network Registrar installation files, but only if PERFORM_BACKUP=y.

CCM_PORT=

Central Configuration Management (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 kill any open CLI connections when installing or upgrading; otherwise, basically deprecated.

CNR_LICENSE_KEY=

For Network Registrar 6.x and earlier only, the product license key string.

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.

JAVADIR=

Fully qualified path to the Java installation (JRE 1.5.0_6 or later).

JSSEDIR=

If using HTTP for releases before Network Registrar 7.0, the fully qualified path to a Java installation with the jsse.jar, jcert.jar, and jnet,.jar files. (For Network Registrar 7.0 and later, the JAVADIR value is enough, because JRE 1.5.0_06 and later contain the required files.)

KEYSTORE_FILE=

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

KEYSTORE_PASSWORD=

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

LOGDIR=

Fully qualified path to the log file directory.

PERFORM_BACKUP=

Sets whether or not to back 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=

Sets whether or not to start the Network Registrar servers automatically at the end of the product installation. Should be set to y unless you explicitly want to manually start the servers.

TEMPDIR=

Fully qualified path to the temp directory.

USE_HTTP=

Sets whether or not 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 or not the web UI server listens for HTTPS connections; one or both of USE_HTTP or USE_HTTPS must be set to y (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


If you want to uninstall the product, invoke the silent uninstallation:

uninstall_cnr 

Lease Import Function

The "Importing and Exporting Lease Data" section in the Cisco Network Registrar User Guide in the "Managing Leases" chapter 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 gives the client whatever it asks for. (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."

Lightweight Directory Access Protocol

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

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

Simple Network Management

The "Simple Network Management" section in the Cisco Network Registrar User Guide in the "Network Registrar Components" chapter provides an incorrect URL for the MIB support list (CSCsm13724). The URL in the section on page 1-2 should read:

"The remaining MIBs are available at the following URL:

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

DHCP Failover Configuration

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

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.

Also, the failover-pair command in the Cisco Network Registrar CLI Reference Guide in the "Using the nrcmd Commands" chapter inadvertently omits the load-balancing attribute. The "failover-pair Command Attributes" table on page 2-96 should contain the following entry:

"load-balancing

"Determines whether load-balancing, as defined in RFC 3074, is enabled on a failover- pair. If you enable load-balancing, the backup-pct is ignored. The client load and leases that are available for all scopes in the failover relationship are split equally between the main and backup servers (as if backup-pct was set to 50%). Optional, default disabled."

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 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 or v6-reply-options when you use DHCP reply options.

HA DNS Server Pair Reloads

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

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

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.

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.

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, Obtaining Support, and Security Guidelines

For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, 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