Table Of Contents
Release Notes for Network Registrar Release 5.0
June 20, 2003
These release notes are for Release 5.0 and subsequent patch releases of Cisco Network Registrar. They describe new installation and upgrade requirements, new software features, and changes to the related documentation.
These release notes cover the following topics:
Note There are new installation procedures for upgrades.
This release builds on the success of the previous releases of this product, and extends the performance and scalability of the DHCP server. Network Registrar has been viewed as one of the best and most reliable DNS, DHCP, and TFTP servers in the industry. The product has remained successful because it:
•Implements cutting edge technology and features.
•Maintains a standards-based approach.
•Provides a flexible, extensible, and customizable platform for DNS, DHCP, and TFTP processing.
•Is closely integrated with other Cisco products.
Cisco Network Registrar 5.0 runs on the following operating systems:
•Windows NT 4.0, with a minimum requirement of Service Pack 4
Note Do not run this release on Windows NT 3.5.1.
•Solaris 2.6, 7, and 8
Note Do not run this release on Solaris 2.5.1. Also, see below for a known problem with Solaris 2.6.
•HP-UX-11(32-bit systems only)
The command line interface (CLI) runs on all the listed operating systems. The Network Registrar graphical user interface (GUI) runs on Windows NT 4.0, Windows 95, Windows 98, Windows 2000, and Solaris.
If you are upgrading to this release, maintain at least the same amount of free disk space you had for the previous release. The full system, server, and client requirements are described in the Network Registrar 5.0 Installation Guide.
For all operating systems, Cisco recommends that you install the current service pack (Windows) or recommended patch cluster (Solaris, AIX, HP-UX).
There is a known problem on Solaris 2.6 that can cause the DHCP server to hang during initialization. The problem is described by Sun RFE 4071167. You can encounter the deadlock in the Solaris name resolver client by installing a linked set of patches from Sun, including 103663-08, and disabling host name caching in nscd (to improve name resolver client performance), which is recommended by Sun in RFE 1243174. To avoid this problem, do one of the following:
•Do not install the linked patch set.
•Do not disable nscd host name caching.
•Install patch 105755-01 for Solaris 2.6.
Software and Standards Compatibility
The Network Registrar servers continue to comply with standard applicable RFCs. All software meets Y2K compliance according to the Cisco Y2K compliance policies (see http://www.cisco.com/warp/public/752/2000/index.shtml).
Network Registrar 5.0 supports the following protocols, standards, and IETF drafts:
•DHCP and BOOTP clients—Compliant with RFCs 951 (with updates 1497 and 1542), 1534, 2131, 2132, 2136, 3004, and 3046
•DHCP failover servers—Compliant with draft-ietf-dhc-failover-03.txt
•DNS servers—Compliant with RFCs 974, 1034, 1035 (with updates 1101and 1183), 1995 (IXFR), 1996 (NOTIFY), 2136 (Dynamic DNS Updates), 2317 (Classless in-addr.arpa), 2782 (SRV), and 2915 (NAPTR)
•Lightweight Directory Access Protocol (LDAP) servers—Interoperation with any LDAP v2 or v3 servers compliant with RFC 1798
•Trivial File Transport Protocol (TFTP)—Compliant with RFCs 1123 and 1350
The major components of Network Registrar 5.0 are unchanged from prior releases. Other than extensions for new functionality, both the Network Registrar CLI (nrcmd) and GUI interfaces are unchanged. However, a new embedded database engine was added for improved efficiency in maintaining lease state information (see the "New Lease Database" section).
Note Due to changes in the database format, earlier versions of the CLI (nrcmd) or the GUI cannot administer a Network Registrar 5.0 server. However, the Network Registrar 5.0 versions of the UIs can administer earlier versions of Network Registrar back to 3.0.
Existing utilities for manipulating the MCD database continue to operate. Note, however, that the output from the mcdadmin utility will no longer include the lease state information. Also, any data you exported using the mcdadmin utility in a previous release is not re-importable in 5.0 (even though it might seem like it is from the lack of any messages to that effect).
LDAP support is unchanged from the previous release.
Upgrading from an Earlier Software Release
The software upgrade procedure handles any database enhancements made due to the new embedded database engine (CNRDB). In some cases, the new installation and the upgrade procedures are distinct.
Caution Do not use the usual installation program for upgrades on UNIX operating systems. Also, do not uninstall the product before upgrading; the upgrade will fail. (See the following bullets for the programs to use in each case.) If you have a Network Registrar release earlier than 3.0, you must first upgrade to 3.0 or 3.5. You cannot downgrade the databases. As an extra precaution, keep a backup of the original (see the "Database Backup and Recovery" section).
•For Solaris installations, you must use the upgrade_cnr program if you have 3.0 or 3.5 installed and want to upgrade to 5.0. Do not use the pkgadd program for either upgrading or uninstalling the previous version.
•For HP-UX installations, you must use the upgrade_cnr program if you have 3.0 or 3.5 installed and want to upgrade to 5.0. Do not use the swinstall program for either upgrading or uninstalling the previous version.
•For IBM AIX installations, you must use the upgrade_cnr program if you have 3.0 or 3.5 installed and want to upgrade to 5.0. Do not use the installp program for either upgrading or uninstalling the previous version.
Note To run upgrade_cnr, log in as the superuser and enter the upgrade_cnr command at the shell prompt. In UNIX, you cannot be in the directory where Network Registrar is installed when executing this command. Be sure the directory where you want to back up the database exists and has enough disk space before you run the upgrade program. In addition to the location you specify, the upgrade program also backs up the database to the data-dir/data/db.bak directory in UNIX, or the install-dir\data\db.bak directory in Windows. Because of this, be sure there is enough disk space for both locations.
After the upgrade procedure, and after starting the product, the DHCP server automatically migrates the lease information to the CNRDB lease database.
Be aware of the following for the Network Registrar 5.0 installation:
•Close all applications and system file windows.
•If you are upgrading from a previous Network Registrar release, complete any configurations using the previous release so that the existing database, prior to conversion, is up to date. Do this as a precautionary measure. To upgrade from a release earlier than 3.0, you must first upgrade to 3.0 or 3.5 before you can upgrade to 5.0. There is no direct upgrade.
•On Windows operating systems, the installation program detects any configuration data from a 3.0 or 3.5 release, and, if you select to do so, migrates the data to the new 5.0 release databases.
•On UNIX operating systems, the installation program you use depends on if you perform a new installation, or an upgrade from 3.0 or 3.5. New installations are described in the "New Installation" section in the chapter for your operating system in the Network Registrar 5.0 Installation Guide. Upgrades are described in the "Upgrading from Version 3.x" section. The procedures are different. For upgrades, use only the upgrade_cnr program for upgrades; do not use an uninstall program.
What's New in This Release
This section describes the new software features in Network Registrar 5.0.
New Software Features
The following new software features appear in Network Registrar 5.0:
DHCP Server Performance Enhancements
The Network Registrar DHCP server provides industry leading performance that will scale to meet high volume requirements of customers. It responds to both sustained loads, as well as spikes (or bursts) of high-volume traffic, such as when a power outage or similar event occurs. The DHCP server can grant 1,200 leases per second under sustained load conditions. It can recover from a 20,000 client DHCP request spike in under 30 seconds. The DHCP server also provides significantly better startup and reload performance than in previous releases.
Considerable improvements were made in the performance of the DHCP server. Note, however, that the performance is very configuration-dependent. For instance, the server runs much faster when it is not logging messages for every lease operation, since logging is a very expensive operation.
There are many new log settings for the DHCP server, most of them designed to turn off logging of messages that may impact the performance of the server (see the "DHCP Log Setting Granularity Enhancement" section).
In addition to logging, capabilities like client-class and failover impact the maximum performance you can achieve with the DHCP server. In all cases, the DHCP server is many tens of times faster than it was in previous versions, but to determine just how much faster it will be, you would have to try it in your environment. Client-class in particular requires a read of the client database for every packet, and this puts a ceiling on the performance a given installation can reach.
If you plan to try to measure the performance of the DHCP server, note that the specific performance approach taken in the DHCP server causes it to run at its maximum speed only when about 120 simultaneous clients are interacting with it. The server is fast in throughput (as well as latency), but it cannot achieve truly remarkable throughput numbers without many clients accessing it at the same time. Note also that the server does not run at top speed on a 10 MB ethernet—all of the best performance numbers were obtained on a 100 MB Ethernet.
Considerable changes were also made to the DHCP server so that it can respond gracefully to sudden bursts of DHCP traffic. These specific changes are:
•The DHCP server drops any packet over 8 seconds old as a default, and you can configure this using the dhcp set drop-old-packets command in the CLI.
•The DHCP server stops logging success messages about every packet (along with many other log messages as well) if it gets "busy" (uses up two-thirds of the total request packets).
•The DHCP server stops keeping the last transaction time up to date when it is "busy" (as defined in the last bullet). This goes with the next item, defer-lease-extension.
•The dhcp set defer-lease-extension property is now the default. If the lease time is less than one-half expired, the server does not grant an entirely new lease (and does not have to write to the database). If the last transaction time does not require a database write, the entire renewal or init-reboot or discover/offer/request/ack sequence will take place in memory with no disk access required.
•These "busy" optimizations were made optional, although they are on by default. You can turn them off using dhcp set inhibit-busy-optimizations.
Because of these changes, the max-dhcp-requests (the number of buffers to allocate for receiving packets from the DHCP server) was increased from 100 to 500, since the server is much better prepared to deal with truly massive amounts of packets. The server is much faster than before. With the optimizations in effect, it can get even faster if the server starts to back up.
Note To have the NT Server Performance Monitor collect performance statistics for the DHCP server, you must use the dhcp set collect-performance-statistics=enabled CLI command (the property is disabled by default). You must also stop, reload, and restart the DHCP server. When running the Performance Monitor, there should be a DHCP server instance to select so that you can display the performance statistics.
You can now forward/switch DHCP traffic from one DHCP server to another under the control of a Network Registrar programming extension. The DHCP forwarding/switching feature is important in situations where the other server is not one you manage. This is most likely to occur in environments (such as for multiple system operators) where multiple vendors supply DHCP services for clients on the same LAN.
This feature was introduced in Release 3.5(3.1). For details on the extension points to use for this feature, see the Network Registrar 5.0 CLI Reference Guide.
New Lease Database
Network Registrar is equipped with a new database (CNRDB) to handle DHCP lease data. The existing shadow backup mechanism was extended to include both the existing MCD database and CNRDB. Recovery mechanisms were also extended to include CNRDB. These backup and recovery procedures are described at the end of Chapter 4 in the Network Registrar 5.0 User's Guide.
Windows 2000 Extensions (User Classes, FQDN, and Dual Zone Updates)
Extensions to the DHCP server functionality improve the integration with Windows 2000 environments. Support is provided for:
•User classes—Use this option to provide different levels of service to different users of a network. You can configure a Windows DHCP client's user class option to convey information about its software configuration or user preferences. Servers not equipped to interpret the user class specified by the client will ignore it. On the DHCP client, you can use the ipconfig utility to set the user class:
You can configure the Network Registrar DHCP server to make the user class a scope selection tag for selection criteria (using the dhcp set map-user-class-id=1 command), or make the user class a client class (using the dhcp set map-user-class-id=2 command). If you are mapping to a scope selection tag, you can either append the user class to the end of the selection criteria list (the default), or use the dhcp disable append-user-class-id-to-selection-tag command to have the user class replace all existing tags in the list. (Note that the dhcp set map-user-class-id= values are incorrect in the Network Registrar 5.0 CLI Reference Guide. They should be set, as above, with integer values. The value for ignoring the user class option should be dhcp set map-user-class-id=0, which is the default.)
•Fully qualified domain name (FQDN) option 81—Use the client-fqdn option to perform dynamic DNS updates. There are two permutations:
–The DHCP client updates the A record and the server updates the PTR record.
–The DHCP server updates both the A and PTR records.
Three new dhcp configuration parameters (use-client-fqdn-first, use-client-fqdn, and return-client-fqdn-if-asked) and the policy allow-client-a-record-update parameter in the CLI control the server's behavior when clients include the client-fqdn option. See the Network Registrar 5.0 CLI Reference Guide for details.
•Dual zone updates (Release 5.0.1)—Windows 2000 DHCP clients may need to be represented by A records in two DNS zones. The DHCP server now returns the client-fqdn option (81) so that the client can request a dual zone update. The policy command and the embedded policy commands (client-policy, client-class-policy, and scope-policy) in the CLI now include a feature you can enable: allow-dual-zone-dns-update. For example:
DHCP Vendor-Specific Option Support
To accommodate a wide range of vendor devices, the Network Registrar DHCP server can now process vendor specific options. Users can now:
•Describe the complex option type (option-datatype) using a collection of existing DHCP data types, such as BYTE and IP_ADDR.
•Describe a set of suboptions (from 0 to 255) for each vendor device, identified by the vendor class identifier string. These strings are unique for each device and are specified by the vendor.
•Associate each of the suboptions to the standard DHCP option-data-type created.
•Specify a collection of suboptions that should always be returned to the DHCP client device with each DHCPOFFER and DHCPACK packet the server sends out.
The Network Registrar CLI now supports the following commands for this purpose:
•option-datatype—This command defines formats for vendor-specific DHCP options. Using it, you can:
–Define a collection of standard DHCP option type items.
–Define the ordering and name of each item within the collection.
–Support special cases, such as the little-endian counted-array and exclude-from-dhcp-packet formats.
•vendor-option—This command defines option namespace and its format for a vendor supplied option for a specific device. Using it, you can:
–Create a vendor option and associate it with a vendor class identifier string for each vendor device. You can also potentially configure several vendor devices, each of which has unique vendor class identifier strings.
–Specify suboptions 1 through 255 in a vendor-specific option for each vendor device. While specifying suboptions, you can also specify the format for the suboption (by option-data-type name).
–Specify a set of suboptions that should always be returned in a DHCPOFFER and DHCPACK packet sent out by the DHCP server to the vendor device.
•policy setVendorOption—Using this command, you can:
–Set data for several vendor supplied options (one per vendor device) within each policy.
–Specify literal string values for each suboption field in the option-datatype.
Note These vendor-specific DHCP options are not manageable from or visible in the GUI.
Extension Point Chaining
The existing DHCP server extension points were extended to allow multiple scripts and libraries to run as part of the DHCP server. Using these extensions, you can customize the operation of the DHCP server. You can have a total of 32 scripts or libraries for each of the seven extension point.
You can specify the order to execute the extensions using a sequence number property. Each of the scripts are then executed in a defined order, independent of each other. The following Network Registrar CLI commands support this functionality:
•dhcp attachExtension extension-point extension-name [sequence-number]
•dhcp detachExtension extension-point [sequence-number]
In addition to implementing extension chaining, there are three new items in the environment dictionary for every script invocation, in addition to the existing extension-point item:
•extension-name-sequence—Includes the comma-separated string that contains the extensions configured for this extension point. All the extensions must be listed in sequence order. Any position in the sequence without an extension must have a null entry in the form of adjacent commas. For example, to configure tclfirst as the first extension and dexscript as the fifth extension, use "tclfirst,,,,dexscript" as the extension-name-sequence string.
•extension-name—Name with which the extension was configured. The same piece of code can be configured as several different extensions (and at several different extension points). A useful application is that one piece of code can do different things based on how it was configured. The code can also use this string to find its name in the extension-name-sequence string.
•extension-sequence—Number string is the sequence in which the extension is currently running.
•extension-point—Existing string is the name of the extension point.
Note Except for these items, there were no changes made to the extension API in general. Existing extensions should work correctly between 3.5 and 5.0. However, the order of initialization may have changed. This order was never guaranteed as part of the extension API, but it seems to have been generally deterministic in previous versions of Network Registrar. Some extensions which (incorrectly) depended on the ordering of initialization may need some adjustment to continue to run correctly.
NAPTR Resource Record Support
The DNS server and UIs were extended to support Naming Authority Pointer (NAPTR) resource records (RFC 2915). These records are required for certain types of residential Voice over IP (VoIP) support.
DNS BIND File Import Restrictions
Network Registrar currently lets you import only BIND 4.x.x named.boot files. You cannot import BIND 8.x.x. named.conf files.
Return Host Name to Client
The DHCP server now returns a host name to a client, if so requested by the client (through the host-name option in the dhcp-parameter-request-list of a DHCP request).
Command Line Interface Enhancements and Changes
The Network Registrar CLI includes new commands and enhanced capabilities for existing ones.
•server <DNS|DHCP|TFTP> serverLogs nlogs=number and logsize=bytes—Sets the number and size of server log files. You must stop and subsequently restart the server agent for these changes to take effect. (See also the "DHCP Log Setting Granularity Enhancement" section.)
•dhcp set properties for DHCP performance considerations. (See the "DHCP Server Performance Enhancements" section.)
•object-type listnames—Lists only the names of all objects of a given type. For example, zone listnames lists the zone names.
•scope name clearUnavailable—Makes available all unavailable leases in a scope.
•lease list -lansegment, -macaddr, and -subnet switches—Use these singly to list only leases in a LAN segment or subnet, or associated with a particular MAC address.
•scope name changemask—Changes the network mask of the scope, in either direction.
•dns enable save-negative-cache-entries—Negative cache entries for queries of names resembling IP addresses can rapidly fill the cache, resulting in decreased performance. Disabling this attribute means that no entry of this type goes into the cache database (cache.db) file. Required, default enable. Note that this attribute is not documented in the Network Registrar 5.0 CLI Reference Guide.
•dns set auth-db-cache-size—Maximum page size of the authoritative database (auth.db) file, set during database initialization. Required, default 20. Note that this attribute is not documented in the Network Registrar 5.0 CLI Reference Guide.
•dns set cache-db-cache-size—Maximum page size of the cache database (cache.db) file, set during database initialization. Required, default 20. Note that this attribute is not documented in the Network Registrar 5.0 CLI Reference Guide.
•dns set cache-write-ttl-threshold—Network Registrar does not write resource records with TTLs less than this value, in milliseconds, to the cache database (cache.db) file. A zero value (the default) disables this threshold test. Required, default 0, range 0 through 2147483647ms. Note that this attribute is not documented in the Network Registrar 5.0 CLI Reference Guide.
Graphical User Interface Changes
The Network Registrar GUI was changed in that certain fields and check boxes were removed from the DHCP Server Properties dialog box Advanced tab. The check boxes that were removed include:
•Number of ping server threads and Ping queue timeout factor—These fields were relevant only to Windows NT 3.5.1 systems, which are no longer supported. However, the Number of ping packets field (default value 500) still applies and is included in the dialog box. (Note that the removed fields were inadvertently included in the example of the DHCP Server Properties dialog box shown in Figure 7-5 of the Network Registrar 5.0 User's Guide.)
•Cisco DHCP Proxy—This previously supported certain Cisco devices that implemented a DHCP proxy function. The DHCP server used a nonzero IP source address as the gateway address (giaddr) of a DHCP packet when no giaddr was specified in the packet. The option is now disabled.
Note Vendor-specific DHCP options you can set using the CLI are not visible in the GUI. (See the "DHCP Vendor-Specific Option Support" section.)
DHCP Log Setting Granularity Enhancement
Greater granularity of server logging ensures that you configure only those logging actions you require. Most of the changes were made to give greater control over existing log messages.
The dhcp set log-settings= command in the CLI now includes the following new flags:
•no-success-messages—Inhibits logging successful outgoing response packets
•no-dropped-dhcp-packets—Inhibits logging dropped DHCP packets
•no-dropped-bootp-packets—Inhibits logging dropped BOOTP packets
•no-failover-activity—Inhibits logging normal server failover activity
•activity-summary—Enables logging a summary message every five minutes (useful if no-xxx type flags are set), showing the activity in the previous interval; provides some indication of how hard the server is working
•no-invalid-packets—Inhibits logging invalid packets
•no-reduce-logging-when-busy—Inhibits reducing logging when receive buffers reach 66%
•no-timeouts—Inhibits logging timeouts of leases and offers
•minimal-config-info—Reduces the number of configuration messages in the log
•no-failover-conflict—Inhibits logging server failover conflicts
Even though these new log settings enable turning off many log messages, error messages are not, in general, disabled. Most warning messages are also not disabled (except by settings such as no-dropped-bootp-packets).
Note Log messages are also sent to the Event Viewer on Windows systems. On Windows NT systems, you may encounter problems running the Network Registrar servers if the NT Event Viewer is wrapped (rolled over) periodically or not at all, instead of on an "as needed" basis. In Event Log Settings, be sure the Overwrite Events as Needed option is selected for the application log.
Database Backup and Recovery
As indicated in the "Installation Notes" section, you do not need to back up your existing database, since the upgrade process copies the database files to a backup location. However, you may also, previous to the installation, want to shut down the AIC Server Agent, initiate a last minute shadow backup of your existing data, then archive this data to a location not in the installation path (such as to disk or another system). Use the mcdshadow command in the /opt/nwreg2/bin/ (UNIX) or \Program Files\Network Registrar\bin\ (Windows NT) directory to perform the manual shadow backup. Do not use any backup procedure other than mcdshadow, although you can archive the resulting shadow backup files anywhere.
These files are located in the /var/nwreg2/data/db.bak directory for UNIX systems, or the \Program Files\Network Registrar\data\db.bak directory for Windows NT systems. After a successful backup, this directory should contain three mcddb.* files with the current date and time. You can check the integrity of your existing database by using the dbcheck -a mcddb command in the /opt/nwreg2/bin/ (UNIX) or \Program Files\Network Registrar\bin\ (Windows NT) directory.
Keep in mind that Network Registrar continues to perform automatic, daily (or otherwise specified) shadow backups on the new 5.0 databases. (This procedure and ways to recover the data are described in the Network Registrar 5.0 User's Guide.)
This section describes the bugs resolved in Network Registrar 5.0 and subsequent patch releases. The list of resolved and unresolved bugs is available on the Cisco Network Registrar CD-ROM. To display it, navigate your browser to this file:
Changes and Bugs Fixed in Release 5.0.12
Network Registrar 5.0 was repackaged on the Windows, Solaris, and HP-UX-11 operating systems to remove cryptographic libraries included in the distribution, but not used by the product.
In addition, the following major issues were resolved in Release 5.0.12:
•The DNS server no longer crashes during a startup or reload while configuring a zone that has dynamic DNS update disabled. CSCdx21710
•A primary failover DHCP server no longer occasionally crashes on high load, especially on multiprocessor machines. CSCdx44064
•A DNS server memory leak with a high number of zones and dynamic resource records was resolved. CSCdx49371
•A DNS server memory leak with the fake-ip-name-response attribute enabled was resolved. CSCdy15765
•Modifying DHCP scopes not having IP address ranges set no longer consumes a large amount of memory. CSCdz68963
Bugs Fixed Prior to Release 5.0.12
For the full list for all bugs resolved and open prior to 5.0.12, see the Cisco.com product download site for Network Registrar, or CNR5012_Bug_List.html on the CD-ROM drive.
Documentation Updates and Errata
The Network Registrar documentation was updated as follows:
•Network Registrar 5.0 Installation Guide was updated based on the new installation procedures on all operating systems.
•Network Registrar 5.0 User's Guide now includes the material previously published in the Concepts Guide and Getting Started guide for Release 3.5. The new features in 5.0 are now described in the User's Guide.
•Network Registrar 5.0 CLI Reference Guide was enhanced based on the new release features and improved for readability.
The following sections describe specific updates and errata:
Read-only Access Not Documented
Network Registrar provides read-only access during login and when connecting to a cluster. Read-only mode provides limited functionality. In the GUI, the Login dialog box includes a Read Only check box. In the CLI, you can include the -r option on the command line.
Cache Database Attributes Not Documented
The CLI now provides two attributes to affect whether Network Registrar writes (possibly bogus) IP address name entries to the cache database (cache.db) file, and whether it should store resource records older than their TTL in this file. You can use the dns disable save-negative-cache-entries command to disable storing any negative cache data (it is enabled by default). You must explicitly enable the TTL threshold test by setting a value other than 0 with the dns set cache-write-ttl-threshold command (the TTL test is disabled by default by being set to a value of 0). These are not documented in the Network Registrar 5.0 CLI Reference Guide. See also the "Command Line Interface Enhancements and Changes" section.
The CLI also includes two additional attributes that are not documented. These attributes set the maximum page size of the auth.db and cache.db database files. You can set them using the dns set auth-db-cache-size and dns set cache-db-cache-size commands, respectively. See also the "Command Line Interface Enhancements and Changes" section.
Update to Configuring Embedded Policies in LDAP (Release 5.0.1)
The "Configuring Embedded Policies Within LDAP" section (and the subsequent "Specifying Multi-Value DHCP Options" section) on page 13-4 of the Network Registrar 5.0 User's Guide should be replaced by the following text:
To configure embedded policies within LDAP, follow these steps:
Step 1 Configure an LDAP server for the DHCP server, naming it myserver, for example.
Step 2 Map the LDAP attribute that you want the DHCP server to interpret as the embedded policy to the internal embedded-policy property. The following example maps the businessCategory LDAP attribute to the property.
Step 3 Add a string to the LDAP attribute that the DHCP server can interpret as an embedded policy. The most practical way to determine what this string should look like is to create a dummy client in the Network Registrar database and use the mcdadmin utility to determine the proper string to add to the LDAP attribute. Note that this dummy client will never be used, because you are using LDAP, and you can subsequently delete it. Have the embedded policy include the option data types you need.
a. For example, create an embedded client policy for client 1,6,01:02:03:04:05:06. Add some reply options and a multi-value option (routers) with an IP address data type.nrcmd> client-policy 1,6,01:02:03:04:05:06 set dhcp-reply-options=packet-file-name,packet-server-name
b. Use the mcdadmin utility to redirect the database client entries into a file.
On NT, run this utility from the Bin folder in the Network Registrar installation directory. On Solaris, it is located in the opt/nwreg2/usrbin directory of the installation directory. The user name and password are required.
c. Open the file in an editor and search for the appropriate client entry.
The ((ClassName Policy) entry is the start of the embedded policy string, with a single closing parentheses ending the string. (The entire entry normally runs together. It is presented here for clarity as parenthesized groupings on separate lines. The final three parentheses close, respectively, the ClassName Policy, embedded-policy, and ClassName Client Entry groupings.)
d. Add the embedded policy string (boldface in the previous step) to the LDAP attribute (businessCategory in the example).businessCategory:((ClassName Policy)(name client-policy:1,6,01:02:03:04:05:06)(vendoroptions ())(version 1)(dhcp-reply-options [packet-file-name packet-server-name ])(dhcp-reply-options-number [257 258 ])(options ((routers 01:03:01:02:03:04:05:06:07:08))))
Note The option values are translated into hexadecimal field syntax, including multiple values that were originally comma-separated. For example, setOption routers 184.108.40.206, 220.127.116.11 translates into (options ((routers 01:03:01:02:03:04:05:06:07:08))). The first field of the option value is the number of bytes in the option number (01 or 02). The second field is the option number itself in hex (option 03, routers, in the example).
e. Use the syntax as a model for each new embedded policy entry in LDAP. To see how other option data types appear in the LDAP string, add these options to the client or create further dummy clients with them. Once you extract the data, you can use the CLI to delete the dummy client.
Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at this URL:
You can access the Cisco website at this URL:
International Cisco websites can be accessed from this URL:
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have shipped with your product. The Documentation CD-ROM is updated regularly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual or quarterly subscription.
Registered Cisco.com users can order a single Documentation CD-ROM (product number DOC-CONDOCCD=) through the Cisco Ordering tool:
All users can order monthly or quarterly subscriptions through the online Subscription Store:
You can find instructions for ordering documentation at this URL:
You can order Cisco documentation in these ways:
•Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace:
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page.
You can e-mail your comments to firstname.lastname@example.org.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com, which includes the Cisco Technical Assistance Center (TAC) website, as a starting point for all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips, and sample configurations from the Cisco TAC website. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC website, including TAC tools and utilities.
Cisco.com offers a suite of interactive, networked services that let you access Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com provides a broad range of features and services to help you with these tasks:
•Streamline business processes and improve productivity
•Resolve technical issues with online support
•Download and test software packages
•Order Cisco learning materials and merchandise
•Register for online skill assessment, training, and certification programs
To obtain customized information and service, you can self-register on Cisco.com at this URL:
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available: the Cisco TAC website and the Cisco TAC Escalation Center. The type of support that you choose depends on the priority of the problem and the conditions stated in service contracts, when applicable.
We categorize Cisco TAC inquiries according to urgency:
•Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration. There is little or no impact to your business operations.
•Priority level 3 (P3)—Operational performance of the network is impaired, but most business operations remain functional. You and Cisco are willing to commit resources during normal business hours to restore service to satisfactory levels.
•Priority level 2 (P2)—Operation of an existing network is severely degraded, or significant aspects of your business operations are negatively impacted by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
•Priority level 1 (P1)—An existing network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Cisco TAC Website
The Cisco TAC website provides online documents and tools to help troubleshoot and resolve technical issues with Cisco products and technologies. To access the Cisco TAC website, go to this URL:
All customers, partners, and resellers who have a valid Cisco service contract have complete access to the technical support resources on the Cisco TAC website. Some services on the Cisco TAC website require a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to this URL to register:
If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC website, you can open a case online at this URL:
If you have Internet access, we recommend that you open P3 and P4 cases online so that you can fully describe the situation and attach any necessary files.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. These classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer automatically opens a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this URL:
Before calling, please check with your network operations center to determine the Cisco support services to which your company is entitled: for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). When you call the center, please have available your service agreement number and your product serial number.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:
•Cisco Press publishes a wide range of networking publications. Cisco suggests these titles for new and experienced users: Internetworking Terms and Acronyms Dictionary, Internetworking Technology Handbook, Internetworking Troubleshooting Guide, and the Internetworking Design Guide. For current Cisco Press titles and other information, go to Cisco Press online at this URL:
•Packet magazine is the Cisco quarterly publication that provides the latest networking trends, technology breakthroughs, and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are networking deployment and troubleshooting tips, configuration examples, customer case studies, tutorials and training, certification information, and links to numerous in-depth online resources. You can access Packet magazine at this URL:
•iQ Magazine is the Cisco bimonthly publication that delivers the latest information about Internet business strategies for executives. You can access iQ Magazine at this URL:
•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:
•Training—Cisco offers world-class networking training. Current offerings in network training are listed at this URL:
Copyright © 2003 Cisco Systems, Inc. All rights reserved.