Cisco Network Registrar

Release Notes for Cisco CNS Network Registrar 5.5.13

  • Viewing Options

  • PDF (400.8 KB)
  • Feedback
Release Notes for Cisco CNS Network Registrar Release 5.5.13

Table Of Contents

Release Notes for Cisco CNS Network Registrar Release 5.5.13



System Requirements

Software and Standards Compatibility

Version Compatibility

Upgrading from an Earlier Software Release

Running the Upgrade Program

Recovering from a Failed Upgrade

Installation Notes

Delegation-Only Domain Feature Added in Release 5.5.11

Features Added in Release 5.5

New Software Features

DNS Performance Enhancements

Zone Checkpointing and Changeset Database

DNS Log Settings

Windows 2000 DNS Interoperability

Resource Record Scavenging

Dual Zone Updating

Virtual Private Network Aware DHCP

DHCP Subnet Allocation

Failover Recovery Enhancements

Client Caching

Lease Query Enhancements

Inhibiting Lease Renewals

IP History Logging

TFTP Server Enhancements

TFTP File Caching

TFTP Logging Restriction

User Interface Enhancements

Extension Point Enhancements and Changes

RedHat Linux Support

Upgrading on Linux

Re-installation Errata

Update on Database Backup and Recovery

Documentation Updates


Upgrade Failure Workaround

Bugs Fixed in Release 5.5.13

Obtaining Documentation

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco Technical Support Website

Submitting a Service Request

Definitions of Service Request Severity

Obtaining Additional Publications and Information

Release Notes for Cisco CNS Network Registrar Release 5.5.13

October 12, 2004

These release notes are for Cisco CNS Network Registrar 5.5.13. They describe installation and upgrading, new software features, caveats, documentation, and technical assistance.


These release notes cover the following topics:


System Requirements

Software and Standards Compatibility

Version Compatibility

Upgrading from an Earlier Software Release

Installation Notes

Delegation-Only Domain Feature Added in Release 5.5.11

Features Added in Release 5.5


Obtaining Documentation

Documentation Feedback

Obtaining Technical Assistance

Obtaining Additional Publications and Information


This release builds on the success of the previous releases of this product; extends the performance and scalability of the DNS, DHCP, and TFTP servers; and adds Linux operating system support.

System Requirements

Cisco Network Registrar 5.5 runs on the following operating systems:

Windows 2000 Service Pack 1 or later, and Windows NT 4.0 with Service Pack 6a

Solaris 7 and 8

Redhat Linux 6.2 (kernel 2.2)

The command line interface (CLI) runs on all the listed operating systems. The Network Registrar graphical user interface (GUI) runs on Windows 2000, Windows NT 4.0, and Solaris.

If you are upgrading to this release, maintain at least the same amount of free disk space that you had for the previous release. The full system, server, and client requirements are described in the Network Registrar Installation Guide.

For all operating systems, Cisco recommends that you install the current service pack (for Windows) or recommended patch cluster (for Solaris).

Software and Standards Compatibility

Network Registrar 5.5 is compatible with Cisco Device Provisioning Registrar (DPR) 2.0 and later, and Cisco Address and Name Registrar (ANR) 2.0 and later.

Network Registrar is not compatible with Cisco Access Registrar (CAR). The two products cannot be run on the same host machine. Verify that CAR was not installed on your server. The integrity of Network Registrar and CAR will be compromised if you try to run both products simultaneously.

The Network Registrar servers continue to comply with standard applicable RFCs, protocols, standards, and IETF drafts:

DNS servers—Compliant with RFCs 974, 1034, 1035 (with updates 1101and 1183), 1995 (IXFR), 1996 (NOTIFY), 2136 (Dynamic DNS Updates), 2317 (Classless, 2782 (SRV), and 2915 (NAPTR).

DHCP and BOOTP clients—Compliant with RFCs 951 (with updates 1497 and 1542), 1534, 2131, 2132, 2136, 3004, and 3046.

DHCP failover servers—Compliant with draft-ietf-dhc-failover-03.txt.

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

Lightweight Directory Access Protocol (LDAP) servers—Interoperation with any LDAP v2 or LDAPv3 servers compliant with RFC 1798. Note that Network Registrar 5.5 uses the iPlanet LDAP Software Development Kit (SDK) version 5.0, an upgrade from Network Registrar 5.0, which used SDK version 3.0. Extensible filtering (per RFCs 2241 and 2254) is also now supported.

Version Compatibility

The Network Registrar 5.5 CLI (nrcmd) includes a number of new features, whereas the GUI is virtually unchanged. Even with the added commands, the CLI is backward compatible with Network Registrar 5.0 and 3.5. The CLI includes new commands for the enhanced dynamic DNS and zone transfer features, and for the virtual private network (VPN), subnet allocation, and IP history features for DHCP.

Caution Due to changes in the database format, earlier versions of the CLI ( nrcmd) or the GUI cannot administer a Network Registrar 5.5 server. However, the Network Registrar 5.5 versions of both user interfaces can administer earlier versions of Network Registrar back to 3.5.

Caution Existing utilities for manipulating the MCD database continue to operate. However, the output from the mcdadmin utility no longer includes the DNS resource records and DHCP lease state data. Also, you can import into 5.5 only configuration data that you exported from a previous release. You cannot import DNS resource record or DHCP lease data from the previous release.

Upgrading from an Earlier Software Release

The software upgrade procedure handles any data conversions required due to the new CNR databases.

Caution Do not use the pkgadd program for upgrades on Solaris. Also, do not uninstall the product before upgrading, or the upgrade will fail. (See the following bullets for the programs to use in each case.) If you have a Network Registrar release earlier than 3.5, you must first upgrade to 3.5. After you complete the upgrade, you can no longer downgrade the databases. Because of this, keep a backup of the original databases (see the "Update on Database Backup and Recovery" section). For a caveat about upgrading from 3.5 with a database possibly having invalid DHCP name formats, see the "Upgrade Failure Workaround" section.

For Solaris installations, you must use the upgrade_cnr utility if you have 3.5 or 5.0 installed and want to upgrade to 5.5. Do not use the pkgadd program for either upgrading or uninstalling the previous version.

Linux allows upgrades only from the 5.5 versions, although you can use the uninstall_cnr program to uninstall the software. See the "Upgrading on Linux" section.

Running the Upgrade Program

To run the upgrade program for Solaris installations, log in as the superuser and specify the full path to the upgrade_cnr command at the shell prompt. You cannot be in the directory where Network Registrar is installed. Ensure that the directory where you want to back up the database exists and has enough disk space before you run the upgrade program. In addition to the location you specify, the upgrade program also backs up the database to the data-dir/data/db.bak directory on Solaris or the install-dir\data\db.bak directory in Windows. Because of this, ensure that there is enough disk space for both locations.

Upgrading from version 3.5 to 5.5, Network Registrar automatically converts the DHCP failover and lease objects in the state databases. However, the failover partner performs a complete recovery (exchanges all lease binding information) between the servers. This can result in long recovery times for large configurations. (See the "Failover Recovery Enhancements" section.)

Recovering from a Failed Upgrade

If the Network Registrar upgrade fails, there are steps you can take to recover. The upgrade usually fails with a message such as "Installation of <nwreg2> was suspended (interaction required)," followed by a message that the program cannot continue with the upgrade process. To correct this problem, follow these steps:

1. Re-install the current version of Network Registrar that you are running.

2. Copy the four files located in the /usr/tmp/cnr_db.bak directory to the /var/nwreg2/data/db directory:


3. Run a keybuild.

cd /var/nwreg2/data/db 
/opt/nwreg2/bin/keybuild mcddb 

4. Run a dbcheck to verify the data integrity of the database, from the /var/nwreg2/data/db directory.

/opt/nwreg2/bin/dbcheck -a mcddb 

5. Restart the AIC Server Agent and all your data should be recovered.

/etc/init.d/aicservagt start 

6. Verify that all the data is complete.

7. Try the upgrade again.

Installation Notes

Be aware of the following for the Network Registrar 5.5 installation:

Close all applications (especially virus scanning) and system file windows.

If you are upgrading from a previous Network Registrar release, complete any configurations using the previous release so that the existing database, prior to conversion, is up to date. Do this as a precautionary measure. To upgrade from a release earlier than 3.5, you must first upgrade to 3.5. There is no direct upgrade from a release earlier than 3.5.

On Windows, the installation program detects any configuration data from a 5.0 or 3.5 release, and, if you choose to do so, migrates the data to the new 5.5 release databases.

On Solaris, the installation program you use depends on whether you perform a new installation or an upgrade from 5.0 or 3.5. New installations are described in the "New Installation" section in the chapter for your operating system in the Network Registrar Installation Guide. Upgrades are described in the "Upgrading from Version 5.0 or 3.5" section. The procedures are different. For upgrades, use the upgrade_cnr utility only; do not use an uninstall program. Also, the installation will fail if any of the directories in the installation path have permissions that are too restrictive, such as 700 (drwx------). Use permissions of 755 (drwxr-xr-x) for the parent directories of the installation directories.

Note There are some errors in the "Re-installing Network Registrar" section of the "Installing Network Registrar on Linux" chapter of the Network Registrar Installation Guide. See the "Re-installation Errata" section for details.

Caution Virus Scanning and Archiving Programs—We recommend excluding certain Network Registrar directories from virus scanning or certain backup programs. Such programs might be damaging to Network Registrar operation. Exclude the following directories and their subdirectories:

Windows—\Program Files\Network Registrar\data and ...\logs
Solaris and Linux—/var/nwreg2/data and .../logs.

Network Registrar also maintains lock files in the \Temp directory on Windows and the /tmp directory on Solaris and Linux. They are recreated during reboot, but are vital while a system is running. Any maintenance process should also exclude this directory.

Delegation-Only Domain Feature Added in Release 5.5.11

Network Registrar Release 5.5.11 addresses unwanted, unregistered domain resolution to SiteFinder or other diversion mechanisms by adopting a similar solution as Internet Software Consortium (ISC) BIND with its newly defined "delegation-only" zone "type" statement. Network Registrar does this through a DNS server-wide delegation-only-domains setting. (Note that this attribute is not documented in the Release 5.5 documentation.)

Through this setting, zones are effectively limited to containing NS resource records for subdomains, but no actual data beyond their own apex (for example, SOA records and apex NS record sets). According to the BIND description, this can be used to filter out "wildcard" or "synthesized" data from authoritative nameservers whose undelegated (in-zone) data is of no interest.

The syntax of the attribute setting is:

nrcmd> dns set delegation-only-domains=list-of-domains 

The list of domains is a comma-separated list—com., net. is one example. When resolving a name in one of the specified domains and communicating with a server considered authoritative for one of them, the Network Registrar DNS server only considers answers that:

Are referrals to other servers.

Provide NS records in response to NS (or ANY) queries.

Contain glue records below a delegation and are accompanied by a referral (delegation NS records in the authority section).

Are in the specified domain.

Any responses that do not conform to one of these are converted to no-such-name (NXDOMAIN) responses. This also applies to no-such-data responses that indicate that a name exists, but does not hold records of the queried type.

The delegation-only-domains feature does not examine answers from forwarders or resolution exception servers. Those servers are queried recursively and may answer from cache, so that their responses may falsely test positive as violations of the delegation-only rules.

Caution Configure delegation-only domains only when absolutely necessary. For example, configuring name. to be a delegation-only domain prevents e-mail from reaching all its registered users. Do not use delegation-only domains especially for top-level domains whose charter allows for wildcard and other non-delegation names, such as the name. and museum. domains.

Features Added in Release 5.5

This section describes the new features in Network Registrar 5.5.

New Software Features

The following software features were introduced in Network Registrar 5.5:

DNS Performance Enhancements

Windows 2000 DNS Interoperability

Virtual Private Network Aware DHCP

DHCP Subnet Allocation

Failover Recovery Enhancements

Client Caching

Lease Query Enhancements

Inhibiting Lease Renewals

IP History Logging

TFTP Server Enhancements

User Interface Enhancements

Extension Point Enhancements and Changes

RedHat Linux Support

Update on Database Backup and Recovery

Documentation Updates

DNS Performance Enhancements

For performance reasons, the version 5.0 DNS MCD state database was replaced in Network Registrar 5.5 with a new CNRDB database. This database better handles incremental zone transfers and dynamic updates, eliminates the need for deferred background loading, and increases zone reload performance. Network Registrar 5.5 now supports up to 32000 zones having a total of one million resource records. Network Registrar now balances the DNS zone data across the following databases:

Existing AUTH database as a cache of authoritative data

MCD CONFIG database for static records and other configuration data

New CHANGESET database for dynamic record data

New CHECKPOINT database to support full zone recovery

CACHE database

The result of these database changes and zone checkpointing is that DNS performance increased five- to tenfold from version 5.0. This means a five- to tenfold increase over BIND 8 performance and a 20- to 30-fold increase over BIND 9 performance. This provides a highly scalable DNS server.

Zone Checkpointing and Changeset Database

Zone checkpointing creates a checkpoint file at periodic intervals for each of the authoritative zones. This checkpoint file serves as a backup and base point for any changesets that occur. The DNS server creates these checkpoint files at runtime. You can use server settings to tune the operation of this subsystem from the defaults. You only need to be aware of these files during the normal database backups and restores.

You can set the zone checkpoint time interval for both the server and the individual zone, using the following new commands in the CLI:

nrcmd> dns set checkpoint-interval=time 
nrcmd> zone name set checkpoint-interval=time 

The default checkpoint interval is three hours, with a minimum of one hour and a maximum of seven days. The checkpointing proceeds automatically at each of these intervals, or when the number of zone changesets exceed a configurable limit (400 by default). You can also force intermittent checkpoints, and dump a more humanly readable form of the checkpoint file, using the following CLI commands, respectively:

nrcmd> zone name chkpt 
nrcmd> zone name dumpchkpt 

Note During an upgrade to 5.5, you may get an "aborting zone checkpointing" error. This is because an error may have occurred in initially checkpointing the authzone.db file before the DNS server comes up. In this case, Network Registrar loads all records from the database, which slows down the upgrade, but does not abort it.

DNS Log Settings

The DNS server now provides extensive log settings through the following CLI command:

nrcmd> dns set log-settings=logging-type 

The logging types include server configuration and unconfiguration, datastore events, dynamic update messages, incremental zone transfer data, notifies, queries, lame delegation notification, packet processing, scavenging, and server operations. See the "Resource Record Scavenging" section for details on the new scavenging feature.

Windows 2000 DNS Interoperability

Network Registrar 5.5 provides dynamic record scavenging and dual zone updates for Windows 2000 clients. These features are described in the following subsections.

Resource Record Scavenging

Network Registrar can now remove stale dynamic resource records. Windows 2000 clients generally refresh their records every 24 hours. However, with the proliferation of laptop computers, it is highly likely that many of these addresses will not be refreshed, because the laptop may not remain connected to the network. These stale records were previously not removed from the database. To counter this problem, Network Registrar 5.5 puts a scavenging mechanism in place that deletes these stale resource records. Other records are refreshed at other intervals.

When Network Registrar creates a record, it gives the record a timestamp. There is a set period, the no-refresh interval, during which actions such as dynamic update and data prerequisite queries concerning that record do not advance its timestamp. Microsoft sets this period at one week by default. After this interval, there is an additional period, called the refresh interval, also defaulting to one week, during which these actions on the record update the timestamp. When a record's timestamp is older than the sum of these intervals, it becomes a candidate for scavenging.

You can enable scavenging on the zone level, using the following CLI command:

nrcmd> zone name enable scvg-enabled 

You can set the time intervals during the no-refresh, refresh, and scavenging cycle through DNS server and zone attributes in the CLI. The zone settings override those for the server. The attributes (along with their defaults) are the following:

nrcmd> dns set scvg-no-refresh-interval=7d 
nrcmd> zone name set scvg-no-refresh-interval=7d 

nrcmd> dns set scvg-refresh-interval=7d 
nrcmd> zone name set scvg-refresh-interval=7d 

You can also set the maximum number of records to search at one time. An additional attribute, scvg-ignore-restarts-interval, provides a safeguard for the server not to reset the scavenging time with every server restart. During this interval, the Network Registrar ignores the time between when the server went down and was restarted, which is usually fairly short. The interval defaults to two hours, but has a maximum value of one day. With any time set longer than that, Network Registrar recalculates the scavenging period. The zone setting overrides the server setting.

nrcmd> dns name set scvg-max-records=1000 
nrcmd> zone name set scvg-max-records=1000 
nrcmd> dns set scvg-ignore-restarts-interval=2h 
nrcmd> zone name set scvg-ignore-restarts-interval=2h 

You can also force scavenging for scavenging-enabled zones on both the server and zone level:

nrcmd> dns scavenge 
nrcmd> zone name scavenge 

Dual Zone Updating

The DHCP server can now perform the dual zone updates requested by some Windows 2000 clients.

The policy command and the embedded policy commands (client-policy, client-class-policy, and scope-policy) include the allow-dual-zone-dns-update attribute that you can enable.

nrcmd> policy name enable allow-dual-zone-dns-update 

The DHCP client sends the 0 flag in option 81 and the DHCP server returns the 0 flag so that the client can update the DNS server with the A record in its main zone. However, the DHCP server also directly sends an A record update based on the client's secondary zone in the client's behalf. If both the allow-client-a-record-update and the allow-dual-zone-dns-update attributes are enabled, allowing the dual zone update takes precedence so that the server can update the secondary zone's A record.

Virtual Private Network Aware DHCP

Network Registrar 5.5 supports virtual private networks (VPNs), which versions of the Cisco Internet Operating System (IOS) use to implement Relay Agent code supporting VPNs. VPNs allow overlapping address spaces, so that DHCP servers must be equipped to service clients on multiple VPNs with the same address space.

In the configuration example in Figure 1, DHCP client1 in VPN "Blue" sends a lease request to DHCP server1 through the relay agent, which can tell the DHCP server which VPN the client is in. The server then communicates through the relay agent to provide the client the proper address. Another DHCP server2 can also play the role of a failover partner in this environment.

Figure 1 VPN Configuration Using DHCP

This configuration requires defining a namespace for the client that defines the VPN to which it belongs. Through the CLI, you can set your session's current namespace so that all new leases are defined in it. You can export and import leases based on namespaces. You can define namespaces with VPN and Virtual Routing and Forwarding instance (VRF) IDs to be compatible with Cisco Relay Agents. Here are the CLI commands appropriate to the example in Figure 1.

nrcmd> namespace vpn-blue create 99 
nrcmd> namespace vpn-blue set vpn-id=a1:3f6c 
nrcmd> namespace vpn-blue set vrf-name=frumius 
nrcmd> session set current-namespace=vpn-blue 
nrcmd> export addresses file=addrexport.txt namespace=vpn-blue 
nrcmd> export leases -server -namespace vpn-blue leaseexport.txt 

You can also associate namespaces with scopes and address blocks, and you can determine which namespace leases and subnets were created in. Here is a sample CLI command:

nrcmd> scope testScope set namespace=vpn-blue 
nrcmd> dhcp reload 

DHCP Subnet Allocation

The Network Registrar 5.5 DHCP server implements a DHCP subnet allocation feature, which the Cisco IOS release that includes Relay Agent code uses to support on-demand address pools. The DHCP protocol is traditionally limited to interactions with individual host devices about their IP addresses. The DHCP server's role as manager of dynamic IP address space offers it a central role in address assignment. Network Registrar 5.5 now extends this role to wholesale address assignment. The DHCP servers work with the supported Cisco IOS Relay Agent to assign entire address pools to provisioning devices. The new concepts for this are address blocks and subnets. The DHCP server creates subnets based on address blocks, which is analogous to creating leases based on scopes.

In the example in Figure 2, the DHCP server issues blocks of addresses to the ISP gateway devices, which provision the addresses to hosts in their respective subnets. In this way, the DHCP server can maintain the lease information without having to assign leases directly to individual hosts.

Figure 2 Subnet Allocation Using DHCP

You create address blocks for the subnets that the DHCP server provides to the ISP gateways. You can assign a namespace to the address block, set the initial subnet and its increment, and associate a policy. You can also create an embedded policy for the address block.

Here are examples of the new CLI commands you can use to support this feature. As with VPN support (see the "Virtual Private Network Aware DHCP" section), you can create a namespace for the address blocks and subnets.

nrcmd> namespace vpn-red create id=192168400 
nrcmd> address-block red create address= namespace-id=vpn-red 
		initial-subnet=24 subnet-increment=24 policy=Policy1 
nrcmd> address-block-policy red enable allow-lease-time-override 
nrcmd> address-block-policy red set server-lease-time=3600 
nrcmd> address-block-policy red setOption dhcp-lease-time 3600 
nrcmd> dhcp reload 

Using the CLI, you can list and control the subnets that the server creates based on these address blocks, including those created for each address block.

nrcmd> subnet list 
nrcmd> subnet vpn-red/ show 
nrcmd> subnet vpn-red/ activate 
nrcmd> subnet vpn-red/ force-available 
nrcmd> address-block red listsubnets 

Failover Recovery Enhancements

Through changes to the state database, DHCP servers that act as failover partners now have a better way of synchronizing after a server was disabled and then re-enabled. This used to lead to lease binding inconsistencies in Release 5.0. Network Registrar 5.5 also provides an improved way for the partners to notify each other of leases moved to different scopes, and of redirections to other failover servers.

Whereas Release 5.0 gave no indication to users of the progress of servers in recovery mode or during the maximum client lead time wait interval, Network Registrar 5.5 now does. This appears in enhanced log messages and output to the dhcp getRelatedServers command in the CLI. You can now monitor the progress of the recovery over time.

Client Caching

Network Registrar 5.5 maintains a cache of DHCP client data, which reduces the number of searches necessary during DHCPDISCOVER, DHCPOFFER, and DHCPREQUEST cycles, by one-half. LDAP lookup performance is thereby also improved.

You can use the CLI to control the number and frequency of clients cached. Here are examples of using the new DHCP attributes provided for this feature:

nrcmd> dhcp set client-cache-count=1000 
nrcmd> dhcp set client-cache-ttl=5 

Note The Network Registrar User's Guide omitted that the client cache feature is not enabled by default. You need to set at least the client-cache-count attribute to enable it. Also, if the client-cache-ttl is 0, the client cache does not expire and is only re-used after a cache hit by processing a DHCPREQUEST packet.

Lease Query Enhancements

DHCPLEASEQUERY is a mechanism for access concentrators that act as DHCP relay agents to obtain IP address endpoint location information directly from DHCP servers when they cannot glean this information from other sources. These access concentrators use this information to route traffic and verify datagram sources. In Release 5.0, lease queries could only be requested by IP address and could not include lease reservations. Network Registrar 5.5 provides lease query requests by IP address, MAC address, and client ID, and can include lease reservations (which are given one year expirations).

Inhibiting Lease Renewals

Normally, the Network Registrar DHCP server retains the association between a client and its leased IP address. The DHCP protocol explicitly recommends this and it is a feature that is usually desirable. However, for some customers, such as ISPs, clients with long-lived lease associations may be undesirable and these clients should change their IP addresses periodically. Network Registrar includes a feature that allows customers to force lease associations to change when DHCP clients attempt to renew their leases or reboot. This feature is new as of Network Registrar patch release 5.5.2.

A server can never force a client to change its lease, but can compel the client to do so based on a renewal or reboot request. Network Registrar offers configuration options to allow customers to choose which interactions to use to force a client to change its address:

Inhibiting all lease renewals—While a client is running and using a leased address, it periodically tries to extend its lease. At each renewal attempt, the server can reject the lease, forcing the client to stop using the address. The client might well have active connections that are terminated when the lease terminates, so renewal inhibition at this point in the DHCP interaction is likely to be user-visible.

Inhibiting renewals at reboot—When a DHCP client reboots, it might have recorded a valid lease binding that did not expire, or it might not have a valid lease. If it does not have a lease, you can prevent the server from granting the last held lease. If the client has a valid lease, you can have the server reject it, forcing the client to obtain a new one. In either case, no active connections use the leased address, so that the inhibition does not have a visible impact.

Effect on reservations—Reservations take precedence over renewal inhibition. If a client has a lease reservation, it can continue to use the reserved address, whether or not renewal inhibition is configured.

Effect on client-classes—Client-class testing takes place after renewal inhibition testing. A client may be forced to change addresses by renewal inhibition, and client-class tests then influence which new lease the server offers to the client.

You enable or disable lease renewal inhibition for a policy, which you can then set system-wide, for a scope, or on a client-by-client basis. You do this using the CLI. The inhibit-all-renews policy attribute causes the server to reject all renewal requests, forcing the client to obtain a new address any time it contacts the DHCP server. The inhibit-renews-at-reboot policy attribute permits clients to renew their leases, but the server forces them to get new leases each time they reboot.

nrcmd> policy policy1 enable inhibit-all-renews 
100 Ok

nrcmd> policy policy1 enable inhibit-renews-at-reboot 
100 Ok

The DHCP server needs to distinguish between a client message that it should reject (such as a renewal request) and one that represents a retransmission. When the server processes a message, it records the time the packet arrived. It also records the time at which it made a lease binding to a client, and the last time it processed a message from the client about that binding. It then compares the packet arrival time with the lease binding time (the start-time-of-state) and processes packets from the client within a certain time interval from the start time of the binding. By default, this time interval is one minute.

IP History Logging

In Release 5.0, the DHCP server stored only the current lease information for an IP address. This lease information provides the binding of the IP address to a device, through its MAC address. However, the lease information is overwritten when a new client is leased the address. Customers have been storing large amounts of DHCP server log information or written custom extension scripts for logging the IP and MAC address information to a separate file for later processing. This is no longer necessary.

IP history logging provides more concise storage of this historical information with a more efficient query mechanism for discovering which devices were associated with a given IP address. Customers can determine where to store the history files. The new iphist utility provides a number of query options, from simple to more complex, including determining the log output format.

You must explicitly enable IP history recording, and you must also specify the directory path to the root of the IP history database directory. You must do both, or the server does not record the IP history data. The following are sample CLI commands:

nrcmd> dhcp enable ip-history 
nrcmd> dhcp set ip-history-dir=/var/nwreg2/logs 

The iphist utility has the following command format:

iphist [options] {ipaddress | all} [start-date | start [end-date | end]]

You run the utility from the following locations:

On Windows—\Program Files\Network Registrar\bin

On Solaris and Linux—/opt/nwreg2/usrbin

For example:

> cd /opt/nwreg2/usrbin 
ip-history> iphist -n red -o output.txt "12/12/2001 10:01:15" end 

Note The syntax for the start-date and end-date is currently only month/day/year@hour:min:sec (for example, 8/28/2001@10:01:15) or "month/day/year hour:min:sec" (for example, "8/28/2001 10:01:15"), with the time optional. The "month day year hour:min:sec" (for example, "Aug 28 2001 10:01:15") syntax, as indicated in the documentation, is currently not recognized.

The dhcp trimIPHistory command in the CLI supplies the DHCP server with a cutoff time to apply to the history records. When you reload the server, it examines the history database and deletes any records with an expiration time older than the date-string value.

dhcp trimIPHistory date-string [-namespace name] [-logfile filename]

nrcmd> dhcp trimIPHistory "Tue Dec 31 19:00:00 2002" 
nrcmd> dhcp reload 

The effect of the dhcp trimIPHistory command is not persistent: it affects only the next reload, not all subsequent reloads. You can specify to trim data in a specific namespace only. You can also redirect output to a log file in the log file directory, mainly for debugging purposes. Enter the date-string based on the local CLI time and date, in relative or fixed format:

-numunit—Relative date in the form of a hyphen followed by a num digit, and unit as one of s (seconds), m (minutes), h (hours), d (days), or w (weeks). For example, -12d, which indicates "twelve days ago."

"[day-of-week] month day hour:minute[:second] year"—This format must be enclosed in quotes, because it includes space characters. The (optional) day of week and the (required) month are abbreviated to the first three characters; the hour is on a 24-hour clock; seconds are optional; and the year is the fully specified year or a two-digit representation in which 98 = 1998, 99 = 1999, and all other values are in 20xx. For example, the "Tue Dec 31 19:00:00 02" date.

You can get a true confirmation of the history data trimmed by running the iphist utility again and verifying the results.

TFTP Server Enhancements

The TFTP server performance was improved in Network Registrar 5.5 through request caching and limiting the log output of success messages. This results in a five-fold TFTP server performance improvement over the previous release. These enhancements are described in the following subsections.

TFTP File Caching

You can improve TFTP server performance significantly by enabling TFTP file caching. You must do this explicitly, because it is disabled by default. You must also create and point to a file cache directory, and you can set the maximum size of this directory. Here is an example of the CLI commands involved:

nrcmd> tftp set home-directory=/var/nwreg2/data/tftp 
nrcmd> tftp set file-cache-directory=CacheDir 
nrcmd> tftp set file-cache-max-memory-size=32000 
nrcmd> tftp enable file-cache 
nrcmd> tftp reload 

TFTP Logging Restriction

You can improve TFTP server performance by restricting TFTP logging and tracing. By default, the server logs error, warning, and informational messages to file_tftp_1_log files. You can set the log levels using a few TFTP server parameters:

Log level—Master controller of server logging, which defaults to level 3 (log all error, warning, and informational messages). As with packet tracing, the higher logging levels are cumulative. If set to 0, no server logging occurs. To change it, you must reload the server. Cisco recommends leaving logging at level 3.

nrcmd> tftp set log-level=3 
nrcmd> tftp reload 

Log settings—This is the second level of logging control and can take the value default or no-success-messages. Default logging does not alter the default of log level 3 (error, warning, and informational messages). However, you may want to disable writing success informational messages, and thereby improve server performance, by changing the log settings to no-success-messages. Reload the server after changing this value.

nrcmd> tftp set log-settings=no-success-messages 
nrcmd> tftp reload 

Log file count and size—Sets how many log files to maintain and how large to allow them to get in the data/tftp directory. The default is to maintain a maximum of four files of one megabyte each. Reload the server after changing these values:

nrcmd> tftp set log-file-count=4 
nrcmd> tftp set log-file-size=1 
nrcmd> tftp reload 

Note The nlogs and logsize values (as set using the tftp serverLogs command) now take precedence over the log-file-count and log-file-size attributes, which were deprecated to a lower visibility level. For details, see Table 1.

User Interface Enhancements

The following new commands were added to the CLI—see the Network Registrar CLI Reference Guide:





The following new keywords and attributes were added to the following commands:

dhcp command—

dhcp delete-orphaned-leases—Deletes leases not associated with a namespace.

dhcp delete-orphaned-subnets—Deletes subnets not associated with a namespace.

dhcp enable/disable vpn-communication (enabled by default)—See the "Virtual Private Network Aware DHCP" section.

dhcp set client-cache-xxx=—See the "Client Caching" section.

dhcp set ip-history-xxx=—See the "IP History Logging" section.

dhcp trimIPHistory—See the "IP History Logging" section.

dns command—

dns forceXfer secondary—Forces full zone transfers for every secondary zone.

dns set delegation-only-domains—See the "Delegation-Only Domain Feature Added in Release 5.5.11" section.

dns enable/disable save-negative-cache-entries and
dns set cache-write-ttl-threshold=—Enable or disable and set based on rogue host attacks.

dns scavenge—See the "Resource Record Scavenging" section.

dns set fake-ip-name-response=—Prevents suspicious quality-of-service attacks of rogue host A record queries to a caching server.

dns set log-settings=—See the "DNS Log Settings" section.

export addresses set namespace= command—Data output also includes a new "namespace_name" column.

export leases -namespace command

lease-notification namespace= command

report namespace command

scope name set namespace= and scope name set namespace-id= commands

session assert commands—Simplifies interactions with external data management processes, and writing multicommand batch scripts that stop processing if an asserted precondition fails. This includes checking DHCP or DNS configuration changes since a previous checkpoint synchronization, and cluster locking before batch modifications.

tftp set file-cache-xxx= commands—See the "TFTP File Caching" section.

zone command—

zone name chkpt, zone name dumpchkpt, and zone name set checkpoint-interval=—See the "Zone Checkpointing and Changeset Database" section.

zone name forceXfer secondary—Forces full zone transfers for every secondary zone.

zone name scavenge, zone name getScavengeStartTime, and zone name set scvg-xxx=—See the "Resource Record Scavenging" section.

Extension Point Enhancements and Changes

The init-entry extension point was enhanced in Network Registrar 5.5 to include the persistent environment dictionary data item. When calling the init-entry extension point for initialize, if the persistent data item contains the value true, you can save and use the environment dictionary pointer any time before the return from the uninitialize call. In this way, background threads can use the environment dictionary pointer to log messages in the server's log file.

Network Registrar also changes the way it processes the gateway address (giaddr) field in cases where client-class is enabled and extensions are attached to the pre-client-lookup or post-client-lookup extension points. Previously, Network Registrar did not process data in the giaddr field until after the post-client-lookup extension point. It treated changes made to the giaddr at the post-decode-packet, pre-client-lookup, or post-client-lookup extension points, as if the packet had arrived with that giaddr.

Network Registrar 5.5 now examines the giaddr immediately after the post-decode-packet and before the pre-client-lookup extension points. There are two new conditions that can drop the packet before any client-class and pre-client-lookup or post-client-lookup extension point execution for this packet:

If the giaddr does not map to an existing DHCP scope, Network Registrar drops the packet. Before Release 5.5, the packet would not have been dropped until considerably later in the cycle.

If the giaddr maps to a scope that belongs to a network for which failover is configured, and which is not currently responsive to DHCPDISCOVER packets, Network Registrar drops any DHCPDISCOVER packet before any client-class processing. This is also new behavior as of Release 5.5 and dramatically decreases the load on the client-class database when the server is heavily loaded while processing DHCPDISCOVER packets, perhaps relieving a busy LDAP server.

If Network Registrar does not drop the packet because of one of these two conditions, the pre-client-lookup and post-client-lookup extension points process it. If the giaddr changes during either or both of these extension points, the new giaddr determines a (possibly different) scope for continued processing after the post-client-lookup extension point. This mimics the previous behavior, where Network Registrar did not examine the giaddr until after the post-client-lookup extension point.

RedHat Linux Support

Network Registrar is now supported on the Redhat Linux operating system, version 6.2 (2.2 kernel or later) for standard Intel hardware. It is a fully functioning port of the core Network Registrar DHCP, DNS, and TFTP services. Linux supports the CLI (the nrcmd program) only. However, you can access the servers using the Windows or Solaris GUI.

Note In Release 5.5, the Linux operating system is a limited availability product. Contact the Cisco Network Registrar Product Manager for access details. Linux is packaged as a separate release, and is not included in the Solaris, Windows NT, or Windows 2000 distribution.

Upgrading on Linux

If Network Registrar 5.5 is already installed, you must run the upgrade_cnr utility to upgrade. The utility is in the Linux subdirectory of the distribution. Follow these steps to perform the upgrade.

Step 1 Ensure that Red Hat Linux 6.2 (kernel 2.2) is properly installed.

Step 2 If you install from a CD-ROM, insert it in your CD-ROM drive or mount it from your remote server. If you install from a network resource, locate the resource containing the image of the Network Registrar distribution files.

Step 3 Enter username su and the root password to become the superuser.

Step 4 Run the upgrade_cnr utility from the installation directory. Always include only the absolute path to the program; it will not work specified as a symbolic link.

upgrade-directory # upgrade_cnr 
Welcome to the Network Registrar installation program for Linux.

Step 5 Enter the location where the Network Registrar was previously installed, or accept the default /opt/nwreg2 directory if it was installed there.

Please enter the directory of the existing Network Registrar 
installation [Default to /opt/nwreg2]: 

Step 6 Enter the administrative username and password.

This upgrade will require an administrator user name and password.
Username: admin 
Stopping Cisco Network Registrar... 

Step 7 The upgrade normally saves a backup copy of the databases as a precaution. You can accept the default y, or enter n to choose not to back up the database. Before entering n, ensure that a recent backup exists, because not saving a backup upgrades only the Network Registrar binaries.

Would you like to back up your database before upgrading [Y]: 

Step 8 If backing up, decide on a backup directory path and enter it at the prompt, or accept the default /usr/tmp. Network Registrar creates a cnr_db.back subdirectory at this location and places the backup files there. If a previous backup already exists, you are prompted whether you want to overwrite it. The default is not to overwrite it.

Please enter the directory to which you would like to do the backup [/usr/tmp]: 
This directory already exists. Backing up the database will destroy
any previous backup. Continue? [N]: y 

If you choose not to overwrite the backup, the upgrade program exits and a message explains that you must rerun the upgrade_cnr utility to select a different backup location. If you choose to overwrite the backup, the upgrade program backs up the database, upgrades the binary portion of Network Registrar, and restarts the AIC Server Agent.

Backing up database...
Updating binary portion of CNR...
Merging database schema changes...
Starting Cisco Network Registrar...
# Starting AIC Server Agent for Network Registrar
Upgrade Completed

Re-installation Errata

There are errors in the "Re-installing Network Registrar" section of the "Installing Network Registrar on Linux" chapter of the Network Registrar Installation Guide.

To run the utilities discussed in the following procedure, you must have several environment variables set, so that the tools can find the Network Registrar libraries and databases. How you set these variables depends on your command shell, and you should refer to your shell documentation on the proper way to set them:

AIC_CONF must be set to the location of your aic.conf file. This file is in the /conf subdirectory of the binary portion of the installation. On a system that was installed using defaults, this would be set to /opt/nwreg2/conf/aic.conf.

LD_LIBRARY_PATH must be set to the location of the Network Registrar libraries. These are typically in the lib subdirectory of the binary portion of the installation. Because LD_LIBRARY_PATH is a system-wide environment variable, you may already have this set to another value. To avoid problems with other applications, it is important to maintain any previous paths. On a system that was installed using defaults, you would typically set this to /opt/nwreg2/lib:$LD_LIBRARY_PATH.

You may also include the Network Registrar /bin directory in your path, so that you do not need to specify full pathnames for every command. Because PATH is a system wide variable, it is likely that you already have this set. It is typically critical to maintain the previous values for PATH. On a system that was installed using defaults, you would typically set this to /opt/nwreg2/bin:$PATH.

Follow these steps to install Network Registrar on Linux:

Step 1 Enter username su and root password to become the superuser.

Step 2 Ensure that you have a copy of the most recent shadow backup of the databases. If not, ensure that you have enough disk space for the backup and run the mcdshadow backup program. For the MCD data, check its integrity using the dbcheck program from the .../db directory.

.../bin# mcdshadow 
.../db# dbcheck -a mcddb 

Step 3 Shut down the servers.

...# /etc/rc.d/init.d/aicservagt stop 

Step 4 Copy the operational database in the .../data directory to the /recover and /dbcopy directories, which should not be in the installation path. The /recover directory contains the actual recovery files, while the /dbcopy directory stores a safety copy.

.../data# cp -rf *.bak .../recover/. 
.../data# cp -rf *.bak .../dbcopy/. 

Step 5 Uninstall Network Registrar using the uninstall_cnr program. Be sure to remove any leftover files not deleted by the uninstall program.

install-directory# uninstall_cnr 

Step 6 Re-install Network Registrar using the install_cnr program.

install-directory# install_cnr 

Step 7 Stop the servers again, check for disk space, and recover the databases.

a. Recover the MCD data by copying the three mcddb.* files in .../recover/db.bak to .../data/db. Rebuild the key files and check the data integrity.

...# /etc/rc.d/init.d/aicservagt stop 
.../recover/db.bak# cp mcddb.* /data-dir/data/db 
.../data/db# keybuild mcddb 
.../data/db# dbcheck mcddb 

b. Recover the CNRDB data by running the cnrdb_recover -c -v recovery program on the server subdirectories of the .../recover directory. Then, verify the recovery. Finally, if no errors occur, copy all the files in .../recover to the .../data-dir/data/server-type directories.

.../recover/dns.bak/ndb# cnrdb_recover -c -v 
.../recover/dns.bak/ndb# cnrdb_verify dns.ndb 
.../recover/dhcp.bak/ndb# cnrdb_recover -c -v 
.../recover/dhcp.bak/ndb# cnrdb_verify dhcp.ndb 
.../recover# cp -rf dns.bak/* /data-dir/data/dns/. 
.../recover# cp -rf dhcp.bak/* /data-dir/data/dhcp/. 

Step 8 Restart the servers and begin using the recovered data on the re-installed product.

Update on Database Backup and Recovery

As indicated in the "Installation Notes" section, you do not need to back up your existing database—the upgrade process copies the database files to a backup location. However, before the installation, you may want to shut down the AIC Server Agent, initiate a last-minute shadow backup of your existing data, then archive this data to a location not in the installation path (such as to disk or another system). Use the mcdshadow command in the /opt/nwreg2/bin/ (UNIX) or \Program Files\Network Registrar\bin\ (Windows NT) directory to perform the manual shadow backup. Do not use any backup procedure other than mcdshadow, although you can archive the resulting shadow backup files anywhere.

These files are located in the /var/nwreg2/data/db.bak directory for UNIX systems, or the \Program Files\Network Registrar\data\db.bak directory for Windows NT systems. After a successful backup, this directory should contain three mcddb.* files and dns and dhcp subdirectories marked with the current date and time. You can check the integrity of your existing database by using the dbcheck -a mcddb command in the /opt/nwreg2/bin/ (UNIX) or \Program Files\Network Registrar\bin\ (Windows NT) directory.

Network Registrar continues to perform automatic daily (or otherwise specified) shadow backups on the new 5.5 databases. This procedure and ways to recover the data are described in the Network Registrar User's Guide.

Documentation Updates

The Network Registrar documentation was updated as follows:

Network Registrar Installation Guide was updated for all operating systems.

Network Registrar User's Guide documents the new features in 5.5 and troubleshooting sections.

Network Registrar CLI Reference Guide was enhanced and reorganized based on the new release features and improved for readability.


This section highlights the major bugs unresolved and resolved in Network Registrar 5.5.13, with a brief description of each one. The complete list of resolved and unresolved bugs is available at the software download site for Network Registrar. The list is also available on the product distribution in HTML format. To display this list, have your Web browser open the following file:


Upgrade Failure Workaround

An upgrade from Network Registrar Release 3.x can fail because of invalid names for DHCP clients in the configuration database. To avoid this, run the remove_bogus_clients.tcl file found in the doc/utilities subdirectory of the installation directory. Run this Tcl script from the CLI in Release 3.x before upgrading to Release 5.5. Follow the usage instructions in the script. CSCdv51985

Bugs Fixed in Release 5.5.13

The major bugs fixed in Release 5.5.13 appear in Table 1.

Table 1 Major Bugs Fixed in Release 5.5.13 

DDTS Number
Software Release
Found In
Correction Made



The TFTP log settings of nlogs and logsize (as set using the tftp serverLogs command) now take precedence over the log-file-count and log-file-size attributes, which were deprecated to a lower visibility level. The server now ignores these attribute values when set, uses the nlogs and logsize values instead, and returns a message to that effect.



The DNS server no longer causes a memory leak while checkpointing under certain error conditions.



The prerequisite to assure that a DNS name exists before updating was dropped for reverse zone DNS updates.



Deleting a DHCP scope that has DNS updates pending no longer blocks subsequent updates.



On rare occasions when a DNS update contains an add and a delete of the same record, the server no longer fails outbound incremental zone transfers.



Changing a DNS zone from dynamic to static, but leaving scavenging enabled, no longer causes the server to crash.

Obtaining Documentation

Cisco documentation and additional literature are available on Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

You can access the most current Cisco documentation at this URL:

You can access the Cisco website at this URL:

You can access international Cisco websites at this URL:

Ordering Documentation

You can find instructions for ordering documentation at this URL:

You can order Cisco documentation in these ways:

Registered users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:

Nonregistered users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

You can send comments about technical documentation to

You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:

Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.

Cisco Technical Support Website

The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year at this URL:

Access to all tools on the Cisco Technical Support Website requires a user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:

Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool automatically provides recommended solutions. If your issue is not resolved using the recommended resources, your service request will be assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:

For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.

To open a service request by telephone, use one of the following numbers:

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553 2447

For a complete list of Cisco TAC contacts, go to this URL:

Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.

Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:

The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:

Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:

Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:

iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL:

Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

World-class networking training is available from Cisco. You can view current offerings at this URL: