User Guide for Cisco Unified Operations Manager 2.0.3
Using Node-To-Node Tests
Downloads: This chapterpdf (PDF - 273.0KB) The complete bookPDF (PDF - 23.65MB) | Feedback

Using Node-To-Node Tests

Table Of Contents

Using Node-To-Node Tests

Working with Node-To-Node Tests

Getting Started: Required Cisco IOS and IP SLA Versions

Creating a Single Node-To-Node Test

UDP Jitter for VoIP

Ping Echo

Ping Path Echo

UDP Echo

Gatekeeper Registration Delay

Importing Multiple Tests

Creating a Node-To-Node Test Import File

Formatting Node-To-Node Test Import Files

Editing Tests

Deleting a Test

Node-To-Node Test Events

Managing Test Operations

Viewing Test Trending

Viewing Test Information

Printing Test Details

Exporting Test Details

Verifying the Status of a Test

Working with Test Data

Where Is Node-To-Node Test Data Stored?

Maintaining Node-To-Node Test Data

Copying Test Data to Another Server

What Is the Format of the Node-To-Node Data?


Using Node-To-Node Tests



Note If you do not have the required software license, you will not be able to use node-to-node tests.


Node-to-Node tests monitor the response time and availability of multiprotocol networks on both an end-to-end and a hop-by-hop basis. After collecting this data, you can use the Operations Manager graphing function to examine changes in network performance metrics. You can select, display, and chart network performance data in real time. See Viewing Test Trending. Also, Node-to-Node tests can be configured to trigger events when certain thresholds are crossed. These events appear in the Monitoring Dashboard displays.

This section describes how to create, edit, remove, and analyze Node-to-Node tests in Cisco Unified Operations Manager (Operations Manager).

This section includes the following topics:

Working with Node-To-Node Tests

Managing Test Operations

Working with Test Data

Working with Node-To-Node Tests

You can create Node-to-Node tests one at a time, or you can import a file to create more than one test at a time.


Note If you ever need to uninstall Operations Manager, be sure to delete all the node-to-node tests from the application before you uninstall it. If you do not delete these tests, they will continue to run on the router. For instructions on deleting, see Deleting a Test.


This section includes the following topics:

Getting Started: Required Cisco IOS and IP SLA Versions

Creating a Single Node-To-Node Test

Importing Multiple Tests

Editing Tests

Deleting a Test

Getting Started: Required Cisco IOS and IP SLA Versions

Node-to-node tests rely upon Cisco IOS IP SLA technology. Table 10-1 lists the versions of IP SLA and Cisco IOS that are required to successfully configure and run each type of node-to-node test.

Table 10-1 IP SLA Mapping for Node-to-Node Tests

Test
Required Versions
IP SLA
Cisco IOS

Ping Echo

2.1.0 and higher

12.0(5)T, 12.1(1), and higher

Ping Path Echo

UDP Echo

UDP Jitter for VoIP

Note Without ICPIF/MOS values.

UDP Jitter for VoIP

Note With ICPIF/MOS values.

2.2.0 and higher

12.3(4)T and higher

Gatekeeper Registration Delay

12.3(14)T and higher


To see device families on which node-to-node tests are supported, see Supported Devices Table for Cisco Unified Operations Manager 2.0 on Cisco.com.

Creating a Single Node-To-Node Test

Before you can create a test, the source device must be monitored by Operations Manager. See Using Device Management, page 16-1 for more information.


Note You can also set up Node-to-Node tests from the Service Level View (see Setting Up Node-To-Node Tests, page 2-20).



Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.


Note If you do not have the required software license, you will not be able to use node-to-node tests. The Diagnostic tab will not appear in Operations Manager.


Step 2 Click Create. The information required for creating Node-to-Node tests is different for each test operation type. See the following for details:

UDP Jitter for VoIP—Measures packet loss, round-trip latency, and delay variance (or jitter) in IP networks by generating synthetic UDP traffic.

Ping Echo—Measures end-to-end response time between a source device and any IP-enabled device.

Ping Path Echo—Measures hop-by-hop response time between a source device and any IP device on the network by discovering the path using traceroute, and then measuring response time between the source device and each hop in the path.

UDP Echo—Measures UDP response time between a source device and any IP-enabled device.

