Guest

Cisco Network Registrar

Release Notes for Cisco Network Registrar 6.3.2

Release Notes for Cisco Network Registrar 6.3.2

Table Of Contents

Release Notes for Cisco Network Registrar 6.3.2

Contents

Introduction

Before You Begin

License Keys

System Requirements

Network Registrar Communications Security Option

Software and Standards Compatibility

Interoperability

Installation and Upgrade Notes

General Installation

Red Hat Linux Installation

Upgrade Considerations

Moving Network Registrar to a New Machine

SDK Installation

Installing on Linux or Solaris

Installing on Windows

Testing Your Installation

Features Added in Network Registrar for 6.2 through 6.3.1

IPv6 Support

DHCPv6 Support

DNSv6 Support

DHCP Enhancements

DNS Enhancements

Network Interface Management

Address Space Reports

SNMP Support and Management

Router Management at the Local Cluster

Enhanced Administrator Role Management

Local and Regional Cluster Administration

New and Revised Web UI Pages

CLI Enhancements and Changes

Log File and Change Log Enhancements

Cluster Backup and Restore

HA DNS Configuration on a GSS appliance

Exception Forwarding Attribute

CCM Database Index Repair

DNS Resolution Queue Management

DNS Scavenging Process

Chatty Client Filter

Lease History Database Compression Utility

General Comments on Running cnr_leasehist_compress

Running Compression on Solaris and Linux

Running Compression on Windows

Failover Pair Rename

Resource Records Generation on BIND Imports

Multiple Interface Users

TFTP Block Sizes

Subnets Push to Cisco uBR10000 Routers

Other Features

Features Added in Network Registrar 6.3.2

DNS Vulnerability Issue

Dynamic Allocation of UDP Ports

Caveats

Documentation Errata

System Requirements

Configuration File (cnr.conf) Changes

Vendor Option 43

Creating Expressions

Reverse Zones

Linux Silent Installation

Lease Import Function

Lightweight Directory Access Protocol

DHCP Failover Configuration

DHCP Reply Options

HA DNS Server Pair

DHCP Failover Server Restoration to Backup State

Related Documentation

Notices

OpenSSL/Open SSL Project

License Issues

Obtaining Documentation and Submitting a Service Request


Release Notes for Cisco Network Registrar 6.3.2


February 13, 2009

These release notes are for Cisco Network Registrar Release 6.3.2. This document describes system requirements, installation and upgrade notes, new features added for 6.2 through 6.3.2 release, and caveats. If you are upgrading from a version earlier than 6.2, review the release notes related to that specific release as well.

Contents

These release notes cover the following topics:

Introduction

Before You Begin

Software and Standards Compatibility

Interoperability

Installation and Upgrade Notes

Features Added in Network Registrar for 6.2 through 6.3.1

Features Added in Network Registrar 6.3.2

Caveats

Documentation Errata

Related Documentation

Notices

Obtaining Documentation and Submitting a Service Request

Introduction

This release of Cisco Network Registrar provides enhanced Domain Name System (DNS) server performance in resolving a DNS vulnerability issue and improves DNS server functionality in handling User Datagram Protocol (UDP) ports for the resolution queries.

Before You Begin

Review the following sections before installing Network Registrar 6.3.2.

License Keys

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

To determine if you need a new license key:

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

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

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

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


Note Do not install or upgrade to Network Registrar 6.0 or later releases without first obtaining a new license key specific to that version. You cannot use license keys from earlier Network Registrar versions
(3.5, 5.0, and 5.5) to access the configuration of a Network Registrar 6.0 or later server. Customer entitlement rights to obtain a license key for a Network Registrar 6.0 or later SASU (Software and Services with Upgrade) support contract that is active for the earlier version of Network Registrar, or an upgrade license for Network Registrar 6.0 or later releases.


Questions regarding access to Network Registrar 6.0 or later can be sent to cnr-licensing@cisco.com.

System Requirements

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

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

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

User interfaces—Network Registrar currently includes two user interfaces: a web UI and CLI:

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

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


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


Table 1 Network Registrar System Recommendations 

Operating System
Solaris
Linux
Windows
Component
     

OS version 1

Solaris 9 or Solaris 10 2

Red Hat Enterprise Linux ES 4.0 only

Windows Server 2003

Disk space 3

2 x 73/146 SAS 4 drives

With basic DHCP and optimal hardware configuration:

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

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

(Recommended hard drive 146 GB)

Memory 6

16 GB

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

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

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

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

4 Serial Attached SCSI.

5 Serial Advanced Technology Attachment (Serial ATA).

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


Network Registrar Communications Security Option

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

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

Software and Standards Compatibility

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

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

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

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

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

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

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

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

Interoperability

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

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

Table 2 Regional Cluster Features 

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

Central push and pull:

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

x
x
x
x

x
x
x
x
x

x
x
x
x
x

x
x
x
x
x

Administrator:

Single sign-on
Password change

x

x
x

