Table Of Contents
How VHM Integrates with Third-Party NMSs
Locating the Supported Device List
How VHM Works with the CiscoWorks2000 Server
Voice Health Monitor Overview
These topics provide an overview of the VHM application:
•
How VHM Integrates with Third-Party NMSs
•
•
•
Overview of VHM
VHM helps network administrators and network operators determine and maintain the stability of the VoIP network within their enterprise. VHM achieves this goal by using:
•
•
VHM integrates with network management systems (NMSs) such as HP OpenView Network Node Manager.
With VHM, you can:
•
•
•
•
•
How VHM Works
VHM manages the voice-specific devices in the network by polling information from managed devices, as well as processing SNMP Traps generated by the devices. VHM relies on DFM to receive the SNMP Traps. VHM does not duplicate queries for information collection, but shares the information collected by DFM.
Any polling analysis done in DFM can be leveraged by VHM. When polling devices, DFM polls generic parameters, while VHM polls voice-specific parameters. When VHM is used in conjunction with DFM, users can detect generic faults that are causing VoIP disruptions.
VHM correlates the collected information and generates events on voice components that can be viewed in alarm logs or on the Real-Time Dashboard. Users can also view device level faults in the DFM alarm log. Alarms for both VHM and DFM can be seen from the Monitoring Console.
VHM and DFM share many features as well as some components of their architectures. VHM and its commonality with DFM are described in more detail in the "VHM and DFM Interdependencies" section.
Event Correlation in VHM
Two types of events are generated by VHM: Compounds and Symptoms. One or more Symptoms generate compound or aggregated events. Symptoms are faults, such as Power Supply Down or Temperature Too High, which generate environment exceptions. Events are generated when fault conditions are detected and the event correlation cycle is reached. The event correlation cycle in VHM occurs every 30 seconds.
An example of an event correlation in VHM is TooManyInActivePhones. This event is generated when phones registered with call managers in a cluster become inactive and cross the InActivePhoneThreshold over a number of active phones. In this event, all the call managers in the cluster are monitored to find out the total number of phones that became inactive and compare that number with the total number of active phones in the cluster.
VHM and DFM Interdependencies
Note
Device Fault Manager (DFM) and VHM both analyze Cisco device failures. The two products often identify problems before users of network services realize that a problem exists. Both VHM and DFM:
•
–
–
•
–
–
The event information necessary to diagnose problems is present in the correlation model. Therefore, VHM and DFM monitor only the events necessary to diagnose problems.
Table 1-1 lists the interdependencies between VHM and DFM.
Table 1-1 Interdependencies between VHM and DFM
DFM Installation
A DFM-compatible version of VHM must be installed either on the same machine as VHM or on a remote machine where it is network accessible to VHM. See Installing and Setting Up Voice Health Monitor on Windows 2000 for server system requirements.
DFM Broker
The DFM Broker maintains a list of active domain managers running on the network and registered with the DFM Broker. Domain managers are fault management server processes such as VHM and DFM. Each domain manager is identified by name and the IP address and port the domain manager is running on.
The VHM installation process can find the DFM Broker if it is installed locally. If not, during installation, VHM prompts the user to enter the IP address and port for the DFM Broker. VHM then registers the VHM domain manager with the DFM broker.
SNMP Trap Receiving
To receive SNMP traps for VoIP devices from DFM, VHM must update the trap forwarding filter in DFM. When DFM receives a trap, it forwards the trap based on the definition of the trap forwarding filter. The VHM trap receiver receives the trap and analyzes it to generate an event in VHM.
Inventory Collection
Inventory Collection performs two tasks at a user-scheduled time:
•
•
VHM also registers with DFM to receive device list update events. If any device is added or deleted, or becomes unresponsive, DFM sends an event alarm to VHM. VHM can process the event by, for example, starting to manage new voice-enabled devices.
Alarm logs
VHM generates voice faults and listens for element-level faults from DFM. If VHM receives an alarm for a device it manages, it uses the alarm in voice fault correlations. Alarms for devices that VHM does not manage are dropped.
For more information about VHM fault browsers, see "Monitoring Voice Network Health."
Device classification differences between VHM and DFM
VHM and DFM classify devices differently. For example, Cisco routers and Catalyst switches are managed by both VHM and DFM. However, DFM classifies Cisco routers as Router class, while VHM classifies routers as Voice Gateways.
Note
Polling and threshold parameters between VHM and DFM
Threshold parameters for voice-enabled routers and switches must be set in DFM. However, threshold parameters for media servers must be set in VHM and are not shared with DFM.
Polling parameters are not shared between VHM and DFM. However, it is best to synchronize them to avoid inconsistent polling of devices. Therefore, it is recommended that you set polling intervals the same in both VHM and DFM.
Figure 1-1 illustrates the architecture that VHM shares with DFM.
Figure 1-1 VHM Architecture
How VHM Integrates with Third-Party NMSs
VHM can be integrated with third-party vendors' NMSs such as HP OpenView Network Node Manager. VHM integrates with an NMS in two ways:
•
See Installing and Setting Up the Device Fault Manager on Solaris for the default port numbers used by DFM and NMS and for example configuration scenarios to help you understand how DFM and NMSs can work together.
•
–
–
Device Types that VHM Manages
The voice-specific devices managed by VHM are categorized by voice device group. Table 1-2 lists the voice device groups and their descriptions.
For each voice device group, the following information is displayed on VHM Real-Time Dashboard:
•
•
•
•
For further information on the Real-Time Dashboard and the individual information displayed for each voice device group, see the "Using the Real-Time Dashboard" section.
Locating the Supported Device List
Device packages for all supported devices are installed when you install VHM. Information about devices installed with VHM can be found at:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/vhm/vhm1_0/supdv1_0.htm
You can download device packages for new devices as they become available and find information about all supported devices from CCO at:
www.cisco.com
To find out which device packages are installed on your CiscoWorks2000 Server, select Server Configuration > About the Server > Applications and Versions.
How VHM Works with the CiscoWorks2000 Server
VHM works in conjunction with the CiscoWorks2000 Server, which represents a common management foundation, providing a set of management services shared by multiple management applications. VHM uses these CiscoWorks2000 components:
•
•
•
•
•
•
•
•
•
Starting the VHM Application
To start VHM from the CiscoWorks2000 desktop:
Step 1
The following applications and folders are displayed:
•
•
•
Getting Started with VHM
Table 1-3 contains the tasks necessary to use VHM to discover VoIP network devices and applications and to generate faults based on voice network events.
