Table Of Contents

Administering DFM

Security Issues

File Ownership and Protection

User Access

Ports and Protocols Used by DFM

Output Files

DFM and Browsers

How the DFM Broker Works

Information the DFM Broker Maintains

How DFM Clients Find the Broker

Domain Manager Settings

Special Commands

Domain Manager Properties

Correlation Tab

DFM and CiscoWorks2000 Processes

Administering DFM

---

These topics describe tasks you may need to perform when administering DFM:

•Security Issues

•How the DFM Broker Works

•Domain Manager Settings

•DFM and CiscoWorks2000 Processes

Security Issues

DFM is designed to maintain the security of your system if it is installed and used as described in Installing and Setting Up Device Fault Manager. Because some DFM processes run with root privileges, be aware of the guidelines in these topics:

•File Ownership and Protection

•User Access

•Ports and Protocols Used by DFM

•Output Files

•DFM and Browsers

File Ownership and Protection

Previously, DFM set file ownership to user bin. All DFM files are now installed with owner CASUSER. Only CASUSER can create, delete, or modify the files installed in $NMSROOT. $NMSROOT is the directory where CiscoWorks2000 is installed (for Solaris, the default value for $NMSROOT is /opt/CSCOpx, and for Windows 2000 and Windows NT, the default value is C:\Program Files\CSCOpx).

---

Caution Do not change the protection of any file or directory to be less restrictive. You may, if you wish, make the protections more restrictive.

---

---

Note On Windows 2000 and Windows NT, file protections are not enforced on FAT partitions.

---

User Access

DFM servers grant access to users who can form a TCP connection to their port. You can control this access in these ways:

•Controlling User Access with the --accept Option

•Controlling User Access through Port Control

---

Note To view the current access assigned to users, run a CiscoWorks2000 Permissions Report by selecting Server Configuration > Setup >
Security >Permissions Report.

---

Controlling User Access with the --accept Option

The --accept option is provided by the DFM servers and broker. Use this option to control the hosts that can connect to a DFM server. Host connections include DFM consoles, adapters, and utilities. Processes running on the same host as a server do not have special access—the server's host must be listed to allow the processes to access the host.

If an unlisted host attempts to initiate a connection, the server rejects the attempt, writes a message to the server's stderr file, and sends the message to the system logging facility.

To use the --accept option to control user access:

---

Step 1 Unregister the daemons with the daemon manager:

•For DFM notification adapters on Solaris, the commands are:

# NMSROOT/bin/pdcmd -u DfmFileNotifier

# NMSROOT/bin/pdcmd -u DfmTrapNotifier

# NMSROOT/bin/pdcmd -u DfmMailNotifier

On Windows 2000 and Windows NT, the commands are:

# NMSROOT\bin\pdcmd.exe -u DfmFileNotifier

# NMSROOT\bin\pdcmd.exe -u DfmTrapNotifier

# NMSROOT\bin\pdcmd.exe -u DfmMailNotifier

•For DfmServer on Solaris, the command is:

# NMSROOT/bin/pdcmd -u DfmServer

On Windows 2000 and Windows NT, the command is:

# NMSROOT\bin\pdcmd.exe -u DfmServer

•For DfmBroker on Solaris, the command is:

# NMSROOT/bin/pdcmd -u DfmBroker

On Windows 2000 and Windows NT, the command is:

# NMSROOT\bin\pdcmd.exe -u DfmBroker

Step 2 Decide which hosts you want to specify using the --accept option with arguments shown in Table 11-1:

Table 11-1 Arguments to the --accept Option

Argument	Description
host1,host2,...	Allow only host1,host2,... to connect to the server. Specify either hostnames or explicit IP addresses in a comma-separated list. Hostnames are resolved to one or more IP addresses, which are then used (the server does not use reverse lookups to determine the name of a connecting host). Note If you specify the clients as hostnames, be sure the hostname is in DNS, especially if you are using DHCP.
=any	Allow all incoming connections (default).

For example, the following command fragment would allow connections only from hosts lucy and ethel:

--accept=lucy,ethel

(See the installation guides for information on how to set options for automatically started servers.)

---

Note To allow connections from processes running on the same host, specify the host's name—do not use "localhost." This is because connections made using the DFM Broker will appear to come from the DFM Broker's host. Only connections that explicitly specify "localhost" as the target address will appear to come from localhost. Such target addresses may result in configurations that forward incoming connections (such as through software that provides an encrypted tunnel).

---

Step 3 Re-register the daemons with the daemon manager, specifying the clients that can connect to the broker and server (in this example, the DFM broker port is 9002 and lucy and ethel are the clients):

•For the DFM broker on Solaris (the following command is one line):

# NMSROOT/bin/pdcmd -r DfmBroker -e NMSROOT/objects/smarts/bin/brstart -f "--output 
--port=9002 --accept=lucy,ethel --restore=NMSROOT/objects/smarts/conf/broker.rps"

For the DFM broker on Windows 2000 and Windows NT (the following command is one line):

# NMSROOT\bin\pdcmd.exe -r DfmBroker -e NMSROOT\objects\smarts\bin\brstart.exe -f 
"--output --port=9002 --accept=lucy,ethel 
--restore=NMSROOT\objects\smarts\conf\broker.rps"

•For the DFM server on Solaris (the following command is one line):

# NMSROOT/bin/pdcmd -r DfmServer -e NMSROOT/objects/smarts/bin/sm_server -d DfmBroker -f 
"--bootstrap=DFM_bootstrap.conf --accept=lucy,ethel --output --name=DFM"

For the DFM server on Windows 2000 and Windows NT:

# NMSROOT\bin\pdcmd.exe -r DfmServer -e NMSROOT\objects\smarts\bin\sm_server.exe -d 
DfmBroker -f "--bootstrap=DFM_bootstrap.conf --accept=lucy,ethel --output --name=DFM"

•For DFM notification adapters on Solaris (the following commands are each one line, and will register the adapter processes to automatically start upon reboot):

# NMSROOT/bin/pdcmd -r DfmFileNotifier -d DfmServer -e 
NMSROOT/objects/smarts/bin/sm_notify -f "--adapter=filelog --output=sm_file_notifier"

# NMSROOT/bin/pdcmd -r DfmTrapNotifier -d DfmServer -e 
NMSROOT/objects/smarts/bin/sm_notify -f "--adapter=trap --output=sm_trap_notifier"

# NMSROOT/bin/pdcmd -r DfmMailNotifier -d DfmServer -e 
NMSROOT/objects/smarts/bin/sm_notify -f "--adapter=mail --output=sm_mail_notifier"

For DFM notification adapters on Windows 2000 and Windows NT (the following commands are each one line, and will register the adapter processes to automatically start upon reboot):

# NMSROOT\bin\pdcmd.exe -r DfmFileNotifier -d DfmServer -e 
NMSROOT\objects\smarts\bin\sm_notify.exe -f "--adapter=filelog --output=sm_file_notifier"

# NMSROOT\bin\pdcmd.exe -r DfmTrapNotifier -d DfmServer -e 
NMSROOT\objects\smarts\bin\sm_notify.exe -f "--adapter=trap --output=sm_trap_notifier"

# NMSROOT\bin\pdcmd.exe -r DfmMailNotifier -d DfmServer -e 
NMSROOT\objects\smarts\bin\sm_notify.exe -f "--adapter=mail --output=sm_mail_notifier"

If you do not want the daemons to start after a reboot, add the -n option to the end of the command, as in this File Notifier Adapter example on Solaris:

# NMSROOT/bin/pdcmd -r DfmFileNotifier -d DfmServer -e 
NMSROOT/objects/smarts/bin/sm_notify -f "--adapter=filelog --output=sm_file_notifier" -n

---

Controlling User Access through Port Control

You can request DFM servers to listen on a specified port (rather than a default port.) Contact the Technical Assistance Center if you wish to set up such a configuration. Note that DFM does not support firewalls between clients and servers.

Ports and Protocols Used by DFM

DFM uses the following ports and protocols.

•Ports:

–162

–9000 (if port 162 is occupied)

–9002

•Protocols:

–SNMP

–ICMP

–TCP/IP

–SMTP

Output Files

DFM is designed so that its output files can be written only into the DFM installation tree, which consists of the directories under $NMSROOT/objects/smarts. ($NMSROOT is the directory where CiscoWorks2000 is installed (for Solaris, the default value for $NMSROOT is /opt/CSCOpx, and for Windows 2000 and Windows NT, the default value is C:\Program Files\CSCOpx).)

DFM and Browsers

You can use DFM consoles within a Web browser. If you do this, do not use the same running browser to both access untrusted Web sites and manage your network.

If you continue fault monitoring after exiting CiscoWorks2000, you should close your web browser so other users cannot access your session.

How the DFM Broker Works

A client application, such as a console or an adapter, utilizes the broker to determine where the domain manager is running. When the domain manager starts, it registers the hostname of the machine it is running on and the TCP port it is listening on with the broker. Clients retrieve this information from the broker so that they can communicate with the domain manager.

Information the DFM Broker Maintains

The broker maintains the following information:

•The name of the domain manager and the host and TCP port it is running on.

•The status of each domain manager.

–Running indicates that the broker is able to communicate with the domain manager.

–Dead indicates that the domain manager exited unexpectedly or is unreachable. When the domain manager properly shuts down, it notifies the broker and the broker removes it from the list.

–Unknown indicates that the broker was restarted and that it is querying the domain manager to determine its state.

The broker checks the status of the domain manager every five minutes by connecting to it and determining whether a DFM process is running correctly. If the broker is unable to connect or the process is not running, it changes the status of the domain manager to dead.

•The process ID of the domain manager. This is the process ID assigned by the host's operating system. In some cases when the broker is restarted, the process ID of the domain manager is set to zero to indicate the broker does not know the process ID of the domain manager.

•The last time the state of the domain manager changed. This value is set when the domain manager registers with the broker and is updated if the broker determines that the domain manager is dead. When the broker restarts, it changes the status of the domain manager (marked Unknown to Running or Dead).

How DFM Clients Find the Broker

Clients follow these steps to determine the broker's location.

1. The client checks to see if the broker's location was passed as a command line option during startup.

2. The client checks the value of the SM_BROKER environment variable. The value of the SM_BROKER variable is normally set during installation.

3. The client checks if the broker is running on the host broker_machine and listening on TCP port 9002.

---

Note The hostname broker_machine is usually an alias, such as a DNS CNAME.

---

4. If the alias broker_machine is not defined, the client tries to use localhost:9002.

Domain Manager Settings

This section describes the parameters related to the operation of a domain manager. Changing these parameters can substantially affect analysis results. For normal operation, the default settings should be sufficient.

---

Caution Any change you make to the domain manager affect all consoles connected to the domain manager.

---

The two commands described in the "Special Commands" section are listed under the Domain menu and in the domain manager's pop-up menu. During normal operation, you will not need to use these commands.

Special Commands

Domain manager special commands are:

•Recompute Codebook

Recompute Codebook tells the domain manager to recompute the codebook because the managed system's inventory has changed. Analysis rules (codebook) are automatically computed from the analysis model and the managed topology. DFM automatically recomputes the codebook when the topology changes. It is not necessary to perform this procedure during normal operation.

•Correlate Now

Correlate Now forces the domain manager to analyze events. This is useful when the analysis interval is several minutes long, you know something has happened, and you want the domain manager to analyze the results now.

Domain Manager Properties

When the icon for the domain manager is selected, the Administration Console displays four tabs in the right panel: Correlation, Modules, Threads, and Inventory. The first three tabs control properties of the Domain Manager.

Correlation Tab

Correlation parameters determine how DFM diagnoses problems.

•Correlation Interval determines how often the domain manager analyzes events to find fault conditions. When the interval is increased, a domain manager looks for fault conditions less often and, as a result, generates notifications less frequently. This value does not affect how often the domain manager generates symptom event notifications, only how often it generates compound notifications.

•Codebook Radius determines the level of noise (delayed, lost, or spurious events) a domain manager can tolerate and still guarantee correct analysis results. A higher number means that the server tolerates more noise (lost or spurious events). This also results in more notifications with a low certainty as the domain manager accounts for every possible cause.

•Correlation Radius determines how exact a match must occur between symptoms known to be caused by a fault condition and the events the domain manager monitors. A domain manager uses the model and network topology to compute the symptoms each fault condition is expected to cause. These are termed a problem signature. When the events that the domain manager monitors match a problem signature within a tolerance defined by the radius, it determines that the corresponding fault condition occurred.

When the radius is too high, the domain manager considers problems whose signatures are quite different from the monitored events, though it will give them a low certainty. When the radius is too small, the problem signatures and monitored events must match so closely that a single lost event can disrupt accurate analysis.

•Number of Problems determines how many concurrent fault conditions a domain manager should consider possible when it analyzes events. It is not unusual for more than one fault condition to occur in a given interval. When one fault condition does not match the codebook, the domain manager checks to see if two fault conditions caused the symptoms. Increasing the number of fault conditions increases the amount of time it takes a domain manager to analyze because it multiplies the possible combinations of fault conditions that must be considered. The limitation on the number of concurrent fault conditions only applies to fault conditions with related symptoms. Sophisticated algorithms in the domain manager allow it to efficiently consider a large number of concurrent fault conditions whose symptoms are unrelated.

•Loss Symptom Probability is the likelihood that the domain manager will not receive notice of a symptom that actually occurred.

•Spurious Symptom Probability is the likelihood that the domain manager will falsely receive notice that a symptom has occurred when it actually has not.

DFM and CiscoWorks2000 Processes

The following table provides a complete list of DFM-related CiscoWorks2000 processes.

---

Note You cannot stop or unregister the DfmServer process if any process that depends on it is running. You must first stop or unregister all dependent processes, and then stop or unregister the DfmServer process.

---

Table 11-2 DFM-Related CiscoWorks2000 Processes 

Name	Description	Dependency
DfmBroker	The DFM Broker maintains a registry about the DFM domain manager. The domain manager registers the following information with the broker when its initialization is complete: •Application name of the domain manager •Hostname where the domain manager is running •TCP port at which the HTTP server is listening When a client needs to connect to the domain manager, it first connects to the broker to determine the hostname and TCP port where that server's HTTP service is listening. It then disconnects from the broker and establishes a connection to the domain manager.	None
DfmServer	DFM domain manager, a DFM program that provides backend services for DFM. Services include SNMP data retrieval and event analysis (SNMP Trap Adapter). The DfmServer log is NMSROOT/objects/smarts/logs/DFM.log.	DfmBroker
DfmFileNotifier	Logs DFM analysis results into ASCII files (File Notifier Adapter).	DfmServer
DfmTrapNotifier	Converts DFM notifications into SNMP traps (Trap Notifier Adapter).	DfmServer
DfmMailNotifier	Monitors user-specified alarms and events and automatically emails notifications to specified recipients (Mail Notifier Adapter).	DfmServer
DfmChangeProbe	Monitors messages from Essentials processes and forwards inventory changes to the DFM domain manager (RME Adapter).	EssentialsDbEngine, EssentialsDbMonitor

To stop (or start) a CiscoWorks2000 process:

---

Step 1 Log on to CiscoWorks2000 as an administrator.

Step 2 Select Server Configuration > Administration > Process Management > Stop Process. The Stop Process window opens.

---

Note If a process is not listed, it has not yet been started.

---

Step 3 In the Stop Process window, locate the process you want to stop in the Process drop-down list.

---

Note The DFM installation procedure sets DfmServer to start automatically, so it is normally listed. When you stop the DfmServer process, any users attached to DFM will be detached. Use the Attach button to re-attach after the DfmServer process is restarted.

---

Step 4 Select the process you want to stop and click the Finish button.

Step 5 To restart the process, select Server Configuration > Administration > Process Management > Start Process. The Start Process window opens.

Step 6 In the Start Process window, locate the process you want to start in the Process drop-down list.

Step 7 Select the process you want to start and click the Finish button.

---