IP SLA (Service-Level Agreement) on Cisco IOS

Hi Juan,

Let’s say we have a WAN connection that we use for VoIP traffic and we want to monitor if there’s a maximum one way delay of 150 ms.

With IP SLA, you can set the threshold to 150 ms and the timeout to a larger value…perhaps 1000 ms.

When you exceed the 150 ms threshold, it shows up in IP SLA monitor. It’s probably something that you want to check even though there is no “failure” at the moment. If you don’t get a reply within 1000 ms, we get a timeout which means that something is probably wrong with the WAN link (or the device on the other end).

Does this help?

Hi Rene,

Could you please let me know when we need to add the source IP address in the operation? and why we need it.

Thanks in Advance.

Hello Wisam

You do not necessarily have to indicate the source IP address. However, there are cases where this is desirable. If a router has several active interfaces (and this is almost always the case) and you want to examine its connectivity to a specific destination, then the source IP address should be explicitly defined in the IP SLA operation.

I hope this has been helpful!


Thank you, I appreciate your quick reply Laz.

1 Like

Hi Rene,
sometimes I saw the log output below in my router log, and experience a slowness in the network, could you please explain it to me and what to look for.

Feb  4 08:00:39.636: %TRACK-6-STATE: 11166 ip sla 11166 state Up -> Down
Feb  4 08:00:40.548: %TRACK-6-STATE: 1116 list threshold percentage Up -> Down
Feb  4 08:01:24.636: %TRACK-6-STATE: 11166 ip sla 11166 state Down -> Up
Feb  4 08:01:25.576: %TRACK-6-STATE: 1116 list threshold percentage Down -> Up
Feb  4 08:45:29.659: %TRACK-6-STATE: 11161 ip sla 11161 state Up -> Down
Feb  4 08:45:29.659: %TRACK-6-STATE: 11162 ip sla 11162 state Up -> Down
Feb  4 08:45:30.107: %TRACK-6-STATE: 1116 list threshold percentage Up -> Down
Feb  4 08:45:54.659: %TRACK-6-STATE: 11166 ip sla 11166 state Up -> Down
Feb  4 08:45:54.659: %TRACK-6-STATE: 11164 ip sla 11164 state Up -> Down
Feb  4 08:46:19.659: %TRACK-6-STATE: 11161 ip sla 11161 state Down -> Up
Feb  4 08:46:19.659: %TRACK-6-STATE: 11162 ip sla 11162 state Down -> Up
Feb  4 08:46:24.659: %TRACK-6-STATE: 11166 ip sla 11166 state Down -> Up
Feb  4 08:46:24.659: %TRACK-6-STATE: 11164 ip sla 11164 state Down -> Up
Feb  4 08:46:25.231: %TRACK-6-STATE: 1116 list threshold percentage Down -> Up

Thanks in advance.

Hello Wisam

These log messages indicate that there is an IP SLA configured and it is being triggered. When it is triggered, the state of the SLA is changed from UP to DOWN. This in turn triggers some other action (if it is configured) such as a change in routing for example. The triggering of the SLA is based on the threshold that has been configured. In order to determine what is actually happening to the network when the SLA is being triggered, examine the following:

your tracking configuration
your threshold percentage up/down configuration

The SLA configuration should not be the problem since it is configured in order to react when something changes. You should investigate what the SLA tracks as that has become unstable and has triggered this behaviour in the device. Take a look at this Cisco Documentaiton for more information about IP SLAs…

I hope this has been helpful!


A lesson on multi-operation SLA would be good, too :slight_smile:

Hello Chris

That would be great! Post it in the Member Ideas section of the site!


Hello dear Networklessons Team

How do we check in UDP jitter SLA statistics if the jitter is acceptable? Is there an option to set a jitter threshold? In your example the threshold represents the average roundtrip time. You mention on the lesson that we can check MOS score. How is it created and what would be an acceptable value range from 1-5? Thank you in advance


Hello Markos

IP SLA is a mechanism that checks the condition of a particular entity (jitter, echo request etc) and returns a value of whether or not it is OK. As such, the SLA statistics will focus on whether the SLA has been achieved or if it has failed. IP SLA is not designed to give more information about the state of jitter. Specifically, according to Cisco, the information provided is:

  • Per-direction jitter (source to destination and destination to source)
  • Per-direction packet loss
  • Per-direction delay (one-way delay)
  • Round-trip delay (average round-trip time)

Now if you want to determine more information about jitter on the network, even when its levels are acceptable, you need to use other monitoring tools such as Wireshark or Netflow. If you’re measuring jitter on an IP phone, Cisco phones have the option of viewing Average and Max jitter of an active call on the Call Statistics screen.

There are many additional options that you can configure when you set up an IP SLA for jitter. You can indeed set a threshold as well as many other settings. You can find out more about these at the following link:

MOS or Mean Opinion Score started out as a subjective measure of the quality of the sound of a voice in general and has been applied to telephony as well. People would rate the quality or the MOS of a particular service from 1 to 5 where 5 is face to face communication, or FM radio quality sound. Various characteristics affect the MOS such as the codec being used, as well as jitter of course.

Now because obtaining MOS ratings can be time consuming and can cost a lot since you actually need people to rate the quality of the voice service, an objective and automatic method of MOS measurement has been devised using algorithms which statistically mimic the human MOS ratings. These algorithms are standardized in the ITU-T PESQ P.862 standard. This is what is used in the Cisco device to estimate an MOS rating.

Any rating above 3.8 is considered good although this value may vary depending on who you ask. Anything below that can become noticeably degraded.

The following is a list of codecs and their MOS scores for reference.

I hope this has been helpful!


when do we configure IP SLA Responder on the other router? is it required if we are doing for local hosts?

Hello Pinki

IP SLA will function without an SLA responder for a limited number of SLA types such as ICMP echo requests for example. This is because network devices are generally configured to respond to such messages. For more advanced features such as that described in the lesson with udp-jitter, a responder must be configured so that traffic will be accepted, processed, and any analysis can be shared between the routers and subsequently displayed to administrators.

The SLA responder essentially allows a system to anticipate and respond to specialized IP SLA request packets beyond just the simple pings. A responder will actually take part in providing accurate measurements without the need for the configuration of dedicated probes, such as those configured on the initial IP SLA device. This coordination between the two devices takes place using Cisco IOS IP SLA Control Protocol through which it will be notified on which port it should listen and respond.

Now if your IP SLA is examining only parameters on the localhost, then a responder is not necessary.

I hope this has been helpful!


Suppose if we have full mesh connectivity , usually how we will do .How we will mark all links performance . Do we need a dedicated device to send simulation packet ?
Can we use a responder as a simulator also ?

Hello Sims

It is possible to set up an IP SLA to function in such a way so that each router within the topology can test all of its links to neighbouring routers and adjust routing parameters accordingly. However, this is not very practical. IP SLAs are usually implemented at particular locations where routing may need to be adjusted, such as the customer edge or at remote locations. You wouldn’t apply it to all routers within an enterprise network topology. In such a case, you would rely on the metrics provided by the routing protocol being used.

I hope this has been helpful!


Hello Rene et al.,
I followed this lab word for word and I got a negative MOS score. Is this ok?

Hello Martha

This is a very interesting result indeed. MOS should have a range between 1 and 5, or have a value of 0 if the MOS could not be calculated. However, looking more in detail into how the MOS is calculated sheds some light on this result.

According to this Cisco documentation, the MOS is calculated in relation to an equation of the Impairment/Calculated Planning Impairment Factor (ICPIF). This formula is ICPIF = Itot - A where Itot is the total impairment caused by various factors including non optimal loudness, quantizing distortions, echo, delay and others, and A is an Advantage Factor that can be adjusted by the user.

It seems here that the Itot and A are shown as the result of the MOS score where Itot is -4294962.0 and A is 95. The MOS score is based on the results of this formula.

Because I have only come across such an output once, and since the values were exactly the same, my assumption is that for some reason, the ICPIF score maxed out due to an incorrect computation and expressed the results as seen above. (ICPIF values are typically between 5 and 55). It may be a bug or some computational error performed by the hardware but I have been unable to find any solid evidence for this.

This is only an assumption based on my understanding of how MOS is calculated using IP SLA. My suggestion would be to attempt to perform the same lab with different equipment, or at least a different version of IOS to see if you get similar results.

I hope this has been helpful!


There is a way to have statistics of the IP SLA operation ?. I mean, the command show ip sla statistics just show the result from the last test done (latest RTT). My question is , if there is a command that show all the result done from an IP SLA operation to know how was the behavior during a certain period of time or if theres is a way to store the results for an analysis?

Hello Rodrigo

IP SLA will only provide you with whatever statistics you find using the command you mentioned. If you need more information concerning the behaviour of the network, you will need to use other tools such as syslog and SNMP to capture events taking place.

I hope this has been helpful!



is my scenario
I have DC1 and DC2 both have nexus 7k core, connected to NExus 5k, connected to nexus 2k
I have one device hanging of both 2k with IP of 10.65.x.10 and 10.65.x.ll in VLAN 66. All routing between both devices is good
The question is can I run an IPSLA from the 7k using 10.65.x.10 as source and .11 as a destination?

Hello Michael

IP SLA can only be implemented with a source IP on the local device. It is not possible to create an IP SLA that has a source IP on another device. The best way to examine connectivity between these two devices is to create an IP SLA or a chron (depending on what device it is) or some sort of periodic echo between them and have this be reported using SNMP or something similar.

An alternative could be to have an IP SLA on the 7K ping one device and then the other. I know this doesn’t guarantee that routing is available between the two devices, but it does verify their connectivity to the network.

I hope this has been helpful!