Cisco IOS® IP Service Level Agreements (SLAs) allow users to monitor network performance between Cisco routers or from either a Cisco router to a remote IP device.
This user guide focuses on Cisco IOS IP SLAs features, and it covers usage and configuration guidelines, and explains how to retrieve data from Cisco IOS IP SLAs functionality. Configuration examples include both Command Line Interface (CLI) and Simple Network Management Protocol (SNMP). This document is a supplement to Cisco IOS Software technical documentation.
Cisco IOS IP SLAs capabilities:
• Voice-over-IP (VoIP), video, and VPN network monitoring
• SLA monitoring
• Network performance monitoring and network performance visibility
• IP service network health readiness or assessment
Cisco IOS IP SLAs is a network performance measurement and diagnostic tool that uses active monitoring, which includes the generation of traffic in a continuous, reliable, and predictable manner. 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 MOS voice quality scores. The user defines an IP SLAs operation (probe) within Cisco IOS Software using the SNMP MIB or CLI. The measurement characteristics include packet size, packet spacing, protocol type, DSCP marking, and other parameters. The operation is scheduled to generate traffic and retrieve performance measurements. The data from the Cisco IOS IP SLAs operation is stored within the RTTMON MIB and available within CLI for Network Management System applications to retrieve network performance statistics. Users can schedule a Cisco IOS IP SLAs operation at any point in time or continuously over any time interval. Cisco IOS IP SLAs is configured to monitor per-class traffic over the same link by setting the Diff-Serv Code Point (DSCP) bits.
A destination router running Cisco IOS Software is configured as a Cisco IOS IP SLAs Responder, which processes measurement packets and provides detailed timestamp information. The responder can send information about the destination router's processing delay back to the source Cisco router. Uni-direction measurements are also possible using Cisco IOS IP SLAs.
Cisco IOS IP SLAs provides a proactive notification feature with an SNMP trap. Each measurement operation can monitor against a pre-set performance threshold. Cisco IOS IP SLAs generates an SNMP trap to alert management applications if this threshold is crossed. Several SNMP traps are available: round trip time, average jitter, one-way latency, jitter, packet loss, MOS, and connectivity tests. Administrators can also configure Cisco IOS IP SLAs to run a new operation automatically when the threshold is crossed. For instance, when latency exceeds a threshold this can trigger a secondary operation to measure hop-by-hop latency to isolate the problem area in the network. Examples of thresholds and triggers are available later in this document.
AN INTRODUCTION TO SLAS MONITORING
Overview
Enterprises are under increasing pressure to offer SLAs to their internal customers or other departments or verify and measure outsourced SLAs. Service providers have an incentive to offer service level agreements, improve customer satisfaction, and guarantee their customers certain service levels. Management requires contractual assurance that the network will meet business objectives, while end users want some assurance that their critical network applications and services will be available as needed. An SLAs or service level verification is often required before a company will deploy a new technology, business critical applications, or IP service, such as voice over IP (VoIP).
It has become increasingly complicated to deliver SLAs. It can be difficult to determine exactly what to monitor, how to take measurements, and how frequently to collect data. With the proliferation of heterogeneous and multi-service networks, it is also difficult to monitor the service from end-to-end. The challenge is compounded by the need to demarcate the timing of problems and to provide customers with reports at the appropriate level of granularity. Cisco IOS IP SLAs ease the burden of measuring network service levels.
Defining the SLA Requirements
When developing SLAs, it is critical that customers focus on translating business objectives to SLAs, so that tangible service metrics are measured, reported, and validated. Long, complex, and unrealistic agreements are often to blame when customers fail to manage by service level. They also have a tendency to fail to monitor the negotiated SLAs parameters.
A clear understanding of the objective is critical to begin monitoring service levels within any network. For example:
• Verify an SLAs that measures Service Provider latency
• Ensure that IP phones in an office are working properly
• Users are getting reasonable response times from an FTP server
While it is important for an end-to-end IP SLAs solution to provide summary information to management, it is also critical that administrators obtain detailed information about specific problem areas. The ability to demarcate what is causing the IP SLAs not to be met-whether it is a problem at the client end, at the server end, or in the network-is crucial.
Examples of Service-Level Contracts and SLAs
An SLAs is a key component of a service-level contract (SLC). The SLC specifies connectivity and performance agreements for an end-user service from a provider of service. The Service Provider could be within the Enterprise (ie: IS organization could be the Service Provider for internal departments), or an external company (ie: an ISP providing wide-area or hosted application services).
The SLC typically includes multiple SLAs, so a violation of any particular SLA could create a violation of the overall SLC. The SLC will outline the minimum level of service and the expected level of service. If the expected level of service is violated multiple times, it can lead to an overall violation.
The service-level management solution needs to provide a means to manage collections of agreements that constitute a contract. The solution should enable the user to monitor multiple SLCs individually, drill down into SLAs details, and monitor the percentage of SLAs conformance for a given SLC. There is typically an expected service level and a minimum service level. The expected service level is what is contracted and needed to give good performance, and the minimum service level will certainly give poor service performance. So for instance if service drops below 90% of the expected service for x number of times over a specified time period this would constitute a violation of the SLA.
Figure 2.SLA Service Level Violation Graph
For example, an SLC for connectivity from several branch sites to the central site may be outlined as "a connection of 64 Kbps with the average latency of 100ms over 1 month. This average latency would be an expected service level. The minimum service would insure when average latency was over 500ms for a day.
End-to-end SLCs are usually defined and monitored by performance- and fault management applications. Cisco IOS IP SLAs provides the details per measured SLAs.
HOW TO MONITOR A NETWORK WITH CISCO IOS IP SLAS
Cisco IOS IP SLAs can be used for network access, troubleshooting, QoS verification, and service level monitoring. Several items need to be resolved before deciding when to monitor the network performance and service levels.
What is the primary goal of the measurements? Which metrics are important to monitor? In other words, at what days and times are measurements needed?
The second step is to make a broad assessment of traffic patterns within the network. When packet samples are distributed and measured more frequently, network traffic patterns are more reliable. More points mean that information is more accurate. Active measurements should mimic the type of traffic run on the network; for example, the correct packet size, spacing an interval to mimic a VoIP Codec.
Scenario 1: Measure Data Traffic Performance from the Branch to Central Office
Figure 3. Network for Scenario 1
An Enterprise customer has one central headquarters site along with two branch offices. One of the branch offices is communicating via a dedicated FR circuit (256 kbps), while the second branch office is accessing the corporate headquarters using a WAN link through the public Internet via a VPN.
Client stations in both branch offices require access to a central web server at the corporate headquarters. For example, corporate can claim to provide server 99.95% availability with a response time of no greater than 50ms. For the branch office accessing the servers via the Internet, corporate headquarters provides a latency SLA of no more than 100ms. Based on this data, the Enterprise must consider how it can measure and verify that both branch offices are getting their agreed-upon service levels from corporate headquarters. Furthermore, if corporate is not meeting these service levels, what part or parts of the network are contributing to this degradation (ie: WAN links, client application, web server)?
Selecting the proper operation or measurement
The first step in SLAs deployment involves answering the question of what needs to be monitored. A variety of operation types are supported by Cisco IOS IP SLAs. The most common operation used is UDP jitter to measure IP performance and UDP performance-sensitive applications. In this example, the operations outlined are UDP echo, TCP Connect, and HTTP. Later examples will utilize UDP jitter.
UDP Echo Operation
The UDP Echo Operation measures end-to-end response time or connectivity between a Cisco router and IP devices. UDP is a network layer (Layer 3) Internet protocol that reports errors and provides other information relevant to IP packet processing. Response time is computed by measuring the time taken between sending the UDP echo request message to the destination and receiving an UDP echo reply. UDP echo accuracy is enhanced by using the IP SLAs responder at the destination Cisco router. Details about IP SLAs responder will be available later in the document.
TCP Connect Operation
The TCP Connect operation response time is computed by taking the difference between the times taken to request the TCP SYN and ACK replies. This result will be useful to test the connection to specific ports on headquarters servers from the branch.
HTTP Operation
The HTTP operation measures the round-trip time (RTT) taken to connect and access data from an HTTP server, which can be specified with a URL. The HTTP server response-time measurements consist of three types:
• DNS Lookup-RTT taken to perform domain name lookup
• TCP Connect-RTT taken to perform a TCP connect to the HTTP server
• HTTP Transaction Time-RTT taken to send a request and get a response back from the HTTP server for the complete Webpage or the first byte of the Webpage
Selecting the Proper Test Pair(s)
Selecting the proper test pairs can be the most difficult step in defining an appropriate SLA. Certain requirements must be considered before making this decision.
• The source device must be a Cisco device running Cisco IOS Software Release 12.0(5)T or later. Preferred Cisco IOS Software releases would be Release 12.4 Mainline and later releases.
• When using an IP SLAs operation, the destination device can be any IP device, but if a Cisco router is used, the accuracy can be improved with the Cisco IOS IP SLAs responder.
With these requirements in mind, the Enterprise can then concentrate on selecting device pairs that make sense. In general, the source device should be the router located at the edge, or the boundary where the Enterprise network meets the service provider's network. If there are other routers along the path that are also in the managed domain, then a device pair to source can be configured from these routers as well. Thus, users can obtain a more granular view of the service levels across the network.
Table 1. The following measurement end points were selected:
Source
Destination
Operation
Comment
C
D
UDP
A
B
UDP
B
Web server
HTTP
D
Web server
HTTP
A
Web server
HTTP
Optional
C
Web server
HTTP
Optional
B
Server
TCP Connect
D
Server
TCP Connect
This provides relevant details about the WAN connections as well as DNS lookup time, TCP connect and finally HTTP operations.
Selecting the Proper Payload
Payload is the actual size (in bytes) of the packet payload. This value corresponds to the payload, rather than the actual packet, size; depending on the protocol used, the size of the packet header will differ.
When determining the payload value, consider the Maximum Transmit Unit (MTU) value for packet fragmentation. By controlling the payload size in relation to the MTU, the number of packets sent out per sample is controlled. This value should be adjusted to find a value that best represents the actual size and number of typical packets traversing the network. The IP SLAs value to change the payload size is called request-data-size. The request-data-size changes the size of the payload of the IP packets.
The average packet size on the Internet is 260 bytes; the customer used this packet size.
Selecting the Proper Type of Service (ToS) Bit
As the customer has not yet implemented QoS, this feature was excluded from the described scenario.
Selecting the Proper Sampling Interval
The frequency with which the Cisco IOS IP SLAs send the active monitoring and sample packets configured depending on the needs and requirements of network bandwidth. Sampling may occur on a frequent basis in order to obtain the most accurate assessment of network service levels; unfortunately, this is not always feasible. For example, when monitoring across a more expensive WAN connection, the user might not want to create a large amount of traffic across the link.
It is also important to consider the active monitoring traffic is generated by the IP SLAs on a Cisco IOS Software device. Processing power might be a concern when a low-end Cisco router is used, or there is a huge amount of traffic passing through the router. In these cases, it would be necessary to cut down on the frequency of the sampling interval or use a dedicated SLA (aka: shadow) router to perform the IP SLAs operations.
For performance details, please refer to the section later in this document.
In this case the following sampling intervals were chosen:
• UDP: 60 sec
• HTTP: 300 sec
• TCP Connect: 30 sec
Selecting the Proper Thresholds
Service Providers do sometimes predefine performance thresholds. As part of an SLC, ISPs may provide SLAs that specify the amount of latency or a percentage of availability. If the terms of a particular SLA are more ambiguous, then it falls to the network administrator to decide what type of thresholds to select. Thresholds and traps can be set for response time, jitter calculations, and packet loss.
Realistic threshold examples:
• One way delay:
– West Europe-US West: 90 ms
– US West-US East: 30 ms
– Within West Europe: 40 ms
– West Europe-Africa: 150 ms
– West Europe-North Asia: 100 ms
As these data consider the carriers backbone only, we have to add the appropriate delay for the access network.
Table 2. The following measurement end points and threshold values were selected:
Source
Destination
Measurement
Threshold
A
B
Round-trip delay < 150 ms
Rising 150 ms and falling 100 ms
C
D
Round-trip delay < 200 ms
Rising 200 ms and falling 150 ms
A,B,C,D
Server
TCP Connect < 500 ms
Rising 500 ms and falling 200 ms
A,B,C,D
Web server
HTTP timeout 5 sec
Rising 2 s and falling 1 s
Implemented properly, IP SLA provides the required level of details to a network administrator. The upper-layer operations can verify the latency of the HTTP, DNS or DHCP application.
Scenario 2: Teleconferencing from Enterprise HQ to Branch Office
Figure 4. Network for Scenario 2
Selecting the proper operation
In Scenario 2, a business unit manager needs the ability to run a teleconferencing session across a data link to a branch office. The customer had already deployed QoS with three different classes. In this situation, the audio and video traveling across the network are extremely sensitive to inter-packet delay and packet loss; therefore, a jitter operation was selected for the VoIP class and a UDP operation was selected for the Business class traffic. No operations were defined for the best effort class.
Jitter / Voice over IP
The VoIP Jitter operation measures the variance in inter-packet delay in both directions (source to destination and destination to source). Cisco IOS IP SLAs will send out a series of packets with a specified interval. The time stamps and sequence numbers of those packets and the responses to those packets are collected and used to calculate the variance in the packet delay. This measurement is useful in verifying solid VoIP services and packet loss. Using the jitter operation requires the Cisco IOS IP SLAs responder feature enabled at the target Cisco device.
Jitter operations provide most information compared to other operations, such as:
• Jitter: source to destination, destination to source
• Packet loss: Source to destination, destination to source
• Round trip time
• One way delay if IP SLAs and responder clocks in sync (i.e. NTP is used)
• The jitter operation is the most accurate operation
• An Operation is defined as a sequence of packets (configurable) rather than one packet per polling interval
• Accounts and removes for processing in IP SLAs source and target
• MOS Voice Quality score and codec simulation (Release 12.3(4)T)
• One-way latency, jitter, packet loss and MOS, and Calculated Planning Impairment Factor (ICPIF) traps (Release 12.3(7)T)
Selecting the Proper Test Pair(s)
• Relevant routers: W, X, Y
• Branch office router: Z
• Operations: X to Z; Y to Z; W to Z
This enables the operator to monitor the performance of the network services with relevant details.
Selecting the Proper Payload
A packet size of 200 Byte was configured.
Selecting the Proper Type of Service (ToS) Bit
In some cases, different types of traffic may receive different levels of priority when passing through the network. For example, if an organization deems email traffic more important than Web traffic, it can set the precedence of email traffic to receive a higher priority than Web traffic.
Cisco IOS IP SLAs has the option to configure the ToS bits in the IP header. The ToS bits are four bits located within the ToS byte in the IP header. The active test traffic that is generated by the Cisco IOS IP SLAs can be subject to queuing or QoS prioritization policies. It is therefore logical that Cisco IOS IP SLAs can verify that these policies are being enforced if there are QoS policies implemented in the network. The DSCP bits needed to be converted to TOS bits and input in Cisco IOS IP SLA because the feature does not support DSCP values directly.
Table 3. Example for defining three different QoS classes:
Class
IP Precedence
DSCP
TOS
VoIP
101
40
160
Business class
100
32
128
Best Effort
000
00
000
Table 4. Example for defining five different QoS classes:
Class
IP Precedence
DSCP
TOS
VoIP
101
40
160
Video
100
32
128
VoIP Ctrl Traffic
011
24
096
Business class
001
08
032
Best Effort
000
00
000
Selecting the Proper Sampling Interval.
The following sampling interval for the active measurements was selected. Because the jitter operation is being used a stream of 10 packets of 64 bytes with 20ms spacing is being sent per operation at the frequencies shown below.
• X-Z: 60 sec
• Y-Z: 60 sec
• W-Z: 180 sec
Selecting the Proper Thresholds
There are no specific thresholds in this SLA, so the network manager must establish thresholds based on independent testing.
Table 5. Measurements and Thresholds Used for this Scenario
Source
Destination
Measurement
Threshold
X-Real time
Z
Round-trip delay < 100 ms
Jitter < 20ms
Rising 100 ms and falling 50 ms, timeout 3 sec
X-Mission Critical
Z
Round-trip delay < 500 ms
Rising 500 ms and falling 300 ms, timeout 5 sec
W-Real time
Z
Round-trip delay < 100 ms
Jitter < 20ms
Rising 100 ms and falling 50 ms, timeout 3 sec
W-Mission Critical
Z
Round-trip delay < 500 ms
Rising 500 ms and falling 300 ms, timeout 5 sec
Y-Real time
Z
Round-trip delay < 100 ms
Jitter < 20ms
Rising 100 ms and falling 50 ms, timeout 3 sec
Y - Mission Critical
Z
Round-trip delay < 500 ms
Rising 500 ms and falling 300 ms, timeout 5 sec
The ITU G.114 standard advises a one-way delay (phone to phone) below 150 ms as considered acceptable. Cisco suggests that jitter should not exceed 20-30 ms.
Scenario 3: Dedicated Router Scenario
Often a dedicated SLA router (or shadow router) can be used as the source of measurements. The dedicated router is used when the number of operations is extremely high (for example, thousands of measurements). Dedicated routers are often deployed in large hub and spoke networks at the hub site, and spokes just respond to the measurements. Many dedicated routers are also used in large service provider networks for point-of-presence (POP)-to-POP measurements or from the POP to the customer premises equipment (CPE) routers. This dedicated router topology allows scalability with a large number of endpoints. A dedicated router provides the benefit of polling a central source location. The destination access or CPE routers will only need the responder and will have a decreased load because they are only periodically responding to the source router's measurement packets. The responder is available in a wide range of Cisco IOS Software releases and is very backward compatible, allowing measurements for almost every Cisco IOS Software box in the network.The exception is for IP SLAs that are aware of VPN routing and forwarding (VRF), in which case the responder must be from Cisco IOS Software Release 12.2(2)T or above. The other exception is new operations that require a responder upgrades. The jitter, VoIP jitter, UDP echo, and TCP connect measurements any Cisco IOS Software Release supporting a responder can be used. There are several advantages to using a dedicated router:
• The dedicated router will be a central location to retrieve measurements from the SNMP MIB.
• The dedicated router has no production traffic and therefore will not be affected by any other features or loads imposed on the device.
• The source router can be updated frequently with new measurements without polling or writing to a traffic-forwarding device.
• SNMP write can be set up on the device, and security will not be as much of an issue because the box is not carrying customer traffic.
• Frequent releases of Cisco IOS Software, and therefore the latest feature set and measurements, are possible because the router is not carrying production traffic.
• The dedicated router can act as a very good Network Time Protocol (NTP) synchronization point, especially when it is a Cisco 7200 Series Router, which can have a Global Positioning Systems (GPS) clock connected to the auxiliary port for time synchronization. Time synchronization is needed for one-way measurements.
A unique feature of Cisco IOS IP SLAs is the ability to work within an MPLS network or RFC 2547 MPLS VPN network. IP SLAs have the ability to specify which VRF routing table is used for forwarding. This feature is used to send IP SLAs packets from a Cisco Router to another vendor's equipment supporting RFC 2547 or to send packets between Cisco routers in an MPLS/VPN network. It is possible for IP SLAs dedicated SLA router to act as a VPNv4 or Internal Border Gateway Protocol (iBGP) neighbor to forward packets to any customer CPE within the VPN network. Often the responder can be placed on a CPE.
MPLS VPN-aware IP SLAs:
VRF-aware operations support (Releases12.0(26)S, 12.2(25)S, and 12.2(2)T)
• ICMP Echo
• ICMP Path Echo
• UDP Echo
• ICMP Path Jitter
• UDP Jitter
The following architectures might be used within an MPLS/VPN network for monitoring:
1. Provider Edge Router (PE) PE-based VRF-aware IP SLAs operations producing PE-to-PE or PE-CE measurements
2. PE-based IP SLAs operations using the global routing table, which produces PE-to-PE measurements
3. PE-based IP SLAs operations for PE-to-CE measurements within a VRF
4. A dedicated SLA router used as an IBGP neighbor, allowing the router to participate in VPNs by using a dedicated route target for IP SLAs traffic and routing to CE routers within customer VPNs
5. A dedicated SLA router using IP SLAs, which utilize logical subinterfaces per VRF connected to a PE to perform PE-to-PE or PE to CE measurements
6. A dedicated SLA router with multi-VRF CE and multiple subinterfaces from the dedicated SLA router to the PE, producing PE-to-PE or PE-CE measurements
7. A dedicated SLA router with IP SLAs measurements using the global table for PE-to-PE measurement
8. A dedicated router with a specific VRF for POP-to-POP measurements and one VRF for the dedicated routers to communicate; the dedicated routers are placed in the POPs, producing PE-to-PE measurement
In general any of the PE-to-PE techniques outlined above may be combined with edge-to-edge (CE-to-CE) measurements. If the VPN topology is fully meshed and the number of sites is large, then the number of measurements for a full mesh of customer CEs may be prohibitive. Another method to avoid CE-based measurements is to have a series of measurements and what is called a hierarchical design; CE-to-PE and PE-to-PE measurements are separated. This obviously eliminates the need for a full mesh of CE-to-CE measurements and increases scalability of the Cisco IOS IP SLAs deployment. The hierarchical approach allows the PE or dedicated router to be dedicated as the source of IP SLAs traffic, and the CE device will only respond to the source for the performance measurement. A Cisco CE using an IP SLAs responder will have accurate measurements. The other advantage with this design is that the CE will only need to have a responder for UDP-based source-dedicated SLA routers, minimizing the resources consumed by the CE. Potentially round trip times can be summed to give an approximate answer for end-to-end measurement. Jitter measurements will be more of a problem and may not be accurate if broken into two separate measurements. The service provider SLA or performance measurements can be set up to accommodate the hierarchical IP SLAs design, simplifying operations for the customer.
Figure 5.IP SLAs RFC2547 MPLS VPN Topology Example
CISCO IOS IP SERVICE LEVEL AGREEMENTS CONFIGURATION AND OPERATIONS DETAILS
The following section outlines configuration and other detailed information about how to utilize Cisco IOS IP SLAs. The configuration of Cisco IOS IP SLAs has changed significantly in Release 12.3(14)T and above. The Cisco IOS IP Service Level Agreements Command Line Interface Overview outlines all the changes in the CLI that occurred before and after Release 12.3(14)T. The CLI changes are taking place over three phases. In general, the CLI used in this document is the phase 2 CLI that will release in late 2005.
The following configuration is an example of IP SLAs operation utilizing the configuration available in Releases 12.4 Mainline and 12.4T.
Configure a jitter test to destination 172.29.139.134 with 64 byte packets and 20ms packet spacing sending 20 packets per measurement. The operation is scheduled to start in 5 minutes.
ip sla monitor 1
type jitter dest-ipaddr 172.29.139.134 dest-port 5000 num-packets 20
ip sla monitor schedule 1 life 300 start-time after 00:05:00
The following is an example of the configuration that will be available in 12.4T in late 2005 and above and this format will be used throughout the document in examples.
ip sla 1
udp-jitter 172.29.139.134 5000 num-packets 20
ip sla schedule 1 life 300 start-time after 00:05:00
The following configuration is an example of IP SLAs operation utilizing the configuration available before Release 12.4 Mainline.
Configure a jitter test to destination 172.29.139.134 with 64 byte packets and 20ms packet spacing sending 20 packets per measurement. The operation is scheduled to start in 5 minutes.
Rtr 1
type jitter dest-ipaddr 172.29.139.134 dest-port 5000 num-packets 20
Routers may take tens of milliseconds to process incoming packets, due to other high-priority processes. This delay affects the response times computed by ping technologies, because the reply to test packets might be sitting on queue while waiting to be processed. Therefore, the response times would not accurately represent true network delays.
Cisco IOS IP SLAs responder minimizes these processing delays on the source router as well as on the target router in order to compute true round-trip times. It does so by time-stamping the test packets for Cisco IOS IP SLAs operations.
Responder and Cisco IOS IP SLAs Control Protocol
Cisco IOS IP SLAs Responder is a component embedded in the destination Cisco router whose functionality is to respond to Cisco IOS IP SLAs request packets. The responder adds timestamps to the echoed packets to allow unidirectional packet loss, latency, and jitter measurements to a Cisco device. The accuracy of the measurements is improved significantly if the responder is used.
The accuracy of Cisco IOS IP SLAs is much better than ICMP ping. The capability uses a patented control protocol between the source and destination devices by leveraging an Cisco IOS IP
-us-Technology_White_Paper-en-01.jpg)
-us-Technology_White_Paper-en-02.jpg)
-us-Technology_White_Paper-en-03.jpg)
-us-Technology_White_Paper-en-04.jpg)
-us-Technology_White_Paper-en-05.jpg)