Guest

Cisco Network Registrar

Release Notes for Cisco Network Registrar 7.1.2.1

  • Viewing Options

  • PDF (256.4 KB)
  • Feedback
Release Notes for Cisco Network Registrar 7.1.2.1

Table Of Contents

Release Notes for Cisco Network Registrar 7.1.2.1

Contents

Introduction

Before You Begin

System Requirements

CNR Communications Security Option

Software and Standards Compatibility

Interoperability

Installation and Upgrade Notes

General Installation

Red Hat Linux Installation

Upgrade Considerations

Moving CNR to a New Machine

About CNR SDK

Installing CNR SDK

Installing on Linux or Solaris

Installing on Windows

Testing Your Installation

Compatibility Considerations

New and Changed Features

New Features in CNR 7.1

Dynamic Lease Notification

Discriminating Rate-Limiter

Performance Improvements

Dashboard Improvements

User Management Improvements

EDNS0 Support

DNS Blackhole Support

New Platform Support

DHCP Option Definitions List Enhancements

New and Changed Features in CNR 7.1.1

VMWARE Support

Changes to Dynamic Lease Notification

New Features in CNR 7.1.2.1

Limitations and Restrictions

Caveats

Documentation Errata

Related Documentation

Notices

OpenSSL/Open SSL Project

License Issues

Obtaining Documentation and Submitting a Service Request


Release Notes for Cisco Network Registrar 7.1.2.1


Revised: September 01, 2010

This release notes is for Cisco Network Registrar (CNR) release 7.1.2.1. This document describes system requirements, installation and upgrade notes, new features and implementation, and caveats.

Contents

This release notes covers the following topics:

Introduction

Before You Begin

Software and Standards Compatibility

Interoperability

Installation and Upgrade Notes

About CNR SDK

New and Changed Features

Limitations and Restrictions

Caveats

Related Documentation

Notices

Obtaining Documentation and Submitting a Service Request

Introduction

This release of CNR resolves a number of customer-reported issues with earlier releases.

Before You Begin

Review the following sections before installing CNR 7.1.2.1:

System Requirements

CNR Communications Security Option


Note If you are migrating to CNR 7.1.2.1 from an earlier version of CNR, you must review the Release Notes for the releases that occurred in between, to fully understand all the changes.


System Requirements

Review these system requirements before installing the CNR 7.1.2.1 software:

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

Operating system—We recommend that your CNR machine run on the Windows, Solaris, or Linux operating systems as described in Table 1. CNR must run on 32-bit or 64-bit operating systems.


Note CNR applications are 32-bit applications and the system should support 32-bit applications (Java JRE/JDK, OpenLDAP library (for RH)).


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

Web UI—Runs on a minimum of Microsoft Internet Explorer 6.0 (Service Pack 2) and 7.0, Mozilla Firefox 2.0 and 3.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 Cisco Network Registrar System Recommendations 

Component
Operating System
Solaris
Linux
Windows

OS version1

Solaris 102

Red Hat Enterprise Linux ES 4.03

Red Hat Enterprise Linux 5.03

Windows Server 20033

Disk space4

2 x 73/146 SAS5 drives

With basic DHCP and optimal hardware configuration:

SATA6 drives with 7500 RPM drive > 500 leases/second

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

(Recommended hard drive 146 GB)

Memory7

16 GB

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

1 CNR must run on 32-bit or 64-bit operating systems.

2 CNR 7.1.2.1 supports 128-KB block sizes in the Solaris 10 ZFS.

3 CNR now supports running in a VMWARE (ESX Server 3.5) environment for Red Hat Enterprise Linux ES 4.0, 5.0, and Windows Server 2003.

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

5 Serial Attached SCSI.

6 Serial Advanced Technology Attachment (Serial ATA).

7 Faster CPU and more memory typically result in higher peak leases per second.



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


CNR Communications Security Option

You need to upgrade the security option to Network Registrar Communications Security Option release 2.2 for CNR 7.1.2.1.

Software and Standards Compatibility

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


Note CNR 7.1.2.1 is compatible with Cisco Broadband Access Center 4.0.1.5 and 4.0.1.6.


Interoperability

CNR 7.1.2.1 protocol servers interoperate with CNR versions 7.0, 6.3.x, and 6.2.x. CNR 7.1.2.1 will not support interoperability with versions earlier than 6.2.x.

