Cisco IOS Software Releases 12.2 T

Table Of Contents

SAA Support for Frame Relay, VoIP, and MPLS VPN Monitoring

Feature Overview

Benefits

Restrictions

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Configuration Tasks

Configuring Frame Relay Operations

Configuring Path Jitter Monitoring for VoIP Networks or VPNs

Configuring a Monitoring Operation for an MPLS VPN

Monitoring and Maintaining SAA Operations

Configuration Examples

Configuring a Frame Relay Monitor Operation Example

Configuring a Path Jitter Operation Example

Configuring a Monitoring Operation for an MPLS VPN: Examples

Command Reference

type frame-relay

type pathJitter

rtr responder type frame-relay

vrf

Appendix: SAA Feature History

SAA Support for Frame Relay, VoIP, and MPLS VPN Monitoring

---

Feature History

Release	Modification
12.2(2)T [12.2T and 12.3]	The following features were introduced: •Service Assurance Agent (SAA) Path Jitter Monitoring Operation (type pathJitter command) •Service Assurance Agent (SAA) MPLS VPN Awareness (MPLS VPN Awareness for SAA Operations, vrf command) •Service Assurance Agent (SAA) Frame Relay Monitoring Operation (type frame-relay and rtr responder type frame-relay commands) •The Service Assurance Agent (SAA) Application Performance Monitor (APM)
12.3(2)T [12.3T and 12.4]	The following enhancement was introduced: •MPLS VPN Awareness for Path Jitter Operations This feature (a.k.a. "SAA MPLS VPN Path Jitter") is an enhancement to the previously released "Service Assurance Agent (SAA) MPLS VPN Awareness" feature; the vrf command is now valid for Path Jitter operations.
12.0(26)S [12.0S, release 26]	The following features were integrated into Cisco IOS Release 12.0S: •Service Assurance Agent (SAA) Path Jitter (type pathJitter command) •Service Assurance Agent (SAA) MPLS VPN Awareness (MPLS VPN Awareness for SAA Operations, vrf command) –This feature includes the "MPLS VPN Awareness for Path Jitter Operations" enhancement. Note The SAA Frame Relay Operation feature and the SAA Application Performance Monitor (APM) feature are not supported in 12.0(26)S.
12.2(20)S [12.2S, release 20; Oct. 2003]	The following features were integrated into Cisco IOS Release 12.2S: •Service Assurance Agent (SAA) Path Jitter (type pathJitter command) •Service Assurance Agent (SAA) MPLS VPN Awareness (MPLS VPN Awareness for SAA Operations, vrf command) –This feature includes the "MPLS VPN Awareness for Path Jitter Operations" enhancement. Note The SAA Frame Relay Operation feature and the SAA Application Performance Monitor (APM) feature are not supported in 12.2(20)S.

This document describes the following features:

•The Service Assurance Agent (SAA) Path Jitter Monitoring
(type pathJitter command)

•Service Assurance Agent (SAA) MPLS VPN Awareness
(vrf command)¹

•Service Assurance Agent (SAA) Frame Relay Interface Connection Monitoring
(type frame-relay and rtr responder type frame-relay commands)

This document includes the following sections:

•Feature Overview

•Supported Platforms

•Supported Standards, MIBs, and RFCs

•Configuration Tasks

•Monitoring and Maintaining SAA Operations

•Configuration Examples

•Command Reference

Feature Overview

The Cisco Service Assurance Agent (SAA) is a Cisco IOS feature that allows users to monitor network performance between a Cisco router and a remote device (which can be another Cisco router, an IP Host or an MVS host). Performance can be measured for real world scenarios through the configuration of SAA operations that are executed periodically. Various performance metrics measured include round trip response time, connect time, packet loss, application performance, inter-packet delay variance ( jitter), and more. This feature allows users to receive notifications and perform troubleshooting and problem analysis based on the statistics collected by the SAA.

The SAA Support for Frame Relay, VoIP, and MPLS VPNs features enhance the functionality of the Cisco SAA network monitoring solution as follows:

•SAA Frame Relay connection monitoring operations allow the user to monitor key performance metrics (round trip latency, packet loss, and data integrity) over Frame Relay permanent virtual circuits (PVCs). Proactively monitoring the performance of Frame Relay networks is essential for service providers that offer Frame Relay services.

•The SAA Path Jitter monitoring operation provides hop-by-hop jitter (interpacket variance) measurement, primarily for Voice/Video over IP (VoIP) networks. The Path Jitter monitoring operation uses standard traceroute utility to discover the intermediate hops. After discovering the path to the final destination, SAA will use Internet Control Message Protocol (ICMP) packets to measure jitter for each intermediate hop. Note that the Path Jitter operation is different from the standard Jitter (UDP+) operation.