Gatekeeper Registration Delay—Measures the time required for a gateway to register with a gatekeeper.


Note For Gatekeeper Registration Delay tests to run, the source gateway must have SIP or H323 configured on it.



UDP Jitter for VoIP

This test uses the UDP protocol to measure latency, one-way jitter, and packet drop. Jitter is interpacket delay. The source device sends a number of packets from the source device to the destination device with a specified interpacket delay. The destination (an IP SLA Responder) time stamps the packet and sends it back. Using this data, the one-way positive and negative jitter (from the source to the destination and back again), packet loss (also from the source to the destination and back again), and round-trip latency are obtained.

Positive jitter occurs when the one-way delay for a packet is longer than the previous packet delay. Negative jitter occurs when the one-way delay for a packet is shorter than the previous packet delay. If the sequence numbers become jumbled, the test reflects the error.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Click Create. The Node-to-Node Test Configuration page appears.

Step 3 In the Test Type pull-down menu select UDP Jitter for VoIP.

Step 4 In the Source pane, do the following:

Using the device selector, select a source device.


Note If you cannot find a recently added device, refresh the device groups. See Troubleshooting Note: Selecting a Source Device.


Select a source interface setting. You can leave it at Default, or enter a new setting.

Step 5 In the Destination pane, do the following:

Using the device selector, select a destination device.

Enter a UDP port for the destination device (the default value is 16400). This is the port on the destination device to which packets are sent by the source device.


Note If you want to switch the source and destination devices with each other, click the Swap Source and Destination button.


Step 6 In the Parameters pane, you can set the following parameters:

Table 10-2 UDP Jitter for VoIP Test Parameters

Parameter
Default Value
Available Values
Description

Codec Type

           —

G.711ulaw

G.711alaw

G.729

Used to determine the packet interval and the request payload.

Call Duration

8

1 - 59 seconds

Time of the call.

Voice Quality Expectation

Land line

Land line

Wireless campus

Wireless on the move

Multi-hop

Corresponds to the Access Advantage factor of Mean Opinion Scores (MOS) and Calculated Planning Impairment Factor (ICPIF).

IP QoS

IP Precedence

IP Precedence

DSCP

Defines the quality of service policies for the IP SLA packets.

5

IP Precedence—0 (none) through 7 (high)

DSCP—0 (none) through 8 (CS1), 9, and 10 (AF11)

This is converted to Type of Service (TOS) and set on the device.


Step 7 In the Threshold pane, you can change the following settings:

Table 10-3 UDP Jitter for VoIP Test Threshold Settings

Parameter
Default Value
Available Values
Description

Source to Destination

3 (packet loss)
40 msec (jitter)

Any positive integer1

Threshold setting for packet loss and jitter.

Destination to Source

3 (packet loss)
40 msec (jitter)

Any positive integer1

Threshold setting for packet loss and jitter.

Average Latency

300 m/secs

Any positive integer1

Threshold setting for latency.

Node-to-Node Quality

Fair

Excellent, Good, Fair, or Poor

Threshold setting for the test's quality. The values are associated with a MOS score. The value and equivalent MOS are as follows:

Excellent—5 (500)

Good—4 (400-499)

Fair—3 (300-399)

Poor—2 (200-299)

Bad—1 (100-199)

1 Positive integers must be 32 bit.


Step 8 In the Run pane configure when the test should run.

If you want the test to run only once, select the Once radio button.

If you want to schedule the test to run at certain intervals, do the following:

Select the schedule radio button.

Choose how often you want the test to run.

Enter the time between which you want the test to run.

Select the days on which the test should run.

Enter a test name. The test name cannot contain tabs, question marks, quotation marks, asterisks, semicolons, commas, colons, forward slashes, straight slashes, or backslashes.

Step 9 Click OK.


Troubleshooting Note: Selecting a Source Device

If you recently added an IP SLA-enabled device and it does not appear in the IP SLA Devices group in the selector in the Source pane on the Node-to-Node Test Configuration dialog box, refresh the device group membership.


Step 1 Select Devices > Device Groups. The Group Administration and Configuration page appears.

Step 2 In the Group Selector, select the OM@<server> group where <server> is the name of your server.

Step 3 Click the Refresh button. A confirmation dialog box appears.

Step 4 Click Yes. A progress bar appears. A success message is displayed.

Step 5 Click OK.

Step 6 If it is open, close the Node-to-Node Test Configuration dialog box. When you open it again, refreshed device groups are displayed in the Source pane.


Ping Echo

This test measures end-to-end latency information using ICMP. The test sends ICMP packets from the source device to the destination device and measures the time it takes to complete the round trip.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Click Create. The Node-to-Node Test Configuration page appears.

Step 3 In the Test Type pull-down menu select Ping Echo.

Step 4 In the Source pane, do the following:

Using the device selector, select a source device.


Note If you cannot find a recently added device, refresh the device groups. See Troubleshooting Note: Selecting a Source Device.


Select a source interface setting. You can leave it at Default, or enter a new setting.

Step 5 In the Destination pane, using the device selector, select a destination device.


Note If you want to switch the source and destination devices with each other, click the Swap Source and Destination button.


Step 6 In the Parameters pane, you can set the following parameters:

Table 10-4 Ping Echo Test Parameters

Parameter
Default Value
Available Values
Description

Request Payload

32 bytes

28 to 16384 bytes

A default ICMP Ping packet has 32 bytes. Allows for variably sized operations.

IP QoS

IP Precedence

IP Precedence

DSCP

Defines the quality of service policies for the IP SLA packets.

0 (none)

IP Precedence—0 (none) through 7 (high)

DSCP—0 (none) through 8 (CS1), 9, and 10 (AF11)

This is converted to TOS and set on the device.

Show Link in Service Level View

Not selected

Displays this test as a virtual link in the Service Level View.


Step 7 If you want to change the Round-Trip Response Time Threshold, in the Thresholds pane, select the check box and enter a new setting (default is 300 m/secs). The setting must be a positive integer (32 bit).

Step 8 In the Run pane configure when the test should run.

If you want the test to run only once, select the Once radio button.

If you want to schedule the test to run at certain intervals, do the following:

Select the schedule radio button.

Choose how often you want the test to run.

Enter the time between which you want the test to run.

Select the days on which the test should run.

Enter a test name. The test name cannot contain tabs, question marks, quotation marks, asterisks, semicolons, commas, colons, forward slashes, straight slashes, or backslashes.

Step 9 Click OK.


Ping Path Echo

This test measures hop-by-hop latency information using ICMP Ping and traceroute.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Click Create. The Node-to-Node Test Configuration page appears.

Step 3 In the Test Type pull-down menu select Ping Path Echo.

Step 4 In the Source pane, do the following:

Using the device selector, select a source device.


Note If you cannot find a recently added device, refresh the device groups. See Troubleshooting Note: Selecting a Source Device.


Select a source interface setting. You can leave it at Default, or enter a new setting.

Step 5 In the Destination pane, using the device selector, select a destination device.


Note If you want to switch the source and destination devices with each other, click the Swap Source and Destination button.


Step 6 In the Parameters pane, you can set the following parameters:

Table 10-5 Ping Path Echo Test Parameters

Parameter
Default Value
Available Values
Description

Request Payload

32 bytes

28 to 16384 bytes

A default ICMP Ping packet has 32 bytes. Allows for variably sized operations.

IP QoS

IP Precedence

IP Precedence

DSCP

Defines the quality of service policies for the IP SLA packets.

0 (none)

IP Precedence—0 (none) through 7 (high)

DSCP—0 (none) through 8 (CS1), 9, and 10 (AF11)

This is converted to TOS and set on the device.


Step 7 If you want to change the Round-Trip Response Time threshold, in the Thresholds pane, select the check box and enter a new setting (default is 300 m/secs). The setting must be a positive integer (32 bit).

Step 8 In the Run pane configure when the test should run.

If you want the test to run only once, select the Once radio button.

If you want to schedule the test to run at certain intervals, do the following:

Select the schedule radio button.

Choose how often you want the test to run.

Enter the time between which you want the test to run.

Select the days on which the test should run.

Enter a test name. The test name cannot contain tabs, question marks, quotation marks, asterisks, semicolons, commas, colons, forward slashes, straight slashes, or backslashes.

Step 9 Click OK.


UDP Echo

This test measures UDP server latency. The UDP echo test sends a packet with the configured number of bytes to the destination with the specified port number and measures the response time. There are two destination device types for the UDP echo operation: RTR Responders, which use IP SLA, and UDP servers, which do not.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Click Create. The Node-to-Node Test Configuration page appears.

Step 3 In the Test Type pull-down menu select UDP Echo.

Step 4 In the Source pane, do the following:

Using the device selector, select a source device.


Note If you cannot find a recently added device, refresh the device groups. See Troubleshooting Note: Selecting a Source Device.


Select a source interface setting. You can leave it at Default, or enter a new setting.

Step 5 In the Destination pane, using the device selector, select a destination device.

Step 6 Enter the UDP port number (the default value is 7) for the destination device to use when sending response packets.


Note If you want to switch the source and destination devices with each other, click the Swap Source and Destination button.


Step 7 In the Parameters pane, you can set the following parameters:

Table 10-6 UDP Echo Test Parameters 

Parameter
Default Value
Available Values
Description

Request Payload

16 bytes

4 to 1500 bytes

Allows for variably sized operations.

IP QoS

IP Precedence

IP Precedence

DSCP

Defines the quality of service policies for the IP SLA packets.

0 (none)

IP Precedence—0 (none) through 7 (high)

DSCP—0 (none) through 8 (CS1), 9, and 10 (AF11)

This is converted to TOS and set on the device.


Step 8 If you want to change the Round-Trip Response Time threshold, in the Thresholds pane, select the check box and enter a new setting (default is 300 m/secs). The setting must be a positive integer (32 bit).

Step 9 In the Run pane configure when the test should run.

If you want the test to run only once, select the Once radio button.

If you want to schedule the test to run at certain intervals, do the following:

Select the schedule radio button.

Choose how often you want the test to run.

Enter the time between which you want the test to run.

Select the days on which the test should run.

Enter a test name. The test name cannot contain tabs, question marks, quotation marks, asterisks, semicolons, commas, colons, forward slashes, straight slashes, or backslashes.

Step 10 Click OK.


Gatekeeper Registration Delay

This test sends a lightweight Registration Request (RRQ) from an H.323 gateway to an H.323 gatekeeper and receives a Registration Confirmation (RCF) from the gatekeeper. The test then measures the response time.


Note For the Gatekeeper Registration Delay test to run, the source gateway must have SIP or H323 configured on it.



Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Click Create. The Node-to-Node Test Configuration page appears.

Step 3 In the Test Type pull-down menu select Gatekeeper Registration Delay.

Step 4 In the Source pane, using the device selector, select a source device.


Note If you cannot find a recently added device, refresh the device groups. See Troubleshooting Note: Selecting a Source Device.


Step 5 If you want to change the Registration Response Time threshold, in the Thresholds pane, select the check box and enter a new setting (default is 300 m/secs). The setting must be a positive integer (32 bit).

Step 6 In the Run pane configure when the test should run.

If you want the test to run only once, select the Once radio button.

If you want to schedule the test to run at certain intervals, do the following:

Select the schedule radio button.

Choose how often you want the test to run.

Enter the time between which you want the test to run.

Select the days on which the test should run.

Enter a test name. The test name cannot contain tabs, question marks, quotation marks, asterisks, semicolons, commas, colons, forward slashes, straight slashes, or backslashes.

Step 7 Click OK.


Importing Multiple Tests

You can import up to 64 tests, the maximum that Operations Manager can support, by importing a seed file.

Before You Begin

Before you can import a test, you must first add the source devices. See Importing Devices into Operations Manager, page 16-14.

Make sure your seed file is formatted correctly. See Creating a Node-To-Node Test Import File for more information.

Place the seed file on the server, in the NMSROOT\ImportFiles directory.


Note NMSROOT is the directory where Cisco Unified Operations Manager is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.



Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.


Note If you do not have the required software license, you will not be able to use node-to-node tests. The Diagnostic tab will not appear in Operations Manager.


Step 2 Click Import. The Import Node-to-Node Tests page appears.

Step 3 In the Seed Filename field, enter the name of the seed file that contains the test information; for example, Node_to_nodetestImport.txt. The file must be located on the server in the directory that is displayed next to the Server Path field name.

Step 4 Click OK.

Operations Manager performs the following actions:

If this is a file you have imported before, Operations Manager checks to see if any of the devices exist in Operations Manager. If all the information in the import file is the same as what already exists in Operations Manager, a message to that effect appears. Click OK.

