CCNP SWITCH 642-813 Guide: Configuring IP SLA

Unlock Best Pricing with In-stock, Ready-to-Ship Products

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.

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.

More Attention

To set up an IP SLA operation, the Cisco IP SLA source device begins by opening a control connection to the IP SLA responder over UDP port 1967. The source uses the control connection to inform the responder to begin listening on an additional port where the actual IP SLA test operation will take place.

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

—Reference from pearsonitcertification.com

Cisco Press:

CCNP SWITCH 642-813 Official Certification Guide is a best-of-breed Cisco exam study guide that focuses specifically on the objectives for the CCNP SWITCH exam. Network architect and best-selling author Dave Hucaby shares preparation hints and test-taking tips, helping you identify areas of weakness and improve both your conceptual knowledge and hands-on skills. Material is presented in a concise manner, focusing on increasing your understanding and retention of exam topics. …More you can see here: https://www.ciscopress.com/store/ccnp-switch-642-813-official-certification-guide-9781587202438