How to Set Alarms with IP SLA

In the world of network administration, just about every day comes with a fire to be put out. Network administrators spend much of their days chasing Today's Big Problems. So, any tool that can help a net admin be more proactive with network administration is incredibly valuable. Admins have enough to worry about just keeping networks running:

A great tool is one that would take work off your plate and prevent future problems before they even arrive. And that's just what IP SLAs can help you do: understand the good, bad and ugly about your network traffic — seeking out problems before they even come up.

What is an IP SLA?

Quick Definition: IP SLA stands for Internet Protocol (IP) Service level Agreement (SLA). An IP SLA is a feature of Cisco devices and networks that lets administrators collect real-time information about network performance. IP SLAs are versatile and extremely useful: they can collect a wide collection of data from many different links and nodes, continuously or at scheduled times.

An Overview of IP SLA [VIDEO]

In this video, Anthony Sequeira covers IP SLA source and IP SLA responder. This tool has gone through quite the evolution in Cisco operating systems and was previously known as the real-time responder, then the service assurance agent, and finally, the IP service level agreement.

Do IP SLAs Have Different Names?

The IP Service Level Agreement has been called many names by Cisco. In previous iterations of the Cisco OS, it was called the Real-Time Responder, and also the Service Assurance Agent. It has been known as the IP SLA since Cisco IOS Release 12.3, which was released in March 2008.

What Does an IP Service Level Agreement Do on a Network?

The basic functionality of an IP SLA is simple: synthetic traffic flows from a source device to a responder, and the IP SLA "listens" and monitors the vital signs of that traffic.

A proactive network manager chooses which nodes and network segments to monitor, then sets up synthetic traffic to be generated from the IP SLA Source device. That gets sent to an IP SLA Responder. The IP SLA Responder can respond back — literally backing out the processing time for the IP SLA Process itself. And when you capture that data and process it, you can get amazing statistics about your network.

If you're a network administrator and you're concerned about the bandwidth on a key link, or concerned about Voice over IP (VoIP) traffic on a particular link, an IP SLA can help you diagnose traffic. For example, one of the most common problems in network traffic is due to variations in delay called "jitter". A Jitter Test lets you proactively sniff out problems on that link, rather than wait for users to call up and complain.

Setting Up a Jitter Test With an IP SLA

A Jitter Test can check just how much variation in delay a network link is experiencing. And once you know the load a particular link is experiencing, a network administrator can reconfigure problem areas.

What we'll do next is go step-by-step through the commands that will help a network administrator set up a Jitter Test on Cisco OS. Hopefully, you have a simulated (or real) network you can practice on, because these are the actual commands you should type into your configuration console for routers on an actual network.

We'll start with the second of our two routers. This is the one we'll be setting up as an IP SLA responder. In console, type:

conf t

Now you're in config mode and you can type the IP SLA responder command:

ip sla responder

Believe it or not, that's all it takes. But you'll want to leave config with:

end

We should verify that we've set up the IP SLA responder. So, from the default console, type:

ip sla responder

As long as you're not in config mode, you should now see a verification that the IP SLA responder is enabled.

It should be noted that you don't have to have an IP SLA Responder device, you could just use any old IP device. But if you do have a Cisco router acting as a responder, you'll end up getting much more robust testing capabilities and useful data.

Now that we've got our responder ready to respond, we head to the console on R1. Our first step is to set up IP SLA testing. We want to get into config mode, so type:

conf t

Now that we're in config, type:

ip sla 1

This creates the particular test we're going to run.

Our next step is to run "udp-jitter", but there's a lot of information that can get added on to that command. When you run this on your own, remember that you can use context-sensitive help to fill everything out. To start, we want to establish our destination for the test. In our case, our R2 is at 10.10.10.2. Therefore, we type:

udp-jitter 10.10.10.2

Next, we establish which port the traffic is headed to. In our case, that's port #49152:

udp-jitter 10.10.10.2 49152

We can instruct the IP SLA what codec we'll want to simulate with this traffic. In our case, we're going to use G.711 A-law:

udp-jitter 10.10.10.2 49152 codec g711alaw

We're only doing a simple demonstration here, but you could make a more sophisticated test by adding more parameters to your test traffic. For instance, it's possible to set the type of service marking for the traffic. For our purposes, we're going to leave this test where it is.

The next step is deciding how often this test is going to run. Be aware that there are minimums. The Cisco OS won't let you over-do it. It'd be pretty ironic if you over-stressed your network with tests to check where the over-stressing was happening on your network.

We set a frequency for the generation of this synthetic traffic by typing (while still in "R1(config-ip-sla-jitter)":

frequency 75

Note: the default value is usually 60.

In this configuration mode, there are additional parameters we can add. For instance, by defining who the owner of this particular test is, we can deliver its results more efficiently. Additionally, if we know that we want the test results to be pulled easily into Simple Network Management Protocol, we can give this test a tag value with:

tag TEST

One of the many other parameters it's possible to define is the type of service for these synthetic packets. If, for example, we wanted to simulate expedited forwarding traffic, we could set the TOS to the differentiated services value (in decimal):

tos 184

Keep in mind that the above three parameters are entered in "R1(config-ip-sla-jitter)" mode. Because now what we do is:

exit

Our test is set up with the parameters that we were interested in. So now what we do is set up a schedule. As above, we'll walk through the full command one keyword at a time. Remember that Cisco's contextual help is useful for remembering commands. We start with the "schedule" keyword:

IP SLA schedule

We specify our particular IP SLA number that we set up previously – 1:

IP SLA schedule 1

We have to answer the device's question of "When should we start it?" How about right now:

IP SLA schedule 1 start-time now

It will also want to know what the life of this particular test should be. We'll say it should run continuously:

IP SLA schedule 1 start-time now life forever

And so we've scheduled our IP SLA test.

How to Verify the Results of an IP SLA Test

After setting up an IP SLA test, you'll want to let it run for a few minutes before running the results. More data is always more useful, but also you may not see any data if you check too soon. After a few minutes, you can type:

show ip sla statistics 1

This should output a table of useful information for you to peruse. The latest operation start time is listed. If everything's gone well, you should see returned codes of "OK". Keep in mind that this was a Jitter Test, you should also have a number of Jitter samples to analyze.

The Jitter samples should show you the average source-to-destination Jitter value. That, combined with the average destination-to-source Jitter is incredibly valuable information that can help re-configure devices or plan upgrades.

Something to keep in mind is that this test can be run periodically, and then the results can be harvested from the machine doing the test. And it doesn't have to be by hand. The data can be harvested by simple network management protocol tools. Those tools getting you this data frees you up to be very proactive about, for instance, the quality of voice over IP phone calls on this particular circuit.

Wrapping Up

This is a tiny fraction of everything you could learn about IP Service Level Agreements, configuring them, scheduling them, and analyzing their results. If you want to dive into the deep end with IP SLAs, you might consider the CCNP Enterprise training at CBT Nuggets.