Operations Manager displays an error message if there are problems with the format of the import file. Click OK, then open the file and correct the listed problems. You cannot import the file until all problems are corrected.

If there are no errors, a confirmation dialog box appears. The dialog box displays the number of new tests created and the number of tests that will be updated. Click Yes.


Creating a Node-To-Node Test Import File

You can import up to 64 tests, the maximum that Operations Manager can support at one time. You can find an example of an import file in the <NMSROOT>\Importfiles folder.


Note NMSROOT is the directory where Operations Manager is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.


For details on formatting test seed files for specific operations, see Formatting Node-To-Node Test Import Files.

All test seed files should have the following information:

Test name

Operation type

Source device name

Destination device information

Operation parameters

Schedule parameters

The general format for a test seed file is as follows:

If you create the import file manually, the import file header must say:

Cisco Systems Node-to-Node test import, version=3.0;type=CSV;source=manual

All values must be separated by commas.

Start and end dates must be formatted as mm/dd/yyyy; for example, 12/01/2004.

Start and end times must be formatted on a 24-hour clock as hh:mm; for example, 23:30.

Entering the source-ip-address is optional. This address is the same as the alternate test address.

Fill in optional fields with double quotation marks; for example, "".

For all days of the week, enter a one; otherwise, it should be a zero. If the entry for all days of the week is zero, then you need to enter the days of the week. Separate the days of the week with a vertical bar (|); for example, Mon|Tue|Thu|Fri.

Formatting Node-To-Node Test Import Files

Ping Echo test

<testName>,Ping-Echo,<source>,<source-ip-address>,<Destination-Name>,<sample-interval>,<IP
QosType><IPQosValue>,<request-payload>,<LSRHop1|LSRop2|LSRHop3|LSRHop4|LSRHop5|LSRHop6|LSR
Hop7|LSRHop8>,<completionTimeThreshold or "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 
for all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>

echo-import1,Ping-Echo,source-1,"",dest-1,1,DSCP,9,64,lsr-hop1|lsr-hop2,300,09:00,17:00,1
echo-import2,Ping-Echo,source-1,"",dest-1,1,IPPrecedence,4,64,lsr-hop1|lsr-hop2,"",09:00,1
7:00,0,mon|tue|wed|fri

LSRHop is an optional field.

Ping Path Echo test

<testName>,Ping-Path-Echo,<source>,<source-ip-address>,<Destination-Name>,<sample- 
interval>,<IPQosType>,<IPQosValue>,<request-payload>,<completionTimeThreshold or ""> 
,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if 
AllDaysOfWeek is 0>

ping-path-import2,Ping-Path-Echo,source-2,"",dest-2,3,DSCP,10,32,250,17:00,23:00,0,mon|tue
|wed|thu|fri
ping-path-import2,Ping-Path-Echo,source-2,"",dest-2,3,IPPrecedence,5,32,"",17:00,23:00,1

UDP Echo test

<testName>,UDP-Echo,<source>,<source-ip-address>,<Destination-Name>,<destination-type>,<sa
mple-interval>,<IPQosType>,<IPQosValue>,<destination-port>,<request-payload>,
<completionTimeThreshold or "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days 
otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>

udp-import1,UDP-Echo,source-1,"",udp-dest,IPSLA-Responder,1,IPPrecedence,4,2001, 
32,300,17:00,23:00,0,mon|tue|wed|thu|fri
udp-import2,UDP-Echo,source-1,"",udp-dest,IPSLA-Responder,1,DSCP,48,2001,32,"", 
17:00,23:00,1

The destination type can be either UDP-Server or IP SLA-Responder.

UDP Jitter for VoIP test

Without Codec (Node-to-Node Quality) Support:

<testName>,Data-Jitter,<source>,<source-ip-address>,<IPSLA-Responder>,<sample-interval>, 
<IPQosType>,<IPQosValue>,<request-payload>,<inter-packet-interval>,<number-of-packets>, 
<destination-port>,<pktlossSDThreshold or "">,<pktlossDSThreshold or "">, 
<jitterSDThreshold or "">,<jitterDSThreshold or "">,<avgLatencyThreshold or "">, 
<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if 
AllDaysOfWeek is 0>

jitter-import1,Data-Jitter,source-1,source-1,dest-with-IPSLA-Responder,3,DSCP,24,64,30,20,
2002,30,30,25,25,50,17:00,23:00,0,mon|tue|wed|thu|fri

WITH Codec (Node-to-Node Quality) Support, valid for IOS version 12.3(4)T or higher:

<testName>,Data-Jitter,<source>,<source-ip-address>,<IPSLA-Responder>,<sample-interval>, 
<IPQosType>,<IPQosValue>,<codecType>,<voiceQualityBenchMark>,<number-of-packets>, 
<destination-port>,<pktlossSDThreshold or "">,<pktlossDSThreshold or "">, 
<jitterSDThreshold or "">,<jitterDSThreshold or "">,<avgLatencyThreshold or "">, 
<nodeToNodeQualityThreshold or "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days 
otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>

jitter-import2,Data-Jitter,source-1,source-1,dest-with-IPSLA-Responder,3,IPPrecedence,5,G.
711ulaw,LandLine,20,2002,30,30,25,25,50,"",17:00,23:00,1

Read-community-string is an optional field. If you specify a community string, Operations Manager validates the IP SLA Responder.

VoIP Gatekeeper Registration Delay test, scheduled daily

<testName>,Voip-GKReg-Delay,<source GateWay>,<sample-interval>, 
<GatekeeperRegistrationTimeThresholdor "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for 
all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>

gkregdelay-import1,Voip-GKReg-Delay,source-gateway,3,50,17:00,23:00,0,mon|tue|wed|thu|fri
gkregdelay-import2,Voip-GKReg-Delay, source-gateway,5,"",17:00,23:00,1

Editing Tests

After you have created tests to Operations Manager, you can change test parameters, or, if you want to remove a test from Operations Manager, you can delete it.

You can use this function to edit the parameters of an existing test. For example, you can change the operation parameters of a test or change the schedule. You cannot change the destination device.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Select the test you want to edit, and then click Edit. The Edit Node-to-Node Test page appears.

Step 3 You can change the test parameters, including scheduling and threshold settings. See Working with Node-To-Node Tests for more information.

Step 4 Click OK when done.


Deleting a Test

You can use this function to delete one or more tests. You can delete tests in any state. See Table 10-8 for a description of possible states.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Select the tests you want to delete, and then click Delete. A confirmation dialog box appears.

Step 3 Click Yes. Operations Manager deletes the tests you selected.


Node-To-Node Test Events

The threshold settings that you set during test creation or during modification determine when a node-to-node event is generated. See Working with Node-To-Node Tests.

The events are raised on the source device. A threshold event is generated when the threshold violation occurs for three consecutive polling cycles. The event is cleared if the value falls below the threshold in the following polling cycle.

The following node-to-node events can be generated:

NodeToNodeTestFailed


Note To determine why a Node-to-Node test failed and how to clear it, see the IP SLA documentation located on Cisco.com at the following locations:

http://www.cisco.com/en/US/products/ps6350/products_installation_and_configuration_guides_list.html

http://www.cisco.com/en/US/products/ps6350/prod_command_reference_list.html


RoundTripResponseTime_ThresholdExceeded

RingBackResponseTime_ThresholdExceeded

RegistrationResponseTime_ThresholdExceeded

AverageLatency_ThresholdExceeded

PacketLossSD_ThresholdExceeded

PacketLossDS_ThresholdExceeded

For details on the node-to-node events, see Events Processed, page E-1.

Managing Test Operations

The following topics discuss these tasks:

Viewing Test Trending

Viewing Test Information

Printing Test Details

Exporting Test Details

Verifying the Status of a Test

Viewing Test Trending

You can select and examine changes in network performance metrics. You can select, display, and chart network performance data in real time. For details on the types of metrics you can graph, see What Metrics Can I Include on a Graph?, page 7-1.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Select the test you want to trend, and click Trend.

If you select a UDP Jitter for VoIP test, a Select Metrics dialog box appears.

a. Select the metrics you want to graph. The metrics must have the same units.

b. Click View Graph.

If you select any of the other tests, a second dialog box does not appear.

A Node-to-Node Test Trend graph appears. For details about working with performance graphs, see How to Use Performance Graphs, page 7-1.


Viewing Test Information

You can find all the details about a particular test on the Test Details page. From this page, you can print or export test information.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Select the test you want to view, and click View. The Test Details window opens.

Table 10-7 explains the contents of the window.

Table 10-7 Test Details 

Field
Description
General Parameters

General information about a test.

Test Name

User-defined test name. Operations Manager also uses the test name to name the folder in which test data is stored. See the description of the Data Directory field in this table.

Operation Type

Type of test operation; for example, Ping Echo.

Source

Name or IP address of the source device.

Source Interface

IP address of an interface on the source device. Can also be listed as Default. In the case of Default, the IP SLA engine in the source device determines the source interface.

IP SLA Responder

Name of the IP SLA-enabled destination device.

Current Status

The status of the test. See Table 10-8 for a description of possible states. The state of the test determines whether you can stop or define the test at any given point. The state also determines the state of the data collection.

If the status is Config Failed, a description of the cause of the failure appears. If the test status is Config Failed or Config Pending, an explanation appears.

Admin Index

Unique numeric identifier for a test on the source device. See the Note following this table for more information.

Data Directory

Directory in which Operations Manager stores test data. The Data Directory name matches the test name. See Where Is Node-To-Node Test Data Stored?.

Schedule Parameters

When and how often the test runs.

Polling Time

The number of hours in a 24-hour period during which polling occurs.

Occurrence Pattern

Dates on which the test starts and ends, and hours during which the test is scheduled to run. If the test runs weekly, the Schedule parameter displays days of the week when the test is scheduled to run.

Operation-Specific Parameters (UDP Jitter for VoIP example)

Information about the specific kind of operation a test is running. The following part of the table is an example of operation-specific parameters for a UDP Jitter for VoIP test. Other test types will have different operation-specific parameters. For information on operation-specific parameters for other operation types, see Creating a Single Node-To-Node Test.

Sample Interval (minutes)

The frequency with which the source device polls the destination device and Operations Manager polls the source device.

Duration

Test duration.

Codec

Used to determine the packet interval and the request payload.

IP QoS Type

The quality of service policies for the IP SLA packets.

IP QoS Value

Quality of service value.

Voice Quality Expectation

Corresponds to the Access Advantage factor of Mean Opinion Scores (MOS) and Calculated Planning Impairment Factor (ICPIF).

Destination Port

The default destination port is 16400.

Threshold Parameters

Threshold settings for the test.

Average Latency

Threshold Setting

Packet Loss Source to Destination

Threshold Setting

Packet Loss Destination to Source

Threshold Setting

Jitter Source to Destination

Threshold Setting

Jitter Destination to Source

Threshold Setting

Node-to-Node Quality

Threshold Setting



Note While the test is the Running state, you can view test information directly on the source device. Telnet to the source device and use the command show rtr configuration <admin index>.



Printing Test Details

You can print all the details about a test shown on the Test Details page.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Select the test you want and click View. The Test Details window opens.

Step 3 To print the test details information, click the printer icon in the upper-right corner of the window.

The records are reformatted into a print-friendly format and are displayed in a new browser window.

Step 4 Use the print function on your browser to print the display.


Exporting Test Details

You can export and save all the details about a single test as shown on the Test Details page, including configuration and status. This is not the same thing as exporting the data gathered by a test. To see how to save and export data gathered by a test, see Copying Test Data to Another Server.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears.

Step 2 Select the test you want and click View. The Test Details window opens.

Step 3 To export the test details information, click the export icon in the upper-right corner of the window. Select either CSV or PDF format for export and click OK.

Step 4 If you chose CSV in Step 3, do the following:

a. When the File Download dialog box appears, click Save.

b. In the Windows folder window, enter the filename and the location where you want to save the file.

c. Click Save.

d. In the Download Complete dialog box, click Close.

Step 5 If you chose PDF in Step 3, do the following:

a. If a security information dialog box appears, click Yes. The records now appear in PDF format.

b. Use the PDF save function to save the file to your system.


Verifying the Status of a Test

You can verify whether a test ran and completed correctly. You can also troubleshoot the test if necessary.


Step 1 Select Diagnostics > Node-to-Node Tests. The Node-to-Node Tests page appears. All current Node-to-Node tests appear in the page. The last column in the table shows the status of each test.

Table 10-8 Test Status Definitions

Test Status
Description

