Table Of Contents
Release Notes for Cisco Network Registrar 6.2.3
Contents
Before You Begin
License Keys
System Requirements
Software and Standards Compatibility
User Interfaces and Version Compatibility
Installation and Upgrade Considerations
Installation Changes in Network Registrar 6.2
General Installation
Upgrading
Upgrade Considerations
Upgrade Planning
Red Hat Upgrade Considerations
Features Added in Network Registrar 6.2
Software Developers Kit
IPv6 Support
DHCPv6 Support
DNSv6 Support
DHCP Enhancements
DNS Enhancements
Network Interface Management
Address Space Reports
SNMP Support and Management
Router Management at the Local Cluster
Enhanced Administrator Role Management
Local and Regional Cluster Administration
New and Revised Web UI Pages
CLI Enhancements and Changes
Log File and Change Log Enhancements
Cluster Backup and Restore
Features Added in Network Registrar 6.2.1
Features Added in Network Registrar 6.2.2
Features Added in Network Registrar 6.2.3
Configuring HA DNS on a GSS appliance
Caveats
Fixed Bugs in Network Registrar 6.2.3
Open Bugs in Network Registrar 6.2.3
Documentation Bugs in Network Registrar 6.2.3
Open Source License Acknowledgements
OpenSSL/Open SSL Project
License Issues
Obtaining Documentation, Obtaining Support, and Security Guidelines
Release Notes for Cisco Network Registrar 6.2.3
February 8, 2007
These release notes describe the new software features, installation updates, caveats, and documentation for Cisco Network Registrar, Release 6.2.3.
See also the following documents for important information about installing, configuring, and managing Network Registrar:
•
For Network Registrar installation procedures, see the Cisco Network Registrar Installation Guide.
•For configuration and management procedures, see the Cisco Network Registrar User's Guide.
•For details about commands available through the command line interface (CLI), see the Cisco Network Registrar CLI Reference.
You can access Network Registrar technical documentation at:
http://www.cisco.com/en/US/products/sw/netmgtsw/ps1982/ tsd_products_support_series_home.html
Contents
These release notes comprise the following sections:
•Before You Begin
•Software and Standards Compatibility
•User Interfaces and Version Compatibility
•Installation and Upgrade Considerations
•Features Added in Network Registrar 6.2
•Features Added in Network Registrar 6.2.1
•Features Added in Network Registrar 6.2.2
•Features Added in Network Registrar 6.2.3
•Caveats
•Open Source License Acknowledgements
•Obtaining Documentation, Obtaining Support, and Security Guidelines
Before You Begin
Review the following critical information before installing Network Registrar 6.2.3.
License Keys
Each Network Registrar software license key addresses a separate functional area. You enter these license keys during installation or in the web-based user interface (Web UI) or CLI. An upgrade now prompts for a license key only if it finds no valid license keys in the existing license file.
Follow these guidelines to determine if you need a new license key:
•Initial installation of Network Registrar—Use the license key provided with your shipment.
•Upgrading from Network Registrar 6.1 or 6.0—You can use a license key from 6.1 or 6.0 for a local server upgrade. Although a 6.0 license key operates on the local server cluster, the regional cluster requires one or more new license keys (introduced in 6.1) to view or change the server configuration data.
•Upgrading from a release before 6.0—You must add a new license key. License keys that were valid before 6.0 do not work.
•DHCPv6 functionality requires a new ipv6 license key.
•The router license can now be applied to the local cluster.
System Requirements
Be certain that your system meets the necessary minimum requirements for Java and the operating system:
•Java—You must install the Java Runtime Environment (JRE) 1.4 or later, or the equivalent Java Development Kit (JDK). Obtain the JRE from the Sun Microsystems website.
•Operating system—Table 1 shows the minimum requirements for the Network Registrar servers on Windows, Solaris, and Linux operating systems.
Table 1 Network Registrar Server Minimum Requirements
Component
|
Windows
|
Solaris
|
Linux
|
CPU architecture
|
Intel Pentium III or equivalent
|
Sun Netra AC200
|
Intel Pentium III or its equivalent
|
OS version
|
Windows 2003 or Windows 2000 (Service Pack 2 or later recommended)
|
Solaris 8 or Solaris 9
|
Red Hat Linux Enterprise Server (ES) 3.0 or 4.0. (See also the "User Interfaces and Version Compatibility" section.)
|
RAM
|
512 MB on all platforms
|
Disk space
|
18 GB recommended, minimum 310 MB required for installation
|
Swap space
|
100 MB free swap space
|
•User Interface—Network Registrar includes a Web UI and CLI for local and regional clusters:
–The Web UI runs on a minimum of Microsoft Internet Explorer 6.0 (Service Pack 2), Netscape 7.0, or Firefox 1.0.
Note Configure your browser not to use cached pages.
–The CLI runs in a Windows, Solaris, or Linux command window.
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 1101and 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—Comply with draft-ietf-dhc-failover-03.txt. Also, RFC 3074 (DHC Load Balancing Algorithm).
•TFTP—Comply with RFCs 1123 and 1350.
•Lightweight Directory Access Protocol (LDAP) servers—Operate with any LDAP version 2 or 3 servers that comply with RFCs 1798, 2241, and 2254 (Extensible Filtering).
•DHCPv6 functionality—Comply (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—Comply (all or in part) with RFC 3152 (Delegation of IP6.ARPA), 3363 (Representing IPv6 Addresses in DNS), and related RFCs.
User Interfaces and Version Compatibility
Network Registrar 6.2.3 includes regional and local cluster versions of the Web UI and CLI (the nrcmd program). Note that the Web UI and CLI present different options for the regional and local clusters.
Table 2 shows the interoperability of the local clusters with the Network Registrar 6.2.3 regional central configuration management (CCM) server. Because of changes to the database, user interfaces in pre-6.2 releases cannot operate with 6.2 servers. The 6.2 CLI is compatible with the 6.1 and 6.0 servers.
Also consider the following Red Hat (RH) Linux version compatibility issues:
•Network Registrar 6.1.x supports RH 7.3, RH ES 2.1, and RH ES 3.0.
•Network Registrar Linux 7.3 download kit supports RH 7.3 and RH ES 2.1.
•Network Registrar Linux 3 download kit supports RH ES 3.0 for Network Registrar 6.1.2 and later.
•Network Registrar 6.2.2 supports RH ES 3.0 only.
•Network Registrar 6.2.3 adds support for RH ES 4.0.
Table 2 6.2 Regional CCM Server Interoperability with Local Clusters
Feature
|
Local Cluster Version
|
|
6.0
|
6.1
|
6.1.1
|
6.2
|
Central 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
|
Central push:
Address space
Zone distribution:
- Primary zones
- Secondary zones
DHCP failover synchronization1
Scope templates, update policies
Zone templates
Policies, client-classes, ACLs, keys
Groups, owners, regions
Administrators, roles
|
x
x
|
x
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
|
IP history reporting:
Central lease history
Detail lease history
|
|
x
|
x
x
|
x
x
|
Utilization reporting:
Central subnet utilization history
Current subnet and scope utilization
|
|
x
|
x
x
|
x
x
|
Installation and Upgrade Considerations
Review the following notes before installing Network Registrar 6.2.3 or upgrading from a previous release. If you want to configure HA DNS on a GSS appliance, review the "Configuring HA DNS on a GSS appliance" section.
For full installation and upgrade procedures, see the Cisco Network Registrar Installation Guide.
Installation Changes in Network Registrar 6.2
The two changes to installing and upgrading to Network Registrar 6.2.x are:
•The installation and upgrade procedures now ask if you want to archive (keep a backup of) your current database. Neither choice has an effect on a new installation, which will proceed as usual.
•Installations and upgrades now request a license key if a previous one does not exist. A new installation now also asks for a license key. An upgrade asks for a license key only if it cannot find a valid one from the previous release. You can still opt to omit the license key and add it later when you need it to log in to the cluster.
General Installation
Review the following points before beginning a new installation or an upgrade:
•Windows, Solaris, and Linux installations occur through these means:
–Windows—Windows-based InstallShield setup program.
–Solaris—The pkgadd command.
–Linux—The install_cnr script that uses RPM Package Manager (RPM).
•On Windows, close all currently running applications, including any antivirus software.
•On Windows, ensure that you uncheck the Dr. Watson Visual Notification check box. If checked, this option prevents the servers from restarting automatically if a failure occurs until you respond to a pop-up dialog box. The Visual Notification check box in Dr. Watson is usually checked by default. Execute C:\WINNT\system32\DRWTSN32.exe, uncheck the Visual Notification check box, and then click OK. (You can perform this step after installation.)
•To avoid losing the most recent log entries when the Application Event Log is full in the Windows Event Viewer, check the Overwrite Events as Needed check box in Event Log Settings for the Application Log. If the installation process detects that this option is not set properly, it displays a warning message advising corrective action.
•Virus-scanning and archiving programs—If you have virus-scanning or automatic backup software enabled on your system, exclude these Network Registrar directories and their subdirectories from being scanned to prevent Network Registrar operations from being damaged:
–Windows:
install-path\data (for example, C:\Program Files\
Network Registrar\Local\data)
install-path\logs (for example, C:\Program Files\
Network Registrar\Local\logs)
–Solaris and Linux:
install-path/data (for example, /var/nwreg2/local/data)
install-path/logs (for example, /var/nwreg2/local/logs)
•Because Network Registrar maintains lock files in the \Temp directory on Windows and the /tmp directory on Solaris or Linux, do not delete these directories while Network Registrar is running.
•You cannot run the Network Registrar DNS, DHCP, or TFTP servers concurrently with any other DNS, DHCP, and TFTP servers. In many Windows 2000 and 2003 server systems, these services are enabled and running by default. If the Network Registrar installation process detects that a conflict may exist, it displays a warning message. Before installing Network Registrar, take the appropriate action to disable the conflicting servers.
Note Network Registrar includes a list of 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:
Windows—C:\Program Files\Network Registrar\{Local | Regional}\Docs\
Msgid\MessageIDIndex.html by default.
Solaris and Linux—
/opt/nwreg2/{local | regional}/docs/msgid/MessageIDIndex.html by default.
Upgrading
The new features in Network Registrar 6.2 have specific effects on an upgrade.
Upgrade Considerations
Note that if you upgrade from a release earlier than Network Registrar 5.5, you must first upgrade to 5.5, then from 5.5 to 6.0 (or 6.1), then to 6.2. You cannot upgrade directly to 6.2 from a release earlier than 6.0.
Complete these tasks before starting the upgrade:
1. Ensure that your environment meets the current system requirements (see the "System Requirements" section).
2. Complete any configuration changes in progress by using the previous release, so that the existing database is consistent before you perform the upgrade.
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.
4. Back up your database The installation program tries to detect configuration data from an earlier installation, and will upgrade the data to the 6.2 database format.
5. If you upgrade from 5.5 and have IP history enabled, export and save your existing IP lease history data, or you will lose it.
Note the changes that can occur from the upgrade:
•If upgrading from 6.0—Beginning with 6.1, the localhost, localnet, any, and none access control list (ACL) names are reserved. If you upgrade from 6.0 and have ACLs with these names in your current configuration, Network Registrar renames them with the oldname-1 convention and updates any instances of their use. For example, if you defined a localhost ACL in 6.0, the upgrade renames it to localhost-1.
•If upgrading from 6.0 or 6.1.0—Like 6.1.1, 6.2 requires that administrators be assigned to groups that define their roles. If you upgrade from 6.0 or 6.1.0 and have administrators assigned directly to roles, Network Registrar creates new groups for each of these roles and reassigns the administrators to these new groups. The new groups will have the same name as the roles, followed by the suffix -group. If you upgrade directly from 6.1.1, this processing does not need to occur.
•The 6.2 local clusters now maintain a cluster list, similar to the regional CCM server, to manage connection credentials to remote servers. The upgrade creates a localhost cluster to represent the local server, and additional clusters for each server referenced in DHCP failover pairs and the default zone distribution. The failover pairs and zone distribution will also be modified to reference the new clusters.
•Failover pairs now use a match list that automatically associates scopes with a failover pair relationship. The upgrade moves all scope and DHCP server failover configuration to the new failover pairs. Network Registrar discards invalid or conflicting failover configurations.
•DNS update configuration was redesigned so that the update configuration can also be associated with a given client. The upgrade moves all scope DNS update configuration to new Update Configuration objects, and associates these with the scope, in the existing nondefault scope policy or embedded policy. The upgrade modifies the existing policy or creates a new embedded policy.
•SNMP trap configuration was changed by introducing the SNMP server in the cluster. During the upgrade, Network Registrar moves any existing trap recipient configuration to the SNMP server database. Network Registrar moves scope and DHCP server address trap configurations to new Address Trap configuration objects.
•The definition of DHCP custom and vendor options was redesigned to integrate the configuration into the Web UI, and simplify their use. During an upgrade, Network Registrar moves existing custom options to the new dhcp-custom option definition set and does not upgrade existing vendor options. Examples of the new format are in the /examples/dhcp installation directory.
•The CCM address space model was extended to support primary-secondary relationships on subnets. During an upgrade, Network Registrar updates subnets matching scopes that define a primary subnet to show this relationship.
•DNS zone and resource record (RR) management was redesigned to support dynamic edits (where you do not need to reload the server). During an upgrade, Network Registrar moves existing DNS server zone data and static RRs, which it stored in the MCD database in prior releases, to new internal databases that the DNS server manages.
•The regional CCM server Replica database was extended to support regional backups of all local cluster data. During an upgrade, Network Registrar discards the existing Replica database and updates the complete configuration for each cluster at the first polling interval. You can update the Replica database immediately by clicking the Update icon for each cluster on the List Clusters page.
Note After upgrading a local cluster, you must resynchronize the cluster on the regional List Clusters page, to reenable the single-signon feature.
Upgrade Planning
The Network Registrar 6.2 upgrade process runs during product installation, but also includes subsequent database upgrades during the initial product startup. Depending on the size of the databases (which can be quite large in some deployments), there might be an extended period during the CCM server upgrade when you cannot log in to the Web UI or CLI, or connect to the cluster. In addition, the subsequent database upgrade of the protocol servers takes further time, during which the DNS server especially cannot respond to normal requests.
Empirical data was gathered during an upgrade for a database that comprises 10,000 DNS zones, including two zones each containing 1,000,000 resource records (RRs). The remaining zones contained fewer than 100 RRs each. Two systems gathered the time statistics for the upgrade:
•A SunFire v440 with four processors and an 8-GB memory upgraded the CCM server database in about 45 minutes. The subsequent DNS server database upgrade took about two hours, for a total DNS server downtime of 2.75 hours.
•A SunFire v100 upgraded the CCM server database in about 1.5 hours, with the subsequent DNS server database upgrade taking about three hours, for a total DNS server downtime of 4.5 hours.
The expected time required for the separate database upgrades is linearly related to the relative sizes of the product databases. Environments with fewer zones (containing fewer RRs) should expect a shorter server downtime than those with larger Network Registrar configurations. Therefore, appropriate planning for this downtime is necessary.
Red Hat Upgrade Considerations
This section describes the path that you must follow to upgrade a Network Registrar 6.2.x RH3 server to Red Hat 4 running Network Registrar 6.2.3. Changes to the underlying Linux operating environment mean that you cannot install a version of Network Registrar built for RH3 on an upgraded RH4 server. You must follow the steps described here to install the Network Registrar version that is built for RH4.
Caution Failure to follow these upgrade steps results in the loss of Network Registrar data.
Step 1 Upgrade Network Registrar RH3 6.2.x to 6.2.3, following the instructions in the Cisco Network Registrar Installation Guide.
Step 2 Shut down the Network Registrar RH3 server.
Step 3 Manually copy the entire Network Registrar data tree, including all subfolders, to a safe location.
Note On Red Hat the Network Registrar data tree is <install path>/data. The location to which you copy the data tree must be on a different machine from the one you are upgrading or you will lose your data.
Make a note of the data tree path.
Step 4 Install the Red Hat 4 operating system, following the Red Hat installaton instructions.
Step 5 Make sure that the required version of Java is installed. See the "System Requirements" section for more informaiton about the Java version.
Step 6 Make sure the owner of the data folder is root, with the read/write/execute permission for the owner.
Step 7 Manually copy the entire Network Registrar data tree to the ugraded RH4 server. Be sure that you create and use the exact path that you used on the RH3 server.
Step 8 Install Network Registrar RH4 on the upgraded server. The installation process detects the data path you created.
Step 9 At the prompt asking whether you want to upgrade the files, enter Yes.
Step 10 Allow the installation to finish and restart the server.
Features Added in Network Registrar 6.2
The following subsections describe the features added in Network Registrar 6.2.
Software Developers Kit
Network Registrar 6.2 provides a software developers kit (SDK) that you can order separately.
IPv6 Support
Network Registrar 6.2 supports IPv6 servers and addressing for DHCP and DNS. This feature requires a separate ipv6 license key.
DHCPv6 Support
DHCPv6 provides basic address assignment, prefix delegation, and stateless autoconfiguration by using IPv6 addressing. Network Registrar supports DHCPv6 for clients, client-classes, static reservations, policies, and options; and supports prefixes and links. Network Registrar 6.2 adds the DHCPv6 service to the existing DHCP server, not a separate server, to better leverage the DHCP functionality and infrastructure where possible.
DHCPv6 support requires a separate software license. For Windows, the minimum release to support DHCPv6 is Windows XP with SP2. The DHCPv6 service requires that the server operating system supports IPv6 and that at least one interface on the system be configured for IPv6. You also require an IPv6 network infrastructure with DHCPv6 clients (and DHCPv6 relay agents) for successful operation.
Obtain the Web UI functionality from new Prefixes and Links subtabs below the DHCP tab. The new commands in the CLI are dhcp-prefix, dhcp-link, and lease6.
DHCPv6 and DHCPv4 have many fundamental differences. In DHCPv6:
•Clients can be given and request multiple addresses, not just one.
•IPv6 addresses have lifetimes (preferred and valid).
•Option codes and lengths are 16 bits, not 8 bits. (Only about 30 DHCPv6 options are currently available; see also the "DHCP Enhancements" section for the new option definitions feature.)
•Clients have a DHCP Unique Identifier (DUID), replacing the hardware address and client identifier.
•Servers have a DUID, replacing the IP address-based identifier.
•Messages primarily comprise options with very small headers (no BOOTP legacy).
•Network Registrar uses multicasting, not broadcasting. Clients always multicast all messages to a link-local address (to a relay agent or server), unless a server explicitly allows unicast communication and the client has an appropriate address. Clients always communicate through relay agents (if present).
•Clients always have at least a link-local address, thereby simplifying client/server or client/relay agent communication.
Network Registrar supports the following DHCPv6 features:
•Stateless autoconfiguration (sometimes called DHCPv6lite per RFC 3736)—The DHCPv6 server does not assign addresses, but provides configuration parameters (such as DNS server information) to these clients.
•Stateful configuration (full DHCPv6 per RFC 3315)—The DHCPv6 server assigns (permanent or temporary) addresses and provides configuration parameters to clients.
•Links and prefixes—Similar to DHCPv4 networks and scopes. Links and prefixes define the network topology. Each link can have one or more prefixes:
–Prefixes are equivalent to DHCPv4 scopes.
–Links allow multiple prefixes to be associated with each other, and adds another layer at which to specify policies for DHCPv6 clients. A prefix's link attribute is similar to a scope's primary-scope; except that the link attribute names a link and not another prefix.
•Prefix delegation (per RFC 3633)—The DHCPv6 server delegates prefixes to clients (routers).
•Client-classes—Clients can be classified and prefixes selected based on known clients or packet-based expressions.
•Policies and options—Attributes and options can be assigned to links, prefixes, and clients.
•Static reservations—Clients can receive predetermined addresses.
•Lease affinity—Allows the server to give the same address to a client even if that client does not renew before the valid lifetime expires.
•Virtual private networks (VPNs).
•Statistics collection and logging—Monitors server activities.
Network Registrar 6.2 does not support the following features when using DHCPv6 (although they may be supported in a future release):
•Dynamic DNS updates for DHCPv6 clients (over IPv4 or IPv6)
•LDAP lookups
•Extensions (C++ and Tcl)
•Expressions for other than client-classes
•Address utilization or lease history
•Dynamic reservations
•Limitation IDs
•Failover
•Client authentication (RFC 3315)
•Reconfiguration (RFC 3315)
•Prefix templates
•Lease query
DNSv6 Support
Network Registrar 6.2 provides a DNS server that supports IPv6, including direct queries and updates by IPv6 clients. This support impacts server and zone configuration attributes, such as for ACLs and update policies, that use IP addresses to control server behavior. DNSv6 support includes:
•Full support of AAAA and PTR RRs for IPv6 addresses, and the ip6.arpa reverse zone (RFC 3152).
•First-hop query support for clients over IPv6 (UDP and TCP). This support allows IPv6-only clients to use the DNS server to resolve DNS queries.
•Update policy and ACL support for IPv6 addresses.
Network Registrar 6.2 does not support the following features when using DNSv6:
•Zone transfers over IPv6 (however, the DHCPv6 server replies to IXFR requests coming in on IPv6 interfaces, for example, on the same interface.
•Resolving and forwarding queries by contacting other DNS servers over IPv6 transports.
DHCP Enhancements
Network Registrar 6.2 includes the following enhancements to DHCP implementation (other than DHCPv6):
•Dynamic scope management—The DHCP server provides two scope edit modes: synchronous and staged. In synchronous mode, the server immediately engages administrator actions to create and edit scopes without a server reload. Staged edits require a server reload. You can use synchronous mode for most editable scope attributes (except scope name, subnet number, subnet mask, primary subnet number, primary subnet mask, and VPN), the scope embedded policy, and the scope address range. The scope edit modes can be set for each session. The default is staged mode.
•Failover pair management—Failover pairs are now distinct objects that are separate from the DHCP servers. This feature is available at the regional and local clusters in the Web UI and CLI. The CLI command is failover-pair.
Note Treatment of the failover pair as a separate object might require new operational procedures (especially if using anything but simple failover). For example, failover pair configuration now includes a Network Match List that might need updating for adding new scopes.
•Failover load balancing (RFC 3074)—Distributes the client population more equally across multiple DHCP servers. The failover pair attribute load-balancing can be enabled or disabled. The default is disabled.
•DNS update configurations—You can now determine update of the DNS server, based on DHCP activities (RFC 2136), by update configurations, which are separate objects from the DHCP server. You can apply updates to all zones or to forward or reverse zones only. The local Web UI includes a DNS subtab below the DHCP tab for this purpose; the CLI provides the dhcp-dns-update command. Update configurations can be applied to zones and policies (named and scope-embedded), as specified in the DNS Update Settings attributes for each object.
Note DNS update configurations might require new operational procedures when adding new zones and scopes.
•Option definitions and option definition sets—You can now create custom and vendor-specific options much more easily than in previous releases, for DHCPv4 and DHCPv6. These option definitions can be included in option definition sets, which you can define by vendor option string or enterprise ID for vendor options. The Web UI now provides an Options subtab below the DHCP tab for this purpose; the CLI provides the option and option-set commands. At the regional cluster, option definition sets can be pulled from the replica local cluster data and pushed to local clusters.
•Support of the RADIUS suboption of the relay-agent option—The DHCP server adds the RADIUS suboptions of the relay-agent option to its lease data. The CCM regional server now forwards requests to the appropriate local cluster based on its mapping of subnets to DHCP servers.
•Activity summary reporting improvements—The DHCP server now includes activity summary statistics in addition to total statistics, collected over a specified time interval (determined by the activity-summary-interval DHCP server attribute, which defaults to 5 minutes). You enable summary reporting by enabling the DHCP server collect-sample-counters attribute or setting the activity-summary log-setting.
•Reservations can now be for non-MAC addresses—On a scope basis, you can now create reserved leases for an IP address as defined by a client lookup key that is a MAC address, string, or binary value. For policies, you can enable the use-client-id-for-reservations attribute.
•Override the client-id as the client identifier—You can now use an expression (in the client-class's override-client-id attribute) to override the client-id value in the incoming packet.
•Allow multiple lookups in the client-entry database.
•Allow extensions and expressions to place a value in the environment dictionary Network Registrar automatically stores with the lease in the lease state database.
DNS Enhancements
Network Registrar 6.2 includes the following enhancements to DNS (other than the DNSv6 and HA DNS features described elsewhere):
•DNS update policies—Update of the DNS server based on DHCP activities (RFC 2136) was enhanced by introducing policies for that purpose for the DNS server. Access control lists (ACLs), which define who can apply an update to a zone, currently control DNS updates, provided that the zone is dynamic. ACLs can restrict updates based on IP address, network address, or TSIG keys. Update policies provide the capability to specify who can update which resource records (RRs). The Web UI provides configuration pages under the Update Policies tab for DNS; the CLI provides the update-policy command. You can use DNS update policies in place of ACLs when you need this level of security. The DNS server recognizes only a single security setting on the zone. If you configure an ACL and update policy, the server ignores the update policy.
•DNS update maps—DNS update maps define simple update relationships between DHCP servers (or failover pairs) and DNS servers (or HA DNS server pairs). The Web UI includes an Update Maps subtab under the DNS tab for this purpose; the CLI provides the dns-update-map command.
•Name set protection—RR name sets can now be set to protected or unprotected in the Web UI and CLI. Two views are also now available in the Web UI, one for CCM protected RRs and another for DNS server (all) RRs. The CLI has separate listings for CCM RRs and DNS RRs, and you can protect or unprotect the RRs by using the zone name protect-name rr or zone name unprotect-name rr commands, where name is the name of the zone and rr is the RR name.
•Dynamic zone management—The DNS server provides two zone edit modes: synchronous and staged. In synchronous mode, Network Registrar immediately engages administrator actions to create and edit zones without a server reload. Staged edits still require a server reload. The zone edit modes can be set for each session. By default, zone edit mode is synchronous for the local cluster and staged for the regional cluster.
•Zone distributions—Synchronize staged primary zones with the DNS server, in addition to creating secondary zones for the list of configured secondary servers.
•Enhanced zone management:
–Facilitated subzone and reverse zone creation and maintenance.
–Classless reverse zones.
–Enhanced consistency rules. (Note that the Consistency Rules subtab now appears under the Home tab in the Web UI.)
–Zone management is now possible at the regional cluster.
•Zones can now be synchronized at the local and regional clusters.
Network Interface Management
You can now use the Web UI to add and manage network interfaces.
Address Space Reports
Network Registrar 6.2 now includes the ability to generate address space reports for address use accountability:
•American Registry of Internet Numbers (ARIN) reports, including:
–Organization and point of contact (POC) reports
–IPv4 address space utilization reports
–Shared WHOIS project (SWIP) allocation and assignment reports
•Allocation reports that show how addresses are deployed across routers and router interfaces of the network, including allocation by:
–Owner reports
–Router interface or network reports
Network Registrar 6.2 adds reporting functions to summarize data required for selected SWIP and ARIN reports to the regional cluster and, in some cases, to the local cluster. Address space utilization data and associated data stored in the CCM server populated report fields for display in the Web UI or exported to an ASCII text file. To send a report to ARIN, you must manually send the text report via email; no process is available to generate and send a report automatically. Reports are limited to IPv4 data only.
SNMP Support and Management
Network Registrar 6.2 now provides local cluster support for the DHCP and DNS protocol servers, and introduces new Cisco-specific Management Information Bases (MIBs) for each server. The DHCP MIB is based on the IETF draft DHCP MIB, but is tailored specifically to Network Registrar.
SNMP support for each server provides access to server statistics and configuration, and issues SNMPv2 notifications for important events. The server-specific MIBs define the list of supported events.
The SNMP server was added to the local cluster to provide these features. The SNMP server configuration defines the interfaces used when listening for SNMP requests or sending traps, and maintains the list of trap recipients. You can define the traps that each server supports configuration. The new functions emit server events for each defined SNMPv2 notification. The DNS server also supports stop and start traps by using the new mechanism and any newly defined DNS notifications.
New SNMP features include:
•SNMP server and trap configuration.
•New Trap Recipient pages in the Web UI and the trap-recipient command in the CLI.
•New Address Trap page in the Web UI and addr-trap command in the CLI.
Router Management at the Local Cluster
The ability to add and manage routers was added to the local cluster. In the Web UI, a new Clusters tab was added; in the CLI, a new router command. The router configuration requires the IP address, router type, and connection credentials (username, password, and enable password) to an actual router. Omitting the router type or connection credentials creates a virtual router, for which you can create network interfaces. You can add a subnet and then push it to one of the subinterfaces on the router.
Router management requires a separate router license key that you add during the configuration.
Enhanced Administrator Role Management
Network Registrar 6.2 added new local and regional administrator roles, and changed existing ones for local and regional cluster parity:
•New local configuration administrator role (cfg-admin), including local cluster management.
•New central-host-admin and central-dns-admin roles.
•Migration of DNS management from the zone-admin to the dns-admin role. Note that the host-admin role remains available to assign certain users very limited access to zone data. You cannot combine the host-admin role with the dns-admin role, and Network Registrar ignores it if configured.
•New constraints added to roles:
–CCM administration in the central-cfg-admin role
–Access to particular zones and hosts in the dns-admin and central-dns-admin roles
–IPv6 management in the local dhcp-admin role
•More granular authorization through contextual read-write and read-only permissions, and all administrators being constrainable.
The CCM server's internal mechanisms for specifying authorization now allows read-write and read-only granularity in a role and to specify granular authorization by object class for generic functions currently requiring superuser access. Read-write constraints override read-only constraints for roles. This is the reverse behavior of the previous release.
Local and Regional Cluster Administration
Cluster management is now available at the local and regional clusters. This enhancement necessitated some rearrangement of the menu hierarchy in the Web UI for consistency and ease of navigation.
New and Revised Web UI Pages
Network Registrar 6.2 provides new and revised Web UI pages to add functionality and provide parity with existing CLI commands:
•Under the Home tab, the:
–Main Menu page was enhanced to allow setting the staged and synchronous modes for scope and zone edits in the Session Settings.
–Consistency Rules subtab was added.
•Network Registrar consolidated the CCM and MCD change logs under the Administration tab into one View Change Log page.
•You can now access the Manage Servers page from a Servers tab.
•The Clusters and Routers functions are now also available from the local Web UI.
•The View Replica Class List page now includes many more objects.
•Under the DHCP tab, Network Registrar added or updated the following pages:
–Prefixes and Links to configure DHCPv6 in the local Web UI.
–Options to configure option sets and definitions in the local Web UI.
–Failover function to configure DHCP failover pairs.
–DNS function for setting DNS update configurations.
–LDAP function to configure remote LDAP servers.
–Extensions function to configure DHCP extensions.
–Traps function to configure SNMP traps in DHCP in the local Web UI.
–DHCP Server function that opens a Manage DHCP Servers page from which to view the new startup change logs and access a command to set limitation criteria.
•Under the DNS tab (that replaces the Zone tab), Network Registrar added or updated the following pages:
–Update Policies to configure DNS update policies.
–ACLs function to configure ACLs.
–Keys function to configure encryption keys.
–HA Pairs function to configure HA DNS server pairs.
–Update Maps function to configure DNS update maps.
–DNS Server function that opens a Manage DNS Server page from which to view the new startup change logs; and access commands to flush DNS cache, force zone transfers, trigger scavenging, and remove nonauthoritative RRs.
•Under the Hosts tab, host configuration now includes an alias setup field.
•Under the Address Space tab, the functions are Address Space, Address Blocks, Subnets, and Address Types. The regional Web UI also includes the Subnet Utilization and Lease History functions.
•The new Reports tab in the regional Web UI includes the Address Space, Contacts, and Organizations report functions.
CLI Enhancements and Changes
The CLI now comes in local and regional cluster versions. The commands in Table 3 are new or modified in Network Registrar 6.2, in some cases to provide parity with the equivalent Web UI functions.
Table 3 CLI Commands Added in Network Registrar 6.2
Command
|
Description
|
addr-trap
|
Manages SNMP traps (see the "SNMP Support and Management" section).
|
ccm
|
Manages the CCM server.
|
cluster
|
Manages clusters.
|
dhcp-address-block
dhcp-address-block-policy
dhcp-subnet
|
Manages subnet allocation and on-demand address pools (ODAP). The previous address-block, address-block-policy, and subnet commands now apply to CCM objects.
|
dhcp-interface
dns-interface
snmp-interface
|
Manages DHCP, DNS, and SNMP interfaces (see the "Network Interface Management" section).
|
dhcp-prefix
dhcp-link
lease6
|
Manages DHCPv6 prefixes, links, and leases (see the (see the "DHCPv6 Support" section).
|
dns-update-map
|
Manages DNS update maps (see the "DNS Enhancements" section).
|
dns-update-policy
|
Manages DNS update policies (see the "DNS Enhancements" section).
|
export key (keys)
export option-set
|
Exports TSIG keys and DNS option sets.
|
failover-pair
|
Manages DHCP failover server pairs (see the "DHCP Enhancements" section). (Note that the failover-pair name sync command synchronizes in the direction main server to backup server only.)
|
group
role
owner
region
|
Manages groups, roles, owners, and regions.
|
ha-dns-pair
|
Manages HA DNS server pairs (see the "DHCP Enhancements" section)
|
import keys
import option-set
|
Imports TSIG keys and DNS option sets.
|
option
option-set
option-datatype
|
Manages DHCP option and option set definitions along with their data types.
|
policy name create
clone=name
|
Allows cloning of DHCP policies. (You can also clone scope and zone templates.)
|
router
router-interface
router-type
|
Manages the Router Interface Configuration (RIC) server, interfaces, and router types.
|
scope-template
scope name applyTemplate
|
Manages scope templates (previously available only in the Web UI).
|
session set scope-edit-mode
session set zone-edit mode
|
Sets the scope and zone edit modes (staged or synchronous).
|
snmp
|
Manages the SNMP server.
|
trap-recipient
|
Sets SNMP trap recipients.
|
zone-dist
|
Manages zone distributions (see the "DNS Enhancements" section).
|
zone-template
zone name applyTemplate
|
Manages zone templates (previously available only in the Web UI).
|
Tip When a CLI create operation (such as scope name create arguments) fails, the CLI might not have removed this object from its internal cache when responding to a prior delete command and, thus, a subsequent create operation (with corrected arguments, for example) might return a 314 Duplicate object error. To resolve this problem: use a save command (which saves any pending changes and flushes the CLI's internal cache) then reissue the create operation.
Log File and Change Log Enhancements
Log files now include a new startup log and search functions in the Web UI. Network Registrar also consolidated change logs in the Web UI and added search functions.
Cluster Backup and Restore
Network Registrar 6.2 now includes a centralized backup and restore of cluster data in the Web UI with relevant functions. The CCM regional replica database was enhanced to store a complete representation of each local cluster's configuration. If a catastrophic hardware failure of a given server occurs, the CCM server can rebuild the previous configuration once you bring new hardware online. In this way, you can restore the previously installed local cluster version. Network Registrar does not support migration to a different version cluster.
Features Added in Network Registrar 6.2.1
Major changes made in Network Registrar 6.2.1 include:
•Red Hat 7.3 and RH ES 2.1 support was removed.
•The mcdshadow tool now does a fatal recovery and verification during a successful backup (CSCsd87059).
•The List Reservations, Add Reservation, and Edit Reservation pages are new to the Web UI (CSCsd82168). The regional cluster also provides for pushing reservations to local clusters (CSCsd82176).
•The reservation command was added to the CLI (CSCsd93395), with the following subcommands:
–reservation [vpn-id/]ipaddress create {macaddress | lookup-key} [-mac | -blob | -string] attribute=value
–reservation [vpn-id/]ipaddress delete
–reservation [vpn-id/]ipaddress get attribute
–reservation [vpn-id/]ipaddress show
–reservation list [[vpn-id/]ipaddress | -mac | -key]
•You can resynchronize between local reservations and scopes (CSCsd82177). You can also pull reservations from, and push them to, local clusters (CSCsd82176).
•Administrators can add, edit, and delete hosts without requiring read-only access to DNS zones and resource records (CSCsd02165).
•The dns getStats command displays statistics in read-only mode (CSCed33083).
•A product upgrade prompts you to archive the existing installation. It also now supports dns.ndb files larger than 2 GB (CSCeh06957).
•The cnr-exim tool exports DHCP failover pairs.
•Network Registrar deprecated the lease send-reservation and lease delete-reservation commands in the CLI in favor of synchronous scope edit mode (CSCsd67360).
•Network Registrar now handles lease renewal more effectively (CSCsc32239). Perhaps due to differences in clock times, a client might renew a lease earlier than at the expected T1 renewal time (typically half the lease time). If defer-lease-extensions was also enabled for the client, the DHCP server properly grants the remaining lease instead of extending the expiration. However, the server also changes the client's expected T1, even if the expiration was not extended. The result is that if the client repeatedly renewed earlier than T1, the server would keep giving the client shorter and shorter leases instead of extending its expiration. The server now applies a 60-second grace period to renewals (to accommodate clock drift), and does not change T1 if it does not extend the expiration.
•The DHCPv6 server supports permanent leases (CSCsd42231).
Features Added in Network Registrar 6.2.2
Network Registrar 6.2.2 adds no new major features. See the "Caveats" section for specifics on major bugs, fixed and open.
Features Added in Network Registrar 6.2.3
Network Registrar 6.2.3 adds support for the Cisco Global Site Selector (GSS) Load Balancer appliance and the Red Hat Enterprise Linux 4.0 operating system.
Configuring HA DNS on a GSS appliance
To successfully configure High Availability(HA) DNS on a GSS appliance, use the Network Registrar CLI to create a new dns-interface object, and use the public IP address and netmask of the appliance. Set the port to any port other than the standard 53; for example, 50053.
If you are trying to use the HA DNS feature and you encountering error, you might have a configuration problem between the main and backup servers. Check the log for a message such as:
01/04/2007 10:56:19 dns_startup Warning Server 0 20687 Neither the HA main [W.X.Y.Z] nor
the HA backup [A.B.C.D] IP Addresses match the configured addresses on this server.
01/04/2007 10:56:19 dns_startup Error Server 0 20054 Encountered error while trying to
start HA server. Disabling HA.
The Network Registrar DNS server attempts to compare the configured HA DNS server addresses against the list of network interfaces defined on the system. Since the Network Registrar DNS server is configured not to listen on the public network interface address on the GSS appliance, the DNS server fails while attempting to enable HA DNS.
To workaround this issue use the following nrcmd example to define a network interface object that does not affect the behavior of the Network Registrar DNS server functionality on a GSS appliance, but does allow HA DNS to operate properly. In the example, one of the HA DNS servers is located on a GSS appliance with an IP address of 192.168.1.5 with a network mask of 255.255.255.0. Adjust the values to fit the actual network configuration of the GSS appliance to be utilized. If the HA DNS failover partner is also located on a GSS appliance, similar steps must be taken on the other GSS machine.
Note Only the local GSS appliance network interface should be specified with the dns-interface commands.
Caution Do not create another dns-interface object on the local appliance for the remote HA DNS server, or HA DNS will not function properly.
nrcmd> dns-interface ha-dns create
100 Ok
ha-dns:
nrcmd> dns-interface ha-dns set address=192.168.1.5/24
100 Ok
nrcmd> dns-interface ha-dns set port=50053
Caveats
Table 4 describes the major fixed bugs in Network Registrar 6.2.3. Note also the installation changes described in the "Installation Changes in Network Registrar 6.2" section. Table 5 describes the major open bugs.
You can find the complete bug list in the CNR623_Bug_List.html file included with the release, or at the Network Registrar software download site:
http://www.cisco.com/pcgi-bin/Software/Tablebuild/tablebuild.pl/nr-eval
You must have a valid Cisco Connection Online (CCO) account to access the software download site.
Fixed Bugs in Network Registrar 6.2.3
Table 4 lists the major bugs fixed in Network Registrar 6.2.3.
Table 4 Major Bugs Fixed in Network Registrar 6.2.3
CDETS Number
|
Software Release
|
Fixed in 6.2.3
|
Condition/Symptom/Workaround
|
CSCse19248
|
Long-lived CNR management connections that become idle may be blocked by customer firewalls. For example, if a regional CNR installation communicates with local CNR installations, the connections between them may only be active occasionally. One symptom associated with this issue is delay while pushing configuration changes from regional to local CNR installations. The delay is caused when blocked connections timeout while waiting for responses.
If an operation fails because the management connection failed, it should be possible to retry the operation. That should cause the CCM server to re-establish a connection to the target CNR installation. It may also be necessary to coordinate the timeouts configured at the firewalls with the polling interval at CCM regional to ensure that communication takes place frequently enough to avoid the firewalls' timeouts.
|
CSCsg29386
|
Each time pull replica address space runs, the CCM server will leak memory used to store reservation lists maintained by each cluster. This may cause the server to fail by exhausting its available memory. Workaround: Periodically restart the service.
|
CSCsg29513
|
With over 1000 reservations, the reservation list command shows only the first 1000. Workaround: Use the Web UI, or the scope name listReservations command in the CLI.
|
CSCsg44141
|
If a regional cluster has never been synchronized, CCM will fail when it attempts to poll subnet utilization data for the cluster. Workaround: Be sure to establish correct connection credentials and synchronize the cluster. If connection to the cluster is not possible, remove the cluster from the configuration, or disable polling.
|
CSCsg51808
|
If two DNS servers are defined to be authoritative for the same zone, it is possible that one DNS server's in-memory cache could be corrupted by RRs from the other server in the same zone. This can happen if the DNS server attribute persist-mem-cache is disabled on the server which gets the corrupted in-memory cache. Workaround: Enable the persist-mem-cache server attribute.
|
CSCsg69485
|
Cache.db appears to grow without bounds. Name-set records in the in-memory cache with TTL's shorter than the cache_write_threshold may get persisted in the cache.db during shutdown. The cache_write_threshold is supposed to be the MIN/"floor" value of a TTL determining records eligible to be persisted. Workaround: There is no graceful work-around for this issue. You can do either of the following:
a. Stop the CNR service/daemon
b. Remove the CNR_data/dns/CACHE.db.
c. Start the CNR service/daemon.
OR
a. nrcmd> dns flushcache
b. nrcmd> dns reload
It should be noted that the latter approach will not actually shrink the cache.db file while the former will.
|
CSCsg71325
|
DDNS updates may fail with a NOTZONE error. These errors may result if the RR names in the update section are mixed or upper case. Workaround: To workaround this issue, ensure that RR names are sent in lower case.
|
CSCsg75949
|
An unsupported tool, cnr_zone_recovery, is included as part of the installation. Workaround: Avoid using this unsupported tool.
|
CSCsg83669
|
In complete or exact mode, regional failover objects are replaced by the local failover pair objects. The regional objects maintain poller attributes that are always unset by the pull operation, because these settings are not applicable on a local cluster. As a result, polling for lease history or subnet utilization data may indavertently be disabled. Workaround: Restore the original poller settings after performing the pull operation.
|
CSCsg86316
|
The primary DNS server could deadlock while receiving DDNS updates. This problem actually occurs when utilizing update-acls. Under certain race-conditions, more prevalent under DDNS loads, a DDNS update being REFUSED due to violation of an update-acl could cause the DNS server to deadlock. Workaround: REFUSED updates by violating an update-acl is typically caused by a misconfigured DHCP server or too exclusive update-acl. One could correct this configuration issue. A more error free workaround is to not utilize update-acl but update-policies. A simple update-policy can replace an update-acl by:
Creating the update-policy
nrcmd> update-policy update-policy-name create update-policy
nrcmd> update-policy update-policy-name rules add "grant IP addresses
wildcard * *"
Assigning the update-policy to the zone
nrcmd> zone name unset update-acl
nrcmd> zone name set update-policy-list=update-policy-name
|
CSCsg93100
|
The DNS server may incorrectly respond with a REFUSED error to a DDNS request that specifies RRs to delete and RRs to add even though the update client should not violate any deployed update-policies. This will only occur if the update request specifies a RR to delete where this RR does not exist. Workaround: Deploy update-policies that do not explicitly constrain on the RR type of owner.
|
CSCsg96347
|
On MS-Windows operating systems, when the DNS server is configured with resolution-exceptions, the server could fail during shutdown, logging an assertion failure. The problem stems from a memory allocation error during configuration of the resolution exception structures. The proper size is not allocated, causing a small amount of memory to be vulnerable to overwrite. The overwrite occurs when the last IP address of the particular resolution exception entry is used to in DNS query forwarding. The only memory corrupted is a single guard word used in the CNR memory system to detect buffer overruns, and the only result is the detection of this corrupt guard word when deallocating memory on server shutdown, stop, or reload.
Workaround: While this problem can be ignored in most installations, because the server agent will restart the process quickly, a workaround is to add one of the server's own addresses into each resolution exception IP address list. This creates a slightly larger allocation. The server will detect its own address as useless for forwarding and will fill less of the allocated memory, avoiding the overwrite of the guard word.
|
CSCsg98117
|
On a server with locally authoritative zones that have subzone delegations, if the DNS server's persist-mem-cache setting is disabled, subzone NS delegation and related subzone glue A records might be lost, preventing the server from providing a proper referral response.
This only affects servers hosting primary or secondary zones which themselves contain subzone delegations, and only when persist-mem-cache is disabled. For example, the server is a secondary for zone "example.com" and that zone contains a delegated subzone "sub.example.com" (indicated by NS records at the name "sub.example.com"), then the server may encounter this problem.
Workaround:The recommended workaround is to use separate caching and authoritative servers if the DNS server is being queried heavily enough for non-authoritative data and that mem-cache persistence must be disabled. Alternatively, enable persist-mem-cache if the non-authoritative query load on the server is such that cache persistence can be enabled without impacting performance.
|
CSCsg98318
|
When a subnet is manually created, it is not automatically deleted when all associated scopes are deleted. Instead, it must be manually deleted when it is determined that it is no longer needed. However, when the subnet is manually deleted, the CCM server does not attempt to remove IP ranges that may have been associated with related scopes. This may result in database inconsistencies that cause errors when trying to re-add related scopes. Workaround: Add the subnet . Then, using expert mode in the web UI, edit the subnet to delete the extra IP ranges.
|
CSCsg99647
|
The CCM server will leak memory each time the SyncZoneDistribution function is run. The memory leak is proportional to the number of zones in the configuration. Workaround: Periodically restart the server.
|
CSCsh04315
|
Entering a badly formatted option value string can cause the user interface or SDK program to fail when defining an option value. The following string, when entered for dhcpv4 option-122, causes the problem.
(3 (0;ro.blah.blurp)(6 BASIC.1)
Workaround: Correct the string being entered to have the right nesting of parentheses.
|
CSCsh04638
|
When processing a request to update local administrators from the regional CCM server, the local CCM server leaks memory proportional to the number of admins to be updated. Over time, the server may exhaust available memory, and fail. Workaround: Periodically restart the server to avoid a server failure.
|
CSCsh04638
|
When processing a request to update local administrators from the regional CCM server, the local CCM server leaks memory proportional to the number of admins to be updated. Over time, the server may exhaust available memory, and fail. Workaround: Periodically restart the server to avoid a server failure.
|
CSCsh12581
|
If a regional zone distribution is configured with a 6.1.x primary server, a version mismatch error is displayed when zone distribution runs. The error is reported for primary zone synchronization. Secondary zones are updated correctly for the list of secondary servers in the zone distribution.
Because zones assigned to a 6.1.x primary server cannot be edited on the regional server, and do not require synchronization, you can ignore this error. Only the secondary zone synchronization, which operates correctly, applies to this configuration.
Workaround: No workaround is required. The error message can be safely ignored.
|
CSCsh17619
|
A CCM Regional server could fail when converting a list of objects from a pre-6.2 local cluster, on Linux and/or Solaris deployments.
Workaround: None.
|
CSCsh44130
|
When the DHCP server experiences a timeout on an LDAP connection, such as when the LDAP server is unreachable on the network, it marks the connection as inactive, and should cease using that connection until it can attempt a reconnect, but instead continues to use the connection while there is sufficient client load on the DHCP server. This causes a primary LDAP server to continue to be used when instead the DHCP server should begin using the secondary LDAP server as soon as the timeouts are experienced. Disconnecting the network between the DHCP server and an LDAP server will cause the DHCP server to experience timeouts rather than LDAP errors, and if there is sufficient (fairly heavy) client load, the DHCP server continues to use the connections that just timed out, instead of trying other connections. Workaround: There is no workaround. If the client load is light enough, the DHCP server does correctly mark the connections.
|
Open Bugs in Network Registrar 6.2.3
Table 5 lists the major open bugs in Network Registrar 6.2.3.
Table 5 Major Open Bugs in Network Registrar 6.2.3
CDETS Number
|
Software Release
|
Open in 6.2.3
|
Condition/Symptom/Workaround
|
CSCsg88331
|
If using synchronous scope-edit-mode to modify scopes that have allocate-first-available enabled (or enabling allocate-first-available on a scope), (DHCP server will fail to lease to new clients.) Workaround: Executing a CLI scope name listleases corrects the problem as this causes the available leases bitmap used by allocate-first-available to be rebuilt.
|
CSCsg88812
|
When viewing the list of leases for a DHCPv6 client, clicking one of the leases may fail to bring up the normal lease view for that lease. this is only an issue if there are multiple prefixes on a link. Workaround: Use alternate methods to view the lease (such as view that Prefix's list of leases).
|
CSCsh06019
|
RRs disappear prematurely from DNS (when scavenging is enabled on a zone). DDNS updates attempt to add an RR do not refresh the existing RR's timestamp. These type of updates should refresh the name-set timestamp. Workaround: the same RR refresh the timestamp on the name-set. Alternatively, a prerequisite only DDNS update also refreshes the name-set.
|
CSCsh23520
|
When connected to a regional cluster, nrcmd does not support the VPN command and returns a "connected to wrong cluster type" error. Workaround: Use the regional Web UI to add, modify, or remove VPNs.
|
Documentation Bugs in Network Registrar 6.2.3
Table 6 lists the documentation bugs in Network Registrar 6.2.3.
Table 6 Documentation Bugs in Network Registrar 6.2.3
CDETS Number
|
Software Release
|
6.2.3
|
Documentation Bug
|
CSCsg20751
|
The description comparing LDAP server round-robin and failover mode, in the "Configuring DHCP-Server-to-LDAP Client Queries" section of Chapter 23 in the User's Guide, will be corrected in future documentation to read:
"LDAP failover mode actually performs preferential load balancing. The DHCP server assesses the LDAP connection and error states and how fast the LDAP server responds. In an optimal state, the DHCP server uses the LDAP server with the highest assigned preference (lowest preference number). In a less-than-optimal state, the DHCP server uses the next LDAP server of lower preference (increasing preference number). If the preference values are the same (or not set), the DHCP server reverts to round-robin mode with the LDAP servers."
|
Open Source License Acknowledgements
The following acknowledgements pertain to this software license.
OpenSSL/Open SSL Project
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com).
This product includes software written by Tim Hudson (tjh@cryptsoft.com).
License Issues
The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact openssl-core@openssl.org.
OpenSSL License:
© 1998-2007 The OpenSSL Project. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact openssl-core@openssl.org.
5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment:
"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)"
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT "AS IS"' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson (tjh@cryptsoft.com).
Original SSLeay License:
© 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved.
This package is an SSL implementation written by Eric Young (eay@cryptsoft.com).
The implementation was written so as to conform with Netscapes SSL.
This library is free for commercial and non-commercial use as long as the following conditions are adhered to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com).
Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:
"This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)".
The word `cryptographic' can be left out if the routines from the library being used are not cryptography-related.
4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: "This product includes software written by Tim Hudson (tjh@cryptsoft.com)".
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution license [including the GNU Public License].
Obtaining Documentation, Obtaining Support, and Security Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, 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
THIS PRODUCT INCLUDES THE FOLLOWING THIRD-PARTY LICENSED SOFTWARE:
This product is distributed with Apache Tomcat 4.0.1 and Jakarta ORO v. 2.1.6 software developed by the Apache Software Foundation.
Copyright © 2000 The Apache Software Foundation. All rights reserved.
The list of conditions and disclaimer for the use of this software are included in the /docs/licenses directory of the installation directory.
This product is distributed with com.oreilly.servlet class library software.
Copyright © 2001-2002 by Jason Hunter. All rights reserved.
The list of conditions and disclaimer for the use of this software are included in the /docs/licenses directory of the installation directory.
This product is distributed with the Tool Command Language (Tcl) software as part of the standard Tcl/Tk distribution.
Copyright © The Regents of the University of California, Sun Microsystems, Inc., Scriptics Corporation, and other parties.
The terms and agreement for the use of this software are included in the /docs/licenses directory of the installation directory.
This product is distributed with the gtar 1.13 software.
Copyright © 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
The terms and agreement for the use of this software are included in the /docs/licenses directory of the installation directory.
This product is distributed with Henry Spencer's regular expression library software, rxspencer-alpha 3.8.
Copyright © 1992, 1993, 1994, 1997 Henry Spencer. All rights reserved.
This software is not subject to any license of the American Telephone and Telegraph Company or of the Regents of the University of California.
The restrictions on the use of this software are included in the /docs/licenses directory of the installation directory.
Copyright © 1995 - 2007 Cisco Systems, Inc. All rights reserved.
