The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter explains how to administer and control your local and regional server operations.
If you are assigned the server-management subrole of the ccm-admin role, you can manage the Cisco PrimeIP Express servers as follows:
Starting and stopping a server is self-explanatory. When you reload the server, Cisco Prime IP Express performs three steps—stops the server, loads configuration data, and restarts the server. Only after you reload the server does it use your changes to the configuration.
Note | The CDNS, DNS, DHCP, and SNMP servers are enabled by default to start on reboot. You can change this using [server] type enable or disable start-on-reboot in the CLI. |
Note | If exit-on-stop attribute of DHCP, or DNS server is enabled, then the statistics and scope utilization data only from the last start (reload) is reported while if the attribute is disabled, information across reloads is displayed. |
You can manage the protocol servers in the following ways depending on if you are a:
The local and regional cluster web UI access to server administration is identical, even though the available functions are different. As a regional administrator, you can check the state and health of the regional CCM server and server agent. However, you cannot stop, start, reload, or view statistics, logs, or interfaces for them.
At the local cluster, to manage the DHCP, DNS, CDNS, or SNMP servers, select the server in the Manage Servers pane and do any of the following:
Along with the Statistics, Startup Logs, Logs, HA DNS Server Status, Start Server, Stop Server, and Restart Server functions, you can also perform other functions when you click the Commands button to open the DNS Commands dialog box.
The server command functions are:
Along with the Statistics, Startup Logs, Logs, Start Server, Stop Server, and Restart Server functions, you can also perform other functions when you click Commands button to open the CDNS Commands dialog box.
In Advanced and Expert modes, you can flush Caching CDNS cache and flush the resource records. Click the Commands button to execute the commands.
Along with the Statistics, Startup Logs, Logs, Start Server, Stop Server, and Restart Server functions, you can also perform other functions when you click the Commands button to open the DHCP Server Commands dialog box.
This page provides the Get Leases with Limitation ID feature, to find clients that are associated through a common limitation identifier (see the "Administering Option 82 Limitation" section in Cisco PrimeIP Express 8.3 DHCP User Guide). Enter at least the IP address of the currently active lease in the IP Address field, then click the Run icon. You can also enter the limitation ID itself in the form nn:nn:nn or as a string ("nnnn"), in which case the IP address becomes the network in which to search. This function is the equivalent of dhcp limitationList ipaddress limitation-id show in the CLI.
In the CLI, the regional cluster allows CCM server management only:
nrcmd> ccm set ipaddr=192.168.50.10
In Basic and Advanced user mode in the local cluster web UI, you can schedule a number of recurring tasks. These tasks are:
To set up one or more of these recurring server tasks:
The following table describes the Cisco Prime IP Express log files in the install-path /logs directory.
Component |
File in /logs Directory |
Local/Regional |
Logs |
---|---|---|---|
Installation |
install_cnr_log |
Both |
Installation process |
Upgrade |
ccm_upgrade_status_log |
Both |
Upgrade process |
dns_upgrade_status_log |
Local |
Upgrade process |
|
Server agent |
agent_server_1_log |
Both |
Server agent starts and stops |
Port check |
checkports_log |
Both |
Network ports |
DNS server |
name_dns_1_log |
Local |
DNS activity |
dns_startup_log |
Local |
DNS startup activity |
|
CDNS server |
cdns_log |
Local |
CDNS activity |
cdns_startup_log |
Local |
CDNS startup activity |
|
DHCP server |
name_dhcp_1_log |
Local |
DHCP activity |
dhcp_startup_log |
Local |
DHCP startup activity |
|
SNMP server |
cnrsnmp_log |
Both |
SNMP activity |
CCM database |
config_ccm_1_log |
Both |
CCM configuration, starts, stops |
ccm_startup_log |
|
CCM startup activity |
|
Web UI |
cnrwebui_log |
Both |
Web UI state |
Tomcat/web UI (in cnrwebui subdirectory) |
catalina.date .log.txt jsui_log.date .txt cnrwebui_access_log.date .txt |
Both |
CCM database for Tomcat server and web UI (Because new files are created daily, periodically archive old log files.) |
Resource Limits |
ccm_monitor_log |
Both |
Resource limit activity. |
Each component can generate a number of log files, each with a pre-configured maximum size of 1 MB. The first log file name has the _log suffix. When this file reaches its maximum size, it gets the .01 version extension appended to its name and a new log file is created without the version extension. Each version extension is incremented by one for each new file created. When the files reach their configured maximum number, the oldest file is deleted and the next oldest assumes its name. The usual maximum number is four for the DNS, and DHCP servers.
Cisco Prime IP Express also has server_startup_log files. This applies to the CCM, DHCP, and DNS servers. These files log the start up and shut down phases of the server (the information is similar to the normal log file information). Server startup log files are useful in diagnosing problems that have been reported when the server was last started.
The number of these start-up logs is fixed at four for a server, and the size is fixed at one MB per server.
Note | Some user commands can create User authentication entries in the Server Agent log because of separate connections to the cluster. Do not interpret these as a system security violation by another user. |
You can check the configured maximums for the DNS, and DHCP servers using [server] type serverLogs show in the CLI, which shows the maximum number (nlogs ) and size (logsize ) of these protocol server log files. You can adjust these parameters using [server] type serverLogs set nlogs=value and [server] type serverLogs set logsize=value . You cannot adjust these maximums for any of the other log files.
Note | A change to the server logs will not take effect until you restart Cisco Prime IP Express. |
When you start Cisco PrimeIP Express, it automatically starts logging Cisco Prime IP Express system activity. Cisco Prime IP Express maintains all the logs by default on:
Tip | To avoid filling up the Windows Event Viewer and preventing Cisco Prime IP Express from running, in the Event Log Settings, check the Overwrite Events as Needed box. If the events do fill up, save them to a file, then clear them from the Event Log. |
Server logging is available in the web UI when you open the Manage Servers page for a server (see the Managing Servers), then click the Log icon in the View Log column for the server. This opens the Log for Server page. The log is in chronological order with the page with the latest entries shown first. If you need to see earlier entries, click the left arrow at the top or bottom of the page.
The server log entries include the following categories:
Note | Warnings and errors go to the Event Viewer on Windows (see the Tip in Logging Server Events). For a description of the log messages for each server module, see the install-path /docs/msgid/MessageIdIndex.html file. |
DNS—From the Deploy > DNS menu, choose DNS Server to open the Manage DNS Server page. Click the name of the server to open the Edit DNS Server page. Expand the Log Settings section to view the log settings. Make changes to the attributes as desired, click Save, then reload the server. (See Table 4 in the "Troubleshooting DNS Servers" section in Cisco PrimeIP Express 8.3 Authoritative and Caching DNS User Guide for the log settings to maximize DNS server performance.)
Use dns set log-settings, dhcp set log-settings, and tftp set log-settings for the respective servers.
The web UI provides a convenient way to search for entries in the activity and startup log files. You can locate specific message text, log message IDs, and message timestamps using a regular expression string entry. When you click the Log icon in the View Log or View Startup Log column on the Manage Servers page (or one of the specific server pages), this opens a Log for Server page. In the text field next to the Search icon at the top or bottom of the page, enter the search string in the regular expression syntax. (For example, entering name? searches for occurrences of the string name in the log file.) Click the Search icon to view the results of log search.
Click the name of the log message, which opens the Log for Server page with the full message text. To view the full message text, click the name of the log message. Change between Table and Text view by clicking the Log icon. Click Close on the Log Search Result page to close the browser window.
In the web UI, you can view the change logs and tasks associated with configurations you make.
From the Operate menu, choose Change Log. To view the change log, you must be assigned the database subrole of the ccm-admin or regional-admin role:
On the View Change Log page, you can filter the list, manually trim it, and save it to a file. You can filter the list by:
Click Filter List or Clear Filter (to clear the filter that persists through the session). You can initiate a trim of the change log by setting how many days old you want the record to get before trimming it, by setting a number of days value in the “older than” field and clicking the Delete icon.
To save the change log entries to a comma-separated values (CSV) file, click the Save icon.
If a task is associated with a change log, it appears on the View Change Set page. You can click the task name to open the View CCM Task page for it.
The DHCP and the DNS servers register the changes on the server logs only during the server configuration, which happens during a reload. Reloading the servers is time consuming. Cisco Prime IP Express allows the DHCP and DNS servers to register the changes to log settings, without a reload.
To dynamically update DHCP server log settings, do the following:
Step 1 | From the Deploy > DHCP menu, choose DHCP Server. The Manage DHCP Server page appears. |
Step 2 | Click the name of the DHCP server in the left pane to open the Edit DHCP Server page. |
Step 3 | Modify the log settings as desired. |
Step 4 | Click Save at the bottom of the page. The new log settings are applied to the DHCP server. The Manage DHCP Server page is displayed with an updated page refresh time. |
To dynamically update DNS server log settings, do the following:
Step 1 | From the Deploy > DNS menu, choose DNS Server. This opens the Manage DNS Server page. | ||
Step 2 | Click the name of the DNS server in the left pane to open the Edit DNS Server page. | ||
Step 3 | Modify the log settings as desired. | ||
Step 4 | Click
Save at
the bottom of the page. The new log settings are applied to the DNS server. The
Manage DNS Server page is displayed with an updated page refresh time.
|
To dynamically update the DHCP or DNS server log settings using the CLI, you must have the appropriate edit-mode set to synchronous. After changing the server log settings, use the save command to save the settings.
For example:
nrcmd>session set dhcp-edit-mode=synchronous nrcmd>dhcp set log-settings=new-settings nrcmd>save
Using consistency rules, you can check data inconsistencies such as overlapping address ranges and subnets. You can set data consistency rules at the regional and local clusters.
The table on the List Consistency Rules page explains these rules. Check the check box next to the rule that you want to run.
Note | You must set the locale parameters on UNIX to en_US.UTF-8 when running Java tools that use Java SDK, such as cnr_rules. |
The List Consistency Rules page includes functions to select all rules and clear selections. You can show the details for each of the rule violations as well as view the output. The rule selections you make are persistent during your user session.
To run consistency rules, do the following:
Step 1 | From the
Operate
>
Reports menu, choose
Consistency
Reports.
The List Consistency Rules page appears. |
Step 2 | Check the check boxes for each of the listed consistency rules that you want to apply. |
Step 3 | Click
Run
Rules.
The Consistency Rules Violations page appears.The rules are categorized by violation type. |
Step 4 | Click Return to return to the List Consistency Rules page. |
Use the cnr_rules consistency rules tool from the command line to check for database inconsistencies. You can also use this tool to capture the results of the rule in a text or XML file.
The cnr_rules tool is located at:
To run the cnr_rules tool, enter:
> cnr_rules -N username -P password [options]
Option |
Description |
||
---|---|---|---|
Example |
|||
–list |
Lists the available consistency rules.
|
||
> cnr_rules -N admin -P changeme -list |
|||
–run [rule-match] |
Run the available rules. Optionally, you can run a subset of the available rules by applying a case-insensitive rule-match string. |
||
> cnr_rules -N admin -P changeme -run > cnr_rules -N admin -P changeme -run dhcp
|
|||
–details |
Includes details of the database objects that violate consistency rules in the results. |
||
Runs the DNS rules, and includes details of the database object in the results: > cnr_rules -N admin -P changeme -run DNS -details |
|||
–xml |
Generates rule results in an XML file.
|
||
> cnr_rules -N admin -P changeme -run -xml |
|||
–path classpath |
Changes the Java classpath that is searched to locate the available consistency rules (optional). In order to run a new, custom consistency rule, you can use this option. You must get the support of a support engineer to do this. |
||
You can redirect the output of any of these preceding commands to another file. Use the following syntax to capture the rule results in a: > cnr_rules -N username -P password -run -details > filename.txt > cnr_rules -N username -P password -run -xml > filename.xml |
|||
–interactive |
Runs the tool in an interactive session. |
||
> cnr_rules -N admin -P changeme -run -interactive RuleEngine [type ? for help] > ? Commands: load <class> // load the specified rule class run <rule-match> // run rules matching a string, or '*' for all list // list rules by name xml // toggle xml mode detail // toggle detail mode (non-xml only) quit // quit RuleEngine |
Monitoring the status of a server involves checking its:
All Cisco Prime IP Express protocol servers (DNS, DHCP, and SNMP) pass through a state machine consisting of the following states:
The two essential states are initialized and running, because the server transitions through the states so quickly that the other states are essentially invisible. Normally, when the server agent starts the server, it tells the server to be up. The server process starts, sets its state to loaded, then moves up to running. If you stop the server, it walks down the states to initialized, and if you restart, it moves up to running again. If it fails to configure for some reason, it drops back to initialized, as if you had stopped it.
There is also an exiting state that the server is in very briefly when the process is exiting. The user interface can also consider the server to be disabled, but this rarely occurs and only when there is no server process at all (the server agent was told not to start one).
You can display aspects of the health of a server, or how well it is running. The following items can decrement the server health, so you should monitor their status periodically. For the:
The server health status varies from the value 0 to 10. The value 0 means the server is not running and 10 means the server is running. Some of the servers report only 0 or 10, and not anything in between. When a server reports a value from 1 to 9, it means that it detected conditions that indicate possible problems. It has nothing to do with the actual performance of the server. So, if the health of the server is a value from 1 to 9, the server log files need to be reviewed to see what errors were logged.
Note | Depending on the level of activity and the size and number of log files, the condition that reduced the server health might not be visible in the log files. It is important to review the log files, but the servers do not log all the conditions that reduce the server health. |
The following conditions can reduce the DHCP server health:
Tip | Health values range from 0 (the server is not running) to 10 (the highest level of health). It is recommended that the health status can be ignored, with the understanding that zero means server is not running and greater than zero means server is running. On Linux, you can run the cnr_status command, in the install-path /usrbin/ directory, to see if your local cluster server is running. For more information on how to check whether the local cluster server is running, see the Cisco Prime IP Express Installation Guide . |
From the Operate menu, select Manage Servers. Check the Manage Servers page for the state and health of each server.
Use [server] type getHealth. The number 10 indicates the highest level of health, 0 that the server is not running.
To display server statistics, the server must be running.
Go to the Manage Servers page, click the name of the server in the left pane, then click the Statistics tab, if available. On the Server Statistics page, click the name of the attribute to get popup help.
The DHCP, DNS, and CDNS statistics are each divided into two groups of statistics. The first group is for total statistics and the second group is for sample statistics. The total statistics are accumulated over time. The sample statistics occur during a configurable sample interval. The names of the two categories vary per server and per user interface, and are identified in the following table.
Server |
User Interface |
Total Statistics (Command) |
Sample Statistics (Command) |
---|---|---|---|
DHCP |
Web UI |
Total Statistics |
Activity Summary |
CLI |
Total Counters since the start of the last DHCP server process (dhcp getStats) |
Sampled counters since the last sample interval (dhcp getStats sample) |
|
DNS |
Web UI |
Total Statistics |
Sample Statistics |
CLI |
Total Counters since the start of the last server process (dns getStats) |
Sampled counters since the last sample interval (dns getStats sample) |
|
CDNS |
Web UI |
Total Statistics |
Sample Statistics |
CLI |
Total Counters since the start of the last server process (cdns getStats total) |
Sampled counters since the last sample interval (cdns getStats sample) |
To set up the sample counters, you must activate either the collect-sample-counters attribute for the server or a log-settings attribute value called activity-summary. You can also set a log-settings value for the sample interval for each server, which is preset to 5 minutes. The collect-sample-counters attribute is preset to true for the DNS server, but is preset to false for the DHCP server. For example, to enable the sample counters and set the interval for DHCP, set the following attributes for the DHCP server:
In the CLI, if you use [server] type getStats, the statistics are encoded in curly braces followed by sets of digits, as described in Table 18 for DNS, Table 20 for DHCP Statistics. The server type getStats all command is more verbose and identifies each statistic on a line by itself. Using the additional sample keyword shows the sample statistics only.
Reset the counters and total statistic by using dhcp resetStats, dns resetStats, or cdns resetStats.
The DNS server statistics in the web UI appear on the DNS Server Statistics page, click on the statistic’s name to read its description. You can refresh the DNS Server Statistics.
The DNS server statistics that you can view are:
Note | To get the most recent data, click the Refresh Server Statistics icon at the top left corner of the page. |
The CLI dns getStats command has the following options:
dns getStats [performance | query | errors | security | maxcounters | ha | ipv6 | all] [total | sample]
The dns getStats all command is the most commonly used.
nrcmd> dns getStats nrcmd> dns getStats 100 Ok {1} 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Digit |
Statistic |
Description |
---|---|---|
{1} |
id |
Implementation ID (release and build information). |
2 |
config-recurs |
Recursion services—(1) available, (2) restricted, (3) unavailable. |
3 |
config-up-time |
Time (in seconds) elapsed since the last server startup. |
4 |
config-reset-time |
Time (in seconds) elapsed since the last server reset (restart). |
5 |
config-reset |
Status or action to reinitializes any name server state—If using the (2) reset action, reinitializes any persistent name server state; the following are read-only statuses: (1) other—server in some unknown state, (3) initializing, or (4) running. |
6 |
counter-auth-ans |
Number of queries answered authoritatively. |
7 |
counter-auth-no-names |
Number of queries returning authoritative no such name responses. |
8 |
counter-auth-no-data-resps |
Number of queries returning authoritative no such data (empty answer) responses. (Deprecated statistics) |
9 |
counter-non-auth-datas |
Number of queries answered nonauthoritatively (cached). (Deprecated statistics) |
10 |
counter-non-auth-no-datas |
Number of queries answered nonauthoritatively with no data. |
11 |
counter-referrals |
Number of queries forwarded to other servers. |
12 |
counter-errors |
Number of responses answered with errors (RCODE values other than 0 or 3). |
13 |
counter-rel-names |
Number of requests received for names of only one label (relative names). |
14 |
counter-req-refusals |
Number of refused queries. |
15 |
counter-req-unparses |
Number of unparsable requests. |
16 |
counter-other-errors |
Number of aborted requests due to other errors. |
17 |
total-zones |
Total number of configured zones. |
The CDNS server statistics in the web UI appear on the DNS Caching Server Statistics page, click on the name of the statistics to read its description. You can refresh the CDNS Server Statistics.
Digit |
Statistic |
Description |
---|---|---|
{1} |
name |
Name identifying the DNS Caching Server. |
2 |
time-current |
The current time given by the CDNS Server. |
3 |
time-up |
The amount of time the server has been up and running. |
4 |
time-elapsed |
The elapsed since last statistics poll. |
5 |
queries-total |
Total number of queries received by the CDNS Server. |
6 |
queries-over-tcp |
Total number of queries received over TCP by the CDNS Server. |
7 |
queries-over-ipv6 |
Total number of queries received over TCP by the CDNS Server. |
8 |
queries-with-edns |
Number of queries with EDNS OPT RR present. |
9 |
queries-with-edns-do |
Number of queries with EDNS OPT RR with DO (DNSSEC OK) bit set. |
10 |
queries-type-A |
Number of A queries received. |
11 |
queries-type-AAAA |
Number of AAAA queries received. |
12 |
queries-type-CNAME |
Number of CNAME queries received. |
13 |
queries-type-PTR |
Number of PTR queries received. |
14 |
queries-type-NS |
Number of NS queries received. |
15 |
queries-type-SOA |
Number of SOA queries received. |
16 |
queries-type-MX |
Number of MX queries received. |
17 |
queries-type-DS |
Number of DS queries received. |
18 |
queries-type-DNSKEY |
Number of DNSKEY queries received. |
19 |
queries-type-RRSIG |
Number of RRSIG queries received. |
21 |
queries-type-NSEC |
Number of NSEC queries received. |
22 |
queries-type-NSEC3 |
Number of NSEC3 queries received. |
23 |
queries-type-other |
Number of queries received of type 256+. |
24 |
queries-with-flag-QR |
Number of incoming queries with QR (query response) flag set. These queries are dropped. |
25 |
queries-with-flag-AA |
Number of incoming queries with AA (auth answer) flag set. These queries are dropped. |
26 |
queries-with-flag-TC |
Number of incoming queries with TC (truncation) flag set. These queries are dropped. |
27 |
queries-with-flag-RD |
Number of incoming queries with RD (recursion desired) flag set. |
28 |
queries-with-flag-RA |
Number of incoming queries with RA (recursion available) flag set. |
29 |
queries-with-flag-Z |
Number of incoming queries with Z flag set. |
30 |
queries-with-flag-AD |
Number of incoming queries with AD flag set. |
31 |
queries-with-flag-CD |
Number of incoming queries with CD flag set. |
32 |
queries-failing-acl |
Number of queries being dropped or refused due to ACL failures. |
33 |
cache-hits |
The total number of queries that were answered from cache. |
34 |
cache-misses |
The total number of queries that were not found in the cache. |
35 |
cache-prefetches |
Number of prefetches performed. |
36 |
requestlist-total |
The total number of queued requests waiting for recursive replies. |
37 |
requestlist-total-user |
The total number of queued user requests waiting for recursive replies. |
38 |
requestlist-total-system |
The total number of queued system requests waiting for recursive replies. |
39 |
requestlist-total-average |
The average number of requests on the request list. |
40 |
requestlist-total-max |
The maximum number of requests on the request list. |
41 |
requestlist-total-overwritten |
The number of requests on the request list that were overwritten by newer entries. |
42 |
requestlist-total-exceeded |
The number of requests dropped because the request list was full. |
43 |
recursive-replies-total |
The total number of recursive queries replies. |
44 |
recursive-time-average |
The average time to complete a recursive query. |
45 |
recursive-time-median |
The median time to complete a recursive query. |
46 |
mem-process |
An estimate of the memory in bytes of the CDNS process. |
47 |
mem-cache |
Memory in bytes of RRSet cache. |
48 |
mem-query-cache |
Memory in bytes of incoming query message cache. |
49 |
mem-iterator |
Memory in bytes used by the CDNS iterator module. |
50 |
mem-validator |
Memory in bytes used by the CDNS validator module. |
51 |
answers-with-NOERROR |
Number of answers from cache or recursion that result in rcode of NOERROR being returned to client. |
52 |
answers-with- NXDOMAIN |
Number of answers from cache or recursion that result in rcode of NXDOMAIN being returned to client. |
53 |
answers-with-NODATA |
Number of answers that result in pseudo rcode of NODATA being returned to client. |
54 |
answers-with-other-errors |
Number of answers that result in pseudo rcode of NODATA being returned to client. |
55 |
answers-secure |
Number of answers that correctly validated. |
56 |
answers-unsecure |
Number of answers that did not correctly validate. |
57 |
answers-rrset-unsecure |
Number of RRSets marked as bogus by the validator. |
58 |
answers-unwanted |
Number of replies that were unwanted or unsolicited. High values could indicate spoofing threat. |
59 |
reset-time |
Reports the most recent time the stats were reset (i.e. cdns resetStats in nrcmd). |
60 |
sample-time |
Reports the time the server collected the last set of sample statistics. |
61 |
sample-interval |
Reports the sample interval used by the server when collecting sample statistics. |
The DHCP server statistics in the web UI appear on the DHCP Server Statistics page, click on the statistic’s name to read its description.
The DHCP server statistics details are available for:
The Additional Attributes are:
Additional Attributes also includes Top Utilized Aggregations.
The CLI dhcp getStats command has the following options:
dhcp getStats [[all | server [,] failover [,] dhcpv6] [total | sample]
The dhcp getStats all command is the most commonly used.
nrcmd> dhcp getStats
Note | To get the most recent data, click the Refresh Server Statistics icon at the top left of the page. |
The CLI dhcp getStats command has the following options:
dhcp getStats[[all| server[,] failover [,] dhcpv6] [total| sample] The dhcp getStatsallcommand is the most commonly used. The dhcp getStats command without this option returns the statistics in a single line of positional values in the following format (The table below shows how to read these values): nrcmd> dhcp getStats 100 Ok {1} 2 3 4 5 6 7 8
Digit |
Statistic |
Description |
---|---|---|
{1} |
start-time-str |
Date and time of last server reload, as a text string. |
2 |
total-discovers |
Number of DISCOVER packets received. |
3 |
total-requests |
Number of REQUEST packets received. |
4 |
total-releases |
Number of RELEASED packets received. |
5 |
total-offers |
Number of OFFER packets sent. |
6 |
total-acks |
Number of acknowledgement (ACK) packets sent. |
7 |
total-naks |
Number of negative acknowledgement (NAK) packets sent. |
8 |
total-declines |
Number of DECLINE packets received. |
Displaying IP address usage gives an overview of how clients are currently assigned addresses.
You can look at the local or regional cluster address space, or generate a subnet utilization or lease history report at the regional cluster, to determine IP address usage. These functions are available in both web UIs in the Design > DHCPv4 menu, if you have address space privileges at the local or regional cluster.
You can determine the current address space utilization by clicking the View icon in the Current Usage column for the unified address space, address block, and subnet (see the "Viewing Address Utilization for Address Blocks, Subnets, and Scopes" section in Cisco PrimeIP Express 8.3 DHCP User Guide). You can also get the most current IP address utilization by querying the lease history (see the "Querying Leases" section in Cisco PrimeIP Express 8.3 DHCP User Guide). In the latter case, the regional CCM server references the appropriate DHCP server directly. To ensure this subnet-to-server mapping, you must update the regional address space view so that it is consistent with the relevant local cluster. Do this by pulling the replica address space, or reclaiming the subnet to push to the DHCP server (see the "Reclaiming Subnets" section in Cisco PrimeIP Express 8.3 DHCP User Guide). Also ensure that the particular DHCP server is running.
You can generate an IP address usage report using the report command. The command has the following syntax:
report[column-separator=string | dhcpv4 | dhcp-only| dhcpv6| file=outputfile | vpn=
The column-separator specifies the character string that separates the report columns (the preset value is the space character). If you want to include more than one space, precede them with the backslash (\) escape character (enclosed in quotation marks). You can specify DHCPv4 or DHCPv6 addresses (dhcp-only is the same as dhcpv4). Not specifying the VPN returns the addresses in the current VPN only.
Cisco Prime IP Express displays the relationship among servers in a DNS zone distribution or a DHCP failover configuration. In the web UI, you can view a related servers page when you click the Related Servers icon on various pages. You can use the display of related servers to diagnose and monitor misconfigured or unreachable servers.
To service clients that require updates to DNS and LDAP related servers, the DHCP server uses a persistent event algorithm to ensure updates to related servers when a related server is temporarily unavailable. In addition, the algorithm prevents a misconfigured or offline DNS server from using up all the available update resources.
At startup, the DHCP server calculates the number of related servers in the configuration that require persistent events. A preconfigured Maximum Pending Events attribute (an Expert mode attribute that specifies the number of in-memory events that is preset to 40,000) is divided by the number of servers to obtain a limit on the number of events permitted for each remote server. This calculation covers related DNS and LDAP servers (DHCP failover does not use persistent storage for events). The DHCP server uses this calculation to issue log messages and take the action described in the following table. The table shows a hypothetical case of a DHCP server with four related DNS servers each having a limit of 10K events.
Event Reached |
DHCP Server Action |
---|---|
50% of the calculated per-server limit (Maximum Pending Events value divided by the number of total related servers); for example, 5K events on a related server out of a total of 40K maximum pending events |
Issues an INFO log message every 2 minutes, as long as the limits are exceeded: The queue of events for the name remote server at address has x events, and has reached the info limit of y/2 events out of an upper limit of y events per remote server. The remote server may be misconfigured, inoperative, or unreachable . |
100% of the calculated per-server limit and less than 50% of the Maximum Pending Events value; for example, 10K events on a related server, with fewer than 10K total maximum pending events |
Issues a WARNING log message every 2 minutes, as long as the limits are exceeded: The queue of events for the name remote server at address has x events, has exceeded the limit of y events per remote server, but is below the limit of z total events in memory. The remote server may be misconfigured, inoperative, or unreachable . |
100% of the calculated per-server limit and 50% or more of the Maximum Pending Events value; for example, 10K events on a related server, with 20K total maximum pending events |
Issues an ERROR log message every 2 minutes, as long as the limits are exceeded: The queue of events for the name remote server at address has x events, and has grown so large that the server cannot continue to queue new events to the remote server. The limit of y events per remote server and z/2 total events in memory has been reached. This and future updates to this server will be dropped. The current eventID n is being dropped.
The server drops the current triggering event and all subsequent events with that server. |
100% of the Maximum Pending Events value; for example, 40K events across all related servers |
Issues an ERROR log message: The queue of pending events has grown so large that the server cannot continue to queue new events. The queue's size is z, and the limit is z The server drops all subsequent events with all related servers. |
SNMP traps and DHCP server log messages also provide notification that a related server is unreachable.
A DNS zone distribution simplifies creating multiple zones that share the same secondary server attributes. You can view and set the primary and secondary DNS servers in a zone distribution.
From the Deploy > DNS menu, click Zone Distribution. This opens the List Zone Distributions page. The local cluster allows only one zone distribution, the default. Click this zone distribution name to open the Edit Zone Distribution page, which shows the authoritative and secondary servers in the zone distribution.
From the Deploy > DNS menu, choose Zone Distributions. This opens the List/Add Zone Distributions page. The regional cluster allows creating more than one zone distribution. Click the zone distribution name to open the Edit Zone Distribution page, which shows the primary, authoritative, and secondary servers in the zone distribution.
Create a zone distribution using zone-dist name create primary-cluster , then view it using zone-dist list. For example:
nrcmd> zone-dist distr-1 create Boston-cluster nrcmd> zone-dist list
Related servers in a DHCP failover pair relationship can show the following information:
For details on DHCP failover implementation, see the "Managing DHCP Failover" section in Cisco PrimeIP Express 8.3 DHCP User Guide
From the Deploy > DHCP menu, choose Failover Pairs. The List/Add DHCP Failover Pairs page shows the main and backup servers in the failover relationship.
Use dhcp getRelatedServers to display the connection status between the main and partner DHCP servers. If there are no related servers, the output is simply 100 Ok .
After you create a scope, you can monitor lease activity and view lease attributes.
From the Design > DHCPv4 menu, choose Scopes; or from the Design > DHCPv6 menu, choose Prefixes (in Advanced mode). On the List/Add DHCP Scopes or List/Add DHCPv6 Prefixes page, click the View icon in the Leases column to open the List DHCP Leases for Scope or List DHCP Leases for Prefix page.
From the Operate > Reports > DHCPv4 menu or Operate > Reports > DHCPv6 menu, choose Lease History. Set the query parameters, then click Query Lease History. (See the "Querying Leases" section in Cisco PrimeIP Express 8.3 Authoritative and Caching DNS User Guide.)
The following sections describe troubleshooting the configuration and the DNS, and DHCP servers.
Immediate Troubleshooting Actions
When facing a problem, it is crucial not to cause further harm while isolating and fixing the initial problem. Here are things to do (or avoid doing) in particular:
Cisco Prime IP Express uses the cnr.conf file for basic configuration parameters. This file is normally located in the install-path /conf directory. Cisco Prime IP Express creates the file during installation and processes it line by line.
You can edit this file if configuration parameters change. Note that during normal operation, you would not want to change the values. However, certain conditions might require you to modify certain values, such as when you move the data files for disk space reasons.
The format of the cnr.conf file consists of parameter name-value pairs, one per line; for example, for a Windows local cluster installation:
cnr.rootdir=C:\\Program Files (x86)\\Cisco Prime IP Express\\Local cnr.ccm-port=1234 cnr.cisco-gss-appliance-integration=n cnr.datadir=C:\\CiscoPrimeIPExpress\\Local\\data cnr.java-home=C:\\Program Files\\Java\\jre1.5.0_12 cnr.logdir=C:\\CiscoPrimeIPExpress\\Local\\logs cnr.https-port=8443 cnr.tempdir=C:\\CiscoPrimeIPExpress\\Local\\temp cnr.http-port=8080 cnr.ccm-mode=local cnr.ccm-type=cnr cnr.http-enabled=y cnr.https-enabled=n cnr.keystore-file=C: cnr.keystore-password=unset cnr.backup-time=23:45
Directory paths must be in the native syntax for the operating system. The format allows the use of colons (:) in directory paths, but not as name-value pair separators; it does not allow line continuation or embedded unicode characters. Other modifications to the file might include the location of the log directory (see Log Files) or the time cnr_shadow_backup backups should occur (see Setting Automatic Backup Time).
In rare cases, you might want to modify the file; for example, to exclude certain data from daily backups due to capacity issues. To do this, you need to add the appropriate settings manually.
Caution | We recommend that you use the default settings in this file. If you must change these settings, do so only in consultation with the Cisco Technical Assistance Center (TAC) or the Cisco Prime IP Express development team. |
The following settings are supported:
Cisco Prime IP Express supports logging to a Syslog server (on Linux). The Syslog support is not enabled by default. To configure which messages need to be logged, based on logging levels, the cnr.conf file must be updated.
In addition, on Windows, event logging for Warnings and Errors is enabled by default (for Windows Event log). In this release, you can log more (or less) to the event log by changing the log settings.
The following cnr.conf configuration parameters are supported:
Note | While it is possible to enable all of the severity levels and thus all messages written to the server log files are also logged to Syslog, this is not recommended unless the server log settings are reviewed and minimized. The performance impact on Syslog and the servers may vary greatly depending on how logging is configured. Syslog may rate limit the messages, so useful messages may also be lost. |
cnr.syslog.facility-Specifies the facility under which Syslog logs (Linux OS). This parameter is ignored for Windows. The valid facility keywords are daemon (the default), local0, local1, local2, local3, local4, local5, local6, local7.
Note |
|
The following cnr.conf configuration parameters allow server-specific overrides of the above parameters. server is one of cnrservagt, ccm, cdns, cnrsnmp, dns, and dhcp.
The server specific configuration value is used, if specified. Otherwise, all parameters of the server are used. For example, to enable Syslog only for DHCP, add the following to the cnr.conf file:
cnr.syslog.dhcp.enable=1
To change the severity levels to include all non-debug logging (this assumes logging has been enabled for some or all servers), use:
cnr.syslog.enable=1 cnr.syslog.levels=error,warning,info,activity
To enable Syslog only for the DNS server:
cnr.syslog.dns.enable=1 cnr.syslog.dns.levels=error,warning,info,activity
Tip | Syntax or other errors in the cnr.conf parameters are not reported and are ignored (that is, if a levels keyword is mistyped, that keyword is ignored). Therefore, if a configuration change does not work, check if the parameter(s) have been specified correctly. |
The server agent processes (nwreglocal and nwregregion) normally detect server failures and restart the server. You can usually recover from the failure and the server is not likely to fail again immediately after restarting. On rare occasions, the source of the server failure prevents the server from successfully restarting, and the server fails again as soon as it restarts. In such instances, perform the following steps:
Step 1 | If the server takes a significantly long time to restart, stop and restart the server agent. On: |
Step 2 | Keep a copy of all the log files. Log files are located in the install-path /logs directory on Linux, and the install-path \logs folder on Windows. The log files often contain useful information that can help isolate the cause of a server failure. |
Step 3 | Use the TAC tool, as described in Using the TAC Tool, or save the core or user.dmp file, if one exists, depending on the operating system: |
Step 4 | On Windows, use the native event logging application to save the System and Application event logs to files. You can do this from the Event Viewer. These event logs often contain data that helps debug Cisco Prime IP Express server problems. For a description of the log messages for each server module, see the install-path /docs/msgid/MessageIdIndex.html file. |
You can also use the following commands on Linux systems to troubleshoot Cisco Prime IP Express. To:
There may be times when any amount of troubleshooting steps will not resolve your problem and you have to resort to contacting the Cisco Technical Assistance Center (TAC) for help. Cisco Prime IP Express provides a tool so that you can easily assemble the server or system error information, and package this data for TAC support engineers. This eliminates having to manually assemble this information with TAC assistance. The resulting package from this tool provides the engineers enough data so that they can more quickly and easily diagnose the problem and provide a solution.
The cnr_tactool utility is available in the bin directory of the Windows, and usrbin directory of the UNIX or Linux, installation directories. Execute the cnr_tactool utility:
> cnr_tactool -N username -P password [-d output-directory
The output directory is optional and normally is the temp directory of the installation directories (in the /var path on Linux). If you do not supply the username and password on the command line, you are prompted for them:
> cnr_tactool username: password: [processing messages....]
The tool generates a packaged tar file whose name includes the date and version. The tar file contains all the diagnostic files.