•With VPN Awareness, SAA allows monitoring within Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs). Using SAA within MPLS VPNs allows service providers to plan, provision, and manage IP VPN services according to the service level agreement (SLA) for a customer.

Benefits

Frame Relay Monitoring

The SAA Frame Relay operation allows users to measure parameters such as response time (round trip latency), frame loss, and data integrity over frame relay circuits (PVCs). By measuring these parameters, providers can verify if the protocol is working correctly to meet customer needs.

Path Jitter Monitoring for VoIP Networks

The SAA Path Jitter operation allows the monitoring of interpacket-delay-variance a hop by hop basis. The Path Jitter operation provides measurements not only for jitter, but for other parameters such as response time, packet loss.

The ability to monitor jitter is a key performance metric for VoIP networks. By using this operation, providers can monitor the performance of different paths in the VoIP network to insure Voice transmission quality for customers.

MPLS VPN Monitoring (VPN Awareness)

This enhancement to the SAA allows users to launch SAA operations on an MPLS VPN PE router. Being able to launch SAA operations allows providers to plan, provision, and manage IP VPN services according to the SLA for their customers. VPN Awareness means that montoring can be performed for a specific VPN by specifying a VPN routing/forwarding (VRF) name.

For example, the SAA Path Jitter operation can be used to measure approximate jitter for each hop along the path from the source node to a destination network. Customers using a MPLS VPN setup in their networks use a different routing table (VRF table) for different VPNs to support overlapping IP addresses in the PE router. By specifying a VRF table when configuring a Path Jitter operation, packets can be sent from a PE to a CE using only the appropriate VPN.

Restrictions

Restrictions for Path Jitter

Path Jitter measurements are approximate because ICMP does not provide the capability to embed processing times on routers in the packet. If the target router does not place ICMP packets as the highest priority, then the router will not respond properly. ICMP performance also can be affected by the configuration of priority queueing on the router and by ping response.

There is no CISCO-RTTMON-MIB support for the Path Jitter operation. Path Jitter operations can only be configured using the CLI, and statistics can only be returned using CLI show rtr commands.

Restrictions for Frame Relay Monitoring

While the Frame Relay monitoring operation can be configured from the Cisco IOS CLI, the SAA Application Performance Monitor (APM) is required for full functionality. Full featured Frame Relay monitoring operations can be launched using APM scripts.

Related Features and Technologies

•SAA Application Performance Monitor (APM)

