Guest

Cisco Network Registrar

Release Notes for Cisco Network Registrar 6.2.4

  • Viewing Options

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

Table Of Contents

Release Notes for Cisco Network Registrar

Contents

Introduction

Before You Begin

License Keys

System Requirements

DNS Vulnerability Issue

Network Registrar Communications Security Option

Software and Standards Compatibility

Interoperability

Installation and Upgrade Notes

General Installation

Red Hat Linux Installation

Windows Installation

Upgrade Considerations

Moving Network Registrar to a New Machine

New Features and Implementation Notes

CCM Database Index Repair

DNS Resolution Queue Management

DNS Scavenging Process

Chatty Client Filter

Lease History Database Compression Utility

General Comments on Running cnr_leasehist_compress

Running Compression on Solaris and Linux

Running Compression on Windows

Warning About Updating DNS First

Failover Pair Renaming

High-Availability (HA) DNS Statistics

Generating Resource Records on BIND Imports

Multiple Interface Users

TFTP Block Sizes

Pushing Subnets to Cisco uBR10000 Routers

Caveats

Documentation Errata

Lease Import Function

LDAP

Simple Network Management

DHCP Failover Configuration

DHCP Reply Options

HA DNS Server Pair Reloads

Related Documentation

Obtaining Documentation and Submitting a Service Request


Release Notes for Cisco Network Registrar


August 15, 2008

These release notes cover Cisco Network Registrar Release 6.2.4. This software release resolves a DNS vulnerability issue (CSCsq01298), and includes all the bug fixes and features incorporated for the 6.3.1.4 release.


Note Network Registrar 6.2.4 is essentially identical to the 6.3.1.4 release, with the exception of certain system requirements. Because 6.2.4 and 6.3.1.4 are otherwise identical, the sections that follow relate to the 6.3.1 Release Notes. For information on the system requirements specific to 6.2.4, see the "System Requirements" section. All other documentation on the installation media are 6.3 documents.

This 6.2.4 release is the final release in the 6.2.x train of releases. If you are using 6.2.x versions, we recommend that you upgrade to the latest 6.3.x or 7.0.x versions at your earliest convenience for enhanced functionality and technical support.


Contents

These release notes cover:

Introduction

Before You Begin

Software and Standards Compatibility

Interoperability

Installation and Upgrade Notes

New Features and Implementation Notes

Caveats

Documentation Errata

Related Documentation

Obtaining Documentation and Submitting a Service Request

Introduction

This release of Network Registrar resolves a DNS vulnerability issue (see the "DNS Vulnerability Issue" section) and includes all the bug fixes and features incorporated for the 6.3.1.4 release.

Before You Begin

Review the following sections before installing Network Registrar 6.3.1.

License Keys

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

To determine if you need a new license key:

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

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

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

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

System Requirements

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

Java—You must have the Java Runtime Environment (JRE) 1.4.2 or later, or the equivalent Java Development Kit (JDK), installed on your system. Before installing the SDK, ensure that you install JRE 1.4.2 or later, or the equivalent JDK, on your system. (The JRE is available from Sun Microsystems on its website.)

Operating system—Your Network Registrar machine must meet the minimum requirements of the Windows, Solaris, or Linux operating systems that appear in Table 1. Network Registrar must run on 32-bit operating systems.

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

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

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


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


Table 1 Network Registrar Minimum Requirements and Recommendations 

Operating System
Solaris
Linux
Windows
Component
     

OS version 1

Solaris 8 or Solaris 9

Red Hat Linux Enterprise Server (ES) 3.0 and 4.0

Windows Server 2003 and Windows 2000 (Service Pack 2 or later recommended)2

Disk space 3

2 x 73/146 SAS4 drives

With basic DHCP and optimal hardware configuration:

SATA5 drives with 7500 RPM drive > 500 leases/second

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

(Recommended hard drive 146 GB)

Memory6

16 GB

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

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

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

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.


DNS Vulnerability Issue

Network Registrar 6.2.4 resolves a DNS vulnerability issue 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

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 at: 800 553-2447 or 408 526-7209.

Network Registrar Communications Security Option

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

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

Software and Standards Compatibility

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

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

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

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

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

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

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

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

Interoperability

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

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

Table 2 Regional Cluster Features 

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

Central push and pull:

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

x
x
x
x

x
x
x
x
x

x
x
x
x
x

x
x
x
x
x

Administrator:

Single sign-on
Password change

x

