CCNP SWITCH 642-813: IP Service Level Agreement (SLA)
- Configuring IP SLA
- Defining and Running an IP SLA Test Operation
- Using IP SLA
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Cisco IOS IP Service Level Agreement (IP SLA) feature can be used to gather realistic information about how specific types of traffic are being handled end-to-end across a network. To do this, an IP SLA device runs a preconfigured test and generates traffic that is destined for a far end device. As the far end responds with packets that are received back at the source, IP SLA gathers data about what happened along the way.
Configuring IP SLA
IP SLA can be configured to perform a variety of tests. The simplest test involves ICMP echo packets that are sent toward a target address, as shown in Figure 1. If the target answers with ICMP echo replies, IP SLA can then assess how well the source and destination were able to communicate. In this case, the echo failures (packet loss) and round trip transit (RTT) times are calculated, as shown in the following example:
Switch#show ip sla statistics aggregated
Round Trip Time (RTT) for Index 1
Type of operation: icmp-echo
Start Time Index: 15:10:17.665 EDT Fri May 21 2010
RTT Values
Number Of RTT: 24
RTT Min/Avg/Max: 1/1/4 ms
Number of successes: 24
Number of failures: 0
){kind=small}
Figure 1 IP SLA ICMP Echo Test Operation
For the ICMP echo test, IP SLA can use any live device at the far end. After all, most every networked device will reply when it is pinged. IP SLA can also test some network protocols, such as DNS, by sending requests to a server at the far end. Cisco IOS is needed only at the source of the IP SLA test, as the far end is simply responding to ordinary request packets.
However, IP SLA is capable of running much more sophisticated tests. Table 1 shows some example test operations that are available with IP SLA.
To leverage its full capabilities, Cisco IOS IP SLA must be available on both the source and the target devices, as shown in Figure 2. The source device handles the test scheduling and sets up each test over a special IP SLA control connection with the target device. The source generates the traffic involved in a test operation, and analyzes the results as packets return from the target. The target end has a simpler role: respond to the incoming test packets. In fact, the target device is called an IP SLA Responder.
){kind=small}
Figure 2 IP SLA UDP Jitter Test Operation
The responder must also add timestamps to the packets it sends, to flag the time a test packet arrived and the time it left the responder. The idea is to account for any latency that is incurred while the responder is processing the test packets. For this to work accurately, both the source and responder must synchronize their clocks through Network Time Protocol (NTP).
Table 1—IP SLA Test Operations
|
Test Type |
Description |
IP SLA Required on Target? |
icmp-echo |
ICMP Echo response time |
No |
path-echo |
Hop-by-hop and end-to-end response times over path discovered from ICMP Echo |
No |
path-jitter |
Hop-by-hop jitter over ICMP Echo path |
Yes |
dns |
DNS query response time |
No |
dhcp |
DHCP IP address request response time |
No |
ftp |
FTP file retrieval response time |
No |
http |
Web page retrieval response time |
No |
udp-echo |
End-to-end response time of UDP echo |
No |
udp-jitter |
Round trip delay, one-way delay, one-way jitter, one-way packet loss, and connectivity using UDP packets |
Yes |
tcp-connect |
Response time to build a TCP connection with a host |
No |
An IP SLA source device can schedule and keep track of multiple test operations. For example, an ICMP echo operation might run against target 10.1.1.1, while UDP jitter operations are running against targets 10.2.2.2, 10.3.3.3, and 10.4.4.4. Each test runs independently, at a configured frequency and duration.
What in the world does this have to do with LAN switching? And why would you want to run IP SLA on a Catalyst switch anyway? Here’s a two-fold answer:
- IP SLA will likely appear on your SWITCH exam.
- IP SLA is actually a useful tool in a switched campus network.
In order to run live tests and take useful measurements without IP SLA, you would need to place some sort of probe devices at various locations in the network[md]all managed from a central system. With IP SLA, you don’t need probes at all! Wherever you have a Catalyst switch, you already have an IP SLA “probe.”
By leveraging IP SLA test operations, you can take advantage of some fancy features:
- Generate SNMP traps when certain test thresholds are exceeded
- Schedule further IP SLA tests automatically when test thresholds are crossed
- Track an IP SLA test to trigger a next-hop gateway redundancy protocol, such as HSRP
- Gather voice quality measurements from all over a network