Guest

Cisco Network Registrar

Release Notes for Cisco Network Registrar 6.1.6

  • Viewing Options

  • PDF (349.7 KB)
  • Feedback
Release Notes for Cisco Network Registrar 6.1.6

Table Of Contents

Release Notes for Cisco Network Registrar 6.1.6

Contents

Purpose

Before You Begin

Backup and Restore Changes Made in Release 6.1.4.1

License Keys

System Requirements

Software and Standards Compatibility

User Interfaces and Version Compatibility

Installation and Upgrade Considerations

Solaris Installation Changes as of Release 6.1.2

General Installation

Upgrading

Features Added in Release 6.1

Central Cluster Administration

Enhanced Address Management

Cluster Management

Cluster Licensing

Regional Administrator Roles

Regional Address Space Management

Replica Data Propagation

RIC Server Support for Cisco CMTSs

DNS Server Enhancements

DHCP Server Enhancements

Import/Export Utility Enhancements

Process, File, and Utility Name Changes

Features Added in Release 6.1.1

Central Management of Administrators, Groups, and Roles

IP Lease History Detail

Current Utilization Reporting

Improved DNS Query Performance

Enhanced Server Controls

DHCP Failover Controls in the Web UI

Dynamic DNS Update Configuration

DNS Forwarder Configuration

Zone Recovery Tool

Connection Security Between Clusters

Features Added in Release 6.1.2

Features Added in Release 6.1.3

Features Added in Release 6.1.4

Features Added in Release 6.1.4.1

Features Added in Release 6.1.4.2

Features Added in Release 6.1.5

Features Added in Release 6.1.6

Caveats

Software Caveats

Documentation Caveats

Open Source License Acknowledgements

OpenSSL/Open SSL Project

License Issues

Obtaining Documentation and Submitting a Service Request


Release Notes for Cisco Network Registrar 6.1.6


May 15, 2007

These release notes describe the new software features, installation updates, caveats, and documentation for Cisco Network Registrar Release 6.1.6.

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 for Network Registrar, 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.

You can access Network Registrar technical documentation at this website:

http://www.cisco.com/en/US/products/sw/netmgtsw/ps1982/index.html

Contents

These release notes are described in the following sections:

Purpose

Before You Begin

Software and Standards Compatibility

User Interfaces and Version Compatibility

Installation and Upgrade Considerations

Features Added in Release 6.1

Features Added in Release 6.1.1

Features Added in Release 6.1.2

Features Added in Release 6.1.3

Features Added in Release 6.1.4

Features Added in Release 6.1.4.1

Features Added in Release 6.1.4.2

Features Added in Release 6.1.5

Features Added in Release 6.1.6

Caveats

Open Source License Acknowledgements

Obtaining Documentation and Submitting a Service Request

Purpose

The 6.1.x releases add greater functionality to Network Registrar. Several key enhancements are improved central management, better detailed lease history recording and reporting, and subnet utilization reporting.

Before You Begin

Review the following critical information before installing Network Registrar.

Backup and Restore Changes Made in Release 6.1.4.1

For a backup of the database files, the algorithm that the mcdshadow utility uses now performs the following steps for each database:

1. Copies the xxx.log files except the most recent ones.

2. Copies the xxx.db directories.

3. Copies any log files not copied in step 1.

4. Runs cnrdb_recover -c on the database.

5. If step 4 fails, repeats from step 1, up to three total passes.

This means that you no longer need to do an explicit cnrdb_recover on the database. This change affects the process described in Chapter 2, "Maintaining Databases" of the Cisco Network Registrar User's Guide. The "Recovering CNRDB Data from Backups, "section should now read as follows:

"When recovering CNRDB data from a backup, if it is unsuccessful, try again using the current shadow backup (in the Network Registrar installation path):

1. "Stop the Network Registrar server agent.

2. "Move the operational database files to a separate temporary location.

3. "Copy each .../data/name.bak directory to .../data/name; for example, copy .../data/mcd.bak to .../data/mcd.

4. "Once the files are renamed, restart the server agent.

"The CNRDB database maintains centrally managed configuration data that is synchronized with the server configuration databases. If you restore the CNRDB files from backup, also restore the MCD database from the same backup.


Note "If the recovery fails, perhaps because the current shadow backup is simply a copy of corrupted files, use the most recent previous shadow backup. You cannot add operational log files to older shadow backup files. All data added to the database since the shadow backup was made will be lost."


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 CLI. During an upgrade, you are prompted for a license key only if no valid license keys are found in the existing license file.

Follow these guidelines to determine if you need a new license key:

Initial installation of Network Registrar—Use the license key provided with your shipment.

Upgrading from Release 6.1 or 6.0—You can use a license key from 6.1 or 6.0 for a local server upgrade. Although a 6.0 license key operates on the local server cluster, the regional cluster requires one or more new license keys introduced in 6.1 to view or change the server configuration data.

Upgrading from a release before 6.0—You must add a new license key. License keys that were valid before 6.0 do not work.

System Requirements

Be sure that your system meets the necessary minimum requirements for Java, the operating system, and the user interface:

Java—You must have the Java Runtime Environment (JRE) version 1.4 or later, or the equivalent Java Development Kit (JDK), installed. The JRE is available from the Sun Microsystems website.

Operating system—Table 1 shows the minimum requirements for the Network Registrar servers on Windows, Solaris, and Linux platforms.

Table 1 Network Registrar Server Minimum Requirements 

Component
Windows
Solaris
Linux

CPU architecture

Intel Pentium III or equivalent

Sun Netra AC200

Intel Pentium III or its equivalent

OS version

Windows 2003 or Windows 2000 (Service Pack 2 or later is recommended)1

Solaris 8 or Solaris 9

Red Hat Linux Enterprise Server (ES) 3.0, or ES or WS 2.1 (kernel 2.4.9-e.24), or 7.3 (kernel 2.4). Use RPM Package Manager (RPM) 4.0.4 or later.

RAM

512 MB on all platforms

Disk space

18 GB recommended, minimum 310 MB required for installation

Swap space

100 MB free swap space

1 Network Registrar was also tested for Japanese Windows 2000, with support for the English language version only.


User interface—Network Registrar includes two user interfaces, a Web UI for local and regional clusters, and a CLI for local clusters:

The Web UI runs on a minimum of Microsoft Internet Explorer 5.5 (Service Pack 2) or Netscape 6.2.

The CLI runs in a Windows, Solaris, or Linux command window.


Caution You cannot run Cisco Network Registrar and Cisco Access Registrar on the same machine. Attempting to do so will compromise the integrity of both products.

Software and Standards Compatibility

Network Registrar 6.1.6 is compatible with Cisco Broadband Access Center for Cable (BACC).

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 (Dynamic DNS Updates), 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 servers—Comply with draft-ietf-dhc-failover-03.txt.

Trivial File Transport Protocol (TFTP)—Comply with RFCs 1123 and 1350.

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

User Interfaces and Version Compatibility

Network Registrar 6.1.6 includes regional and local cluster web UIs and a CLI (the nrcmd program). Note the following:

The CLI connects only to the local cluster. (Although the regional cluster installation provides the CLI, it is only present to provide connectivity with local clusters.)


Note The number of simultaneous active CLI sessions on a cluster can be no more than 14.


As of Release 6.1, Network Registrar no longer supports the Windows-based graphical user interface (GUI).

Table 2 shows the interoperability of the local clusters with the Release 6.1.6 regional central configuration management (CCM) server. Because of changes to the database, user interfaces in pre-6.0 releases cannot operate with the Network Registrar 6.1 or 6.0 servers. The 6.1.6 CLI is compatible with the 6.1, 6.0, 5.5, 5.0, and 3.5 servers.

You can use the zone recovery tool that was added in this release to recover zones from other servers of the same version; that is, from Release 6.0 to a 6.0 cluster, or from 6.1 local and regional clusters to a 6.1 local cluster.

Table 2 6.1.6 Regional CCM Server Interoperability with Local Clusters

Feature
Local Cluster Version
6.0
6.1
6.1.2/3/4/6

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

Administrator:

Single sign-on
Password change

 

x

x
x

IP history reporting:

Central lease history
Detail lease history

 

x

x
x

Utilization reporting:

Central subnet utilization history
Current subnet and scope utilization

 

x

x
x


Installation and Upgrade Considerations

Review the following notes before installing Network Registrar or upgrading from a previous version. For the procedures to install Network Registrar, see the Cisco CNS Network Registrar Installation Guide.

Solaris Installation Changes as of Release 6.1.2

Solaris users installing or upgrading to Network Registrar 6.1.6 should note three changes to the procedure (Windows and Linux procedures remain unchanged):

An upgrade now automatically tries to upgrade your database from the previous version. The prompt "Would you like to upgrade the existing Network Registrar ... database (recommended)?" no longer appears. If the upgrade process detects a previous configuration database and cannot determine the previous release, it assumes Release 5.5. If you want to override this default and have the upgrade process prompt for the previous version, create an empty cnr_prompt_version file in the system /tmp directory. If you do not want to upgrade based on the previous database, remove the previous database files before running the installation.

Both the installation and upgrade procedures now ask if you want to archive (keep a backup of) your current database. Either choice has no effect on a new installation, which will proceed as usual.

Installations and upgrades now both request a license key if a previous one does not exist. A new installation now also asks for a license key. An upgrade asks for a license key only if it cannot find a valid one from the previous release. You can still opt to omit the license key and add it later when you need it to log in to the cluster.

General Installation

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

Windows, Solaris, and Linux installations are performed through these means:

Windows—Using a Windows-based InstallShield setup program.

Solaris—With the pkgadd command.

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

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

The names of certain Network Registrar processes, files, and utilities were changed in Release 6.1, primarily because product regional and local cluster configurations were introduced. For these name changes, see the "Process, File, and Utility Name Changes" section.

On Windows, ensure that the Dr. Watson Visual Notification check box is unchecked. 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 usually enabled by default. Execute C:\WINNT\system32\DRWTSN32.exe, uncheck the Visual Notification check box, and then click OK. (You can perform this step after installation.)

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 set properly, it displays a warning message advising corrective action.

Virus scanning and archiving programs—If you have virus scanning or automatic backup software enabled on your system, exclude these Network Registrar directories and their subdirectories from being scanned to prevent Network Registrar operations from being damaged:

Windows—

install-path\data (for example, C:\Program Files\Network Registrar\Local\data)
install-path\logs (for example, C:\Program Files\Network Registrar\Local\logs)

Solaris and Linux—

install-path/data (for example, /var/nwreg2/local/data)
install-path/logs (for example, /var/nwreg2/local/logs)

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.

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 may exist, it displays a warning message. Before installing Network Registrar, take the appropriate action to disable the conflicting servers.


Note Network Registrar includes a list of information, activity, warning, and error messages that are logged during certain operating conditions. This list is available in HTML files for each component as links from a MessageIDIndex.html file—On Windows, by default, C:\Program Files\Network Registrar\Docs\Msgid\MessageIDIndex.html; on Solaris and Linux, by default, /opt/nwreg2/docs/msgid/MessageIDIndex.html


Upgrading

Before beginning an upgrade from an earlier version of Network Registrar, note that the upgrade process differs slightly based on the release and operating system:

Network Registrar does not support upgrades from 5.0 or earlier.

If you are upgrading from 6.1, 6.0. or 5.5, you can upgrade to 6.1.6 while preserving the earlier configuration. On Windows or Linux, you can choose to replace the configuration with a new database. To replace the configuration on Solaris, remove the previous database before running the installation.

Complete these tasks before starting the upgrade:

Be sure that your environment meets the current system requirements—See the "System Requirements" section.

Complete any configuration changes in progress using the previous release so that the existing database is consistent before you perform the upgrade.

Back up your database—The installation program tries to detect configuration data from an earlier installation, and will upgrade the data to the 6.1.6 database format.

If you are upgrading from 5.5 and have IP history enabled, export and save your existing IP lease history data, or you will lose it.

Note the changes that can occur from the upgrade:

If upgrading from 5.5—Beginning with 6.0, usernames are not case sensitive. If you are upgrading from 5.5 with usernames that differed in case only, the upgrade deconflicts these names, with a warning message in the log files. All existing usernames are converted to NRCMD limited access users, as defined in the web UI, except the admin account, which is converted to superuser. If there is no admin account, it is created with a password of changeme.

If upgrading from 6.0—Beginning with 6.1, the localhost, localnet, any, and none access control list (ACL) names are reserved. If you are upgrading from 6.0 and have ACLs with these names in your current configuration, Network Registrar renames them with the oldname-1 convention and updates any instances of their use. For example, if you defined a localhost ACL in 6.0, the upgrade renames it to localhost-1.

If upgrading from 6.0 or 6.1—6.1.6 requires that administrators be assigned to groups that define their roles. If you are upgrading from 6.0 or 6.1 and have administrators assigned directly to roles, new groups are created for each of these roles and the administrators reassigned to these new groups. The new groups will have the same name as the roles, followed by the suffix -group.

Features Added in Release 6.1

This section briefly describes the features that were added in Release 6.1:

Central Cluster Administration

Enhanced Address Management

Cluster Management

RIC Server Support for Cisco CMTSs

DNS Server Enhancements

DHCP Server Enhancements

Import/Export Utility Enhancements

Process, File, and Utility Name Changes

These features and corresponding commands are described in greater detail in the Cisco Network Registrar User's Guide and the Cisco Network Registrar CLI Reference Guide.

Central Cluster Administration

Network Registrar 6.1 adds a regional management cluster to the local address server and address management architecture of Network Registrar 6.0 (see Figure 1). This regional cluster acts as an aggregate management system for up to 100 local clusters. Address and server administrators interact on the regional and local clusters through the regional and local web UIs.

The regional cluster consists of a CCM server, Router Interface Configuration (RIC) server, Tomcat web server, and server agent. A typical deployment is a regional cluster at a network operation center (NOC), the central point of network operations for an organization. Each division of the organization includes a local address management server cluster responsible for managing a part of the network.

The regional cluster can also manage router interfaces responsible for end-point cable modem termination systems (CMTSs). (See the "RIC Server Support for Cisco CMTSs" section.)

Figure 1 Network Registrar User Interfaces and the Server Cluster

Enhanced Address Management

This release significantly improves address management by providing a central view of address allocations spanning multiple Network Registrar DNS and DHCP servers and associated routers. The regional cluster supports a model in which address space flows from external authoritative sources to edge routers and network devices.

Address blocks are assigned from the authoritative source to intermediary allocators and are eventually divided into subnets for assignment to router interfaces. These subnet addresses are allocated statically to manually configured devices or assigned to DHCP servers for dynamic allocation.

Cluster Management

The Network Registrar 6.1 regional cluster centrally manages address space and protocol server configurations such as policies, client-classes, and scope templates. Administrators at the regional cluster can manage a list of Network Registrar local clusters and their credentials by using the regional web UI. Local cluster data is replicated at the regional cluster.

Table 2 shows the added functionality in Release 6.1. These functions require authentication and authorization, which are handled through multiple licensing and administrator role assignments, as described in the following subsections.

Cluster Licensing

These are the new licenses required for user and feature authentication and authorization:

local-cluster license—At the local cluster, sets the permissions to manage the DNS, DHCP, and TFTP protocol servers for the local cluster.

central-cluster license—At the regional cluster, sets permissions to manage the local clusters.

addrspace license—At the regional cluster, sets permissions to manage subnets and address blocks and to view IP address history and subnet utilization data.

router license—At the regional cluster, sets permissions to manage router interfaces through the Router Interface Configuration (RIC) server.

node-count license—At the local and regional clusters, reports the number of licensed nodes.

For information about when you need a new license key, see also the "License Keys" section.

Regional Administrator Roles

These are the new regional cluster administrator roles:

central-cfg-admin—Manages the local server clusters and routers to be centrally administered, along with the DHCP objects, failover pairs, and zone distributions. You can constrain the role by owners, regions, and subroles. The subroles are dhcp-management, ric-management, and dns-management.

regional-admin—Manages administrators, groups, roles, and licenses and views database change logs and tasks. The subroles are authentication, authorization, owner-region, server-management, and database.

regional-addr-admin—Manages the address space allocated to organizations, delegates address blocks to local clusters, and views address utilization and lease history reports. The subroles are subnet-utilization, lease-history, ric-management, and dhcp-management. (See also the "Regional Address Space Management" section.)

Regional Address Space Management

The regional address space administrators can manage these central cluster functions:

Address aggregation—The local address block can be rolled up (through replication) under its parent at the regional cluster, which allows a unified view of the address space at the regional cluster without affecting the local cluster configuration.

