You can manage the protocol servers in the following ways depending on if you are a:

• Local or regional cluster administrator —Choose Manage Servers from the Operate menu to open the Manage Servers page.

  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, TFTP, or SNMP servers, select the server in the Manage Servers pane and do any of the following:

  • Click the Statistics tab to view statistics for the server. (See the Displaying Statistics.)
  • Click the Logs tab in the View Log column to view the log messages for the server. (See the Searching the Logs.)
  • Click the Start Server button to start the server.
  • Click the Stop Server button stop the server.
  • Click the Restart Server button to reload the server.

• Local cluster DNS administrator —Choose DNS Server from the Deploy menu to open the Manage DNS Authoritative Server page.

  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:

  • Forcing all zone transfers (see the "Enabling Zone Transfers" section in Cisco Prime Network Registrar 11.2 Authoritative and Caching DNS User Guide)—Click the Run icon. This is the equivalent of dns forceXfer secondary in the CLI.
  • Scavenging all zones (see the "Scavenging Dynamic Records" section in Cisco Prime Network Registrar 11.2 DHCP User Guide)—Click the Run icon. This is the equivalent of dns scavenge in the CLI.

• Local cluster Caching DNS server— Choose CDNS Server from the Deploy menu to open the Manage DNS Caching Server page.

  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 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.

• Local cluster DHCP administrator —Click DHCP Server from the Deploy menu to open the Manage DHCP Server page.

  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 Prime Network Registrar 11.2 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:

• To start the server, use server type start (or simply type start ; for example, dhcp start ).
• To stop the server, use server type stop (or simply type stop ; for example, dhcp stop ). If stopping the server, it is advisable to save it first using the save command.
• To reload the server, use server type reload (or simply type reload ; for example, dhcp reload ). Cisco Prime Network Registrar stops the server you chose, loads the configuration data, and then restarts the server.

• To set or show attributes for the server, use [server ] type set attribute= value or [server ] type show . For example:

  nrcmd> ccm set ipaddr=192.168.50.10
  
  

The following table describes the Cisco Prime Network Registrar log files in the /var/nwreg2/{local | regional}/logs directory.

DNS, DHCP, CDNS, CCM, and TFTP servers can generate a number of log files, each with a preconfigured maximum size of 10 MB. This preconfigured value applies to new installs only.

Note	Upgrades from pre-11.1 versions will use the old preconfigured (or explicitly configured) value of 1,000,000 bytes for log files.

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 10 for the DNS, DHCP, CDNS, CCM, and TFTP servers.

Cisco Prime Network Registrar also has server_startup_log files. This applies to the CCM, DHCP, DNS, and TFTP 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 10 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.

Logging can also be directed to Syslog. See Modifying the cnr.conf File.

When you start Cisco Prime Network Registrar, it automatically starts logging Cisco Prime Network Registrar system activity. Cisco Prime Network Registrar maintains all the logs by default in the /var/nwreg2/{local | regional}/logs directory. To view these logs, use the tail -f command.

The server log entries include the following categories:

• Activity —Logs the activity of your servers.

• Info —Logs standard operations of the servers, such as starting up and shutting down.

• Warning —Logs warnings, such as invalid packets, user miscommunication, or an error in a script while processing a request.

• Error —Logs events that prevent the server from operating properly, such as out of memory, unable to acquire resources, or errors in configuration.

• Packet —Logs packet logging messages.

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. 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. Change between table and text view by clicking the Page icon which is available at the top and bottom of the page.

To view the full message text, click the name of the log message. 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.

All Cisco Prime Network Registrar protocol servers (DNS, DHCP, SNMP, and TFTP) pass through a state machine consisting of the following states:

• Loaded —First step after the server agent starts the server (transitional).
• Initialized —Server was stopped or fails to configure.
• Unconfigured —Server is not operational because of a configuration failure (transitional).
• Stopped —Server was administratively stopped and is not running (transitional).
• Running —Server is running successfully.

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:

• Server agent (local and regional clusters)
• CCM server (local and regional clusters)
• DNS server (local cluster):
  • Configuration errors
  • Memory
  • Disk space usage
  • Inability to contact its root servers
• Caching DNS server (local cluster)
• DHCP server (local cluster):
  • Configuration errors
  • Memory
  • Disk space usage
  • Packet caching low
  • Options not fitting in the stated packet limit
  • No more leases available
• TFTP server (local cluster):
  • Memory
  • Socket read or write error
  • Exceeding the overload threshold and dropping request packets

To display server statistics, the server must be running.

Displaying IP address usage gives an overview of how clients are currently assigned addresses.

Cisco Prime Network Registrar 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.

After you create a scope, you can monitor lease activity and view lease attributes.

Cisco Prime Network Registrar supports logging to a Syslog server. 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.

The following cnr.conf configuration parameters are supported:

• cnr.syslog.enable—Specifies whether logging to Syslog server is enabled for Prime Network Registrar servers.

  • To disable all logging, the value can be 0, off, or disabled.

  • To enable all logging, the value can be 1, on, or enabled.

  • By default, this parameter is disabled.

• cnr.syslog.levels—Specifies the severity levels to be logged to Syslog. If Syslog is enabled, this defaults to warning and error. The value can be a case-blind, comma separated, list of the following keywords: error, warning, activity, info, and debug. This parameter is ignored if Syslog is disabled.

Caution

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. 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. Cisco highly recommends reviewing the Syslog settings and messages in order to minimize the number of messages written. Writing too many messages to Syslog will cause a performance impact on the Cisco Prime Network Registrar servers and Syslog.

• cnr.syslog.facility—Specifies the facility under which Syslog logs. The valid facility keywords are daemon (the default), local0, local1, local2, local3, local4, local5, local6, local7.