Running

The test is active and collecting data.

Config Pending

Either the device is not responding or configuration of the test is under way.

Delete Pending

Intermediate state, before the test is deleted. No actions can be performed on the test.

Suspended

The test is suspended from data collecting or polling. This occurs because the device was suspended.

Scheduled

Appears after you create or update a test. The status will change to Running at the first polling cycle.

Dormant

The test is active but not currently collecting data. Tests are in the Dormant state between polling cycles.

Config Failed

The test was not configured correctly. Possible problems include incorrect device credentials or low device memory. You can see more information on why the test configuration failed by viewing the Study Details page.



Working with Test Data

Operations Manager saves the data collected by tests to disk.

The following topics provide information you will need to use the data, keep the data safe, and prepare to run additional tests:

Where Is Node-To-Node Test Data Stored?

Maintaining Node-To-Node Test Data

Copying Test Data to Another Server

What Is the Format of the Node-To-Node Data?

Where Is Node-To-Node Test Data Stored?

Node-to-node test data is stored on the Operations Manager server in the NMSROOT\data\N2Ntests folder.


Note NMSROOT is the directory where Operations Manager is installed on your system. If you selected the default directory during installation, it is C:\Program Files\CSCOpx.


Table 10-9 shows the two different types of files stored in the data storage directory.

Table 10-9 Test Data Files and Log Files

File Names
Contents

YYYYMMDD.csv

The test data. Each file has multiple records. Each record is a comma-separated values (CSV) record, and there is one record in a file for each polling interval.

StudyInfo.log

The log includes test name, description, polling interval, devices, start date, end date, operation type, polling interval, and status.


Maintaining Node-To-Node Test Data

You should perform all tasks related to maintaining test data, including the following:

Verify that there is sufficient disk space to store test data. Check disk space before a test is scheduled to run. Operations Manager appends data to a test's log files. Operations Manager produces one data file for each running test per day when a test is running. Assess the amount of space used by previous tests to derive an estimate.

For example, a test with a 16-hour polling cycle and a 1-minute sampling interval uses approximately 60 to 100 KB per day. A path echo test with a 16-hour polling cycle, a 1-minute sampling interval, and 12 hops uses approximately 1.2 MB per day.

Export and save test data. Operations Manager purges all data files more than 31 days old. You must save the test to another server to maintain data for more than 31 days. See Copying Test Data to Another Server.

Back up the test data. Operations Manager writes test data to the Data Storage Directory, displayed in the Test Details window. Perform regular backups using the same method you use to back up your file system.

Determine when to copy data to another server. You should copy test data to another server before you examine it.

Display and use the data. You can analyze the results of the test after you import the test data into Microsoft Excel or by using a third-party report-generating tool.


Note Do not open test data files using any application that acquires an exclusive read-only lock on files while the test is in the Running state. If test data files are locked, Operations Manager will not be able to write output data and will instead write errors to the log files. Examples of applications that acquire an exclusive lock are Microsoft Excel and Microsoft Word. You can use these applications when the test is not running.


Copying Test Data to Another Server

You must copy test data to another server before you examine it. You may also want to copy the test data to another server as a means of backup. Test data is in ASCII format. You can copy it to another server using whatever method is available to you; for example, SSH or copy-and-paste. Copy the test data files from the Data Storage Directory. Test data files are those whose names end with .csv, because the test data is written to CSV files.


Note If you use drag-and-drop, you risk moving the test data instead of copying it.


What Is the Format of the Node-To-Node Data?

Operations Manager provides one record type for each type of data collected. The record types are summarized in Table 10-10.

For details on the format of all exported data, see Data File Formats, page J-1.

Table 10-10 Node-To-Node Record Types 

Type
Definition

200

Echo—This record format captures end-to-end statistics for the following types of tests:

ICMP Echo

UDP Echo

Gatekeeper Registration Delay

201

Path Echo—This record format captures hop-by-hop statistics for ICMP Path Echo tests. The tests record information from source to destination.

204

Path Echo (Destination Hop)—This record format captures end-to-end statistics for ICMP Path Echo tests. The tests are from the source to the destination.

205

UDP Jitter for VoIP—This record format captures the end-to-end statistics for UDP Jitter for VoIP (Enhanced UDP) tests. The tests record information from source to destination.