IP SLA (Service-Level Agreement) on Cisco IOS

This topic is to discuss the following lesson:

Hi Rene,

How would you go about redirecting traffic if a MOS falls below a certain score?
Thanks
Rob

Hi Rob,

I’m not sure if MOS can be used directly as a operation “failure” for IP SLA, that’s something I’d have to check.

One method that works for sure is to use an IP SLA reaction. You can configure it to produce a syslog message when the MOS score gets below a certain value.

You can then use EEM to act upon this syslog message:

https://networklessons.com/network-management/cisco-ios-embedded-event-manager/

Rene

Hi Rene,

Would you please let me know why this post is not shown in your official book HOW TO MASTER CCNP .

This is not the only article which is not shown in the book ? why the book is not updated in the same manner of the website ?

I evaluated the website 100% , but the book has some missing information if we compared to the website.

Can you please let me know . The version of the book has been buy from amazon.com and it is printed on 2015 .

Hi Sinan,

The books are updated a few times per year, it’s possible that there is newer material here (one of the advantages of online publishing). The next time I do an update on the books, I might add some of the articles here in it.

Rene

For whomever do not know what MOS means, I just wanted to share some basic info:

Mean opinion score (MOS)

VoIP measurements are collected for after testing the one-way delay or the latency of the connection, packet loss with a metric to include the number of consecutive packets lost, and the amount jitter (difference in time it takes packets to arrive). Calculations then factor an R Factor that can be used to estimate a MOS score.

MOS has a subjective measurement where listeners would sit in a “quiet room” and score call quality as they perceived it

Mean opinion score (MOS)
MOS Quality Impairment
5 Excellent Imperceptible
4 Good Perceptible but not annoying
3 Fair Slightly annoying
2 Poor Annoying
1 Bad Very annoying

4 Likes

superb lesson but does it related to ccnp switching…i’m confused?

Hi Hakam,

IP SLA is on CCNP switch and route so it’s best to get familiar with it :slight_smile:

Rene

Hi Rene,

May i know why you haven’t added IP SLA RESPONDER command in icmp echo operation ? Is it only required when the UDP in action?

I have an ASR 9000 which is having slightly different commands & couldn’t find the MOS score in it , Any idea?

Hi Ajay,

For ICMP traffic it is not needed, the remote router will respond anyway. For UDP, you’ll need the responder yes.

I’d have to check an ASR 9000 to see if they show the MOS score somewhere…

Rene

Hi Rene

in the UDP example, I don’t see configuration sal responder in R2 ( R2(config)#ip sla responder )
am I missing something?

Thank you

Hello Hoan

If you look closely, the ip sla responder command is included in the UDP example:

This finishes our configuration on R1 but we still have something to do on R2:

R2(config)#ip sla responder

The ip sla responder command is required on R2 otherwise it will drop our UDP packets. Let’s verify our work:

I hope this has been helpful!

Laz

Hi Lazaros

I understood all of that, but
I think you misunderstood me. if you look at the configuration example of R1 and R2 (right above Conclusion.
the instruction is clear, but the config file of R2 is missing ip sla responder.

Thank you

Hi Rene,

I have a solid understanding on how IP SLA works would you be able to break down threshold a little more for me. In a lot of configurations I see it configured to the same parameter as the timeout command. Would you also be able to provide an example using threshold

thanks in advance.

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!

Laz

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!

Laz

1 Like