x
x

x
x

IP history reporting:

Central lease history
Detail lease history

x

x
x

x
x

x
x

Utilization reporting:

Central subnet utilization history
Current subnet and scope utilization

x

x
x

x
x

x
x


Installation and Upgrade Notes

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

This section covers the following topics:

General Installation

Red Hat Linux Installation

Upgrade Considerations

Moving Network Registrar to a New Machine

SDK Installation

General Installation

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

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

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

Windows—Windows-based InstallShield setup program

Solaris—The pkgadd command

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

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

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

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

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

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

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

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.

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

Red Hat Linux Installation

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

To verify if openldap is installed, enter:

# rpm -ql openldap | more

If the openldap package is installed, you can see the information about the location where it is installed; otherwise, you will see a message similar to:
package openldap is not installed.

To install the openldap package, enter:

# yum install compat-openldap.i386

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

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

The linux download kit supports RH 7.3 and RH 2.1.

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

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

The linux3 download kit supports RH ES 3.0.

The linux4 download kit supports RH ES 4.0.

Release 6.3.x supports RH ES 4.0 only.

Upgrade Considerations

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

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

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

Before you upgrade to Network Registrar 6.3.2:


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

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

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

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

Windowsnet stop nwreglocal

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

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

Step 6 Upgrade your operating system, if necessary.

Step 7 Upgrade Network Registrar. Note that:

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

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


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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

Windows—net stop nwreglocal

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

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

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

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

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

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


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


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

h. Start the Network Registrar server agent:

Windows—net start nwreglocal

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

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


See also the "CCM Database Index Repair" section.

Moving Network Registrar to a New Machine

You might want to move an existing Network Registrar installation to a new machine. The following procedure preserves your original data on the old machine should a problem arise during the installation on the new machine (CSCso06297):


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

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

Windowsnet stop nwreglocal

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

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

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

Step 5 Install Network Registrar on the new machine (on Solaris and Linux, use the -a option). The installation will detect an upgrade and will do so based on the copied data.

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


SDK Installation

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

Installing on Linux or Solaris

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

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

a. Create the SDK directory:

% mkdir /cnr-sdk 

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

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

2. Export your LD_LIBRARY_PATH and CLASSPATH environment variable:

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

Installing on Windows

To install the Network Registrar SDK on a Windows platform:

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

a. Create the SDK directory:

> mkdir c:\cnr-sdk

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

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

The install-path is the path in which you install Network Registrar. You may optionally use Winzip to extract the cnrsdk.tar to the C:\cnr-sdk directory.

2. Set your PATH and CLASSPATH variables:

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

You can set up these values each time when you start an SDK session. Or, to set the system-wide variables, choose Start > Settings > Control Panel, double-click the System icon, click the Advanced tab, click Environment Variables, and enter the values in the System Variables pane.

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

Features Added in Network Registrar for 6.2 through 6.3.1

This section covers the following new features added in Network Registrar for 6.2 through 6.3.1:

IPv6 Support

DHCP Enhancements

DNS Enhancements

Network Interface Management

Address Space Reports

SNMP Support and Management

Router Management at the Local Cluster

Enhanced Administrator Role Management

Local and Regional Cluster Administration

New and Revised Web UI Pages

CLI Enhancements and Changes

Log File and Change Log Enhancements

Cluster Backup and Restore

HA DNS Configuration on a GSS appliance

Exception Forwarding Attribute

CCM Database Index Repair

DNS Resolution Queue Management

DNS Scavenging Process

Chatty Client Filter

Lease History Database Compression Utility

Failover Pair Rename

Resource Records Generation on BIND Imports

Multiple Interface Users

TFTP Block Sizes

Subnets Push to Cisco uBR10000 Routers

Other Features

IPv6 Support

Network Registrar 6.2 supports IPv6 servers and addressing for DHCP and DNS. This feature requires a separate ipv6 license key.

DHCPv6 Support

DHCPv6 provides basic address assignment, prefix delegation, and stateless autoconfiguration by using IPv6 addressing. Network Registrar supports DHCPv6 for clients, client-classes, static reservations, policies, and options; and supports prefixes and links. Network Registrar 6.2 adds the DHCPv6 service to the existing DHCP server, not a separate server, to better leverage the DHCP functionality and infrastructure where possible.

DHCPv6 support requires a separate software license. For Windows, the minimum release to support DHCPv6 is Windows XP with SP2. The DHCPv6 service requires that the server operating system supports IPv6 and that at least one interface on the system be configured for IPv6. You also require an IPv6 network infrastructure with DHCPv6 clients (and DHCPv6 relay agents) for successful operation.

Obtain the Web UI functionality from new Prefixes and Links subtabs below the DHCP tab. The new commands in the CLI are dhcp-prefix, dhcp-link, and lease6.

DHCPv6 and DHCPv4 have many fundamental differences. In DHCPv6:

Clients can be given and request multiple addresses, not just one.

