Home > Articles > Cisco > CCNP Routing and Switching

CCNP SWITCH 642-813: IP Service Level Agreement (SLA)

  • Print
  • + Share This
A key topic on the CCNP SWITCH exam, 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. . In this article, expert network architect and author of best-selling CCNP SWITCH 642-813 Official Certification Guide Dave Hucaby shows you how to configure IP SLA to perform a variety of tests and to use IP SLA to make certain switch features change behavior automatically.
From the author of

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

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.

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
  • + Share This
  • 🔖 Save To Your Account