•Internetwork Performance Monitor (IPM) [ http://www.cisco.com/go/ipm ]

•SNMP

•The "SNMP Support for VPNs" feature, Cisco IOS Release 12.2(2)T

Related Documents

For details on configuring the Cisco SAA, refer to the "Network Monitoring Using Cisco Service Assurance Agent" chapter in the Release 12.2 Cisco IOS Configuration Fundamental Configuration Guide and the "Cisco Service Assurance Agent Commands" chapter in the Release 12.2 Cisco IOS Configuration Fundamentals Command Reference.

For information about configuring Frame Relay connections using Cisco IOS software, refer to the "Configuring Frame Relay" chapter of the Release 12.2 Cisco IOS Wide-Area Network Configuration Guide.

For general industry implementation details on Frame Relay monitoring, refer to the Frame Relay Forum Implementation Agreement 13 (FRF.13); Service Level Definitions Implementation Agreement.

For information about configuring MPLS VPN routing/forwarding tables (VRFs), refer to the "Configuring Multiprotocol Label Switching" chapter of the Cisco IOS Switching Services Configuration Guide, Release 12.2.

For information about MPLS VPNs, refer to the "Introduction to Cisco MPLS VPN Technology" chapter in the MPLS VPN Users Guide.

For information about configuring Simple Network Management Protocol (SNMP) support over VPN, refer to the Cisco IOS Release 12.2(2)T "SNMP Support for VPNs" feature guide document.

Supported Platforms

Service Assurance Agent (SAA) Path Jitter Operation

Path Jitter monitoring operations are supported on any system which supports SAA. See Feature Navigator for support details.

Service Assurance Agent (SAA) MPLS VPN Operation

MPLS VPN monitoring using SAA operations is supported on any platform that support both MPLS VPN and Cisco SAA. This includes images for the following platforms:

•Cisco 3640 series

•Cisco 7200 series;

•Cisco 7500 series

•Cisco 8540 series (MSR)

•Cisco 8650 series (BPX)

•Cisco 8800 series (MGX)

---

Note MPLS VPN support is available only in Service Provider subset images (images containing the letters p, pv, k4p, or k4pv).

---

Service Assurance Agent (SAA) Frame Relay Operation

Frame Relay monitoring operations are supported on any system which supports both Frame Relay and SAA, including images for the following platforms:

•Cisco 2500;

•Cisco 2600;

•Cisco 3620;

•Cisco 3640;

•Cisco 3660;

•Cisco 4500;

•c4gwy;

•Cisco 5300 and 5350

•Cisco 5400

•Cisco 7100 Series

•Cisco 7200 Series

•Cisco MC3810

•rpm images

•Cisco 7500 Series (rsp images)

•Cisco uBR7200

The routing device must have an interface which supports Frame Relay (such as a Serial interface) to support FR monitoring operations.

Finding Support Information for Platforms and Cisco IOS Software Images

Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

•The Cisco Response Time Monitor MIB (CISCO-RTTMON-MIB.my) was enhanced for Cisco IOS Release 12.2(2)T.

•The Cisco SAA Application Performance Monitor MIB (CISCO-SAA-APM-MIB.my) was introduced with Cisco IOS Release 12.2(2)T.

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

http://www.cisco.com/go/mibs

RFCs

No new or modified RFCs are supported by this feature.

Configuration Tasks

See the following sections for configuration tasks for the SAA feature. All tasks are optional.

•Configuring Frame Relay Operations

•Configuring Path Jitter Monitoring for VoIP Networks or VPNs

•Configuring a Monitoring Operation for an MPLS VPN

---

Note The command syntax for configuring, monitoring, and maintaining the SAA and the SAA Responder uses the acronym "rtr". SAA operations are configured in "RTR Entry Configuration Mode".

---

Configuring Frame Relay Operations

Frame Relay monitoring operations:

•Measure the round trip time and the one-way delay experienced by a Frame Relay packet from source to destination.

•Measure the absolute packet loss, or how many packets were sent from source to destination, and how many were received. This includes all frames sent, not just SAA frames.

•Keep track of packet corruption for the SAA generated frames. The user can specify the number of bytes of data and the pattern of data to be sent (in the request only).

To configure a Frame Relay operation on the transmitting device (agent), use the following commands beginning in global configuration mode on the transmitting device:

	Command	Purpose
Step 1	Router(config)# rtr operation-number	Specifies an SAA operation and enters RTR configuration mode.
Step 2	Router(config-rtr)# type frame-relay interface interface-type interface-number dlci dlci-number	Configures the specified operation as a Frame Relay operation, which measures response time, frame loss, and data corruption across a Frame Relay PVC.
Step 3	Router(config-rtr)# data-pattern hex-pattern	(optional) Specifies the pattern of data to be sent in the Frame Relay Monitor operational probes. The data-pattern allows you to verify that the operation payload does not get corrupted from source-to-destination or from destination-to-source.
Step 4	Router(config-rtr)# request-data-size number-of-bytes	(optional) Specifies the protocol data size in the payload of the Frame Relay Monitor operation's request packets.

Because the Frame Relay operation is testing the connection of a permanent virtual circuit (PVC), you do not have to specify an operational target. When specifying the DLCI number, there is only one possible target device (responder) possible.

After you configure the type of operation, you can configure optional characteristics for the Frame Relay Monitor operation. The following operational characteristics apply to Frame Relay operations:

•frequency

•owner

•request-data-size

•tag

•timeout

•verify-data

•data-pattern

For information on configuring these characteristics, see the "Configuring SAA Operation Characteristics" section in the "Network Monitoring Using Cisco SAA" chapter of the Release 12.2 Cisco IOS Configuration Fundamentals Configuration Guide. Note that the SAA "statistics" commands do not apply to Frame Relay operations.

After you configure the characteristics of the operation, you must specify when the operation should start. To schedule the operation, use the following command in EXEC mode:

Command	Purpose
Router(config)# rtr schedule operation-number [life seconds] [start-time {pending | now | hh:mm day month}] [ageout seconds]	Schedules an SAA operation.

To enable the destination device (responder) to process and reply to SAA Frame Relay operations, use one of the following forms of the rtr responder type frameRelay command in global configuration mode on the destination device:

Command	Purpose
Router(config)# rtr responder type frame-relay interface interface-ID dlci dlci-number	Enables the system to respond to SAA Frame Relay operations on only the specified interface. The interface-ID argument should specify the interface type and the interface identification number.
Router(config)# rtr responder type frame-relay all	Enables the system to respond to SAA Frame Relay operations on all interfaces.

Configuring Path Jitter Monitoring for VoIP Networks or VPNs

To configure a Path Jitter SAA operation, use the following commands, starting in global configuration mode:

	Command	Purpose
Step 1	Router(config)# rtr operation-number	Specifies an SAA operation and enters RTR Entry configuration mode.
Step 2	Router(config-rtr)# type pathJitter dest-ipaddr dest-ipaddress [source-ipaddress source-ipaddress] [number-packets packet-number] [interval time-ms] [targetOnly]	Configures the specified operation as a Path Jitter operation. This command will cause the operation to trace the IP path from the source (src-ipaddress) to the destination (dest-ipaddress) and then send number echo probes to each hop along the traced path with an interval of time-ms between each echo probe. The source-ipaddr, num-packets and interval fields are optional. If the number of packets and interval are not specified, default values of 10 packets and a 20 ms interval are used.

If the targetOnly keyword is not used in the type pathJitter command (used in Step 2), the Path Jitter operation will trace the "hop-by-hop" IP path from the source to the destination and send the specified number of test packets to each hop along the trace path, using the specified time interval between each test packet.

To send echo probes to the destination only, use the optional targetOnly keyword at the end of the command. When the targetOnly keyword is used, the path from the source to the destination is not traced.

The SAA Responder does not have to be enabled on either the target device or intermediate devices for Path Jitter operations.

See the following section for information on specifying a VPN for the Path Jitter operation.

Configuring a Monitoring Operation for an MPLS VPN

The following SAA operations can be configured to measure response time of an MPLS VPN tunnel:

•IP/ICMP Echo operation (type echo protocol ipIcmpEcho)

•IP/ICMP Path Echo operation (type pathEcho protocol ipIcmpEcho)

•UDP Echo operation (type udpEcho)

•Jitter operation (type jitter)

•Path Jitter operations (type pathJitter) [12.0(26)S or 12.3(2)T and later releases]

To configure any of these operations for a MPLS VPN connection, use the following commands, starting in global configuration mode:

	Command	Purpose
Step 1	Router(config)# rtr operation-number	Specifies an SAA operation and enters RTR Entry configuration mode.
Step 2	Router(config-rtr)# type {echo | pathEcho | udpEcho | jitter | pathJitter}	Configures the operation type. See the list above for supported operations. For the complete command syntax, use the CLI ? command, or see the 12.2 Command Reference documents. Note When configuring the operation type, the source IP address should not be specified. The SAA will automatically assign the appropriate source IP address for the interface in the VPN.
Step 3	Router(config-rtr)# vrf vrf-name	Binds specific VRF tables for a particular VPN. •The show rtr configuration command will indicate if a VPN is specified for the operation in the Vrf Name: line.

After completing Steps 1 through 3 above, configure additional operational characteristics as desired, and schedule the operation.

Monitoring and Maintaining SAA Operations

To display the status and current statistics for any SAA operation, use any of the following commands:

Command	Purpose
Router# show rtr operational-state [operation-number]	Displays statistics, history, and state of all SAA operations. •You can show the state of a specific operation using the optional operation-number argument.
Router# show rtr configuration [operation-number]	Displays configuration values (including all defaults) for all SAA operations. •You can show the configuration for a specific operation using the optional operation-number argument.

Configuration Examples

This section provides the following configuration examples:

•Configuring a Frame Relay Monitor Operation Example

•Configuring a Path Jitter Operation Example

•Configuring a Monitoring Operation for an MPLS VPN: Examples

Configuring a Frame Relay Monitor Operation Example

Router A (Agent)

Router(config)#rtr 1

Router(config-rtr)#type frame-relay interface FR-ATM 20 dlci 16 

Router B (Responder)

Router(config)#rtr responder type frame-relay interface FR-ATM 20 dlci 16

Monitoring Output on Router A (Agent)

Router# show rtr operational-state 1

 Current Operational State

Entry Number: 1

Modification Time: *00:00:47.000 UTC Mon Mar 1 2001

Diagnostics Text: 

Last Time this Entry was Reset: Never

Number of Octets in use by this Entry: 1376

Number of Operations Attempted: 111

Current Seconds Left in Life: infinite - runs forever

Operational State of Entry: active

Latest Completion Time (milliseconds): 6

Latest Operation Start Time: *00:38:04.000 UTC Mon Mar 1 2001

Latest Oper Sense: ok

Latest RTT: 6

Frames Sent from Source to Destination: 1

Frames Lost from Source to Destination: 0

Frames Sent from Destination to Source: 1

Frames Lost from Destination to Source: 0

Router# show rtr configuration

 Complete Configuration Table (includes defaults)

Entry Number: 1

Owner: 

Tag: 

Type of Operation to Perform: frame-relay

Reaction and History Threshold (milliseconds): 5000

Operation Frequency (seconds): 20

Operation Timeout (milliseconds): 5000

Verify Data: TRUE

Status of Entry (SNMP RowStatus): active

Protocol Type: frameRelayAppl

Target Address: 

Source Address: 

Target Port: 0

Source Port: 0

Request Size (ARR data portion): 58

Response Size (ARR data portion): 58

Control Packets: enabled

Loose Source Routing: disabled

LSR Path: 

Type of Service Parameters: 0x0

Life (seconds): infinite - runs forever

Next Scheduled Start Time: Start Time already passed

Entry Ageout: never

Connection Loss Reaction Enabled: FALSE

Timeout Reaction Enabled: FALSE

Threshold Reaction Type: never

Threshold Falling (milliseconds): 3000

Threshold Count: 5

Threshold Count2: 5

Reaction Type: none

Verify Error Reaction Enabled: FALSE

Number of Statistic Hours kept: 2

Number of Statistic Paths kept: 1

Number of Statistic Hops kept: 1

Number of Statistic Distribution Buckets kept: 1

Statistic Distribution Interval (milliseconds): 20

Number of History Lives kept: 0

Number of History Buckets kept: 15

Number of History Samples kept: 1

History Filter Type: none

Configuring a Path Jitter Operation Example

Router#configure terminal

Router(config)#rtr 1

Router(config-rtr)# type PathJitter dest-ipaddr 172.31.1.129 source-ipaddr 10.2.30.1 
num-packets 10 interval 20

.

.

.

Router#show rtr configuration 1

Complete Configuration Table (includes defaults)

Entry Number: 5

Owner: 

Tag: 

Type of Operation to Perform: PathJitter

Reaction and History Threshold (milliseconds): 5000

Operation Frequency (seconds): 60

Operation Timeout (milliseconds): 5000

Verify Data: FALSE

Status of Entry (SNMP RowStatus): active

Protocol Type: ipIcmpEcho

Target Address: 172.31.1.129

Source Address: 0.0.0.0

Target Port: 0

Source Port: 0

Request Size (ARR data portion): 28

Response Size (ARR data portion): 28

Number of Packets per probe: 10

Interval between packets(milliseconds): 20

Control Packets: enabled

Loose Source Routing: disabled

LSR Path: 

Type of Service Parameters: 0x0

Life (seconds): 3600

Next Scheduled Start Time: Start Time already passed

Entry Ageout: never

Router#show rtr operational-state

Current Operational State

Entry Number: 1

Modification Time: 15:41:33.000 UTC Tue Sep 19 2000

Diagnostics Text: 

Last Time this Entry was Reset: Never

Number of Octets in use by this Entry: 1882

Number of Operations Attempted: 1

Current Seconds Left in Life: 3586

Operational State of Entry: active

Latest Completion Time Average (milliseconds): 4

Latest Operation Start Time: 15:41:43.000 UTC Tue Sep 19 2000

Path Jitter Statistics:

        Legend - TR = Total Receives; RTT = Round Trip Time (Avg); PL = Packet Loss

                 DS = Discarded Samples; OS = Out Of Sequence Echo Replies

        HopAddress       TR      RTT     PL      DS      OS      Jitter(RFC 1889)

        10.2.30.1        10      1       0       0       0       0

        172.21.22.1      10      1       0       0       0       0

        172.24.112.122   10      1       0       0       0       0

        171.69.4.16      10      1       0       0       0       0

        171.69.5.6       10      1       0       0       0       0

        171.69.1.129     10      1       0       0       0       0

Configuring a Monitoring Operation for an MPLS VPN: Examples

The following examples illustrate how to set up different SAA operations that support MPLS VPNs. These examples show how test traffic can be sent in an already existing VPN tunnel between two endpoints. Only the following operations can measure response time of a VPN tunnel.

Note that for all of the following operation types, the source IP address is not specified. The SAA will automatically specify the correct source interface when the vrf command is used.

The SAA Responder (RTR Responder) is also VRF Aware.

Configuring an Echo Operation Example

Router(config)#rtr 1

Router(config-rtr)#type echo protocol ipIcmpEcho 1.1.1.1

Router(config-rtr)#vrf vpn1

Router(config-rtr)#exit

Router(config)#rtr schedule 1 start now

Configuring a Path Echo Operation Example

Router(config)#rtr 2

Router(config-rtr)#type pathEcho protocol ipIcmpEcho 1.1.1.1

Router(config-rtr)#vrf vpn1

Router(config)#rtr schedule 2 start now

Configuring a UDP Echo Operation Example

Router(config)#rtr 3

Router(config-rtr)#type udpEcho dest-ipaddr 1.1.1.1 dest-port 1213

Router(config-rtr)#vrf vpn1

Router(config)#rtr schedule 3start now

Configuring a Jitter Operation Example

Router(config)# rtr 4

Router(config-rtr)# type jitter dest-ipaddr 1.1.1.1 dest-port 1213

Router(config-rtr-jitter)# vrf vpn1

Router(config-rtr-jitter)# exit 

Router(config)# rtr schedule 4start now

Configuring a Path Jitter Operation with VPN Awareness Example

In the following example, a Path Jitter operation is configured to run to a CE with the VPN "red" specified:

Router# configure terminal 

Enter configuration commands, one per line.  End with CNTL/Z.

Router(config)# rtr 7 

Router(config-rtr)# type pathJitter dest-ipaddr 10.3.30.130

Router(config-rtr-pathJitter)# vrf red 

Router(config-rtr-pathJitter)# exit 

Router(config)# rtr schedule 7 start-time now life forever 

Router#

00:38:04: %SYS-5-CONFIG_I: Configured from console by console

Router# show rtr operational-state 7 

     Entry Number: 7

Owner: 

Tag: 

Type of Operation to Perform: pathJitter

Reaction and History Threshold (milliseconds): 5000

Operation Frequency (seconds): 60

Operation Timeout (milliseconds): 5000

Verify Data: FALSE

Status of Entry (SNMP RowStatus): active

Protocol Type: ipIcmpEcho

Target Address: 10.3.30.130

Source Address: 10.3.30.129

Target Port: 0

Source Port: 0

Request Size (ARR data portion): 28

Response Size (ARR data portion): 28

Num of Packets per probe: 10

Interval between packets(milliseconds): 20

Target Only: Disabled

Control Packets: enabled

Loose Source Routing: disabled

LSR Path: 

Type of Service Parameters: 0x0

Life (seconds): infinite - runs forever

Next Scheduled Start Time: Start Time already passed

Entry Ageout (seconds): never

Connection Loss Reaction Enabled: FALSE

Timeout Reaction Enabled: FALSE

Threshold Reaction Type: never

Threshold Falling (milliseconds): 3000

Threshold Count: 5

Threshold Count2: 5

Reaction Type: none

Command Reference

This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.2 command reference publications.

•type frame-relay

•type pathJitter

•rtr responder type frame-relay

•vrf

type frame-relay

To measure response time, frame loss, or data corruption across a Frame Relay permanent virtual circuit (PVC) using the Cisco Service Assurance Agent, use the type frame-relay command in global configuration mode. To delete the type configuration for each configured responder, use the no form of this command.

type frame-relay interface interface-ID dlci dlci-number

no type frame-relay interface interface-ID dlci dlci-number

Syntax Description

interface interface-ID	Specifies the Frame Relay interface from which the operation will be sent. The interface-ID argument should consist of the interface type and identification number.
dlci dlci-number	Specifies the Frame Relay PVC subinterface link that is assigned to the interface.

Defaults

No default behavior or values.

Command Modes

RTR Entry configuration mode

Command History

Release	Modification
12.2(2)T	This command was introduced.

Usage Guidelines

The type frame-relay global configuration command must have the SAA Responder configured before this command can work. Use the rtr responder type frame-relay all global configuration command or rtr responder global configuration command to configure the responder.

If the first measurement does not have the correct values for frames sent and frames lost, the command cannot work properly. There need to be at least two successful measurements for the frames sent and frames lost to be correct.

If the encapsulation on the target interface is not Frame Relay (for example, if the encapsulation is changed), the Frame Relay operation will be removed automatically from the configuration.

Examples

The following example sets router 1 with Frame Relay and a specified interface of Serial0 on specified subinterface 22:

Router(config)# rtr 1

Router(config-rtr)# type frame-Relay interface Serial0 dlci 22

type pathJitter

To configure an SAA Path Jitter monitoring operation, use the type pathJitter command in global configuration mode.

type PathJitter dest-ipaddress destination-ip [source-ipaddress source-ip] [number-packets packet-number] [interval time-ms] [targetOnly]

Syntax Description

dest-ipaddress destination-ip	Specifies the destination (target) IP address.
source-ipaddress source-ip	(Optional) Specifies the source IP address that will be used in the test packets.
number-packets packet-number	(Optional) The number of packets, as specified by the packet-number argument. The default value is 10.
interval time-ms	(Optional) Time interval between packets (in milliseconds). The default value is 20 ms.
targetOnly	(Optional) Sends test packets to the destination only (path is not traced).

Defaults

packet-number: 10

time-ms: 20 ms

Command Modes

RTR Entry configuration mode

Command History

Release	Modification
12.2(2)T	This command was introduced.
12.0(26)S	This command was integrated into Cisco IOS Release 12.0S.

Usage Guidelines

The Path Jitter SAA operation traces a specified IP path from the source to the destination and then sends a specified number of packets to each hop along the traced path. Optionally, the time interval between each test packet can be specified.

If the number of packets and the time interval are not specified, the path jitter operation will use the default values.

If the targetOnly keyword is not used, the path jitter operation will trace the "hop-by-hop" IP path from the source to the destination and send the specified number of test packets to each hop along the trace path, using the specified time interval between each test packet.

If the targetOnly keyword is used, the command will cause cause the Path Jitter operation to send echos to the destination only (the path from the source to the destination is not traced).

The SAA Responder should not be enabled for Path Jitter operations.

Examples

The following example enables the Path Jitter operation to trace the IP path to the destination 172.69.1.129 and send ten test packets to each hop with an interval of 20 ms between each test packet:

Router# config terminal

Router(config)# rtr 1

Router(config-rtr)# type pathJitter dest-ipaddr 172.69.1.129

The following example enables the Path Jitter operation to send 50 test packets to 172.69.5.6 with an interval of 30 ms between each test packet:

Router# config terminal

Router(config)# rtr 2

Router(config-rtr)# type pathJitter 172.69.5.6 num-packets 50 interval 30 targetOnly

rtr responder type frame-relay

To enable the SAA Responder on the operational target device for Frame Relay operations, use the rtr responder global configuration command. To disable the SAA Responder, use the no form of this command.

rtr responder type frame-relay {all | interface {serial | FR-ATM} interface-number dlci dlci-number}

no rtr responder type frame-relay {all | interface {serial | FR-ATM} interface-number dlci dlci-number}

Syntax Description

all	(Optional) Specifies that the responder will accept and return udpEcho operation packets.
interface interface-ID	Specifies the Frame Relay interface at which Frame Relay operations will be recieved.
dlci dlci-number	Specifies the Frame Relay PVC subinterface link that is assigned to the interface.

Defaults

None

Command Modes

Global configuration

Command History

Release	Modification
12.0(3)T	The rtr responder command was introduced.
12.2(2)T	This extension of the rtr responder command was introduced.

Usage Guidelines

This command is used on the destination device for SAA operations to enable UPD Echo, TCP Connect, and Jitter (UDP+) operations on non-native interfaces.

The type, ipaddr, and port keywords enable the SAA Responder to respond to probe packets without receiving Control Protocol packets. The applicable protocols are Jitter, udpEcho, and tcpConnect. However, note that if you use these keywords, packet loss statistics will not be able to be generated for the operation, because the Responder will not be able to determine the order of the received packets.

Examples

The following example enables the SAA Responder to respond to Frame Relay operations:

Router(config)# rtr responder type frame-relay ?

  all        Respond to frame relay measurement packets on every interface and

             dlci

  interface  Serial interface over which to respond to measurement packets

Router(config)#rtr responder type frame-relay all 

Related Commands

Command	Description
rtr	Specifies an SAA operation and enters RTR Entry configuration mode.

vrf

To allow monitoring within Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs) using SAA operations, use the vrf RTR Entry configuration command.

vrf vrf-name

Syntax Description

vrf-name

Name of the VPN (VRF name).

Defaults

No default behavior or values.

Command Modes

RTR Entry configuration mode

Command History

Release	Modification
12.2(2)T	This command was introduced.
12.2(11)T	Syntax changed from vrfName to vrf with SAA Engine II.
12.0(26)S	This command was integrated into Cisco IOS Release 12.0S.
12.3(2)T, 12.0(26)S	Support for this command was added for Path Jitter operations (the VRF name can be specified as part of configuring type pathJitter).

Usage Guidelines

VRF is short for Vitual Routing/Forwarding table. A Virtual Private Network (VPN) is commonly identified using the VRF name.

If the vrf keyword and vrf-name argument combination is configured for an SAA operation, SAA uses the vrf-name to identify the VPN for this operation. This command should only be used if it is necessary to measure the response time over the VPN tunnel.

Examples

The following examples illustrate how to set up different SAA operations that support MPLS VPNs. These examples show how test traffic can be sent in an already existing VPN tunnel between two endpoints. Only the following operations can measure response time of a VPN tunnel.

Note that for all of the following operation types, the source IP address is not specified. The SAA will automatically specify the correct source interface when the vrf command is used.

Configuring an Echo Operation Example

Router(config)# rtr 1

Router(config-rtr)# type echo protocol ipIcmpEcho 1.1.1.1

Router(config-rtr-echo)# vrf vpn1

Router(config-rtr-echo)# end

Router(config)# rtr schedule 1 start now

Configuring a Path Echo Operation Example

Router(config)# rtr 1

Router(config-rtr)# type pathEcho protocol ipIcmpEcho 1.1.1.1

Router(config-rtr-pathEcho)# vrf vpn1

Router(config-rtr-pathEcho)# end

Router(config)# rtr schedule 1 start now

Configuring a UDP Echo Operation Example

Router(config)# rtr 1

Router(config-rtr)# type udpEcho dest-ipaddr 1.1.1.1 dest-port 1213

Router(config-rtr)# vrf vpn1

Router(config-rtr)# end

Router(config)# rtr schedule 1 start now

Configuring a Jitter Operation Example

Router(config)# rtr 1

Router(config-rtr)# type jitter dest-ipaddr 1.1.1.1 dest-port 1213

Router(config-rtr-jitter)# vrf vpn1

Router(config-rtr-jitter)# end

Router(config)# rtr schedule 1 start now

Configuring a Path Jitter Operation Example

In the following example, a Path Jitter operation is configured to run to a CE with the VPN "red" specified, and the source IP address specified:

Router(config)# rtr 7 

Router(config-rtr)# type pathJitter dest-ipaddr 10.3.30.130 source-ipaddr 10.3.30.129 

Router(config-rtr-pathJitter)# vrf red 

Router(config-rtr-pathJitter)# end 

Router(config)# rtr schedule 7 start-time now life forever

Related Commands

Command	Description
type echo	Configures an SAA Echo operation.

Appendix: SAA Feature History

Before Cisco IOS Release 12.0(5)T, the Service Assurance Agent (SAA) was refered to as the Response Time Reporter (RTR).

Feature History for Release 12.2T, 12.2 & 12.3 mainline, and 12.3T.

Release	Features Supported
11.3, 12.0	Service Assurance Agent (SAA) ICMP Echo Operation
12.0(3)T	Service Assurance Agent (SAA) Echo Operation Service Assurance Agent (SAA) Path Echo Operation Service Assurance Agent (SAA) TCP Connect Operation Service Assurance Agent (SAA) UDP Echo Operation
12.0(5)T	Service Assurance Agent (SAA) DHCP Operation Service Assurance Agent (SAA) Jitter Operation Service Assurance Agent (SAA) HTTP Operation
12.1(1) mainline	All features in 12.0T release train.
12.1(1)T	Service Assurance Agent (SAA) FTP Operation
12.2(1) mainline	All features in 12.1T release train.
12.2(2)T	Service Assurance Agent (SAA) Path Jitter Operation Service Assurance Agent (SAA) MPLS VPN Awareness SAA Application Performance Monitor (APM) Service Assurance Agent (SAA) Frame Relay Operation
12.2(11)T	Service Assurance Agent (SAA) Engine II
12.2(15)T	Service Assurance Agent (SAA) SLM for ATM Interfaces
12.3(1) mainline	Service Assurance Agent (SAA) SLM for Frame Relay Interfaces + all features in 12.2T release train
12.3(2)T	MPLS VPN Awareness for Path Jitter Operations
12.3(4)T	Service Assurance Agent (SAA) VoIP UDP Operation