IPv6 addresses have lifetimes (preferred and valid).

Option codes and lengths are 16 bits, not 8 bits. (Only about 30 DHCPv6 options are currently available; see also the "DHCP Enhancements" section for the new option definitions feature.)

Clients have a DHCP Unique Identifier (DUID), replacing the hardware address and client identifier.

Servers have a DUID, replacing the IP address-based identifier.

Messages primarily comprise options with very small headers (no BOOTP legacy).

Network Registrar uses multicasting, not broadcasting. Clients always multicast all messages to a link-local address (to a relay agent or server), unless a server explicitly allows unicast communication and the client has an appropriate address. Clients always communicate through relay agents (if present).

Clients always have at least a link-local address, thereby simplifying client/server or client/relay agent communication.

Network Registrar supports the following DHCPv6 features:

Stateless autoconfiguration (sometimes called DHCPv6lite per RFC 3736)—The DHCPv6 server does not assign addresses, but provides configuration parameters (such as DNS server information) to these clients.

Stateful configuration (full DHCPv6 per RFC 3315)—The DHCPv6 server assigns (permanent or temporary) addresses and provides configuration parameters to clients.

Links and prefixes—Similar to DHCPv4 networks and scopes. Links and prefixes define the network topology. Each link can have one or more prefixes:

Prefixes are equivalent to DHCPv4 scopes.

Links allow multiple prefixes to be associated with each other, and adds another layer at which to specify policies for DHCPv6 clients. A prefix's link attribute is similar to a scope's primary-scope; except that the link attribute names a link and not another prefix.

Prefix delegation (per RFC 3633)—The DHCPv6 server delegates prefixes to clients (routers).

Client-classes—Clients can be classified and prefixes selected based on known clients or packet-based expressions.

Policies and options—Attributes and options can be assigned to links, prefixes, and clients.

Static reservations—Clients can receive predetermined addresses.

Lease affinity—Allows the server to give the same address to a client even if that client does not renew before the valid lifetime expires.

Virtual private networks (VPNs).

Statistics collection and logging—Monitors server activities.

DNSv6 Support

Network Registrar 6.2 provides a DNS server that supports IPv6, including direct queries and updates by IPv6 clients. This support impacts server and zone configuration attributes, such as for ACLs and update policies, that use IP addresses to control server behavior. DNSv6 support includes:

Full support of AAAA and PTR RRs for IPv6 addresses, and the ip6.arpa reverse zone (RFC 3152).

First-hop query support for clients over IPv6 (UDP and TCP). This support allows IPv6-only clients to use the DNS server to resolve DNS queries.

Update policy and ACL support for IPv6 addresses.

DHCP Enhancements

Network Registrar 6.2 includes the following enhancements to DHCP implementation (other than DHCPv6):

Dynamic scope management—The DHCP server provides two scope edit modes: synchronous and staged. In synchronous mode, the server immediately engages administrator actions to create and edit scopes without a server reload. Staged edits require a server reload. You can use synchronous mode for most editable scope attributes (except scope name, subnet number, subnet mask, primary subnet number, primary subnet mask, and VPN), the scope embedded policy, and the scope address range. The scope edit modes can be set for each session. The default is staged mode.

Failover pair management—Failover pairs are now distinct objects that are separate from the DHCP servers. This feature is available at the regional and local clusters in the Web UI and CLI. The CLI command is failover-pair.


Note Treatment of the failover pair as a separate object might require new operational procedures (especially if using anything but simple failover). For example, failover pair configuration now includes a Network Match List that might need updating for adding new scopes.


Failover load balancing (RFC 3074)—Distributes the client population more equally across multiple DHCP servers. The failover pair attribute load-balancing can be enabled or disabled. The default is disabled.

DNS update configurations—You can determine update of the DNS server, based on DHCP activities (RFC 2136), by update configurations, which are separate objects from the DHCP server. You can apply updates to all zones or to forward or reverse zones only. The local Web UI includes a DNS subtab below the DHCP tab for this purpose; the CLI provides the dhcp-dns-update command. Update configurations can be applied to zones and policies (named and scope-embedded), as specified in the DNS Update Settings attributes for each object.


Note DNS update configurations might require new operational procedures when adding new zones and scopes.


Option definitions and option definition sets—You can create custom and vendor-specific options much more easily than in previous releases, for DHCPv4 and DHCPv6. These option definitions can be included in option definition sets, which you can define by vendor option string or enterprise ID for vendor options. The Web UI provides an Options subtab below the DHCP tab for this purpose; the CLI provides the option and option-set commands. At the regional cluster, option definition sets can be pulled from the replica local cluster data and pushed to local clusters.

Support of the RADIUS suboption of the relay-agent option—The DHCP server adds the RADIUS suboptions of the relay-agent option to its lease data. The CCM regional server now forwards requests to the appropriate local cluster based on its mapping of subnets to DHCP servers.

