Installation and Setup Guide for Device Fault Manager 1.2 and 1.2 Updated for Common Services Version 2.2 on Solaris (With LMS 2.2) - Getting Started [CiscoWorks Device Fault Manager]

Table Of Contents

Getting Started

Enabling Devices to Send Traps to DFM

Enabling DFM to Send Traps to NMSs

Configuring the SNMP Trap Adapter

Using the GUI to Configure the SNMP Trap Adapter to Receive Traps

Using the GUI to Configure the SNMP Trap Adapter to Forward Traps

Integrating the SNMP Trap Adapter with Other Trap Daemons

Scenario One

Scenario Two

Scenario Three

Scenario Four

Scenario Five

Preparing a Seed File

Format of a Seed File

How To Determine What to Put in a Seed File

Choosing a Router Address for the Seed File: Special Considerations

Accessing Device Fault Manager

Importing Devices from a Seed File

Changing the Default Read Community String

Opening the DFM Administration Console

Opening the DFM Polling and Thresholds Console

Checking Default Settings

Accessing the Device Inventory

Probing the DFM Inventory

Synchronizing the DFM Inventory with the Essentials Inventory

Rediscovering Devices in the Entire DFM Inventory

Opening the DFM Monitoring Console

Closing the DFM Monitoring Console

Getting Started

This section provides a minimum number of steps for setting up DFM and viewing diagnostic results. It is intended to help you to start using DFM immediately.

Note Within DFM are three consoles: the Monitoring Console, the Administration Console, and the Polling and Thresholds Console. The consoles are described in detail in the User Guide for Device Fault Manager (available from online help).

To start using DFM, you will want to perform most of the steps in these sections:

•Enabling Devices to Send Traps to DFM

•Enabling DFM to Send Traps to NMSs

•Preparing a Seed File

•Accessing Device Fault Manager

•Importing Devices from a Seed File

•Opening the DFM Administration Console

•Opening the DFM Polling and Thresholds Console

•Checking Default Settings

•Accessing the Device Inventory

•Probing the DFM Inventory

•Opening the DFM Monitoring Console

•Closing the DFM Monitoring Console

Enabling Devices to Send Traps to DFM

Make sure your devices are enabled to send traps to DFM by using the command line or GUI interface appropriate for your device. For example, if you are using Essentials, you can use the NetConfig application to do this.

•For information on enabling traps on IOS-based devices, use the
snmp-server enable traps command. Refer to the appropriate command reference guide on Cisco.com:

http://www.cisco.com/univercd/cc/td/doc/product/software/index.htm

•For information on enabling traps on Catalyst devices (which use the Catalyst operating system), use the set snmp trap command. Refer to the appropriate command reference guide on Cisco.com:

http://www.cisco.com/univercd/cc/td/doc/product/lan/index.htm

Enabling DFM to Send Traps to NMSs

If you want DFM to integrate with other NMSs, you must enable trap forwarding in DFM by performing the tasks outlined in these sections:

1. Configuring the SNMP Trap Adapter

2. Integrating the SNMP Trap Adapter with Other Trap Daemons

For more information on configuring adapters, refer to the User Guide for Device Fault Manager (available from online help).

Configuring the SNMP Trap Adapter

The SNMP Trap Adapter listens for traps (from managed devices) on a user-specified port and forwards the traps to specified destinations, providing a generic method for integrating with other NMS applications. If another NMS is already listening for traps on the standard UDP trap port (162), you must configure this adapter to use another port, such as port 9000.

You can use the DFM administration menus to configure the SNMP Trap Adapter to both receive and forward SNMP traps.

Using the GUI to Configure the SNMP Trap Adapter to Receive Traps

To configure which port will be monitored for SNMP traps DFM receives from other NMSs:

Step 1 Make sure the devices and/or NMSs that are forwarding traps to DFM are configured to send them to the port defined in the adapter configuration file. When the process is unregistered, you will no longer see it using
Server Configuration > Administration > Process Management.

If another NMS is already listening for traps on the standard UDP trap port (162), you must configure this adapter to use another port, such as port 9000.

Step 2 Select Device Fault Manager > Administration > Trap Configuration > Trap Receiving.

Step 3 In the Listening Port field, enter the port number of the local host where the DFM server is running.

Step 4 Select the Restart DFM Server check box if you want to restart the server when you click OK. (You must restart the DFM server for your changes to take effect.)

Step 5 Click OK.

This procedure does the following:

•Enables/disables the process and registers/unregisters the process with CiscoWorks.

•Updates the SNMP Trap Adapter configuration file NMSROOT/objects/smarts/conf/trapd/trapd.conf.

•Updates the SNMP Trap Adapter log information in the DFM domain manager log file NMSROOT/objects/smarts/conf/trapd/trapd.conf.

If you did not select the Restart DFM Server check box, you must do so manually to apply your changes. Use Server Configuration > Administration > Process Management. To further configure the adapter—for example, to specify how nonprintable characters are formatted—use the command line as described in the User Guide for Device Fault Manager (available from online help).

You may also need to complete one or more of the following steps:

•If your network devices are already sending traps to another management application, configure that application to forward traps to DFM.

•If your devices are already configured to send traps to port 162, and no other management application is using port 162, then you can configure DFM to listen on port 162 instead of port 9000.

•If your network devices are already sending traps to another NMS, but that NMS cannot forward traps, you should:

–Configure the devices to send traps to DFM.

–Configure DFM to forward the traps to the other NMS.

