Monitoring Performance with IP SLA - Monitoring Campus Networks - CCNP Routing and Switching SWITCH 300-115 Official Cert Guide (2015)

CCNP Routing and Switching SWITCH 300-115 Official Cert Guide (2015)

Part V. Monitoring Campus Networks

Chapter 15. Monitoring Performance with IP SLA

This chapter covers the following topics that you need to master for the CCNP SWITCH exam:

Image IP SLA Overview: This section provides a brief overview of the IP SLA feature and how you can use it to measure network performance.

Image Configuring IP SLA: This section explains how you can configure several types of IP SLA tests on Cisco Catalyst switches.

Image Using IP SLA: This section discusses ways you can set up IP SLA tests and interpret their results.

Switches routinely transport data throughout a network, based on their configuration and how they are interconnected. A well-designed network might move packets efficiently, but many other factors, such as actual traffic loads and link conditions, can change over time and impact time-critical applications.

Once a network is built, you might have a hard time gauging how well it is performing from an end-user perspective. This chapter explains how you can leverage the switches themselves to actively test end-to-end network performance.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt based on your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 15-1 outlines the major headings in this chapter and the “Do I Know This Already?” quiz questions that go with them. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Image

Table 15-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. Is the following statement true or false? To use the IP SLA feature, a third-party network management platform must be used.

a. True

b. False

2. Which of the following are valid types of IP SLA tests? (Choose all that apply.)

a. ICMP echo

b. ICMP time exceeded

c. UDP jitter

d. UDP connect

e. TCP jitter

f. TCP connect

3. Which one of the following commands will enable a switch to participate in all types of IP SLA tests?

a. ip sla enable

b. ip sla all

c. ip sla reflector

d. ip sla responder

e. ip sla reply all

4. Suppose the following configuration commands have been entered on Switch A, which has IP address 10.1.1.1. Which one of the answers correctly identifies the configuration that is needed on the target switch so it can participate in the UDP jitter tests?

ip sla 40132
udp-jitter 10.9.1.100 17000 source-ip 10.1.1.1 num-packets 100
request-data-size 100
frequency 300
ip sla schedule 40132 life forever start-time now ageout 3600

a. Enter the same set of commands on the target switch.

b. Enter the ip sla responder command on the target switch.

c. Do nothing; the target switch will automatically participate.

d. Do nothing; UDP jitter is not a valid IP SLA test.

5. To verify that an IP SLA test operation 123 has been configured and is scheduled to run, which one of the following commands should you use?

a. show ip sla status 123

b. show ip sla configuration 123

c. show ip sla operation 123

d. show ip sla 123

6. According to the following output, how many IP SLA tests have run and gotten results? (Choose one answer.)

Switch# show ip sla statistics aggregated 123
Round Trip Time (RTT) for Index 123
Start Time Index: 09:53:57.314 EDT Fri Aug 8 2014
Type of operation: jitter
Voice Scores:
MinOfICPIF: 0 MaxOfICPIF: 0 MinOfMOS: 0 MaxOfMOS: 0
RTT Values
Number Of RTT: 1100
RTT Min/Avg/Max: 1/3/6 ms
Latency one-way time milliseconds
Number of Latency one-way Samples: 1046
Source to Destination Latency one way Min/Avg/Max: 0/0/3 ms
Destination to Source Latency one way Min/Avg/Max: 1/2/4 ms
Jitter time milliseconds
Number of SD Jitter Samples: 1089
Number of DS Jitter Samples: 1089
Source to Destination Jitter Min/Avg/Max: 0/1/3 ms
Destination to Source Jitter Min/Avg/Max: 0/1/3 ms
Packet Loss Values
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Number of successes: 238
Number of failures: 7

a. 123

b. 1100

c. 1046

d. 238

e. 7

Foundation Topics

IP SLA Overview

The Cisco IOS IP Service Level Agreement (IP SLA) feature enables you 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.


Tip

As the IP SLA feature has evolved, it has been known by several other names. You might also find references to Cisco Response Time Reporter (RTR) and Service Assurance Agent (SAA).


IP SLA can be configured to perform a variety of tests. The simplest test involves Internet Control Message Protocol (ICMP) echo packets that are sent toward a target address, as shown in Figure 15-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 Example 15-1.

Image

Image

Figure 15-1 IP SLA ICMP Echo Test Operation

Example 15-1 Sample ICMP Echo Test Results


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 Aug 22 2014
RTT Values
Number Of RTT: 24
RTT Min/Avg/Max: 1/1/4 ms
Number of successes: 24
Number of failures: 0


For the ICMP echo test, IP SLA can use any live device at the far end; after all, most networked devices will reply when they are 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 because the far end is simply responding to ordinary request packets.

However, IP SLA is capable of running much more sophisticated tests. Table 15-2 shows some sample test operations that are available with IP SLA.

Image

Image

Table 15-2 IP SLA Test Operations

To leverage its full capabilities, Cisco IOS IP SLA must be available on both the source and the target devices, as shown in Figure 15-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.

Image

Image

Figure 15-2 IP SLA UDP Jitter Test Operation

The responder must also add time stamps 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 incurred while the responder is processing the test packets. For this to work accurately, both the source and responder must synchronize their clocks through NTP.

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.


Tip

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 twofold answer:

Image IP SLA will likely appear on your SWITCH exam.

Image IP SLA is actually a useful tool in a switched campus network.

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—all managed from a central system. With IP SLA, you do not 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:

Image Generate SNMP traps when certain test thresholds are exceeded

Image Schedule further IP SLA tests automatically when test thresholds are crossed

Image Track an IP SLA test to trigger a next-hop gateway redundancy protocol, such as Hot Standby Router Protocol (HSRP)

Image Gather voice quality measurements from all over a network

Configuring IP SLA

To define an IP SLA operation, you must configure both the source switch and identify the target device. Some test types, such as ICMP echo, can use any target device provided it can reply to the simple test requests. In that case, you do not need to configure anything on the target device.

Other test types, such as UDP jitter, require a target that can negotiate an IP SLA test, keep time stamps during the test, and respond to protocols that do not necessarily require a response. In those cases, the target must be an IP SLA-capable Cisco switch or router. You must enable the IP SLA responder on the target switch so that it can communicate with the source. You should make sure that both switches are configured to use Network Time Protocol (NTP) to synchronize their time clocks with a common, accurate source. Configuring IP SLA on the target switch is easy; just enable the IP SLA responder with the following command. By default, the IP SLA responder is disabled.

Switch(config)# ip sla responder


Tip

For the most accurate results, you should configure the IP SLA source and target switches to use a trusted NTP server so that the time stamps will be correct and synchronized. NTP configuration is covered in Chapter 13, “Logging Switch Activity.”


You can secure IP SLA operations with message digest 5 (MD5) authentication so that only known and trusted devices can participate. Using the following commands, you can define a key chain that consists of keys, each containing an authentication key string. Normally, you will need only one key in the key chain. Assign the key chain to IP SLA with the ip sla key-chain command. Be sure to enter the same commands on both the responder and the source switch so that their authentication keys match:

Switch(config)# key chain chain-name
Switch(config-keychain)# key key-number
Switch(config-keychain-key)# key-string string
Switch(config-keychain-key)# exit
Switch(config-keychain)# exit
Switch(config)# ip sla key-chain chain-name

On the source switch, IP SLA configuration is a bit more involved. You can use the following configuration steps to define and run an IP SLA test operation:

Step 1. Define a new IP SLA operation on the source switch.

Switch(config)# ip sla operation-number

The operation-number is an arbitrary index that can range from 1 to a very large number. This number uniquely identifies the test.

Step 2. Select the type of test operation to perform.

Switch(config-ip-sla)# test-type parameters...

Some of the possible test-type values are the following:

dhcp, dns, ethernet, ftp, http, icmp-echo, mpls, path-echo, path-jitter, slm, tcp-connect, udp-echo, or udp-jitter

The list of parameters following the test-type varies according to the test operation. As an example, consider the following icmp-echo operation syntax:

Switch(config-ip-sla)# icmp-echo destination-ip-addr [source-ip-addr]

The parameters are simple: a destination address to ping and an optional source address to use. If a switch has several Layer 3 interfaces, you can specify which one of their IP address to use as the source of the test packets.

As another example, the udp-jitter command is useful for testing time-critical traffic paths through a switched network. The command syntax is a little more complex, as follows:

Switch(config-ip-sla)# udp-jitter destination-ip-addr dest-udp-port [source-ip source-ip-addr] [source-port source-udp-port] [num-packets number-of-packets] [interval packet-interval]

In addition to the source and destination IP addresses, you can define the UDP port numbers that will be used for the packet stream. By default, 10 packets spaced at 20 milliseconds will be sent. You can override that by specifying the num-packets and interval keywords.

As an alternative, you can configure the udp-jitter operation to test Voice over IP (VoIP) call quality. To do this, the udp-jitter command must include the codec keyword and a codec definition. The IP SLA operation will then simulate a real-time stream of voice traffic using a specific codec. In this way, you can tailor the test to fit the type of calls that are actually being used in the network.

You can define the UDP jitter codec operation by using the following command syntax:

Switch(config-ip-sla)# udp-jitter destination-ip-addr dest-udp-port
codec {g711alaw | g711ulaw | g729a}

There are other keywords and parameters you can add to the command, but those are beyond the scope of this book. By default, 1000 packets are sent, 20 milliseconds apart.

Step 3. Set the frequency of the operation.

By default, IP SLA operations are run at regular 60-second intervals for the lifetime of the test. You can configure the frequency with the following command:

Switch(config-ip-sla)# frequency seconds

Step 4. Schedule the test operation.

Switch(config)# ip sla schedule operation-number [life {forever | sec
onds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now
| after hh:mm:ss}] [ageout seconds] [recurring]

In a nutshell, the ip sla schedule command tells the switch when to start the test, how long to let it run, and how long to keep the data that is collected.

Set the lifetime with the life keyword: forever means the operation will keep running forever, until you manually remove it. Otherwise, specify how many seconds it will run. By default, an IP SLA scheduled operation will run for 3600 seconds (1 hour).

Set the start time with the start-time keyword. You can define the start time as a specific time or date, after a delay with the after keyword, or right now with the now keyword.

By default, the test statistics are collected and held in memory indefinitely. You can use the ageout keyword to specify how many seconds elapse before the data is aged out.

The recurring keyword can be used to schedule the test operation to run at the same time each day, as long as you have defined the starting time with hh:mm:ss, too.


Tip

Be aware that the IP SLA operation command syntax has changed along the way. In Cisco IOS Releases 12.2(33) and later, the syntax is as shown in Steps 2 through 4. Before 12.2(33), the commands in Steps 2 through 4 included additional keywords, as follows:

Step 2. ip sla monitor operation-number

Step 3. type test-type

Step 4. ip sla monitor schedule operation-number


Using IP SLA

After you have configured an IP SLA operation, you can verify the configuration with the show ip sla configuration [operation-number] command. As an example, the following configuration commands are used to define IP SLA operation 100—an ICMP echo test that pings target 172.25.226.1 every 5 seconds:

Switch(config)# ip sla 100
Switch(config-ip-sla)# icmp-echo 172.25.226.1
Switch(config-ip-sla)# frequency 5
Switch(config-ip-sla)# exit
Switch(config)# ip sla schedule 100 life forever start-time now

Example 15-2 shows the output of the show ip sla configuration command.

Example 15-2 Displaying the Current IP SLA Configuration


Switch# show ip sla configuration
IP SLAs, Infrastructure Engine-II
Entry number: 100
Owner:
Tag:
Type of operation to perform: echo
Target address: 172.25.226.1
Source address: 0.0.0.0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0x0
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 5
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Enhanced History:


You can use the show ip sla statistics [aggregated] [operation-number] command to display the IP SLA test analysis. By default, the most recent test results are shown. You can add the aggregated keyword to show a summary of the data gathered over the life of the operation. Example 15-3shows the statistics gathered for ICMP echo operation 100.

Example 15-3 Displaying IP SLA Statistics