Feature History for Release 12.0 S

Release	Features Supported
12.0(5)S	Service Assurance Agent (SAA) ICMP Echo Operation Service Assurance Agent (SAA) Echo Operation Service Assurance Agent (SAA) Path Echo Operation Service Assurance Agent (SAA) TCP Connect Operation Service Assurance Agent (SAA) UDP Echo Operation
12.0(8)S	Service Assurance Agent (SAA) DHCP Operation
12.0(26)S	Service Assurance Agent (SAA) Path Jitter Operation Service Assurance Agent (SAA) MPLS VPN Awareness MPLS VPN Awareness for Path Jitter Operations

Feature History for Release 12.2 S

Release	Features Supported
12.2 S	Service Assurance Agent (SAA) ICMP Echo Operation Service Assurance Agent (SAA) Echo Operation Service Assurance Agent (SAA) Path Echo Operation Service Assurance Agent (SAA) TCP Connect Operation Service Assurance Agent (SAA) UDP Echo Operation
12.2(20)S	Service Assurance Agent (SAA) Path Jitter Operation Service Assurance Agent (SAA) MPLS VPN Awareness MPLS VPN Awareness for Path Jitter Operations

---

 Copyright © 2001-2003 Cisco Systems, Inc. All rights reserved.

This document first published June 7, 2001. Last updated September 15, 2003.

¹ This feature is also referred to as "MPLS VPN Awareness for SAA Operations" or as "VRF Awareness for SAA."