Downloads |
 Feedback
|
Table Of Contents
Configuring Cisco IOS IP SLAs Operations
Understanding Cisco IOS IP SLAs
Using Cisco IOS IP SLAs to Measure Network Performance
IP SLAs Responder and IP SLAs Control Protocol
Response Time Computation for IP SLAs
IP SLAs Operation Threshold Monitoring
Configuring IP SLAs Operations
Configuring the IP SLAs Responder
Analyzing IP Service Levels by Using the UDP Jitter Operation
Analyzing IP Service Levels by Using the ICMP Echo Operation
Configuring Cisco IOS IP SLAs Operations
This chapter describes how to use Cisco IOS IP Service Level Agreements (SLAs) on the Cisco ME 3800X and 3600X switch. Cisco IP SLAs is a part of Cisco IOS software that allows Cisco customers to analyze IP service levels for IP applications and services by using active traffic monitoring—the generation of traffic in a continuous, reliable, and predictable manner—for measuring network performance. With Cisco IOS IP SLAs, service provider customers can measure and provide service level agreements, and enterprise customers can verify service levels, verify outsourced service level agreements, and understand network performance. Cisco IOS IP SLAs can perform network assessments, verify quality of service (QoS), ease the deployment of new services, and assist with network troubleshooting.
For more information about IP SLAs, see the IP SLAs Configuration Guide, Cisco IOS Release 15.x.
For command syntax information, see the command reference at this URL:
http://www.cisco.com/en/US/docs/ios/ipsla/command/reference/sla_book.html
This chapter consists of these sections:
•
Understanding Cisco IOS IP SLAs
•
•
Understanding Cisco IOS IP SLAs
Cisco IOS IP SLAs sends data across the network to measure performance between multiple network locations or across multiple network paths. It simulates network data and IP services and collects network performance information in real time. Cisco IOS IP SLAs generates and analyzes traffic either between Cisco IOS devices or from a Cisco IOS device to a remote IP device such as a network application server. Measurements provided by the various Cisco IOS IP SLAs operations can be used for troubleshooting, for problem analysis, and for designing network topologies.
Depending on the specific Cisco IOS IP SLAs operation, various network performance statistics are monitored within the Cisco device and stored in both command-line interface (CLI) and Simple Network Management Protocol (SNMP) MIBs. IP SLAs packets have configurable IP and application layer options such as source and destination IP address, User Datagram Protocol (UDP)/TCP port numbers, a type of service (ToS) byte (including Differentiated Services Code Point [DSCP] and IP Prefix bits), Virtual Private Network (VPN) routing/forwarding instance (VRF), and URL web address.
Because Cisco IP SLAs is Layer 2 transport independent, you can configure end-to-end operations over disparate networks to best reflect the metrics that an end user is likely to experience. IP SLAs collects a unique subset of these performance metrics:
•
•
•
•
•
•
•
Because Cisco IOS IP SLAs is SNMP-accessible, it can also be used by performance-monitoring applications like CiscoWorks Internetwork Performance Monitor (IPM) and other third-party Cisco partner performance management products. You can find more details about network management products that use Cisco IOS IP SLAs at this URL:
Using IP SLAs can provide these benefits:
•
•
–
–
•
•
•
•
This section includes this information about IP SLAs functionality:
•
•
•
•
Using Cisco IOS IP SLAs to Measure Network Performance
You can use IP SLAs to monitor the performance between any area in the network—core, distribution, and edge—without deploying a physical probe. It uses generated traffic to measure network performance between two networking devices. Figure 42-1 shows how IP SLAs begins when the source device sends a generated packet to the destination device. After the destination device receives the packet, depending on the type of IP SLAs operation, it responds with time-stamp information for the source to make the calculation on performance metrics. An IP SLAs operation performs a network measurement from the source device to a destination in the network using a specific protocol such as UDP.
Figure 42-1 Cisco IOS IP SLAs Operation
To implement IP SLAs network performance measurement, you need to perform these tasks:
1.
2.
3.
4.
5.
6.
For more information about IP SLAs operations, see the operation-specific chapters in the IP SLAs Configuration Guide, Cisco IOS Release 15.x.
Note
IP SLAs Responder and IP SLAs Control Protocol
The IP SLAs responder is a component embedded in the destination Cisco device that allows the system to anticipate and respond to IP SLAs request packets. The responder provides accurate measurements without the need for dedicated probes. The responder uses the Cisco IOS IP SLAs Control Protocol to provide a mechanism through which it can be notified on which port it should listen and respond. Only a Cisco IOS device can be a source for a destination IP SLAs Responder.
Note
Figure 42-1 shows where the Cisco IOS IP SLAs responder fits in the IP network. The responder listens on a specific port for control protocol messages sent by an IP SLAs operation. Upon receipt of the control message, it enables the specified UDP or TCP port for the specified duration. During this time, the responder accepts the requests and responds to them. It disables the port after it responds to the IP SLAs packet, or when the specified time expires. MD5 authentication for control messages is available for added security.
You do not need to enable the responder on the destination device for all IP SLAs operations. For example, a responder is not required for services that are already provided by the destination router (such as Telnet or HTTP). You cannot configure the IP SLAs responder on non-Cisco devices and Cisco IOS IP SLAs can send operational packets only to services native to those devices.
Response Time Computation for IP SLAs
Switches and routers can take tens of milliseconds to process incoming packets due to other high priority processes. This delay affects the response times because the test-packet reply might be in a queue while waiting to be processed. In this situation, the response times would not accurately represent true network delays. IP SLAs minimizes these processing delays on the source device as well as on the target device (if the responder is being used) to determine true round-trip times. IP SLAs test packets use time stamping to minimize the processing delays.
When the IP SLAs responder is enabled, it allows the target device to take time stamps when the packet arrives on the interface at interrupt level and again just as it is leaving, eliminating the processing time. This time stamping is made with a granularity of sub-milliseconds (ms).
Figure 42-2 demonstrates how the responder works. Four time stamps are taken to make the calculation for round-trip time. At the target router, with the responder functionality enabled, time stamp 2 (TS2) is subtracted from time stamp 3 (TS3) to produce the time spent processing the test packet as represented by delta. This delta value is then subtracted from the overall round-trip time. Notice that the same principle is applied by IP SLAs on the source router where the incoming time stamp 4 (TS4) is also taken at the interrupt level to allow for greater accuracy.
Figure 42-2 Cisco IOS IP SLAs Responder Time Stamping
An additional benefit of the two time stamps at the target device is the ability to track one-way delay, jitter, and directional packet loss. Because much network behavior is asynchronous, it is critical to have these statistics. However, to capture one-way delay measurements, you must configure both the source router and target router with Network Time Protocol (NTP) so that the source and target are synchronized to the same clock source. One-way jitter measurements do not require clock synchronization.
IP SLAs Operation Scheduling
When you configure an IP SLAs operation, you must schedule the operation to begin capturing statistics and collecting error information. You can schedule an operation to start immediately or to start at a certain month, day, and hour. You can use the pending option to set the operation to start at a later time. The pending option is an internal state of the operation that is visible through SNMP. The pending state is also used when an operation is a reaction (threshold) operation waiting to be triggered. You can schedule a single IP SLAs operation or a group of operations at one time.
You can schedule several IP SLAs operations by using a single command through the Cisco IOS CLI or the CISCO RTTMON-MIB. Scheduling the operations to run at evenly distributed times allows you to control the amount of IP SLAs monitoring traffic. This distribution of IP SLAs operations helps minimize the CPU utilization and thus improves network scalability.
For more details about the IP SLAs multioperations scheduling functionality, see the IP SLAs Configuration Guide, Cisco IOS Release 15.x.
IP SLAs Operation Threshold Monitoring
To support successful service level agreement monitoring, you must have mechanisms that notify you immediately of any possible violation. IP SLAs can send SNMP traps that are triggered by events such as these:
•
•
•
•
•
•
•
•
An IP SLAs threshold violation can also trigger another IP SLAs operation for further analysis. For example, the frequency could be increased or an ICMP path echo or ICMP path jitter operation could be initiated for troubleshooting.
Determining the type of threshold and the level to set can be complex, and depends on the type of IP service being used in the network. For more details on using thresholds with Cisco IOS IP SLAs operations, see the "IP SLAs—Proactive Threshold Monitoring" chapter of the IP SLAs Configuration Guide, Cisco IOS Release 15.x.
Configuring IP SLAs Operations
This section does not include configuration information for all available operations as the configuration information details are included in the Cisco IOS IP SLAs Configuration Guide. It includes several operations as examples, including configuring the responder, configuring UDP jitter operation, which requires a responder, and configuring ICMP echo operation, which does not require a responder. For details about configuring other operations, see the IP SLAs Configuration Guide, Cisco IOS Release 15.x.
This section includes this information:
•
•
•
Default Configuration
No IP SLAs operations are configured.
Configuration Guidelines
For information on the IP SLAs commands, see the Cisco IOS IP SLAs Command Reference.
For detailed descriptions and configuration procedures, see the IP SLAs Configuration Guide, Cisco IOS Release 15.x.
Note that not all of the IP SLAs commands or operations described in this guide are supported on the switch. The switch supports IP service level analysis by using UDP jitter, UDP echo, HTTP, TCP connect, ICMP echo, ICMP path echo, ICMP path jitter, FTP, DNS, and DHCP, as well as multiple operation scheduling and proactive threshold monitoring. It does not support IP SLAs VoIP service levels using the gatekeeper registration delay operations measurements.
Before configuring any IP SLAs application, you can use the show ip sla application privileged EXEC command to verify that the operation type is supported on your software image. This is an example of the output from the command:
Switch# show ip sla applicationIP SLAsVersion: 2.2.0 Round Trip Time MIB, Infrastructure Engine-IITime of last change in whole IP SLAs: 22:17:39.117 UTC Fri JunEstimated system max number of entries: 15801Estimated number of configurable operations: 15801Number of Entries configured : 0Number of active Entries : 0Number of pending Entries : 0Number of inactive Entries : 0Supported Operation TypesType of Operation to Perform: 802.1agEchoType of Operation to Perform: 802.1agJitterType of Operation to Perform: dhcpType of Operation to Perform: dnsType of Operation to Perform: echoType of Operation to Perform: ftpType of Operation to Perform: httpType of Operation to Perform: jitterType of Operation to Perform: pathEchoType of Operation to Perform: pathJitterType of Operation to Perform: tcpConnectType of Operation to Perform: udpEchoIP SLAs low memory water mark: 21741224Configuring the IP SLAs Responder
The IP SLAs responder is available only on Cisco IOS software-based devices, including some Layer 2 switches that do not support full IP SLAs functionality, such as the Catalyst 2960 or the Cisco ME 2400 switch or a Cisco ME 3400 switch running the metro base image. Beginning in privileged EXEC mode, follow these steps to configure the IP SLAs responder on the target device (the operational target):
To disable the IP SLAs responder, enter the no ip sla responder global configuration command. This example shows how to configure the device as a responder for the UDP jitter IP SLAs operation in the next procedure:
Switch(config)# ip sla responder udp-echo 172.29.139.134 5000Analyzing IP Service Levels by Using the UDP Jitter Operation
Jitter means interpacket delay variance. When multiple packets are sent consecutively 10 ms apart from source to destination, if the network is behaving correctly, the destination should receive them 10 ms apart. But if there are delays in the network (like queuing, arriving through alternate routes, and so on) the arrival delay between packets might be more than or less than 10 ms with a positive jitter value meaning that the packets arrived more than 10 ms apart. If the packets arrive 12 ms apart, positive jitter is 2 ms; if the packets arrive 8 ms apart, negative jitter is 2 ms. For delay-sensitive networks, positive jitter values are undesirable, and a jitter value of 0 is ideal.
In addition to monitoring jitter, the IP SLAs UDP jitter operation can be used as a multipurpose data gathering operation. The packets IP SLAs generates carry packet sending and receiving sequence information and sending and receiving time stamps from the source and the operational target. Based on these, UDP jitter operations measure this data:
•
•
•
•
Because the paths for the sending and receiving of data can be different (asymmetric), you can use the per-direction data to more readily identify where congestion or other problems are occurring in the network.
The UDP jitter operation generates synthetic (simulated) UDP traffic and sends a number of UDP packets, each of a specified size, sent a specified number of milliseconds apart, from a source router to a target router, at a given frequency. By default, ten packet-frames, each with a payload size of 10 bytes are generated every 10 ms, and the operation is repeated every 60 seconds. You can configure each of these parameters to best simulate the IP service you want to provide.
To provide accurate one-way delay (latency) measurements, time synchronization, such as that provided by NTP, is required between the source and the target device. Time synchronization is not required for the one-way jitter and packet loss measurements. If the time is not synchronized between the source and target devices, one-way jitter and packet loss data is returned, but values of 0 are returned for the one-way delay measurements provided by the UDP jitter operation
Note
Beginning in privileged EXEC mode, follow these steps to configure UDP jitter operation on the source device:
To disable the IP SLAs operation, enter the no ip sla operation-number global configuration command. This example shows how to configure a UDP jitter IP SLAs operation:
Switch(config)# ip sla 10Switch(config-ip-sla)# udp-jitter 172.29.139.134 5000Switch(config-ip-sla-jitter)# frequency 30Switch(config-ip-sla-jitter)# exitSwitch(config)# ip sla schedule 5 start-time now life foreverSwitch(config)# endSwitch# show ip sla configuration 10IP SLAs, Infrastructure Engine-II.Entry number: 10Owner:Tag:Type of operation to perform: udp-jitterTarget address/Source address: 1.1.1.1/0.0.0.0Target port/Source port: 2/0Request size (ARR data portion): 32Operation timeout (milliseconds): 5000Packet Interval (milliseconds)/Number of packets: 20/10Type Of Service parameters: 0x0Verify data: NoVrf Name:Control Packets: enabledSchedule:Operation frequency (seconds): 30Next Scheduled Start Time: Pending triggerGroup Scheduled : FALSERandomly Scheduled : FALSELife (seconds): 3600Entry Ageout (seconds): neverRecurring (Starting Everyday): FALSEStatus of entry (SNMP RowStatus): notInServiceThreshold (milliseconds): 5000Distribution Statistics:Number of statistic hours kept: 2Number of statistic distribution buckets kept: 1Statistic distribution interval (milliseconds): 20Enhanced History:Analyzing IP Service Levels by Using the ICMP Echo Operation
The ICMP echo operation measures end-to-end response time between a Cisco device and any devices using IP. Response time is computed by measuring the time taken between sending an ICMP echo request message to the destination and receiving an ICMP echo reply. Many customers use IP SLAs ICMP-based operations, in-house ping testing, or ping-based dedicated probes for response time measurements between the source IP SLAs device and the destination IP device. The IP SLAs ICMP echo operation conforms to the same specifications as ICMP ping testing, and the two methods result in the same response times.
Note
Beginning in privileged EXEC mode, follow these steps to configure an ICMP echo operation on the source device:
To disable the IP SLAs operation, enter the no ip sla operation-number global configuration command. This example shows how to configure an ICMP echo IP SLAs operation:
Switch(config)# ip sla 12Switch(config-ip-sla)# icmp-echo 172.29.139.134Switch(config-ip-sla-echo)# frequency 30Switch(config-ip-sla-echo)# exitSwitch(config)# ip sla schedule 5 start-time now life foreverSwitch(config)# endSwitch# show ip sla configuration 22IP SLAs, Infrastructure Engine-II.Entry number: 12Owner:Tag:Type of operation to perform: echoTarget address: 2.2.2.2Source address: 0.0.0.0Request size (ARR data portion): 28Operation timeout (milliseconds): 5000Type Of Service parameters: 0x0Verify data: NoVrf Name:Schedule:Operation frequency (seconds): 60Next Scheduled Start Time: Pending triggerGroup Scheduled : FALSERandomly Scheduled : FALSELife (seconds): 3600Entry Ageout (seconds): neverRecurring (Starting Everyday): FALSEStatus of entry (SNMP RowStatus): notInServiceThreshold (milliseconds): 5000Distribution Statistics:Number of statistic hours kept: 2Number of statistic distribution buckets kept: 1Statistic distribution interval (milliseconds): 20History Statistics:Number of history Lives kept: 0Number of history Buckets kept: 15History Filter Type: NoneEnhanced History:Monitoring IP SLAs Operations
Use the User EXEC or Privileged EXEC commands in Table 42-1 to display IP SLAs operations configuration and results.