Using the GUI to Configure the SNMP Trap Adapter to Forward Traps

To have DFM send received traps to other NMSs:

Step 1 Select Device Fault Manager > Administration > Trap Configuration > Trap Forwarding.

Step 2 In the Forwarding field, select ON or OFF to enable or disable trap forwarding.

Step 3 If you want to add a recipient, in the Add Recipient field, enter the hostname and port number of the machine you want to forward traps to.

Step 4 If you want to remove a recipient, select the recipient from the Remove Recipient field.

Step 5 Click OK.

Step 6 If you want to add or remove any other recipients, repeat the appropriate steps and click OK. Repeat these steps until you have added or removed all recipients.

Step 7 Select the Restart DFM Server check box if you want to restart the server when you click OK. (You must restart the DFM server for your changes to take effect.)

This procedure does the following:

•Enables/disables the process and registers/unregisters the process with CiscoWorks. When the process is unregistered, you will no longer see it using Server Configuration > Administration > Process Management.

•Updates the SNMP Trap Adapter configuration file NMSROOT/objects/smarts/conf/trapd/trapd.conf.

•Updates the SNMP Trap Adapter log information in the DFM domain manager log file NMSROOT/objects/smarts/conf/trapd/trapd.conf

If you did not select the Restart DFM Server check box, you must do so manually to apply your changes. Use Server Configuration > Administration > Process Management. To further configure the adapter—for example, to specify how nonprintable characters will be formatted—use the command line as described in the User Guide for Device Fault Manager (available from online help).

Integrating the SNMP Trap Adapter with Other Trap Daemons

The SNMP Trap Adapter can receive traps on any port and forward them to a list of devices and ports. This flexibility enables it to easily work with other trap processing applications. The following sections describe possible scenarios for integrating the SNMP Trap Adapter with an existing network management system (NMS) platform.

You may need to complete one or more of the following steps to configure the Trap Notifier Adapter:

•Add the host where DFM is running to the list of trap destinations in your network devices. Specify port 9000 as the destination trap port.

•If your network devices are already sending traps to another management application, configure that application to forward traps to DFM.

•If your devices are already configured to send traps to port 162, and no other management application is using port 162, then you can configure DFM to listen on port 162 instead of port 9000.

Scenario One

DFM and another NMS are installed on the same host. DFM can be configured to listen for traps on default port 162 and forward them to the NMS, which listens on a nonstandard port, such as port 9000.

The advantages of this approach:

•SNMP Trap Adapter provides a reliable trap reception, storage, and forwarding mechanism.

•Devices do not need to be reconfigured to send traps to another host or port.

•DFM and the NMS run on the same host.

Scenario Two

DFM and the NMS run on separate hosts. Network devices send traps to port 162 of the host where DFM is running. DFM receives the traps and forwards them to the NMS.

The advantages of this approach:

•SNMP Trap Adapter provides a reliable trap reception, storage, and forwarding mechanism.

•NMS continues to receive traps on port 162.

•Network devices continue to send traps to port 162.

Scenario Three

DFM and the NMS are installed on the same host. The SNMP Trap Adapter listens for traps on port 9000 and forwards them to the NMS on port 162.

The advantages of this approach:

•SNMP Trap Adapter provides a reliable trap reception, storage, and forwarding mechanism.

•No reconfiguration of the NMS is required; it continues to listen for traps on default port 162.

•DFM and the NMS run on the same host.

Scenario Four

DFM and the NMS run on the same host. The NMS receives traps on port 162 and forwards them to the SNMP Trap Adapter, which listens for traps on a nonstandard port such as port 9000.

The advantages of this approach:

•No reconfiguration of the NMS is required.

•No reconfiguration of network devices is required.

•DFM and the NMS run on the same host.

•The SNMP Trap Adapter does not receive traps dropped by the NMS.

Scenario Five

DFM and the NMS run on separate hosts. The NMS receives traps on the default port of 162 and forwards them to port 162 on the host where DFM is running.

The advantages of this approach:

•No reconfiguration of the NMS is required.

•No reconfiguration of network devices is required.

•The SNMP Trap Adapter does not receive traps dropped by the NMS.

Preparing a Seed File

When DFM is installed as a standalone product, the device inventory of the network must be imported into DFM from a text file called a seed file. The file can be created with any text editor. Subsequent updates to groups of managed devices can also be performed by way of a seed file. Individual devices can be added using File > Add Agent in the Administration Console.

A seed file lists top-level network devices such as hosts, routers, switches, and hubs. After the seed file is imported into DFM, DFM automatically discovers the internal structure of the devices. For example, you need only provide the name or IP address of one interface in a router; DFM discovers the rest of the interfaces. In the case of a switch, you need only provide the name or IP address of the switch's SNMP agent. DFM automatically determines the switch's configuration and how it connects to other devices listed in the DFM inventory.

The seed file must be stored on the host on which the domain manager runs. It is recommended that you store it under its default path name, NMSROOT/objects/smarts/conf/seedfile.

Format of a Seed File

A seed file consists of lines with one or two columns. Separate the columns with any combination of spaces and tab characters. The first column names the network device. You can specify either a name or an IP address. You can intermix the two formats freely within a single seed file.

The second column defines the read community string. It is meaningful only if an SNMP agent is accessible at the default SNMP port (UDP port 161) at the name or address given in the first column. If you omit this column, DFM uses a default value; the initial default value is public. If many of your devices use a single alternative read community string, you can change DFM's default (see the "Changing the Default Read Community String" section for additional information). To make your seed file more readable, you can include blank and comment lines. A comment line is one that begins with a # sign.

