Symptom: In some situations a dhcp-renewal-time or a dhcp-rebinding-time which has been specifically configured within a policy will not be used. In these situations, when the DHCP server decides to return the remaining term of the lease to the DHCP client, it will calculate the dhcp-renewal-time to be .5 of the remaining time, and the dhcp-rebinding-time to be .66 of the remaining time, and will return those values to the client, instead of whatever was configured in the appropriate policy. Conditions: This will occur when the DHCP server has decided to return the remaining time left on a lease to the DHCP client, instead of extending the lease. This will only occur if less than half of the lease time has elapsed, and also only if defer-lease-extension has been enabled for the DHCP server (which is the default in CNR 5.0 -- a change from 3.5(3) and previous versions). Workaround: None
Scope names should show up on the alarms, presently CNR MIBs do not support this feature.
Symptom: When adding servers to the secondary servers list for zone distributions, no check is made against the primary server's addresses. Attempting to run the synchronization will result in an error such as: "zone-distribution-name synchronization Failed : Object already exists. Please respecify." Condition: This error is encountered because the synchronization is attempting to add the secondary zones to the primary server, where the primary zone already exists. The server configuration will not be affected by this error. Workaround: To clear the error, remove the invalid server from the list of secondary servers.
Symptom: 6. If DHCP failover is in use, a client's initial lease is granted for a specific, short period of time, called MCLT. Subsequent renewals extend the lease for the full configured lease time. If the client does not renew the lease, and it expires at MCLT, the lease may not become available for reassignment until a full lease period elapses. Workaround: Upgrade to CNR2 (check for the latest available version).
Symptom: When zone data from a 6.0 server is pulled from the replica database, the deprecated 6.0 attribute 'restricted-set' is not converted to the equivalent 6.1 attribute 'restricted-xfer-acl'. The 'restricted-xfer-acl' attribute is instead left unset. Workaround: Manually enter the 6.0 server 'restrict-set' attribute value into the new attribute 'restricted-xfer-acl'.
Symptom: If the DHCP server is seeing a higher than expected load or clients are getting unexpectedly short lease times, the allow-lease-time-override, which is enabled by default in CNR releases prior to 6.2.1, might be set incorrectly. Workaround: Make sure that allow-lease-time-override is explicitly disabled in any and all policies unless this is explicitly required. Note that new policies may be created with this defaulting to enabled. Enabling allow-lease-time-override is rarely required and there are clients that will re-request the same lease time on a renewal that they had previously (i.e., they never ask for a longer lease time) and this causes the clients to have to renew much more frequently, which impact load on the DHCP server and other network elements.
Symptom: When you first create a scope, if you leave the namespace-id attribute unset, a subnet is created in the global (non-VPN) address space. If you then edit this attribute to assign the scope to a VPN, a new subnet will not be created in the assigned VPN, and the global subnet will remain. Once assigned, however, the namespace-id is not editable, and the scope will be permanently assigned to the VPN. Workaround: To correct this inconsistency, you must delete the scope and recreate it, ensuring the correct VPN is assigned before the scope is saved. In the CLI, be sure to set the attribute immediately after creating the scope, before issuing a save command.
Symptom: When pulling zone data, zone distributions will only be created in update mode. Workaround: In order to pull new zone distribution data that overlaps with the existing zone distributions, you must first delete these manually.
Symptom: On a secondary DNS server, statistic non-auth-no-data will include any IXFR refusals. The resulting counter may therefore be slightly inflated. Workaround: Check secondary zone's configuration to ensure proper specification of master servers to reduce the chance of improper inflation of this DNS statistic counter.
Symptom: When a slave requests an IXFR from the master and the master has insufficient history to provide the incremental changes, the master will respond with a full zone xfer. This incident is counted in DNS statistic ixfrs-full-resp. All AXFR occurrences including ixfrs-full-resp in the master are counted as axfrs-out Workaround: None
Symptom: The server times out the session after the configured timeout period. Conditions: When the client drops the last data packet from CNR TFTP server, or that packet is lost in transmission, it is not re-transmitted by the server. Workaround: The client must re-initiate the file transfer.
Symptom:
When importing a BIND file, no error or warning is generated when an
unsupported $
Symptom: The DNS server will fail with a time out, when resolving domain names with more than two levels of gluelessness for NS resource records (without Glue-Records). Workaround: If you have control over the authoritative servers, add Glue A records as a workaround. Otherwise, issue direct queries for the second level or third level server to create cache entries for NS servers needed for resolution.
Symptom: When importing host data using cnr_exim corresponding resource records will always be overwritten so that they match the host data.
Symptom: CNR 6.1.1.2 regional appears to corrupt replicadb periodcally. It is similar to CSCeh45099. We see in the server agent log:
04/20/2005 9:23:59 agent/server/1 Info Server 0 08012 server agent loading 'ccmsrv -c 1244' 04/20/2005 9:25:10 agent/server/1 Info Server 0 08017 timeout waiting for server 0 to connect; timeout was 61 secs server config/ccm/1 'ccmsrv' 04/20/2005 9:25:10 agent/server/1 Info Server 0 08014 forceably unloading server config/ccm/1 'ccmsrv' 04/20/2005 9:25:10 agent/server/1 Warning System 0 08038 ServerInfo::unload_server_md(ccmsrv): couldn't find proc Id or handle: id=3484, handle=0 04/20/2005 9:26:14 agent/server/1 Info Server 0 08016 reloading dead server config/ccm/1 'ccmsrv'
And from the CCM server log:
04/20/2005 9:26:26 config/ccm/1 Error Server AX_EINVAL 06081 Module 'Replication module' start failed. 04/20/2005 9:26:26 config/ccm/1 Error Server AX_EINVAL 06033 ccm_start() failedWorkaround:
- Stop the nwregregion service - Clean the\replica directory - Clean the \replica\logs directory - Restart service
The Replica DB will be recreated from each of the local clusters when the CCM server is restarted. No data is lost when executing this procedure.
Symptom: The DNS server will not honor an activity-summary-interval setting less than 60 seconds. Regardless of the value entered, statistics will be logged at 60-second intervals. Workaround: None
Symptom: Mismatch between the WebUI counter name and corresponding MIB attribute name. The total count value of ha-zone-mismatch corresponds to cDnsHaResponseMismatchCnt and the interval count corresponds to cDnsHaIntResponseMismatchCnt in the MIB.
Symptom: The DHCP server does not validate that the option values defined on a policy are configured with reasonable values: lease renewal < rebind < expire times. Unexpected results could occur within the client I.E. 'Obsessive Renewing' clients could occur. Workaround: Don't manually configure dhcp-renew|rebind-times in a policy and let the servers default behavior of using 50% for renewal and 85% for rebind apply.
Also it is recommended to disable the policy attribute;
nrcmd> policy
in ALL policies on the server to ensure the client cannot get a shorter then configured dhcp-lease-time thus more likely causing renew or rebind times to possibly be sent as greater then lease-time.
Symptom:
The Pull Replica Address space function will fail silently whenever there are overlapping subnets between regional and local clusters. Subnet renumbering at local cluster is a one scenario that can result in overlapping subnets between the Replica DB and authoritative CCM DB.
Workaround:
Manually delete any overlapping subnets in the CCM DB prior to running the pull
operation.
Symptom:
The system does not prevent you from specifying multiple prefixes with the
same address and
overlapping ranges. For example, these 2 prefixes have the same address and
range specified, and thus the ranges are completely overlapping:
Prefix p1 with address 1:2:3:4::/64 and range 1:2:3:4:5::/96
Prefix p2 with address 1:2:3:4::/64 and range 1:2:3:4:5::/96
Workaround:
Do not specify prefixes with the same address and overlapping ranges, as
this will result in a misconfiguration of the DHCP server. Instead, specify
prefix p2 in the previous example as follows:
Prefix p1 with address 1:2:3:4::/64 and range 1:2:3:4:5::/96
Prefix p2 with address 1:2:3:4::/64 and range 1:2:3:4:5:1::/96
In this case, the 2 prefixes have the same address, but non-overlapping
ranges, which is a perfectly valid configuration.
Symptom: A constrained dns admin, who should be authorized to pull replica zone templates on the regional CCM server, encounters a "permission denied" error. Workaround: Perform the pull operation using an admin with superuser credentials.
Symptom: The relay-agent-info option is not available to an extension running at the post-send-packet extension point. Workaround: Because the relay-agent-info in the response packet is an exact copy of the relay-agent-info in the request packet, you can access the relay-agent-info in the request dictionary with not loss of functionality.
Symptom: Whenever a zone distribution is run, certain zone attributes such as 'notify' are explicitly set. These should be configurable, so that zones may inherit server global settings. Workaround: Manually edit zones to restore settings.
Symptom: A constrained dns-admin can run the Sync All Zone Distributions function, which should not be permitted. Workaround: None.
Symptom: A constrained dns-admin is not able to view the region assigned to the zone. Workaround: Assign the unconstrained dns-admin role to users who need to view this information.
Symptom: When performing HA DNS pair synchronization from the regional server, only regional zone data is used when 'use regional data' is selected. Regional Key, Update-Policy, and ACL configuration is ignored. Workaround: Before running the HA DNS pair sync, use the Push function to update the local cluster Key Update-Policy, and ACL lists.
Symptom: Even if there are client-class changes that need to be applied, synch will skip these objects in the update mode Workaround:
1. Delete the client-class on the server that needs to be synched 2. Synch from the main server using replace or exact modes.
Symptom: DNS HA servers do not log a message when they receive a truncated request or response from their partner server. Workaround: None
Symptom: In CNR versions 6.2.* and 6.3: A Push DNS Update Map initiated from a Regional Cluster to a DNS HA pair may fail to update the target zones on the HA Pair's clusters appropriately -- i.e. the "dynamic" and "update-acl" and "update-policy-list" attributes of those zones may not get updated to the correct values (e.g. "dynamic" = TRUE; update-acl set to IP of the DHCP server or update-policy-list set to names of the appropriate update policy). Workaround: Login to the Main DNS partner; update the "dynamic" and the "update-acl" or "update-policy-list" attributes to reflect the correct values; then perform an HA DNS Sync operation to update the backup cluster.
Symptom: CNR does not save the relay agent's address in leases (giaddr for DHCPv4, ipv6 source address for DHCPv6). This enhancement adds that support, which is needed to support DHCPv6 client reconfiguration, for example. Workaround: There is no straightforward workaround for this lack. Conceivably someone could write an extension which could save this attribute in another attribute that was not currently in use by the DHCP server given the mode in which the DHCP server is currently operating.
Symptom:
The nrcmd CLI command
Symptom: The DHCP server after version 6.0 cannot import or read a Policy object that was exported via mcdadmin or CLI commands. The 6.0 release introduced the option-list attribute, which cannot be parsed by the server code into a valid attribute. Unfortunately the parsing code silently ignores the error and creates a genobj without the offending attribute. Customers who attempt to follow the documented instructions for entering an embedded policy into LDAP will find that any option values are "lost" when the client is read from LDAP. Workaround: Use the pre-6.0 Policy attribute 'options' format. See also CSCsd32284, this workaround does not work for the 6.2 release.
Symptom: Certain failures in extensions may cause a misleading error message in the DHCP server logfiles. The message states incorrectly that the operation is not supported at the current extension point. Workaround: None.
Symptom: The DHCPv6 server does not save the client-vendor-class data received from DHCPv6 clients. Workaround: None.
Symptom: The push and pull all roles functions will fail if multiple roles in the list define constraints that use the same owners or regions. An empty change set report is shown when this occurs. Workaround: Push or pull the roles individually.
Symptom: When an update is refused because it is either not allowed or explicitly denied by an update-acl, the update-errors counter is not increased.
Symptom: When performing a push role or group operation, the selected mode is also applied to related objects if "replace related objects" is also selected. As a result, when ensure mode is selected, related objects are not updated, and when exact mode is selected, unrelated objects may be deleted. Workaround: To avoid these issues, only use this feature with replace mode. To make changes in ensure or exact mode, leave this option unchecked, and sync roles and groups as separate user actions.
Symptom: If the DNS servers purge database log intervals are set too low, database log files required by the backup may be deleted prior to being backed up. This may lead to an unusable backup. Workaround: Avoid setting the log purging intervals smaller than the time it takes to copy the database files.
Symptom: Attempts to upgrade from Network Registrar 6.1.4 to Network Registrar 6.2 may not complete successfully since the cnrdb_recover utility is unable to successfully run against several of the server databases. Users can definitively diagnose the upgrade failure by examining the contents of the install_cnr_log file in the product's log directory. Entries similar to the following indicates an occurrence of this defect:
05/03/06-11:40:46:AM - Attempting to update the NDB databases... 05/03/06-11:40:46:AM - 'C:\Program Files\Network Registrar\Local\data/ccm/ndb/log.db' database not present and will not be upgraded. 05/03/06-11:40:47:AM - Unable to update the 'C:\Program Files\Network Registrar\Local\data/ccm/ndb' database(s), error = db_recover: warning: changelog.db: No such file or directory.Conditions: A database change was made in Network Registrar 6.1.4 that caused one of the database files to be renamed, and the installer was not updated to copy the new database file prior to running cnrdb_recover. Workaround: There is no manual procedure that has been approved to work around this behavior. Customers should use CNR version 6.2.1 or later when upgrading from CNR 6.1.x.
Symptom: The CCM server uses the same message handler to process both subnet and address block requests, and will return incorrect data for some requests. When both an address block and subnet exist for the same subnet number, the block is returned, regardless of the request. Also, if only the address block exists, CCM will return the block when a subnet is requested, instead of NOT FOUND. Similarly, if only the subnet exists, CCM will return the subnet, when a block is requested. Workaround: None
The DHCP server will no longer log AX_EMSGSIZE messages when reading packet from the ping (ICMP) socket.
Symptom: Long-lived CNR management connections that become idle may be blocked by customer firewalls. For example, if a regional CNR installation communicates with local CNR installations, the connections between them may only be active occasionally. One symptom associated with this issue is a delay while pushing configuration changes from regional to local CNR installations. The delay is caused when blocked connections timeout while waiting for responses. Workaround: If an operation fails because the management connection failed, it should be possible to retry the operation. That should cause the CCM server to re-establish a connection to the target CNR installation. It may also be necessary to coordinate the timeouts configured at the firewalls with the polling interval at the CCM regional to ensure that communication takes place frequently enough to avoid the firewalls' timeouts.
Symptom: The CCM server may occasionally deadlock when handling multiple client requests that add new objects to the CCM database. When this occurs, the client request will be blocked, although other server processes may continue to operate. Further add requests will also be blocked, however, and eventually may consume all available server resources. Workaround: To recover from this condition, restart the CCM server.
Symptom: In vary rare situations the server may crash on startup while attempting to deference a bad pointer to the hostname string it has been passed when configuring the interface. This will happen if the host has a very long host name (say about 240 bytes) or has many alias names. Workarounds:
1) Add information to %SystemRoot%\system32\drivers\etc\hosts that is shorter or has fewer alias entries. 2) Shorten the server's DNS name or alias names. 3) Remove alias names.
Symptom: EditSubnet page on regional does not display any scopes associated with the subnet and can crash the regional CCM server. Workaround: None.
Symptom: Network Registrar 6.2 introduces several changes in dealing with vendor- options (dhcp option 43). Not all of these changes are covered by documentation. All the existing datatypes have been obsoleted and now there are a couple dozen new data types without any definition. Workaround: None.
Symptom: There is no means of temporarily disabling an LDAP configuration on the DHCP server. Workaround: You must delete the configuration object and completely re-create it. This is error-prone and time-consuming. The only alternative is to disable the three attributes that control LDAP connections: can-update, can-create, and can-query, which is also error prone (easy to forget which ones you had set).
Symptom: On rare occassions the backup HA server might error on deleting an RR nameset. When this condition occurs, the backup HA server will transition to communications interrupted and request a full transfer of the zone. Workaround: There is no need for a manual workaround as the HA servers do detect this and recover by forcing synchronization and subsequently applying a full zone xfer.
Symptom: If you have configured the 'can-create' ability on the LDAP server, the string used for the list of object classes (in the create-object-classes attribute) is leaked on a reload. Because this string is used on each LDAP connection object, the amount of memory leaked is the length of this string times the number of LDAP connections configured. Workaround: Stop and start the DHCP server process if memory usage is approaching the physical limits of the host machine.
Symptom: Configuring the DHCP server with a custom option definition that replaces one of the built-in option definitions causes the DHCP server to leak a small amount of memory on reloads (about 100 bytes, the size of most of the built- in option definitions). The memory leaked could be as much as 1Kb if one of the complex option definitions is redefined (option-122 in the dhcpv4 option set, for instance). Workaround: Monitor the DHCP server memory usage and periodically stop the process completely.
Symptom: The DHCP server logs an unnecessary warning for a failed LDAP attribute conversion for an embedded policy. Workaround: None, but these log warnings can be ignored.
Symptom: User is not able to change cluster name in CLI. When the user tries to change the cluster name in CLI, the following error occurs:
nrcmd> cluster localhost set name=test 302 Not Found - cluster localhost set name=testConditions: This affects only the CLI. Workaround: Change the cluster name by using the web UI.
Symptom: On Solaris, the DHCP server fails to use all configured LDAP connections after detecting an LDAP failure. Workaround: Reload the DHCP server.
Symptom: An attempt to define a new DHCP Option Definition using the CNR web UI may result in an error stacktrace under certain situations. Conditions: When defining a new top-most level DHCP Option Definition using the CNR web UI, an error stacktrace may be displayed. This will occur if the Option Definition being defined does not already exist, and only if it is the top-most level at which the new Option Definition is being defined at. Workaround: Use the CNR Command Line Interface (CLI) to define the new DHCP Option Definition. Further Problem Description:
Symptom: The description comparing LDAP server round-robin and failover mode, in the "Configuring DHCP-Server-to-LDAP Client Queries" section of Chapter 23 in the User's Guide, will be corrected in future documentation to read:
"LDAP failover mode actually performs preferential load balancing. The DHCP server assesses the LDAP connection and error states and how fast the LDAP server responds. In an optimal state, the DHCP server uses the LDAP server with the highest assigned preference (lowest preference number). In a less than optimal state, the DHCP server uses the next LDAP server of lower preference (increasing preference number). If the preference values are the same (or not set), the DHCP server reverts to round-robin mode with the LDAP servers."
Symptom: When upgrading from 5.5.x to 6.2.x, host RR aliases are not autopopulated with CNAME RRs. Workaround: Manually remove and re-add CNAME RRs.
Symptom: RFC 3046 (option 82) states: "No 'pad' sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option." The built-in options definition has 255 end improperly defined as a suboption for option 82.
82 relay-agent-info binary (AT_BLOB)
1 circuit-id binary (AT_BLOB)
2 remote-id binary (AT_BLOB)
4 device-class unsigned 32-bit (AT_INT)
5 subnet-selection IP address (AT_IPADDR)
6 subscriber-id string (AT_NSTRING)
7 radius-attributes binary (AT_BLOB)
8 authentication binary (AT_BLOB)
9 v-i-vendor-opts vendor-opts (AT_VENDOR_OPTS)
150 cisco-subnet-selection IP address (AT_IPADDR)
151 cisco-vpn-id binary (AT_BLOB)
152 cisco-server-id-override IP address (AT_IPADDR)
181 vpn-id binary (AT_BLOB)
182 server-id-override IP address (AT_IPADDR)
255 end no len or val (AT_NOLEN)
Workaround:
None.
Symptom: For CNR 6.2.3: When a zone's region is set at the Regional CNR, a sync will not propagate the region value for that zone to the local CNR cluster. Workaround: After performing a sync, go to the local CNR cluster, and manually enter the region information for the zone.
Symptom: If a regional cluster has never been synchronized, CCM will fail when it attempts to poll subnet utilization data for the cluster. Workaround: Be sure to establish correct connection credentials and synchronize the cluster. If connection to the cluster is not possible, remove the cluster from the configuration, or disable polling.
Symptom: The DHCP server returns two copies of the same vendor option value to the client. Conditions: This situation can occur if you configure option-43 into the policy v4-reply- options attribute in 6.2, or the dhcp-reply-options attribute in earlier releases. Workaround: Do not configure option-43 into the v4-reply-options or dhcp-reply-options attributes on any policy in the server configuration.
Symptom:
In the CLI, if the command
import option-set
Symptom: The DHCPv6 fqdn option is defined to have 2 fields in RFC4704 - first field is a "flags" byte second is an encoded DNS name. The current builds have the second field as AT_NSTRING, this should be AT_DNSNAME. Workaround: Redefine the second field as AT_DNSNAME type.
Symptom: The DHCPv6 server returns all configured v6 reservations for a client in the first IA-NA, when it should be returning any reserved leases in the IA-NA in which the client requests the lease. Workaround: None
Symptom: The DHCPv6 server drops any message that fails to match the RFC definitions for option values. As an example, a test client sending the Elapsed Time option value as 4 bytes instead of the defined 2 bytes, causes the entire message to be dropped. Workaround: There is no workaround.
Symptom: When running the cnr_tactool, the RIC server and security kit install logs as part of the cnr_tactool bundle that is generated. Workaround: There is no workaround for this issue. These log files may have to be manually provided separately, if necessary.
Symptom: The DNS HA message sent and received counters ha-msg-zonesync-sent, ha-msg-rrupdate-sent, ha-zonesync-revc and ha-msg-rrsync-recv may not properly increase as these HA messages are sent and received. Workaround: None
Symptom: DHCP server extensions cannot set AT_TIME option values outside the default range of 1 - 255. Conditions: Attempting to set the dhcp-rebinding-time option value in an extension to a value of more than 255, will result in a failure to set the value due an improper range check. The following option codes are non-editable in 6.2 and later:
51 dhcp-lease-time 58 dhcp-renewal-time 59 dhcp-rebinding-timeWorkaround: For those option types that are AT_TIME, and are flagged as CONSTANT (non- editable), you can create a custom option set and import it to change these to AT_INT. For those option codes that are editable, change the option type from AT_TIME to AT_INT if you need to set these in extensions.
Symptom: The CCM server fails to enforce zone constraints when an administrator that is constrained by name regular expression match attempts to delete a zone for which he is not authorized. Workaround: Use an explicit zone list to constrain the administrator.
Symptom: HTTPS Install CNR 6.2 - User guide error Conditions: In 6.2.1 User Guide, Chapter 2 is stated: Access Security At installation, you can choose to configure HTTPS to support secure client access to the Web UIs. To enable secure communication, you must have the Cisco CNS Network Registrar Communications Security Option Release 1.1 installed. This is wrong. Workaround: The installation guide provides the correct information which is just to answer that you want HTTPS during installation and to provide the keystore file. The security kit is NOT required for HTTPS to the Web UI.
Symptom: The cnr_exim utility can abort due to memory corruption when exporting Network Regustrar data in text format. Workaround: Export data in s-expression format using the -t option.
Symptom: One of the HA DNS servers remains in the connection establishment state even when their partner HA DNS server may be down. Conditions: On rare occassions, if either the main or backup HA DNS server go down after an initial connection has been made, the partner server may not detect that the partner is no longer running. Workaround: If this issue occurs, reloading the effected server will cause the condition to clear.
Symptom: It is not possible to enter an option value on a policy for the v6 option-11. The built-in option definition uses AT_BLOB with a repeat count of 8 to define one of the suboptions, and this type fails to parse properly. Workaround: Redefine option-11 and change the suboption type for the "auth" field from AT_BLOB (binary) to AT_INT8 (unsigned 8-bit). This change will allow entering option values on a policy for the v6 option #11. Because this is an option format that the server is required to use, the built-in option definition is not directly editable. To override it, you must import a custom option set.
Symptom: Network Registrar currently does not support TFTP files larger than 32 MB. Workaround: None.
Symptom: Hosts are automatically created for each protected A record in a zone. But there is no way to automatically recreate hosts for existing A records, or repair parent zone references, if these somehow fall out of sync. Workaround: Delete and re-add the record to recreate the host object.
Symptom: When the DHCP server experiences a timeout on an LDAP connection, such as when the LDAP server is unreachable on the network, it marks the connection as inactive, and should cease using that connection until it can attempt a reconnect, but instead continues to use the connection while there is sufficient client load on the DHCP server. This causes a primary LDAP server to continue to be used when instead the DHCP server should begin using the secondary LDAP server as soon as the timeouts are experienced. Conditions: Disconnecting the network between the DHCP server and an LDAP server will cause the DHCP server to experience timeouts rather than LDAP errors, and if there is sufficient (fairly heavy) client load, the DHCP server continues to use the connections that just timed out, instead of trying other connections. Workaround: There is no workaround. If the client load is light enough, the DHCP server does correctly mark the connections
Symptom: In rare circumstances, such as when the CCM database becomes unreadable, the CCM server can fail when a user attempts to add a scope to a local cluster. Workaround: Ensure that the database is in working order, either by using the system db recovery tools or restoring from a backup.
Symptom: The DHCPv6 packet processing attempts to save the relayed message in the lease6 object in the database, but strips out the client portion of the message and adjusts the option codes and lengths in the copy of the packet that it makes. However, it writes the option codes and lengths in host order rather than in network order. This is a problem on Intel platforms, where host ordering differs from network ordering. Conditions: Any DHCPv6 packet with a relayed message will store an invalid relay message on the client-relay-message attribute of the lease6. Workaround: There is no workaround. The actual option values are correct, but may be unparseable.
Symptom: If your DHCP server configuration contains custom option definitions with suboption definitions, a small amount of memory is leaked on every server reload ( about 100 bytes per custom suboption definition ). This is only an issue for custom suboption definitions. Workaround: Remove any custom option definitions that have suboption definitions. There is no other workaround except to monitor the memory usage and completely stop the dhcp process periodically.
Symptom: When HA is enabled, heart beat message logs could fill up the dns log file. Workaround: Disable ha-details with the dns server log-setting attribute.
Symptom: In cases where there are options in an incoming DHCP packet that have option code 220, which is the option code used by the cisco-vpn-id option, and that option does not parse correctly as a cisco-vpn-id option (which in general it would not unless it really came from a Cisco relay agent), and if the server is configured for LDAP client class queries, then the DHCP server will fail. The invalid options will be signalled by message number 05490 and the intent to drop the packet by message 18499. If the server is also configured for LDAP client class lookup, then the server will likely fail. Workaround: There is a very nice workaround for this problem if multiple MPLS VPNs are not, in fact, being used (and they rarely are used). The DHCP server attribute ignore-cisco-options should be configured to have the value "vpn-id, cisco-vpn-id, subnet-alloc." If this is done correctly, when the server is reloaded, there should be three messages with number 05989 indicating that the three Cisco specific options are going to be ignored. The server should thus ignore any options with values of 220, 221, and 185.
Symptom: Customers using LDAP lookups may find that the DHCP server uses more and more memory over time. This is because the server is internally leaking memory for a data structure it uses for client data. Workaround: Periodically stop CNR and start it. (Just reloading the DHCP server is unlikely to fix the memory leak.) Then upgrade to CNR 6.2.
Symptom: The regional CCM server will leak memory each time it updates a cluster's replica data or re-synchronizes the cluster. Over time, the server may exhaust all available memory, which will cause it to fail. Workaround: Periodically restart the CCM server to avoid excessive memory growth.
Symptom: The CCM server may crash when processing current utilization data from the DHCP server, if no subnet data is reported. Workaround: The server agent will automatically restart the CCM server, if it fails. No further action is required.
Symptom: The CCM server returns the wrong object when a CCMFailoverPair is added using the 'AddObject' method. Attempting to use this object in subsequent method calls may generate a 'NOT FOUND' error. Workaround: Use the 'GetObjectByName' method to retrieve the correct object for use in subsequent method calls.
Symptom: At CCM regional, large lists of replica data, such as 500,000 reservations, may appear to be missing entries. This occurs when the CCM replica database has run out of database locks, because these are required to retrieve the data. No error is generated, and a partial list is returned Workaround: In expert mode, edit the CCM Server configuration to set a higher value for replica-db-lock-count. You must restart the server, using the server agent, for this change to take effect.
Symptom: DNS server will fail if the operating system has more than 1024 file descriptors per process. Conditions: This affects CNR 6.1.x and CNR 6.2.x UNIX systems Workaround:
- Remove any ulimit -n statement that was added to the /etc/init.d/nwreglocal script.
- Verify that the OS's default is set to 1024 and not something higher (ulimit -a). Potentially you could change the nwreglocal file (above) to contain a ulimit -n 1024
A short-term alternative workaround is to disable TCP-based resolution. Set the "requery-over-tcp" (vis-z) to false. This will revert to older behavior of NOT retrying truncated responses over TCP. It may be a suitable alternative if these large datasets are not critical to the customer, but maybe just queries caused by clients putting ads on a web page or something else non-critical.
Symptom: After running the secondary zone command promote-to-primary and reloading DNS, it is possible for the server to lose many of the resource records that existed on the zone. Workaround: As an alternative to using the promote-to-primary command when a primary server is down, one could either restore from the primary's most recent backup or setup HA DNS and have a backup DNS server automatically take the roll of the downed machine.
Symptom: The server may silently drop client packets under certain circumstanes. This is only a packet traceability issue. Conditions: If a client sends a DHCPREQUEST with dhcp-requested-address option specifying an address that has no corresponding scope configured and with a dhcp-server-identifier option, the server silently drops the packet. Workaround: None required. This only impacts the traceability of actions in the server as the server may have logged that the packet was received, but not what happened to it during processing.
Symptom: The consistency rules on "Missing PTR Records" output displays all records as not having corresponding reverse zone while they are able to successfully look up both forward and reverse entries, if the records are contained in a parent zone rather than in the Class-C reverse zone. Workaround: None
Symptom: Setting tsig-processing attribute to other than the default could cause the DNS server to fail when sending a zone transfer. Workaround: Reset the default setting for tsig-processing:
nrcmd> session set visibility=3 nrcmd> dns unset tsig-processing nrcmd> dns reload
Symptom: Under the "Edit Scope" page, selecting a Template and choosing "Apply Template" does not update the scope's range to match the template's range expression. Workaround: Delete the range prior to applying the template.
Symptoms: When you install Cisco Network Registrar with the local installation, the "localhost" cluster is created and its "ipaddr" field is set to the machine's current IP address. If you change the machine's IP address subsequently, you must edit the "localhost" cluster and enter the new IP address in the "ipaddr" field. Because this address is used for communication and synchronizations between partner machines when you configure DHCP failover or HA DNS, you should not set the localhost IP address to "127.0.0.1" (also know as the loopback address). Conditions: Internally, Cisco Network Registrar always uses the loopback connection for localhost message processing, regardless of the cluster object configuration - - it is not necessary (or desirable) to explicitly configure the localhost IP address as "127.0.0.1" for this to happen. Workaround: If, despite this, you configure the localhost cluster address as "127.0.0.1", then you must specify the failover server addresses, and/or the HA server addresses, when you configure DHCP failover and/or HA DNS. For DHCP failover, you must specify the main-server and backup-server. For HA DNS, you must specify the ha-dns-main-server and ha-dns-backup-server. These fields must be set with the actual IP addresses for the main and backup partners.
Symptom:
In the web UI, the List DHCP Leases for Scope
nrcmd> lease address
Workaround:
If you log out and log back in to the Web UI, the lease list page shows the
correct current status of the leases. However, subsequent DHCP server
activity during the current Web UI session may again result in a
discrepancy
between the data on the Lease List page and the data on the Lease Detail
page. To reliably ascertain the current lease state, use the CLI command:
nrcmd> lease
Symptom: If the Network Registrar product installation for the Linux platform is unsuccessful, under certain circumstances the installer, as is done on the other supported product platforms, generates a script named debug_install in the base product installation directory. This script is intended to reproduce the failure without having to re-run the product installation program. Due to a logic error, several required supporting files are removed as part of a cleanup effort when exiting the installer after failure, rendering the debug_install script inoperable. Workaround: There is currently no workaround for this defect.
Symptom: Force-available does NOT clear the current lease hostname and attempts to re-discover using the existing possibly disambiguated name, so to clean up names that are disambiguated you need use the following workaround: Workaround:
1. NRCMD> dhcp disable use-dns-update-prereqs
NRCMD> dhcp reload
2. Force available the client's lease
3. Disable the original lease forcing the device to get a
different lease (Not already containing -1 hostname) at the
Next Discover.
4. Reboot the device
5. Check for proper (non "-1") FQDN in DNS
6. Go back and re-enable the previously disabled lease so that it
can be used by someone else.
Symptom: When doing a snmpwalk, the walk does not traverse the MIB tree correctly. Workaround: None
Symptom: When upgrading to 6.2.x from a prior release, scope templates are not upgraded. As a result, DNS update and address trap configuration formerly stored in the template are lost. In addition, the embedded policy, if present will lose any reply option or vendor option settings that were configured. Workaround: Manually re-enter the required data in the upgraded configuration.
Symptom: Extension point Response dictionary Data item lease-relay-agent-info is not documented in the Network Registrar 6.x User Guide. Workaround: None.
Symptom: Either the main or the backup DNS HA server leaks memory if the zone data synchronization is aborted while transferring a large message. Workaround: Avoid interrupting the synchronization state by not reloading or stopping the servers until synchronization is complete.
Symptom: The DHCPv6 server will drop packets for which it cannot find a prefix (and link) before doing client-classing. Thus, it can not pick up VPNs configured on client-classes or client-entries. And, even if it finds the link, it will ignore any VPNs specified by the client-classes or client-entires. Workaround: None. VPN support for DHCPv6 is not available.
Symptom: When DNS HA is enabled, the HA DNS main server will send notifies to the HA DNS backup, which will then be refused. Workaround: None
Symptom: If you use the pre-dns-add-forward extension point to set a new hostname on a lease, the new name is used in dns but is not stored properly on the client object in the lease database. When the lease expires, the DNS information is not deleted. Workaround: There is no workaround.
Symptom: It is not possible to turn off the synthesize-reverse-name attribute on the DHCP server.The attribute will display as DISABLED or FALSE, but internally the DHCP server always resets this attribute to TRUE in the running configuration. Workaround: None
Symptom: The force-xfer operation on a secondary zone does not work. The log indicates that SOA queries are sent, but no responses are received. Additionally, all normal zone transfers use TCP due to failed SOA/IXFR queries. Conditions: This occurs with the 'query-source-port' DNS global configuration setting has been set to a value other than either '53' or 'unset' (which is its default setting), and the 'transfer-source-port' configuration setting is either unset, or set to '53'. Workaround: Either unset the 'query-source-port', or set 'transfer-source-port' to a specific value of a port that is not in use.
Symptom: If the option-set contains an underscore in the name field, you will encounter an error when you try assigning a value to this option at the policy level in the webui. Error message is: "No Option number selected" Workaround:
- Changing the identified lines "_" (underscore) to a "-" (minus) fixes problem. - Use the CLI policyFurther Problem Description:setvendoroption c1100 my_test "(241 10.1.1.1)"
Example option 43:
given the following option-set:
# Version: 1
# example option
#
{
( id-range = 1 )
( name = my_test ) <=====
CAUSES ERROR
( vendor-option-string = "Cisco AP c1200" )
( children = [
{
( id = 43 )
( name = c1200 )
( base-type = AT_BLOB )
( children = [
{
( id = 241 )
( name = controller )
( base-type = AT_IPADDR )
( repeat = ONE_OR_MORE )
}
] )
}
] )
}
# ------------ end test option --------------
The complex option-set is defined as follows:
- select specific option-set under "dhcpv4 vendor options" section. click
select
- from drop down select the vendor-option
- enter the value in complex format:
( 241 10.1.1.1 )
- Click Add option
Error message at the top of the screen in red states:
"No Option number selected"
Symptom: The CCM server leaks memory when a failover-pair object is deleted. This leak is very small, but over time, it may cause the process size to grow. If the process size exceeds available capacity, the server may crash. Workaround: If the CCM server process grows too large, restart Network Registrar.
Symptom: There is no way to turn off nightly backups in Network Registrar because the cnr.conf file does not provide a way to disable shadow backups. Conditions: The cnr.conf file does not provide way to disable shadow backups. Workaround: A partial workaround can be obtained by redirecting the server to backup non- existent input and output directories and files. Note: This is only a partial workaround because the legacy RAIMA database (/var/nwreg2/local/data/db) is not affected and will continue to be backed up. Use the following parameters in cnr.conf (/opt/nwreg2/local/conf/cnr.conf):
cnr.backup-dbs=/tmp/dummy cnr.backup-files=/tmp/dummy cnr.backup-dest=/dev/null
Symptom: Due to some recent changes, customers running with the use-dns-update-prereqs attribute disabled may notice that the actual database write activity on their DNS Primary server has increased. Note: This may only occur once per lease. It is likely related to CSCsi05706. Workaround: If this becomes a problem, re-enable the use-dns-update-prereqs attribute.
Symptom: The Web UI may display a disparity in the SOA TTL value between the DNS server view and the CCM server view when looking at the zone's Active RRs. This disparity occurs during upgrades from versions of Network Registrar prior to 6.2. In this scenario, the DNS server converts the SOA TTL value from a value that tells it to use the zone default TTL to the actual zone default TTL value. Any changes to the default TTL of the zone are not then propagated to the SOA RR. The differences in SOA TTL values show up when performing a Zone Distribution sync report because the SOA records require synchronization to converge on using the zone default setting again. Workaround: After you upgrade to Network Registrar 6.2 or later, perform a Zone Distribution sync to reset the SOA TTL to use the zone default setting.
Symptom: The nrcmd "dhcp getstats [[all | server [,] failover [,] dhcpv6] sample" command will return an "invalid" error if the server is not configured to collect sample counters. The error message could be more informative that the requested feature is not enabled. Workaround: None.
Symptom: While under load, if errors are generated in scope propagation, the returned error list can become corrupted and cause a CCM server failure. Workaround: There is no workaround. However, the server agent will automatically restart the CCM server if it fails.
Symptom: The CCM server will leak memory whenever a zone or any of its protected resource records are deleted. This may cause the server to crash, if the process grows sufficiently large and exhausts available memory. Workaround: Restart the server periodically to avoid this issue.
Symptom: The current utilization report always shows zeros for subnet utilization when run from the CCM regional server. The CCM server log shows the message request returned an AX_SCP_PERMISSION_DENIED error. Workaround: Connect to the local cluster to view the report.
Symptom: After upgrading (to 6.1 or 6.2), all client-class names are lowercase which can result in the Web UI not showing the client-class when editing existing objects. Workaround: None. Further Problem Description: While the web UI fails to show the client-class on other objects in the pull- down, the client-class is still set and will be retained (unless changed in the pull-down list). The Web UI should be selecting the client-class using a case-blind comparison but is not. CCM and the DHCP server always treats the client-class names as case blind.
Symptom: The ccmsrv process crashes if a configuration change is attempted through nrcmd or web UI. Conditions: The changelog.db file is missing. Workaround: Restore the appropriate database directory from the nightly backup.
Symptom: The CLI permits entry of an option code (attribute name is 'id') that is out of range for the specified option definition set. For example, it is possible to create an option definition with an option code of 65536 in a v4 option definition set. Workaround: Avoid entering option definitions with out-of-range option codes, there is no other workaround.
Symptom: If a role that is configured on a 6.1 local cluster specifies 'By Owner', 'By Zone' or 'Edit Owners', these attributes are cleared when the role is pulled to a 6.2 Regional server, because they are instead represented by 6.2 constraints. When the role is pushed again, the 6.1 checkbox will no longer be checked, effectively removing all zone permissions from the user. Workaround: Manually reset these attributes on the local 6.1 cluster.
Symptom: Under some conditions, the HA DNS backup server may hard code the TTL value of the SOA RR as a result of receiving a DNS RR update message from the HA DNS main server. As a result, the SOA RR may show up as requiring synchronization when performing a Zone Distribution Synchronization or an HA Synchronization using the UIs. Workaround: Running the Zone Distribution sync or HA sync should restore the correct (default) value to the SOA RRs. Until you install a patched version of Network Registrar, however, subsequent DNS updates that are processed by the HA DNS pairs may cause the SOA TTL to become explicitly set again.
Symptom: On upgrade to 6.2, vendor option data in regional policies, and embedded policies in regional client-class objects are not upgraded. In addition, policies are not downgraded when pushed to a 6.1 cluster. As a result, any reply options or vendor options configured in the policy will be lost. Workaround: Manually create the required configuration for each version, and avoid using regional push/pull features for these policies.
Symptom: When running failover sync from 6.2 to 6.1 partner, the address trap configuration, if configured, is not migrated to the 6.1 scope configuration. Workaround: Configure traps globally on the 6.1 partner to ensure traps will be generated.
Symptom: When nrcmd reports server statistics, there is no indication of the time at which those statistics are reported. Workaround: Record the time manually.
Symptom: When the DHCP server sends a DHCPNAK message, it does not include the relay- agent-info option (82) information in the NAK, which technically violates the RFC-3046 as that requires the server to always echo this option. Workaround: None.
Symptom: A /8 subnet mask is shown in the "primary subnet" field in the address space details for a certain scope. The proper subnet mask should be /31 or /32. Workaround: None
Symptom: On upgrade, an invalid failover pair configuration means your CCM server will not create the new failover pair object in the CCM database. However, the DHCP server will detect the invalid configuration in its MCD database, and fail to start. Conditions: The most common way to trigger this condition is to migrate the pre-6.2 configuration from a different server as part of the upgrade. The old failover pair configuration will be invalid, because no IP addresses match the localhost. Workaround: Manually create the new cluster and failover pair objects in the new server. Then using expert mode in the web UI, run the CCM Failover Pair Sync from the List Failover Pairs page, to remove the old objects in the MCD database, and replace these with the newly created failover pair object. At this point, the DHCP server can be restarted.
Symptom: RedHat Linux support is only for 32 bit Kernel. Documentation should clearly point out that we only support the 32-bit RH operating systems. Conditions: Network Registrar Linux 6.x and RedHat 3.0 and 4.0 Workaround: Use 32 bit RedHat 3.0 or 32 bit RedHat 4.0 releases,
Symptom: A duplicate primary subnet will be created for each secondary scope, when CCM is rebuilt from MCD, after the ccm db directory is deleted. Workaround: In expert mode, navigate to the DHCP Server page, and run 'sync from DHCP' to delete the duplicate subnets.
Symptom: With HA DNS configured, the backup CCM server will hang when host edits are performed either on the main or the backup. Conditions: This occurs if the backup is able to connect to itself using its localhost configuration, because it mistakingly attempts to forward the change. Workaround: Unset the user credentials on the localhost cluster to ensure the attempt to connect to itself fails.
Symptom: The CCM regional server will leak memory each time a local cluster configuration is restored fom the the replica database. The leak will be proportional to the size of the local cluster configuration. Workaround: Periodically restart the server to avoid excessive memory growth.
Symptom: The DHCP server is including deactivated scopes in the total count of leases available when Network or Selection-tag trap aggregations are configured. This can result in traps failing to fire on such aggregations when the count of leases available is below the configured threshold. Conditions: When a Network or Selection-tag trap aggregation is configured on the DHCP server, and some scopes within the trap aggregation are deactivated, the server continues to include the deactivated scopes within the count of available leases for the trap aggregation. Workaround: Do not use Network or Selection-tag trap aggregations if you also use the deactivated mode on any Scopes.
Symptom: Occasionally, the regional CCM server may crash when completing a failover pair sync operation. Workaround: There is no workaround. However, if this error occurs, the server agent will automatically restart the server.
Symptom: The CCM server may leak memory when performing add or modify zone operations on the regional server, or a HA pair. Workaround: Periodically restart the server to avoid the risk of running out of memory.
Symptom: When CCM fails to access the license file, a core dump occurs. Conditions: This has been seen on CNR 6.2.3.2. Workaround:
1. Delete the file conf/product.licenses. 2. Restart CNR. 3. Re-enter the license key.
Symptom: The CCM server is inconsistent in its handling of local zones that have their zone distribution set to 'none', when these are pulled into the regional server configuration, or synchronized using HA pair sync instead of local zone distribution sync. On the regional server, this occurs because the zone is always assigned to a zone distribution when it is pulled. As a result, the zones will be grouped with the main zone distribution and included in the sync that is run from regional. When running HA pair sync, the assigned zone distribution is ignored, and all primary zones are always included. Workaround: Only run zone distribution synchronization from the primary local cluster, when using the local exclude feature. To exclude the local loopback zone in HA pair sync, run HA pair sync from the regional server.
Symptom: The CCM regional server leaks memory each time pull replica zone data is run. The leak is proportional to the number of primary zones in the replica data. Workaround: Periodically restart the server to avoid exhausting available memory.
Symptom: The CCM regional server will leak memory each time the Sync All Zone Distributions function is run. Workaround: Periodically restart the server to avoid exhausting available memory.
Symptom: When zone distribution or HA sync is run on the HA backup, the CCM server always attempts to update the DNS server, regardless of the HA mode. When the HA pair is in normal mode, the sync reports a failure because the DNS server refuses the RR updates. Workaround: This error can be safely ignored, because all RR updates must be synchronized from the HA main, when running in normal mode.
Symptom: When configuring a DHCP Failover pair or HA DNS pair, the main and backup server addresses are derived from the IP addresses associated with the specified main and backup clusters. However, if the cluster IP addresses are changed after the pair has been created, the new addresses are not updated in the server configuration. Workaround: Re-edit the pair configuration to force an update of its IP addresses.
Symptom: A primary DNS server could become flooded with full zone transfer requests as its secondary servers reach the ixfr-expire-interval on their secondary zones. One effect that might be seen is that the primary logs many messages about reach it's concurrent zone transfer limit. Workaround: This feature can be disabled by setting ixfr-expire-interval=0 on all the secondary servers as follows:
nrcmd> dns set ixfr-expire-interval=0 nrcmd> dns reload
Symptom: Importing or pulling data via HA sync on a GSS/CNR appliance can cause CNR DNS to respond with FORMERR to GSS requests. This is mainly an issue for situation where either one of the HA partners is not running GSS or when importing data from a non-GSS CNR configuration. Workaround: CNR DNS server needs to be reset to understand GSS requests as follows on the GSS/CNR appliance:
nrcmd> session set visibility=3 nrcmd> dns enable gss-load-balancer-appliance nrcmd> dns reload
Symptom: CCMSVR uses a large amount (50% or more) of CPU after navigating log search pages through the webUI. Conditions: Can occur in 6.2.x. Workaround:
1) Move the existing server log files to backup versions. 2) Restart the CCM server. The ccmsrv process restarts.Further Problem Description: This situation occurs if there is a line in a server log file exactly 8192 bytes long.
Symptom: A message in the DHCP log that the "Resolution queue reached its configured limit (1000). The request will be dropped" baffled the user in that no documentation was provided for it. Conditions: The resolution-queue-max-size DNS attribute is the relevant configuration setting, but is available only in Expert mode (CLI visibility=3). Expert mode (viz. 3) attributes are generally not documented in the User Guide, CLI Reference Guide, or CLI online help (nrcmd> help dns properties). The description of the resolution-queue-max-size attribute is:
This value imposes a maximum limit of queries on the outgoing queue. However this maximum does not apply for zone transfer requests, notify requests, and root primings. (It is a bounded integer from 10-50000 and defaults to 5000.)Workaround: In CNR 7.0 this attribute description is available in the local cluster web UI in Expert mode on the Edit DNS Server page. Click the name of the attribute to get the help description.
Symptom: The CLI will let you create remote-dns entries that differ only in insignificant bits. For example, you could create two entries for 10.1.0.0/16 and 10.1.1.1/16, which in fact point to the same network. Workaround: Delete the duplicate entry.
Symptom: The cnr_exim tool will not overwrite an existing AddressType object, even when the -o flag is specified. Workaround: To import these objects, you must first delete the existing objects.
Symptom: If a user does not have sufficient permissions to access the requested configuration, the data is not exported. However, the Permission Denied error is also not displayed, which may make it difficult to determine why the data export failed.
Symptom: The current method for starting and stopping the Network Registrar servers on Unix imposes a 64 character installation pathname length, due to the length of the the process string returned by the long form of the 'ps' command on Solaris/Linux.
Symptom: A scope template evaluation error may not be returned for certain invalid arguments to the create-option, such as when an integer value is enclosed in quotes. The function will appear to work, but in such cases, the embedded policy option will not be created.
The search function for the zone lists on the zone distribution page may fail to find certain zone names. In these cases, the list returns to the first page.
Symptom: The regional web UI may take as long as 5 minutes to save 200,000 leases in text format.
Symptom: For subnets in a failover configuration, the refresh icon may fail to correctly refresh the View Current Utilization Report. b Workaround: Click the OK button on the page and reselect the report on the View Address Space to view updated data.
Symptom: When editing zone-top RRs, you can create an invalid configuration by adding a CNAME RR type that conflicts with existing RRs. The server will reject this record on reload and perform a full reload to rebuild the zone.
Symptom: The DNS server retains zone history (changes) in its changeset DB. Stale history (history no longer needed) is periodically trimmed away. When a zone gets deleted, the changeset DB relinguishes the zone's history. Unfortunately, it fails to "free" this history, causing memory leaks. Conditions: This leak only occurs due to a zone deletion (or zone re-add) in which the zone has history.
Symptom: For versions prior to CNR 6.2:
If you configure the override-namespace or default-namespace attributes in the client or client-class, you might expect that the DHCP server will send the vpn-id option or vpn-id suboption of the relay-agent-info option to the DHCP client or relay that is next downstream. However, it does not, at present, do this.
In CNR 6.2:
If you configure the override-namespace or default-namespace attributes in the client or client-class, you might expect that the DHCP server will send the vpn-id option or vpn-id suboption of the relay-agent-info option to the DHCP client or relay that is next downstream. At present, it only sends the vpn-id option, and not the vpn-id sub-option of the relay-agent-info option to the downstream client. Moreover, it will always send the vpn-id option in any situation where the output packet is going to a vpn which is not the global vpn. This should have no effect on the operation of these clients. Further, this only works at all if you get in the client-class through the normal path of a client-entry lookup, not through the expression of the client-class-lookup-id. Workaround: The only realistic workaround for versions before 6.2 is to write an extension script to run at the pre-packet-encode extension point and in that extension to get the namespaces vpn-id and put it into either the vpn-id option or the vpn-id sub-option of the relay-agent-info option.
Symptom: Internal database warning and error messages, such as running out of locks, are only emitted to the debugging log system and are not part of the normal log files. Conditions: If the CCM server is behaving oddly with database queries (Get<*>List), especially prior to 6.1.0.1, the troubleshooting should include running the CCM server with the debug flag D set to 1, and debug messages should be redirected to the normal log files.
Symptom: SNMP server still recognizes SNMP requests and sends SNMP traps after being stopped in the CLI. Workaround: Stop the SNMP server from the Web UI.
When running the cnrdb_recover, the documentation suggests that you copy all of the log files from the .log subdirectory of the DB database into the directory containing the .ndb or .db file(s).
An alternative is to create a short text file in the .../data/.../ndb/ directory which describes the file hierarchy to the database utilities. This will allow the utilities to find the log files and will thus relieve you of the task of moving the log files.
This text file is named "DB_CONFIG" (and case is significant) and must appear in the .../data/.../ndb directory. It should contain the following two lines:
set_lg_dir logs
set_tmp_dir tmp
Note that the first line has "lg" in it, and that "logs" ends with an 's' character.
You will create this file in the following directories:
.../data/dhcp/ndb
.../data/dns/ndb
.../data/ccm/ndb
Once you have created these files, you can run cnrdb_recover by setting your current directory to one of the above directories, and by invoking the command line:
cnrdb_recover -h . -v
You may leave the DB_CONFIG files in these directories for future use. The fact that our log files for sleepycat files are in a subdirectory called "logs", and temp file in a subdirectory called "tmp", means that, without help, we have to move the logs or database files around in order to do things like run the recovery tool. This can be fixed by creating a file in the ndb directory containing: ipv6-sun# more data/dhcp/ndb/DB_CONFIG set_lg_dir logs set_tmp_dir tmp This is enough so that, cnrdb_recover can be run: ipv6-sun# cnrdb_recover -h . -v db_recover: Finding last valid log LSN: file: 396 offset 1904005 db_recover: Checkpoint at: [396][1903471] db_recover: Checkpoint LSN: [396][1903471] db_recover: Previous checkpoint: [396][1666027] db_recover: Checkpoint at: [396][1903471] db_recover: Checkpoint LSN: [396][1666027] db_recover: Previous checkpoint: [396][764928] db_recover: Recovery starting from [396][1666027] db_recover: Recovery complete at Mon Oct 3 11:55:08 2005 db_recover: Maximum transaction ID 800413ac Recovery checkpoint [396][1904053] db_recover: Recovery complete at Mon Oct 3 11:55:08 2005 db_recover: Maximum transaction id 80000000 Recovery checkpoint [396][1904053] ipv6-sun# !!
Symptom: When a very large synchronization operation is run, the entire changeset must be loaded into the web UI for display, both for the Report phase of the operation and the Run phase of the operation. The Report phase changeset report is not released prior to loading the Run phase changeset, which doubles the memory required for the function. Once the server's memory capacity is exceeded, the web UI's responsiveness is severely impacted. Workaround: Avoid accumulating very large changes between server synchronizations.
Users may have difficulty connecting to the Network Registrar web interface over HTTPS depending on the name of the keystore file used to authenticate the connection. The keystore file name is provided by users when performing the Network Registrar installation. It has been observed that under certain circumstances, the Network Registrar web server will generate a Java exception, which can be verified in the tomcat_stdout log file in the Network Registrar product logs directory. If a user notices that their web interface connection does not display any data, they should check the aforementioned log file for exceptions. It appears that recreating the keystore file using the name 'keystore' or '.keystore' will allow HTTPS connections to properly connect.
Symptom: The push and reclaim functions require that a failover pair pre-exist at the local cluster, and that the servers are kept synchronized, for correct operation. Validation that the pair exists is currently done by name. Conditions: If the CCM regional server, DHCP main, and DHCP backup don't all use the same named failover pair, a 'not found' error is returned. Successful synchronization of the failover pair is not an indicator that the names are consistent, because the validation in that case is done by server IP address. Workaround: Use consistent names on all servers.
Symptom: If background polling to update a cluster's replica data is scheduled while a manual request to update the cluster's data is under way, the replica data may not be updated correctly. When this occurs, a 'general error' is returned. The background polling may also purge the cluster's replica data, and reinitialize its copy from the local cluster. Workaround: Ensure polling is complete before attempting any further manual updates. This can be confirmed by examining the CCM server log.
Symptom: You may experience inconsistencies between the CLI and the webUI when adding a DNS RR to an existing RR nameset. From the CLI, the following may occur:
nrcmd-R> zone test1.com addDNSRR host1 txt "this is a test" 316 Invalid - name: host1 ttl: 0 type: TXT data: "this is a test"When adding a DNS RR to an existing RR nameset from webUI's "List/Add DNS Server RRs for Zone zonename" page, the RR add succeeded (with the protection state changed to "protected"). Note that you cannot have a mixture of protected and unprotected RRs in the same RR nameset.
Symptom: CNR 6.2 - When importing BIND files in either named.conf or named.boot format that contain CNAME records. After import, doing Filter RR for the zone shows the CNAMES but when checking on hosts TAB in webUI, there are no Aliases created for them. Workaround: none
Symptom: After upgrade from pre-6.2 to 6.2.x/6.3.x, zone reported extra RR's than what is actually there. Workaround: The actual number of records in the zone may be confirmed using the zone cli command ' zone zone_name listrr dns', and obtaining a count of the RRs that are returned.
Symptom:
The CNR CLI returns an obscure error code in response to the
Symptom: When one changes the defttl of a zone, on a subsequent reload, the server should send out notifies. Subsequent IXFR requests should be responded w/ a full zone xfer response. The server may not send out notifies and the server may not respond w/ a full zone xfer response. Workaround: Manually pull a full zone xfer (via CLI command forceXfer) from the secondary after you changed the defttl on the primary. Forcing full xfers only need to be manually initiated on 1st tier secondaries; you do not need to do this on 2nd, 3rd, etc tier secondaries.
It is possible for a DNS secondary to report ADDRINUSE errors when pulling many full zone transfers. The server will reschedule the zone transfers for a later time and eventually the zone transfer should succeed.
Symptom: Upon a full reload, after a long period of running under a heavy load, the server could fail to start up. This problem rarely occurs. Conditions: Under sustained stress, the server might checkpoint a zone with an invalid FQDN for a RR. On a subsequent full reload (which must use this zone checkpoint), the server could core due to this invalid RR name. Note, if the server does not need to fully reload the zone using this zone checkpoint, like an incremental or (typical) minmal reload, the server will not crash. This only occurs on a full reload using this zone checkpoint. A re-checkpoint of the zone in question may remedy the situation by producing a valid checkpoint (a force checkpoint can manually be initiated via the CLI). Workaround: None
Symptom: In some cases, the defer-lease-extension capability of the DHCP server will not function precisely as expected, where it should return the remaining lease time if the renewal is before the expected renewal time, and it should return a full new lease period if the renewal is at or after the expected renewal time. It may return times that are somewhat in variance to these expectations. Workaround: These variations should not cause a client any difficulties.
Symptom: When running in synchronous mode, the regional CCM server fails to forward host alias changes to the local cluster. Workaround: Run zone synchronization to push the changes to the local cluster.
Symptom: You may experience difficulties reloading the DHCP server via the webUI, after deleting an LDAP server configuration. Workaround: Stop the DHCP server, then restart it. Also, avoid switching back a forth between the CLI and the webUI to make DHCP server configuration changes.
Symptom: After adding and deleting multiple zones, the CCM server may get into an out of memory condition when running the zone distribution. Workaround: The secondary server references should be removed and re-added prior to running the zone distribution.
Symptom: If DTRACE of f=9 is enabled, a server is likely to crash whenever the server's log file rolls. Workaround: Do not enable DTRACE of f=9.
Symptom: Address space reports may show the wron value for subnet state. Workaround: Use the Subnet edit page to view the correct state.
Symptom: When connected to a regional cluster, the CLI (nrcmd) might crash after creating one or more client-classes. This crash occurs when you save or exit the CLI. Workaround: Use the Web UI to create new client-classes on a regional cluster, or use the CLI on the local cluster itself.
Symptom: When scavenging is enabled on a zone, RRs can disappear prematurely from DNS. Conditions: DDNS updates that attempt to add an already existing RR do not refresh the existing RR timestamp. These type of updates should refresh the name-set timestamp. Workaround: Deleting and adding back of the same RR refreshes the timestamp on the name- set. Alternatively, a prerequisite-only DDNS update also refreshes the name- set.
Symptom: You may experience difficulties editing RRs containing special characters via the web UI. Workaround: If you require special characters in the data field of the RR, use the CLI to create and maintain these records, and avoid editing them in the web UI. Characters such as '/', '^', '$' or '@' may be particularly problematic.
Symptom: The uninstall of the client-only install returns without deleting any files. One of the options when installing cnr is to select a 'client and server' OR 'client-only' install. If 'client-only' is selected, the install completes successfully. However, when we attempt to uninstall, the script returns immediately without deleting any files. Conditions: The problem only occurs when the 'client-only' install option is choosen. Workaround: Manually uninstall the files.
Symptom: The Network Registrar DNS server may not log the correct client source address when outgoing-packet-detail DNS server log tracing is enabled for TCP packets in a combined Network Registrar/GSS appliance environment. Conditions: This condition is expected to occur when the DNS server's outgoing packet tracing is enabled on a GSS appliance. The defect only affects TCP based communications, as the UDP outgoing packets utilize a different code path for tracing the packet contents. Workaround: There is no workaround to this problem. The loopback interface address utilized by the GSS<->Network Registrar communications will be displayed in the DNS server packet log tracing.
Symptom: From the List Zone Distributions page, if you have previously deleted one or more of the clusters representing secondary DNS servers, but have not updated the Zone Distribution to remove these clusters, and you click the Manage Servers icon, you get a Java stacktrace. Workaround: If you remove clusters, be sure to remove these clusters from the Zone Distribution before clicking on the Manage Servers icon.
Symptom: Although the Red Hat 4 distribution comes with its own version of Java 1.4.2 installed, this version of Java is not compatible with CNR versions 6.2.x and later. Workaround: Install the Java JRE for that platform that is available from Sun (java.sun.com). Java version 1.5.0 or later is recommended.
Symptom: Invoking the following CNR Java API methods can throw an ScpException under certain circumstances: Session.reloadServer(String serverType) OR Session.reloadServer(ScpObj server) Conditions: An exception trace similar to the following may be displayed: Bad id or server not loaded. (TRE_NOTLOADED) com.cisco.cnr.sdk.ScpMsg.getException(...) com.cisco.cnr.sdk.ScpConn.sendRequest(...) ... This typically happens when the server in question - DHCP, DNS, or TFTP, was in the "stopped" state prior to the method invocation. Workaround: Even though the above exception trace is noted, the server in question will have reloaded, essentially denoting that the method invocation did actually work and the error message may be ignored after confirming the corresponding server's startup log file. Also, reinvoking the method to reload the server will no longer throw the exception. Further Problem Description:
Symptom: Reservation doesn't work with lookup type string when assigning client-id from the extension script. Conditions: Problem is experienced only when using reservations with lookup type string and if we're assigning client-id from extension. When expression is used with override-client-id then problem will not occur. Workaround: Use lookup type binary for reservations instead of string.
Symptom: When scavenging and HA are enabled, DDNS updates may be refused during the scavenging period. Workaround: To work around this issue, increase the number of records to scavenge and the pause time between scavenges as follows:
nrcmd> session set visibility=3 nrcmd> dns set scvg-max-records=250 nrcmd> dns set scvg-pause-interval=5s
Symptom: You can use the Session class method setReadTimeout(int seconds) to set a per-connection timeout value. If you are using an SSL-secured connection, however, this timeout value is ignored, and the CCM timeout value (CCMServerConfig.local-scp-read-timeout, which defaults to 20 minutes) is used instead. Workaround: There is no workaround for this issue.
Symptom: For a DNS server with forwarder(s) configured, the server mistakenly increases the statistical counter 'query-timeout' for a query successfully answered by a forwarder. Thus, the 'query-timeout' counter may be artificially large and should consequently be ignored. Workaround: None. Ignore this counter.
Symptom:
On the "DNS Query Responses" chart, the "Forwarding" plot fails to plot changes.
Conditions: Workaround:There is no workaround.
Further Problem Description:Symptom: The DNS server may deadlock under stress when dynamic updates and zone transfers are happening on a zone. Workaround: If the server gets into this state, the cnr server agent should be stopped and restarted.
Symptom: DNS HA Main and Backup may not behave consistently in respect to responding to zone transfer requests when in the process of Synchronizing their data. Workaround: None
Symptom: The web UI Setup Interview displays the DNS server role as "Caching" by default instead of as "Primary". Conditions: When configuring CNR using the web UI Setup Interview, with the DNS server not yet configured the DNS server role defaults to "Caching". The web UI Setup Interview also displays the DNS server role as "Caching" even though a user may have explicitly configured the DNS server to either be a "Primary" or a "Secondary" when a new web UI Setup Interview session is initiated at a later time under certain circumstances. Workaround: The user must create (or the DNS server must already have configured) at least one Forward Zone or one Reverse Zone (non-default) in order to designate the DNS server as a Primary server. Further Problem Description: When no Zones are defined (except for the default Zone), the DNS server is treated as a caching-only server.
Symptom: Virtual Bundles are not discovered when adding devices in Router Management. Workaround: None
Symptom: For scope based failover - where failover disabled server wide and feature is only enabled on specific scopes - sync report list all scopes, including scopes set to either use-server-settings or scope-disabled and not just those set for scope-enabled. Workaround: Manually make configuration changes for the specific scopes with failover enabled on both servers to keep them in sync.
Symptom: The "View Network Tree" page no longer displays the Scope and Selection Tags. It's not possible to get the scope name from the network. Additionally, selecting a Secondary Subnet does not show the Scope that it is assigned to while works for a Primary Subnet. Workaround: None.
Symptom: The CLI (nrcmd) can only be run by at most 14 users (or processes) simultaneously. When the 15 user (or process) attempts to initiate a session, that session will hang until one of the other users (processes) exits the CLI. Workaround: None. Limit the number of simultaneously active sessions to a cluster to no more than 14. Customers might consider using the Web UI or SDK. Further Problem Description: The cnrservagt is limited to 20 pipes. As it typically uses 6 for other tasks, this leaves 14. When a nrcmd user attempts to log in, it connects to the cnrservagt via a pipe and if all of the available pipes are in use, cnrservagt waits for one to become available before accepting the new connection. Ideally, it should close this new connection rather than waiting for an available pipe to establish the connection.
Symptom: In cases where the Evenstore may be kept very busy by DDNS update traffic, the cleanup of files may not occur in a timely fashion. Workaround: None
Symptom: If you create a secondary zone on a secondary DNS server by synchronizing the Zone Distribution on the primary server, then delete the secondary zone on the secondary DNS server, and attempt to recreate it by performing the Zone Distribution from the primary a second time, the synchronization may fail to create the secondary zone. Workaround: Create the secondary zone manually on the secondary server.
Symptom:
The dashboard "DNS Network Errors" chart sometimes fails to plot new data on a page refresh.
Conditions: Workaround:There is no workaround.
Further Problem Description:Symptom:
In the dashboard "DNS Related Servers Errors" chart, the "TSIG Errors / TSIG Attempts" plot does not reflect TSIG bad key and bad sig errors.
Conditions: Workaround:There is no workaround.
Further Problem Description:Symptom: On rare occassions the DNS HA server may get deadlocked when removing data from its database. This is likely to happen when removing many existing zones. Workaround: If the server gets into this state, stop dns, remove the dns/ha data directory and start dns. The HA database will be recreated when the dns server restarts.
Symptom:
If there are some zero data values in the "Incremental Responses" plot in the dashboard "DNS Outbound Zone Transfers" chart, the plot may not be accurate. This symptom can also show up in the "DNS Network Errors" and "DNS Related Servers Errors" charts too.
Conditions: Workaround:There is no workaround.
Further Problem Description:Symptom:
No plot is seen for "Dropped" on the "DNS Forwarding Errors" dashboard chart.
Conditions: Workaround:There is no workaround.
Further Problem Description:Symptom: It is not possible to add user-defined (custom) option definitions to the v4- reply-options and the v6-reply-options attributes on a Policy by the custom name. Workaround: Use the option code number, or the string "option-##".
Symptom: The v4-reply-options and v6-reply-options attributes on a policy do not accept custom option name strings. These attributes use a low-level parsing method that only works on the built-in option definitions. Workaround If you have defined custom option definitions with custom names, use either the option code number or the string "option-###" in these attributes.
Symptom: Installing CNR 6.2.3.2 on windows 2003 SP1 standard edition and receive pop-op window which caption is "Can't run 16-bit Windows program" and the message is "Cannot find ......\SETUP.EXE or one of its components. Check to ensure the path and filename are correct and that all required libraries are available". Conditions: NtfsDisable8dot3NameCreation registry key which is set to 1 and therefore 8.3 names are not created and the system fails to locate directories/files. Workaround: Install program creates subdirectories like C:\TEMP\cnr_6_2_3_2\Windows\install and if they are renamed from cnr_6_2_3_2 to shorter name like cnr for instance, then it works fine.
Symptom: The RIC server does not support routers with IOS version 12.0 or later. Workaround: None.
Symptom: A dialog box containing no text may be displayed when attempting to perform a Network Registrar product installation on the Windows platform if the user that is performing the installation does not have the proper credentials. This dialog box does not indicate the error condition that is preventing the installation from proceeding. Conditions: The behavior described by this defect should only be encountered if the user performing the Network Registrar installation does not have the appropriate Administrator credentials on the Windows host. These credentials can be obtained by either logging on as the system Administrator, or by adding the user's login ID to the system's Administrators group. Workaround: There is no workaround that allows users that do not have Adminstrator privileges to perform the Network Registrar product install on a Windows system.
Symptom: Initial DNS queries to caching servers result in no a record given. A second subsequent query does. Conditions: Occurs on DNS caching servers with 6.1.4.2 with particular domain. Workaround: Unknown Further Problem Description: CNR returns NXDOMAIN on the first lookup attempt, indicating the name doesn't exist. We don't cache that negative response, though, and we do cache the CNAME record. So on the next lookup, we go find the real data. However, the TTLs on this data are set at 20mins, so 20mins later the same thing will happen.
Symptom: At WEB UI when do search within DHCP>DHCP SERVER>view log, may get nothing, just back to "manage server page". Conditions: CNR 6.2. Workaround: When do next search, do not close the search result window (the small one).
Symptom: CNR DNS does not sign a response to a signed query request when the response was generated by querying other servers. Workaround: None
Symptom: When attempting to create a new DHCPv6 Prefix using the CNR web UI, the user may be led to another page for adding in the Prefix under certain conditions. Conditions: When creating a new DHCPv6 Prefix using the CNR web UI, if the user selects a pre-defined Prefix Template to apply to the Prefix being created, and if the Prefix Template being applied is not a valid one, then the user will be led to another page to add the new Prefix. No error message is displayed indicating that the Prefix Template could not be applied. If now, the user attempts to apply the same template available for selection via a selection box, the error message will be displayed indicating that the selected Prefix Template is not a valid Prefix Template. Workaround: Edit the Prefix Template so that it is valid and then attempt to apply the Prefix Template when creating a new DHCPv6 Prefix. Further Problem Description:
Symptom: If you are editing an object, and, while the edit is still in progress, switch from Basic to Advanced mode, or from Advanced mode to Basic mode, fields which were completed in the previous mode show as unmodified in the new mode. Conditions: This would typically happen if a user normally uses Basic mode in the WebUI. Sometimes it may be necessary to switch to Advanced mode to specify fields which are not displayed in Basic mode. While switching the mode is not prevented while an edit is in progress, the fields which have been completed or modified in Basic mode may not retain their changes if you do so. Similarly, changes made in Advanced mode may be lost if you switch to Basic mode while the edit is still in progress. No changes are lost if the modifications are committed or cancelled prior to switching modes. Workaround: Avoid switching modes while an edit is in progress, particularly if you have already made data modifications which you wish to keep.
Symptom: When CCM server crashes, it loses the connection to the SNMP server. Workaround: To recover from this condition, restart the servers by stopping and starting the server agent.
Symptom: Using the Zone List attribute to filter DNS RR's has no effect. The content of Zone List filter elements is ignored during search Conditions: Whenever the DNS search page is used, this problem occurs Workaround: Where it is sufficient to search on a single zone name rather than a whole list of names, use the Regular Expression type instead of Zone List type to create the zone filter element. Where a RRs are required that match one of multiple zone names (that would have been in the list) perform multiple searches using the Regular Expression type zone filter element. e.g. If you would have searched using a list of three zones in the zone list filter element, instead perform three separate searches, each time creating a zone regular expression type filter element. This approach will yield that same resuts, but in three separate batches.
Symptom: CNR rejects multiple request with the message: No more leases are AVAILABLE, unable to respond to DHCP DISCOVER Request. Conditions: This is seen on CNR 6.3.2.3 with configuration scope-edit- mode = synchronous. Workaround: Set the scope edit mode to staged.
Symptom: If you create a LinkTemplate and set its prefix-expr attribute, so that when you create a Link using the template, Prefixes based on the template-root-prefix value should also be created and associated with the new Link, this functionality does not work correctly from the web UI.
For example, suppose you create the LinkTemplate lt-1, and set its prefix-expr to be that given in the online help example, i.e.:
(list
(create-prefix "cm-prefix" (create-prefix-range 32 0x1))
(create-prefix "cpe-address-prefix" (create-prefix-range 32 0x2))
(create-prefix "cpe-pd-prefix" (create-prefix-range 16 0x1))
)
Also, suppose that the PrefixTemplates cm-prefix, cpe-address-prefix, and cpe-pd-prefix
already exist.
If you create a Link using the LinkTemplate lt-1 from the web UI, and specify the template-root-prefix value "9999::/32", the Link is created, but not the expected three Prefixes with addresses "9999:0:0:1::/64" ("cm-prefix"), "9999:0:0:2::/64" ("cpe-address-prefix"), and "9999:0:1::/48" ("cpe-pd-prefix"). Workaround: Use the CLI if you want to use LinkTemplates with prefix-expr to create a new Link and associated Prefixes, as follows:
nrcmd > link link9999 create template-root-prefix=9999::/32 template=lt-1
Symptom: When an error is encountered on the Router Interface Add page, the error is *not* displayed, and you are returned directly to the List page. For example, it is an error to add an interface with an overlapping subnet. The interface is not added, but no error is displayed. Workaround: Check the CCM Server log for "Add Router Interface" to view the error condition that was detected.
Symptom: The PushSubnet operation on a 6.2/6.3 regional CCM server does not support earlier version clusters. An AX_SCP_PRODUCT_VERSION_MISMATCH error is returned. Workaround: None.
Symptom: The webui permits a user in Basic or Advanced mode to delete a Link that has prefixes associated with it. This capability should be restricted to the Expert mode. Conditions: The webui displays a trashcan icon next to links that have prefixes associated with them. Workaround: There is no workaround, other than to avoid clicking on the trashcan icon inadvertently.
Symptom:
The dashboard system metrics table alternatively shows values and then "No data available".
Conditions:In the web UI, the stats-history-sample-interval value on the CCM server was changed to a slower value in expert mode, followed by a restart of the Network Registrar service.
Workaround:The dashboard polling speeds are: Slow (30s), Medium (20s) and Fast (10s). To fix this problem, use the stats-history-sample-interval default value of 10s or set it to a value equal to or faster than the selected dashboard polling speed.
Further Problem Description:Symptom: When creating a reverse zone from a prefix, and the zone template is missing a required attribute such as Nameserver, the web UI returns you to the prefix list page with no error reported. Instead, you should be redirected to the Add Reverse Zone page so that you can specify the missing configuration data. Workaround: In order to use the facility for creating reverse zones, you must supply a zone template which specifies all of the required fields for the zone. These fields are: Serial Number, Nameserver, Contact E-Mail, and at least one name server must be specified in the Nameservers list.
Symptom: If you create a DNS Update Map that references either a DNS HA Pair or a DHCP Failover Pair, and subsequently delete the HA Pair and/or the Failover Pair, you will be unable to display the list of DNS Update Maps in the web UI: instead, you will get an error page with a Java stack trace when you try to access the List DNS Update Maps page (menu pick DNS > Update Maps).
To avoid this situation, delete a DNS Update Map object which reference DNS HA Pair or DHCP Failover Pair objects before deleting any pair objects which it references. Workaround: There is no workaround for this defect in the web UI. To correct the situation, you must delete the defective DNS Update Map object using the nrcmd command-line program. In this example, the name of the defective DNS Update Map object is
update-map-1. Follow these steps:
1. log in to the cluster where the DNS Update Map object is defined 2. nrcmd> dns-update-map update-map-1 deleteYou can then use the web UI to create a new DNS Update Map object, and/or point it at new or existing DNS HA Pair and/or DHCP Failover Pair objects.
Symptom: On rare occasions, the DNS server may fail when it is under query load and reaches its configured memory cache size. Conditions: This issue occurs when the DNS server is configured either as an HA DNS main or HA DNS backup server. Workaround: The DNS server will automatically recover from the failure but increasing the memory cache size may prevent the server from encountering this issue.
Symptom: It is possible that the DNS server continues responding with previously cached entries after the addition of a wildcard entry. Workaround: To workaround this issue, it is best to reload the DNS server after adding wildcard entries.
Symptom: If you use Single-Sign-On (SSO) to connect from the regional CNR's replica class list for zones to the local cluster, you may get an error page and a Java stacktrace, if the administrator name used for the SSO connection has a User Preference of Basic mode, or if the Application default is to use Basic mode. Conditions: The above symptoms will occur if the local CNR cluster was a "greenfield" installation, of CNR 7.0, i.e., if this was not an update installation from a previous version of CNR. Workaround: If this occurs, click on Advanced in the upper-left of the menu bar (Basic will be highlighted). This will restore normal page functionality. If Basic mode is desired, you can then click on Basic.
Symptom: The failover recover process is not sufficiently covered in the user documents. Workaround: A Tech Note is currently being developed to better describe the failover recovery process. The procedures covers the special steps required to recreate a failover relationship where the for backup server has the lease state data and is running in standalone mode.
Symptom: When a new link is added to the server by another user, the refresh icon fails to show the new link. Workaround: Use the 'prev' or 'next' pager commands to refresh the list.
Symptom: DHCPv6 AAAA and PTR records may be left in DNS. Conditions: This should only occur if the forward and/or reverse DnsUpdateConfig changes for a DHCPv6 lease and the server and/or zone if different in the new DnsUpdateConfig. Workaround: None. The records may need to be removed manually. Further Problem Description: The DHCPv6 processing removes the DNS information after having updated the DnsUpdateConfig objects and therefore uses the new, not the previous (used for the add), objects. Thus, if the new objects point to different servers and/or zones, the information may fail to be removed from the old zone.
Symptom: DHCP server process using lots of CPU time. Conditions: This is difficult to detect because this happens when the server is very busy in the first place. It will only occur when the server is out of response buffers. Workaround: None, other than increasing response buffers or otherwise reducing the load on the server. Further Problem Description: The timeout processing within the DHCP server can, under stress conditions, use lots of CPU time for little productive gain (a series of conditions causes it to loop attempting to process the timeouts). This is likely difficult to notice as the server is busy anyway, but this also adds insult to injury as CPU time that could otherwise be used to process the existing responses is spent looping in the timeout processing for little productive gain.
Symptom: The cli command lease-notification incorrectly reports the mask on all scopes as /32. Conditions: All scopes displayed by the lease-notification command have the mask as /32. Workaround: There is no workaround. You may view the scope utilization on the webui address management pages, where the scope mask is correctly displayed.
Symptom: When performing the Push DNS Update Map operation on the regional CCM server, the 'Report' command does not include required zone changes. However, these changes are correctly applied when 'Run' is selected. Workaround: None.
Symptom: TFTP server fails during the put of a file or the get of a binary file in netascii mode. Workaround: Ensure that all tftp put's are done in binary or octet mode, and that tftp get's of binary files are done in binary mode.
Symptom: DHCP extensions dictionary is not fully updated in the CNR documentation. Workaround: A review would need to be done to make sure all available data-items are documented. An example of data-item that is not currently in the dictionary is response-source, available in the lease-state-change extension point.
Symptom: The dhcpv4 'active-leases' statistics counter does not keep an accurate count when failover is enabled. Conditions: With failover enabled, the transition from DISCONNECTED to AVAILABLE on the lease state fails to decrement the 'active-leases' counter. This results in the counter showing an incorrect count at any time after a reload when such leases have transitioned. Workaround: The counter will be accurate immediately after a reload, but only until a lease expires and is updated via its failover partner.
Symptom: The DNS server may disable a zone if it encounters an error adding wildcard and/or glue records while doing a full load from a checkpoint file. Workaround: The zone and RR information should be exported and reimported as follows:
1. Export the configuration: cnr_exim -x -e2. Delete the zone and reload DNS: nrcmd> zone delete nrcmd> dns reload 3. Re-import the configuration: cnr_exim -i 4. Reload DNS once again: nrcmd> dns reload
Symptom: The lease import feature documentation does not cover all scenarios and needs further clarification. Conditions: The import feature is behaving as per design, but the documentation needs to clarify all scenarios. As currently written, it assumes that import-mode is not enabled for the DHCP server, whereas it normally should be set. The correct scenarios are described in the Workaround. Workaround: If for an import request, the DHCP server:
- Is enabled for import-mode and the lease is not already leased to the client, the server accepts any lease time the client specifies.
- Is enabled for import-mode, the lease is already leased to the client, defer-lease-extensions is enabled for the server (the default), and the request arrives before the renewal time (T1), the server uses the existing lease time. If the request arrives after T1, the server gives the client whatever it asks for. (Also, within about 2 minutes of the expiration time, defer-lease-extension is not operative--just to make things interesting.)
- Is NOT enabled for import-mode, it never accepts a lease time longer than the server-configured one. If allow-lease-time-override is enabled for a policy applicable to the request, the server accepts a shorter lease time from the client (although you can set a server expert mode client-requested- min-lease-time attribute that creates a floor for the lease time). If allow- lease-time-override is not configured for any applicable policy, the server ignores the dhcp-lease-time request in the incoming packet and uses its setting.
Symptom: The following response dictionary data items are not working dhcpv6 packets:
lease-vpn-id lease-vpn-name lease-vpn-vrf-name lease-vpn-vpn-id lease-vpn-descriptionYou get the following type of errors in the server log for these: Error Extension 0 18552 Attribute 'lease-vpn-id' is invalid in DHCPv6 response dictionary while processing extension 'test' Workaround: None.
Symptom: Network Registrar product installations can fail on Solaris systems if installing the database directory to a partition that is using the ZFS file system type. The installation log file typically contains entries similar to the following:
/opt/nwreg2/bin/keybuild mcddb db_VISTA Version 3.20 Key File Build Utility Copyright (C) 1985-1990 Raima Corporation, All Rights Reserved initializing key file: mcddb.k01 initializing key file: mcddb.k02 initializing key file: mcddb.k03 processing data file: mcddb.d01, total records = 183119 filesystem blocksize (131072) not supported record: 0 *** db_VISTA database error -907 - database taf/log file errorConditions: This condition is likely to be encountered whenever installing the Network Registrar database directory to a filesystem utilizing the ZFS file system with block sizes that exceed 65536 (64K) bytes. Other common filesystem types on Solaris typically utilize block sizes less than or equal to 64K, and are thus not vulnerable to the behavior described in this defect. Workaround: This defect can be avoided by either selecting an installation location for the Network Registrar database directory that does not utilize the ZFS filesystem, or else by changing the block size used by the ZFS filesystem to 64K or less.
Symptom: When querying for interval counters, inconsistent results could be reported. Condition: This only happens if the query for interval counters follows a query for total counters before 'cache-ttl' attribute in SNMP Server has elapsed. Workaround: If querying for interval counters after a query for total counters, wait for 'cache-ttl' in SNMP Server to elapse.
Symptom: A large number of database transaction logs may accumulate on the CCM regional server without triggering scheduled checkpoint and log file purges. Conditions: By default, CCM runs one thread to service scheduled maintenance tasks such as database trimming, checkpoints, and log file purging. If trimming runs for an extended period of time, usually because a configuration change has made a large number of new records eligible for trimming, the other scheduled tasks will be queued until the current task completes. Workaround: To avoid this condition, make gradual changes to configured trimming parameters that will generate smaller change sets, or periodically stop and restart the servers to interrupt the trimming process and force intermediate checkpoints.
Symptom: Multiple prefixes of type 'prefix-delegation' that are configured with the same prefix address are rejected as invalid. Provided they are configured with non-conflicting ranges, these should be accepted as valid. This issue is limited to prefixes of type 'prefix-delegation'. Multiple prefixes of type 'dhcp' can be configured, and combined with up to one prefix of type 'prefix-delegation'. Workaround: Use extensions to control the address assignment, if multiple 'prefix-delegation' configurations are needed on a single prefix.
Symptom: When clicking on the Refresh ICON (not the browser's refresh button) while displaying a list of DHCPv6 leases for a client, the "title" at the top of the page looses the lookup key and displays "List DHCP Leases for Client LookUp Key null" Workaround: None.