Address delegation—Administrators can delegate address space to the local cluster, which gives up authority of the delegated object.

IP address (lease) history reports—These reports provide a single vantage point on the IP lease history of multiple DHCP servers.

Subnet utilization reports—The regional cluster supports subnet utilization reporting across regions, protocol servers, and sets of network hardware.

Polling configurations—The administrator can control the intervals and periods of local cluster polling for replication, IP histories, and subnet utilization. You can also set the IP history and subnet utilization trimming ages and compacting intervals at the CCM server level.

These DHCP attributes were added for this feature:

collect-addr-util-duration—Maximum time period, in hours, that the server maintains address utilization data (default: 0 hours).

collect-addr-util-interval—Frequency, in minutes or hours, that the DHCP server should maintain address utilization data snapshots (default: 15 minutes).

Replica Data Propagation

The regional cluster maintains copies, called replicas, of configuration objects that are authoritatively managed at the local clusters. You can use this data as input to consistency validation rules, and you can pull (propagate) it into the authoritative data for the regional cluster. In general, the pull functions attempt to build a unified model of the data stored in the local clusters and then merge this model with the existing data in the regional datastore:

Pulling address space—The address space model is created by looking at the scope, subnet, and address block information on the local clusters. The scope information provides the failover pair information for subnets.

Pulling zone data—The list of zones and the mappings of primary and secondary servers are pulled from the replica data by examining the lists of replica primary (forward and reverse) and secondary zones and the servers with which they are associated.

RIC Server Support for Cisco CMTSs

Network Registrar 6.1 adds support for Cisco cable modem termination systems (CMTSs). The Cisco 7200 and Cisco 10000 series Universal Broadband Routers (uBRs) through the Router Interface Configuration (RIC) server module in the regional cluster. Network Registrar maps the relationship between a CMTS and the DHCP server that services it through the RIC server, which manages the interfaces and address space that reside on the CMTS. The RIC server synchronizes periodically with the CMTS through Telnet or secure shell (SSH).

DNS Server Enhancements

Network Registrar 6.1 enhances the DNS server by adding the following capabilities:

Zone transfers based on transaction signatures (TSIGs)—You can restrict DNS zone transfers based on TSIGs. The TSIG data can include a list of server IP addresses, networks, and TSIG keys. This attribute was added for this feature:

master-servers—For secondary zones, the list of servers from which data can be transferred. You can append each server address with an optional TSIG key name to configure secure zone transfers, in the syntax address-key. If you use the zone name create secondary addr command to create the secondary zone instead, the addr in that syntax becomes the master-servers value (no default).

The master-servers attribute replaces the auth-servers attribute. (You may need to update existing scripts written for previous releases.)

Restricted query access control lists (ACLs)—You can now limit query clients based on the ACL, source IP, or network address. The ACL can contain another ACL or a TSIG key. You can limit queries at the DNS server level or the zone level:

restrict-query-acl—Limits query clients based on the source IP address, source network address, or ACL (default: allow all queries).

restrict-xfer-acl—ACL that designates who is allowed to receive zone transfers. The zone value overrides this setting (no default). This attribute replaces the restricted-set attribute (you may need to update existing scripts written for previous releases).

Named ACLs—Network Registrar 6.1 reserves these ACL names to improve your ability to configure ACLs:

any—Anyone can perform a certain action.

none—No one can perform a certain action.

localhost—Any local host IP address can perform a certain action.

localnet—Any local network can perform a certain action.

If you are upgrading from 6.0 and have ACLs with the localhost, localnet, any, or none names in your current configuration, Network Registrar renames them with the oldname-1 convention and updates any instances of their use. For example, if you defined a localhost ACL in 6.0, the upgrade renames it localhost-1.

Enhanced statistics—Network Registrar 6.1 adds the following statistical performance counters so you can better measure the performance of its DNS server, including query performance, security, internal errors, and maximum counters.

activity-counter-interval—Sample time interval of server counters (default: 5 minutes).

activity-counter-log-settings—Logs DNS server activity counters in different categories (default categories: total, performance, query, errors, and security).

activity-sample-interval—Sampling period of DNS activity counters, in seconds (default: 5 minutes).

These additional DNS attributes were added:

default-negcache-ttl—Time, in seconds, that negative answers are cached if no SOA resource record exists in the authority section of the reply. An SOA record in the authority section of a negative answer overrides this attribute value (default: 0 seconds).

delegation-only-domains—Limits zones to contain name server (NS) resource records for subdomains but no actual data beyond their own apex (for example, SOA records and apex NS record sets) (no default).

The lame-delegation-notify attribute was deprecated in this release. (You may need to update existing scripts written for previous releases that used this attribute.)

DHCP Server Enhancements


Note All changes to the DHCP server require a server reload except setting debug values, and adding, modifying, and deleting clients.


Network Registrar 6.1 adds several capabilities to the DHCP server:

Allocation priority configuration—The DHCP server now lets you disable round-robin allocation across multiple subnets by setting the allocation priority for each subnet. In addition, you can configure the server to allocate addresses contiguously from within a subnet and control the block of addresses allocated to the backup server when using DHCP server failover.

These dhcp command attributes were added for this feature:

equal-priority-most-available—If multiple scopes have the same nonzero allocation priority, the scope with the most available addresses is used to allocate an address for a new client (if it is not in a limitation list; default: disable).

priority-address-allocation—Considers scopes in the order of the allocation priority if the scope's allocation-priority attribute is set. If the allocation-priority is unset, the scope's subnet address becomes the allocation priority (default: disable).

These scope command attributes were added for this feature:

allocate-first-available—Forces all new IP addresses from the scope to be allocated from the first available address. If disabled, allocation is from the least recently used address (default: disable).

allocation-priority—Assigns an ordering to scopes so that IP addresses are allocated from acceptable scopes with a higher priority until all addresses in these scopes are allocated. Lower values have a higher priority (default: 0 is equal to no allocation priority).

failover-backup-allocation-boundary—If the scope participates in a failover relationship, this is the address boundary below which the failover backup server's addresses are allocated. Normal client addresses are allocated in ascending order, while the backup server's addresses are allocated in descending order from this boundary (no default).

Improved IP lease history—The IP lease history feature significantly improves server performance when it is enabled. The IP lease history data is no longer stored in a separate database and is now maintained concurrently with the active lease data. To ensure that the database does not grow without limit, records older than the configured maximum time period are deleted:

The ip-history-max-age attribute was added in this release—If ip-history is enabled, the DHCP server accumulates database records over time as lease bindings change. This parameter establishes an age limit for the history records that are kept in the database (default: 4 weeks).

The ip-history-dir attribute was deprecated in this release. (You may need to update existing scripts written for previous releases.)

This additional dns command attribute was added to address the DHCP server: map-radius-class—Controls using the RADIUS class attribute if it exists in a DHCP request's relay-agent option. The values are none (default), map-as-tag, map-as-class, and append-to-tags.

Import/Export Utility Enhancements

In Release 6.0, an import/export (cnr_exim) utility was added to manage importing and exporting configuration data. In Release 6.1, new objects were added to represent configuration data that also needs to be imported or exported by using the cnr_exim utility:

DHCP—AddrSpaceType, RouterType, and VPN

Cluster—ServerConfig and RouterLoginTemplate

An important aspect to this feature is that these new objects, such as AddrSpaceType, are exported as part of the DHCP or cluster classification only and not as single objects. If a file contains these objects in the configuration, the objects are now exported as part of the file.

The cnr_exim utility is available on both the local and regional clusters. It exists in the bin directory on Windows and the usrbin directory on Solaris or Linux. For details about using the utility, see the Cisco Network Registrar User's Guide.

Process, File, and Utility Name Changes

Several Network Registrar processes, files, and utilities changed from the introduction of regional and local cluster configurations and general product evolution. The most notable changes are the product extensions to include new CCM regional and local servers that replace the previous MCD configuration server. Because of this, there are now two distinct server agent processes, and different web UI references for the regional and local servers, respectively. The name changes are summarized in Table 3.


Caution These changes can affect user scripts written for previous releases.

Table 3 Name Changes in Network Registrar 6.1 

Previous Name or Path
New Name(s) or Paths

AIC Server Agent 2.0
(Windows server agent service)

Network Registrar Local Server Agent (nwreglocal)
Network Registrar Regional Server Agent (nwregregion)

/etc/init.d/aicservagt
(Solaris/Linux server agent service)

/etc/init.d/nwreglocal
/etc/init.d/nwregregion

aicservagt.exe

cnrservagt.exe (Windows server agent process)

aicservagt

cnrservagt (Solaris/Linux server agent process)

mcdsvr.exe

ccmsrv.exe (Windows CCM server file)

mcdsvr

ccmsrv (Solaris/Linux CCM server process)

config_mcd_1_log file

config_ccm_1_log file (CCM configuration log file)

aicstatus

cnr_status (server status utility-UNIX platforms only)


Features Added in Release 6.1.1

This section describes the features added in Network Registrar 6.1.1:

Central Management of Administrators, Groups, and Roles

IP Lease History Detail

Current Utilization Reporting

Improved DNS Query Performance

Enhanced Server Controls

Zone Recovery Tool

Connection Security Between Clusters

Central Management of Administrators, Groups, and Roles

In Network Registrar 6.1.1 and later, you can centrally manage administrators and related administrator data. This feature allows administrators, groups, and roles to be defined centrally at one time and then populated throughout the system. To simplify central management, groups are used exclusively to associate administrators with roles. These groups now manage the role assignments.

If administrators in the previous release were configured with direct role assignments, the upgrade converts these role assignments to group assignments. Group names are created from role names by appending -group, with numbers appended as needed to avoid conflicting names. These groups are only created for the upgrade, and only for roles that have administrators associated with them. The upgrade does not automatically generate a group for roles that have no administrators associated with them.

For new 6.1.1 and later installations only (not upgrades), the regional and local clusters now create predefined groups for each base role. Owners and regions are also centrally managed because this information provides the basis for role permissions. Owners and regions now have a push-and-pull mechanism at the regional level that is independent of the administrators/groups/roles push and pull.

Administrator password management was also enhanced so that any administrator can change his or her own password. Before this release, administrators could change their passwords at the local or regional levels only if they had ccm-admin and regional-admin role permissions, respectively. (You can change passwords in the web UI.)


Note You can use this administrator central management feature between 6.1.1 and later clusters. In releases earlier than 6.1.1, you could not pull and push all data related to this feature between clusters.


IP Lease History Detail

A new option is available to record additional detail for IP lease history detail. When IP lease history detail is enabled, each interaction between the DHCP server and client is recorded and reported.

The DHCP and CCM servers each have a new configuration attribute in the lease-history category:

ip-history-detail—Causes the DHCP server to maintain a database that records every change to a lease binding, including each renewal. This feature is only meaningful if ip-history is enabled (default: disabled).

lease-hist-detail—If polling for IP lease history, the CCM server also asks the DHCP server to return history detail if it is available (default: enabled).

Current Utilization Reporting

The current utilization reporting feature adds viewing current subnet or scope utilization data from the regional or local web UI:

Local and regional web UI pages display current utilization by address block, subnet, and scope.

New current utilization web pages provide a convenient link to jump to view most recent historical subnet utilization data.

Enhanced regional web UI pages display historical data so that the latest data for each address block and subnet is shown. Simple calculated fields, such as %free, were added to the report. In addition, all subnet utilization queries filter on virtual private networks (VPNs).

The report command in the CLI now provides a one-line summary of lease utilization for each scope, subnet, and address block. The summary includes the subnet number and mask, scope name, totals for dynamic and reserved leases, percentage of dynamic leases that are free, and counts for the lease states.

These attributes for the report command were deprecated in 6.1.1:

config=config-file

leasing-only

mask-bits

dns-only

Improved DNS Query Performance

The DNS server was enhanced to provide greater query throughput (number of queries per second that a server can handle). Improvements to input request queue handling allow the server to handle concurrent queries more effectively. Throughput is increased as much as 50% on dual-processor systems. Also, in the server's default configuration, cached answers to queries are also persisted to disk. Because writing to disk can be very costly in terms of performance, a new attribute was added to disable this feature. When time-to-live (TTL) values are relatively short, little value would exist in saving the cache entries, because they are likely to have expired when they are retrieved from disk the next time.

These attributes were added in 6.1.1:

max-dns-packets—Maximum number of concurrent packets (default: 500).

persist-mem-cache—For records stored in in-memory cache, determines if the DNS server should read and write records to and from the persistent cache database (cache.db) (default: enabled).

auth-db-cache-kbytes—Size (in KB) of the internal cache of authoritative records retrieved from the authoritative zone database (authzone.db) (default: 5 MB).

cache-db-cache-kbytes—Size of the internal cache.db records (default: 5 MB).

In addition, the default for the DNS mem-cache-size attribute was changed from 200 KB to 10 MB.

Enhanced Server Controls

This section explains additional server improvements added in this release.

DHCP Failover Controls in the Web UI

Equivalents of the getRelatedServers and setPartnerDown CLI commands were added to the web UIs. These two commands are useful when you are monitoring the DHCP failover pair's operation.

In the regional web UI, these features were added to the View Cluster Tree and the List Failover Pairs pages. On the local web UI, they were added to the Manage DHCP Server and List Failover Pairs pages.

For failover servers, if you click the server name, the View Failover Related Server page displays comprehensive information concerning the failover relationship represented by this related server. Note that this functionality is only available when interacting with a 6.1.1 or later cluster.

Dynamic DNS Update Configuration

The scope dynamic-dns attribute was extended to use these new configuration values:

update-none—Does not perform dynamic DNS update for leases in this scope.

update-all—Performs dynamic DNS update to forward and reverse zone for leases in this scope.

update-fwd-only—Performs dynamic DNS update to forward zone alone for leases in this scope.

update-rev-only—Performs dynamic DNS update to reverse zone alone for leases in this scope.

If you are using CLI scripts with dynamic-dns, you need to edit them to work with 6.1.1 and later:

The scope name enable dynamic-dns command changes to the new command syntax scope name set dynamic-dns=update-all.

The scope name disable dynamic-dns command changes to scope name set dynamic-dns=update-none.

These changes were made to the DHCP extensions for dynamic DNS update:

In the request dictionary, a new update-dns attribute was added to be a read/write integer. This attribute enables extension users to request partial, full, or no dynamic DNS updates on a per request packet basis. These are the acceptable (input and output) values:

Update-none—Equivalent to a scope name dynamic-dns=update-none setting where the DHCP server does not perform any DNS updates.

Update-all—Equivalent to a scope name dynamic-dns=update-all setting where the DHCP performs forward and reverse zone updates.

Update-fwd-only—Equivalent to a scope name dynamic-dns=update-fwd-only setting where the DHCP performs only forward zone updates.

Update-rev-only—Equivalent to a scope name dynamic-dns update-rev-only setting where the DHCP server performs only reverse zone updates.

In the response dictionary, a new scope-update-dns attribute was added to be a read-only integer. The return values are the same as for the request attributes update-none, update-fwd-only, and update-rev-only.

DNS Forwarder Configuration

In previous releases, when a query (nonauthoritative and not yet cached) was sent to a forwarder, the server waited a fixed time of 8 seconds for a response before querying the next forwarder. In 6.1.1, you can configure this time period by using the following new attributes:

forward-retry-time—Retry time for forwarding a DNS query in slave mode to a forwarder or resolution exception server (default: 8 seconds).

request-retry-time—Retry time interval, in seconds, when querying a configured server (not in slave mode). This time interval is used in general UDP queries in response to DNS client queries, zone transfer state of authority (SOA) queries, incremental zone transfer (IXFR) requests, and notify requests (default: 4 seconds).

request-expiration-time—Expiration time, in seconds, of a DNS request (that is, a DNS query, zone transfer SOA query, IXFR, or notify request) (default: 90 seconds).

restrict-recursion-acl—As a global ACL, restricts the recursive queries that the DNS server honors. This list can contain hosts, network addresses, transaction signature (TSIG) keys, and ACLs that restrict recursive queries to a certain set of DNS clients (default: any).

tcp-query-retry-time—Retry time for DNS queries over a TCP connection (not in slave mode) (default: 10 seconds).

Zone Recovery Tool

The zone recovery tool is a command line tool whereby you can convert a secondary zone to a primary zone when the primary zone is lost. The tool lets you pick different sources from which to extract the necessary data and specify a target machine.

If you need to extract information from a primary and a secondary source, the two sets of data are merged to produce a complete configuration. In this case, however, the primary zone configuration takes precedence, and only the nonduplicated resource record sets are used from the secondary configuration source.

