Table Of Contents
Deployment Guide for CiscoWorks IP Telephony Environment Monitor 2.0
Preparing Devices to Be Monitored by ITEM
Media Convergence Servers on Compaq (Cisco-approved) Platforms
Media Convergence Servers on IBM Platforms
Enable/Install Windows SNMP Service
Browser Version and Java Plug-in
Preparing the Network for ITEM
Register Devices and Interfaces in DNS
Configure Cisco CallManager Security Certificates
Modify Admin Password and Cisco.com Account
Setting Up Device List Synchronization Between RME and ITM
Determining the Media Server Account to Use for Cisco CallManager Access
Managing Cisco CallManager Security Certificates
Importing Cisco CallManager Security Certificates
Validating Cisco CallManager Security Certificates
What Are the Benefits of Using Groups?
Working with Notification Services
Working with the Alerts and Activities display
Confidence Tests Descriptions and Expected Results
How to Set Up Applications for Confidence Testing
Polling and Threshold Configuration
How Do I Change Polling and Threshold Values for a Device?
How Do I Verify New Polling and Threshold Settings?
How Do I Revert Back to Factory Polling and Threshold Settings?
How Do I Create Custom Polling and Threshold Settings for Multiple Devices?
Integrating HP OpenView and NetView with CiscoWorks ITM
IP Phone Information Facility Initial Setup
IP Phone Information Facility Discovery
Using IP Phone Information Facility to Run Queries
IP Phone Information Facility Reports
Technology Under IP Phone Reachability Testing
Setting Up Phone Reachability Tests
Managing IP Phone Reachability Testing
Troubleshooting Discovery-Related Issues
Sensitivity to Available Memory and CPU Headroom
Multi-View Discovery Recommendations
Identifying CPU-Intensive Operations
High Event Throughput Conditions
Simultaneous Operations by Multiple Users
Daily Use Scenarios (using ITEM in your network)
Deployment Guide for CiscoWorks IP Telephony Environment Monitor 2.0
Introduction
This document outlines steps for successful deployment of CiscoWorks IP Telephony Environment Monitor (ITEM) 2.0 in a large enterprise environment. It will present the initial device setup, installation recommendations, server sizing, and best practices for ongoing administration and maintenance of the product. This document is not an alternative to the installation guide or the user guide as it will not mention all the features and steps of all the operations. Wherever relevant, detailed steps will be provided for the recommendations, but this document does not replace the user guide.
Product Overview
CiscoWorks ITEM 2.0 is a suite of tools that continuously evaluates and reports the operational health of Cisco IP telephony deployments. It monitors Cisco Architecture for Voice, Video, and Integrated Data (AVVID) and Cisco IOS Software-based IP telephony environments. It also provides specialized operations and security tools beneficial to large and small IP telephony implementations. CiscoWorks ITEM consists of a product bundle as well as several optional components that can be downloaded from the Cisco Systems website (Cisco.com).
Following are the components of CiscoWorks ITEM 2.0:
•
IP Telephony Monitor (ITM)—Is the base product for the ITEM 2.0 suite. It offers the following real-time assistance to network and telephony operations personnel:
–
–
–
–
•
–
–
–
•
–
–
–
–
–
•
–
–
–
IP telephony can be broken down into multiple layers for purposes of illustration. The lowest layer is the IP fabric layer. This is the layer that supports the infrastructure on which all data and voice must flow. This layer is composed of the core routers, WAN gateways and switches that form a part of the infrastructure. The second layer is the IP Telephony layer. This is the layer dedicated to supporting voice as a service. It consists of the AVVID elements such as Cisco CallManagers, PSTN gateways, Access switches to which IP phones are connected, IP phones themselves, etc. For a particular IP telephony implementation to be successful, both these environments must be managed and monitored.
CiscoWorks ITEM is designed to understand, manage and monitor both these layers. It has a device fault management technology that manages the elements of the data network, combined with a voice health monitoring technology that manages the devices supporting voice in the network. Both these components are integrated tightly to feed data into each other so that the data can be intelligently processed. Figure 1 illustrates how CiscoWorks ITEM fits into a typical IP telephony management scenario.
Figure 1 Typical IP Telephony Deployment
Preinstallation Tasks
This section describes the minimum configuration tasks that should be performed on Cisco IOS, Cisco Catalyst, and Cisco Media Convergence Server devices before attempting to monitor them using CiscoWorks ITEM. It should be noted that this is by no means is a complete list. Depending on the functionality required, further device configuration may be required. For comprehensive information, see Performance and Fault Management from Cisco Press, and look on Cisco.com.
Preparing Devices to Be Monitored by ITEM
For CiscoWorks ITEM features and tools to function correctly ITEM must be able to discover and monitor the devices. In order for ITEM to be able to monitor devices successfully, the following conditions must be met:
•
•
•
•
Cisco IOS Devices
This section describes the steps to set up Cisco IOS devices for monitoring. Note that not all steps may be required, and some steps can be expanded with more functionality. Do not forget to save the configuration to nonvolatile random-access memory (NVRAM) after performing these steps by using one of the two following commands:
write memoryor
copy running-config startup-configCommunity Strings
CiscoWorks ITEM uses the SNMP read community string to retrieve fault and performance information from the devices. Some of the components within ITEM (WAN Performance Utility, SRST Monitoring and IP Phone Reachability Testing) also require the SNMP write community string to configure Cisco IOS IP SLA (IP SLA) on the devices. Therefore, all SNMP community strings must match on the devices and in the ITEM inventory.
To configure SNMP community strings on a Cisco IOS device, use the following global configuration commands:
snmp-server community <read-community-string> ROsnmp-server community <write-community-string> RWThese commands ensure that the device can be identified and added to inventory.
SysName Variable
The system name must be unique on every Cisco IOS device for network services to discover all Cisco IOS devices on the network. Network services use this variable to identify each device via Cisco Discovery Protocol. If this value is duplicated on any devices, network services discover only one of the devices. On Cisco IOS Software, the domain name also affects the sysName.
To set the sysName variable on a Cisco IOS device, use the following global configuration command:
hostname <name>Setting up IP SLA on Cisco IOS Devices
Certain features within the ITEM product use the IP SLA functionality in Cisco routers. If you intend to use these features (SRST Monitoring, IP Phone Reachability Testing, and WAN Performance Utility), you will need to ensure that the IP SLA is enabled on these devices. You will need to do this on all the routers that will be used in SRST Monitoring or by WAN Performance Utility. Typically these are the edge routers in your branch networks and the default gateway for the Cisco CallManager. You can enable the RTR responder in the IP SLA router by issuing the following command under the global configuration mode:
(config #) rtr responderUse the show command to verify that the responder is running fine.
router#show rtr responderUse the following show command to verify that IP SLA is available in the Cisco IOS device.
Router#show rtr applicationCisco Catalyst Devices
This section describes the steps to set up Cisco Catalyst devices for network monitoring. Note that not all steps may be required, and some steps can be expanded with more functionality.
Community Strings
CiscoWorks ITEM uses SNMP read community strings to retrieve fault and performance information from the devices. Also, a write community string is required by some of the components of ITEM (WAN Performance Utility, SRST Monitoring, and IP Phone Reachability Testing) to configure IP SLA probes on the Cisco IOS devices.
To configure SNMP community strings on a Cisco CatOS device, use the following global configuration commands:
set snmp community read-only <read-community-string>set snmp community read-write <write-community-string>These commands ensure that the device can be identified and that SNMP polling can be carried out.
Cisco Discovery Protocol
Cisco Discovery Protocol (CDP) is a Cisco proprietary protocol that is used by devices to advertise their existence to other devices on the network. Each device that has CDP enabled maintains a table of its neighbors. ITEM uses CDP to gather information about Cisco IP Phones connected to Cisco Catalyst switches. If CDP is not enabled on a device, ITEM cannot gather information about Cisco IP Phones connected to this device. CDP is enabled by default, so you need to enable it only if it has been disabled. You might want to disable CDP on devices that are on the borders of your management domain.
To enable CDP on a Cisco Catalyst device, use the following command:
set cdp enable <all | module/port>Tips
•
set cdp enable 2/1-10,3/5-10To disable CDP on a Cisco Catalyst device, use the set cdp disable command.
•
Note
Media Convergence Servers on Compaq (Cisco-approved) Platforms
This section describes the steps to set up Cisco Media Convergence Servers (MCSs) on Compaq platforms for network management. Note that not all steps may be required, and some steps can be expanded with more functionality.
Compaq Foundation Agent Service
The hardware instrumentation on Cisco MCS on Compaq platforms is provided by the Compaq Foundation Agent running as a service or a set of services on the system. As part of the Cisco provided IP Telephony Operating System, these services are automatically installed. You can verify that by looking at the services user interface (Start > Control Panel > Administrative Tools > Services). If the services are not installed, you must install them on the Compaq system.
SNMP Service
As a part of the standard IP Telephony OS installation, the SNMP Service on the MCS box is installed, but community strings are not specified. For ITEM to monitor the device, the device must have a proper SNMP read community string defined for the SNMP Service.
In order to define SNMP read community string, do the following:
Step 1
Step 2
Step 3
Media Convergence Servers on IBM Platforms
This section describes the steps to set up Cisco Media Convergence Servers on IBM x-series platforms for network management. Note that not all steps may be required, and some steps can be expanded with more functionality.
IBM UM Services
The hardware instrumentation on Cisco MCS on IBM platforms is provided by IBM UM Services running as a service or a set of services on the system. As a part of the Cisco provided IP Telephony Operating System, these services are automatically installed. You can verify this by looking at the process umslmsensor from the task manager interface. You can verify installation by locating the UM Services folder under C:\Program Files.
SNMP Service
As a part of the standard IP Telephony OS installation, the SNMP Service on the MCS box is installed, but community strings are not specified. In order for ITEM to be able to manage the device, the device must have a proper SNMP read community string defined for the SNMP Service.
In order to define an SNMP read community string, do the following:
Step 1
Step 2
Step 3
Preparing the Server for ITEM
The following tasks should be carried out or reviewed before installing CiscoWorks ITEM.
Hostname for the Server
You should determine the hostname for the CiscoWorks ITEM server before starting the installation. Once installed, the hostname cannot be changed; if changed, ITEM will not work and it has to be reinstalled.
Verify Locale Settings
CiscoWorks ITEM is currently supported only on U.S. English and Japanese locales. Using other locales means that you are running on a nonsupported configuration. Further, CiscoWorks may display erratic behavior, such as JRunProxyServer services not starting automatically. Non-U.S. English keyboard layouts should work.
Verify DNS Settings
Verify that the CiscoWorks server has correct Domain Name System (DNS) settings. Verify connectivity to DNS, as well as forward and reverse lookup. CiscoWorks uses DNS for numerous operations, and waiting for DNS timeout will make it appear slow.
Verify ODBC Driver Manager
Tactical Graphics Utility (TGU), a component of ITEM, requires that the correct version of Open Database Connectivity (ODBC) Driver Manager be present on the Windows server.
To verify the correct version of ODBC Driver Manager:
Step 1
Step 2
Step 3
Note
Enable/Install Windows SNMP Service
IP Telephony Monitor (ITM) and the add-on components, Tactical Graphics Utility (TGU), WAN Performance Utility (WPU), and Gateway Statistics Utility (GSU) support the host resources and system application MIBs starting from IP Telephony Monitor 2.0 Incremental Device Update 4 (IDU 4). This support enables you to monitor the management station using a third-party SNMP management tool. To enable SNMP queries Windows SNMP Service must be installed before you install ITM or any other components. So before installing IDU 4, ensure that SNMP Service is installed. If IDU 4 is installed without Windows SNMP Service, then to enable SNMP queries you need to install the Windows SNMP Service and reinstall IDU 4.
Note
To verify that Windows SNMP Service is installed, perform the following steps:
Step 1
Step 2
•
•
If the SNMP Service is not installed, follow the Windows online help to install SNMP Service. Search for Install SNMP Service from the online help search.
Browser Version and Java Plug-in
The recommended browser is Microsoft Internet Explorer (IE) 6.0.2600.0000 or IE 6.0.2800.1106. The browsers must have Java Virtual Machine (JVM) 5.1.3182, Java Plug-in 1.4.1_02 and Java Runtime Environment (JRE) 1.2.2. Configure the browser to accept cookies by default. CiscoWorks uses cookies to identify authenticated client sessions. These browser requirements are for both server and client systems.
To verify the version of the JRE running on your client system, launch a Windows command console and type in the following command:
java -versionThis provides you with version information about the JRE.
To verify the JVM in your browser:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
NetBIOS Settings
On the system where ITEM is installed, make sure you have disabled NetBIOS over TCP/IP. The default behavior of Windows is to enable NetBIOS, but if you do not disable it, devices that are not in DNS will cause problems when ITEM tries to discover them.
To disable NetBIOS, go to the network interface properties, drill down to Internet Protocol (TCP/IP) properties, navigate to the advanced configuration, and go to the WINS tab (see Figure 2).
Figure 2 Disabling NetBios
Device Connectivity
Before attempting to manage your network using CiscoWorks ITEM, ensure that you are able to reach devices in all your subnets from the target CiscoWorks ITEM system. This will ensure that there are no IP connectivity issues between the management system and the devices.
Antivirus & Platform Agents
It is recommended that you enable virus protection on your ITM system, using virus protection software. But you should perform active scanning of drives and memory during off-peak hours. You may experience delays and performance may be degraded when the virus scan software is scanning all files.
ITM 2.0 IDU 6 has undergone interoperability testing with the following:
•
–
–
•
–
RAM Configuration
It is recommended that you have a minimum of 2 GB of RAM on the ITEM sysyem. All the IDUs up to IDU 4 can be installed on a system with 1 GB of RAM. However, starting with IDU 5 it is mandatory to have 2 GB of RAM. If your system does not have 2 GB of RAM, the installation will stop.
Server Sizing
Table 1 provides the recommended configurations for server sizing. These are approximate figures, and may not be applicable to every environment, even if the numbers of devices match. The requirements could vary depending on the number of phones and managed ports in the network. Similarly, the number of simultaneous users will also affect these requirements.
It should be noted that the requirements given above move upwards based on the first criterion violated. For instance, if you have 200 devices but end up having more than 1000 phones, you would need a CPU more powerful than 2 GHz. Similarly, if you only have 5000 phones, but have more than 500 devices, you would need a CPU more powerful than 2.8 GHz.
Preparing the Network for ITEM
The following tasks should be carried out or reviewed prior to deploying CiscoWorks ITEM in your IP Telephony network.
Register Devices and Interfaces in DNS
For the name lookup process to work, devices should be registered in DNS. When the discovery process encounters a device, it performs a reverse lookup on the IP address where the device was encountered in order to get the hostname for the device. CiscoWorks then performs a forward lookup on the hostname to get the preferred management interface for the device. Hence, all interfaces should be registered in reverse DNS, but only the preferred management interface should be registered in the forward lookup. The loopback interface is an ideal candidate for this, because it is never down. Ensure that the other interfaces do not have forward lookup pointing to incorrect DNS names. Take care to ensure that the system name (hostname) of the Cisco devices is exactly identical to their DNS names.
If registering all the devices in DNS is not an acceptable option, then you will need to define a host file with the lookup names (sysnames) of all the devices and the corresponding IP addresses. In the absence of DNS, CiscoWorks ITEM will use this as the basis of translation.
Configure Cisco CallManager Security Certificates
Apart from SNMP polling, ITM runs AXL/SOAP queries on Cisco CallManager to retrieve information from the Cisco CallManager. To secure this communication between ITM and Cisco CallManager, you could enable Secure Socket Layer (SSL). This option is available for Cisco CallManager 4.1 or later.
On Cisco CallManager 4.1 or later, enable SSL on these virtual directories:
•
•
To enable SSL on virtual directories in Cisco CallManager 4.1 or later:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
a.
b.
Note
Once Cisco CallManager is configured for SSL, you need to import certificates for the Cisco CallManager to ITM. Please check the user guide of ITM for importing Cisco CallManager certificates and managing them at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itm/itm_20/userguid/usedevmg.htm#wp1190907
Check Routing and Firewalls
Verify that any firewalls between the CiscoWorks server and the managed devices are configured to let management traffic through.See the "Port Availability" section for information on which ports should be opened.
Also, make sure that there is connectivity between the devices to be monitored and the CiscoWorks server. Even if a route exists to a network behind a managed device, that does not mean that one exists to (and from) the device itself.
NAT
CiscoWorks ITEM has limited support for Network Address Translation (NAT). For CiscoWorks ITEM to support devices behind a NAT firewall, you will need to ensure that you have both IP and SNMP reachability to the NAT IP addresses from the CiscoWorks ITEM server. You will also need to ensure that you do not have duplicate IP addresses across NAT domains that you are trying to monitor with the same CiscoWorks ITEM server.
Network Time Protocol
To be able to correlate events across multiple devices, the devices need to have the same perception of time. To achieve this, configure the Network Time Protocol (NTP) on the devices. For information on how to configure this functionality, refer to the Cisco device configuration documentation or http://www.cisco.com/univercd.
Port Availability
Before installing ITM, make sure that the ports ITM uses are not already used by your existing applications. ITM and CiscoWorks Common Services 2.2 use the following TCP and UDP ports.
ITM Installation
This section describes the types of installations you can perform for IP Telephony Monitor (ITM) (the base product for ITEM 2.0) . For actual installation procedures, see Installation and Setup Guide for IP Telephony Monitor on Windows 2000.
Installation Procedures
ITM requires a dedicated system. It cannot coexist with any other CiscoWorks application. ITM is supported only on Microsoft Windows 2000 Professional, Server, and Advanced Server with Service Pack 3 or Service Pack 4. The current version of Windows can be verified by running the command winver from a command prompt on the ITM system. Terminal Services in local or remote administration is not supported on systems where you intend to install ITM.
ITM has three different modes of installation:
•
•
•
The overall installation procedure for ITM takes approximately one hour and could vary based on the server speed and configuration. At the end of the installation you are prompted to restart the system. The system must be restarted before installing any additional components of CiscoWorks ITEM. Failure to do so might lead to inconsistent behavior in the interaction between CiscoWorks ITEM modules.
Installing IDUs
CiscoWorks ITEM releases periodic device updates that add support for newly released Cisco devices as well as support for new features. These updates are known as Incremental Device Updates (IDUs) and are available on Cisco.com at the following locations:
For ITM—http://www.cisco.com/cgi-bin/tablebuild.pl/item-3des
For GSU—http://www.cisco.com/cgi-bin/tablebuild.pl/cw-gtwystat-util
For WPU—http://www.cisco.com/cgi-bin/tablebuild.pl/item-wpu
After installing the initial version of ITM, it is a good idea to go to Cisco.com and check if there are any IDUs released for this product. The current IDU that is available on Cisco.com is IDU 6. To install IDU 6, you must have ITM 2.0 and IDU 4 or IDU 5. IDU 6 is cumulative in the sense it carries all the features and device support added in IDU 5. So you can install IDU 6 directly over IDU 4.
IDUs are available for the ITEM drop-ins. So if you have any of the CiscoWorks ITEM drop-ins installed, you will need to download and install the relevant IDUs.
Initial Configuration
After installing ITM, initial configuration should consist of setting up the following:
•
Security and Users
After Installing CiscoWorks ITEM, the first thing you should do is configure the security settings of the product.
Configuring security settings consists of the following:
•
•
Select Login Module
You should verify that you are using the correct login module for CiscoWorks. From the CiscoWorks desktop, select Server Configuration > Setup > Security > Select Login Module. The Select Login Module page displays which login module is being used, and provides you the option to select an alternative login module.
Note
Modify Admin Password and Cisco.com Account
The default password for the CiscoWorks admin user is admin. This should be changed as soon as possible.
Change the admin password by logging in as the admin user, and from the CiscoWorks desktop, select the Server Configuration > Setup > Security > Modify My Profile. In the Modify My Profile page you can change the admin password and add the Cisco.com and proxy information as needed.
Add Users
Add additional users to CiscoWorks as needed. Consider creating one user per operator for logging purposes.
To add users, from the CiscoWorks desktop, select Server Configuration > Setup > Security > Add Users.
Tip
Schedule Backup
Schedule backup enables you to schedule automatic database backups. Backups can be scheduled on a daily, weekly, or monthly basis. In order to conserve disk space, select how many backup versions or generations should be retained (default is 0 or one retained version).
To configure backups, from the CiscoWorks desktop, select Server Configuration > Administration > Database Management > Schedule Backup.
Specify where you want the database dump to be stored, and the number of generations you want.
CiscoWorks ITEM can have up to six databases depending on the drop-ins that are installed. The databases are cmf.db, ama.db, iteminv.db, itemfh.db, itemepm.db, pif.db, and gpf.db.
The size of the database dump varies depending on the size of the inventory, the duration and the volume of study information, and the number of alerts and events identified by ITEM. Make sure you have sufficient disk space in the drive in which you are storing these backups (at least 10 GB of free space on the disk).
Tip
IP Address/Hostname Changes
Details such as IP address and hostname for the server on which you plan to install ITEM should be determined in advance. Making these changes after installation will involve downtime and should be done carefully.
To change the IP address of the server:
Step 1
net stop crmdmgtdStep 2
net start crmdmgtdIt will take a few minutes for all the processes to start and reach their steady state. Once that has happened, the operation is complete.
Changing the hostname is a more involved process. The recommendation is to reinstall the product.
Setting Up Device List Synchronization Between RME and ITM
In ITM 2.0 IDU 2 or later support for automatic device list synchronization between CiscoWorks Resource Manager Essentials (RME) and ITM is added. You will first need to download the utility ITM2.0.IDU.v2.RMESynchronization and install it on your RME server. Both Windows and Solaris versions of this utility are available. So depending on your RME platform, you will need to download the appropriate version and install it on the RME server. This utility is supported for versions 3.4 and 3.5 of RME.
Before installing this utility make sure that you have connectivity between the RME server and the ITM server. You will also need to know the IP address or hostname of the ITM server and a valid username and password for the ITM server. This username should have the privilege to add devices to the ITM server. In case you are integrating RME with a Multi-View version of ITM, the synchronized devices will be stored in the default partition (P0) until the partition administrator chooses to move the devices to the appropriate partition.
Once you finish the installation, verify that the installation was successful.
1.
2.
If you ever need to remove the RME synchronization utility, you can uninstall this utility from the RME server by using the CiscoWorks uninstallation framework. From the RME server select Start > Programs > CiscoWorks > Uninstall.
Multi-View Administration
If you are administering an ITM Multi-View installation, you must first create a user with the role of Partition Administrator. The procedure for creating the user is similar to creating any CiscoWorks user with administrator privileges. The partition administrator is the user authorized to move devices between the default partition and other available partitions.
After creating a partition administrator, make sure you create all the users who will need access to the different partitions available in ITM Multi-View. You will be assigning these users to the respective partitions at a later time using the Multi-View Manager page.
Device Management
Before you start using ITM, ITM must learn about your IP Telephony network. For this to happen, you must import the devices into ITM. ITM uses a combination of SNMP and HTTP queries to discover devices and start managing them. In order to ensure that you do not face any difficulties in letting ITM discover your network, make sure that you have the SNMP read community string for all your devices available. In case of Media Convergence Servers (MCSs) running Cisco Call Manager or other voice applications, make sure you also have the administrative username and password available. Table 4 lists the information required for ITM to successfully discover devices.
Table 4 Device To Credential Mapping
Data devices (routers, switches, gateways, gatekeepers, etc.)
Yes
No
No
Media Convergence Servers (running Cisco CallManager)
Yes
Yes
Yes
1 HTTP Username and HTTP Password refer to Windows username and password. For information on determining the username and password, see the "Determining the Media Server Account to Use for Cisco CallManager Access" section.
Determining the Media Server Account to Use for Cisco CallManager Access
To enable ITM to access a Cisco CallManager, you must supply the username and password for an account on the media server. The account to use depends upon the Cisco CallManager version and might also depend on whether multilevel administration access (MLA) is enabled for the Cisco CallManager.
Device Import Options
Devices can be imported into ITM in four different ways:
•
•
•
•
Manual Device Import
To import devices manually use the Add/Import/Export Devices page. From the CiscoWorks desktop, select IP Telephony Monitor > Device Management > Add/Import/Export Devices. Then use the Add button to add devices to ITM one at a time.
For media convergence servers, there is a parameter called Ethernet Phone Port. Its default value is set to 2000. This is the port that Cisco CallManager uses to communicate with IP phones. If you know that this has been changed, use the new value that the Cisco CallManager is using. You can check the value used by Cisco CallManager by going to the Cisco CallManager Administration page and looking under Server > Cisco CallManager, then locating the Cisco Call Manager instance that you are trying to import into ITM.
Note
Using a Seed File to Import Devices
Importing a large number of devices can be time consuming if done one at a time. To help in this process, ITM allows you to import devices using a seed file. The seed file can be a manually created file or a file that is generated from the export feature in CiscoWorks RME.
Manually Created Seed File
To obtain a copy of the seed file, go to the directory where ITM is installed on your hard drive (CSCOpx\ImportFiles). You will find a file called sampleITEMExportFormat.txt.
Make a copy of this file and use it to input the devices and their credentials. When you open the file, you will see instructions on using the file and two sample entries. Use the sample entries to guide you in inputting the device credentials into this file. After entering all the device credentials, remove the sample entries and save the file. You can now import the devices into ITM using this file.
To import devices using a seed file, use the Add/Import/Export Devices page. From the CiscoWorks desktop, select IP Telephony Monitor > Device Management > Add/Import/Export Devices. Then use the Import button to add devices.
Using the CiscoWorks RME Export Feature
If you already have CiscoWorks RME installed in your network and you wish to manage the devices both in ITM and RME, you can use the export feature of RME to create a seed file that ITM will use to import the devices into ITM.
To export devices from RME:
Step 1
Step 2
Step 3
Step 4
•
•
•
•
The following figure provides an example of the RME Export To File page:
This process works well for all the data devices since ITM only uses a subset of the credentials that RME uses. But for media convergence servers, ITM requires the administrative username and password, which RME cannot provide. Therefore, any media convergence servers that you are importing will not be completely discovered. They will be moved to the Aware state.
To fix this situation, you should do the following:
Step 1
Step 2
Step 3
Step 4
Setting Up Automatic Synchronization Between RME and ITM
Once you install the RME-ITM change probe on the RME server and let it know about the ITM server, the synchronization is set up and no further configuration is required.
The device list is synchronized according to the frequency defined during installation. If you need to change the frequency, you will need to run a command utility on the RME server. This utility is called updateItmParams. More details about this can be found in the ITM online help.
Every time a device is added to RME, the device credentials are securely passed to ITM and ITM discovers the device. For network devices, like routers and switches, ITM receives all the necessary details from RME and the device is completely discovered and goes to the Known state. For Cisco CallManagers, RME does not have all the information, therefore these devices are only partially discovered in ITM. Cisco CallManagers go to the Aware state after discovery is completed. You will need to provide additional information regarding administrative username and password to complete the discovery of the Cisco CallManager.
To fix this situation, you should do the following:
Step 1
Step 2
Step 3
Step 4
Note
Device Discovery Process
Once the data has been input into ITM, ITM begins performing SNMP and HTTP queries to the device to understand the device composition, port and interface details and its connectivity to other elements of the IP telephony network. On data devices like routers, switches and gateways, only SNMP queries are performed. On the voice related devices like Cisco CallManagers and other voice application servers, SNMP and HTTP queries are performed. During this time, the status of the device discovery is Learning.
Figure 3 illustrates the changes in device states for a device as it goes through discovery.
Figure 3 Device Discovery Process
If ITM does not support a device, the device will be moved to the Unknown state.
If ITM cannot reach the device through ICMP or SNMP, the device will be moved to the Questioned state. You can look at the error condition that caused this state by going to Device Management > Edit Device Configuration and opening the All Questioned Devices group, and then selecting the device that is in the Questioned state. In the adjacent pane, you will see the error condition and its cause listed.
Sometimes if the link between the ITM server and the device is very slow, or if the device is slow in responding to SNMP queries, the SNMP queries may timeout and the device may be placed into the Questioned state. In this case, you should change the SNMP timeout and retries parameters for the discovery and restart the discovery on these devices.
Note
If ITM is able to perform all the SNMP queries and discover the device completely, the device will move to the Known state. This means that ITM fully understands the composition of this device and supports all operations on this device.
If ITM is able to perform SNMP queries on the device, but has problems performing HTTP queries to the device, the device will move to the Aware state. This means that ITM can support only a subset of the operations on this device and can provide limited monitoring of the device.
Note
To fix this situation, you should do the following:
1.
2.
3.
4.
The final goal of the device import operation is to get all the devices into the Known state. Once this has been achieved, you can be sure that you can perform all of ITM's operations on all devices. When you reach such a condition, it is a good practice to export the current inventory to a CSV file so that it can be used for future import operations.
To export the current inventory of ITM, from the CiscoWorks desktop, select IP Telephony Monitor > Device Management > Add/Import/Export Devices, and then use the Export button to export the inventory to a file. The credentials stored in the file are encrypted.
Managing Cisco CallManager Security Certificates
In addition to SNMP polling, ITM uses AXL/SOAP queries on Cisco CallManager to obtain information. To secure communications between the Cisco CallManager and ITM you can enable SSL in Cisco CallManager. Once SSL is enabled on Cisco CallManager, certificates need to be imported into ITM server. Without certificates, ITM cannot monitor the connectivity between devices and Cisco CallManager; the Cisco CallManager remains in Aware state.
Note
Importing Cisco CallManager Security Certificates
It is very important to import security certificates for those Cisco CallManagers on which SSL is enabled. If you do not, the Cisco CallManager will continue to remain in Aware state and ITM will not be able to monitor Cisco CallManager completely.
To import security certificates:
Step 1
Step 2
Step 3
Step 4
Step 5
Validating Cisco CallManager Security Certificates
Once certificates are imported into ITM, you need to validate the certificates periodically to ensure they are up to date and match the certificates in Cisco CallManager. You can validate certificates by going to IP Telephony Monitor > Device Management > Manage CCM Security Certificates. In the window on the right select CallManager Server and click Validate Certificate.
Validation does the following:
•
•
If an error message appears and states the security certificate has expired or is invalid, you must reimport the certificates from Cisco CallManager. For details on reimporting see the "Importing Cisco CallManager Security Certificates" section.
Working with ITM Multi-View
If you are performing device import in an ITM Multi-View installation, you should log in as the partition administrator user. This is the only user who is allowed to work in the default partition titled P0. When you import devices in a multi-view installation, the devices are placed in the default partition and the discovery process is initiated. It is recommended that you let the discovery complete while the devices are in the default partition. You should move the devices into the respective partitions only after the devices reach the Known state.
Even if you are a partition user and you import devices into your own partition, ITM will move these devices into the default partition and initiate the discovery. Only rediscovery of pre-existing devices are carried out in the partition they are currently residing in.
Setting Up ITM
This section helps you to get started using ITM's features.
Initial configuration of ITM constists of the following:
•
Device Grouping
Organizing devices into groups enables you to work more efficiently with the devices monitored by ITM. Groups can be used to perform operations like notification services, Alert views, polling and threshold definitions, querying alert histories, etc.
ITM has a feature called Group Management that can be used to group devices or applications based on certain sets of predefined criteria. You can create groups with static membership or groups with dynamic membership that are updated based on defined criteria. ITM is shipped with predefined groups based on device capabilities and device characteristics. These groups are called System Defined Groups. In addition to these groups, you have the ability to create your own groups based on a variety of criteria (for example: location, IP addressing, contacts, device relationships, or static memberships). These groups are called User Defined Groups.
In a Multi-View installation of ITM, both System Defined Groups and User Defined Groups can be defined in each of the ten partitions.
After completing device discovery, ITM automatically populates all the System Defined Groups with all the devices. Also, if you have any User Defined Groups with dynamic membership, these groups will be refreshed after device discovery.
To verify group membership:
Step 1
Step 2
Step 3
Step 4
What Are the Benefits of Using Groups?
If you have a large inventory of devices (1000 or more devices), you will likely have a significant number of devices with similar capabilities. You may end up with over 500 members in either the Switches group or the Routers group. Keeping track of so many devices becomes difficult. To help with this, you can group devices based on the person responsible for maintaining them, or you can consider grouping them based on their geographical location. By doing so, you will have groups that are representative of your topology. Within a single geography, you could group devices based on the IP addressing scheme and create a hierarchy of device groups.
How Can I Create Groups?
Before you create groups, you need to ensure that the criteria on which you plan to group devices have valid entries in the device configuration. For example, if you are planning to group devices based on the location or the primary contact person, make sure that the devices have this information in them. If the devices are not properly configured, they will not show up in the correct format.
Note
To create groups, from the CiscoWorks desktop, select IP Telephony Monitor > Configuration > Group Management. From the Group Selector, select the group User Defined Groups and click the Create button. You will be prompted to go through a wizard to create the group.
How Do I Maintain Groups?
Once a group is created, it is not removed until deleted. If the group is a static group, its membership is not updated to reflect the current device inventory. You have to manually refresh the group to update its membership. If the group is a dynamic group, then its membership is refreshed to reflect the current device inventory at all times.
Since a group will continue to remain in ITM at all times and will consume resources, it is important to delete groups that are not being used. To delete a group, go to Configuration > Group Management.
Note
Working with Notification Services
The Notification Services module within ITM is responsible for transmitting email, syslog, and SNMP trap notifications to its subscribers. If there is a messaging gateway to the paging system, epage subscriptions can also be set up.
Most large enterprises have their own domain managers already running in their management systems. One of the primary requirements for any new management application to fit into their present mode of operations is to integrate with their existing managers. Therefore, the SNMP traps that come out of ITM are helpful in integrating ITM with other managers like Cisco Info Center (CIC), HP OpenView Network Node Manager (NNM), or Tivoli Netview.
The email and epage notification mechanisms provide additional ways for informing network operations personnel about the alerts in their network. This frees the network personnel from having to monitor the real-time fault view throughout the day.
Along with SNMP Trap and eEmail notification, syslog notifications are provided starting with IDU 4. The syslog notification feature enables forwarding of syslog messages to syslog daemons on remote systems.
Notification Services works on the basis of subscriptions. For every subscription that you set up, you can define for following:
•
•
•
•
•
•
Note
The subject line in the email has details about the device and the alert. The configuration options provide you with multiple choices for creating subscriptions to cover all your needs. For example, you can create separate subscriptions for critical, warning, or informational alerts. They can also separate new alerts from currently acknowledged alerts. There is also an option to suspend subscriptions. This lets you create separate profiles based on the operations shifts and allows you to suspend or resume the appropriate ones when the shift changeover takes place.
Along similar lines, for SNMP trap subscriptions, you can define the recipient hosts and the ports to which the SNMP traps are sent. ITM uses the traps defined in the Cisco EPM Notification MIB.
Notification Customization
Starting with IDU 4 you can customize the names of the events displayed by ITM. The customized names are used in the Alerts and Activities display, Fault History and Notification Services. It is a good idea to change the names of the events where the events names are not easily understood. To launch Notification Customization, from CiscoWorks desktop go to IP Telephony Monitor > Configuration > Notification Services > Notification Customization.
Working with the Alerts and Activities display
The Alerts and Activities display is the primary operational interface for ITM. This is a real-time view that lists all the alerts on the current devices in the inventory. An alert in the context of ITM is a rollup of multiple fault conditions (events) on a device. At any point, a device can have only one alert on it. The alert would be a summary of all the different fault conditions on this device. At this level only basic information about the alert is exposed to the user. The parameters relating to the alert that are displayed are severity of the alert, type of the device, duration of the alert, last update time stamp on the alert, the device name/IP address, the category of the last update to the alert, and finally the current status of the alert.
The display can be organized by views and each view can be assigned to report on a set of devices. The alerts in the Alerts and Activities display can be exported into a csv or pdf format. The information in the display can be printed, exported, and filtered. Users can also invoke Fault History from within the Alerts and Activities display to query historical faults for the past 31 days on the devices in that view. If the view has been filtered, then historical data only on the filtered devices will be shown in Fault History. Any operation (exporting, printing, or historical reporting) would be only on the devices in the current view, and if the view has been filtered, it will be only on the filtered devices.
Why Do I Need Views?
If you have a large inventory of devices (over 500) then you could potentially see many alerts in the Alerts and Activities display on these devices. Beyond a certain number, the volume of alerts becomes unmanageable and if multiple operations personnel are involved in maintaining the network, one person may only be concerned with the alert information on a certain set of devices. Views can be used to organize the available inventory into different buckets based on who is responsible for them or based on the geographical deployment of the devices.
How Do I Create Views?
Two operations must be performed before views show up on the Alerts and Activities display. They need to be created, and then activated. Any number of views can be created in ITM, but only eighteen can be active at a time. With the addition of the two default views, the Alerts and Activities display is limited to twenty active views at one time. Make sure you identify the most important views and activate only those.
Alert views are based on grouping (see Device Grouping). Every view must be associated to at least one group, but you could use the same group as the basis for multiple views. Before you create a view, identify the groups of devices that map to the view. If you do not have a group or multiple groups that contain all the devices you want in the view, create additional groups using the Group Management functionality.
To create a view, from the CiscoWorks desktop, select IP Telephony Monitor > Configuration > Alerts and Activities Views, then click the Create button. The creation proceeds through a wizard.
Once a view is created, if you need to see it on the Alerts and Activities display, it must be activated.
To activate a view, from the CiscoWorks desktop, select IP Telephony Monitor > Configuration > Alerts and Activities Views, then select the view from the list of the available views and click on the Activate button.
If the Alerts and Activities display is already open, the view will show up after the next refresh cycle. The view panel is refreshed every two minutes and the alert panel is refreshed every thirty seconds.
Note
Drill-Down Actions on Alerts
Since the alerts in the Alerts and Activities display only give the highest level information, it is necessary to drill down to get more information. There are two different paths for drilling down. One is using the Alerts and Activities Detail page, and the other is using the Detailed Device View.
Once an alert is generated and it appears on the Alerts and Activities display, the next task for you is to drill down and understand what caused the alert. You can do this by clicking the hyperlink corresponding to the alert ID. This launchs a popup window called the Alerts and Activities Detail page, containing details about the alert. This window lists all the events that are responsible for the alert (both active as well as cleared). For every event that appears in the window, the nature of the fault, the component on which the event was noticed, the time of occurrence, the severity of the fault, the status of the fault and the tools available to troubleshoot the fault are listed.
Currently, Fault History is the only tool that is available. Launching Fault History in this context will bring up a history of faults on this component for the last 24 hours. Further details on what caused the fault to occur can be retrieved by clicking on the hyperlink corresponding to the event ID. This launches a popup window that provides information that relates to the cause of the fault. The information in the Alerts and Activities Detail page can be printed. The other tasks that can be done from this window are annotation, acknowledgement, notification, and suspension of monitoring.
Annotation is a mechanism to add user entered data and relate that to the current alert. This is done by clicking on the Annotate button and then entering the data in the popup window. The information entered will be mantained with the alert, and in the future, whenever the alert is presented to you through Fault History in the Alerts and Activities display, you will be able to pull out the annotation and have access to it. This is an excellent way to document a faults cause, resolution and what was responsible for the fault.
The other action that can be performed from the Alerts and Activities Detail page is the acknowledgement of alerts. This causes the status of the alert to change from Active to ACK. This is an irreversible action and cannot be undone. After an alert has been acknowledged, its status will show up as ACK in all the Alerts and Activities displays that are open currently and any that will be opened in the future. This lets other users of the Alerts and Activities display know that this alert has been taken over by someone. If a suitable notification profile has been defined, then a notification (trap or email) will be sent when the state of the alert changes to ACK.
If notification subscription profiles have been defined, ITM will automatically send emails whenever alerts are generated. However, if there is a case where a separate email needs to be sent about the current alert, then the Notify feature in the Alerts and Activities Detail page can be used to accomplish this task. This feature can be invoked by clicking the Notify button in the view and in the subsequent popup. You will be required to enter the source email address, the destination email address, the SMTP server to use, and an optional message. The e-mail notification will contain only the text you add; it will not append any alert or event information.
The final option available in this window is the Suspend option. This causes ITM to suspend monitoring the device, until there is a request to resume monitoring. This is especially useful if the device is still being configured and the alerts you are seeing are due to configuration errors or mismatches. Clicking the Suspend button takes you to the Detailed Device View for that device, where there is an option to suspend the device. Once a device is suspended, no alerts will be generated on that device and it will not be polled until further notice. Suspension of the device will also cause all confidence tests to be suspended on that device. It will also suspend the periodic rediscovery of the device to track new hardware or software components. The device will, however, stay in inventory and ITM will continue to remember the credentials of the device.
The other drill-down action that can be performed from the Alerts and Activities display is to launch the Detailed Device View on the device. Once an alert and its causes have been understood, there might be a need to retrieve more details about the device and its hardware or software configuration and status. The Detailed Device View is a good place to get this sort of information. The Detailed Device View can be launched by clicking on the device name in the Alerts and Activities display. This causes a popup to be launched, containing details about the device. In the left pane you will see a hierarchical tree structure listing the different components of the device (both software and hardware) and in the right pane you will see information about the selected component. When the Detailed Device View is launched, the default content of the right pane shows high level information about the device (IP/MAC details, platform, software version, etc.). If individual components need to be suspended from monitoring, select the component in the left pane, pick the item you wish to suspend in the right pane and change the managed status from true to false for that row. This causes the particular component to be suspended. This is a useful way to get rid of monitoring components that you know will never be repaired, or that you wish to ignore for the time being. The Detailed Device View is also the place to suspend and resume monitoring the complete device. When you resume monitoring a device, be sure to go to IP Telephony Monitor > Configuration > Apply Changes and apply your changes. If this step is not followed, the device will not resume and polling will not be reinitiated.
Fault History
The Fault History component within ITM does not need any set up. It automatically processes every alert that ITM processes. The information is entered into a database and multiple queries are provided to view this data. You can query the Fault History data by alert details (alert ID, device name, device group) or by event details (event ID, alert Id, device name or device group). The information that matches the query is shown in the form of a report. The data in the report can be exported to a CSV or PDF format or can be printed.
Working with Fault History
Fault history is set up by default to purge data older than 31 days. This means that every day, any alert or event information that is older than 31 days is purged. Once the information is purged, there is no way to recover it. Hence it is important to periodically export the information to a PDF or a CSV file if you need to persist the data for longer than 31 days. The data can be exported by generating a report using a generic query and then selecting the export option from the report.
If Fault History finds more than 2,000 records while generating a report, a popup window tells you the total number of records found. The Fault History displays can show up to 2,000 records as a table you can scroll or page through. If your report exceeds 2,000 records and you want to view all of them, you can use the Export tool button to save all of the information to a CSV or PDF file.
You can use Fault History to generate customized tabular displays of specific alerts, specific events, event dates, event severity, and so forth.
You might want to generate a Fault History report when:
•
•
•
Note
Confidence Tests
Confidence testing is a mechanism by which ITM attempts to use the available voice applications in the IP telephony network just like a typical user would. For example, ITM makes phone calls, logs on to conferences, leaves voice mails, makes emergency calls, and downloads TFTP files. When any of these operations fail, ITM flags this as an alert, letting the operations personnel know that there could be a problem. Confidence tests are supported on a variety of applications (Cisco CallManager, TFTP Server, Cisco Conference Connection, Cisco Emergency Response, and Cisco Unity) and these tests can be scheduled to run in any sixteen hour period. You should run these tests between 6:00 am and 10:00 pm. Beyond this period, ITM performs internal update operations such as rediscovery of devices for hardware and software updates, and reconfiguration of polling servers for updated polling and threshold settings. These operations consume significant CPU and memory resources, so running confidence tests at the same time might cause failures due to a lack of system resources and could create false alerts.
ITM simulates Cisco IP Phones (Cisco 7960 phones) to execute confidence tests. Before setting up confidence tests, the appropriate Cisco CallManagers need to be configured with details about these IP phones.
ITM communicates with Cisco CallManager using the default phone Ethernet port 2000 on Cisco CallManager. If this port is changed all the confidence tests related to that Cisco CallManager will fail. To fix this, when adding the Cisco Call Manager you must enter a different phone Ethernet port. This is done through the Device Management page.
How Many IP Phones Do I Need?
The number of IP phones you need to define in the Cisco CallManager depends on the number of tests you plan to configure. Different types of confidence tests need a different number of IP phones. A predefined MAC address range has been earmarked for these IP phones so that it does not clash with any of the real IP phones or devices in the network. The MAC address range that is available for confidence testing is between 00059a3b7700 and 00059a3b8aff. It is a good idea to input the description for these dummy IP phones as "ITM Simulated Phone" when they are configured in the Cisco CallManager so that it is distinct from the descriptions of other IP phones in the Cisco CallManager. The phones to be used in confidence testing must be configured as 7960 phones in the Cisco CallManager. Table 6 table lists the number of phones needed for the different confidence tests.
Confidence Tests Descriptions and Expected Results
Table 7 lists the confidence tests supported in ITM, what each of these tests is trying to accomplish and what is the expected behavior.
How to Set Up Applications for Confidence Testing
The following sections describe the setup that needs to be done on the applications being monitored so that confidence tests can be run on them.
Setting Up Cisco CallManager for Confidence Testing
The only configuration needed in the Cisco CallManager to start running confidence tests is the creation of IP phones in the Cisco CallManager. The following conditions need to be met for the phones:
•
•
•
Setting Up TFTP Server for Confidence Testing
No special configuration is needed for the confidence tests on the TFTP server. TFTP tests must be configured only on the Publisher server in a cluster. TFTP servers on the subscribers are shut down as a security precaution and hence if tests are configured on the subscribers, they are likely to fail.
Setting Up Cisco Emergency Responder for Confidence Testing
You will need to create a separate emergency zone to run confidence tests on the Emergency Responder. You cannot use the regular emergency number. When you create the test emergency calling zone, the outgoing Public Safety Answering Point (PSAP) must use a local phone (not 911). Also, for the On Site Alert Number (OSAN), use a synthetic phone only (do not use your local onsite security phone). Ensure that the IP phones that you create in the Cisco CallManager to use in these tests are in the right calling search space to be able to call the emergency number.
Setting Up Cisco Conference Connection for Confidence Testing
You will need to ensure that the IP phones that you create in the Cisco CallManager to use in these tests are in the right calling search space to be able to call the conference connection access number.
Setting Up Cisco Unity for Confidence Testing
When creating the Cisco Unity subscriber that you are going to use for confidence testing, configure the subscriber according to the following:
•
•
Advanced Configuration
This section describes advanced configurations that you might want to perform to customize ITEM to your IP Telephony deployment.
Polling and Threshold Configuration
ITM uses SNMP polling as a mechanism to detect fault conditions in the network. Every device in monitored state is polled at a predefined interval. The default polling interval is four minutes.
Polling and Threshold settings can be viewed or changed by selecting from the CiscoWorks desktop, IP Telephony Monitor > Configuration > Polling and Thresholds > Polling Parameters or Managing Thresholds.
Polling and threshold settings are defined on the basis of groups. Every system defined group in ITM has polling and threshold settings associated with it. Since every device that is in the known or aware state belongs to at least one of the system defined groups, every device will automatically be polled based on the settings in the group to which it belongs. There is an implicit order of priority in these system defined groups. The more specialized the group is, the higher its priority. When a device belongs to multiple groups, it derives its polling and threshold settings from the group that has the highest priority. The customizable groups have the highest priority, and if a device belongs to one of these groups, it will derive its settings from the group.
As an example, if you have a Cisco 2600 router with a voice module (router1.cisco.com), it will belong to the following groups: All Cisco Routers, All Cisco Voice Gateways, All Cisco Gateways/All Cisco Voice Gateways, and All Devices with FXX Interfaces. Of all these groups, the most specialized group is All Devices with FXX Interfaces. Therefore the device would derive its polling and threshold settings from this group.
Similarly, if you have a Cisco Catalyst 3424XL with phones connected to it (access1.cisco.com), it will belong to the groups All Cisco Switches and All Cisco Switches with phones connected. Of these, the most specialized group is the All Cisco Switches with phones connected group. Therefore the device will derive its polling and threshold settings from this group.
Note
How Do I Change Polling and Threshold Values for a Device?
Since polling and threshold settings are defined at the level of the groups, you would first need to find out the groups to which this device belongs, and the overriding group from which this device derives its settings. This can be accomplished by launching the Polling and Thresholds report on one of the groups it belongs to (All Cisco Routers, All Cisco Switches or All 78XX Media Servers). From the report, figure out the overriding group for that particular device. Then select the overriding group and edit the necessary settings (by clicking on the Edit button). The Edit window is a multilayer window. Hence changes made to every layer need to be applied (by clicking on the Apply button) before changing the layers.
After making all the changes, go to IP Telephony Monitor > Configuration > Apply Changes to apply changes that you have made. This operation can cause the CPU utilization on the ITM server to spike for a brief period (10 - 150 seconds). If settings on many groups need to be changed, finish all those operations and then select Apply Changes once. During the periods of high CPU activity, confidence tests may not be run. Therefore these operations should be performed during nonbusiness hours.
How Do I Verify New Polling and Threshold Settings?
To verify that the changes made on the devices have been applied, launch the polling and threshold settings report on the group to which the device belongs. Navigate down to the device settings and verify the new values.
In addition, go to the Apply Changes page (IP Telephony Monitor > Configuration > Apply Changes) and ensure that the message there says that all necessary changes have been applied. This will mean that the changes were updated and applied on the polling and threshold engine.
How Do I Revert Back to Factory Polling and Threshold Settings?
Sometimes, after polling and threshold settings have been changed, there is a need to revert back to the factory settings. This could happen because the changes that were made were temporary in nature, or because the changes caused an undesirable ripple effect. To revert back the changes made on any group's polling and threshold settings, you need to navigate to the Polling and Threshold settings page, select the group and click Default. Upon confirmation, all the settings on that group will be overwritten with the factory settings. If only a particular setting's values need changing, you can use the Default check box in the Edit page to make the change.
How Do I Create Custom Polling and Threshold Settings for Multiple Devices?
If you wish to define your own polling and threshold settings for several devices, not all of which fall under the same system defined group, you will have to use a special category of user defined groups called Customizable Groups to make these configurations. As a first step, edit one of the customizable groups (1-4, A-C) to contain your devices as members. Customizable groups A-C can only contain one device. You will need to use the group management feature to accomplish this task. Once this has been done you go to the Polling and Thresholds page and edit the polling and threshold settings for the groups you want. The priorities of customizable groups will always be higher than those of system defined groups, so any changes made to the customizable group would take effect first. As usual, after the changes are made, you will need to apply changes (go to IP Telephony Monitor > Configuration > Apply Changes) for your changes to take effect.
When you perform factory default operations on customizable groups, all changes made on these groups will be lost and they will revert to the factory state of not having any polling and threshold settings defined on these customizable groups.
Rediscovery Schedules
ITM rediscovery probes the devices to discover their configuration and verify their manageable elements in inventory. If new components are added to devices, then the rediscovery ensures that the newly added components are managed in ITM. ITM contains a default discovery schedule that starts rediscovery on a weekly basis. Although you cannot modify the default discovery schedule, you can suspend it and add, modify, or delete additional schedules. When additional schedules are added, ensure that the start time for rediscovery is specified to be after normal business hours. If you have large inventories (upwards of 500 devices), rediscovery times can range up to an hour or more and during this time, the system CPU resources will be consumed by the ITM discovery engine. Confidence tests cannot be run in this time window, and there will be an impact on monitoring the network, too. It is very important to schedule rediscoveries to run after business hours. Rediscovery schedules can be created to run on a one-time, daily, weekly, or monthly basis. Care should be taken to ensure that multiple rediscoveries are not scheduled to run within the same time window. For example, if you have a rediscovery starting at 20:00 hours, make sure that you do not have another rediscovery starting until at least 23:00 hours.
A rediscovery schedule runs as a job in ITM. To check the status of your job, from the CiscoWorks desktop select Server Configuration > Administration > Job Management. This page tells you whether the job was executed.
Purging Schedules
Purging is used to clear out data older than 31 days from the Fault History database. The default schedule is to run the purge operation every day at midnight to purge data older than 31 days.
If you wish to change the timing of this operation, go to IP Telephony Monitor > Configuration > Daily Purging Schedule.
A purging schedule runs as a job in ITM. To check the status of your job, from the CiscoWorks desktop select Server Configuration > Administration > Job Management. This page tells you whether the job was executed or not. If you wish to disable the purging operation then you can delete the job from this page. If you delete the purging operation, the historical data will never be purged and this causes the Fault History database to grow to an enormous size over a period of time.
The recommendation would be not to delete the purging schedule, but instead to periodically export the contents of the Fault History database into a CSV or a PDF file. This is a manual operation and can be performed from the Fault History report.
SMTP Server
The SMTP server information you enter in the Default SMTP Server page is used as the SMTP server by the email notifiers for sending out emails. It is located at IP Telephony Monitor > Configuration > Default SMTP Server.
Trap Receiving and Forwarding
The SNMP trap receiving port determines which port SNMP traps are received on. The default value is 162, but if the traps are being forwarded by some intermediate entity and it forwards on a different port, you will need to enter that port number here.
The SNMP trap forwarding feature is used to forward all the SNMP traps that the ITM server receives. For each server that you wish to forward the trap to, you will need to provide information about the server name and IP address and the port number that the host can receive the traps on. This feature will forward all the raw traps that are received by ITM, the ones that are processed as well as the ones that are not. This is different from the Trap Notification feature where fault conditions diagnosed by ITM are packaged into traps and sent out. You should not confuse one with the other.
For a list of all the traps that are processed by ITM and the ones that are blindly passed through, see the Appendix, for a link to the table on Cisco.com.
Figure 4 shows different mechanisms of integrating ITM with other Network Management Systems (NMSs) in the network.
Figure 4 Different Integration Options With Other Network Management Systems
Integrating HP OpenView and NetView with CiscoWorks ITM
Starting with IDU 5, third party Network Management Systems (NMSs) HP OpenView and NetView can be integrated with ITM. For this to happen, adapters (available for both Windows and Solaris) need to be installed on these third party NMSs. The HPOV-NetView Adapter enables IP Telephony Monitor (ITM) users to collect and display events from HP OpenView or NetView NMSs. This adapter can be used when users want ITM to monitor faults on devices managed by HP OpenView or NetView.
ITM supports only the following HP OpenView and NetView versions on Windows:
•
•
Download the adapters from Cisco.com and install them on HP OpenView or NetView. During the process of installation, the ITM Server IP address need to be provided. After installing the adapters, restart HP OpenView or NetView to activate the adapters.
Additional Features
This section desribes ITM's additional features. You should become familiar with all of ITM's features to maximize the tools use in your IP Telephony network.
This section describes the following:
•
•
SRST Monitoring
Survivable Remote Site Telephony (SRST) is a software feature in Cisco IOS available on some router platforms (2600, 3600, 3700, etc.) that can provide backup call processing in case of connectivity failure with the Cisco CallManager in the central site. When the WAN link from the remote location to the central site fails, the SRST feature is automatically activated, and the phones register with the router as the call processing agent. As long as the WAN link is down, the router handles the call processing, and when the WAN link comes up, the SRST feature is deactivated, and the phones register with the Cisco CallManager again. This technology provides for backup call processing during WAN outages.
ITM provides the monitoring necessary to determine if the branch is currently using the centralized call processing resources or if it is in SRST mode.
ITM monitors the WAN link between the head office router and the branch office router configured for SRST. When the WAN link goes down, an alert is raised on the SRST router (branch office router). This alert indicates that the phones are in SRST mode in the branch office.
When the WAN link goes down, ITM raises an SRSTEntered event on the branch router, which will be captured in the Alerts and Activities display. When the WAN Link comes back up the SRSTEntered event will clear. SRST Monitoring is achieved by configuring an IP SLA jitter study between the source router (head office router) and the target router (branch office router configured for SRST).
SRST monitoring does the following:
•
•
•
Understanding SRST Monitoring
IP SLA jitter tests are set up between the source router and the target SRST router to detect reachability of the SRST router from the source router. This test is configured by default to send 10-packets at 30-second intervals. The test succeeds even if one of the packets reaches the target and comes back to the source. As an alternative to jitter tests, echo test can be used. However, jitter tests are used for reliability. Echo tests are less expensive but send only one packet, which may be lost, to the target and may lead to false positives. The 10-packet and 30-second interval is a good combination to provide reliable alerts to the user without creating excess traffic on the network. You can also modify these parameters (i.e., number of packets and interpacket time) and also how frequently these tests need to be run. By default 30 seconds is the time interval between the tests. These parameters are present in the seed file and if any changes are desired, the seed file must be modified to reflect that.
In order to understand the high level algorithm, let us look at how the SRST active events get generated. Figure 5 displays the algorithm in the form of a flow chart.
As shown in the figure, ITM constantly monitors the state of the WAN link using the IP SLA tests. If it determines that the WAN link is down, it will immediately classify the phones to be in SRST mode and raise an event titled SRSTEntered.
On the other hand, when the WAN link is up, the data from the IP phone reports is used to figure out if the phones are currently registered to the Cisco CallManager or not. If the Cisco CallManager reports that it has lost contact with all the phones in the remote office (where the SRST router is present), then ITM concludes that there is a possibility that the remote office might be in SRST mode though the WAN link is active, and hence raises an event titled SRSTSuspected.
When the WAN link is restored, the SRSTEntered event is cleared and when one of the IP phones registers back with the Cisco CallManager, the SRSTSuspected event is cleared.
Figure 5 SRST Flow Chart
Setting Up SRST Operations
Before you set up the IP SLA tests, ensure that you have enabled the IP SLA agent on the routers being tested. See Setting up IP SLA on Cisco IOS Devices.
The IP SLA tests for monitoring the SRST status is set up using a seed file. The format of the entries in the seed file is as follows;
Test1,10.76.34.194,public,private,10.76.34.218,public,private,0009e8470515:00075079c2da, 1226:4015 ,30,30,10Where:
•
•
•
•
•
•
•
Also ensure that this router has rtr responder enabled. If this is not enabled then no SRST studies will be configured. For IP SLA jitter tests, the target router should have RTR responder enabled. For instructions on how to enable the RTR responder on the target devices, see Setting up IP SLA on Cisco IOS Devices.
The seed file should be saved in the CSCOpx\Importfiles folder. You can create multiple IP SLA tests using a single seed file. Every line in the seed file corresponds to a IP SLA test. If you need to delete any of the configured tests, you will need to delete the corresponding row from the user interface. To edit the parameters of a test, you will need to edit the corresponding entry in the seed file and import it again in ITM.
Managing SRST Operations
The SRST Operations window is launched from IP Telephony Monitor > SRST Monitoring Management. It displays all the currently configured IP SLA studies between the head office router and Branch office routers. For every study, it gives the name of the study, the source router, and the destination router, and the current status of the IP SLA tests (whether they are active or not). From this window, you can perform administrative operations like suspending the studies, resuming the suspended studies and deleting studies. When studies are suspended, there will be no SRST events. To resume the studies, click Resume.
If any of the devices associated with the study (head office router or branch office router) is suspended from the Detailed Device View, then the studies will also get suspended. These studies cannot be resumed using the resume button in the Detailed Device View. They can only be resumed by resuming the suspended studies.
There is also a new system defined group called All SRST Devices. This group contains all the SRST routers. This group helps the user to create Alerts and Activities display views, notification profiles, etc. for SRST devices.
IP Phone Information Facility
Note
IP Phone Information Facility provides a mechanism to track the deployment of IP phones within the network. It works off of the ITM inventory, collecting data about all the IP phones connected to different switches in the network and validating that data with the information in the Cisco CallManager registration table. It provides a report of all the different IP phones and their current status (connected, disconnected, registered, or deregistered) in a report.
If you are using IP Phone Information Facility in a multi-view (partitioned) environment, you will be able to see phone related data relevant to the currently active partition. Phones are defined to be in a partition if the switches they are connected to, and the Cisco CallManagers they are registered to, are in the same partition. The queries you are able to run will also be restricted to the switches and Cisco CallManagers present in that partition.
IP Phone Information Facility Initial Setup
There is no initial setup needed for IP Phone Information Facility to start working. It starts working as soon as the installation is complete.
IP Phone Information Facility Discovery
Upon the completion of installation of IP Phone Information Facility, it automatically synchronizes itself with the current ITM inventory. IP Phone Information Facility collects the list of switches and Cisco CallManagers known to ITM and starts polling it for phone related data. After the initial discovery is complete, IP Phone Information Facility periodically runs a synchronization routine to synchronize the device list with ITM. This operation is called major discovery and the interval is set to four hours. Information about this schedule is available at IP Telephony Monitor > IP Phone Information Facility > Collection Schedule.
If you wish to modify any of the schedules or add more to the existing list, you can do so from this link. By default six schedules are present. You can add a maximum of ten schedules. In a multi-view environment, only the Partition Administrator can add, delete, or modify schedules. Newly added devices, devices removed from ITM, new components added to existing devices, or components removed from existing devices are synchronized as a part of this operation. The status of the last discovery is available at IP Telephony Monitor > IP Phone Information Facility > Collection Status.
In addition, IP Phone Information Facility performs periodic polling of the switch ports and Cisco CallManagers to get status information about the phones. This polling interval is set to five minutes. You cannot change this.
Using IP Phone Information Facility to Run Queries
IP Phone Information Facility can be used to run a query on the current inventory of IP phones. You can use the basic find to query based on the directory number, IP address or the MAC address. Alternately you can run an advanced find to query based on the phone type, Cisco CallManager details, switch details, VLAN details, SRST details (SRST or non-SRST mode) or phone status.
IP Phone Information Facility Reports
IP Phone Information Facility provides the following reports:
•
•
•
The data in each of these reports can be printed or exported. The export options available are PDF and CSV.
IPT Security Displays
Note
IPT Security Displays provide the following reports:
•
•
•
•
In addition to generation of these reports based on user request, there is also a mechanism to automatically generate these reports every midnight and store them in a user specified location. These reports will be incremental in nature. This means that the report generated this midnight will only have the change in information from last midnight's report.
The IPT Security Display reports are generated once every 24 hours. They are created in PDF format and stored on the ITM system. When the file is created, the date and time stamp of the file is used to name the file. The filename format is typeofreport_date_time.
Note
IP Phone Reachability Testing
The IP Phone Reachability Testing feature of ITM ensures the reachability of IP phones from two different places in the network. The first place is from ITM itself, and the second is from the router nearest to the Cisco CallManager to which the phone under test is registered. The ping from ITM uses ICMP, while the ping from the router is achieved by using an IP SLA icmpEcho study.
If either of the pings fails, a PhoneReachabilityTestFailed event is raised on the IP phone being tested, and is captured in the Alerts and Activities display.
IP Phone Reachability Testing does the following:
•
•
•
Technology Under IP Phone Reachability Testing
IP Phone Reachability Testing tests the reachability of phones in the network using a triangulation procedure. IP Phone Reachability testing performs the following:
•
•
•
Figure 6 diagrams the triangulation concept behind Phone Reachability testing.
Figure 6 Triangulation Concept of Phone Reachability
IP SLA echo tests will be set up between the designated router and the target IP phone to detect reachability of the IP phone from the designated router. This test is configured by default to send one packet to the destination and await its arrival. It is important that the designated router which acts as the source for the IP SLA tests is chosen with care. If a wrong router (or an unsuitable router) is chosen as the source, the IP SLA based test will not be able to predict the reachability between the IP phone and the Cisco CallManager cluster accurately and this might lead to false alerts or not generating alerts when the IP phones lose contact with the Cisco CallManager cluster. It is strongly recommended that the default gateway of the Cisco CallManager be chosen as the designated router to act as the source for the IP SLA tests. This will ensure that the IP phone reachability can be accurately extrapolated based on the IP SLA tests.
In addition to the IP SLA based test, an optional test you can set up is to ping the IP phone from the ITM server itself. This will tell you if the ITM server is able to reach the phones or not.
Setting Up Phone Reachability Tests
Before you set up the IP SLA tests, ensure that you have enabled the IP SLA agent on the routers under test. For instructions on enabling the IP SLA agent, see Setting up IP SLA on Cisco IOS Devices.
The IP SLA tests for monitoring the phone reachability is set up using a seed file. The format of the seed file is as follows:
3110:0008a3d313a2:10.76.27.83:10.76.30.82:public:privateWhere:
•
•
•
•
•
The seed file for phone reachability tests should be located in the CSCOpx\ImportFiles directory only. A maximum of 1000 tests can be configured. Keep in mind that you can only define phones that have already been discovered by the IP Phone Information Facility. In other words, if it shows up in one of the phone reports.
As a part of setting up the phone reachability tests, you are also allowed to specify how often you want to run these tests and set up a time window for their execution. A maximum of 16 hours a day can be specified as the execution time window for these tests.
If the IP address of the specified phone is changed later on by the administrator, then the tests are automatically changed to point to the new IP address. This is automatically done because the IP Phone Reachability Testing is in communication with the IP Phone Information Facility and whenever the IP address of the phones known to IP Phone Information Facility changes, the phone reachability tests are automatically modified.
One can also specify the IP phones not known to ITM. However, for such phones, if the IP address is changed then there will be no automatic tracking and update. The tests will fail and you will see alerts in the Alerts and Activities display.
If three consecutive IP SLA tests fail, an alert is generated and shown on the Alerts and Activities display. Additionally, if the ITM-based ping is also enabled, the first failure of the ITM-based ping will trigger the generation of the alert. The alert is cleared when both the tests (from ITM as well as from the IP SLA test) are successful.
Managing IP Phone Reachability Testing
The Phone Reachability Testing Manager window is launched from IP Telephony Monitor > IP Phone Reachability Testing > Phone Reachability Testing Manager. It displays all the currently configured IP SLA studies between the designated router and the different IP phones. For every study, it gives the name of the seed file, and the current status of the IP SLA tests (whether they are active or not). From this window, you can perform administrative operations like adding more studies, modifying the existing ones, deleting studies and viewing the configuration of the studies. When you click on the View button, a report is launched with all the necessary details regarding the IP SLA study (the source router, the target IP phone directory numbers, frequency of the tests and the execution schedule).
Unlike SRST Monitoring, IP Phone Reachability Testing cannot be suspended. Also, if the source router on which the IP SLA icmpEcho tests were configured is suspended from the Detail Device View, the phone reachability tests will not be suspended.
Optional Add-On Modules
This section describes the optional drop-in modules that are part of the ITEM suite of products. These modules can be downloaded from Cisco.com.
This section describes the following:
IP Help Desk Utility
The CiscoWorks IP Phone Help Desk Utility (IPHDU) is an optional, Microsoft Windows application that provides help-desk personnel with operational status and implementation details about individual IP telephones without having to go to the Cisco CallManager or other CiscoWorks tools. The IPHDU works in conjunction with the IP Phone Information Facility to make Cisco IP telephone installation details available to help-desk personnel. Access is read-only.
IPHDU is a Windows-based application that resides on the Windows taskbar. It can be turned on by right clicking on the windows task bar and enabling the IP Phone Search Band toolbar.
During the installation of IPHDU, you will need to provide the location of the ITM installation in the network and the credentials to log in to the server.
The data you can see from IPHDU depends on the permissions of the username you set up to interact with the ITM server. If the hostname or IP address of the ITM server changes, or you wish to use IPHDU to work with a different ITM server, you will need to reinstall the application and provide the new credentials.
If you are using IPHDU in a multi-view environment, the username you provide during installation is used to associate a view (partition) to your request, and data relevant to that partition is displayed. If you query a phone that is not present in that partition (the phone is not connected to a switch in that partition), you will not be able to retrieve its data.
IPHDU uses HTTP-based calls to retrieve the data from the ITM servers. It uses the credentials provided during installation to gain secure access to the data within ITM. The data retrieved depends on the level of access available for the supplied credentials. A given installation of IPHDU can only communicate with one instance of ITM. If you want to change the ITM server you are retrieving the data from, you will need to reinstall the IPHDU application. There is no limit on the number of IPHDU installations that can point to an ITM server. However, an ITM server can serve up to a maximum of ten simultaneous requests from different IPHDU installations. The eleventh request will be rejected and an error message informing you that the server is busy is displayed.
Gateway Statistics Utility
The CiscoWorks Gateway Statistics Utility (GSU) is an optional part of the CiscoWorks ITEM suite that can be installed on the ITM system. It is a web-based application that collects key performance and behavior statistics about Cisco CallManager, Cisco CallManager-controlled Gateways (MGCP Gateways), and Cisco IOS software-based IP telephony gateways. This performance information can be processed by tools, such as HP OpenView Performance, or Insight's Report Pack for Cisco IP Telephony Statistics, to produce meaningful utilization and capacity management reports.
Once installed, GSU can automatically capture and record performance and capacity management metrics for a managed IP telephony implementation. GSU is not dependent upon the existence of ITM for its data collection. You can install GSU on a separate system from ITM. In this case, you must install CiscoWorks Common Services 2.2 from the ITM installation CD and then load the GSU application.
GSU Installation
GSU can be installed on a standalone server or on the ITM server. If you are installing it on an ITM server, you will only need to install the GSU component. During the install, you will need to specify a password for the database, and also point GSU to the location where the study data will be stored.
If you are installing GSU on a standalone server, the same hardware requirements as ITM apply. In this case, you will first need to install Ciscoworks Common Services 2.2 from the ITM installation CD. After the successful installation of Ciscoworks Common Services 2.2, you will need to install the GSU component.
GSU Initial Setup and Device Discovery
Two operations need to be performed before GSU can start collecting performance and capacity data on the gateways.
The first of the two is the device discovery operation. The objective of this operation is to let GSU know of the different Cisco CallManager and Gateway devices that it needs to monitor. The devices can be imported using a seed file. The seed file needs to contain information about the device name, type of device, if it is a Cisco CallManager, the IP address of the web server in that cluster, the software version on that device (Cisco CallManager version/Cisco IOS version). A sample format of the device seed file is given below.
172.20.118.6,GW,3661Ac, 12.2(8)T,172.20.118.8,GW/GK,AS5400,12.2(8)T,SJDPA1.cisco.com, DPA,7630,1.1,myCCM1.cisco.com, CCM, ICS, 3.3,172.20.118.5, CCM, , 3.3, 172.20.118.20You can initiate the device discovery by going to Gateway Statistics > Device Import. Once the devices have been discovered you would need to enter the device credentials so that GSU can poll data from the devices. This can be done by going to Gateway Statistics > Device Credentials. For network devices like Cisco IOS based gateways, gatekeepers, and DPAs, you would need to enter the SNMP read community string. For the Cisco CallManagers, you would need to enter the administrative username and password.
Once both the operations have been completed, you can look at the device summary to verify that the device import operation is complete and successful. To launch the device summary, go to Gateway Statistics > Device Summary.
Defining and Managing Studies in GSU
A study is a mechanism to select a set of devices and let GSU poll them to collect capacity and performance data. The essential components of a study are the device set, the polling interval, when to run the study and how frequently to run. GSU supports only one study in the current release. Any time you need to make changes to a study, you will need to stop it, make changes to it and then restart it again. Once a study has been defined, if any of the devices in the study cannot be polled, an error will be logged. If any of the devices are removed from the GSU inventory, GSU will stop polling that device as a part of the study. Every study causes the creation of a folder that is given the name of the study under the directory specified for data storage (which is configured as a part of the installation). Under this folder are three files related to the study, StudyInfo.txt (this gives basic information about the study), StudyAudit.txt (this gives information about devices that were added or removed after the study was defined), and StudyError.txt (this gives information about any errors encountered when polling the data). In addition one file is created for every device in the study and this file stores the results of the collected data. Results are stored as records and every record has 38 fields. There are different types of records and they store different types of information. More details on the record types and what they mean can be found in the user guide document available on Cisco.com at the following location:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itemgsu/gsuguide/records.htm
Reporting Options in GSU
GSU is purely a data collection tool. Users of GSU set up studies, and GSU polls the data from the devices and saves them in a text file in CSV format on the hard disk. Users can use Tactical Graphics Utility (see Tactical Graphics Utility) for reporting and charting.Tactical Graphics Utility (TGU) can be used for real time charting and it plots charts using only the last 72 hours of data from any given point. It also provides a minimal set of graphs. Users can also use third-party tools for reporting and charting. The schema of the data files is published on Cisco.com and is available at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itemgsu/gsuguide/records.htm
Cisco has partnered with HP to offer a charting/trending tool for these reports. As a part of HP Performance Insight, a report pack for IP telephony is available and this report pack has the intelligence to read the GSU data files and create numerous charts. More information on the HP charts and the report pack can be found at
http://www.openview.hp.com/products/ovpi/ds/ovpi_rp_ip-telephony_ds.doc
Data Collected by GSU
Data collected by GSU depends on the device being monitored. Table 8 lists the data collected for a particular device.
WAN Performance Utility
The CiscoWorks WAN Performance Utility (WPU) is an optional part of the CiscoWorks ITEM suite that can be installed on the ITM system. It is a web-based application that collects key performance statistics like jitter, latency, packet loss, etc. on WAN links. The collected information is exported in the form of a 38-field record format and can be processed by Tactical Graphics Utility (TGU).
Once installed, WPU provides you an option to define multiple types of IP SLA tests that capture the performance of the WAN links to the remote offices. Once these studies are defined, WPU can automatically capture and record performance metrics. WPU is not dependent upon the existence of ITM for its data collection. You can install WPU on a separate system from ITM. In this case, you will need to install CiscoWorks Common Services 2.2 from the ITM installation CD and then load the WPU application.
WPU Installation
WPU can be installed on a standalone server or on the ITM server. If you are installing it on an ITM server, you will only need to install the WPU component. During the install, you will need to point WPU to the location where the study data will be stored.
If you are installing WPU on a standalone server, the same hardware requirements as ITEM apply. In this case, you will first need to install CiscoWorks Common Services 2.2 from the ITM installation CD. After the successful installation of CiscoWorks Common Services 2.2, you will need to install the WPU component. If you already have a standalone GSU server, you can install the WPU component on the GSU server as well. There are no coexistence issues between GSU and WPU.
WPU Initial Setup and Device Discovery
Before you start using WPU, you will first need to import sources into WPU. The source is nothing but a Cisco router that has the necessary software image that will support IP SLA operations. To that extent, it is no different from the notion of a device within ITM. The only way to import sources into ITM is through a seed file. The objective behind importing the sources is to let WPU know about the necessary credentials of the routers so that WPU can configure the IP SLA tests.
The seed file needs to contain information about the device name/IP address, SNMP read community string, and SNMP write community string. A sample format of the device seed file is given below.
172.20.118.6, public, private172.20.118.8, public, privatehq-core-7200.cisco.com, read, writehq-remote-2600.com, public, privateIf your ITM seed file has both the read community string and the write community string for your routers, you can extract that portion of the seed file and use it to import sources into WPU. Alternately you can even use the Resource Manager Essentials (RME) export version 2.0 format to import sources into WPU.
Once the sources have been imported, you can look at the source summary to verify that the device import operation is complete and successful. To launch the source summary, go to WAN Performance > WPU Device Management > Source Summary. The report provides details like the device name, its current state, Cisco IOS software version, and the IP SLA agent version. Studies can be configured only on those sources that are in the Known state, so ensure that all your sources are in the Known state before you try to configure studies on them.
You will not be able to delete a device if it is a part of any study. If you need to delete a device, ensure that it is not a part of any study before you attempt to delete it. If you need to change the credentials of a device, go to WAN Performance > WPU Device Management > Edit Sources and select the corresponding source and edit the credentials.
If, for any reason, the device cannot be discovered (for example, if the device is down or the credentials are insufficient), the device is moved into the Questioned state. WPU has a mechanism wherein it will try again to discover a device in the Questioned state, so that the device can be moved to the Known state.
Only devices that have an IP SLA version later than 2.1.0 are supported in WPU. If you import a device with an earlier IP SLA version, the device will be moved into the Unsupported category.
Defining and Managing Studies in WPU
The essential components of a study are the devices (source and target), the type of IP SLA test to be executed within the study, optional advanced configuration, when to run the study and how frequently to run. WPU supports up to 64 studies to be run concurrently. Any time you need to make changes to a study, you can edit the study to reflect the necessary changes. Subsequent operations will be performed with the new configuration. Once a study has been defined, if the source device cannot be polled to collect performance data, an error will be logged.
Every study causes the creation of a folder that is given the name of the study under the directory specified for data storage (which is configured as a part of the installation). Under this folder is one file related to the study, StudyInfo.txt (this gives basic information about the study), and the rest are files corresponding to the study data. One file is created for every day of operation of the study and this file stores the results of the collected data. Results are stored as records and every record has 38 fields. There are different types of records and they store different types of information. More details on the record types and what they mean can be found in the user guide document available on Cisco.com at the following location:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itemwpu/wpu_20/useguide/datafmts.htm
WPU Reporting Options
WPU is purely a data collection tool. Users of WPU set up studies, and WPU polls the data from the devices and saves them in a text file in CSV format on the hard disk. Tactical Graphics Utility (see Tactical Graphics Utility) does minimal reporting and charting of the data collected by WPU. You can also use 3rd party tools for reporting. To facilitate this, the schema of the data files is published on Cisco.com and is available at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itemwpu/wpu_20/useguide/datafmts.htm
IP SLA Tests Performed by WPU
For each of these tests, advanced configuration can be specified. To know more about relevant advanced configuration see the WPU documentation check the user guide available at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itemwpu/wpu_20/useguide/mngstudy.htm#wp1221290
WPU supports the following IP SLA tests on different sources:
•
•
•
•
•
•
•
•
•
Note
Tactical Graphics Utility
The CiscoWorks Tactical Graphics Utility (TGU) is an optional part of the CiscoWorks ITEM suite that can be installed on the ITM system. It is a web-based application that allows you to select and examine changes in network performance metrics. You can select, display, and chart network performance data in real time.
Once installed, TGU provides you with the ability to display and graph output source files generated by WPU and GSU. TGU is not dependent upon the existence of ITM for its data collection. You can install TGU on a separate system. In this case, you will need to install CiscoWorks Common Services 2.2 from the ITM installation CD and then load the TGU application.
TGU Installation
TGU can be installed on a standalone server or on the ITM server. If you are installing it on an ITM server, you will only need to install the TGU component. During the install, you will need to point TGU to the location where the study data for GSU and WPU is stored.
If you are installing TGU on a standalone server, the same hardware requirements as ITM apply. In this case, you will first need to install CiscoWorks Common Services 2.2 from the ITM installation CD. After the successful installation of CiscoWorks Common Services 2.2, you will need to install the TGU component. If you already have a standalone GSU or WPU server, you can install the TGU component on the GSU or WPU server as well. There are no coexistence issues between TGU, WPU, or GSU.
Setting Up TGU
Before you start using TGU, you will first need to create views. Once views are created you need to activate them. A total of 32 views can be created. The views define the various parameters that are required for graphing or charting.
A view defines the following:
•
•
•
•
•
•
Table 9 and Table 10 show the various record types available in GSU/WPU, and which can and cannot be graphed using TGU.
Using the Tactical Graphics Utility Display
The Tactical Graphics Utility display provides real-time information through the use of graphs. Three types of graphs are available: line graph, bar graph and area chart. The information also can be displayed in a tabular format. The graphs display information for specific selected performance metrics; i.e. Views. The display is designed to be set up and left running, providing an ongoing monitoring tool that signals you when something needs attention. Only the last 72 hours of data will be graphed at any given point of time. Using the slide bar at the bottom of the graph you can control the time window e.g. 4, 8, 16, 24, 48 & 72 hours. To launch TGU Display go to Tactical Graphics > Tactical Graphics Utility.
Note
To include a view in the Tactical Graphics Utility display, you must first activate it. When you activate or deactivate a view, your changes are shown in the Tactical Graphics Utility display when the view is refreshed (every two minutes). If you deactivate a view, it is removed from your Tactical Graphics Utility display when the view is refreshed. The deactivated view can be reactivated from the Tactical Graphics Utility: View Management page. A Tactical Graphics Utility display may contain a maximum of 20 active views.
Best Practices
This section covers the following:
•
•
•
•
•
•
Troubleshooting Discovery-Related Issues
Discovery of a device within ITM is a complicated process with different embedded collectors looking to collect different pieces of information through multiple means (SNMP, HTTP). That being said, if all the necessary instructions (as mentioned in earlier sections) have been followed, the device gets discovered pretty quickly. The actual discovery time for a given device varies based on the number of other devices being concurrently discovered, the composition of the device (ports, cards, and interfaces in the device), the SNMP and IP response times, and other such factors.
When discovery is being performed on the device, the device remains in the Learning state. During this time, if you feel that the process is being very slow, be patient. At this point we do not know if it is an issue with the device configuration, the response times, or an internal error within ITM. It is important to wait for the device to reach a stable state (Aware, Known, Unknown, or Questioned). If you delete the device at this point and try to add it again, internally ITM does not abort the previous discovery, and hence the new discovery will start only after the currently running discovery concludes. Hence it is not recommended to delete a device that is currently in the Learning state.
Device discovery within ITM is a nonlinear process. For example, in discovering 1000 devices (which takes about 2-1/2 hours to 3-1/2 hours on Enterprise Edition), devices will be displayed in the Learning state for at least the first 2 hours. Devices will start transitioning over to the Known state only in the last 45 minutes or so. Once the transition to the Known state starts, the process is very rapid.
You should use the user interfaces within Device Management to check on the progress of the device discovery to ensure that progress is being made. If the SNMP response times of the device are slower than the timeout values for the discovery process, the device will reach the Questioned state and the cause will be listed as timeout. At this point you can either fix the issue that is causing the slow response times or change the timeout and retries parameters for the discovery process.
If the failure to discover the device is due to any other cause, then it is important to run through the device setup again to ensure that all the instructions have been followed. In most of the cases, the failure to discover the device is caused by incorrect or insufficient configuration of the device.
Sensitivity to Available Memory and CPU Headroom
The performance and response of any system depends on the available headroom in the CPU as well as the available memory. This is true for ITM as well. The server configuration listed for the server sizing is the minimum recommended configuration. It is always advisable to have a better equipped system than the minimum recommendation. If you intend to maintain a large inventory, it is advisable to have at least 2 GB and preferably 4 GB of RAM. Beyond this point addition of RAM does not make a big difference. It will help if you have a stronger processor. Try getting a Pentium IV 3 GHz instead of a Pentium IV 1 GHz. Alternately, you can consider getting a multiple processor server instead of a single processor server.
HP Proliant DL 320 is a good entry-level server for small inventories (under 750 devices) and HP Proliant DL 380-G3 would be a typical server to consider for large inventories (over 750 devices). More information on these servers can be found at http://h18004.www1.hp.com/products/servers/platforms/index-dl-ml.html
Multi-View Discovery Recommendations
When working with ITM Multi-View, it is recommended that the discovery of the devices be carried out while they are in the default partition (P0), and that they be moved to their respective partitions only after the discovery is complete.
Discovering devices as well as moving them between partitions can cause significant CPU consumption and hence it is advisable that these operations be performed consecutively rather than simultaneously. Discovering devices in partitions other than the default partition will cause the SNMP polling for discovery to conflict with the SNMP polling for monitoring and this will cause the overall system to slow down and hence negatively affect device discovery times.
Identifying CPU-Intensive Operations
The overall performance of any software depends on the amount of CPU processing time it can garner for its processes. This is true for ITM as well. One of the steps you can take to ensure reasonable response time is to make the ITM server exclusive to the use of ITM only. Do not install any unnecessary software that will result in reduced CPU and memory headroom for ITM.
Even if you have a dedicated server only for ITM, you will need to be careful in performing certain tasks within ITM during peak hours of the day. Some of these tasks can cause considerable CPU usage and this will mean that the primary task of ITM (which is monitoring your network and letting you know of faults and alerts) is forced to take a back seat. The following section outlines some of these operations and recommendations on when is a good time to perform such operations.
Any time the CPU consumption stays high for an extended period (over 30 seconds) the confidence tests that are scheduled to run during those times are not run. This will affect the monitoring of your network. If confidence tests are not run for extended periods, then an alert will show up in the Alerts and Activities display.
Rediscovery Schedules
This feature is responsible for running periodic rediscoveries (once every week, by default) to ensure that new hardware/software components in devices are automatically discovered and monitored. It is configured to run early in the morning, at 2.00 A.M. It is recommended to change the default schedule or add another schedule to rediscover the devices more frequently (preferably on a daily basis). When you do that, be careful to ensure that the start time of the discovery is during off-peak hours (preferably the same time as the default: 2.00 A.M). Rediscovery of devices can consume significant CPU resources for long periods, especially if you have a large inventory (based on the testing performed at Cisco, rediscovering 1500 devices takes almost 4.5 hours). During this time, confidence tests may not be executed due to lack of CPU resources, and fault/event processing might be affected. Ensure that you do not have confidence test schedules overlapping rediscovery schedules.
Apply Changes
Apply Changes is an operation you will need to perform after making changes to polling and threshold settings on different device groups. If you are changing multiple polling and threshold settings, ensure that you complete all the changes before you apply your changes. You will also need to apply changes when you resume monitoring a device.
Apply Changes is a CPU intensive operation and this causes the CPU consumption to stay high for up to five minutes. Again, it depends on the size of the inventory you have. However, it is best if such operations are performed during off peak hours.
Device Management Operations
Most device management operations (add, rediscover, and change credentials) either individually or in bulk, causes high CPU activity due to the internal data collection server reconfigurations. These operations should be reserved for off-peak hours.
High Event Throughput Conditions
A high fault rate on the same device can cause the internal event/alert database to build up over time. In these cases, alerts do not get a chance to expire and get purged off the database. Any fault rate (whether high or low), but recurring on the same set of devices, can cause the internal event database to build up. The rule of thumb is to be on the alert for devices with recurring failures (not necessarily the same type of failure) at intervals of less than 2-1/2 hours. This situation has the potential to create long-term performance problems in ITM. The build of the event/alert database can eventually stress both system CPU and memory. Such situations are best handled by fixing the underlying problems in the managed network quickly.
Simultaneous Operations by Multiple Users
ITM supports up to 10 users simultaneously accessing it and performing operations on it. However, since all the applications within ITEM reside on the same server and compete for the same CPU, care needs to be exercised when performing CPU intensive operations. If all the users are performing read operations (like using the Alerts and Activities display, configuring confidence tests, defining views, or setting up notification profiles) there will be no conflict. However if one of the users is trying to perform a write operation (like discovering and rediscovering devices, applying changes, etc.) it will affect the response times and user experience for all the current users.
It is recommended that all CPU intensive operations be consolidated and be performed only during off peak hours to create the least possible impact on the system.
Daily Use Scenarios (using ITEM in your network)
This section describes a few of the symptoms in a typical IP Telephony environment and shows how ITEM features can be used to detect, diagnose, and address the symptoms.
Note
The following symptoms are diagnosed:
•
•
•
Delay in Getting Dial Tone or Not Getting Dial Tone At All
Do the following:
1.
2.
3.
4.
5.
6.
7.
IP phone Not Booting
Do the following:
1.
2.
3.
4.
Unable to Call an IP Phone
Do the following:
1.
2.
3.
4.
Bad Voice Quality in a Call
Do the following:
1.
2.
3.
4.
5.
Unable to create/join a conference
Do the following:
1.
2.
3.
Ensuring the Availability of a Key Phone
Do the following:
1.
2.
3.
4.
Branch Office in SRST Mode
Do the following:
1.
2.
3.
4.
5.
Post Installation Checklist
Use the following checklist to ensure that all aspects of your deployment is complete and that you are ready to use ITEM.
Appendix
For a list of all the possible events displayed in the Alerts and Activities display and their description, see the ITM documentation on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itm/itm_20/userguid/events.htm
For information about the ITM support host resources MIB and ITM implementation of system application MIBs, see the ITM documentation on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itm/itm_20/userguid/snmpagt.htm
For information on ICMP and SNMP polling done by ITM and SNMP version supported in ITM, see the ITM documentation on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itm/itm_20/userguid/snmpinfo.htm
For the list of MIBS polled by ITM, see the ITM documentation on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itm/itm_20/userguid/trapmibs.htm
For a list of the processed and pass-through traps and other unidentified traps and events, see the ITM documentation on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itm/itm_20/userguid/trapfwd.htm
For information on how ITM calculates repeated restarts and flapping, see the ITM documentation on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/itm/itm_20/userguid/flapping.htm
Guest