The following offers a brief example of a seed file:
# Sample seed file
192.168.1.200
access-router-1 private
192.168.2.100 public
host1.example.com.
The default read community string (public, unless changed) is used for the devices at IP address 192.168.1.200 and at name host1.example.com, because an alternate string is not specified. The read community string for access-router-1 is private, and the read community string for 192.168.2.100 is public, regardless of the default community string.

How To Determine What to Put in a Seed File

The seed file must list all of the network devices that DFM is to manage. Creating the seed file can be a substantial task if it is done manually. However, the necessary information is usually available from existing computer-accessible sources. This section lists a variety of sources where this information might be found:

•If you are using CiscoWorks with Essentials on another host but do not want to use it to perform automatic updates, you can dump the hardware inventory to a text file. That text file can be converted into a seed file. Similar operations may be possible with other NMSs.

•If you are using HP OpenView or NetView, you can obtain this information from the ovsnmp.conf or nvsnmp.conf files. This configuration file is maintained by the xnmsnmpconf configuration utility. By default, for example, the ovsnmp.conf is located in /usr/OV/conf.

•If you store backup router or switch configuration files at a central location, you can construct a seed file from them.

•Domain name resolution files, such as hosts.txt or zone files, are often a useful source. Note that, at sites with multiple administrative authorities who choose different read community strings, the hosts listed in a given zone file often share an administrative authority and hence a read community string.

TACACS configuration files may be useful for similar reasons.

•Large sites usually maintain hardware inventories in a database or at least in some computer-readable form. These inventories often contain the necessary information.

•Some sites run network sniffer tools to keep track of active IP addresses. The lists of addresses they generate can form the basis for a seed file.

Choosing a Router Address for the Seed File: Special Considerations

As noted earlier, only a single name or IP address is necessary for a router. However, if a router is configured to allow SNMP access only on select interfaces, at least one of those interfaces must be listed in the seed file. While only one name or IP address is needed for a given network device, more than one can be listed. DFM automatically determines that the names or addresses actually belong to a single device. In complex network configurations, this capability enables DFM to reach the device using an alternate address if the primary address is inaccessible (due to a failure) during DFM's initial probe of the device. (Once DFM has probed the device successfully, it knows all its IP addresses, and will automatically try them all to route around failures and reach the device.)

Accessing Device Fault Manager

To access DFM, select one of the following:

•Device Fault Manager > Monitoring Console to open the DFM Monitoring Console and check DFM polling and analysis results. For more information, refer to the User Guide for Device Fault Manager (available from online help).

•Device Fault Manager > Administration > Administration Console to open the Administration Console. For more information, refer to the "Opening the DFM Administration Console" section.

•From the Administration Console, select Edit > Polling and Thresholds to open the Polling and Thresholds Console to browse and fine tune the device inventory of your network. For more information, refer to the "Opening the DFM Polling and Thresholds Console" section.

Importing Devices from a Seed File

When DFM is installed as a standalone product, a seed file—or a list of managed devices—must be imported into DFM to initiate inventory discovery.

To import a seed file:

Step 1 Select Device Fault Manager > Administration > Administration Console to open the Administration Console.

Step 2 Select Inventory > Import From Seed File or click on the Import From Seed File toolbar button. The Import From Seed File dialog box appears.

Step 3 Specify the complete path and the name of the seed file, and click OK. The Discovery Progress dialog box appears.

Note The seed file must be stored on the host where the domain manager runs.

When DFM imports devices from the seed file, it probes them to discover their configuration and adds their manageable elements to its inventory. For a large number of elements, this process may take several minutes.

Changing the Default Read Community String

DFM uses public as its default read community string to access the SNMP agents of managed devices. You can change the default read community string if the read community string for SNMP agents in your network is different.

Step 1 Click the domain manager icon.

Step 2 Select the Inventory tab in the right panel of the Administration Console.

Step 3 Specify a different read community string in the Default Read Community String field.

Step 4 Click Apply to make the new string take effect.

Opening the DFM Administration Console

To open the Monitoring Console, select Device Fault Manager >
Administration > Administration Console.

The Administration Console displays an inventory tree that lists system classes and VLANs. Systems include devices such as switches, hubs, bridges, routers, router switch modules, probes, and hosts.

When an instance (managed element) of a class is selected in the left panel, DFM displays the properties of the instance under three tabs:

•Attributes lists the attributes and their values for the selected instance.

Note If a line appears in place of an attribute value, the value is derived by polling an external device that is currently unavailable to the domain manager.

•Events lists the events that can occur in or affect the instance. Active events are colored according to their type. Double-clicking an event displays the Notification Properties dialog box for the event. For more information regarding the Notification Properties dialog box, see the User Guide for Device Fault Manager (available from the online help).

•Group lists the Polling and Threshold groups the instance is a member of and the settings from those groups that apply to the instance.

Opening the DFM Polling and Thresholds Console

From the Administration Console, select Edit > Polling and Thresholds to open the Polling and Thresholds Console.

The Polling and Thresholds Console enables you to display the settings and configurations of the managed devices. It also enables you to display the current device inventory.

Settings are the polling parameters and notification thresholds that are applied to the managed devices of the network. Configuration groups, in turn, are collections of settings that are applied to specified groups of managed devices (hosts and routers, for example).

Step 1 Click the domain icon that is displayed in the left-hand panel of the window to display the configuration groups of the domain.