• cnr.syslog.ids—Specifies the individual messages to be logged (or not logged) as either a comma separated list of message IDs or message ID ranges (x-y). If a message ID or range is preceded by a minus sign (hyphen) or ! (exclamation mark), the message ID or range of IDs will explicitly not be logged. The explicitly referenced message IDs are logged or not logged regardless of any other Syslog settings (including the .enable setting).

  Refer to the /opt/nwreg2/local/docs/msgid/*.html files (or the actual server log files) for determining the message IDs.

  For example:

  cnr.syslog.ids=4000-4100,-4101-4200,4300 

  This would cause messages 4000-4100 and 4300 to be logged to Syslog and messages 4101-4200 to NOT be logged (regardless of any other Syslog settings).

Note	These parameters apply to all Cisco Prime Network Registrar servers (cnrservagt, ccm, cdns, cnrsnmp, dns, dhcp, and tftp). To apply any change to the cnr.conf parameters, Cisco Prime Network Registrar must be restarted.

The following cnr.conf configuration parameters allow server-specific overrides of the above parameters. server is one of cnrservagt, ccm, cdns, cnrsnmp, dns, dhcp, and tftp.

• cnr.syslog.server.enable—Specifies whether Syslog is enabled for the specified server (cnr.syslog.enable is ignored for that server).

• cnr.syslog.server.levels—Specifies the severity levels for the specified server (cnr.syslog.levels is ignored for that server).

• cnr.syslog.server.facility—Specifies the Syslog facility for the specified server (cnr.syslog.facility is ignored for that server).

cnr.syslog.dhcp.enable=1

cnr.syslog.enable=1
cnr.syslog.levels=activity

cnr.syslog.dns.enable=1
cnr.syslog.dns.levels=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.

Note

Most Syslog implementations implement rate limiting and the Cisco Prime Network Registrar server logging can easily trigger this causing a loss of log data to Syslog. If this is occurring, you will typically see “Suppressed number messages from ….” messages, usually in /var/log/messages. Most Syslog implementations have settings to control the rate that triggers this or even disable the action (though disabling is not recommended). You may need to make these adjustments or consider reducing what is logged to Syslog (it is not a best idea to log everything, especially for high levels of activity). Typically, this means adjusting the /etc/systemd/journald.conf’s RateLimitInterval and RateLimitBurst settings.

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:

• Have 512 MB or more of memory and 2.5 GB or more of a data partition.
• Do not reboot a cable modem termination system (CMTS).
• Enable or disable DHCP failover. If one of the failover partners is not operating, be sure to put the running server into PARTNER-DOWN mode (if it appears that the partner is unlikely to be returned to service quickly).
• Do not reload, restart, or disrupt Cisco Prime Network Registrar with failover resynchronization in progress.

You can also use the following commands to troubleshoot Cisco Prime Network Registrar. To:

• See all Cisco Prime Network Registrar processes:

  ps -leaf | grep nwr
  

• Monitor system usage and performance:

  top
  vmstat
  

• View login or bootup errors:

  grep /var/log/messages*
  

• View the configured interfaces and other network data:

  ifconfig -a
   

Cisco Prime Network Registrar includes the statscollector utility, which reads the statistics collected by the CCM server on the local clusters. It has several options:

• Obtain the CCM server history from a cluster. You can get the history currently available and optionally continue collecting new history as it becomes available, and write this into a file. The file can later be processed or appended to. Note that by default, the statscollector will continue running "forever" collecting the history. You can ask it to just get the current history and exit by specifying -i 0. If the file exists, it will read that history data to determine the "last" sample collected and start collecting more data from there (so, you can run it with -i 0 every so often to just get the "new" history). Note that if you use a file against a different cluster, you will get a mix of two clusters data which probably is not useful.

  Example:

  statscollector -C cluster -N user -P password stats.bin

• Generate XML (for import to Excel or other tools) of the statistics data either previously collected into a file or obtained from a cluster.

  • Example (using pre-existing file):

    statscollector -e stats.xml stats.bin

  • Example (collecting from cluster):

    statscollector -C cluster -N user -P password -e stats.xml

• Generate HTML (using Google Charts API) of the statistics data either previously collected into a file or obtained from a cluster. You can use the built-in or define your own charts, and have them plotted.

  • Example (using pre-existing file):

    statscollector -h stats.html stats.bin

  • Example (collecting from cluster):

    statscollector -C cluster -N user -P password -h stats.html

You can run the statscollector from the following location:

/opt/nwreg2/local/usrbin

The following options are available:

Note

When exporting to XML or HTML, the resulting files could be very large depending on the statistics collected. You may want to limit the data by using the -i, -s, and -f options. For example, -i 300 means that the exported data is only reported every 5 minutes. But, -s and -f may be more effective to view the data for a specific (shorter) time interval.

To trace TFTP server activity, set the packet-trace-level attribute to a value of 1 through 4, depending on the level of verbosity you want the TFTP server to use to write messages to the trace file. The trace files are located in the /logs subdirectory of the installation directory. Tracing goes to the /var/nwreg2/{local | regional}/logs/file_tftp_1_log and file_tftp_1_trace files.

Here are the trace levels, with each higher level being cumulative:

• 0 —Disables all server tracing (the default).
• 1 —Displays all the log messages in the trace file.
• 2 —Displays the client IP address and port number for all packets.
• 3 —Displays the packet header information.
• 4 —Displays the first 32 bytes of the packet.

Note	Setting and getting the trace level only works if the TFTP server is started. Turn on packet tracing only for debugging purposes, and then not for any extended time, for performance reasons.

You can improve TFTP server performance by restricting logging and tracing. By default, the server logs error, warning, and informational messages to file_tftp_1_log files. You can set the log levels using a few TFTP server parameters:

• Log level (use the log-level attribute)—Primary controller of server logging, which is preset to, and is best left at, level 3 (logs all error, warning, and informational messages). As with packet tracing, the higher logging levels are cumulative. If set to 0, no server logging occurs.

• Log settings (use the log-settings attribute)—This is the second level of logging control and takes only two values, default or no-success-messages. The default log setting does not alter the default value of log level 3 (error, warning, and informational messages). However, you may want to disable writing success informational messages, and thereby improve server performance, by changing the log settings to no-success-messages.

• Log file count and size (use the log-file-count attribute)—Sets how many log files to maintain and how large to allow them to get in the /logs directory. The default value is to maintain a maximum of ten files of 10 MB each.

Note	Reload the TFTP server after changing these values.