x
x

x
x

x
x

IP history reporting:

Central lease history
Detail lease history

x

x
x

x
x

x
x

Utilization reporting:

Central subnet utilization history
Current subnet and scope utilization

x

x
x

x
x

x
x


Installation and Upgrade Notes

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

General Installation

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

Windows, Solaris, and Linux installations occur through:

Windows—Windows-based InstallShield setup program.

Solaris—The pkgadd command.

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

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

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

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

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

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

Red Hat Linux Installation

Installing Network Registrar on Red Hat Linux requires that you install the 32-bit OpenLDAP library.

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

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

The Linux download kit supports RH 7.3 and RH 2.1.

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

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

The Linux3 download kit supports RH ES 3.0.

The Linux4 download kit supports RH ES 4.0.

Release 6.3.x supports RH ES 4.0 only.

Windows Installation

The Network Registrar 6.3.1 installation program for Windows no longer attempts to modify ACLs to restrict access to installed files and directories. If you want to restrict access to these files and directories, use the native Microsoft utilities cacls and icacls to manually change file and directory permissions. (Refer to Microsoft documentation about how to use the cacls and icacls utilities.)

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

installdir\conf\cnr.conf

installdir\tomcat\conf\server.xml

installdir\conf\priv\

installdir\data\

Upgrade Considerations

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

Before you upgrade to Network Registrar 6.3.1:


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

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

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

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

Windows—net stop nwreglocal

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

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

Step 6 Upgrade your operating system, if necessary.

Step 7 Upgrade Network Registrar (see the following Note).


Note The recommended practice is to upgrade the regional cluster before upgrading any local clusters, because an older version regional cluster cannot connect to newer local clusters (CSCsm61420). For upgrades from version 6.1 of DHCP failover servers, upgrade the main server before the backup server, because mixed-mode failover synchronization back to version 6.1 (which is needed for the period until the backup is also upgraded) is supported only from main to backup. (See also the "Failover Pair Renaming" section.)


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

a. Delete the possibly corrupted data directory.

b. Install the previous Network Registrar release.

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

d. Delete the data directory that the installation creates.

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

f. Restart the server agent:

Windows—net start nwreglocal

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


See also the "CCM Database Index Repair" section.

Moving Network Registrar to a New Machine

You might want to move an existing Network Registrar installation to a new machine. The following procedure preserves your original data on the old machine if a problem arises 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:

Windows—net 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 for an upgrade; for example:
pkgadd -a install-path/solaris/nwreg2/install/cnradmin -d
install-path/solaris nwreg2). The installation will detect an upgrade, based on the copied data.

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


New Features and Implementation Notes

This section covers the following:

CCM Database Index Repair

DNS Resolution Queue Management

DNS Scavenging Process

Chatty Client Filter

Lease History Database Compression Utility

Warning About Updating DNS First

Failover Pair Renaming

High-Availability (HA) DNS Statistics

Generating Resource Records on BIND Imports

Multiple Interface Users

TFTP Block Sizes

Pushing Subnets to Cisco uBR10000 Routers

CCM Database Index Repair

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

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


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

You can run this utility from:

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

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

The syntax for the rebuild_indexes utility is:

rebuild_indexes options -d path [options]

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

options are:

-c—Checkpoints the database before exiting.

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

The rebuild_indexes utility checks and updates:

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

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

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

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 to a higher value (the preset value in this release is 5000 concurrent requests; the maximum value is 50000). For example:

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

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

DNS Scavenging Process

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

Chatty Client Filter

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

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

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

Clients in this network send a large number of packets.

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

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

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


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


nrcmd> dhcp attachextension post-packet-decode dexChattyClientFilter 

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


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


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

Table 3 Chatty Client Filter Options 

Option
Description
Default

-d packets seconds

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

Disabled

-h packet-count

Sample hits to disable.

15 packets

-i seconds

Sample time interval.

30 seconds

-l packet-count

Quiet hits to leave disabled.

5 packets

-q seconds

Quiet time interval.

10 seconds

-s

Silently discards dropped packets.

Disabled

-n

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

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

Disabled

-r seconds

Controls the statistics reporting interval.

300 seconds (5 minutes)


Lease History Database Compression Utility

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


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

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

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

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

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 certain router configurations create; servers must then handle the additional load.

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 this tool 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.

Table 4 describes the qualifying options for the cnr_leasehist_compress utility.

Table 4 cnr_leasehist_compress Options 