The tool exists in the bin directory on Windows and the usrbin directory on Solaris or Linux. For details about using the tool, see the Cisco Network Registrar User's Guide.

Connection Security Between Clusters

Network Registrar 6.1.1 added support for configuring connection security between clusters, failover servers, and zone distribution servers by using a new use-ssl attribute for outbound connections:

At the regional cluster, for connections to local clusters.

For local and regional DHCP failover pair connections to remote servers.

For local and regional zone distribution connections to remote servers.

In each case, the new use-ssl attribute can have one of three values:

Optional (default)—If the Security Option is installed, use secure connections; otherwise, do not require them.

Required—The Security Option is required to handle secure connections.

Disabled—Disable secure connections.

In previous releases, both inbound and outbound connection security was determined through the cnr.conf file security-mode setting. This setting now controls inbound connections only. However, if security-mode is disabled and outbound connections are configured with use-ssl required, the connections will fail, because a secure connection is not possible.

Features Added in Release 6.1.2

Release 6.1.2 now supports the Windows 2003 and Linux Enterprise Server (ES) 3.0 operating systems.

Features Added in Release 6.1.3

Backward compatibility with Release 5.0 was removed from this release. Also, a dexChattyClientFilter extension was added.

Features Added in Release 6.1.4

Features added and enhancements made in Release 6.1.4 include:

The dns getStats command now displays statistics in read-only mode.

A product upgrade now prompts to archive the existing installation. It also now supports dns.ndb files larger than 2 GB.

The cnr-exim tool now exports DHCP failover pairs.

Lease renewal is now handled more effectively (CSCsc32239). Perhaps due to differences in clock times, a client might renew a lease earlier than at the expected T1 renewal time (typically half the lease time). If defer-lease-extensions was also enabled for the client, the DHCP server properly grants the remaining lease instead of extending the expiration. However, the server also changes the client's expected T1 even if the expiration was not extended. The result is that if the client repeatedly renewed earlier than T1, the server would keep giving the client shorter and shorter leases instead of extending its expiration. This condition was corrected so that the server now applies a 60-second grace period to renewals (to accommodate clock drift), and does not change T1 if it is not extending the expiration.

Features Added in Release 6.1.4.1

The backup and restore function changed in Release 6.1.4.1. See the "Backup and Restore Changes Made in Release 6.1.4.1" section. See also the "Caveats" section.

Features Added in Release 6.1.4.2

The 6.1.4.2 release includes an enhancement to the response data dictionary for use with the lease-state-change extension point. The enhancement introduces a new attribute, response-source. This attribute returns one of the following values:

unknown

client

failover

timeout

operator

one-lease-per-client

When a client is the response-source, a request dictionary is available to the extension at the lease-state-change extension point.

Features Added in Release 6.1.5

Network Registrar 6.1.5 was a limited distribution technical (T) release of the software.

Features Added in Release 6.1.6

The 6.1.6 release fixes a number of outstanding bugs. These fixes are described in the "Software Caveats" section.

Caveats

Table 4 describes the major resolved bugs in Network Registrar 6.1.6. Also, see the "Solaris Installation Changes as of Release 6.1.2" section.

You can find the complete bug list in the CNR616_Bug_List.html file included in the installation media, or at the Network Registrar software download site:

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

You must have a valid Cisco Connection Online account to access the software download site.

Software Caveats

The major bug fixes made in this release are listed in Table 4. Also, see the "Backup and Restore Changes Made in Release 6.1.4.1" section.

Table 4 Major Bugs Fixed in Release 6.1.6 

CDETS Number
Software Release
Fixed in 6.1.6
Condition/Symptom/Workaround

CSCdz68825

When using the CLI, the CCM server fails after several simultaneous connections.
Workaround: Restart Network Registrar without starting multiple connections.

CSCeh89969

A user defined with the ccm-admin-group role cannot view details of the CCM change log. The user receives an error message stating:

com.cisco.cnr.sdk.ScpAuthorizationException: GetDBSN: PERMISSION_DENIED  

Workaround: Define user with superuser enabled.

CSCsc64128

On the List/Add DNS Server RRs for Zone <zonename> and List/Add CCM Server Protected RRs for Zone <zonename> pages, if you add an RR, Network Registrar does not trim trailing spaces from the Data field.

So, for example, if you add a CNAME record to zone "foo.tst.",where name is "ned", type is CNAME, and data is "edward ", Network Registrar creates the record with the data "edward .foo.tst."

Workaround: Be sure not to type trailing spaces in the Data field.

CSCsd91939

In failover environments, the DHCP server rebalances the leases allocated to the backup server with those allocated to the main server to ensure that the correct percentage of the available leases is allocated to the backup server. This rebalancing goes on whenever the servers enter NORMAL state as well as once an hour, by default.

When the main server gets low on leases in a particular scope, it takes back some leases from the backup server when rebalancing occurs. Because of the particular algorithm used to perform this rebalancing, it is likely that about five leases remain on the backup server when the main server is low or even out of leases to hand out to DHCP clients. This situation results in premature exhaustion of the lease pool for this scope.

Workaround: The only workaround for this situation is to ensure that enough leases are available on the network to which the scope belongs so that leases are always available for DHCP clients.

CSCse18499

On rare occasions a DNS secondary server might into a state where it constantly tries to connect to a primary for zone transfer. This problem arises if the primary server goes down after issuing a notify message to the secondary.

CSCsf08767

When performing DNS updates for reverse zones, DHCP generates corrupt TXT RRs for client IDs longer than 84 bytes.

Workaround: Prevent a client from using client IDs longer than 84 bytes.

CSCsf32509

