text:
Table Of Contents
Release Notes for Cisco Network Registrar 184.108.40.206
CNR Communications Security Option
Software and Standards Compatibility
Installation and Upgrade Notes
Installing on Linux or Solaris
DHCP Option Definitions List Enhancements
New and Changed Features in CNR 7.1.1
Changes to Dynamic Lease Notification
Obtaining Documentation and Submitting a Service Request
Release Notes for Cisco Network Registrar 188.8.131.52
Revised: September 01, 2010
This release notes is for Cisco Network Registrar (CNR) release 220.127.116.11. This document describes system requirements, installation and upgrade notes, new features and implementation, and caveats.
This release notes covers the following topics:
•Software and Standards Compatibility
•Installation and Upgrade Notes
•Obtaining Documentation and Submitting a Service Request
This release of CNR resolves a number of customer-reported issues with earlier releases.
Before You Begin
Review the following sections before installing CNR 220.127.116.11:
•CNR Communications Security Option
Note If you are migrating to CNR 22.214.171.124 from an earlier version of CNR, you must review the Release Notes for the releases that occurred in between, to fully understand all the changes.
System Requirements
Review these system requirements before installing the CNR 184.108.40.206 software:
•Java—You must have the Java Runtime Environment (JRE) 5.0 (1.5.0_06) or later, or the equivalent Java Development Kit (JDK), installed on your system. (The JRE is available from Sun Microsystems on its website.)
•Operating system—We recommend that your CNR machine run on the Windows, Solaris, or Linux operating systems as described in Table 1. CNR must run on 32-bit or 64-bit operating systems.
Note CNR applications are 32-bit applications and the system should support 32-bit applications (Java JRE/JDK, OpenLDAP library (for RH)).
•User interfaces—CNR currently includes two user interfaces: a web UI and a command-line interface (CLI):
–Web UI—Runs on a minimum of Microsoft Internet Explorer 6.0 (Service Pack 2) and 7.0, Mozilla Firefox 2.0 and 3.0, and requires JRE 5.0 (1.5.0_06).
–CLI—Runs in a Windows, Solaris, or Linux command window.
Tip Include a network time service (such as NTP) in your configuration to avoid time differences between the local and regional clusters, so that aggregated data appears consistently at the regional server.
Table 1 Cisco Network Registrar System Recommendations
Component Operating System Solaris Linux Windows
OS version1
Solaris 102
•Red Hat Enterprise Linux ES 4.03
•Red Hat Enterprise Linux 5.03
Windows Server 20033
Disk space4
2 x 73/146 SAS5 drives
With basic DHCP and optimal hardware configuration:
SATA6 drives with 7500 RPM drive > 500 leases/second
SAS drives with 15K RPM drive > 1000 leases/second
(Recommended hard drive 146 GB)
4 GB (small networks), 8 GB (average networks), or 16 GB (large networks)
1 CNR must run on 32-bit or 64-bit operating systems.
2 CNR 184.108.40.206 supports 128-KB block sizes in the Solaris 10 ZFS.
3 CNR now supports running in a VMWARE (ESX Server 3.5) environment for Red Hat Enterprise Linux ES 4.0, 5.0, and Windows Server 2003.
4 Higher I/O bandwidth usually results in higher average leases per second.
5 Serial Attached SCSI.
6 Serial Advanced Technology Attachment (Serial ATA).
7 Faster CPU and more memory typically result in higher peak leases per second.
Note CNR no longer supports Red Hat 3.0, and Solaris 8 and 9. If you are running one of these operating systems, you must upgrade to Red Hat 4.0, or Solaris 10 before installing or upgrading CNR 184.108.40.206. (See the "Installation and Upgrade Notes" section.)
CNR Communications Security Option
You need to upgrade the security option to Network Registrar Communications Security Option release 2.2 for CNR 126.96.36.199.
Software and Standards Compatibility
This release of CNR complies with the applicable Request for Comments (RFCs), protocols, standards, and Internet Engineering Task Force (IETF) drafts of earlier releases.
Note CNR 220.127.116.11 is compatible with Cisco Broadband Access Center 22.214.171.124 and 188.8.131.52.
CNR 184.108.40.206 protocol servers interoperate with CNR versions 7.0, 6.3.x, and 6.2.x. CNR 184.108.40.206 will not support interoperability with versions earlier than 6.2.x.
•CNR 220.127.116.11 DHCPv4 failover servers interoperate with CNR 7.0.x, 6.3.x, and 6.2.x failover servers.
•By the nature of the EDNS0 protocol, CNR 184.108.40.206 DNS servers interoperate with earlier versions of CNR DNS (and 3rd party DNS vendors). EDNS0 defines the interoperability with DNS servers that do not support EDNS0; CNR 22.214.171.124 DNS adheres to the RFC and consequently interoperates with earlier versions of CNR.
•CNR 184.108.40.206 HA DNS servers interoperate with CNR 7.0.x, 6.3.x, and 6.2.x versions.
•CNR 18.104.22.168 DDNSv6 interoperates only with CNR 7.0 and CNR 7.1 DNS servers—because of the usage of the DHCID RRs.
Installation and Upgrade Notes
Review the following notes before installing CNR 22.214.171.124 or upgrading from a previous version. For full installation and upgrade procedures, see the Cisco Network Registrar Installation Guide 7.1.
This section covers:
General Installation
•CNR now implements the FLEXlm licensing mechanism; therefore, you must obtain a FLEXlm license file.
The installation program prompts you for the license file. You can defer submitting a license file during the upgrade, but you must provide one when you invoke the web UI or the CLI. License keys obtained for prior versions of CNR no longer function.
Note If CNR has to be installed via a Remote Desktop Connection on a Windows Server, you will not be able to enter the license information during the installation process. CNR will reject the license as invalid. You have to skip the license information steps (select an appropriate option to continue the installation process without a license), and then add the license using either the Web UI or nrcmd, after the installation has completed.
•The CNR installation program for Windows does not try to modify ACLs to restrict access to installed files and directories. If you want to restrict access to these files and directories, use the native Microsoft utilities cacls and icacls to manually change file and directory permissions. For more information, see the Cisco Network Registrar Installation Guide 7.1.
•Windows, Solaris, and Linux installations occur through:
–Windows—Windows-based InstallShield setup program.
–Solaris—The pkgadd command.
–Linux—The install_cnr script that uses RPM Package Manager (RPM).
•On Windows, close all currently running applications, including any antivirus software.
•On Windows, ensure that you uncheck the Dr. Watson Visual Notification check box. If checked, this option prevents the servers from restarting automatically if a failure occurs until you respond to a pop-up dialog box. The Visual Notification check box in Dr. Watson is checked by default.
Execute C:\WINNT\system32\DRWTSN32.exe, uncheck the Visual Notification check box, and click OK. (You can perform this step after installation.)
•Due to changes in the behavior of the Windows installer, you are now required to use a new silent installation response file to successfully perform unattended installations of CNR. The installer will fail to perform unattended installations properly if you use a response file that was generated for CNR 7.0.
•To avoid losing the most recent log entries when the Application Event Log is full in the Windows Event Viewer, check the Overwrite Events as Needed check box in Event Log Settings for the Application Log. If the installation process detects that this option is not checked, it displays a warning message advising corrective action.
•Because CNR maintains lock files in the \Temp directory on Windows and the /tmp directory on Solaris or Linux, do not delete these directories when CNR is running.
•You cannot run the CNR DNS, DHCP, or TFTP servers concurrently with any other DNS, DHCP, and TFTP servers. In many Windows 2003 server systems, these services are enabled and running by default. If the CNR installation process detects that a conflict exists, it displays a warning message. Before installing CNR, take the appropriate action to disable the conflicting servers.
•CNR includes a list of informational, activity, warning, and error messages that it logs during certain operating conditions. Obtain this list in HTML files for each component as links from a MessageIdIndex.html file, which, by default, is in:
–Windows—C:\Program Files\Network Registrar\{Local | Regional}\docs\msgid\
–Solaris and Linux—/opt/nwreg2/{local | regional}/docs/msgid/MessageIdIndex.html
Red Hat Linux Installation
Installing CNR on Red Hat Linux requires that the 32-bit OpenLDAP library be installed; otherwise, the DHCP server may fail to start.
To verify if openldap is installed, enter:
# rpm -ql openldap | more
If the openldap package is installed, the LDAP library details will appear; otherwise the following error message appears:
package openldap is not installed
To install the openldap package, enter:
# yum install compat-openldap.i386
Upgrade Considerations
CNR 22.214.171.124 supports upgrades from CNR versions 6.2 and later. When you install the software, the installation program automatically detects an existing version and upgrades the software to the latest version. The program first prompts you to archive existing CNR data. If the program encounters errors during the upgrade, it restores the software to the earlier release.
Note If you are from a version earlier than CNR 184.108.40.206, review the Release Notes for any intervening CNR versions before upgrading, to fully understand all of the changes incorporated in this release. The CNR 188.8.131.52 Release Notes document only the changes since 7.1.
CNR no longer supports the Red Hat 3.0 and Solaris 8 and 9 operating systems. Back up your CNR data and upgrade your operating system before installing this latest release. (See Table 1 for currently supported operating systems.)
During an upgrade, CNR displays any pre-existing HTTPS configuration defaults for the keystore filename and password to enable a secure connection for web UI logins (CSCee14992). If you have enabled HTTPS, and are unaware of the keystore filename and password at the time of the upgrade, you can preserve HTTPS connectivity during the upgrade, and re-enter the defaults when prompted.
Note The default keystore filename and password appear only if you are upgrading from CNR 6.3.1 or later versions, or reinstalling the CNR 126.96.36.199 version.
To upgrade to CNR 184.108.40.206:
Step 1 Ensure that your environment meets the current system requirements. (See the "System Requirements" section.)
Step 2 Use the currently installed release to complete any configuration changes in progress, so that the existing database is consistent before you perform the upgrade.
Step 3 Ensure that no pending database tasks result from recent edits. You can confirm that the task lists are empty by viewing the CCM and MCD Tasks pages under the Administration menu in the web UI. Wait until both lists are empty before proceeding with the update.
Step 4 Stop the CNR server agent and back up the existing database:
–if local—net stop nwreglocal
–if regional—net stop nwregregion
•Solaris and Linux
–if local—/etc/init.d/nwreglocal stop
–if regional—/etc/init.d/nwregregion stop
Step 5 Copy the data directory in your installation path to a .zip file.
Step 6 Upgrade your operating system, if necessary.
Step 7 Upgrade CNR.
Note We recommend you to upgrade the regional cluster before upgrading any local clusters, because an older version of a regional cluster cannot connect to newer local clusters (CSCsm61420).
Note For upgrades from CNR version 6.2 of DHCP failover servers, upgrade the main server before the backup server, because mixed-mode failover synchronization back to version 6.1 (which is needed for the period until the backup is also upgraded) is supported only from main to backup.
If the upgrade fails for any reason, you can revert to the earlier CNR version. The CNR installation program provides the capability of archiving the existing product configuration and data when upgrading to a newer version of the product. If you chose this option, and the upgrade process fails, use the following procedure to revert to the earlier product version and configuration:
Caution To complete this process, you must have access to the product installer and license key or license file for the earlier CNR version. Any attempt to proceed otherwise may destabilize the product.
If the installer had successfully performed the upgrade but you want to roll back to the earlier version at some later point, this procedure can result in network destabilization and data loss; for example, you will lose updates made to the CNR database after the upgrade, including DHCP lease data and DNS dynamic updates.
a. Verify that the archive directory (cnr_archive.tar) that you specified during the upgrade process exists and is valid. These examples assume the default archive location provided during installation. Ensure that the path to the cnr_archive.tar file reflects the value of the archive directory that you specified during installation. If you are using:
•Windows—C:\Program Files\Network Registrar\{Local.sav | Regional.sav}
•Solaris and Linux—/opt/nwreg2/{local.sav | regional.sav}
b. Uninstall CNR using the procedure described in the Cisco Network Registrar Installation Guide.
c. Other than the contents of the specified archive directory, delete any remaining files and directories in the CNR installation paths.
d. Reinstall the original version of CNR. Ensure that you follow the reinstallation procedure described in the Cisco Network Registrar Installation Guide that is specific to the original product version.
e. After the installation ends successfully, stop the CNR server agent:
•if local—net stop nwreglocal
•if regional—net stop nwregregion
–Solaris and Linux
•if local—/etc/init.d/nwreglocal stop
•if regional—/etc/init.d/nwregregion stop
f. Delete the contents of the CNR install-path/data subdirectory.
g. Extract the contents of the backup file to the newly reinstalled version of CNR. To do this:
1. Change to the root directory of the filesystem. On Windows, this directory would be the base drive (such as C:\); on Solaris and Linux, it would be /.
2. Using the fully qualified path to the archive directory containing the cnr_archive.tar file, extract the archive. These examples assume the default archive location provided during installation. Ensure that the paths to the tar executable and cnr_archive.tar file reflect the value of the archive directory that you specified during installation.
•Windows—"C:\Program Files\Network Registrar\{Local.sav | Regional.sav}\tar.exe"
xf "//C/Program Files/Network Registrar/{Local.sav | Regional.sav}/cnr_archive.tar"
Note Running the tar executable requires that you change the directory delimiters for the tar filepath to forward slashes (/) and that the drive letter be specified using double slashes (//) without the colon (:).
•Solaris and Linux—/opt/nwreg2/{local.sav | regional.sav}/tar -xf /opt/nwreg2/
{local.sav | regional.sav}/cnr_archive.tar
h. Start the CNR server agent:
•if local—net start nwreglocal
•if regional—net start nwregregion
–Solaris and Linux
•if local—/etc/init.d/nwreglocal start
•if regional—/etc/init.d/nwregregion start
i. Verify if the previous configuration, including scopes and zones, is intact.
Moving CNR to a New Machine
You might want to move an existing CNR installation to a new machine. By following this procedure, you can preserve your original data on the old machine if a problem arises during installation on the new machine (CSCso06297):
Step 1 Ensure that the new machine runs the same operating system (Windows, Solaris, or Red Hat Linux) as the old machine.
Step 2 Stop the server agent on the old machine:
–if local—net stop nwreglocal
–if regional—net stop nwregregion
•Solaris and Linux
–if local—/etc/init.d/nwreglocal stop
–if regional—/etc/init.d/nwregregion stop
Step 3 Zip the data directory on the old machine.
Step 4 Copy the .zip file to the same location on the new machine.
Step 5 Install CNR on the new machine (on Solaris and Linux, use the -a option for an upgrade; for example: pkgadd -a install-path/solaris/nwreg2/install/cnradmin -d install-path/solaris nwreg2). The installation will detect an upgrade and will do so based on the copied data.
Step 6 Ensure that any IP address references in CNR are updated to reflect the IP address of the new server.
The data from the old machine is now migrated to the new machine.
About CNR SDK
This section documents how to install the CNR SDK and details the compatibility considerations. The following are the topics covered in this section:
Installing CNR SDK
This section documents how to install the CNR SDK on the Linux, Solaris, and Windows platforms. Before installing the SDK, ensure that you have Java Runtime Environment (JRE) 5.0 (1.5.0_06) or later, or the equivalent Java Development Kit (JDK), installed on your system.
Installing on Linux or Solaris
To install the CNR SDK on a Linux or Solaris platform:
Step 1 Extract the contents of the distribution .tar file.
a. Create the SDK directory:
% mkdir /cnr-sdk
b. Change to the directory that you just created and extract the .tar file contents:
% cd /cnr-sdk
% tar xvf sdk_tar_file_location/cnrsdk.tar
Step 2 Export your LD_LIBRARY_PATH and CLASSPATH environment variable:
% export LD_LIBRARY_PATH=/cnr-sdk/lib
% export CLASSPATH=/cnr-sdk/classes/cnrsdk.jar:.
Installing on Windows
To install the CNR SDK on a Windows platform:
Step 1 Extract the contents of the distribution .tar file.
a. Create the SDK directory:
> md c:\cnr-sdk
b. Change to the directory that you just created and extract the .zip file contents:
> c:
> cd \cnr-sdk
> tar xvf sdk_tar_file_location\cnrsdk.tar
You may optionally use Winzip to extract cnrsdk.tar to the C:\cnr-sdk directory.
Step 2 Set your PATH and CLASSPATH variables:
> set PATH=%PATH%;c:\cnr-sdk\lib
> set CLASSPATH=c:\cnr-sdk\classes\cnrsdk.jar;.
Testing Your Installation
On Linux or Solaris, the following test program verifies that you have set your PATH or LD_LIBRARY_PATH correctly:
% java -jar /cnr-sdk/classes/cnrsdk.jar
On Windows, the following test program verifies that you have set your CLASSPATH correctly:
> java -jar c:\cnr-sdk\classes\cnrsdk.jar
Compatibility Considerations
For Java SDK client code developed with an earlier version of the SDK, you can simply recompile most code with the latest JAR file to connect to an upgraded server.
But in cases where the client code directly manipulates reservation lists in scopes or prefixes, changes will be required. These changes are required because the embedded reservation lists in both scopes and prefixes are no longer used. Individual reservations are now stored separately and reference the parent scope or prefix by name.
The new design provides the following benefits:
•Reservation edits (add/modify/delete) do not require a scope or prefix edit.
•Reservations can be indexed directly to allow quick search and retrieval.
•Edits to scopes or prefixes with a large number of reservations no longer result in large scope or prefix change entry logs.
No changes are required for client code that adds or removes reservations using the addReservation or removeReservation methods. However, these methods are now deprecated because the edit functionality has been replaced and extended by the general addObject, modifyObject, removeObject, addObjectList, modifyObjectList, and removeObjectList methods.
New and Changed Features
This following are the topics covered in this section:
•New and Changed Features in CNR 7.1.1
New Features in CNR 7.1
This section briefly describes the following new and modified features in the CNR 7.1 release:
•DHCP Option Definitions List Enhancements
Dynamic Lease Notification
With Dynamic Lease Notification, customers can have external systems notified whenever CNR issues a lease. This feature is used in Lawful Intercept solutions and long-term storage of customer data for Regulatory Compliance and Operational Efficiency.
For more details, please see the "Managing Leases" chapter of the User Guide for Cisco Network Registrar.
Discriminating Rate-Limiter
The patent-pending Discriminating Rate-Limiter reduces downtime after outage in very large service networks by restricting the rate of DISCOVER requests while still honoring all RENEW requests.
For more details, please see the Table 23-1 in the "Advanced DHCP Server Properties" chapter of the User Guide for Cisco Network Registrar.
Performance Improvements
Protocol Implementation improvements that enhance the query performance of the DNS server. The improvements to the DNS vulnerability fix enhances the query performance. The DHCP reservation system improvements enhances the reliability and performance of this mechanism.
Dashboard Improvements
CNR 7.1 provides the end-users the ability to select and persist the dashboard default chart types.
User Management Improvements
The fine-grained role-based system includes the ability to define the administrative roles at the scope/prefix and link levels of DHCP. Also admin password changes are now synched between regional and local clusters.
EDNS0 Support
Added support in the DNS implementation for EDNS0 as defined in RFC 2671 (not including the request forwarding).
DNS Blackhole Support
The DNS server can now be configured to avoid the interaction with misbehaving and/or unresponsive remote name-servers and clients.
For more details, please see the "Handling Malicious DNS Clients and Unresponsive Nameservers" section of the "Managing DNS Server Properties" chapter of the User Guide for Cisco Network Registrar.
New Platform Support
CNR 7.1 is optimized to leverage the multi-core processors. It is certified to run on 64 bit variants of the supported OS versions and Red Hat 5.0 was added to the list of supported OS's.
DHCP Option Definitions List Enhancements
The DHCP option definitions list has been updated to support the following RFCs, which does not require any modification to the DHCP server behavior,
•RFC5192 is the PANA option, which was not an RFC on CNR 7.0 release
•RFC5223 is the LOST server option
•Cisco Vendor Specific Option definitions is included in the dhcp-cisco-config and dhcp6-cisco-config option definitions sets
For more details about the new software features added, please see the User Guide for Cisco Network Registrar.
New and Changed Features in CNR 7.1.1
This following are the topics covered in this section:
•Changes to Dynamic Lease Notification
VMWARE Support
CNR now supports running in a VMWARE (ESX Server 3.5) environment for Linux RedHat 4.0, Linux 5.0, and Windows Server 2003.
Changes to Dynamic Lease Notification
The dynamic lease notification feature is modified to include the following:
•Changing the processing of active leasequery sessions on reload in order to reduce or remove the necessity for the dynamic lease notification client to issue a bulk leasequery when the server returns to service. The detailed description is given in the "Avoiding Bulk Leasequery for Active Leasequery Client After DHCP Reload" section.
•Allowing extensions to control the sending of active leasequery packet to the dynamic lease notification client. The detailed description is given in the "Using Extensions to Control Active Leasequery Notifications" section.
Avoiding Bulk Leasequery for Active Leasequery Client After DHCP Reload
In CNR 7.1, a DHCP server reload required an active leasequery client to issue a bulk leasequery to capture any changes between the time the server was shutting down and the client reconnected to the server after the server restarted.
While a client can still do this, the DHCP server is enhanced as follows to reduce the need for this bulk leasequery.
•On server shutdown or reload, the DHCP server examines the queue of leases which it has queued up for each active leasequery connection. If the queue is empty, it means that all the notifications for that connection have been sent, at least into the TCP connection and are not waiting on the DHCP server. So, if the queue is empty and the TCP connection is not blocked, the DHCP server will send a DHCPLEASEQUERYSTATUS message with a status-code of QueryTerminated. This DHCPLEASEQUERYSTATUS message includes a base-time of the server's shutdown time. The client, when it reconnects to the server, should then issue an active leasequery request with a query-start-time of this base-time.
If these conditions are not met, the connection is closed by the DHCP server as before (no DHCPLEASEQUERYSTATUS message is sent). In this case, the client should use a query-start-time in the active leasequery request when it reconnects of the last base-time it received from the server minus 10 seconds.
•On server startup, the server initiates saving the leases that it may need to send to active leasequery connections even if there are no active leasequery connections. It will save these leases for the backlog time (120 seconds by default).
And, if an active leasequery request is received within this backlog time with a query-start-time that is within a few seconds of the server's saved shutdown time, the server will assume that the active leasequery client is resuming a previous active leasequery and will initiate the active leasequery operation and no bulk leasequery is needed. If these conditions are not met, the DHCP server will notify the client that it has potentially missed notifications and needs to perform a bulk leasequery.
The sample Dynamic Lease Notification Client has also been modified to make use of the DHCP server enhancement. In particular, it saves the base-time received in a DHCPLEASEQUERYSTATUS message with the status-code of QueryTerminated and will use this base-time as the query-start-time when it successfully reconnects to the DHCP server. And, if that reconnect happens within the backlog time after the DHCP server has restarted, no bulk leasequery will be necessary.
Using Extensions to Control Active Leasequery Notifications
The server determines whether a lease is queued for active leasequery notifications based on the dhcp-listener's leasequery-send-all attribute. If enabled, the DHCP server always sends a notification to an active leasequery client; if disabled (or unset), the DHCP server only sends notifications which are necessary to maintain accurate state in the active leasequery client.
To allow customer written extensions to control the sending of a lease (such as only on specific state changes), a new data item, active-leasequery-control, has been added to both the request and response dictionaries. These data items have three values:
•0—unspecified (the server determines whether to send the notification)
•1—send (the server will send the notification)
•2—don't send (the server will not send the notification)
The active-leasequery-control data item is initialized as 0, unspecified.
Note These data items may be written and read, but the value that is read is only the value that might have been previously written. These data items can force the DHCP server to take specific actions after being written, but reading them without previously writing them will always return 0, unspecified. These data items will not let you determine the choices that the DHCP server will make when it comes to deciding whether or not to send a message to an active leasequery client concerning the changes (if any) made to a lease that is being processed. Thus, these data items are technically read/write, but reading them will only allow you to determine what you may have previously written into them.
These data items are examined (the response dictionary is examined first, then the request) when the lease is written to the internal lease state database as that is when the lease is also queued for active leasequery notification. This occurs after the check-lease-acceptable and lease-state-change extensions points, but prior to the pre-packet-encode extension point. Therefore, any changes made to these attributes at or after the pre-packet-encode extension point will be ignored.
Whether a lease is queued for active leasequery notification is determined as follows:
Response's active-leasequery-control Request's active-leasequery-control Leasequery-send-all Action
False or unset
Conditional (see leasequery-send-all attribute description)
1— send
2—don't send
Not Sent
1— send
2—don't send
Not Sent
Note that the response's and request's active-leasequery-control is examined prior to any examination of the leasequery-send-all attribute. Thus, if either of these dictionary data items has a value other than unspecified, that value will override any value configured in the leasequery-send-all attribute of the dhcp listener.
Note You cannot control the sending of active leasequery information by writing a single extension that runs only at the lease-state-change extension point, because that extension point is only called when there is a change in state of a lease. Lease state changes may not occur when you might expect them to. For example, if a lease is leased, and that same client goes through a DISCOVER/OFFER/REQUEST/ACK cycle, the lease-state-change extension point is not called since the lease does not actually go through a state change internally; it remains leased throughout the cycle. Thus, to gain absolute control over the transmission of information to active leasequery clients, you will probably need to initialize the active-leasequery-control attribute in request processing, and then possibly alter it or override it by operating on the response dictionary value at the lease-state-change extension point.
New Features in CNR 22.214.171.124
There are no new features added for this release. For details about the list of resolved and known bugs of this release, see Caveats.
Limitations and Restrictions
This section describes limitations and restrictions you might encounter when using CNR 22.214.171.124.
•The Regional Pull Replica Address Space fails when reservations are being pulled for new failover-pair objects. This problem occurs only if there is a new failover-pair and one or more reservations associated with that failover-pair. To workaround this issue, repeat the operation twice—first checking Omit Reservations and then without checking Omit Reservations. After the failover-pairs have been pulled, subsequent pull replica address space operations will work correctly.
•In situations where a DHCPv6 server supports clients with multiple leases, the demand on server memory increases. DHCPv4 supports only one lease per client, while DHCPv6 supports multiple leases. Therefore, a DHCPv6 server cannot support as many leases (clients) as can the same server running DHCPv4. For example, one DHCPv6 client might require 2,500 bytes of space compared to 1,000 bytes per DHCPv4 client. This means that a machine that would support one million DHCPv4 clients supports only 400,000 DHCPv6 clients. We recommend that you allow three times the memory for DHCPv6 clients as you would for DHCPv4.
You must:
–Be aware of how many prefixes per link are configured. If the configuration has two prefixes on a link, then with default configuration parameters, you have to cut in half the number of clients.
–Use care if you enable inhibit-all-renews. When enabled, each client would use at least two leases, and perhaps three, depending on the grace and affinity times per prefix.
You can find the complete list of resolved and known bugs in the cnr_7_1_2_1-buglist.pdf file included with the release. Refer to this list especially for information about fixes to customer-reported issues.
Documentation Errata
In the README.txt for Cisco Network Registrar 188.8.131.52, read the occurrences of the version CNR 7.1.2 as CNR 18.104.22.168.
In the documentation set provided within the CD for Cisco Network Registrar 22.214.171.124, read the title "Release Notes for Cisco Network Registrar 7.1.2" as "Release Notes for Cisco Network Registrar 184.108.40.206", and read all the occurrences of CNR 7.1.2 within the document as CNR 220.127.116.11.
See Cisco.com for the most up-to-date version of the Release Notes for Cisco Network Registrar 18.104.22.168.
Related Documentation
See the following documents for important information about installing, configuring, and managing CNR:
Table 2 Related Documentation
Document Title Available Formats
Documentation Guide for Cisco Network Registrar 7.1
•PDF on the product CD-ROM
•On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/roadmap/guide/CNR71DocGuide.html
User Guide for Cisco Network Registrar 7.1
•PDF on the product CD-ROM
•On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/user/guide/cnr71book.html
Installation Guide for Cisco Network Registrar 7.1
•PDF on the product CD-ROM
•On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/installation/guide/CNR71Install.html
Quick Start Guide for Cisco Network Registrar 7.1
•PDF on the product CD-ROM
•On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/user/guide/cnr71_qs_book.html
CLI Reference Guide for Cisco Network Registrar 7.1
•As an HTML document that you can view in your web browser when you install the software. The document is available at All Programs > Network Registrar > Network Registrar CLI Reference Guide.
•On Cisco.com: http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/7.1/command/reference/CLIReferenceGuide.pdf
Release Notes for Cisco Network Registrar 188.8.131.52 (This document)
•It is available on Cisco.com:
Online Help
•Choose Help > Help Contents in the main menu to view the entire help contents
The following notices pertain to this software license.
OpenSSL/Open SSL Project
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).
This product includes cryptographic software written by Eric Young (email@example.com).
This product includes software written by Tim Hudson (firstname.lastname@example.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 firstname.lastname@example.com.
OpenSSL License:
Copyright © 1998-2007 The OpenSSL Project. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)".
4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact email@example.com.
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 (firstname.lastname@example.com). This product includes software written by Tim Hudson (email@example.com).
Original SSLeay License:
Copyright © 1995-1998 Eric Young (email@example.com). All rights reserved.
This package is an SSL implementation written by Eric Young (email@example.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 (firstname.lastname@example.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 (firstname.lastname@example.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 (email@example.com)".
The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution license [including the GNU Public License].
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2010 Cisco Systems, Inc. All rights reserved.


text:
UEFA president Michel Platini is considering an appeal to increase the one-match spectator ban and £65,000 fine imposed on Serbia for racist abuse and violence towards England Under-21 players.
The sanction, imposed last night by UEFA's independent control and disciplinary panel following the ugly scenes in Krusevac in October, has been criticised for being too lenient.
UEFA sources said Platini has taken note of the sanction and will make a final decision once he has read the full file on his return from the Club World Cup in Japan next week.
The Football Association criticised the sanction and will appeal against the two-match and one-match bans for Steven Caulker and Tom Ince respectively.
FA general secretary Alex Horne said: "We are disappointed with the sanctions levied by UEFA with regards to the racist behaviour displayed towards England's players.
"Racism is unacceptable in any form and should play no part in football. The scenes were deplorable and we do not believe the sanction sends a strong enough message."
The FA reported the racist abuse to UEFA plus a number of other incidents. Full-back Danny Rose, who was dismissed after the final whistle for kicking the ball away in anger, complained he had been subjected to monkey chants throughout the match and as he left the pitch.
Lord Herman Ouseley, chairman of Kick It Out, slammed the sanction and said: "Again we haven't seen decisive action from UEFA."
- More about:
- Michel Platini

subset: commoncrawl


text:
Belligerent V-neck T-shirt s are an Idakoos specialtiy! Idakoos has many things to offer. Whether you want to get a Belligerent V-neck Tee for a special occasion, give a Belligerent T-Shirt as a present or need to represent with a funny Belligerent V-neck Tee during Holidays or Family and Friends get-togethers, Idakoos is sure to have the right Belligerent V-neck T-shirt for you! Even if it turns out you can't find the right Belligerent V-neck Shirt with the perfect design for your mother, father or children; Idakoos offers all of its men's women's and children's Belligerent V-neck T-shirt s as Custom Belligerent T-Shirts. Personalize any Belligerent V-neck T-shirt the way you want to ensure the perfect gift.
Showing 1 - 24 of 69 V-Neck T-Shirt


text:
Big game moves in the twilight. There is a reason they call the hour around sunrise and the hour before sunset 'The Golden Hour', as in those two hours of the day deer and elk are on the move.For years, scope makers have been improving the quality of their lenses, the coatings on the lenses, and increasing the diameters of the objectives trying to maximize light transmission through the scope to the hunter's eye.
Scope objective lenses have progressed from 36mm to 40mm to 50mm in the quest to funnel light during the golden hour. As this has happened, scopes have needed to be mounted higher and higher off the bore centerline. Unfortunately, this move has often repositioned the shooters face too high off the comb of the stock where they lose their 'spotweld' and accuracy suffers.
Enter the VX-3L line of scopes from Leupold. The clever engineers at Leupold threw convention aside, and engineered a scope that has a 50mm objective lens, but sits as low on the rifle as a 32mm objective would. This combination of retained 'spotweld' and superior light gathering makes this scope an attractive proposition.
Let's take a look at how they did this. A picture is worth a thousand words, they say:
Obviously, they took a 'bite' out of the bottom of the scope housing and the lens, then devised a method of clamping and sealing the objective lens with screws rather than a threaded retainer. Brilliant!
Let's take a look at everything that comes with the scope as we open the box.
Top to bottom, you have the box, a nice neoprene scope sock, product registration card, a Leupold window sticker, an allen wrench, some tags, a manual and an explanation of the CDS system with a certificate for a custom laser engraved elevation turret knob.
My deer rifle is a Ruger 77 MKII, chambered in the often overlooked .260 Remington cartridge. Atop this rifle is mounted 'old faithful', a Leupold VariX-III 2.5-8x 36 scope that I got my first Elk with back in 1984. This scope has treated me well, even though it's been abused, beat up, dropped, dragged, bumped, rattled and rubbed. It shows the scars of hard hunting and riding in trucks.
I wanted to upgrade the magnification on this rifle to take advantage of the flat shooting caliber, and I had another 'brush gun' that I wanted to put a scope on. This led me to the VX-3L line of scopes for the .260, and I settled on this one, model 59265, from Webyshops.com.
In addition to the superb VX-3 glass, the low sitting capability of the 'L', this scope also features the 'CDS' system. The elevation turret of the scope is not a cap covering the adjustment, rather, the cap IS the adjustment knob. Unlike other externally adjustable scopes, this adjustment knob sits in low profile to the scope making it less likely to snag on things, gouge you in the back, get caught up in the sling, or bang against the transfer case lever in your truck.
A call to Leupold will get you a custom engraved knob matched to your hunting load. You simply zero the rifle at 100 yards, and if you find a target at 400 yards, you simply turn the knob to '400', hold your crosshairs where you want the bullet to hit. No multiple crosshairs messing up your sight picture, no trying to remember if the third or the fourth crosshatch is 300 yards, no cheatsheets taped to butt of your rifle. Brilliant.
I mounted the VX-3L on the same rings that the old 36mm scope sat on, and it fit like a glove.
As you can see, the objective hunkers down nicely over the barrel using the same rings that were used on the 36mm scope, and still allow enough room for cleaning and maintenance.
Here is another view that shows the overall aesthetics of the rifle with the scope mounted. The matte finish goes well with synthetic stock, and the low profile of the mounting flows well. The distinctive shape of the objective lens also lets others in hunting camp know that you have superb taste in optics, if you're into that sort of thing.
After mounting and leveling the scope, it was time to sight it in.
I set up at my 100 yard range, and set up 4 conventional rifle targets on a 3x5 board. I optimistically put a dot in the center of the board, and proceeded to dial it in.
I hit 8" low and 7" left on my first shot. I adjusted the scope 32 clicks up, and 28 clicks right. I fired once more, and hit ¾" low and ¾" left. One more shot proved I was good, and two more provided a nice tight group in the bullseye. Frankly, this group is usually better than I do, so I'll post a picture.
The crosshairs are a regular duplex pattern, which is my favorite. Here's a picture of the sight picture through the scope.
Here's what it looks like looking at a pear tree on 3.5 power at 130 yards.
And here's what it looks like at 10 power looking at the same tree.
The glass is great on this scope. Clarity and focus is crisp and clear from center to edge. Objects seen at dusk and dawn that are mere shadowy figures illuminate like you lit them up with a flashlight when seen through the scope. Deer and elk spotted coming out of the timber at dusk are no longer just vague shapes, but you can spot and count the points on the antlers, and determine if you have a shot clear of other animals.
If you are upgrading to a VX-3L from a lesser scope, it is like buying an hour of the best hunting time every day. You literally gain 30 minutes of visibility in the morning, and another 30 minutes at night. Those minutes are priceless.
The 3.5-10 power setting is a great compromise for the Northwest hunter, who may be hunting in brush and heavy timber and needs a low power scope for those situations, yet may pop out into a clearcut and need the 10 power for that bull at 300 yards or beyond. The CDS system, when utilized and tested at the range, would give a hunter some ethical confidence for that monster bull that's at 400 yards.
The only fly in the ointment in this combination doesn't have anything to do with the scope, but rather accessories. Here in the Northwest, hunting season means rain, sleet and snow. A fella that isn't running scope covers is likely to find his objective opening full of water, snow, leaves and fir needles at that all important time when he needs to whip up his rifle and that the shot at the big bull. I'm a fan of the Butler creek flip up scope covers, which are available for less than $20 a set. Due to the unique shape of the objective lens, these are not available. Leupold makes a fine set of flip up scope covers for this scope, but the price is staggering: $164.00 list, $120.00 at my local sporting goods store, or $100.00 online on sale. The scope does ship with a nice neoprene scope sock that I figured would do well to keep the scope from getting dinged up in the safe or the pickup. However, it may have to do as a cover while hunting if you have a hard time pulling the trigger on a $100+ set of covers.
Leupold's reputation of standing behind their product is legendary, and has been tested and proven to be superb by yours truly in the past. The combination of great glass, a low mounting height, a versatile power range, the CDS system and Leupold's dedication to quality and standing behind their product make this an excellent choice in a rifle scope. Even if you have to buy crazy expensive scope covers.
Mark Spreadborough writes from his family homestead in Kalama, Washington, where he lives with his wife, son, daughter, dog and cat. When not writing, shooting, hunting, fishing or working on his property, he goes to his day job as a HVAC repair mechanic.


text:
Beautiful Color on this set of Bavarian porcelain Demitasse and Saucer. Stands on 3 feet and has a really pretty ornate Handle. Nicely Gold Trim on rim of saucer and cup, handle and Feet. Mark on bottom of Cup ia almost not legible, but is one of a set that was made in Bavaria, Germany. Great Condition!
Our Own Family Estate Heirlooms! ~4 Generations of Avid Collectors~ALL Fair Offers Considered~
~From Our Family ESTATE ! ~LAY AWAY Available~Great Vintage Dolls.~ FAST Shipping ~ celebrating our 15th anniversary!


text:
Amid Growing Criticism, NYC Marathon is Canceled
The ING New York City Marathon has been canceled amid growing criticism from those who felt the city should focus its efforts on cleanup and rebuilding in the wake of Sandy.
New York Road Runner CEO Mary Wittenberg made the announcement Friday, hours after Mayor Michael Bloomberg defended the decision to go forward with the annual event that generates about $340 million for the city.
"Given the level of pain and suffering, it's not the right thing to do," Wittenberg said, near tears when talking about two toddlers who died in the storm.
She said no one expected the race "to play out this way," and that she had high hopes that the marathon would be an opportunity to honor the city, dedicating the run to those suffering, and to help the city move on.
The supplies stocked for the marathon — blankets, generators, water and food — will be deployed to areas of the city in need.
Many New Yorkers and local politicians, especially in storm-ravaged Staten Island, were angry the marathon was scheduled to go on.
And by early Friday, Bloomberg put out a joint statement with the NYRR canceling the 26.2 mile race that had been run every year since 1970.
Deputy Mayor Howard Wolfson described the marathon as one of the best days in the life in the city — a time of unity, happiness and celebration. But this year, it became "divisive," he said.
"And candidly, that controversy grew and that division grew over the course of the week," he said, "and those of us that love this city and those of us who love this race recognized it wasn't the marathon if it wasn't a unifying event."
(Photo: (Left to Right) Deputy Mayor Howard Wolfson, NYRR CEO Mary Wittenberg and NYRR Chairman George Hirsch officially anounce the cancelation of the 2012 ING NYC Marathon. Caitlyn Kim/WNYC)
Wittenberg and Wolfson said they had debated modifying the course or shortening it. There was also talk about postponement, but the "totality of what it takes to do this event and the people who committed to it were here this weekend," Wittenberg said.
There was also talk about turning the marathon into a 10-mile run.
"We did not think that made sense," Wolfson said. "The marathon is a five- borough race that unifies everybody in every borough and a 10-mile race in a portion of the races is not the marathon. We thought it was better to cancel and have a great marathon next year."
Wittenberg said she was also concerned that people angry about the marathon would take it out on runners.
People signed up for this year's marathon will get guaranteed entry next year.
Wittenberg told runners that she was "really sorry," but believed that runners who had spent months training and traveled from near and far could turn on the TV and understand why the decision was made.