CNR 7.1.2.1 DHCPv4 failover servers interoperate with CNR 7.0.x, 6.3.x, and 6.2.x failover servers.

By the nature of the EDNS0 protocol, CNR 7.1.2.1 DNS servers interoperate with earlier versions of CNR DNS (and 3rd party DNS vendors). EDNS0 defines the interoperability with DNS servers that do not support EDNS0; CNR 7.1.2.1 DNS adheres to the RFC and consequently interoperates with earlier versions of CNR.

CNR 7.1.2.1 HA DNS servers interoperate with CNR 7.0.x, 6.3.x, and 6.2.x versions.

CNR 7.1.2.1 DDNSv6 interoperates only with CNR 7.0 and CNR 7.1 DNS servers—because of the usage of the DHCID RRs.

Installation and Upgrade Notes

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

This section covers:

General Installation

Red Hat Linux Installation

Upgrade Considerations

Moving CNR to a New Machine

General Installation

CNR now implements the FLEXlm licensing mechanism; therefore, you must obtain a FLEXlm license file.

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


Note If CNR has to be installed via a Remote Desktop Connection on a Windows Server, you will not be able to enter the license information during the installation process. CNR will reject the license as invalid. You have to skip the license information steps (select an appropriate option to continue the installation process without a license), and then add the license using either the Web UI or nrcmd, after the installation has completed.


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

Windows, Solaris, and Linux installations occur through:

Windows—Windows-based InstallShield setup program.

Solaris—The pkgadd command.

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

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

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

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

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

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

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

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

CNR 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 CNR on Red Hat Linux requires that the 32-bit OpenLDAP library be installed; otherwise, the DHCP server may fail to start.

To verify if openldap is installed, enter:

# rpm -ql openldap | more

If the openldap package is installed, the LDAP library details will appear; otherwise the following error message appears:

package openldap is not installed

To install the openldap package, enter:

# yum install compat-openldap.i386

Upgrade Considerations

CNR 7.1.2.1 supports upgrades from CNR versions 6.2 and later. When you install the software, the installation program automatically detects an existing version and upgrades the software to the latest version. The program first prompts you to archive existing CNR data. If the program encounters errors during the upgrade, it restores the software to the earlier release.


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


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

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


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


To upgrade to CNR 7.1.2.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 CNR server agent and back up the existing database:

Windows

if local—net stop nwreglocal

if regional—net stop nwregregion

Solaris and Linux

if local—/etc/init.d/nwreglocal stop

if regional—/etc/init.d/nwregregion 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 CNR.


Note We recommend you to upgrade the regional cluster before upgrading any local clusters, because an older version of a regional cluster cannot connect to newer local clusters (CSCsm61420).



Note For upgrades from CNR version 6.2 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.



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


Caution To complete this process, you must have access to the product installer and license key or license file for the earlier CNR version. Any attempt to proceed otherwise may destabilize the product.
If the installer had successfully performed the upgrade but you want to roll back to the earlier version at some later point, this procedure can result in network destabilization and data loss; for example, you will lose updates made to the CNR database after the upgrade, including DHCP lease data and DNS dynamic updates.

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

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

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

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

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

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

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

Windows

if local—net stop nwreglocal

if regional—net stop nwregregion

Solaris and Linux

if local—/etc/init.d/nwreglocal stop

if regional—/etc/init.d/nwregregion stop

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

g. Extract the contents of the backup file to the newly reinstalled version of CNR. To do this:

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

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

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


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


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

h. Start the CNR server agent:

Windows

if local—net start nwreglocal

if regional—net start nwregregion

Solaris and Linux

if local—/etc/init.d/nwreglocal start

if regional—/etc/init.d/nwregregion start

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


Moving CNR to a New Machine

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


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

Step 2 Stop the server agent on the old machine:

Windows

if local—net stop nwreglocal

if regional—net stop nwregregion

Solaris and Linux

if local—/etc/init.d/nwreglocal stop

if regional—/etc/init.d/nwregregion stop

Step 3 Zip the data directory on the old machine.

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

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

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

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


About CNR SDK

This section documents how to install the CNR SDK and details the compatibility considerations. The following are the topics covered in this section:

Installing CNR SDK

Compatibility Considerations

Installing CNR SDK

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

Installing on Linux or Solaris

To install the CNR SDK on a Linux or Solaris platform:


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

a. Create the SDK directory:

% mkdir /cnr-sdk

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

% cd /cnr-sdk

% tar xvf sdk_tar_file_location/cnrsdk.tar

Step 2 Export your LD_LIBRARY_PATH and CLASSPATH environment variable:

% export LD_LIBRARY_PATH=/cnr-sdk/lib

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


Installing on Windows

To install the CNR SDK on a Windows platform:


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

a. Create the SDK directory:

> md c:\cnr-sdk

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

> c:

> cd \cnr-sdk

> tar xvf sdk_tar_file_location\cnrsdk.tar

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

Step 2 Set your PATH and CLASSPATH variables:

> set PATH=%PATH%;c:\cnr-sdk\lib

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


Testing Your Installation

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

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

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

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

Compatibility Considerations

For Java SDK client code developed with an earlier version of the SDK, you can simply recompile most code with the latest JAR file to connect to an upgraded server.

But in cases where the client code directly manipulates reservation lists in scopes or prefixes, changes will be required. These changes are required because the embedded reservation lists in both scopes and prefixes are no longer used. Individual reservations are now stored separately and reference the parent scope or prefix by name.

The new design provides the following benefits:

Reservation edits (add/modify/delete) do not require a scope or prefix edit.

Reservations can be indexed directly to allow quick search and retrieval.

Edits to scopes or prefixes with a large number of reservations no longer result in large scope or prefix change entry logs.

No changes are required for client code that adds or removes reservations using the addReservation or removeReservation methods. However, these methods are now deprecated because the edit functionality has been replaced and extended by the general addObject, modifyObject, removeObject, addObjectList, modifyObjectList, and removeObjectList methods.

New and Changed Features

This following are the topics covered in this section:

New Features in CNR 7.1

New and Changed Features in CNR 7.1.1

New Features in CNR 7.1.2.1

New Features in CNR 7.1

This section briefly describes the following new and modified features in the CNR 7.1 release:

Dynamic Lease Notification

Discriminating Rate-Limiter

Performance Improvements

Dashboard Improvements

User Management Improvements

EDNS0 Support

DNS Blackhole Support

New Platform Support

DHCP Option Definitions List Enhancements

Dynamic Lease Notification

With Dynamic Lease Notification, customers can have external systems notified whenever CNR issues a lease. This feature is used in Lawful Intercept solutions and long-term storage of customer data for Regulatory Compliance and Operational Efficiency.

For more details, please see the "Managing Leases" chapter of the User Guide for Cisco Network Registrar.

Discriminating Rate-Limiter

The patent-pending Discriminating Rate-Limiter reduces downtime after outage in very large service networks by restricting the rate of DISCOVER requests while still honoring all RENEW requests.

For more details, please see the Table 23-1 in the "Advanced DHCP Server Properties" chapter of the User Guide for Cisco Network Registrar.

Performance Improvements

Protocol Implementation improvements that enhance the query performance of the DNS server. The improvements to the DNS vulnerability fix enhances the query performance. The DHCP reservation system improvements enhances the reliability and performance of this mechanism.

Dashboard Improvements

CNR 7.1 provides the end-users the ability to select and persist the dashboard default chart types.

User Management Improvements

The fine-grained role-based system includes the ability to define the administrative roles at the scope/prefix and link levels of DHCP. Also admin password changes are now synched between regional and local clusters.

EDNS0 Support

Added support in the DNS implementation for EDNS0 as defined in RFC 2671 (not including the request forwarding).

DNS Blackhole Support

The DNS server can now be configured to avoid the interaction with misbehaving and/or unresponsive remote name-servers and clients.

For more details, please see the "Handling Malicious DNS Clients and Unresponsive Nameservers" section of the "Managing DNS Server Properties" chapter of the User Guide for Cisco Network Registrar.

New Platform Support

CNR 7.1 is optimized to leverage the multi-core processors. It is certified to run on 64 bit variants of the supported OS versions and Red Hat 5.0 was added to the list of supported OS's.

DHCP Option Definitions List Enhancements

The DHCP option definitions list has been updated to support the following RFCs, which does not require any modification to the DHCP server behavior,

RFC5192 is the PANA option, which was not an RFC on CNR 7.0 release

RFC5223 is the LOST server option

Cisco Vendor Specific Option definitions is included in the dhcp-cisco-config and dhcp6-cisco-config option definitions sets

For more details about the new software features added, please see the User Guide for Cisco Network Registrar.

New and Changed Features in CNR 7.1.1

This following are the topics covered in this section:

VMWARE Support

Changes to Dynamic Lease Notification

VMWARE Support

CNR now supports running in a VMWARE (ESX Server 3.5) environment for Linux RedHat 4.0, Linux 5.0, and Windows Server 2003.

Changes to Dynamic Lease Notification

The dynamic lease notification feature is modified to include the following:

Changing the processing of active leasequery sessions on reload in order to reduce or remove the necessity for the dynamic lease notification client to issue a bulk leasequery when the server returns to service. The detailed description is given in the "Avoiding Bulk Leasequery for Active Leasequery Client After DHCP Reload" section.

Allowing extensions to control the sending of active leasequery packet to the dynamic lease notification client. The detailed description is given in the "Using Extensions to Control Active Leasequery Notifications" section.

Avoiding Bulk Leasequery for Active Leasequery Client After DHCP Reload

In CNR 7.1, a DHCP server reload required an active leasequery client to issue a bulk leasequery to capture any changes between the time the server was shutting down and the client reconnected to the server after the server restarted.

While a client can still do this, the DHCP server is enhanced as follows to reduce the need for this bulk leasequery.

On server shutdown or reload, the DHCP server examines the queue of leases which it has queued up for each active leasequery connection. If the queue is empty, it means that all the notifications for that connection have been sent, at least into the TCP connection and are not waiting on the DHCP server. So, if the queue is empty and the TCP connection is not blocked, the DHCP server will send a DHCPLEASEQUERYSTATUS message with a status-code of QueryTerminated. This DHCPLEASEQUERYSTATUS message includes a base-time of the server's shutdown time. The client, when it reconnects to the server, should then issue an active leasequery request with a query-start-time of this base-time.

If these conditions are not met, the connection is closed by the DHCP server as before (no DHCPLEASEQUERYSTATUS message is sent). In this case, the client should use a query-start-time in the active leasequery request when it reconnects of the last base-time it received from the server minus 10 seconds.

On server startup, the server initiates saving the leases that it may need to send to active leasequery connections even if there are no active leasequery connections. It will save these leases for the backlog time (120 seconds by default).

And, if an active leasequery request is received within this backlog time with a query-start-time that is within a few seconds of the server's saved shutdown time, the server will assume that the active leasequery client is resuming a previous active leasequery and will initiate the active leasequery operation and no bulk leasequery is needed. If these conditions are not met, the DHCP server will notify the client that it has potentially missed notifications and needs to perform a bulk leasequery.

The sample Dynamic Lease Notification Client has also been modified to make use of the DHCP server enhancement. In particular, it saves the base-time received in a DHCPLEASEQUERYSTATUS message with the status-code of QueryTerminated and will use this base-time as the query-start-time when it successfully reconnects to the DHCP server. And, if that reconnect happens within the backlog time after the DHCP server has restarted, no bulk leasequery will be necessary.

Using Extensions to Control Active Leasequery Notifications

The server determines whether a lease is queued for active leasequery notifications based on the dhcp-listener's leasequery-send-all attribute. If enabled, the DHCP server always sends a notification to an active leasequery client; if disabled (or unset), the DHCP server only sends notifications which are necessary to maintain accurate state in the active leasequery client.

To allow customer written extensions to control the sending of a lease (such as only on specific state changes), a new data item, active-leasequery-control, has been added to both the request and response dictionaries. These data items have three values:

0—unspecified (the server determines whether to send the notification)

1—send (the server will send the notification)

2—don't send (the server will not send the notification)

The active-leasequery-control data item is initialized as 0, unspecified.


Note These data items may be written and read, but the value that is read is only the value that might have been previously written. These data items can force the DHCP server to take specific actions after being written, but reading them without previously writing them will always return 0, unspecified. These data items will not let you determine the choices that the DHCP server will make when it comes to deciding whether or not to send a message to an active leasequery client concerning the changes (if any) made to a lease that is being processed. Thus, these data items are technically read/write, but reading them will only allow you to determine what you may have previously written into them.