Step 2 Select and click on a configuration group to display the settings of that group. At this point, you can also display the description, priorities, and matching criteria for the group.

Step 3 Review the default information for the domain group.

For additional information on the Polling and Thresholds Console, see the User Guide for Device Fault Manager (available from online help).

Checking Default Settings

When it is installed, DFM includes default values for all of the configurations and settings used by the application. The default values can be modified to meet the requirements of your environment. For additional information about modifying the configurations and settings, see the User Guide for Device Fault Manager (available from online help).

Accessing the Device Inventory

To access the device inventory of your network, click the domain manager icon displayed in the left panel of the Administration Console to expand the inventory tree.

This inventory tree view enables you to traverse the device inventory that DFM imported from the Essentials database. The view displays the domain manager, its classes, a selected managed element (instance), and that element's relationship to other elements.

For each object you select in the inventory view, a corresponding property sheet appears. The property sheet displays the current value of the element's attributes, its events (highlighting the active ones), and its configuration settings.

In the inventory view:

•Click the plus sign to expand individual objects.

•Click the plus sign next to the domain manager to view the classes (types) of elements it manages.

•Click the plus sign next to a class to view its instances.

•Click an instance to view its properties.

•Click the plus sign next to an instance to view its relations.

•Click the plus sign next to a relation to view the classes of the related objects.

•Click the plus sign next to each class to view the actual related instances.

•Double-click an instance to create a new, separate window that displays an inventory browser starting with the selected object.

For more information on viewing analysis results and other operator tasks, see the User Guide for Device Fault Manager (available from online help).

Probing the DFM Inventory

After Device Fault Manager is installed, the DFM inventory is regularly probed. These topics provide information on how this is done:

•Synchronizing the DFM Inventory with the Essentials Inventory

•Rediscovering Devices in the Entire DFM Inventory

Synchronizing the DFM Inventory with the Essentials Inventory

When Essentials is installed, DFM (specifically, the DfmChangeProbe process) automatically queries the Essentials database, and sends device information to the DFM repository. DFM then probes the devices to analyze their properties and status.

During normal operation, the DfmChangeProbe process monitors messages that are broadcast by the Essentials inventory collector, and forwards inventory additions and updates to the DFM repository.

To check the status of the DfmChangeProbe process, when necessary, select Server Configuration > Administration > Process Management > Process Status.

To disable (or enable) the DfmChangeProbe process, select Device Fault Manager > Administration > Device Discovery > ChangeProbe. For more information, see the User Guide for Device Fault Manager (available from online help).

Note If you delete a device from the DFM inventory, the device is not deleted from the Essentials database. Therefore, when the DfmChangeProbe process again performs a query of the full Essentials database (after a restart of the system, for example), the deleted device will again be added to the DFM repository.

Rediscovering Devices in the Entire DFM Inventory

In addition to the initial inventory probe, DFM includes a scheduled probe of the entire inventory. The scheduled probe is a batch process that is controlled by CiscoWorks. By default, the probe of the entire inventory is scheduled to run once a week, on Saturday night or Sunday morning. After the probe of the entire inventory, the DFM inventory is also synchronized with the Essentials inventory, and DFM is directed to rediscover the managed devices.

To check the status of a scheduled probe of the inventory, when necessary, select Server Configuration > Administration > Job Management.

To change the date, time, and duration of inventory collection, use the Rediscovery Schedule option:

Step 1 Select Administration > Device Discovery > Rediscovery Schedule.

Step 2 Enter the desired start date, time, and frequency, and click OK.

If the Rediscovery Schedule job is stopped by the CiscoWorks Job Manager, you must remove the job and then schedule discovery again.

To remove the job:

Step 1 Select CiscoWorks Server > Administration > Job Management.

Step 2 Select the job and click Remove Job.

For more information on rediscovering devices in the DFM inventory, refer to the User Guide for Device Fault Manager (available from online help).

Opening the DFM Monitoring Console

To open the Monitoring Console, select Device Fault Manager > Monitoring Console.

The Monitoring Console displays the results of DFM's polling and analysis of the managed devices. The Console automatically receives and displays notifications in the Alarm Log view.

Note When you open a Monitoring Console using the CiscoWorks navigation tree, by default the Monitoring Console does not display the Inventory Browser. If you want to open a Monitoring Console that displays the Inventory Browser, either
(1) open a Monitoring Console using the Administration Console's toolbar button, or (2) open a Monitoring Console from any running console in a session using File > New > Monitoring Console.

As exceptional conditions occur across the network, notifications begin to appear in the Alarm Log view of the Monitoring Console. In the Alarm Log view, information presented for the notifications includes class (or type) of managed element, name of managed element, name of notified event, certainty of diagnosis, number of times the event occurred, last change (of state), first notification (the time the event was first detected), and the name of the domain manager.

To view possible causes or events used in the analysis, double-click the notification in the Alarm Log. This displays the Notification Properties window.

The Notification Properties window displays the selected event notification, the name of the device associated with the notification, the general properties of that device, and any associated component notifications. Thus, it provides you with the information that you need to resolve the problem.

For additional information about the Monitoring Console, see the User Guide for Device Fault Manager (available from online help).

Closing the DFM Monitoring Console

Three methods exist to close the Monitoring Console (none of the methods affect the domain manager):

•Select File > Close.

The Close command closes an individual Console and the session continues. When you close the last Monitoring Console, you end the DFM session.

•Select File > Exit.

The Exit command closes all consoles that are part of the session, and the session ends.

•Close your Web browser.