Switch# show ip sla statistics 100
Round Trip Time (RTT) for Index 100
Latest RTT: 1 ms
Latest operation start time: 15:52:00.834 EDT Fri Aug 29 2014
Latest operation return code: OK
Number of successes: 117
Number of failures: 0
Operation time to live: Forever

Switch# show ip sla statistics aggregated 100
Round Trip Time (RTT) for Index 100
Type of operation: icmp-echo
Start Time Index: 15:43:55.842 EDT Fri Aug 29 2014
RTT Values
Number Of RTT: 121
RTT Min/Avg/Max: 1/1/4 ms
Number of successes: 121
Number of failures: 0


It is not too difficult to configure an IP SLA operation manually and check the results every now and then. But does IP SLA have any greater use? Yes, you can also use an IP SLA operation to make some other switch features change behavior automatically, without any other intervention.

For example, HSRP can track the status of an IP SLA operation to automatically decrement the priority value when the target device stops answering ICMP echo packets. To do this, begin by using the track command to define a unique track object-number index that will be bound to the IP SLA operation number.

Switch(config)# track object-number ip sla operation-number {state | reachability}

You can use the state keyword to track the return code or state of the IP SLA operation; the state is up if the IP SLA test was successful or down if it was not. The reachability keyword differs slightly: The result is up if the IP SLA operation is successful or has risen above a threshold; otherwise, the reachability is down.

Next, configure the HSRP standby group to use the tracked object to control the priority decrement value. As long as the tracked object (the IP SLA operation) is up or successful, the HSRP priority stays unchanged. If the tracked object is down, the HSRP priority is decremented bydecrement-value (default 10):

Switch(config-if)# standby group track object-number decrement decrement-value


Tip

HSRP configuration is covered in greater detail in Chapter 18, “Layer 3 High Availability.”


In Example 15-4, Switches A and B are configured as an HSRP pair, sharing gateway address 192.168.1.1. Switch A has a higher priority (120) than Switch B (the default 100), so it is normally the active gateway. However, it is configured to ping an upstream router at 192.168.70.1 every 5 seconds; if that router does not respond, Switch A will decrement its HSRP priority by 30, permitting Switch B to take over.

Example 15-4 Tracking an IP SLA Operation in an HSRP Group


Switch-A(config)# ip sla 10
Switch-A(config-ip-sla)# icmp-echo 192.168.70.1
Switch-A(config-ip-sla)# frequency 5
Switch-A(config-ip-sla)# exit
Switch-A(config)# ip sla schedule 10 life forever start-time now

Switch-A(config)# track 1 ip sla 10 reachability

Switch-A(config)# interface vlan10
Switch-A(config-if)# ip address 192.168.1.3 255.255.255.0
Switch-A(config-if)# standby 1 priority 120
Switch-A(config-if)# standby 1 track 1 decrement 30
Switch-A(config-if)# standby 1 preempt
Switch-A(config-if)# no shutdown


In some cases, you might need many IP SLA operations to take many measurements in a network. For example, you could use UDP jitter operations to measure voice call quality across many different parts of the network. Manually configuring and monitoring more than a few IP SLA operations can become overwhelming and impractical. Instead, you can leverage a network management application that can set up and monitor IP SLA tests automatically. To do this, the network management system needs SNMP read and write access to each switch that will use IP SLA. Tests are configured by writing to the IP SLA MIB, and results are gathered by reading the MIB.

Exam Preparation Tasks

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 15-3 lists a reference of these key topics and the page numbers on which each is found.

Image

Image

Table 15-3 Key Topics for Chapter 15

Complete Tables and Lists from Memory

There are no memory tables in this chapter.

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

IP SLA

IP SLA responder

Use Command Reference to Check Your Memory

This section includes the most important configuration and EXEC commands covered in this chapter. It might not be necessary to memorize the complete syntax of every command, but you should remember the basic keywords that are needed.

To test your memory of the VLAN and trunk-related commands, cover the right side of Table 15-4 with a piece of paper, read the description on the left side, and then see how much of the command you can remember.

Image

Table 15-4 IP SLA Configuration and Monitoring Commands

Remember that the CCNP exam focuses on practical or hands-on skills that are used by a networking professional.