[XML] Cisco IP SLA templates (AKA RTR & SAA)

[vikingmaster]

thanks for you information

[Fred]

(asking a question about a post that's 2 years old, I know; original post is on page 1)

First, thanks for the template. Finally had a need to further analyze/troubleshoot/prove my network, and this is coming in handy. They went in just fine for me.

I have a question about the Jitter/Error Statistics Graph:

Sample Jitter & Jitter/Error statistics

Best probe to measure overall network health and especially useful if you want to measure the network health for multimedia application, VoIP, and Video. Also, If you run this probe on WAN edge routers, you can compare SLA you get from the Cacti to the ones service provider presents.

The graph contains measurements of Loss (S->D and D->S), as well as packets Late, Missing, and OOS.

It looks to me like these are measuring absolute packets lost. So if I see a value of '1' in the "Loss S->D" graph, that means that 1 of the probes was lost on its way from Source to Destination. I believe this is actually sending 1000 probes, so that measurement is actually 1/1000 (0.01%) packet loss. Am I reading that correctly? I'm experiencing some loss, but according to my references, <1% packet loss should still result in excellent voice quality.

My statistics from 'show interface' show that the network is at about 0.01% loss (due to a tiny amount of errors on a T1). This graph, however, is showing '1'... I think these numbers correlate, but I want to make sure that I'm reading it right. Is "loss" being measured in number of packets, and not in the usual 'percentage of packets' measurement?

[grifter0x]

Can someone please provide some assistance, I can't seem to get the VoIP Score working. Do I have to adjust the OID in the XML file because when I did a walk on my router it needed a .3 on the end for both the MOS and ICPIF.

Thanks.

[jay]

Hi Grifter

the .3 will be the index you specify for the IP SLA monitor. E.G
ip sla monitor 600

If you look at your device you should see the voip score as a graph template and the ip sla stats as a data query. When you go to create graph template you should see a list of index along with the tag and other info. You should then be able to tick one of these and select the voip score from the drop down menu at the bottom right of the page. Are you seeing all this?

You also need to be using the codec feature in order for the voip score to work..I think! I do know its only supported in newer releases of IOS.See below for example.

ip sla monitor 600
type jitter dest-ipaddr <ip address> dest-port 16392 source-ipaddr <ip address> codec g711alaw
tag BLAH_BLAH1_VOIP
ip sla monitor schedule 600 life forever start-time now

Hope this helps?

Regards

Jay

[hwon]

It looks to me like these are measuring absolute packets lost. So if I see a value of '1' in the "Loss S->D" graph, that means that 1 of the probes was lost on its way from Source to Destination. I believe this is actually sending 1000 probes, so that measurement is actually 1/1000 (0.01%) packet loss. Am I reading that correctly? I'm experiencing some loss, but according to my references, <1% packet loss should still result in excellent voice quality.

Fred, you are correct. But. the number of probes per operation is configurable parameter. So it could be 1/1000 or 1/300 depending on your sla configuration. If you want that value to be relative and assuming you always use 1000 probes, you could use CDEF to devide the value by 1000.

[grifter0x]

Jay,

Thanks for the clarification, got it up and running.


Hwon,

Thanks for your templates.

[bjorn2]

I have imported the script successfully but receive the following error when i try to create a new graph.

Undefined variable: column_counter in /usr/share/cacti/site/graphs_new.php on line 876

Im running version 0.8.7b. This is the output from line 876

<select name='sgg_" . $snmp_query["id"] . "' id='sgg_" .

[spfister]

I've just gotten Cacti installed and these IP SLA templates working (for the most part)... I'm looking at the jitter graphs and I'm trying to figure out exactly what they're telling me and how they can be used in troubleshooting. Can someone point me to some documentation?

Thanks!

[zivley]

I have imported the script successfully but receive the following error when i try to create a new graph.

Undefined variable: column_counter in /usr/share/cacti/site/graphs_new.php on line 876

Im running version 0.8.7b. This is the output from line 876

<select name='sgg_" . $snmp_query["id"] . "' id='sgg_" .

Perhaps you've forgotten to copy the cisco_saa.xml file into your <path_cacti>/resource/snmp_queries/ ?

[jay]

Hi

I have a question regarding the TOS field.

If you are using the codec type do you need to add a TOS type as well? I want to make sure the packets are sent into our COS1 queue. If I set a TOS value of 184 this will mark the traffic as DSCP 46 EF and will get put in our COS1 queue. Is this correct?

ip sla monitor 603
type jitter dest-ipaddr x.x.x.x dest-port 16392 source-ipaddr x.x.x.x codec g729a
tos 184
tag BLAH_VOIP
ip sla monitor schedule 603 life forever start-time now

Cheers Jay

[zivley]

I think this may help
http://www.ciscoblog.com/archives/2009/ ... ple_c.html
And also pay attention to Grubs explanation and correction later on about Cos/Tos and DSCP:
http://forums.whirlpool.net.au/forum-re ... m?t=524152

[jay]

Hi

I saw the Cisco blog post. I wanted to find out how to work out the TOS value and I noticed that it was wrong as well. The value should have been 184.

The reason I asked the question was that there has been no reference to using a TOS value in this post. I wasn't sure if that meant it wasn't required. Maybe I'll set up 2 monitors, 1 with and 1 without, and see the difference in response.

Cheers

Jay

[zivley]

From what I've read using the codec should be enough but as you said, it may be a good idea to set two different monitors with and without and see if there is a difference, I'd like to know if you find something interesting about this

[jay]

Hi Zivley

Sorry for the delay the Cacti site was down yesterday.

I have got 2 ip sla monitors going to the same router across our WAN. One us using TOS and Codec and one is using just codec.

My monitors are as follows:-

ip sla monitor 603
type jitter dest-ipaddr <ip add remote router> dest-port 16392 source-ipaddr <ip add local router> codec g729a
tos 184
tag BRPAV2_ACUMA04_VOIP
ip sla monitor schedule 603 life forever start-time now

ip sla monitor 604
type jitter dest-ipaddr <ip add remote router> dest-port 16392 source-ipaddr <ip add local router> codec g729a
tag BRPAV2_ACUMA04_VOIPTEST
ip sla monitor schedule 604 life forever start-time now



If I look at my Cacti graphs there isn't much in the RTT response times between the 2 monitors. I have also attached screenshot of a normal ICMP echo monitor as a baseline. Its when you look at the jitter that you notice the difference. Without the tos value the jitter is significantly higher. I think that all the codec does is to simulate a call, using the following parameters:-

Default Request Size (Packet Payload) (s)

Default Interval Between Packets (t)

Default Number of Packets (n)

Frequency of Probe Operations (f)

I think by adding the TOS value the packet will then be put into the relevant COS queue.



Here are the router stats for those 2 monitors.

brpav2#show ip sla monitor statistics 603
Round trip time (RTT) Index 603
Latest RTT: 98 ms
Latest operation start time: 16:00:06.538 BST Mon Jul 6 2009
Latest operation return code: OK
RTT Values
Number Of RTT: 1000
RTT Min/Avg/Max: 96/98/106 ms
Latency one-way time milliseconds
Number of one-way Samples: 1000
Source to Destination one way Min/Avg/Max: 53/54/62 ms
Destination to Source one way Min/Avg/Max: 43/44/53 ms
Jitter time milliseconds
Number of SD Jitter Samples: 999
Number of DS Jitter Samples: 999
Source to Destination Jitter Min/Avg/Max: 0/2/9 ms
Destination to Source Jitter Min/Avg/Max: 0/1/10 ms
Packet Loss Values
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Voice Score Values
Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 60
Number of failures: 0
Operation time to live: Forever


brpav2#show ip sla monitor statistics 604
Round trip time (RTT) Index 604
Latest RTT: 101 ms
Latest operation start time: 15:59:57.611 BST Mon Jul 6 2009
Latest operation return code: OK
RTT Values
Number Of RTT: 1000
RTT Min/Avg/Max: 96/101/180 ms
Latency one-way time milliseconds
Number of one-way Samples: 1000
Source to Destination one way Min/Avg/Max: 53/55/135 ms
Destination to Source one way Min/Avg/Max: 43/45/95 ms
Jitter time milliseconds
Number of SD Jitter Samples: 999
Number of DS Jitter Samples: 998
Source to Destination Jitter Min/Avg/Max: 0/3/39 ms
Destination to Source Jitter Min/Avg/Max: 0/2/51 ms
Packet Loss Values
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Voice Score Values
Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 31
Number of failures: 0
Operation time to live: Forever


Cheers

Jay

[osiris123d]

I have been using this template for about 2 years now and it works great. The only issue I am starting to run into is running out of space on my Cacti box. I notice in the rra folder under the cacti folder that the biggest files I have are the XXX_rttmax_xxxxx.rrd
Here is an example

-rw-r--r-- 1 root root 394205168 2009-10-19 11:09 aw-2800-cr-1_rttmax_14540.rrd
-rw-r--r-- 1 root root 394205168 2009-10-19 11:09 aw-2800-cr-1_rttmax_14541.rrd
-rw-r--r-- 1 root root 394205168 2009-10-19 11:09 aw-2800-cr-1_rttmax_14542.rrd
-rw-r--r-- 1 root root 394205168 2009-10-19 11:09 aw-2800-cr-1_rttmax_14543.rrd
-rw-r--r-- 1 root root 394205168 2009-10-19 11:09 aw-2800-cr-1_rttmax_14544.rrd
-rw-r--r-- 1 root root 394205168 2009-10-19 11:09 aw-2800-cr-1_rttmax_14545.rrd
-rw-r--r-- 1 root root 394205168 2009-10-19 11:09 aw-2800-cr-1_rttmax_14546.rrd
-rw-r--r-- 1 root root 394205168 2009-10-19 11:09 aw-2800-cr-1_rttmax_14547.rrd

some of these graphs are a year of data. Should these graphs be getting this big?