Note When you log out of CiscoWorks, the Monitoring Console remains displayed for continuous viewing. To close the Console, you must explicitly close it or the Web browser.

	Installation and Setup Guide for Device Fault Manager 1.2 and 1.2 Updated for Common Services Version 2.2 on Solaris (With LMS 2.2)
	Getting Started
Installation and Setup Guide for Device Fault Manager 1.2 and 1.2 Updated for Common Services Version 2.2 on Solaris (With LMS 2.2) Index Preface Prerequisites Installing Device Fault Manager Mounting and Unmounting on Solaris Getting Started	Download this chapter Getting Started Download the complete book Installation and Setup Guide for Device Fault Manager on Solaris (PDF - 1 MB) Table Of Contents Getting Started Enabling Devices to Send Traps to DFM Enabling DFM to Send Traps to NMSs Configuring the SNMP Trap Adapter Using the GUI to Configure the SNMP Trap Adapter to Receive Traps Using the GUI to Configure the SNMP Trap Adapter to Forward Traps Integrating the SNMP Trap Adapter with Other Trap Daemons Scenario One Scenario Two Scenario Three Scenario Four Scenario Five Preparing a Seed File Format of a Seed File How To Determine What to Put in a Seed File Choosing a Router Address for the Seed File: Special Considerations Accessing Device Fault Manager Importing Devices from a Seed File Changing the Default Read Community String Opening the DFM Administration Console Opening the DFM Polling and Thresholds Console Checking Default Settings Accessing the Device Inventory Probing the DFM Inventory Synchronizing the DFM Inventory with the Essentials Inventory Rediscovering Devices in the Entire DFM Inventory Opening the DFM Monitoring Console Closing the DFM Monitoring Console Getting Started This section provides a minimum number of steps for setting up DFM and viewing diagnostic results. It is intended to help you to start using DFM immediately. Note Within DFM are three consoles: the Monitoring Console, the Administration Console, and the Polling and Thresholds Console. The consoles are described in detail in the User Guide for Device Fault Manager (available from online help). To start using DFM, you will want to perform most of the steps in these sections: •Enabling Devices to Send Traps to DFM •Enabling DFM to Send Traps to NMSs •Preparing a Seed File •Accessing Device Fault Manager •Importing Devices from a Seed File •Opening the DFM Administration Console •Opening the DFM Polling and Thresholds Console •Checking Default Settings •Accessing the Device Inventory •Probing the DFM Inventory •Opening the DFM Monitoring Console •Closing the DFM Monitoring Console Enabling Devices to Send Traps to DFM Make sure your devices are enabled to send traps to DFM by using the command line or GUI interface appropriate for your device. For example, if you are using Essentials, you can use the NetConfig application to do this. •For information on enabling traps on IOS-based devices, use the snmp-server enable traps command. Refer to the appropriate command reference guide on Cisco.com: http://www.cisco.com/univercd/cc/td/doc/product/software/index.htm •For information on enabling traps on Catalyst devices (which use the Catalyst operating system), use the set snmp trap command. Refer to the appropriate command reference guide on Cisco.com: http://www.cisco.com/univercd/cc/td/doc/product/lan/index.htm Enabling DFM to Send Traps to NMSs If you want DFM to integrate with other NMSs, you must enable trap forwarding in DFM by performing the tasks outlined in these sections: 1. Configuring the SNMP Trap Adapter 2. Integrating the SNMP Trap Adapter with Other Trap Daemons For more information on configuring adapters, refer to the User Guide for Device Fault Manager (available from online help). Configuring the SNMP Trap Adapter The SNMP Trap Adapter listens for traps (from managed devices) on a user-specified port and forwards the traps to specified destinations, providing a generic method for integrating with other NMS applications. If another NMS is already listening for traps on the standard UDP trap port (162), you must configure this adapter to use another port, such as port 9000. You can use the DFM administration menus to configure the SNMP Trap Adapter to both receive and forward SNMP traps. Using the GUI to Configure the SNMP Trap Adapter to Receive Traps To configure which port will be monitored for SNMP traps DFM receives from other NMSs: Step 1 Make sure the devices and/or NMSs that are forwarding traps to DFM are configured to send them to the port defined in the adapter configuration file. When the process is unregistered, you will no longer see it using Server Configuration > Administration > Process Management. If another NMS is already listening for traps on the standard UDP trap port (162), you must configure this adapter to use another port, such as port 9000. Step 2 Select Device Fault Manager > Administration > Trap Configuration > Trap Receiving. Step 3 In the Listening Port field, enter the port number of the local host where the DFM server is running. Step 4 Select the Restart DFM Server check box if you want to restart the server when you click OK. (You must restart the DFM server for your changes to take effect.) Step 5 Click OK. This procedure does the following: •Enables/disables the process and registers/unregisters the process with CiscoWorks. •Updates the SNMP Trap Adapter configuration file NMSROOT/objects/smarts/conf/trapd/trapd.conf. •Updates the SNMP Trap Adapter log information in the DFM domain manager log file NMSROOT/objects/smarts/conf/trapd/trapd.conf. If you did not select the Restart DFM Server check box, you must do so manually to apply your changes. Use Server Configuration > Administration > Process Management. To further configure the adapter—for example, to specify how nonprintable characters are formatted—use the command line as described in the User Guide for Device Fault Manager (available from online help). You may also need to complete one or more of the following steps: •If your network devices are already sending traps to another management application, configure that application to forward traps to DFM. •If your devices are already configured to send traps to port 162, and no other management application is using port 162, then you can configure DFM to listen on port 162 instead of port 9000. •If your network devices are already sending traps to another NMS, but that NMS cannot forward traps, you should: –Configure the devices to send traps to DFM. –Configure DFM to forward the traps to the other NMS. Using the GUI to Configure the SNMP Trap Adapter to Forward Traps To have DFM send received traps to other NMSs: Step 1 Select Device Fault Manager > Administration > Trap Configuration > Trap Forwarding. Step 2 In the Forwarding field, select ON or OFF to enable or disable trap forwarding. Step 3 If you want to add a recipient, in the Add Recipient field, enter the hostname and port number of the machine you want to forward traps to. Step 4 If you want to remove a recipient, select the recipient from the Remove Recipient field. Step 5 Click OK. Step 6 If you want to add or remove any other recipients, repeat the appropriate steps and click OK. Repeat these steps until you have added or removed all recipients. Step 7 Select the Restart DFM Server check box if you want to restart the server when you click OK. (You must restart the DFM server for your changes to take effect.) This procedure does the following: •Enables/disables the process and registers/unregisters the process with CiscoWorks. When the process is unregistered, you will no longer see it using Server Configuration > Administration > Process Management. •Updates the SNMP Trap Adapter configuration file NMSROOT/objects/smarts/conf/trapd/trapd.conf. •Updates the SNMP Trap Adapter log information in the DFM domain manager log file NMSROOT/objects/smarts/conf/trapd/trapd.conf If you did not select the Restart DFM Server check box, you must do so manually to apply your changes. Use Server Configuration > Administration > Process Management. To further configure the adapter—for example, to specify how nonprintable characters will be formatted—use the command line as described in the User Guide for Device Fault Manager (available from online help). Integrating the SNMP Trap Adapter with Other Trap Daemons The SNMP Trap Adapter can receive traps on any port and forward them to a list of devices and ports. This flexibility enables it to easily work with other trap processing applications. The following sections describe possible scenarios for integrating the SNMP Trap Adapter with an existing network management system (NMS) platform. You may need to complete one or more of the following steps to configure the Trap Notifier Adapter: •Add the host where DFM is running to the list of trap destinations in your network devices. Specify port 9000 as the destination trap port. •If your network devices are already sending traps to another management application, configure that application to forward traps to DFM. •If your devices are already configured to send traps to port 162, and no other management application is using port 162, then you can configure DFM to listen on port 162 instead of port 9000. Scenario One DFM and another NMS are installed on the same host. DFM can be configured to listen for traps on default port 162 and forward them to the NMS, which listens on a nonstandard port, such as port 9000. The advantages of this approach: •SNMP Trap Adapter provides a reliable trap reception, storage, and forwarding mechanism. •Devices do not need to be reconfigured to send traps to another host or port. •DFM and the NMS run on the same host. Scenario Two DFM and the NMS run on separate hosts. Network devices send traps to port 162 of the host where DFM is running. DFM receives the traps and forwards them to the NMS. The advantages of this approach: •SNMP Trap Adapter provides a reliable trap reception, storage, and forwarding mechanism. •NMS continues to receive traps on port 162. •Network devices continue to send traps to port 162. Scenario Three DFM and the NMS are installed on the same host. The SNMP Trap Adapter listens for traps on port 9000 and forwards them to the NMS on port 162. The advantages of this approach: •SNMP Trap Adapter provides a reliable trap reception, storage, and forwarding mechanism. •No reconfiguration of the NMS is required; it continues to listen for traps on default port 162. •DFM and the NMS run on the same host. Scenario Four DFM and the NMS run on the same host. The NMS receives traps on port 162 and forwards them to the SNMP Trap Adapter, which listens for traps on a nonstandard port such as port 9000. The advantages of this approach: •No reconfiguration of the NMS is required. •No reconfiguration of network devices is required. •DFM and the NMS run on the same host. •The SNMP Trap Adapter does not receive traps dropped by the NMS. Scenario Five DFM and the NMS run on separate hosts. The NMS receives traps on the default port of 162 and forwards them to port 162 on the host where DFM is running. The advantages of this approach: •No reconfiguration of the NMS is required. •No reconfiguration of network devices is required. •The SNMP Trap Adapter does not receive traps dropped by the NMS. Preparing a Seed File When DFM is installed as a standalone product, the device inventory of the network must be imported into DFM from a text file called a seed file. The file can be created with any text editor. Subsequent updates to groups of managed devices can also be performed by way of a seed file. Individual devices can be added using File > Add Agent in the Administration Console. A seed file lists top-level network devices such as hosts, routers, switches, and hubs. After the seed file is imported into DFM, DFM automatically discovers the internal structure of the devices. For example, you need only provide the name or IP address of one interface in a router; DFM discovers the rest of the interfaces. In the case of a switch, you need only provide the name or IP address of the switch's SNMP agent. DFM automatically determines the switch's configuration and how it connects to other devices listed in the DFM inventory. The seed file must be stored on the host on which the domain manager runs. It is recommended that you store it under its default path name, NMSROOT/objects/smarts/conf/seedfile. Format of a Seed File A seed file consists of lines with one or two columns. Separate the columns with any combination of spaces and tab characters. The first column names the network device. You can specify either a name or an IP address. You can intermix the two formats freely within a single seed file. The second column defines the read community string. It is meaningful only if an SNMP agent is accessible at the default SNMP port (UDP port 161) at the name or address given in the first column. If you omit this column, DFM uses a default value; the initial default value is public. If many of your devices use a single alternative read community string, you can change DFM's default (see the "Changing the Default Read Community String" section for additional information). To make your seed file more readable, you can include blank and comment lines. A comment line is one that begins with a # sign. The following offers a brief example of a seed file: # Sample seed file 192.168.1.200 access-router-1 private 192.168.2.100 public host1.example.com. The default read community string (public, unless changed) is used for the devices at IP address 192.168.1.200 and at name host1.example.com, because an alternate string is not specified. The read community string for access-router-1 is private, and the read community string for 192.168.2.100 is public, regardless of the default community string. How To Determine What to Put in a Seed File The seed file must list all of the network devices that DFM is to manage. Creating the seed file can be a substantial task if it is done manually. However, the necessary information is usually available from existing computer-accessible sources. This section lists a variety of sources where this information might be found: •If you are using CiscoWorks with Essentials on another host but do not want to use it to perform automatic updates, you can dump the hardware inventory to a text file. That text file can be converted into a seed file. Similar operations may be possible with other NMSs. •If you are using HP OpenView or NetView, you can obtain this information from the ovsnmp.conf or nvsnmp.conf files. This configuration file is maintained by the xnmsnmpconf configuration utility. By default, for example, the ovsnmp.conf is located in /usr/OV/conf. •If you store backup router or switch configuration files at a central location, you can construct a seed file from them. •Domain name resolution files, such as hosts.txt or zone files, are often a useful source. Note that, at sites with multiple administrative authorities who choose different read community strings, the hosts listed in a given zone file often share an administrative authority and hence a read community string. TACACS configuration files may be useful for similar reasons. •Large sites usually maintain hardware inventories in a database or at least in some computer-readable form. These inventories often contain the necessary information. •Some sites run network sniffer tools to keep track of active IP addresses. The lists of addresses they generate can form the basis for a seed file. Choosing a Router Address for the Seed File: Special Considerations As noted earlier, only a single name or IP address is necessary for a router. However, if a router is configured to allow SNMP access only on select interfaces, at least one of those interfaces must be listed in the seed file. While only one name or IP address is needed for a given network device, more than one can be listed. DFM automatically determines that the names or addresses actually belong to a single device. In complex network configurations, this capability enables DFM to reach the device using an alternate address if the primary address is inaccessible (due to a failure) during DFM's initial probe of the device. (Once DFM has probed the device successfully, it knows all its IP addresses, and will automatically try them all to route around failures and reach the device.) Accessing Device Fault Manager To access DFM, select one of the following: •Device Fault Manager > Monitoring Console to open the DFM Monitoring Console and check DFM polling and analysis results. For more information, refer to the User Guide for Device Fault Manager (available from online help). •Device Fault Manager > Administration > Administration Console to open the Administration Console. For more information, refer to the "Opening the DFM Administration Console" section. •From the Administration Console, select Edit > Polling and Thresholds to open the Polling and Thresholds Console to browse and fine tune the device inventory of your network. For more information, refer to the "Opening the DFM Polling and Thresholds Console" section. Importing Devices from a Seed File When DFM is installed as a standalone product, a seed file—or a list of managed devices—must be imported into DFM to initiate inventory discovery. To import a seed file: Step 1 Select Device Fault Manager > Administration > Administration Console to open the Administration Console. Step 2 Select Inventory > Import From Seed File or click on the Import From Seed File toolbar button. The Import From Seed File dialog box appears. Step 3 Specify the complete path and the name of the seed file, and click OK. The Discovery Progress dialog box appears. Note The seed file must be stored on the host where the domain manager runs. When DFM imports devices from the seed file, it probes them to discover their configuration and adds their manageable elements to its inventory. For a large number of elements, this process may take several minutes. Changing the Default Read Community String DFM uses public as its default read community string to access the SNMP agents of managed devices. You can change the default read community string if the read community string for SNMP agents in your network is different. Step 1 Click the domain manager icon. Step 2 Select the Inventory tab in the right panel of the Administration Console. Step 3 Specify a different read community string in the Default Read Community String field. Step 4 Click Apply to make the new string take effect. Opening the DFM Administration Console To open the Monitoring Console, select Device Fault Manager > Administration > Administration Console. The Administration Console displays an inventory tree that lists system classes and VLANs. Systems include devices such as switches, hubs, bridges, routers, router switch modules, probes, and hosts. When an instance (managed element) of a class is selected in the left panel, DFM displays the properties of the instance under three tabs: •Attributes lists the attributes and their values for the selected instance. Note If a line appears in place of an attribute value, the value is derived by polling an external device that is currently unavailable to the domain manager. •Events lists the events that can occur in or affect the instance. Active events are colored according to their type. Double-clicking an event displays the Notification Properties dialog box for the event. For more information regarding the Notification Properties dialog box, see the User Guide for Device Fault Manager (available from the online help). •Group lists the Polling and Threshold groups the instance is a member of and the settings from those groups that apply to the instance. Opening the DFM Polling and Thresholds Console From the Administration Console, select Edit > Polling and Thresholds to open the Polling and Thresholds Console. The Polling and Thresholds Console enables you to display the settings and configurations of the managed devices. It also enables you to display the current device inventory. Settings are the polling parameters and notification thresholds that are applied to the managed devices of the network. Configuration groups, in turn, are collections of settings that are applied to specified groups of managed devices (hosts and routers, for example). Step 1 Click the domain icon that is displayed in the left-hand panel of the window to display the configuration groups of the domain. Step 2 Select and click on a configuration group to display the settings of that group. At this point, you can also display the description, priorities, and matching criteria for the group. Step 3 Review the default information for the domain group. For additional information on the Polling and Thresholds Console, see the User Guide for Device Fault Manager (available from online help). Checking Default Settings When it is installed, DFM includes default values for all of the configurations and settings used by the application. The default values can be modified to meet the requirements of your environment. For additional information about modifying the configurations and settings, see the User Guide for Device Fault Manager (available from online help). Accessing the Device Inventory To access the device inventory of your network, click the domain manager icon displayed in the left panel of the Administration Console to expand the inventory tree. This inventory tree view enables you to traverse the device inventory that DFM imported from the Essentials database. The view displays the domain manager, its classes, a selected managed element (instance), and that element's relationship to other elements. For each object you select in the inventory view, a corresponding property sheet appears. The property sheet displays the current value of the element's attributes, its events (highlighting the active ones), and its configuration settings. In the inventory view: •Click the plus sign to expand individual objects. •Click the plus sign next to the domain manager to view the classes (types) of elements it manages. •Click the plus sign next to a class to view its instances. •Click an instance to view its properties. •Click the plus sign next to an instance to view its relations. •Click the plus sign next to a relation to view the classes of the related objects. •Click the plus sign next to each class to view the actual related instances. •Double-click an instance to create a new, separate window that displays an inventory browser starting with the selected object. For more information on viewing analysis results and other operator tasks, see the User Guide for Device Fault Manager (available from online help). Probing the DFM Inventory After Device Fault Manager is installed, the DFM inventory is regularly probed. These topics provide information on how this is done: •Synchronizing the DFM Inventory with the Essentials Inventory •Rediscovering Devices in the Entire DFM Inventory Synchronizing the DFM Inventory with the Essentials Inventory When Essentials is installed, DFM (specifically, the DfmChangeProbe process) automatically queries the Essentials database, and sends device information to the DFM repository. DFM then probes the devices to analyze their properties and status. During normal operation, the DfmChangeProbe process monitors messages that are broadcast by the Essentials inventory collector, and forwards inventory additions and updates to the DFM repository. To check the status of the DfmChangeProbe process, when necessary, select Server Configuration > Administration > Process Management > Process Status. To disable (or enable) the DfmChangeProbe process, select Device Fault Manager > Administration > Device Discovery > ChangeProbe. For more information, see the User Guide for Device Fault Manager (available from online help). Note If you delete a device from the DFM inventory, the device is not deleted from the Essentials database. Therefore, when the DfmChangeProbe process again performs a query of the full Essentials database (after a restart of the system, for example), the deleted device will again be added to the DFM repository. Rediscovering Devices in the Entire DFM Inventory In addition to the initial inventory probe, DFM includes a scheduled probe of the entire inventory. The scheduled probe is a batch process that is controlled by CiscoWorks. By default, the probe of the entire inventory is scheduled to run once a week, on Saturday night or Sunday morning. After the probe of the entire inventory, the DFM inventory is also synchronized with the Essentials inventory, and DFM is directed to rediscover the managed devices. To check the status of a scheduled probe of the inventory, when necessary, select Server Configuration > Administration > Job Management. To change the date, time, and duration of inventory collection, use the Rediscovery Schedule option: Step 1 Select Administration > Device Discovery > Rediscovery Schedule. Step 2 Enter the desired start date, time, and frequency, and click OK. If the Rediscovery Schedule job is stopped by the CiscoWorks Job Manager, you must remove the job and then schedule discovery again. To remove the job: Step 1 Select CiscoWorks Server > Administration > Job Management. Step 2 Select the job and click Remove Job. For more information on rediscovering devices in the DFM inventory, refer to the User Guide for Device Fault Manager (available from online help). Opening the DFM Monitoring Console To open the Monitoring Console, select Device Fault Manager > Monitoring Console. The Monitoring Console displays the results of DFM's polling and analysis of the managed devices. The Console automatically receives and displays notifications in the Alarm Log view. Note When you open a Monitoring Console using the CiscoWorks navigation tree, by default the Monitoring Console does not display the Inventory Browser. If you want to open a Monitoring Console that displays the Inventory Browser, either (1) open a Monitoring Console using the Administration Console's toolbar button, or (2) open a Monitoring Console from any running console in a session using File > New > Monitoring Console. As exceptional conditions occur across the network, notifications begin to appear in the Alarm Log view of the Monitoring Console. In the Alarm Log view, information presented for the notifications includes class (or type) of managed element, name of managed element, name of notified event, certainty of diagnosis, number of times the event occurred, last change (of state), first notification (the time the event was first detected), and the name of the domain manager. To view possible causes or events used in the analysis, double-click the notification in the Alarm Log. This displays the Notification Properties window. The Notification Properties window displays the selected event notification, the name of the device associated with the notification, the general properties of that device, and any associated component notifications. Thus, it provides you with the information that you need to resolve the problem. For additional information about the Monitoring Console, see the User Guide for Device Fault Manager (available from online help). Closing the DFM Monitoring Console Three methods exist to close the Monitoring Console (none of the methods affect the domain manager): •Select File > Close. The Close command closes an individual Console and the session continues. When you close the last Monitoring Console, you end the DFM session. •Select File > Exit. The Exit command closes all consoles that are part of the session, and the session ends. •Close your Web browser. Note When you log out of CiscoWorks, the Monitoring Console remains displayed for continuous viewing. To close the Console, you must explicitly close it or the Web browser.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks