IP SLA (Service-Level Agreement) on Cisco IOS

(Hakam A) #7

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

0 Likes

(Rene Molenaar) #8

Hi Hakam,

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

Rene

0 Likes

(Ajay R) #9

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?

0 Likes

(Rene Molenaar) #10

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

0 Likes

(Hoan N) #11

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

0 Likes

(Lazaros Agapides) #12

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

0 Likes

(Hoan N) #13

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

0 Likes

(juan i) #14

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.

0 Likes

(Rene Molenaar) #15

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?

0 Likes

(Wisam A) #16

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.

0 Likes

(Lazaros Agapides) #17

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

0 Likes

(Wisam A) #18

Thank you, I appreciate your quick reply Laz.

1 Like

(Wisam A) #19

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.

0 Likes

(Lazaros Agapides) #20

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

0 Likes

(Chris N) #21

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

0 Likes

(Lazaros Agapides) #22

Hello Chris

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

Laz

0 Likes

(MARKOS A) #23

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

Regards
Markos

0 Likes

(Lazaros Agapides) #24

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!

Laz

0 Likes

(Pinki D) #25

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

0 Likes

(Lazaros Agapides) #26

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!

Laz

0 Likes