The DHCP server in PARTNER DOWN state ignores a dhcp-requested-address even after the MCLT has passed and the lease is in an other-available state. Workaround: None.

CSCsf98245

The server does not properly release the request packet after processing it, if all the following conditions exist:

1. A lease is denied a client because the DHCP server uses a limitation-count that was exceeded.

2. If there is a dhcp-requested-address option in the request packet, and

3. The IP address specified is not in the same network as the giaddr in the DHCPDISCOVER packet. This situation results in an increasing in-use count in the activity summary in the incoming-requests log message (04619).

Workaround: Give the client-class that contains the limitation-id an over-limit-client-class value, which specifies a selection-criteria that is not in any existing scope.

CSCsg12063

The DNS server fails on rare occasions when zone checkpointing occurs at the same time the server is processing other requests on the same zone.

CSCsg51808

If two DNS servers are defined as authoritative for the same zone, it is possible that one DNS server's in-memory cache might become corrupted by RRs from the other server in the same zone. This problem can happen if the DNS server attribute persist-mem-cache is disabled.

Workaround: Enable the persist-mem-cache server attribute.

CSCsg99647

The CCM server leaks memory when the SyncZoneDistribution function is run. The memory leak is proportional to the number of zones in the configuration. If available memory is exhausted, the server might fail.

Workaround: Periodically restart the server.

CSCsh04638

When processing a request to update local administrators from the regional CCM server, the local CCM server leaks memory proportional to the number of administrators being updated. Over time, the server may exhaust available memory and fail.

Workaround: Periodically restart the server to avoid a server failure.

CSCsh22271

In rare situations, the DHCP server fails on force-available for a lease in a failover situation because a leased lease does not have a client pointer.

Workaround: Enable the log-setting "no-success-messages" to remove from active use the only code path that is not protected against this problem.

CSCsh26871

When TSIG is enabled, DHCP sometimes does not add the expected TSIG RR to an update. This results in log messages such as:

... name/dhcp/1 Warning Server 0 05682 Lease '#.#.#.#',

client '01:00:0a:0b:0c:0d:0e': DNS server at '#.#.#.#' returned

error 'NO ERROR' after an attempt to update the name 'dhcp-151-6876' in

zone 'xxx.yyy.com'. This Server received a Dynamic DNS response packet

without(or with an invalid) TSIG RR. This dynamic update response will

be discarded, and dynamic-update processing will not be retried.


Workaround: The only workaround at this time is to unconfigure/not require TSIG for updates.

CSCsh28984

When DNS has reached its maximum resolution queue size, there is no error or warning logged.

Workaround: Enable debugging messages with the following command:

nrcmd> dns setDebug D=8

CSCsh35110

In some cases, a DHCP client that sends in a DHCPINFORM request may get option values that are incorrect for its client-class, and different from those that it received on its DHCPOFFER and DHCPACK when the lease was originally granted or renewed.

See CNR616_Bug_List.html on the installation media for a complete description of this bug and the workarounds for it. The description is also available at the Network Registrar software download site:

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

CSCsh81736

Viewing the current utilization for subnets or DHCP scopes, (either through the web UI or through the CLI report command) causes CCM to grow in size as it causes CCM to leak memory.

Workaround: If possible, limit viewing the current utilization. Periodically restart the server agent when CCM's memory footprint has grown significantly.

CSCsh96682

Incoming incremental zone transfers sometimes cause query performance issues. This performance degradation can occur under continuous IXFR load and simultaneous query loads.

Workaround: None.

CSCsh96694

While processing many inbound AXFRs or a few for large zones, query performance could degrade.

Workaround: None.

CSCsi07158

Under load, a DNS primary server might experience performance issues and possibly deadlock.

Workaround: If the DNS server appears unresponsive, stop and restart Network Registrar.

CSCsi56927

When the DNS server reaches its max-dns-packets limit, it will silently drop an incoming request without providing a log message.

Workaround: Enable the dtrace level that displays the number of times the server has dropped packets due to hitting the max-dns-packets limit. To enable this dtrace, run the following command:

nrcmd> dns setDebug M=8

CSCsi77091

A main DHCP server in a failover situation sometimes allocates leases to the backup server and then immediately takes them back from the backup server.

This situation occurs only when there are three leases available between the main and the backup.

Workaround: There is no workaround for this problem. There is no significant negative impact of this problem.


Documentation Caveats

The Cisco Network Registrar CLI Reference Guide includes these caveats:

Chapter 2, "Using the nrcmd Commands," the sections on the client and client-class-policy commands should state that when leases expire on a DHCP server these commands are not used in processing. Thus, attributes such as grace-period that are configured on client and client-class policies are ignored. The grace-period attribute is only used when configured on the embedded or named policies of a scope.

Chapter 2, "Using the nrcmd Commands," the section on the policy command incorrectly describes the setVendorOption syntax. (CSCsi61211)

The correct syntax is:

[type-]policy name setVendorOption vendoroption suboption field

The Cisco Network Registrar User's Guide includes these caveats:

Chapter 4, "Configuring Local and Regional Administrators," should state that if the NRCMD flag is set for an administrator, it overrides any roles set for that administrator (CSCeg80070). Also, note that in the tutorial section of this chapter, in the "Create the Local Clusters" section, the example-central-admin (not the example-ccm-admin) should add the clusters (CSCei42766).

Chapter 7, "Maintaining Databases," was changed to reflect newly enhanced backup procedures introduced in Release 6.1.4.1 (CSCsd74097). See the "Backup and Restore Changes Made in Release 6.1.4.1" section.

Open Source License Acknowledgements

The following acknowledgements 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:

© 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:

© 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

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.