Activity summary reporting improvements—The DHCP server includes activity summary statistics in addition to total statistics, collected over a specified time interval (determined by the activity-summary-interval DHCP server attribute, which defaults to 5 minutes). You enable summary reporting by enabling the DHCP server collect-sample-counters attribute or setting the activity-summary log-setting.

Reservations can now be for non-MAC addresses—On a scope basis, you can create reserved leases for an IP address as defined by a client lookup key that is a MAC address, string, or binary value. For policies, you can enable the use-client-id-for-reservations attribute.

Override the client-id as the client identifier—You can use expression (in the client-class's override-client-id attribute) to override the client-id value in the incoming packet.

Allow multiple lookups in the client-entry database.

Allow extensions and expressions to place a value in the environment dictionary Network Registrar automatically stores with the lease in the lease state database.

DNS Enhancements

Network Registrar 6.2 includes the following enhancements to DNS (other than the DNSv6 and HA DNS features described elsewhere):

DNS update policies—Update of the DNS server based on DHCP activities (RFC 2136) was enhanced by introducing policies for that purpose for the DNS server. Access control lists (ACLs), which define who can apply an update to a zone, currently control DNS updates, provided that the zone is dynamic. ACLs can restrict updates based on IP address, network address, or TSIG keys. Update policies provide the capability to specify who can update which resource records (RRs). The Web UI provides configuration pages under the Update Policies tab for DNS; the CLI provides the update-policy command. You can use DNS update policies in place of ACLs when you need this level of security. The DNS server recognizes only a single security setting on the zone. If you configure an ACL and update policy, the server ignores the update policy.

DNS update maps—DNS update maps define simple update relationships between DHCP servers (or failover pairs) and DNS servers (or HA DNS server pairs). The Web UI includes an Update Maps subtab under the DNS tab for this purpose; the CLI provides the dns-update-map command.

Name set protection—RR name sets can be set to protected or unprotected in the Web UI and CLI. Two views are also available in the Web UI, one for CCM protected RRs and another for DNS server (all) RRs. The CLI has separate listings for CCM RRs and DNS RRs, and you can protect or unprotect the RRs by using the zone name protect-name rr or zone name unprotect-name rr commands, where name is the name of the zone and rr is the RR name.

Dynamic zone management—The DNS server provides two zone edit modes: synchronous and staged. In synchronous mode, Network Registrar immediately engages administrator actions to create and edit zones without a server reload. Staged edits still require a server reload. The zone edit modes can be set for each session. By default, zone edit mode is synchronous for the local cluster and staged for the regional cluster.

Zone distributions—Synchronize staged primary zones with the DNS server, in addition to creating secondary zones for the list of configured secondary servers.

Enhanced zone management:

Facilitated subzone and reverse zone creation and maintenance.

Classless reverse zones.

Enhanced consistency rules. (Note that the Consistency Rules subtab now appears under the Home tab in the Web UI.)

Zone management is possible at the regional cluster.

Zones can be synchronized at the local and regional clusters.

Network Interface Management

Using the Web UI in Network Registrar 6.2, you can add and manage network interfaces.

Address Space Reports

Network Registrar 6.2 includes the ability to generate address space reports for address use accountability:

American Registry of Internet Numbers (ARIN) reports, including:

Organization and point of contact (POC) reports

IPv4 address space utilization reports

Shared WHOIS project (SWIP) allocation and assignment reports

Allocation reports that show how addresses are deployed across routers and router interfaces of the network, including allocation by:

Owner reports

Router interface or network reports

Network Registrar 6.2 adds reporting functions to summarize data required for selected SWIP and ARIN reports to the regional cluster and, in some cases, to the local cluster. Address space utilization data and associated data stored in the CCM server populated report fields for display in the Web UI or exported to an ASCII text file. To send a report to ARIN, you must manually send the text report via email; no process is available to generate and send a report automatically. Reports are limited to IPv4 data only.

SNMP Support and Management

Network Registrar 6.2 provides local cluster support for the DHCP and DNS protocol servers, and introduces new Cisco-specific Management Information Bases (MIBs) for each server. The DHCP MIB is based on the IETF draft DHCP MIB, but is tailored specifically to Network Registrar.

SNMP support for each server provides access to server statistics and configuration, and issues SNMPv2 notifications for important events. The server-specific MIBs define the list of supported events.

The SNMP server was added to the local cluster to provide these features. The SNMP server configuration defines the interfaces used when listening for SNMP requests or sending traps, and maintains the list of trap recipients. You can define the traps that each server supports configuration. The new functions emit server events for each defined SNMPv2 notification. The DNS server also supports stop and start traps by using the new mechanism and any newly defined DNS notifications.

New SNMP features include:

SNMP server and trap configuration.

New Trap Recipient pages in the Web UI and the trap-recipient command in the CLI.

New Address Trap page in the Web UI and addr-trap command in the CLI.

Router Management at the Local Cluster

The ability to add and manage routers was added to the local cluster. In the Web UI, a new Clusters tab was added; in the CLI, a new router command. The router configuration requires the IP address, router type, and connection credentials (username, password, and enable password) to an actual router. Omitting the router type or connection credentials creates a virtual router, for which you can create network interfaces. You can add a subnet and then push it to one of the subinterfaces on the router.

Router management requires a separate router license key that you add during the configuration.

Enhanced Administrator Role Management

Network Registrar 6.2 added new local and regional administrator roles, and changed existing ones for local and regional cluster parity:

New local configuration administrator role (cfg-admin), including local cluster management.

New central-host-admin and central-dns-admin roles.

Migration of DNS management from the zone-admin to the dns-admin role. Note that the host-admin role remains available to assign certain users very limited access to zone data. You cannot combine the host-admin role with the dns-admin role, and Network Registrar ignores it if configured.

New constraints added to roles:

CCM administration in the central-cfg-admin role

Access to particular zones and hosts in the dns-admin and central-dns-admin roles

IPv6 management in the local dhcp-admin role

More granular authorization through contextual read-write and read-only permissions, and all administrators being constrainable.

The CCM server's internal mechanisms for specifying authorization allows read-write and read-only granularity in a role and to specify granular authorization by object class for generic functions currently requiring superuser access. Read-write constraints override read-only constraints for roles. This is the reverse behavior of the previous release.

Local and Regional Cluster Administration

Network Registrar 6.2 provides cluster management at the local and regional clusters. This enhancement necessitated some rearrangement of the menu hierarchy in the Web UI for consistency and ease of navigation.

New and Revised Web UI Pages

Network Registrar 6.2 provides new and revised Web UI pages to add functionality and provide parity with existing CLI commands:

Under the Home tab, the:

Main Menu page was enhanced to allow setting the staged and synchronous modes for scope and zone edits in the Session Settings.

Consistency Rules subtab was added.

Network Registrar consolidated the CCM and MCD change logs under the Administration tab into one View Change Log page.

You can access the Manage Servers page from a Servers tab.

The Clusters and Routers functions are also available from the local Web UI.

The View Replica Class List page now includes many more objects.

Under the DHCP tab, Network Registrar added or updated the following pages:

Prefixes and Links to configure DHCPv6 in the local Web UI.

Options to configure option sets and definitions in the local Web UI.

Failover function to configure DHCP failover pairs.

DNS function for setting DNS update configurations.

LDAP function to configure remote LDAP servers.

Extensions function to configure DHCP extensions.

Traps function to configure SNMP traps in DHCP in the local Web UI.

DHCP Server function that opens a Manage DHCP Servers page from which to view the new startup change logs and access a command to set limitation criteria.

Under the DNS tab (that replaces the Zone tab), Network Registrar added or updated the following pages:

Update Policies to configure DNS update policies.

ACLs function to configure ACLs.

Keys function to configure encryption keys.

HA Pairs function to configure HA DNS server pairs.

Update Maps function to configure DNS update maps.

DNS Server function that opens a Manage DNS Server page from which to view the new startup change logs; and access commands to flush DNS cache, force zone transfers, trigger scavenging, and remove nonauthoritative RRs.

Under the Hosts tab, host configuration includes an alias setup field.

Under the Address Space tab, the functions are Address Space, Address Blocks, Subnets, and Address Types. The regional Web UI also includes the Subnet Utilization and Lease History functions.

The new Reports tab in the regional Web UI includes the Address Space, Contacts, and Organizations report functions.

CLI Enhancements and Changes

The CLI comes in local and regional cluster versions. The commands in Table 3 are new or modified in Network Registrar 6.2, in some cases to provide parity with the equivalent Web UI functions.

Table 3 CLI Commands Added in Network Registrar 6.2 

Command
Description

addr-trap

Manages SNMP traps (see the "SNMP Support and Management" section).

ccm

Manages the CCM server.

cluster

Manages clusters.

dhcp-address-block
dhcp-address-block-policy
dhcp-subnet

Manages subnet allocation and on-demand address pools (ODAP). The previous address-block, address-block-policy, and subnet commands apply to CCM objects.

dhcp-interface
dns-interface
snmp-interface

Manages DHCP, DNS, and SNMP interfaces (see the "Network Interface Management" section).

dhcp-prefix
dhcp-link
lease6

Manages DHCPv6 prefixes, links, and leases (see the (see the "DHCPv6 Support" section).

dns-update-map

Manages DNS update maps (see the "DNS Enhancements" section).

dns-update-policy

Manages DNS update policies (see the "DNS Enhancements" section).

export key (keys)
export option-set

Exports TSIG keys and DNS option sets.

failover-pair

Manages DHCP failover server pairs (see the "DHCP Enhancements" section). (Note that the failover-pair name sync command synchronizes in the direction main server to backup server only.)

group
role
owner
region

Manages groups, roles, owners, and regions.

ha-dns-pair

Manages HA DNS server pairs (see the "DHCP Enhancements" section)

import keys
import option-set

Imports TSIG keys and DNS option sets.

option
option-set
option-datatype

Manages DHCP option and option set definitions along with their data types.

policy name create
clone=
name

Allows cloning of DHCP policies. (You can also clone scope and zone templates.)

router
router-interface
router-type

Manages the Router Interface Configuration (RIC) server, interfaces, and router types.

scope-template
scope 
name applyTemplate

Manages scope templates (previously available only in the Web UI).

session set scope-edit-mode
session set zone-edit mode

Sets the scope and zone edit modes (staged or synchronous).

snmp

Manages the SNMP server.

trap-recipient

Sets SNMP trap recipients.

zone-dist

Manages zone distributions (see the "DNS Enhancements" section).

zone-template
zone 
name applyTemplate

Manages zone templates (previously available only in the Web UI).



Tip When a CLI create operation (such as scope name create arguments) fails, the CLI might not have removed this object from its internal cache when responding to a prior delete command and, thus, a subsequent create operation (with corrected arguments, for example) might return a 314 Duplicate object error. To resolve this problem: use a save command (which saves any pending changes and flushes the CLI's internal cache) then reissue the create operation.


Log File and Change Log Enhancements

Log files in Network Registrar 6.2 include a new startup log, consolidated change logs and added search functions in the Web UI.

Cluster Backup and Restore

Network Registrar 6.2 includes a centralized backup and restore of cluster data in the Web UI with relevant functions. The CCM regional replica database was enhanced to store a complete representation of each local cluster's configuration. If a catastrophic hardware failure of a given server occurs, the CCM server can rebuild the previous configuration once you bring new hardware online. In this way, you can restore the previously installed local cluster version. Network Registrar does not support migration to a different version cluster.

HA DNS Configuration on a GSS appliance

To successfully configure High Availability (HA) DNS on a GSS appliance, use the Network Registrar CLI to create a new dns-interface object, and use the public IP address and netmask of the appliance. For more information, see the "Configuring HA DNS on a GSS appliance" section of the Release Notes for Cisco Network Registrar 6.2.3.

Exception Forwarding Attribute

Network Registrar 6.3 provides greater control over whether DNS forwards a query to a resolution exception server or uses cached name server records. DNS servers now have a BIND-like function with an exception-forwarding attribute that you can set using either the web UI or the CLI.

To set the attribute using the web UI, go to the Edit DNS Server page. You can set the exception-forwarding attribute using a drop-down list. To set the attribute using the CLI, use the dns show command to see its current value and the dns set attribute=value command to change the value.

Possible values for the exception-forwarding attribute are:

forward-always—DNS always forwards queries to a configured exception server.

forward-first—DNS first forwards queries to a configured exception server, and, if it does not receive an answer before the request expires, it forwards to name servers (if any).

forward-last— DNS first forwards queries to cached name servers (if any), and, if it doesn't get an answer before request expires, it forwards the query to a configured exception server.

CCM Database Index Repair

In rare circumstances, CCM database index definitions might be lost for a given class of objects. You might notice this issue when the object list appears empty, but you know the configuration to exist. The Network Registrar 6.3.1 release resolves this issue so that the upgrade repairs the database.

A standalone utility, rebuild_indexes, is also available to repair the database if you cannot resolve this issue through an upgrade (CSCsm89823).


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

The syntax for the rebuild_indexes utility is:

rebuild_indexes options 

where options are:

-d path—Path to the existing CCM database.

-c—Checkpoints the database before exiting.

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

The rebuild_indexes utility checks and updates:

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

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

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

DNS Resolution Queue Management

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

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

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

DNS Scavenging Process

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

Chatty Client Filter

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

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

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

Clients in this network send a large number of packets.

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

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

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


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


nrcmd> dhcp attachextension post-packet-decode dexChattyClientFilter 

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


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


Table 4 describes the options available with the Chatty Client Filter.

Table 4 Arguments for the Chatty Client Filter 

Argument
Description
Default

-d packets seconds

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

Disabled

-h packet-count

SampleHitsToDisable.

15 packets

-i seconds

SampleTimeInterval.

30 seconds

-l packet-count

QuietHitsToLeaveDisabled.

5 packets

-q seconds

QuietTimeInterval.

10 seconds

-s

Silently discards dropped packets.

Disabled

-n

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

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

Disabled

-r seconds

Controls the statistics reporting interval.

300 seconds (5 minutes)


Lease History Database Compression Utility

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


Caution Use the cnr_leasehist_compress utility only with the regional cluster lease history database, and when you suspect that the database grew significantly, particularly because of DHCPRELEASE packets (see also the "Chatty Client Filter" section).

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

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

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

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

Before you run the cnr_leasehist_compress utility:

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

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

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

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

General Comments on Running cnr_leasehist_compress


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

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

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

Running Compression on Solaris and Linux

To run the cnr_leasehist_compress utility on Solaris and Linux:


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

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

Step 2 Stop the Network Registrar regional cluster:

# /etc/init.d/nwregregion stop 

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

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

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

# mkdir install-path/data/leasehist 

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

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


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

Step 6 Restart the Network Registrar regional cluster.

# /etc/init.d/nwregregion start 

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

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

# mkdir install-path/data/newleasehist 


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


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

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

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

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


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


a. Stop the Network Registrar regional cluster:

# /etc/init.d/nwregregion stop

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

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


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

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

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

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

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

Step 10 Start the Network Registrar regional cluster:

# /etc/init.d/nwregregion start 

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

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

Step 13 Delete the original database and temporary active database:

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


Running Compression on Windows

To run the cnr_leasehist_compress utility on Windows:


Step 1 Stop the Network Registrar regional cluster:

> net stop nwregregion 

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

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


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


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

> mkdir install-path\data\leasehist 

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

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


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

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

> net start nwregregion 

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

> mkdir install-path\data\newleasehist 


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


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

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

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

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


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


a. Stop the Network Registrar regional cluster:

> net stop nwregregion 

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

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


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

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

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

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

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

Step 9 Start the Network Registrar regional cluster:

> net start nwregregion 

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

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

Step 12 Delete the original database and temporary active database:

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


Table 5 describes the qualifying options for the cnr_leasehist_compress utility.

Table 5 cnr_leasehist_compress Options 

Option
Description

-a

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

-c

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

-d

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

-e attrlist

Overwrites the excluded merge attribute list.

-f file

Redirects most lease history record warnings to a log file.

-g

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

-i ipaddr

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

-l limit

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

-m time-int

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

-n

Compares adjacent records without merging them.

-p

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

-q records

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

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

-r records

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

-s path

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

-t age

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

-v

Emits the version and exits.

-w

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

-y

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

-z {letters}=level

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


Failover Pair Rename

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

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

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

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

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

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

In releases 6.3.1 and later, the server detects name and address changes in a single failover based on an algorithm. If however, you change the role of the servers from backup to main or vice-versa, the server invalidates the old failover state.


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

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


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

nrcmd> dhcp disable start-on-reboot 

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

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

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

nrcmd> dhcp enable start-on-reboot 

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


Resource Records Generation on BIND Imports

Support for the $GENERATE directive was added in Network Registrar 6.3.1 so that you can generate resource records when importing data from a BIND file.

Multiple Interface Users

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

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

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

TFTP Block Sizes

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


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

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

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

Subnets Push to Cisco uBR10000 Routers

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

Other Features

Major changes made in Network Registrar 6.2.1 include:

Red Hat 7.3 and RH ES 2.1 support was removed.

The mcdshadow tool does a fatal recovery and verification during a successful backup (CSCsd87059).

The List Reservations, Add Reservation, and Edit Reservation pages are new to the Web UI (CSCsd82168). The regional cluster also provides for pushing reservations to local clusters (CSCsd82176).

The reservation command was added to the CLI (CSCsd93395), with the following subcommands:

reservation [vpn-id/]ipaddress create {macaddress | lookup-key} [-mac | -blob | -string] attribute=value

reservation [vpn-id/]ipaddress delete

reservation [vpn-id/]ipaddress get attribute

reservation [vpn-id/]ipaddress show

reservation list [[vpn-id/]ipaddress | -mac | -key]

You can resynchronize between local reservations and scopes (CSCsd82177). You can also pull reservations from, and push them to, local clusters (CSCsd82176).

Administrators can add, edit, and delete hosts without requiring read-only access to DNS zones and resource records (CSCsd02165).

The dns getStats command displays statistics in read-only mode (CSCed33083).

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

The cnr-exim tool exports DHCP failover pairs.

Network Registrar deprecated the lease send-reservation and lease delete-reservation commands in the CLI in favor of synchronous scope edit mode (CSCsd67360).

Network Registrar now handles lease renewal 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. The server now applies a 60-second grace period to renewals (to accommodate clock drift), and does not change T1 if it does not extend the expiration.

The DHCPv6 server supports permanent leases (CSCsd42231).

Features Added in Network Registrar 6.3.2

DNS Vulnerability Issue

Network Registrar 6.3.1.5 resolves a DNS vulnerability issue (CSCsq01298) as addressed in a Cisco Product Security Incident Response Team (PSIRT) document number PSIRT-107064 with Advisory ID cisco-sa-20080708-dns, available at:

http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml

Network Registrar 6.3.2 enhances the DNS server performance in addressing the DNS vulnerability issue.

If you need technical assistance, see the Cisco Technical Assistance Center (TAC) website at:

http://www.cisco.com/tac

You can also contact the TAC by phone, using the number specific to your region listed at:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

Dynamic Allocation of UDP Ports

Network Registrar 6.3.2 enhances the capabilities of the DNS server to provide a dynamic pool of UDP ports that are configured during server initialization for resolution queries. The DNS server increases the default size of the pool of UDP ports to 2048 and increases the maximum allowable size to 4096 (CSCsu55330). Currently, Network Registrar uses the port range from 1024 to 65535. Based on the number of outstanding resolution queries, the DNS server adjusts the pool size by adding or removing ports. The DNS server allocates and releases the UDP ports dynamically when the server is running. If you reload the server, all the UDP ports are released and randomly picked again.


Note Before starting the DNS server, ensure that you start UDP-based applications. By starting these UDP applications ahead of DNS server, the applications can bind to their ports before the DNS server uses those ports for allocation. If you stop and restart any UDP-based application using any port ranging from 1024 to 65535 when the DNS server is operational, the application may not bind to those ports. In that case, you must stop the DNS server, start the UDP-based application, and restart the DNS server.


Caveats

You can find the complete list of resolved and known bugs (including customer-found ones) in the cnr_6_3_2-buglist.html file on the Cisco software download site at:

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

Documentation Errata

This section covers the following:

System Requirements

Configuration File (cnr.conf) Changes

Vendor Option 43

Creating Expressions

Reverse Zones

Linux Silent Installation

Lease Import Function

Lightweight Directory Access Protocol

DHCP Failover Configuration

DHCP Reply Options

HA DNS Server Pair

DHCP Failover Server Restoration to Backup State

System Requirements

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

Configuration File (cnr.conf) Changes

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


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

The following settings are supported:

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

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


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


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

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

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

Vendor Option 43

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

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


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

Cisco Aironet 1200 series

Cisco Aironet 1240 series


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

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


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

Step 2 Click Add Option Definition Set.

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

Attribute
Value

Name

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

DHCP Type

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

Vendor Option String

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


Step 4 Click Add Option Definition Set.

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

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

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

Attribute
Value

Number

Number of the option code. You must enter 43.

Name

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

Type

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


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

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

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

Attribute
Value

Number

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

Name

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

Type

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

Repeat

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


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

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

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

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

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

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

(241 3.3.3.3,4.4.4.4)

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

Step 17 Reload the DHCP server.


Creating Vendor Option Set and Vendor Option Values from the CLI

To configure option 43 from the CLI:


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

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

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


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

Cisco Aironet 1200 series

Cisco Aironet 1240 series


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

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

For example:

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

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

For example:

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

Step 4 Reload the DHCP server.


Creating Expressions

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

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

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

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

Function
Example

(try expr failure-expr)

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

Reverse Zones

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

An IPv4 subnet.

An IPv6 prefix.

The name of an IPv6 prefix.

Local Advanced and Regional Web UI

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


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

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

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

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

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

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

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

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

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


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


Step 1 Click DHCP v6, then Prefixes.

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

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

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

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

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


CLI Commands

To create a reverse zone by using:

An IPv4 subnet, enter, for example:

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

An IPv6 prefix, enter, for example:

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

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

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

Linux Silent Installation

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


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

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

install_cnr -r response-file

Table 6 Silent-Response File Entries for Linux 

Silent-Response File Entry
Description and Value

BACKUPDIR=

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

CCM_PORT=

CCM port; default value is:

1234 if CNR_CCM_MODE=local

1244 if CNR_CCM_MODE=regional

CNR_CCM_MODE=

CCM mode; set to local or regional.

CNR_EXISTS=

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

DATADIR=

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

JAVADIR=

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

JSSEDIR=

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

KEYSTORE_FILE=

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

KEYSTORE_PASSWORD=

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

LOGDIR=

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

PERFORM_BACKUP=

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

ROOTDIR=

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

START_SERVERS=

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

TEMPDIR=

Fully qualified path to the /temp directory.

USE_HTTP=

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

USE_HTTPS=

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

For USE_HTTPS, see also KEYSTORE_FILE= and KEYSTORE_PASSWORD=.

WEBUI_PORT=

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

8080 if CNR_CCM_MODE=local

8090 if CNR_CCM_MODE=regional

WEBUI_SEC_PORT=

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

8443 if CNR_CCM_MODE=local

8453 if CNR_CCM_MODE=regional


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

uninstall_cnr

Lease Import Function

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

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

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

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

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

Lightweight Directory Access Protocol

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

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

DHCP Failover Configuration

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

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

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

DHCP Reply Options

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

HA DNS Server Pair

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

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

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

nrcmd> dns reload


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


DHCP Failover Server Restoration to Backup State

Standalone DHCP failover recovery procedure is not sufficiently provided in the user documents (CSCsl45373). A technote is developed to better describe the failover recovery process. The procedures in the technote cover the special steps required to recreate a failover relationship where the backup server has the lease state data and is running in standalone mode. You can find this technote at:

http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/6.3.1/troubleshooting/guide/RestoringFailoverBackup.html

This document was published independent of any specific release of Network Registrar.

Related Documentation

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

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

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

For details about commands available through the CLI, see the Cisco Network Registrar CLI Reference 6.3.

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

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.

This document is to be used in conjunction with the documents listed in the "Related Documentation" section.