Option
Description

-a

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

-c

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

-d

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

-e attrlist

Overwrites the excluded merge attribute list.

-f file

Redirects most lease history record warnings to a log file.

-g

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

-i ipaddr

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

-l limit

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

-m time-int

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

-n

Compares adjacent records without merging them.

-p

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

-q records

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

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

-r records

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

-s path

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

-t age

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

-v

Emits the version and exits.

-w

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

-y

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

-z {letters}=level

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


Running Compression on Solaris and Linux

To run the cnr_leasehist_compress utility on Solaris and Linux:


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

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

Step 2 Stop the Network Registrar regional cluster:

# /etc/init.d/nwregregion stop 

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

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

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

# mkdir install-path/data/leasehist 

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

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


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

Step 6 Restart the Network Registrar regional cluster.

# /etc/init.d/nwregregion start 

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

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

# mkdir install-path/data/newleasehist 


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


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

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

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

Step 9 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 complete the following procedure. If the system reboots during the following procedure, repeat these steps.


a. Stop the Network Registrar regional cluster:

# /etc/init.d/nwregregion stop

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

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


Caution The -a option is critical because 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 by using the Network Registrar Web UI.

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

Step 13 Delete the original database and temporary active database:

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


Running Compression on Windows

To run the cnr_leasehist_compress utility on Windows:


Step 1 Stop the Network Registrar regional cluster:

> net stop nwregregion 

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

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


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


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

> mkdir install-path\data\leasehist 

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

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


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


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

> net start nwregregion 

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

> mkdir install-path\data\newleasehist 


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


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

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

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

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


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


a. Stop the Network Registrar regional cluster:

> net stop nwregregion 

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

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


Caution The -a option is critical because 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 


Warning About Updating DNS First

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

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

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

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

Failover Pair Renaming

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

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

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

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

The behavior of failover-pair objects differs 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-pair objects when upgrading from pre-6.2 to 6.2 or later:


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

nrcmd> dhcp disable start-on-reboot 

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

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

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

nrcmd> dhcp enable start-on-reboot 

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


High-Availability (HA) DNS Statistics

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

Table 5 DNS Statistics 

Statistic
Description

ha-msg-connect-recv

Number of connection establishment request messages received (HA_DNS_ESTABLISH_CONNECTION).

ha-msg-connect-sent

Number of connection establishment request messages sent (HA_DNS_ESTABLISH_CONNECTION).

ha-msg-heartbeat-recv

Number of heartbeat request messages received (HA_DNS_HEARTBEAT).

ha-msg-heartbeat-sent

Number of heartbeat request messages sent (HA_DNS_HEARTBEAT).

ha-msg-reconcile-recv

Number of zone reconciliation request messages received (HA_DNS_RECONCILIATION).

ha-msg-reconcile-sent

Number of zone reconciliation request messages sent (HA_DNS_RECONCILIATION).

ha-msg-rrsync-recv

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

ha-msg-rrsync-sent

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

ha-msg-rrupdate-recv

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

ha-msg-rrupdate-sent

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

ha-msg-zonesync-recv

Number of zone synchronization request messages received (HA_DNS_ZONE_SYNC).

ha-msg-zonesync-sent

Number of zone synchronization request messages sent (HA_DNS_ZONE_SYNC).

ha-zone-mismatch

Number of zones reporting a mismatch error (HA_DNS_RESP_ERR_MISMATCH).

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


Generating Resource Records on BIND Imports

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

Multiple Interface Users

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

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, and make changes, if it is still valid after the other user's changes.

TFTP Block Sizes

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


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

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

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

Pushing Subnets to Cisco uBR10000 Routers

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

Caveats

For a list of resolved and open bugs for this release, see the cnr_6_2_4-buglist.html file at the product download site at:

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

Documentation Errata

This section covers:

Lease Import Function

LDAP

Simple Network Management

DHCP Failover Configuration

DHCP Reply Options

HA DNS Server Pair Reloads

Lease Import Function

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

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

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

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

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

LDAP

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

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

Simple Network Management

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

The remaining MIBs are available at:

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

DHCP Failover Configuration

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

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

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

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

"load-balancing

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

DHCP Reply Options

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

HA DNS Server Pair Reloads

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

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

Related Documentation

If you require more information about installing, configuring, and managing Network Registrar, for:

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

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

Commands available through the CLI, see the Cisco Network Registrar CLI Reference Guide 6.3.

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 by using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.