Cisco CNS Network Registrar User's Guide, 6.0
Administering Network Registrar
Downloads: This chapterpdf (PDF - 504.0KB) The complete bookPDF (PDF - 7.06MB) | Feedback

Administering Network Registrar

Table Of Contents

Administering Network Registrar

Administering Clusters

Adding Clusters

Connecting to a Cluster

Viewing the Connectivity of a Cluster

Disconnecting from a Cluster

Removing a Cluster

Using Session Assert Commands for Data Management

Administering Users

Adding an Administrator

Adding a Password Without Exposing It

Changing the Administrator Password

Listing and Deleting Network Administrators

Exiting Network Registrar

Controlling Servers

Starting Servers

Stopping Servers

Reloading Servers

Logging Server Events

Event Logging Format

Log Files

Monitoring and Reporting Server Status

Adding Servers to the Server Status Monitor

Removing Servers from the Server Status Monitor

Displaying the Server's Health

Displaying Server Statistics

Displaying IP Address Usage

Displaying Related DHCP Servers

Displaying Leases

Backing up the Network Registrar Databases

Using Third Party Backup Programs With the mcdshadow Utility

Before Performing a Backup or Recovery

Backup Strategy

Setting the Shadow Backup Time

Performing a Manual Backup

Database Recovery Strategy

Backing up and Recovering MCD Data

Checking MCD Database Integrity

Recovering MCD Data from a Damaged Database

Recovering MCD Data from Backup

MCD Recovery Errors

MCD Data Files

Backing up CNRDB Data

Recovering CNRDB Data from a Damaged Database

Recovering CNRDB Data from Backup

Virus Scanning While Running Network Registrar

Troubleshooting Servers and Databases

Immediate Troubleshooting Actions

Troubleshooting Server Failures

Troubleshooting and Optimizing the TFTP Server

Tracing TFTP Server Activity

Optimizing TFTP Message Logging

Enabling File Caching

Using the cnr_exim Data Import and Export Tool

Using the mcdadmin Tool

Using the cnrdb_recover Utility

Using the cnrdb_verify Utility

Using the cnrdb_checkpoint Utility

Using the keybuild Tool

Using the dbcheck Tool

Solaris and Linux Troubleshooting Tools

Using the TAC Tool


Administering Network Registrar


This chapter explains how to administer and control your servers' operations through Cisco CNS Network Registrar's Web-based user interface (Web UI), CLI (the nrcmd program), and GUI (the ntwkreg program). (Web UI management is described in the Network Registrar Web UI Guide. See also Chapter 3, "Network Registrar User Interfaces.")

Table 4-1 lists the major Network Registrar server administration tasks and the sections where you can find procedures on how to accomplish these tasks.

Table 4-1 Administering Network Registrar Topics

If you want to...
See...

Add, remove, connect to, or disconnect from a cluster, or view a cluster's state

"Administering Clusters" section

Add an administrator, or create or change an administrator's password

"Administering Users" section

Start, stop, or reload the servers

"Controlling Servers" section

Set and view the debug logging options

"Logging Server Events" section

Monitor server status or health, display statistics, or display related servers for DHCP

"Monitoring and Reporting Server Status" section

Back up and recover the databases

"Backing up the Network Registrar Databases" section

Troubleshoot servers and databases

"Troubleshooting Servers and Databases" section

Packaging troubleshooting information

"Using the TAC Tool" section


Administering Clusters

A Network Registrar cluster consists of:

Network Registrar DNS, DHCP, and TFTP servers. These servers often run on the same physical machine. In this case, cluster refers to the physical machine.

MCD, Central Configuration Management (CCM), and CNRDB persistent stores that contain configuration and state data for the cluster servers.

AIC Server Agent that starts and stops the servers and provides a standard control interface to them.

A Tomcat server that runs the Web-based user interface (Web UI).

Adding Clusters

Each cluster requires a username and password combination that controls access to the cluster:

Enter localhost as the cluster name if the cluster is on the same machine as the user interface.

If the cluster is on a different machine than the user interface, ensure that the cluster host name does not include the "at" (@) symbol. This is because Network Registrar concatenates the name of the cluster with the name of the server in each cluster with the symbol.

Using the CLI

When you invoke the CLI, you specify the cluster and connect to it at the same time. See the "Invoking the CLI" section on page 3-4. In interactive mode, you would use the command:

> nrcmd -C cluster -N username -P password 
nrcmd> command 

Using the GUI

In the Server Manager window, click Add on the toolbar, or right-click the List of Clusters object and click Add Cluster. This opens the Add Cluster dialog box. See also the "Starting the GUI" section on page 3-11. Add the host name of the cluster (localhost if it is the same machine as the GUI). If you want to connect to the cluster immediately, check the Connect to this cluster once added box. If the cluster does not exist on the network, you cannot connect to it.

Connecting to a Cluster

After you add a cluster to Network Registrar, you must connect to it before you can configure or administer it. If you try to connect to a cluster that someone else is using, Network Registrar warns you that the cluster is locked and tells you who is holding the lock. The format of the warning message is:

username@machine-name.process-id

The process-id identifies the unique process on machine-name in which the user interface runs.


Tip If someone else is using the cluster, disconnect from it. If you want to connect to a locked cluster, contact the person who is currently connected and request that he or she disconnect from it. You can override the lock using the force-lock command, but you should do so only if you know that no one else is editing the cluster; for example, if the other system crashed while the cluster was connected.


Using the CLI

Use the nrcmd -C command to connect to a cluster. For example, to connect to the cluster named mycluster, enter the following command from a command line prompt on Windows:

C:\Program Files\Network Registrar\bin> nrcmd -C mycluster 
username: 


Tip You can include the -r option on the command line to indicate read-only access to the cluster.


If you are connecting to a cluster for the first time, you also need to add a license key. Network Registrar licensing controls your ability to configure your servers. Every copy of Network Registrar requires a license. The license key is located on the back of the software CD-ROM case.

If you have a permanent license, you will not see the license message again.

If you have an evaluation copy of Network Registrar, you have a license that will expire.

If you have an invalid or missing license key, you cannot configure or manage the Network Registrar servers. However, the servers will continue to function normally.

Add the license key using the license set key command.

nrcmd> license set key=license-key 

If you have full administrator privileges, you can confirm your settings.

nrcmd> license get expiration 
100 Ok
Tue Jan 01 19:00:00 2030
nrcmd> license get key 
100 Ok
key-string 
nrcmd> license 
100 Ok
license: 
expiration = Thu Dec 03 19:00:00 2037 
key = key-string 

Using the GUI


Step 1 From the Admin menu, click Clusters.

Step 2 Click the cluster in the Clusters dialog box.

Step 3 Click Connect.

Step 4 If necessary, complete the Login for Cluster dialog box with the username and password, and whether you want read-only access to the cluster. If read-only, the Server Manager window indicates it after the cluster name. Note that read-only access provides limited functionality.

Step 5 Click Close in the Clusters dialog box.


Viewing the Connectivity of a Cluster

To see if a cluster is connected, you can view its state.

Using the CLI

Invoking the CLI successfully means that you are connected to a cluster. To show the cluster to which you are connected, use the session show command to show all the attributes, or use the session get command to confirm each attribute separately.

nrcmd> session show 
100 Ok
session: 
cluster = localhost 
current-namespace = global 
default-format = user 
user-name = admin 
visibility = 5 

Using the GUI

In the Server Manager window, from the Admin menu, click Clusters. The State column indicates the state of the cluster—Connected or Disconnected. Then, click Close.

Disconnecting from a Cluster

When you disconnect from a cluster, you can no longer configure or administer it from that workstation. Another user can then administer the cluster.

Using the CLI

Use the exit command to disconnect from a cluster.

nrcmd> exit 

Using the GUI

In the Server Manager window, right-click the cluster from which you want to disconnect. Then, click Disconnect. If this takes you to the Clusters dialog box, click Close.


Timesaver Right-click on an object to select from the floating menu instead of using the menu bar.


Removing a Cluster

When you remove a cluster, the user interface no longer knows about it, and its name does not appear in the Server Manager.

Using the GUI


Step 1 In the Server Manager window, right-click the cluster you want to remove. Alternatively, from the Admin menu, click Clusters, then choose the cluster.

Step 2 Click Remove.

Step 3 Click Yes in the Network Registrar dialog box.

Step 4 If you are in the Clusters dialog box, click Close.


Using Session Assert Commands for Data Management

You can use the CLI session assert commands to simplify interactions with external data management processes. It also helps in writing multicommand batch scripts that stop processing if an asserted precondition fails. You generally use these commands with the default session format of script. See the session show command in the "Viewing the Connectivity of a Cluster" section. If the assertion passes, you get a "100 Ok" message. If it fails, you get a "107 Assertion Failed xxx.dbsn (minor-serial-number) = value" message and the CLI exits.

Using a CLI Command File (Batch Script)

The session assert locked command exits the CLI if it cannot lock the session. This sample command file performs batch operations requiring a lock:

session set default-format=script 
session assert locked 
commands-that-require-a-lock 

The session assert dhcp.dbsn command exits the CLI session if the minor serial number of the DHCP server does not match (==) or does not exceed (!=) the value given. The minor serial number is incremented with each configuration change. Get its value using the dhcp get dbsn command. This sample script modifies a DHCP server based on configuration version 1234:

session set default-format=script 
dhcp get dbsn 
session assert dhcp.dbsn == 1234 
scope scope1 create 192.168.1.0 255.255.255.0 
scope scope1 addRange 192.168.1.10 192.168.1.200 

This sample script lists DHCP configuration changes made since version 1234:

session set default-format=script 
session assert dhcp.dbsn != 1234 
scope list 
policy list 
client-class list 

Administering Users

If you have full administrator privileges, you can add administrators and change their passwords for the cluster.

Adding an Administrator

You can add administrators responsible for the clusters. You can also add administrators responsible for functionality in the Network Registrar Web-based UI. If you do not want to expose the password when creating the administrator, see the "Adding a Password Without Exposing It" section.

Using the Web UI

Adding administrator accounts in the Web UI involves setting up administrator types, groups, and roles. These are described in detail in the Network Registrar Web UI Guide.

Using the CLI

Use the admin name create command to create an administrator and associated password. You can also determine the level of access to the Web UI and whether the administrator should be a superuser there. The nrcmd-flags attribute sets whether you want limited or full access to the CLI and GUI. Enabling the superuser attribute creates a superuser in the Web UI, although creating this type of administrator should be severely limited. An additional group attribute is usually set in the Web UI, but you can edit this list in the CLI, based on the known groups in the Web UI. (The CLI does not check whether a group exists; if you reference a group, be sure to create it in the Web UI.)

nrcmd> admin bob create password=bob nrcmd-flags=limited 
groups=host-admin-group,zone-admin-group 
100 Ok 
bob: 
    groups = {{0 host-admin-group} {1 zone-admin-group}} 
    nrcmd-flags = 1 
    password = ******** 
    superuser = 

Limited administrator access (shown as the value 1 for the nrcmd-flag) allows access to host, zone, and DHCP server settings in the Web UI through the CLI and GUI, but does not allow an administrator to create new users or view license key data. The full access (shown as the value 2) allows additional access to the global administration functions.

Add attributes using the admin name set attribute command. To show the attribute settings, use the admin name [show] or admin name get attribute command.

nrcmd> admin bob set groups=host-admin-group 
100 Ok 
groups=host-admin-group 
nrcmd> admin bob get groups 
100 Ok 
groups=host-admin-group 

Using the GUI


Step 1 From the Admin menu, click Add Administrator.

Step 2 Enter the administrator's username. You can choose any text string for the administrator's name.

Step 3 Enter the administrator's password. Network Registrar uses the password to authenticate the names. If you create an administrator without a password, Network Registrar cannot authenticate the name and denies that user access to the cluster.

Step 4 Enter the password a second time.

Step 5 Choose the clusters that the administrator can access. See the "Adding Clusters" section. You do not have to be connected to the cluster to add an administrator.

Step 6 Click Add.


Adding a Password Without Exposing It

You can add a password without exposing it on the screen.

Using the Web UI

Logging in to the Web UI always hides the password. However, adding passwords for administrator accounts does expose the password in log files. See the Network Registrar Web UI Guide for details.

Using the CLI

Create an administrator and omit the password. See the "Adding an Administrator" section. Then, use the admin name enterPassword command to enter a password to prevent echoing it on the screen. You are prompted to verify the password.

nrcmd> admin bob create 
100 Ok
bob:
groups =
nrcmd-flags =
password =
superuser =
nrcmd> admin bob enterPassword 
password:
verify password:
100 Ok

Changing the Administrator Password

If you have full administrator privileges, you can change any administrator's password. You should do this for your security reasons. (If you lack full administrator privileges, an error message appears.)

Using the Web UI

The superuser and CCM administrator can change administrator passwords at any time. See the Network Registrar Web UI Guide for details.

Using the CLI

If you have full administrator privileges, use the admin name set password command to change an existing password. This takes a plain text value. If you do not want to expose this password value when you enter it on the screen, see the "Adding a Password Without Exposing It" section.

nrcmd> admin bob set password=plaintext-password 
100 Ok
password=********

Using the GUI


Step 1 If you have full administrator privileges, on the Admin menu, click Change Administrator Password.

Step 2 Enter the administrator's current, old username and password.

Step 3 Enter the administrator's new password and re-enter it in the subsequent field.

Step 4 Choose the cluster the administrator can access.

Step 5 Click OK.


Listing and Deleting Network Administrators

If you have full administrator privileges, you can list the Network Registrar administrators and delete specific ones, if necessary. (If you lack full administrator privileges, an error message appears.)

Using the Web UI

The superuser and CCM administrators can list and delete administrators at any time. See the Network Registrar Web UI Guide for details.

Using the CLI

You can check the administrators created using the admin list command, or just their names using the admin listnames command, and delete a specific one using the admin name delete command.

nrcmd> admin list 
100 Ok
admin:
groups =
nrcmd-flags = 2
password = ********
superuser = true
bob:
groups =
nrcmd-flags =
password = ********
superuser =
nrcmd> admin bob delete 
100 Ok

Exiting Network Registrar

Exiting the Network Registrar user interface does not affect your network servers' or your hosts' ability to request leases or access the Internet.

Using the Web UI

Exit the Web UI by clicking the Logout link at the top of any page.

Using the CLI

Use the exit command to exit Network Registrar. This writes all your unsaved changes to the database. If Network Registrar cannot save your changes, the same error code appears as for the save command.

nrcmd> exit 

Using the GUI

From the Admin menu, click Exit. Network Registrar may prompt you to save your changes.

Controlling Servers

You can control the Network Registrar servers as follows:

Start—Load the database and start the server

Stop—Stop the server

Reload—Stop and restart the server


Tip You can get the Network Registrar software version of each of the servers using the server type get version command, where type is DNS, DHCP, or TFTP.


Starting Servers

This section describes how to start the Network Registrar servers.


Note The DNS and DHCP servers are enabled by default to start on a reboot. The TFTP server is not enabled by default to start on a reboot. You can change this using the server type enable or disable start-on-reboot command in the CLI.


Using the Web UI

You can start the protocol servers in one of two ways:

If you are a CCM administrator, you can select Administration on the Primary Navigation bar and Servers on the Secondary Navigation bar, then click the Start icon for the server you want to start.

If you are a zone administrator, you can click Zone on the Primary Navigation bar and DNS Server on the Secondary Navigation bar, then click the Start icon for the server. If you are a DHCP administrator, the function is available under the DHCP Primary Navigation bar.

Using the CLI

Use the server type start command (or simply server-type start, such as dhcp start) to start the specified server.

nrcmd> dns start 
100 Ok


Timesaver Because the server command requires the server type keyword after it (dns, dhcp, or tftp), you can omit the server keyword and simply start the command with the server type keyword.


Using the GUI

In the Server Manager window, right-click the server you want to start, click Start, then OK.

Stopping Servers

This section describes how to stop the Network Registrar servers.

Using the Web UI

You can stop the protocol servers in one of two ways:

If you are a CCM administrator, you can select Administration on the Primary Navigation bar and Servers on the Secondary Navigation bar, then click the Stop icon for the server you want to start.

If you are a zone administrator, you can click Zone on the Primary Navigation bar and DNS Server on the Secondary Navigation bar, then click the Stop icon for the server. If you are a DHCP administrator, the function is available under the DHCP Primary Navigation bar.

Using the CLI

Use the server type stop (or simply server-type stop, such as dhcp stop) command to stop the specified server. It is advisable to save the server first.

nrcmd> save 
100 Ok
nrcmd> dhcp stop 
100 Ok

Using the GUI

In the Server Manager window, right-click the server you want to stop. Alternatively, choose the server, then click the Servers menu. Then click Stop, Yes to confirm, and OK.

Reloading Servers

When you reload the server, Network Registrar performs three steps—stops the server, loads configuration data, and restarts the server. Only after you issue the reload command does the server use your changes to the configuration.

Using the Web UI

You can reload the protocol servers in one of two ways:

If you are a CCM administrator, you can select Administration on the Primary Navigation bar and Servers on the Secondary Navigation bar, then click the Reload icon for the server you want to start.

If you are a zone administrator, you can click Zone on the Primary Navigation bar and DNS Server on the Secondary Navigation bar, then click the Reload icon for the server. If you are a DHCP administrator, the function is available under the DHCP Primary Navigation bar.

Using the CLI

Use the server type reload (or simply server-type reload) command to reload the specified server. Network Registrar stops the server you chose, loads the configuration data, and then restarts the server.

nrcmd> server dhcp reload 
100 Ok
nrcmd> dns reload 
100 Ok

Using the GUI

In the Server Manager window, right-click the server you want to reload. Click Reload, then OK.

Logging Server Events

When you start Network Registrar, it automatically starts logging system activity. Network Registrar maintains all the logs by default on:

UNIX or Linux, in /var/nwreg2/logs (to view these logs, use the tail -f command)

Windows, in Program Files\Network Registrar\logs


Caution To avoid filling up the Windows Event Viewer, in the Event Log Settings, check the Overwrite Events as Needed box. Otherwise, you might fill up your disk with log messages and prevent Network Registrar from running.

Event Logging Format

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.

Using the CLI

The DNS, DHCP, and TFTP servers have log settings that can severely restrict what is logged, and thereby improve server performance. These log settings are available using the dns set log-settings, dhcp set log-settings, and tftp set log-settings commands in the CLI, respectively. See the Network Registrar CLI Reference for details.


Note Warnings and errors go to Syslog on Solaris or the Event Viewer on Windows. See the Caution.


Log Files

Table 4-2 describes the Network Registrar log files in the install-dir/logs directory.

Table 4-2 Log Files in .../logs Directory 

Component
File in /logs Directory
Content

Server Agent

agent_server_log

Data about when the servers started and stopped.

WIN32 GUI

aicwin32gui_log

GUI messages and only logs activity on the server PC, not from the remote GUI.

MCD database

config_mcd_1_log

Management system configuration and start, stop, and GUI login logs.

CCM database

catalina_log.date.txt
jsui_log.date.txt
localhost_access_log.date.txt

CCM database log files for the Tomcat server and Web UI events. New files are created daily, so to monitor disc usage, periodically archive old log files.

DNS server

name_dns_1_log

Server state, DDNS updates, and zone transfers.

DHCP server

name_dhcp_1_log

Server state, new leases, and lease renewal.

TFTP server

file_tftp_1_log
file_tftp_1_trace

Server logging and tracing files, if created.


Each component can generate a number of log files, each with a preconfigured 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 three for the DNS server, and four for the DHCP and TFTP servers.


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.


Using the CLI

You can find out how the server maximums are set using the [server] type serverLogs show command and looking at the number (nlogs) and size (logsize) parameters. Follow this procedure:


Step 1 Run the server-type serverLogs show command.

nrcmd> dhcp serverLogs show 
100 Ok
nlogs=4 
logsize=1000000 

Step 2 Change the nlogs and logsize attribute values, if needed, using the [server] type serverLogs nlogs=value logsize=value command. You can set the nlogs value from between 2 and 100. (Note that if you set the value to 1, the actual value used is 2.)

nrcmd> dhcp serverlogs nlogs=6 logsize=200000 

Step 3 Stop and restart the Server Agent. On:

Windows:

net stop "AIC Server Agent 2.0" 
net start "AIC Server Agent 2.0" 

Solaris:

/etc/init.d/aicservagt stop 
ps -leaf | grep nwr 
kill -9 pid pid ... any processes left running in this ps.... 
/etc/init.d/aicservagt start 

Linux:

/etc/rc.d/init.d/aicservagt stop 
ps -leaf | grep nwr 
kill -9 pid pid ... any processes left running in this ps.... 
/etc/rc.d/init.d/aicservagt start 


Monitoring and Reporting Server Status

You can monitor the state of your Network Registrar servers by displaying or reporting aspects of a server's health. The following items can decrement the server's health, so you should monitor their status periodically. For a:

DNS server:

Memory

Inability to contact its root servers

DHCP server:

Configuration errors

Memory

Packet caching low

Options not fitting in the stated packet limit

No more leases available

TFTP server:

Memory

Socket read or write error

Exceeding the overload threshold and dropping request packets


Tip On a UNIX machine, you can run the aicstatus command in the /opt/nwreg2/usrbin/ directory to see if your server is running. See the Network Registrar Installation Guide for details.


Adding Servers to the Server Status Monitor

You can view a server's status by checking the Manage Protocol Servers page of the Web UI, or adding the server to the Server Status Monitor in the GUI.

Using the Web UI

On the Primary Navigation bar, click Administration. On the Secondary Navigation bar, click Servers. Check the Manage Protocol Server s page for the state and health of each server. See the Network Registrar Web UI Guide for details.

Using the GUI

The Status Monitor window is where you can place server icons to monitor their state. The icons change to reflect the server's current state. The traffic lights indicate the server's state—started is green, stopped is red. The bar to the right of the traffic light shows the server's health, which is a combination of server resources and network balance.

To add a server to the Status Monitor, right-click the server in the Server Manager window. (Alternatively, choose the server and click the Servers menu.) Then, click Add to Status Monitor. (Alternatively, drag the server icon to the Status Monitor window.)

You can add as many servers as you want to the Status Monitor window. They can be from any of the clusters to which you connected.


Tip When Network Registrar cannot contact the server, you see the warning triangle and exclamation point, and the green or red color is muted. The warning can mean that the network is down, the server machine crashed, the server was stopped from the control panel, or the client lost its address (hence, its communication with the server).


Removing Servers from the Server Status Monitor

You can remove a server from the Server Status Monitor in the GUI. In the Status Monitor window, right-click the server that you want to remove. Then, click Remove.

Displaying the Server's Health

You can display a server's health (how well it is running) by using the [server] type getHealth command in the CLI. The number 10 indicates the highest level of health, 0 that the server is not running.


Tip Use any descending health values as a reminder to check the log files for the particular server.


Using the Web UI

On the Primary Navigation bar, click Administration. On the Secondary Navigation bar, click Servers. Check the Manage Protocol Server s page for the state and health of each server. See the Network Registrar Web UI Guide for details.

Using the CLI

nrcmd> dhcp getHealth 
100 Ok
10

Displaying Server Statistics

You can display statistics about a server.

Using the CLI

Use the [server] type getStats command to display the specified server's statistics. The statistics for the DNS and DHCP servers are encoded in curly braces followed by sets of digits, as described in Table 4-3 for DNS, Table 4-4 for DHCP, and Table 4-5 for TFTP.

nrcmd> dns getStats 
100 Ok
{Cisco Systems, Inc. DNS Server, Release 6.0 nightly build #114597, Aug 26 2002 15:31:42}
3 114913 100363 4 2 384 0 0 0 36 0 382 0 0 0

Table 4-3 DNS Statistics 

Position
Description

{1}

Implementation ID (release and build information)

2

Recursion services (3 in the example)

3

Server up time, in seconds (82245 in the example)

4

Server reset time, in seconds (82236 in the example)

5

Server reset number, as a frequency (4 in the example)

6

Requests authoritatively answered (0 in the example)

7

Requests answered with "no such name" (0 in the example)

8

Requests answered with "no such data" (0 in the example)

9

Requests nonauthoritatively answered (0 in the example)

10

Requests nonauthoritatively answered with "no such data" (0 in the example)

11

Requests referred to other servers (0 in the example)

12

Requests answered with errors (0 in the example)

13

Requests for names one label long (0 in the example)

14

Requests refused (0 in the example)

15

Requests received unparsable (0 in the example)

16

Requests aborted for other errors (0 in the example)


nrcmd> dhcp getStats 
100 Ok
{Tue Aug 27 13:06:18 2002} 0 0 0 0 0 0 0

Table 4-4 DHCP Statistics 

Position
Description

{1}

Server start date and time

2

DISCOVER packets (0 in the example)

3

REQUEST packets (0 in the example)

4

RELEASED packets (0 in the example)

5

OFFER packets (0 in the example)

6

ACK (acknowledgement) packets (0 in the example)

7

NACK (negative acknowledgement) packets (0 in the example)

8

DECLINE packets (0 in the example)


nrcmd> tftp getStats 
100 Ok
{Cisco Systems, Inc. TFTP Server, Release 6.0 nightly build #114597, Aug 26 2002
16:53:05} 4 7 6 512 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Table 4-5 TFTP Statistics 

Position
Description

{1}

Implementation ID (release and build information)

2

Server state (4 in the example)

3

Time since reboot (7 in the example)

4

Time since reset (6 in the example)

5

Packets available (512 in the example)

6

Packets in use (0 in the example)

7

Total packets received (0 in the example)

8

Total packets sent (0 in the example)

9

Total packets drained (0 in the example)

10

Total packets dropped (0 in the example)

11

Total packets malformed (0 in the example)

12

Total read requests (0 in the example)

13

Total read requests completed (0 in the example)

14

Total read requests refused (0 in the example)

15

Total read requests ignored (0 in the example)

16

Total read requests timed-out (0 in the example)

17

Total write requests (0 in the example)

18

Total write requests completed (0 in the example)

19

Total write requests refused (0 in the example)

20

Total write requests ignored (0 in the example)

21

Total write requests timed-out (0 in the example)

22

Total CSRC 1.0 DOCSIS requests (0 in the example)

23

Total CSRC 1.0 DOCSIS requests completed (0 in the example)

24

Total CSRC 1.0 DOCSIS requests refused (0 in the example)

25

Total CSRC 1.0 DOCSIS requests ignored (0 in the example)

26

Total CSRC 1.0 DOCSIS requests timed-out (0 in the example)

27

Read requests per second (0 in the example)

28

Write requests per second (0 in the example)

29

CSRC 1.0 DOCSIS requests per second (0 in the example)


Using the GUI

In the Server Manager window, right-click the server whose statistics you want to view. Then, click Show Statistics. In the Statistics window, click Refresh to refresh the statistics.

Displaying IP Address Usage

You can generate an IP address usage report.

Using the CLI

Use the report command to display the IP address usage for specified servers. See the Network Registrar CLI Reference for additional options you can set.

nrcmd> report dhcp-only 
100 Ok

Network  Mask Cluster   Role Scope         Network      Total Static Unalloc Addrs % Free
 Free Reserved Leased Dyn Leased Unavail Deactiv Other Avail Other Reserv
C0A83200   24 localhost NONE examplescope1 192.168.50.0                        178   100%
  178        0      0          0       0       0           0            1
C0A80000   16                              192.168.0.0  65536      0   65357   178   100%
  178        0      0          0       0       0           0            1

Total                                                   65536      0   65357   178   100%
  178        0      0          0       0       0           0            1

100 Ok

Displaying Related DHCP Servers

Network Registrar displays a report about related servers in a DHCP failover configuration that contains the following information:

Type—Main or backup DHCP server

Server name—DNS name of the server

IP address—Server's IP address in dotted octet format

Requests—Number of outstanding requests, or two dashes if not applicable

Communication status—OK or INTERRUPTED

Cluster state—Failover state of this DHCP server

Partner state—Failover state of its partner server

Using the Web UI

On the Primary Navigation bar, click DHCP. On the Secondary Navigation bar, click Failover. The List DHCP Failover Pairs page shows any related DHCP servers. See the Network Registrar Web UI Guide for details.

Using the CLI

Use the dhcp getRelatedServers command to display the connection status between the main and partner DHCP server. If there are no related servers, the output is simply "100 Ok." For details on the output from this command, see the "Monitoring Failover Server Status" section on page 11-7.

nrcmd> dhcp getRelatedServers 
100 Ok

Using the GUI

In the Server Manager window, right-click the DHCP server for which you want to show the related server. Click Show related servers. This option is only available if you configured DHCP failover. See Chapter 11, "Configuring DHCP Failover." Network Registrar displays the Related Servers window. Network Registrar refreshes the window every ten seconds. If you want to refresh the window immediately, click Refresh.

Displaying Leases

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

Using the Web UI

On the Primary Navigation bar, click DHCP. On the Secondary Navigation bar, click Scopes. Click a scope name on the List/Add DHCP Scopes page to open the Edit DHCP Scope page. Halfway down the page, click the List Leases button to open the List DHCP Lease for Scope page. See the Network Registrar Web UI Guide for details.

Using the CLI

Use the lease list command to view the properties of all leases.

nrcmd> lease list 
100 Ok

Using the GUI

In the Server Manager window, right-click the scope and click Properties. In the Scope Properties dialog box, click the Leases tab and select the lease. Then, click Lease Properties. The properties of the lease you chose appear.

Backing up the Network Registrar Databases

Because the Network Registrar database does a variety of memory caching and may be active at any time, you cannot rely on third-party system backups to protect the database. For one thing, there may be Network Registrar operations in progress during the backup, causing backup data inconsistency and an unusable replacement database.

For this purpose, Network Registrar provides a shadow backup facility, mcdshadow. Once a day, at a configurable time, Network Registrar suspends all activity to the database and takes a snapshot of the critical files. This snapshot is guaranteed to be a consistent view of the database. The mcdshadow program backs up the DNS data even when you run the shadow backup on a secondary server. This backup is only a single generation backup. So, to maintain multiple backup versions, implement an archiving strategy.

Using Third Party Backup Programs With the mcdshadow Utility

You should avoid scheduling third party backup programs while mcdshadow is operating, with a margin of an hour in either direction. As described in the "Setting the Shadow Backup Time" section, the default shadow backup time is daily at 23:45.


Caution Configure third party backup programs to skip the Network Registrar operational database directories and files, and to back up only their shadow copies. Otherwise, your server might crash. The operational files are listed in the "Backup Strategy" section. The shadow copies that you can back up are the db.bak, dhcp.bak, dns.bak, mcd.bak, and ccm.bak files in the .../data directory.

Network Registrar also maintains lock files in the /tmp directory on Solaris and Linux, and the \Temp directory on Windows. They are recreated during reboot, but are vital while a system is running. Any maintenance process (such as virus scanning and archiving) should exclude this temporary directory, together with the operational database directories and files.

Before Performing a Backup or Recovery

Before undertaking a database backup or recovery, be sure to understand that the notation ".../data/db" in the following sections refers to directories in the Network Registrar product installation path, depending on the operating system. On:

Windows, ".../data/db" means \Program Files\Network Registrar\data\db (if you installed in the default directory)

UNIX and Linux, ".../data/db" means /var/nwreg2/data/db

Network Registrar database utility programs mentioned in the following sections are located in the ".../bin" directory, which you run as its full path name. On:

Windows, ".../bin/program" means \Program Files\Network Registrar\bin\program

UNIX and Linux, ".../bin/program" means /opt/nwreg2/bin/program


Note Use only the approved utilities for each type of database, as described in the following sections.


Backup Strategy

The backup strategy involves backing up three databases using the mcdshadow utility:

MCD database: ...data/db

CNRDB and CCM database: ...data/dhcp/ndb, data/dns/ndb, data/mcd/ndb, and data/ccm/ndb

DNS zone checkpoint database: ...data/dns/zchk

The most basic component of a backup strategy is the daily shadow backup. When problems occur with the operational database, you might need to try recovering based on the previous day's shadow backup. Therefore, you must recognize and correct any problems that prevent a successful backup. The most common problem is disk space exhaustion. To get a rough estimate of disk space requirements, sum up the sizes of the following MCD and CNRDB database files:

.../data/ccm/ndb/* 
.../data/db/mcddb.d0* 
.../data/dhcp/ndb/dhcp.ndb 
.../data/dhcp/ndb/logs/log.* 
.../data/dns/ndb/dns.ndb 
.../data/dns/ndb/logs/log.* 
.../data/dns/zchk/* 
.../data/mcd/ndb/* 

A conservative approach is ten times the space consumed by these combined database files. System load, such as usage patterns, application mix, and the load on Network Registrar itself, may dictate that a much larger reserve of space be available.

You should regularly archive existing shadow backups (such as to tape, other disks, or other systems) to preserve them for possible future recovery purposes.


Caution There are different database technologies Network Registrar uses with distinct sets of utility programs, as described in the following sections. Using a utility on the wrong type of database can cause database corruption. Use only the utilities indicated. Also, never use the database utilities on the operational database, only on a copy.

Setting the Shadow Backup Time

You can set the time at which an automatic shadow backup should occur through a single entry in the system registry, at the following paths. On:

Windows: HKEY_LOCAL_MACHINE/SOFTWARE/American Internet/Network Registrar/2.0/DBShadowTime

UNIX and Linux: /opt/nwreg2/conf/aic.conf

The registry entry is a string that represents the time of day at which the shadow backup is scheduled to occur, in 24-hour HH:MM format. The default is 23:45. If you remove this registry entry or set it to an illegal value (for example, if it does not begin with a digit), you suppress the backups. The server is otherwise unaffected.

Performing a Manual Backup

You can also initiate a manual shadow backup with the mcdshadow utility. Your username and password are required. Enter the mcdshadow command at the command prompt to perform the shadow backup. Because a full copy of the database is created, the backup may take a few minutes.

Database Recovery Strategy

The database recovery strategy involves manually restoring up to four Network Registrar databases using tools specific to each type of database. This is different from the backup procedure in which one mechanism backs up all the server data. The two database types are called MCD and CNRDB. The four databases are:

MCD Configuration database

Central Configuration Management (CCM) MCD database

DNS CNRDB database

DHCP CNRDB database

The MCD database is generally used to store server configuration data. The CCM MCD database is used to store centrally managed data for the cluster. The DNS and DHCP CNRDB databases store state data for the DNS and DHCP servers.

Depending on what occurred with the database recovery event, you may need to apply one of the following options to all or just one of the databases:

Restore the integrity of one or more of the current database files—For example, if a primary server has a hard disk failure and the Network Registrar data resides on a secondary disk, you can repair the current configuration and state databases once the system is back on line.

Restore one or more backed up databases—For example, a server may have a hard disk failure and the Network Registrar data resides on a second disk. If you can repair two of the three existing databases, you can restore the third from backup.

Restore backed up system configuration and state databases—For example, if a system hard disk crashes and the Network Registrar database was on that disk, you can restore the database from a backup copy.

Each of the recovery options follows the same general approach. First, stop the Network Registrar server agent. Then, restore or repair the data. Finally, restart the server agent and monitor the server for errors.

After you are sure that you executed a successful database recovery, always manually execute the mcdshadow utility to make a backup of the current configuration and state.

Backing up and Recovering MCD Data

The operational database that the mcdshadow utility uses is in .../data/db and the shadow copy is in .../data/db.bak. The actual file names are mcddb.d01, mcddb.d02, and mcddb.d03.

The mcdshadow utility generates an SNMP trap if it finds inadequate disk space for the backup, provided that the trap is configured.


Caution For the MCD database, use only the dbcheck and keybuild utilities. Do not use the cnrdb_archive, cnrdb_recover, or cnrdb_verify utility that applies to the CNRDB database. See the "Troubleshooting Servers and Databases" section for details. The dbcheck utility encounters errors if you try to check the databases while the servers are running, due to access conflicts with the servers. You must stop the servers before you run the utility.

Checking MCD Database Integrity

You can use the dbcheck utility to check the integrity of the MCD database. Stop all Network Registrar servers. Go to the .../data/db directory for the MCD database. As a safety check, enter the command .../bin/dbcheck -a mcddb. This requires root privileges.

Recovering MCD Data from a Damaged Database

Depending on the event that caused the database corruption, you can restore the database to a healthy state using the current data. Here are the steps:


Step 1 Stop the Network Registrar Server Agent.

Step 2 Change to the .../data/db directory.

Step 3 Rebuild the key files by entering the command .../bin/keybuild mcddb.

Step 4 As a safety check, enter the command .../bin/dbcheck mcddb. This requires root privileges.


Remember to stop the servers first. If there are any indications that the database recovery was unsuccessful, restore the database from a backup, as described in the "Recovering MCD Data from Backup" section. Also see the "MCD Recovery Errors" section.

Recovering MCD Data from Backup

Use the shadow backup to recover MCD data, either because a system crash corrupted the regular working database or the disk on which it resides is corrupted.


Step 1 Stop the Network Registrar Server Agent. Be sure that enough disk space is available for two copies of the database files, plus a 15% safety margin.

Step 2 Ensure that the following three files are in .../data/db.bak: mcddb.d01, mcddb.d02, and mcddb.d03.

Step 3 Copy these files to .../data/db. Do not use the move command, because you may need these files again. You do not need to delete the current contents of the .../data/db directory, as these files are cleaned up automatically.

Step 4 Change to the .../data/db directory.

Step 5 To rebuild the key files, enter the command .../bin/keybuild mcddb.

Step 6 As a safety check, enter the command .../bin/dbcheck mcddb. This requires root privileges.



Caution The CCM CNRDB database maintains centrally managed configuration data that is synchronized with the server configuration data. After restoring from backup, be sure to also restore the CCM CNRDB database from the same backup to maintain a consistent use of your configuration data.

MCD Recovery Errors

You should not have errors. If you do, ensure that:

The Network Registrar Server Agent (aicservagt) is stopped.

Your current working directory is .../data/db directory.

The mcddb.dbd and mcdschema.txt files are present in the .../data/db directory. If the files are lost or corrupted, backup files are stored in the .../data/db.bak directory.

MCD Data Files

You need the files listed in Table 4-6 for a fully functioning MCD database. As described earlier, only a subset of these files are present in a shadow backup. You need at a minimum the mcddb.dbd, mcddb.d0x, and mcdschema.txt files to rebuild the database from a backup.

Table 4-6 MCD Data Files in .../data/db Directory 

Data File
Description

mcddb.dbd

Template file that describes the low level data schema for the MCD runtime library. Network Registrar cannot run without this file.

mcddb.k01-k03

Key files that contain the redundant data—Network Registrar does not back up these files because they can be completely rebuilt with the keybuild command.

mcddb.d01-d03

MCD data repository files.

mcdConfig.txt

Windows-only text file from which Network Registrar configures the initial install time database.

mcdschema.txt

Text file containing a version number of the schema in the mcddb.dbd file. Network Registrar does not try to open the database unless the number in this file matches a version constant in the libraries. Network Registrar cannot run without this file.

vista.taf, tcf, tjf

Working files MCD runtime uses to ensure transactional integrity. When database files are restored from a backup, the server uses or discards these files as needed.


Backing up CNRDB Data

In the case of the CNRDB databases, the mcdshadow utility copies the database and all log files to a secondary directory in the directory tree of the installed Network Registrar product. For:

DHCP, the operational database is in the .../data/dhcp/ndb directory and the associated operational logs are in the .../data/dhcp/ndb/logs directory. The database shadow copy is in the .../data/dhcp.bak/ndb directory and the associated log copy is in the .../data/dhcp.bak/ndb/logs directory.

DNS, the operational database is in the .../data/dns/ndb directory. The important operational components are the changeset database and zone checkpoint files. The changeset database is in the .../data/dns/ndb/dns.ndb file, and its associated log files are in the .../data/dns/ndb/logs directory. The zone checkpoint files are in the .../data/dns/zchk directory. The shadow copies are in the .../data/dns.bak directory.

CCM, the operational database and associated log files are in the .../data/ccm/ndb directory. The shadow copies are in the .../data/ccm.bak directory.

MCD, the operational database and associated log files are in the .../data/mcd/ndb directory. The shadow copies are in the .../data/mcd.bak directory.

The actual file naming convention is:

Database: dhcp.ndb and dns.ndb

Log files: log.0000000001 through log.9999999999—Typically only a small number of log files are present on a system. The specific file name extensions in use at a site vary over time as the database is used. These files are not humanly readable.

Recovering CNRDB Data from a Damaged Database

Depending on the event that caused the database corruption, you can restore the database to a healthy state using the current data. This is the best option. Always attempt recovery on a copy of the database file and associated log files, never on the operational files. This is a simple file copy operation, distinct from a shadow backup. Also, never attempt a recovery while Network Registrar is running.


Caution It is possible to damage the CNRDB database files without the damage being immediately obvious. Such damage could occur because of (a) inappropriately deleting log files; (b) mixing pre- and postrecovery database and log files; (c) attempting recovery of database files currently in use by an application; or (d) using tools intended for other databases, such as MCD database tools. For the CNRDB database, be sure to use only the cnrdb_archive, cnrdb_recover, and cnrdb_verify utilities. Do not use the keybuild or dbcheck utility that applies to the MCD database.

Use the cnrdb_recover utility, included in the Network Registrar product distribution, for database recovery. Use this tool with care. You should never use it directly on an operational database, or on files another application is concurrently accessing. On a successful database recovery, do not intermingle the recovered files (database file and log files) with files from another source, such as the operational database or shadow backups. Recovered database files acquire state information that make them incompatible with older database files.

Here is the procedure for CNRDB database recovery:


Step 1 Stop the Network Registrar server agent. This stops all the protocol servers. Ensure that enough disk space is available for two copies of the database files, plus a 15% safety margin.

Step 2 Create two temporary directories, outside the Network Registrar installation tree, for safety. On Windows, these might be C:\Temp\dbcopy and C:\Temp\recover. On Solaris or Linux, these might be /scratch/dbcopy and /scratch/recover.

Step 3 Copy the database files using shell copy commands, in the following order:

a. Copy the CNRDB operational database file to subdirectories of .../dbcopy/. For:

DHCP, .../data/dhcp/ndb/dhcp.ndb file to .../dbcopy/dhcp/

DNS, .../data/dns/ndb/dns.ndb file to .../dbcopy/dns/

CCM, .../data/ccm/ndb/*.db files to .../dbcopy/ccm/

MCD, .../data/mcd/ndb/*.db files to .../dbcopy/mcd/

b. Copy the associated log files to subdirectories of .../dbcopy/. For:

DHCP, .../data/dhcp/ndb/logs/log.* files to .../dbcopy/dhcp

DNS, .../data/dns/ndb/logs/log.* files to .../dbcopy/dns

CCM, .../data/ccm/ndb/logs/log.* files to .../dbcopy/ccm/

MCD, .../data/mcd/ndb/logs/log.* files to .../dbcopy/mcd/

c. Double-check that the database file and all log files were copied correctly. The .../dbcopy area contains a safety copy of the database files. Do not allow these files to be modified in any way. Do not run any utilities or servers on these files.

Step 4 Copy the same operational database files again, but this time to subdirectories of the .../recover directory.

Step 5 Try to recover the current database files:

a. Change to the appropriate subdirectory of .../recover and run the recovery utility program, cnrdb_recover -c -v. It is helpful to use the -v option; otherwise, the utility displays no output in the absence of errors. For details on this utility and its further options, see the "Using the cnrdb_recover Utility" section.

b. Run the verification utility program for each of the servers. There is no output if the verification was successful. For details on the cnrdb_verify utility and its options, see the "Using the cnrdb_verify Utility" section. For:

DHCP, cnrdb_verify dhcp.ndb in .../data/dhcp/ndb

DNS, cnrdb_verify dns.ndb in .../data/dns/ndb

CCM, cnrdb_verify each *.db file in .../data/ccm/ndb

MCD, cnrdb_verify each *.db file in .../data/mcd/ndb

c. Optionally, for additional confidence, run the cnrdb_archive utility program:

cnrdb_archive -l lists all log files

cnrdb_archive -s lists the database file

d. If there are any indications that an error occurred, proceed to restore the database from a backup, as described in the "Recovering CNRDB Data from Backup" section.

e. Replace the operational database file and log files in the Network Registrar installation tree with the files in .../recover. Be careful not to mix database files processed with cnrdb_recover with those that were not. To avoid this problem, delete the operational CNRDB file and log files from the Network Registrar installation. In copying the recovered files, ensure that the database file and log files are copied to the appropriate and separate directories in the Network Registrar installation tree.

f. Delete the files in the .../data/dhcpeventstore directory.

g. Restart Network Registrar.


Recovering CNRDB Data from Backup

If there are any indications, such as server log messages or missing data, that database recovery was unsuccessful, you may need to base a recovery attempt on the current shadow backup (in the Network Registrar installation tree).

The procedure (as follows) is identical to that of Step 5 in the previous section, except that the current contents of .../dbcopy/ are not disturbed, and the source of the files copied to .../recover is .../data/dhcp.bak, .../data/dns.bak, or .../data/ccm.bak.


Step 1 Once the files from the shadow backup are copied to .../recover, copy the operational log files from .../data/dhcp/ndb/logs, .../data/dns/ndb/logs, or .../data/ccm/ndb/log.* to .../recover. This may cause older files in.../recover to be overwritten by newer log files from the operational database. This is expected and typically occurs to at least one log file. Be careful, however, not to do the reverse by overwriting new log files from the operational database with older ones from the shadow backup.

If the cnrdb_recover operation fails, try it again, this time using only the shadow backup files and not copying the operational log files. In this case, all data written to the database since the shadow backup was made is lost.

Step 2 If this fails, perhaps because the current shadow backup is simply a copy of corrupted files, use the most recent previous shadow backup. (This illustrates the need to regularly archive shadow backups.) You cannot add operational log files to older shadow backup files. All data added to the database since the shadow backup was made will be lost.

Step 3 After a successful database recovery:

a. As a safety measure, archive the contents of .../dbcopy/.

b. Using the mcdshadow utility, initiate an immediate shadow backup and archive the files. See the "Performing a Manual Backup" section. This backup is the earliest, oldest backup from which you can attempt a future recovery. You cannot use older shadow backups.



Caution The CCM CNRDB database maintains centrally managed configuration data that is synchronized with the server configuration databases. If you restore the CCM CNRDB files from backup, also restore the MCD database from the same backup.

Virus Scanning While Running Network Registrar

If you have virus scanning enabled on your system, it is best to configure it to exclude certain Network Registrar directories from being scanned. Including these directories might impede Network Registrar operation. Exclude from scanning the following directories and their subdirectories:

On Windows: \Program Files\Network Registrar\data and ...\logs

On UNIX and Linux: /var/nwreg2/data and .../logs

Troubleshooting Servers and Databases

The following sections describe troubleshooting the DNS, DHCP, and TFTP servers, as well as the Network Registrar databases.

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 avoid doing in particular:

Do not have less than 512 MB of memory and less than 2.5 GB of a data partition.

Do not reboot a cable modem termination system (CMTS).

Do not disable DHCP failover.

Do not reload, restart, or disrupt Network Registrar with failover resynchronization in progress.

Troubleshooting Server Failures

The Server Agent process (aicservagt) normally detects server failures and restarts 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, causing the server to fail 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:

Windows:

net stop "AIC Server Agent 2.0" 
net start "AIC Server Agent 2.0" 

Solaris:

/etc/init.d/aicservagt stop 
/etc/init.d/aicservagt start 

Linux:

/etc/rc.d/init.d/aicservagt stop 
/etc/rc.d/init.d/aicservagt start 

Step 2 Keep a copy of all the log files. By default, log files are located in the /var/nwreg2/logs directory on UNIX, and the C:\Program Files\Network Registrar\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 the "Using the TAC Tool" section, or save the core or user.dmp file, if one exists, depending on the operating system. On:

UNIX or Linux, the core file is located in the parent directory of the server executables, /opt/nwreg2. Save a renamed copy of this file that Network Registrar does not overwrite.

Windows, the user.dmp file is located in the system directory, which varies depending on the Windows system. Search for this file and save a renamed copy.

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 Network Registrar server problems.


Troubleshooting and Optimizing the TFTP Server

You can set certain attributes to troubleshoot and optimize TFTP server performance.

Tracing TFTP Server Activity

The TFTP server has two commands that help create more output to logs and can be useful in troubleshooting, although this usually impacts performance. These commands set up server packet tracing. The tftp getTraceLevel command identifies the current trace level, which by default is 0, or no tracing. The tftp setTraceLevel command sets the packet tracing to a value between 0 and 4. The trace files are located in the /logs subdirectory of your installation directory. Windows tracing goes to the file_tftp_1_log file; Solaris and Linux tracing goes to the file_tftp_1_log and file_tftp_1_trace files.

nrcmd> tftp getTraceLevel 
100 Ok
0
nrcmd> tftp setTraceLevel 4 
500 - 0x2d tftp setTraceLevel 4

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's 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 will only work if the TFTP server is started. Turn on packet tracing only for debugging purposes, and then not for any extended time, because tracing can have significant performance impact.


Optimizing TFTP Message Logging

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—Master controller of server logging, which defaults 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. To change it, you must reload the server.

nrcmd> tftp set log-level=3 
100 Ok
log-level=3
nrcmd> tftp reload 
100 Ok

Log settings—This is the second level of logging control and can take the value default or no-success-messages. Default logging is the default, which does not alter the default 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. Reload the server after changing this value.

nrcmd> tftp set log-settings=no-success-messages 
100 Ok
log-settings=no-success-messages
nrcmd> tftp reload 
100 Ok

Log file count and size—Sets how many log files to maintain and how large to allow them to get in the /logs directory. The default is to maintain a maximum of four files of one megabyte each. Reload the server after changing these values.

nrcmd> tftp set log-file-count=4 
100 Ok
log-file-count=4
nrcmd> tftp set log-file-size=1 
100 Ok
log-file-size=1
nrcmd> tftp reload 
100 Ok

Enabling File Caching

You can improve TFTP server performance significantly by enabling file caching on the server. You must do this explicitly, because it is disabled by default. You must also create and point to a file cache directory, and you can set the maximum size of this directory. Here are the steps:


Step 1 Determine where you want to store the TFTP cache files. This cache directory becomes a subdirectory of the TFTP home directory, which is by default .../data/tftp. On Windows, the home directory default is C:\Program Files\Network Registrar\data\tftp; on Solaris and Linux, it is /var/nwreg2/data/tftp.

If you want a different location, use the home-directory attribute.

nrcmd> tftp set home-directory=/tmp/tftp 
100 Ok
home-directory=/tmp/tftp

Step 2 Change to the TFTP home directory and create the cache directory, such as CacheDir, in the home directory. Note that Network Registrar ignores any files in any subdirectories of this cache directory.

mkdir CacheDir 

Step 3 Set up the TFTP server to point to the cache directory. You cannot use relative paths in the directory name, such as .../cachedir. If the directory does not exist, file caching cannot occur.

nrcmd> tftp set file-cache-directory=CacheDir 
100 Ok
file-cache-directory=CacheDir

Step 4 Set the maximum memory size, in bytes, of the cache. The default is 32 K bytes. Network Registrar loads all files into cache that cumulatively fit this memory size. If you set the value to 0, Network Registrar does not cache any data, even if you enable file caching.

nrcmd> tftp set file-cache-max-memory-size=32000 
100 Ok
file-cache-max-memory-size=32000

Step 5 Copy all of the files you want cached into the cache directory, and not into any subdirectory. Because all files in this directory are loaded into cache, do not include large files.

Step 6 Enable file caching and reload the server.

nrcmd> tftp enable file-cache 
100 Ok
file-cache=enabled
nrcmd> tftp reload 
100 Ok

Network Registrar logs the name of each cached file, and skips any it cannot load. It reads in all files as binary data and translates them as the TFTP client requests. For example, if a client requests a file as NetASCII, the client receives the cached data in that form.

Step 7 Writing to cache is not allowed. If you need to update a cache file, overwrite it in the cache directory, then reload the server.


Using the cnr_exim Data Import and Export Tool

Because Network Registrar 6.0 extends the data repositories to serve the Web UI, the current Network Registrar data import and export tool, mcdadmin, is no longer adequate (see the "Using the mcdadmin Tool" section). The cnr_exim data import and export tool now serves to import data to and export data from Network Registrar 6.0 servers. The cnr_exim tool overcomes the mcdadmin limitations of not being able to export dynamic resource record information.

Before using the cnr_exim tool, exit from the GUI or CLI. Then, find the tool on:

Windows, by default, at C:\Program Files\Network Registrar\Bin\cnr_exim.exe

Solaris or Linux, at /opt/nwreg2/usrbin/cnr_exim

You must reload the server for the imported data to become active.

The data export syntax is:

> cnr_exim -e exportfile [-N username -P password -C cluster] 

(The username and password are prompted for if omitted. The cluster defaults to the local cluster.)

To export raw data, use the -x option.

> cnr_exim -e exportfile.txt -x 

To export dynamic resource records along with other data, use the -a dynRR option; to export them alone without any other components, add the -c "none" option.

> cnr_exim -e exportfile.txt -a dynRR -c "none" 

To export DNS server and zone components as binary data in raw format, use the -x and -c options.

> cnr_exim -e exportfile.txt -x -c "dnsserver,zone" 

The data import syntax is:

> cnr_exim -i importfile [-N username -P password -C cluster] 

The import file must be in raw format.

You can also overwrite existing data with the -o option.

> cnr_exim -i importfile.txt -o 

Table 4-7 describes all the qualifying options for the cnr_exim tool.

Table 4-7 cnr_exim Options 

Option
Description

-a dynRR

Imports or exports dynamic resource records only. It assumes that the DNS server was reloaded and zone data exists. (You can combine this option with the
-c "none" option.)

-c "components"

Imports or exports Network Registrar components, as a quoted, comma-delimited string. Use -c help to view the supported components. User names are not exported by default; you must explicitly export them using this option, and they are always grouped with their defined groups and roles. Secrets are never exported.

Note After you import administrator names, you must set new passwords for them. If you export groups and roles separately from user names (which are not exported by default), their relationship to user names is lost.

-C cluster

Imports from or exports to the specified cluster. Defaults to localhost.

-e exportfile

Exports the configuration to the specified file.

-h

Displays help text for the supported options.

-i importfile

Imports the configuration to the specified file. The import file must be in raw format.

-N username

Imports or exports using the specified username.

-o

When used with the -i (import) option, overwrites existing data.

-P password

Imports or exports using the specified password.

-x

When used with the -e (export) option, exports binary data in raw format.


Using the mcdadmin Tool

The mcdadmin tool is a utility with which you can import and export the MCD database and diagnose Network Registrar conditions under Cisco guidance. This tool is relevant for versions of Network Registrar before 6.0 only.


Caution Use this tool only under the guidance of the Cisco Technical Assistance Center. Casual use can inflict catastrophic damage to the Network Registrar configuration database. This tool is only relevant for version of Network Registrar before 6.0. For Network Registrar 6.0 data imports and exports, see the "Using the cnr_exim Data Import and Export Tool" section.

Before using the mcdadmin tool, exit from the GUI or CLI. Then, find the tool on:

Windows, by default, at C:\Program Files\Network Registrar\Bin\mcdamin.exe

Solaris or Linux, at /opt/nwreg2/usrbin/mcdadmin

Run the tool from the command shell. This example displays the application version number:

> mcdadmin -v 

This command overwrites the current configuration database with the installation defaults:

> mcdadmin -i cnrconfig.txt -z m=3 

This command exports the scopePC scope configuration data to the cnrconfig.txt file:

> mcdadmin -e cnrconfig.txt -p /servers/name/dhcp/1/scopes/scopePC/ -x -z m=3 

Table 4-8 describes the qualifying options. The absolute path to an object in the MCD tree, dbpath, always begins and ends with a forward slash (/).

Table 4-8 mcdadmin Options 

Option
Description

-a area

Specifies the area of the database to use: config (the default), state, altconfig, or altstate.

-c

Creates the MCD database, and deletes your existing one.


Caution Use this option only under Cisco Technical Assistance Center guidance.

-d dbname

Specifies the database name or the default database.

-e exportfile

Exports the configuration to the specified file, or a dash (-) for standard output.

> mcdadmin -N admin -P changeme -e mcdconfig.txt 
> mcdadmin -N admin -P changeme -e - 

-G gen

When used with the -e (export) option, specifies the generation number for the resource record table export.

-H

Dumps the full table generational history.

-i importfile

Imports the configuration from the specified file, or a dash (-) for standard input.

> mcdadmin -N admin -P changeme -o -i mcdconfig.txt -z m=3 


Caution If used with -o, -i overwrites the current database. If not used with -o, creates new the entries introduced by the file.

-k

When used just by itself, kills the lock manager.

-l

When used with the -i (import) option, hold an exclusive lock while importing.

-o

Overwrites the contents of the current database with entries of the same name.

-O

Merges the data into the existing database, while ignoring unique keys and the resource record tables.

-p dbpath

When used with the -e (export) option, specifies the subset of the configuration database to export, as an absolute path.

> mcdadmin -N admin -P changeme -e scopepc.txt 
  -p /servers/name/dhcp/1/scopes/scopePC/ -x -z m=3 

-r dbpath

Removes the specified path in the MCD database, not including subentries.

> mcdadmin -r /servers/name/dhcp/1/scopes/scopePC/ 

-R dbpath

Recursively removes all entries below and including the specified path.


Caution Using this option can destroy large portions of the MCD database that may require partial or total reconstruction

dbpath

The use of dbpath in -p, -r, and -R is either an absolute path name starting with /, when it refers to that part of the MCD tree, or a server zone name tuple, starting with a colon (:). The fields after the colon are whitespace-separated and the name, or zone and name, can be left unspecified. For example, -p ":myserv example.com. mypath".

-t dir

Specifies the directory from which to get the database templates.

-T

Recopies the database templates when creating the database.

-v or -V

Prints version information.

-x

When used with the -e (export) option, exports binary data in raw format.

> mcdadmin -N admin -P changeme -e mcdconfig.txt -x 

-z class=n

Sets the debugging class or classes to level n.

> mcdadmin -N admin -P changeme -c -o -i mcdconfig.txt -z m=3 


Using the cnrdb_recover Utility

The cnrdb_recover utility is useful in restoring the Network Registrar databases to a consistent state after a system failure. You would typically use the -c and -v options with this command. However, Table 4-9 describes all the qualifying options. The utility is located in the installation bin directory.

Table 4-9 cnrdb_recover Options 

Option
Description

-c

Performs catastrophic recovery instead of normal recovery.

-e

Retains the environment after running recovery, rarely used unless there is a db_config file in the home directory.

-h dir

Specifies a home directory for the database environment. By default, the current working directory is used.

-t

Recovers to the time specified rather than to the most current possible date. The time format is [[CC]YY]MMDDhhmm[.ss] (the brackets indicating optional entries, with the omitted year defaulting to the current year).

-v

Runs in verbose mode.

-V

Writes the library version number to the standard output, and exits.


In the case of a catastrophic failure, restore a snapshot of all database files, along with all log files written since the snapshot. If not catastrophic, all you need are the system files at the time of failure. If any log files are missing, cnrdb_recover identifies the missing ones and fails, in which case you need to restore them and perform the recovery again.

This example shows possible output from this utility:

C:\temp\recover\dns> "C:\Program Files\Network Registrar\bin\cnrdb_recover" -c -v 
db_recover:Finding last valid log LSN:file:1 offset 83482 
db_recover:Recovery starting from [0][0] 
db_recover:Recovery complete at Thu Jul 25 21:18:58 2002 
db_recover:Maximum transaction ID 80000013 Recovery checkpoint [1][83770] 
db_recover:Recovery complete at Thu Jul 25 21:18:58 2002 
db_recover:Maximum transaction id 80000000 Recovery checkpoint [1][83770] 

If you forget to copy the log files into the directory, the output might look like this (note that the maximum transaction ID was not incremented):

C:\temp\dns> "C:\Program Files\Network Registrar\bin\cnrdb_recover" -c -v 
db_recover:Recovery complete at Thu Jul 25 21:19:20 2002 
db_recover:Maximum transaction id 80000000 Recovery checkpoint [0][0] 

Using the cnrdb_verify Utility

The cnrdb_verify utility is useful for verifying the structure of the Network Registrar databases. The command requires a file parameter. Use this utility only if you are sure there are no programs running that are modifying the file. Table 4-10 describes all its qualifying options. The utility is located in the installation bin directory.

Table 4-10 cnrdb_verify Options 

Option
Description

-h dir

Specifies a home directory for the database environment. By default, the current working directory is used.

-N

Prevents acquiring shared region locks while running, intended for debugging errors only, and should not be used under any other circumstances.

-q

Suppresses printing any error descriptions other than exit success or failure.

-V

Writes the library version number to the standard output, and exits.


Using the cnrdb_checkpoint Utility

The cnrdb_checkpoint utility is useful in setting a checkpoint for the database files so as to keep them current. The utility is located in the installation bin directory. The syntax is described in the usage information when you run the command.

C:\Program Files\Network Registrar\bin>cnrdb_checkpoint ? 
usage: db_checkpoint [-1Vv] [-h home] [-k kbytes] [-L file] [-p min]

Using the keybuild Tool

The keybuild tool is a utility you can use to rebuild the database key files, which contain redundant data with the MCD files. On:

Windows, click Start > Settings > Control Panel > Services, highlight AIC Server Agent, then click Stop. Go to the install-location\data\db folder and run the keybuild.exe file.

keybuild mcddb 

Solaris, stop the Server Agent. Go to the install-location/data/db folder. You need root privileges.

/etc/init.d/aicservagt stop 
keybuild -a mcddb 

Using the dbcheck Tool


Caution Do not run the dbcheck utility while the servers are running. Stop the servers first.

The dbcheck tool is a utility you can use to check the MCD integrity. You must have root privileges to run the dbcheck tool. On:

Windows, click Start > Settings > Control Panel > Services, highlight AIC Server Agent, then click Stop. Go to the install-location/data/db folder and run the dbcheck.exe file.

dbcheck mcddb 

Solaris, stop the Server Agent. Go to the install-location/data/db folder. You need to have administrator privileges.

/etc/init.d/aicservagt stop 
dbcheck -a mcddb 

Solaris and Linux Troubleshooting Tools

You can also use the following commands on Solaris and Linux systems to troubleshoot Network Registrar. To:

See all Network Registrar processes:

ps -leaf | grep nwr 

Monitor system usage and performance:

top 
vmstat 

View login or bootup errors:

On Solaris—grep /var/adm/messages*

On Linux—grep /var/log/messages*

View the configured interfaces and other network data:

ifconfig -a 

Using the TAC Tool

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. Network Registrar 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 as quickly as possible.

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. 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 you need. Figure 4-1 shows an example of the main index.html page included in this tar file.

Figure 4-1 TAC Tool Main HTML Page