Last updated: May 2011
Overview
Q. What is the Cisco IOS IP Service Level Agreement (SLA) feature?
A. Cisco IOS IP SLA is a feature that allows a Cisco IOS device to perform network performance measurements between Cisco Systems® devices. It allows Cisco customers to understand IP service levels for IP applications and services, increase productivity, lower operational costs, and reduce the frequency and length of network outages. Cisco IP technology and IP SLAs are converging and extending IP performance monitoring to be application aware, which is critical for new IP network applications such as Voice over IP (VoIP), audio and video, Enterprise Resource Management (ERP), Customer Relationship Management (CRM), Material Requirements Planning (MRP), and VPN virtualization (such as VPNs). To be effective, performance SLA measurements within an IP network must be end -to -end, and embedded for accuracy, flexibility, and cost-effectiveness. Cisco IOS IP SLAs uses unique service-level assurance metrics and methodologies to provide highly accurate, precise service-level assurance measurements. It allows the user to verify service guarantees, increases network reliability by validating network performance, proactively identifies network issues, and eases the deployment of new IP services.
Cisco IOS IP SLA uses active traffic monitoring-the generation of synthetic traffic in a continuous, reliable, and predictable manner-for measuring network performance. Cisco IOS IP SLAs actively sends data across the network to measure performance between multiple network locations or across multiple network paths. It uses the timestamp information to calculate performance metrics such as jitter, latency, network, and server response times, packet loss, and mean opinion score.
Q. How can Cisco customers use Cisco IOS IP SLA?
A.
• Performance visibility for VoIP, video, business-critical applications, Multiprotocol Label Switching (MPLS), and VPN networks
• Service-level agreement monitoring
• Network performance monitoring
• IP service network health readiness or assessment
• Edge-to-edge network availability monitoring
• Business-critical applications performance monitoring
• Network operation troubleshooting
Q. What benefits will customers realize with Cisco IOS IP SLA?
A.
• Enables customers to deploy new applications and services with complete confidence. Performance visibility, reduced deployment time for new applications, enhanced acceptance of business-critical services, and proactive identification of issues enforce higher reliability.
• Verifies and monitors Quality of Service (QoS) and differentiates service levels.
• Creates higher end-user confidence and satisfaction.
• Continuously, reliably, and predictably measures network performance.
Q. Why is Cisco IOS IP SLA unique in the market?
A. Performance measurement has been available for many years, but the combination of IP services, end-to-end measurement, and application awareness is unique to Cisco IP SLA, and superior to the traditional approach. The traditional SLA is fixed circuit and point to point, in no way indicative of the end-to-end experience of the end user and the user's IP application.
Q. What is a service-level agreement?
A. A Service-Level Agreement (SLA) is a contract between the network provider and its customers, or between an IT department and internal corporate customers. It provides a form of guarantee to customers with regard to the level of user experience.
Typically, an SLA contains the following levels of guarantee:
• Network availability (for example, 99 percent of the time)
• Network performance (for example, the round-trip delay is less than three seconds 95 percent of the time)
• Latency, jitter, packet loss, Domain Name System (DNS) lookup time, and website response time
• Help desk hours (for example, 24 hours a day)
• Trouble response time (for example, within three hours)
• Resolution time (for example, within one day)
• Reimbursement schedule if any of the thresholds is violated
Q. Is Cisco IOS IP SLA an IETF standard?
A. Work is under way, and standardization is planned. Many of the protocols used by IP SLA are currently IETF or ITU standards, such as IP SLA Y.1731 is ITU-T Y.1731 and IP SLA TWAMP is based on IETF RFC5357.
Q. What Cisco hardware supports Cisco IOS IP SLA?
A. All Cisco hardware that runs Cisco IOS Software supports Cisco IOS IP SLAs.
Q. How do customers benefit from providing SLA to their customers?
A. The network has become increasingly critical for customers, and any downtime or degradation can adversely impact revenue. Companies need some form of predictability with regard to IP services, regardless of the cost. An SLA provides well-defined expectations for the provider of the SLA and the customer. The IT department can use the SLA to verify that the service provider is meeting its own SLAs and will thus induce payback for violations. Service providers experience higher profit margins, enhanced customer satisfaction and retention, and a better competitive position. The IT department has the capability to define service levels for critical business applications. Its effectiveness is largely judged by network efficiency and user experience. An SLA can also be used as the basis for planning budgets and justifying network expenditures. Administrators can ultimately reduce the mean time between failures by proactively isolating network issues, and increase network uptime by decreasing mean time to repair.
Measurements And Calculations
Q. What type of measurements can Cisco IOS IP SLAs perform?
A.
Table 1. Cisco IOS IP SLAs Operations and Applications
Q. What applications from Cisco and other companies use Cisco IOS IP SLA measurements?
A. Many of the major performance-monitoring applications used in networks support Cisco IOS IP SLAs. When a third-party application uses Cisco IOS IP SLA to collect or configure measurements, it generally uses Simple Network Management Protocol (SNMP) for the interface.
For additional information, please visit http://www.cisco.com/go/ipsla/.
General Information
Q. What is the Cisco IOS IP SLA Responder?
A. When a Cisco Router has been designated to reply to Cisco IOS IP SLA test packets, configuring it to be a Cisco IOS IP SLA Responder provides greater accuracy in the measurements. The responder can utilize MD5 authentication for securing the control protocol exchange.
After the initial exchange, the responder can listen to Cisco IOS IP SLA test packets in the port requested by the Cisco IOS IP SLA source. Upon receiving the test packets, it captures the timestamps when the packets arrive, as well as when the replies leave. These timestamps help the Cisco IOS IP SLA source to make accurate assessments on one-way delay and the processing time in the target routers.
Cisco IOS IP SLA Responder can be enabled for the following operations:
• UDP Echo
• UDP Jitter
• TCP Connect
• Application Performance Monitor
• Video Operations
Q. How can Cisco IOS IP SLA troubleshoot the network?
A. Cisco IOS IP SLA can be configured with thresholds. When the performance level crosses the thresholds, Cisco IOS IP SLAs can generate SNMP traps to notify applications. This helps to detect potential problems. IP SLA can be used in conjunction with Embedded Event Manager (EEM) to perform other proactive troubleshooting actions such as detecting failed links and failing over to a backup link.
Additionally, a network administrator can obtain hop-by-hop performance information using Cisco IOS IP SLA ICMP Path Echo and Path Jitter operations. This isolates any performance bottleneck.
Q. What is a dedicated (shadow) SLAs router? What are the benefits?
A. The dedicated or SLAs router is used exclusively for Cisco IOS IP SLA operations and is connected to the edge routers to simulate the customer network traffic. It is typically a Cisco 1900, 2800, 2900, 3800, 3900 or 7200 Series Router. Cisco IP SLA routers are particularly useful for Point-Of-Presence (POP) or hub sites to gain access to router monitoring, which requires thousands of Cisco IOS IP SLA probes.
A dedicated router reduces the resource impact on primary routers. It enables the upgrade of Cisco IOS IP SLA features without affecting normal operations and is independent from Cisco IOS Software images in the production network.
Q. How can Cisco IOS IP SLA monitor different classes of services?
A. Cisco IOS IP SLA can be configured to monitor different classes of services, if the Differentiated Services Code Point (DSCP) bits are configured with the TOS command.
This command is supported by all Cisco IOS IP SLA operations. The feature is available in Cisco IOS Release 12.2T and all subsequent releases.
Q. What is IP SLA Video Operations (VO)?
A. IP SLA VO is a new type of operation that provides a realistic representation of video traffic. Cisco will initially include profiles that represent Cisco IP cameras for video surveillance, IPTV (unicast-only) and Telepresence.
Q. What platforms is IP SLA Video Operations (VO) supported on?
A. The Cisco Catalyst 3000 switches with Cisco IOS 12.2(58)SE software.
Q. How is round-trip delay calculated?
A. This represents the time between sending the test packet and receiving a reply, subtracting the processing time on the source and end routers. Round-trip delay is calculated by recording the timestamps.
The processing time on the end routers is only assessed for operations that involve the responder, which will increase the accuracy of round trip time measurements as compared to traditional ICMP ping measurements.
Q. How is one-way delay calculated?
A. One-way delay is the time delta of the time the test packet goes out and the time when the test packet arrives at the responder.
The UDP Jitter Operations are the only operations that can compute one-way delay measurement. The end router must enable the Cisco IOS IP SLA responder, as well as the time-synchronization of the source and end routers. The time synchronization is usually implemented with Network Time Protocol (NTP) and an accurate reference clock for timing.
Q. How is jitter calculated?
A. Jitter is the variance of delay. The Cisco IOS IP SLA jitter operation sends out multiple packets with equal time spacing between each interval. The jitter is then calculated as the variance of the round-trip delay measurements. One-way jitter is possible without using time synchronization of the clocks.
UDP Jitter and ICMP Path Jitter operations can measure jitter. The minimum number of packets for measuring jitter is three; however, ten is the default, with twenty ms time spacing.
Q. Why do I get different Mean Opinion Scores (MOS) using the UDP Jitter and RTP probes?
A. UDP Jitters uses MOS-CQ (based on packet loss and jitter) and R-Factor (which is not displayed) to calculate the MOS score while RTP uses MOS-CQ (based on packet loss and jitter) and MOS-LQ (which is reported by the DSP).
Q. How can measurement information be retrieved from Cisco IOS IP SLA?
A. The measurement can be retrieved using Cisco IOS Command Line Interface (CLI) or SNMP. The measurements are stored in the RTTMON MIB. The SNMP MIB is available at: http://tools.cisco.com/ITDIT/MIBS/servlet/index
Q. How granular are Cisco IOS IP SLA performance measurements?
A. Submillisecond (ms) and microsecond (usec) accuracy is available. Microsecond (usec) precision was introduced in Cisco IOS 12.3(14)T. Note that the microsecond (usec) display changes the granularity of the display and does not increase accuracy.
Q. Why does the UDP Jitter operation obtain more accurate measurements than operations based on Internet Control Message Protocol (ICMP)?
A. The UDP Jitter operation uses the responder that provides information on the processing delay in the end router. It then subtracts that information from both the one-way and round-trip measurements. Tests have shown that processing delay for a router under load can produce large inaccuracies when using ICMP. The tests show inaccuracy by as much as 30 times the actual delay measurement.
Q. What methods are available to monitor service-level performance?
A. There are two primary dimensions to performance monitoring: where and how the measures are completed.
A measurement may reside in a dedicated appliance. This approach allows network providers to monitor a given link by deploying hardware-based probes next to both the source and target routers. While it is feasible to monitor performance between a limited number of routers, it is cost prohibitive to monitor hub-to-CPE, as the number of CPEs tends to be large.
Cisco IOS IP SLA is embedded in Cisco IOS Software. By including the measurement capabilities in the router, the Cisco IOS IP SLA approach eliminates the need to deploy additional appliances. Therefore, there is no additional cost, training, or maintenance to deploy the solution. Since it is supported in almost all Cisco hardware, it is possible to monitor any connection. There is no additional appliance to deploy and therefore no additional cost.
Q. To what extent does Cisco IOS IP SLA impact CPU utilization or memory?
A. As Cisco IOS IP SLA is a software-based measurement, it does consume CPU usage and memory.
Table 2. UDP-Echo Probe Running Eng 3-Cisco IOS Software Release 15.1(4)M
Default Parameters: Frequency (60secs), Request Size (32bytes)
Table 3. UDP-Jitter Probe Running Eng 3-Cisco IOS Release 15.1(4)M
Default Parameters: Frequency (60secs), Request Size (32bytes), Packet Interval (20ms), Number of Packets (10)
Table 4. UDP-Jitter Probe for VoIP (G.729a) Running Eng 3-Cisco IOS Release 15.1(4)M
Default Parameters: Frequency (60secs), Codec Packet Size (32bytes), Codec Interval (20ms), Codec Number of Packets (1000)
Table 5. Cisco IOS IP SLAs Memory Usage
Q. What MIB should I use for IP SLA, and where do I find it?
A. Use the RTTMON-MIB: ftp://ftp.cisco.com/pub/mibs/v2/CISCO-RTTMON-MIB.my
Q. What debug commands can be run for troubleshooting?
A. On a source router, run "debug ip sla trace" and "debug ip sla error". Further information is available in the IOS documentation: http://www.cisco.com/go/ipsla/
Q. What is a good deployment guide for Cisco IOS IP SLA?
A. For deployment information, please see the Cisco IOS IP SLA user guide at http://www.cisco.com/go/ipsla/.
Q. What are the IP SLA Engine versions?
A. The initial version of IP SLA (Engine-I) was introduced in Cisco IOS Release 12.0(5)T. IP SLA Engine-II was introduced in Cisco IOS Release 12.2(15)T2, 12.3(3) and 12.2(25)S. The latest IP SLA Engine-III is available in Cisco IOS Release 15.1(1)T.
Q. What is new with IP SLA Engine III?
A. IPSLA Engine 3 brings template based CLI, QoS integration and end-point auto discovery and registration as well as significant performance increases for IPSLA responder.
Thresholds
Q. What is the benefit of setting thresholds?
A. Setting a threshold allows network administrators to remotely monitor network performance. If the threshold is violated, Cisco IOS IP SLA generates an SNMP trap to the application.
Q. What conditions or thresholds can be set in Cisco IOS IP SLA for SNMP traps?
A. Cisco IOS IP SLA can generate SNMP traps for timeout, threshold violation, loss of connection, and data verification error (the data in source packet and reply are not the same). Available thresholds include round trip delay, average jitter, and connection loss and for one-way jitter, packet loss and latency, and MOS VoIP scoring.
Security
Q. How secure is Cisco IOS IP SLA?
A. The Cisco IOS IP SLA control protocol can be configured with MD5 authentication.
Q. What is the control protocol used to secure Cisco IOS IP SLA?
A. The Cisco IOS IP SLAs control protocol is a proprietary protocol for initial exchange between the Cisco IOS IP SLA source and the responder. With this exchange, the Cisco IOS IP SLA source can specify which port the responder should listen to for a particular operation.
Note that this port is capable of listening to multiple operations, and will thus be disabled after the operation is completed. IP SLA uses port 1167 as the control port and security firewalls may need to be configured to allow this port.
Configuration and Operation Information
Q. Can configuration variables be changed while the operation is running?
A. Configuration parameters cannot be changed while the operation is running, as it would adversely impact the data storage. It is therefore recommended to configure an `ageout' in the `ip sla schedule' command, if operations may be changed in the future.
Q. How can an operation be stopped once it has been configured to run "forever"?
A. This is not possible, so it is advisable to configure a specific time, rather than "forever".
Example:
*ip sla 1
icmp-echo ip 10.2.20.20
frequency 3600
ip sla schedule 1 start-time 12:00 life 864000
In this example, the operation will run for ten days.
* The phase 1 implementation of the CLI is available in Cisco Software IOS Release 12.4M. The IP SLAs CLI described will be implemented in three phases across Cisco Software IOS Release 12.4T releases.
Q. How does Cisco IOS IP SLAs account for processing delay in the routers?
A. The delay in the source router is always eliminated, while the delay in the end router is only eliminated when the responder is used. Therefore, measurements such as UDP Jitter, TCP Connect, and UDP Echo benefit by using the enhanced accuracy of the responder.
Q. What processing delay does Cisco IOS IP SLA remove?
A. There are three processing delays in both the source and the destination routers:
• Ingress Queue: time from when the packet arrives at the router until Cisco IOS IP SLA receives it
• Cisco IOS IP SLAs Processing: time it takes for Cisco IOS IP SLA to process the packet
• Egress Queue: time from when the packet leaves Cisco IOS IP SLA until it is physically sent
Cisco IOS IP SLAs takes out the ingress queuing time and the Cisco IOS IP SLA processing time in the source. If the Cisco IOS IP SLA operation involves the responder, then the ingress queuing time and the responder processing time in the destination are also removed.
Q. How can the CLI statistics for the UDP Jitter operation be interpreted?
A. The show ip sla statistics command displays the current state of the Cisco IOS IP SLA operation. The following is a show output example for the UDP Jitter operation, and the explanation:
Router#sh ip sla statistics 15
Round trip time (RTT) Index 15
Latest RTT: 1 ms
Latest operation start time: *05:43:28.720 UTC Fri May 28 2004
Latest operation return code: OK
Round Trip Time milliseconds
Number Of RTT: 10
RTT Min/Avg/Max: 1/1/1
Latency one-way time milliseconds
Number of one-way Samples: 0
Source to Destination one way Latency Min/Avg/Max: 0/0/0
Destination to source one way Latency Min/Avg/Max: 0/0/0
Jitter time milliseconds
Number of Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 20/20/23
Destination to Source Jitter Min/Avg/Max: 0/0/0
Packet Loss Values
Loss Source to Destination: Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Number of successes: 1
Number of failures: 0
Operation time to live: 3567 sec
* The phase 1 implementation of the CLI is available in Cisco IOS Software Release 12.4M. The IP SLAs CLI described will be implemented in three phases across Cisco IOS Software Release 12.4T releases.
Q. Why am I seeing "tail drops" in the output from "show ip sla stat"?
sh ip sla stat 2110
IPSLAs Latest Operation Statistics
IPSLA operation id: 2110
Type of operation: udp-jitter
Latest RTT: 1 milliseconds
Latest operation start time: 19:29:34.155 EDT Mon Apr 4 2011
Latest operation return code: OK
RTT Values:
Number Of RTT: 863 RTT Min/Avg/Max: 1/1/2 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 854
Number of DS Jitter Samples: 855
Source to Destination Jitter Min/Avg/Max: 0/1/2 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/1/2 milliseconds
Packet Loss Values:
Loss Source to Destination: 1
Source to Destination Loss Periods Number: 1
Source to Destination Loss Period Length Min/Max: 1/1
Source to Destination Inter Loss Period Length Min/Max: 153/721
Loss Destination to Source: 11
Destination to Source Loss Periods Number: 7
Destination to Source Loss Period Length Min/Max: 1/3
Destination to Source Inter Loss Period Length Min/Max: 2/371
Out Of Sequence: 0 Tail Drop: 125
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 15
MOS score: 3.92
Number of successes: 1
Number of failures: 0
Operation time to live: Forever
A. Tail drops are an indication that the IP SLA device is stressed beyond its capacity. Reduce the number of operations, packets per second speed by increasing the packet size of the probes and monitor the results.
Q. Is there any limit to the number of operations that can be configured on a router?
A. The number of operations is limited only by memory and CPU consumption.
Q. How can the operations supported on a router, as well as the current Cisco IOS Software release, be identified?
A. Enter show ip sla application, and the output will list the supported operations.
Q. If continuous monitoring of a link is necessary, what is the best time interval between operations?
A. That depends on the necessary frequency of monitoring. Cisco IOS IP SLA does consume CPU and memory. Most deployments use five minute intervals, but some have spacing of as little as one, or as much as fifteen, minutes.
Q. What is the default port number and type of proxy server for HTTP probes?
A. The default port number for HTTP is 80. The proxy server type is unspecified.
Q. What is the port number for the UDP Echo operation?
A. The default port number for UDP Echo is 7.
Q. Why are the one-way delay values zero in the output of show commands?
A. There must be time synchronization between the source and the target.
Cisco IOS IP SLA calculates whether or not the one-way delay is reasonable. If the sum of the source-destination and destination-source times is within ten percent of the round-trip time, keep the one-way values, presuming that the clocks are synchronized accurately.
Note: If the round-trip time is very small, it is more likely to be outside of the ten percent range.
If the network is running NTP to provide clock to the source and destination, use the "show ntp status" command to check.
Q. Why are FTP probes unable to find the configured files?
A. The file name portion of the URL is unique in this situation.
Example 1:
• URL: ftp://user:pass@server/some/file.txt
• The file the router is trying to access in reality is:
/home/user/some/file.txt (assuming /home/user is the home directory)
Example 2:
• URL syntax:
ftp://user:pass@server//some/file.txt
• File is accessed by its absolute path, rather than its relative path. Note the two slashes. This will retrieve the file /some/file.txt.
Q. How do I clear counters on IP SLA?
A. In the configuration parser issue the command "ip sla restart <ID>".
Example:
IPSLA#conf t
Enter configuration commands, one per line. End with CNTL/Z.
IPSLA(config)#ip sla restart ?
<1-2147483647> Entry Number
Q. Why is the jitter value larger than the RTT values?
A. Check the interface input queues on the responder as well as the input and output queues on the sender to see if the queues are not being processed quickly enough. Queue processing may impact the jitter values.
Q. What does the output "Latest Operation Return Code: timeout" mean in a show command?
Router#sh ip sla statistics 15
Round trip time (RTT) Index 15
Latest RTT: 1 ms
Latest operation start time: *05:43:28.720 UTC Fri May 28 2004
Latest operation return code: Timeout ⇐= Opcode Value
.....
A. There are various possible return codes that can be displayed. Some of the more common return codes are listed below.
[Timeout] The response for the operation packet did not come in the expected time. The default timeout is five seconds for an echo operation. If a target device is down, or the reply comes after five seconds due to network congestion, it will be considered a timeout.
[No Connection] This is an indication that the destination does not exist (invalid IP address or unreachable) or responder is not enabled.
[Over Threshold] The timestamp delta (receive time - send time) is greater than the provisioned timeout value. If NTP is not configured, this value is meaningless.
[Authentication Failure] Either the sender or the responder is missing the correct key-chain.
[Format failure] Control message incompatibility between sender and responder.