IP SLA Fundamentals


Most of us, as network engineers, have been in a situation where users have reported performance issues with the network or that the network is down and we have to investigate to discover the root cause of the problem. When this happens, we usually rely on some sort of network monitoring and reporting application in order to get an idea of what our network is doing at the time.


In this write-up, I will delve a little into the world of systems monitoring utilizing Cisco IOS IP SLA to gather and report on statistics. There are several other monitoring features that can be used in conjunction with IP SLA, including SNMP and NetFlow to assist in determining the cause of a network issue. However, this post will focus on IP SLA. IP SLA can be used to monitor and keep track of a number of statistics and report on them, but this blog post will only focus on a few.


What is IP SLA

IP SLA is an active method of monitoring and reliably reporting on network performance. By "active," I refer to the fact that IP SLA will generate and actively monitor traffic continuously across the network. An IP SLA Router is capable of generating traffic and reporting on it in real time. IP SLA can be configured in such a way that it can report on statistics such as:

  • Jitter

  • Response time

  • Packet loss

  • Voice Quality Scoring (MOS)

  • Connectivity

  • Server or website responses and downtime

  • Delay


Although you do not need a Cisco Router at the other end of what you are monitoring, you are able to obtain a more detailed output if you do. This Cisco router is referred to as an IP SLA Responder.


From the above list, you can see the benefits of utilizing Cisco IP SLA to perform network monitoring and reporting functions. IP SLA provides the ability to monitor a traffic path to a destination while also confirming that a particular web server is accepting connections. While this information is useful and can be seen through show commands on the IP SLA device, to make IP SLA reporting more human-readable, you can use an SNMP agent to poll the IP SLA router. There are a number of SNMP agents available that are capable of retrieving this information, including SolarWinds, Cacti, or PRTG to name a few.


There are also other use cases for IP SLA, such as policy-based routing (PBR); however, the focus of this blog post is on the monitoring of the network.


How IP SLA works

IP SLA can be configured in two parts. There is the IP SLA router, which generates the traffic, and the IP SLA Responder (which can be any device, not just a Cisco router). One point I should mention is that the IP SLA Responder is not required for IP SLA to function, but it does allow for more detailed information gathering and reporting. In order to understand a little how the IP SLA function works, let’s take a look at how IP SLA is configured for UDP jitter to monitor the link between two Cisco routers, with one configured as an IP SLA Responder.


The IP SLA ICMP jitter operation is configured to send an ICMP Timestamp Request (Type 13) to the configured destination host and is expecting an ICMP Timestamp Reply (Type 14) response from the destination. This ICMP packet contains three timestamp fields. One is the Originating timestamp, which is the timestamp from the source IP SLA router of the time that the packet was sent. The next two timestamp fields are the Receive timestamp, and the Transmit timestamp. As the field names suggest, the IP SLA Responder will insert the timestamp of when that packet was received, then also the timestamp of when it is transmitted. This can be seen in the below packet capture of the IP SLA ICMP jitter response showing the ICMP Timestamp Reply message.



Having the Receive and Transmit timestamps allows the IP SLA packet to not only measure the RTT of the packet getting from the source to the destination, but also to record how long the destination device takes to process the packet. If the IP SLA probe response is taking a long time, this could indicate that the receiving end device may be under high load and need to be investigated. There is also a fourth timestamp that is added to the calculated jitter, and this is when the IP SLA probe receives the packet back again. To verify the IP SLA operation statistics use the show command show ip sla statistics <sla number> detail.



Each of the different IP SLA operations will function in a slightly different way, but follows the same principles. For example, the IP SLA Path Echo operation will use ICMP ping packets.


Configuring IP SLA

There are a few components that go together and need to be configured for IP SLA to function. First you need to decide what type of IP SLA operation you want to configure, whether it be ICMP jitter, HTTP GET request, DNS request, VoIP, etc. You then need to configure the IP SLA schedule to tell the IP SLA router when and how often to run the IP SLA operation and also when to stop it. There is also the IP SLA Responder that needs to be configured if you are using an IP SLA Operation that can make use of it.


Due to the large number of configuration options available for IP SLA (showing how to configure all of them would mean writing a book instead of a blog article), I will only show how to configure IP SLA to perform one operation, which for this article will be a check on an FTP server. Note that IP SLA only supports an FTP get request in order to report on the RTT it takes for the IP SLA Operation to communicate and download the file from the FTP server. Also note that this particular IP SLA operation does not require the IP SLA Responder to be configured.


When configuring IP SLA, you first need to specify the IP SLA operation number. The IP SLA operation number can be anywhere from 1 to 2147483647. Once the IP SLA operation number has been configured, you can select which type of IP SLA operation you want.



To configured the FTP operation, you will need to specify the username and password along with the FTP path in this format: ftp://<username>:<password>@<server-ip>/<filename>. If you do not specify a username and password, then the default of anonymous and test are used.



Once the FTP path has been configured, you can now configure any timeout parameters along with any other configuration options you wish to alter. For this example, I will leave everything as default values.


The next step is to schedule the IP SLA operation to start, and tell the router how long to run for. You can configure the IP SLA operation to run for various periods of time. For our FTP operation, we want the IP SLA operation to only run from 8am to 5pm.



This tells the router to start the IP SLA operation 200 after 8am in the morning, continue for 9 hours, and to have this re-occur every day. Without the recurring keyword, the operation would only run once.


To verify that our IP SLA operation has started and that we are getting successful results, we can use the show command show ip sla statistics 200 detail



This information can be polled by your SNMP Agent, which will usually record and graph your IP SLA results, making viewing historical data easier.



This blog has hopefully provided you with a basic understanding of how IP SLA works and how it can be used to monitor your network and services. The configuration examples above show only a very small portion of what IP SLA is capable of performing. There are other features of IP SLA that do not just include the monitoring of a network.


More detailed information regarding the configuration of IP SLA can be found here. http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_sla/configuration/guide/hsla_c.html