These data items are examined (the response dictionary is examined first, then the request) when the lease is written to the internal lease state database as that is when the lease is also queued for active leasequery notification. This occurs after the check-lease-acceptable and lease-state-change extensions points, but prior to the pre-packet-encode extension point. Therefore, any changes made to these attributes at or after the pre-packet-encode extension point will be ignored.

Whether a lease is queued for active leasequery notification is determined as follows:

Response's active-leasequery-control
Request's active-leasequery-control
Leasequery-send-all
Action

0—unspecified

0—unspecified

False or unset

Conditional (see leasequery-send-all attribute description)

0—unspecified

0—unspecified

True

Sent

0—unspecified

1— send

Ignored

Sent

0—unspecified

2—don't send

Ignored

Not Sent

1— send

Ignored

Ignored

Sent

2—don't send

Ignored

Ignored

Not Sent


Note that the response's and request's active-leasequery-control is examined prior to any examination of the leasequery-send-all attribute. Thus, if either of these dictionary data items has a value other than unspecified, that value will override any value configured in the leasequery-send-all attribute of the dhcp listener.


Note You cannot control the sending of active leasequery information by writing a single extension that runs only at the lease-state-change extension point, because that extension point is only called when there is a change in state of a lease. Lease state changes may not occur when you might expect them to. For example, if a lease is leased, and that same client goes through a DISCOVER/OFFER/REQUEST/ACK cycle, the lease-state-change extension point is not called since the lease does not actually go through a state change internally; it remains leased throughout the cycle. Thus, to gain absolute control over the transmission of information to active leasequery clients, you will probably need to initialize the active-leasequery-control attribute in request processing, and then possibly alter it or override it by operating on the response dictionary value at the lease-state-change extension point.


New Features in CNR 7.1.2.1

There are no new features added for this release. For details about the list of resolved and known bugs of this release, see Caveats.

Limitations and Restrictions

This section describes limitations and restrictions you might encounter when using CNR 7.1.2.1.

The Regional Pull Replica Address Space fails when reservations are being pulled for new failover-pair objects. This problem occurs only if there is a new failover-pair and one or more reservations associated with that failover-pair. To workaround this issue, repeat the operation twice—first checking Omit Reservations and then without checking Omit Reservations. After the failover-pairs have been pulled, subsequent pull replica address space operations will work correctly.

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

You must:

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

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

Caveats

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

Documentation Errata

In the README.txt for Cisco Network Registrar 7.1.2.1, read the occurrences of the version CNR 7.1.2 as CNR 7.1.2.1.

In the documentation set provided within the CD for Cisco Network Registrar 7.1.2.1, read the title "Release Notes for Cisco Network Registrar 7.1.2" as "Release Notes for Cisco Network Registrar 7.1.2.1", and read all the occurrences of CNR 7.1.2 within the document as CNR 7.1.2.1.

See Cisco.com for the most up-to-date version of the Release Notes for Cisco Network Registrar 7.1.2.1.

Related Documentation

See the following documents for important information about installing, configuring, and managing CNR:

Table 2 Related Documentation

Document Title
Available Formats

Documentation Guide for Cisco Network Registrar 7.1

PDF on the product CD-ROM

On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/roadmap/guide/CNR71DocGuide.html

User Guide for Cisco Network Registrar 7.1

PDF on the product CD-ROM

On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/user/guide/cnr71book.html

Installation Guide for Cisco Network Registrar 7.1

PDF on the product CD-ROM

On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/installation/guide/CNR71Install.html

Quick Start Guide for Cisco Network Registrar 7.1

PDF on the product CD-ROM

On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/user/guide/cnr71_qs_book.html

CLI Reference Guide for Cisco Network Registrar 7.1

As an HTML document that you can view in your web browser when you install the software. The document is available at All Programs > Network Registrar >  Network Registrar CLI Reference Guide.

On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/command/reference/CLIReferenceGuide.pdf

Release Notes for Cisco Network Registrar 7.1.2.1 (This document)

It is available on Cisco.com:
http://www.cisco.com/en/US/products/sw/netmgtsw/ps1982/prod_release_notes_list.html

Online Help

Choose Help > Help Contents in the main menu to view the entire help contents


Notices

The following notices pertain to this software license.

OpenSSL/Open SSL Project

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

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

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

License Issues

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

OpenSSL License:

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

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

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

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

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

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

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

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

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

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

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

Original SSLeay License:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Obtaining Documentation and Submitting a Service Request

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

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