What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

PRTG does not work with path-jitter

Votes:

0

We are faced with the fact that our PRTG(14.3.11.2750) does not work with cisco ip sla path-jitter. Ip sla was configured as follows: ip sla 1 path-jitter x.x.x.x targetOnly vrf xxxx ip sla schedule 1 life forever start-time now This message appears when the survey sensor: Wrong Type, expected "(Type not defined: 29 )", got " And we have configured different hardware sensor as follows: ip sla 2 path-jitter y.y.y.y num-packets 100 interval 1000 targetOnly vrf yyy frequency 180 ip sla schedule 2 life forever start-time now This message appears when the survey sensor: Wrong Type, expected "(Type not defined: 0 )", got " Can you help fix it? Thanks!

cisco ip-sla path-jitter

Created on Sep 5, 2014 4:50:53 AM



12 Replies

Votes:

0

Could you please run a walk on the OID 1.3.6.1.4.1.9.9.42.1.2.1.1 and post the results?

Created on Sep 5, 2014 8:38:03 AM by Greg Campion [Paessler Support]



Votes:

0

Well, here's the result

Paessler SNMP Tester 5.1.2
05.09.2014 15:45:42 (2 ms) : Device: 10.250.127.34
05.09.2014 15:45:42 (4 ms) : SNMP V2c
05.09.2014 15:45:42 (6 ms) : Walk 1.3.6.1.4.1.9.9.42.1.2.1.1
05.09.2014 15:45:42 (22 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.2.1 = ""
05.09.2014 15:45:42 (31 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.3.1 = ""
05.09.2014 15:45:42 (41 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.4.1 = "29"
05.09.2014 15:45:42 (50 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.5.1 = "5000"
05.09.2014 15:45:42 (60 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.6.1 = "60"
05.09.2014 15:45:42 (71 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.7.1 = "5000"
05.09.2014 15:45:42 (81 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.8.1 = "2"
05.09.2014 15:45:42 (91 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.9.1 = "1"
05.09.2014 15:45:42 (104 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.1 = "1"
05.09.2014 15:45:42 (115 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.11.1 = ""

Created on Sep 5, 2014 8:48:15 AM

Last change on Sep 5, 2014 1:03:59 PM by Greg Campion [Paessler Support]



Votes:

0

The problem here is that the SNMP tree that is supposed to be filled out for the IP SLA is not complete and cannot be read by PRTG. This is something that you will need to take up with Cisco to find out why SNMP isn't working properly. Sometimes a reboot may help or altering the configuration.

Created on Sep 5, 2014 1:19:25 PM by Greg Campion [Paessler Support]



Votes:

0

But the tree is completely filled. I tested this OID with a known working type SLA: icmp-echo. The results of walks are the same. Significantly different only 1.3.6.1.4.1.9.9.42.1.2.1.1.4 indicate the type of SLA (1 rather than 29 as in path-jitter) which PRTG complains!

Created on Sep 8, 2014 12:40:42 AM



Votes:

0

A jitter sensor that we have here and is working has many more OID's than the ones from the walk that you sent us.

9/8/2014 9:55:52 AM (2 ms) : Walk 1.3.6.1.4.1.9.9.42.1.2.1.1.10
9/8/2014 9:55:52 AM (6 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.1 = "1"
9/8/2014 9:55:52 AM (9 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.10 = "1"
9/8/2014 9:55:52 AM (12 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.11 = "1"
9/8/2014 9:55:52 AM (16 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.12 = "1"
9/8/2014 9:55:52 AM (19 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.13 = "1"
9/8/2014 9:55:52 AM (22 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.14 = "1"
9/8/2014 9:55:52 AM (26 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.15 = "1"
9/8/2014 9:55:52 AM (30 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.16 = "1"
9/8/2014 9:55:52 AM (34 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.17 = "1"
9/8/2014 9:55:52 AM (37 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.18 = "1"
9/8/2014 9:55:52 AM (42 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.19 = "1"
9/8/2014 9:55:52 AM (46 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.20 = "1"
9/8/2014 9:55:52 AM (50 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.21 = "1"
9/8/2014 9:55:52 AM (54 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.22 = "1"
9/8/2014 9:55:52 AM (58 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.23 = "1"
9/8/2014 9:55:52 AM (63 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.24 = "1"
9/8/2014 9:55:52 AM (67 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.25 = "1"
9/8/2014 9:55:52 AM (72 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.26 = "1"
9/8/2014 9:55:52 AM (77 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.27 = "1"
9/8/2014 9:55:52 AM (81 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.28 = "1"
9/8/2014 9:55:52 AM (87 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.29 = "1"
9/8/2014 9:55:52 AM (93 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.30 = "1"
9/8/2014 9:55:52 AM (100 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.31 = "1"
9/8/2014 9:55:52 AM (105 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.32 = "1"
9/8/2014 9:55:52 AM (110 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.33 = "1"
9/8/2014 9:55:52 AM (115 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.34 = "1"
9/8/2014 9:55:52 AM (121 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.35 = "1"
9/8/2014 9:55:52 AM (128 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.36 = "1"
9/8/2014 9:55:52 AM (134 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.37 = "1"
9/8/2014 9:55:52 AM (140 ms) : 1.3.6.1.4.1.9.9.42.1.2.1.1.10.38 = "1"

PRTG is showing that error because other data from the OIDs that should be there is not.

Created on Sep 8, 2014 8:17:56 AM by Greg Campion [Paessler Support]



Votes:

0

I have the same problem and I receive many OID's similar to your walk result but still the IP SLA type is not recognized, do you have further news about this issue ?

thanks a lot ddrago1

Created on Mar 30, 2016 4:44:50 PM



Votes:

0

Hello ddrago1, thank you for your post.

Please feel free to contact us via a support ticket as we may be able to send you a walk script to be used with our SNMP Tester for debugging purposes, it will allow us to confirm which information is and isn't reported by your device via SNMP.

Best Regards,

Created on Mar 31, 2016 5:23:07 PM by Luciano Lingnau [Paessler]



Votes:

0

We are noticing the same kind of issue with two different Cisco IOS versions, namely:

  • Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(58)SE2, RELEASE SOFTWARE (fc1)
  • Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.2(1)E1, RELEASE SOFTWARE (fc2)

It seems that Paessler expects the value "23" for "rttMonCtrlAdminRttType" (1.3.6.1.4.1.9.9.42.1.2.1.1.4.<Check ID>), where as both of our devices report the value "29" for a path-jitter test. The following output is taken from a device with 5 different IP SLA tests configured:

SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.2.1 = "" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.2.2 = "" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.2.3 = "" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.2.4 = "" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.2.5 = "" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.3.1 = STRING: "ICMP Echo @ 1.2.3.4" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.3.2 = STRING: "Path Jitter @ 1.2.3.4" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.3.3 = STRING: "DNS @ 1.2.3.4" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.3.4 = STRING: "TCP Connect @ 1.2.3.4" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.3.5 = STRING: "UDP Jitter @ 1.2.3.4" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.4.1 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.4.2 = INTEGER: 29 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.4.3 = INTEGER: 8 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.4.4 = INTEGER: 6 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.4.5 = INTEGER: 9 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.5.1 = INTEGER: 3000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.5.2 = INTEGER: 3000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.5.3 = INTEGER: 3000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.5.4 = INTEGER: 3000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.5.5 = INTEGER: 3000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.6.1 = INTEGER: 60 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.6.2 = INTEGER: 60 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.6.3 = INTEGER: 60 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.6.4 = INTEGER: 60 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.6.5 = INTEGER: 60 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.7.1 = INTEGER: 5000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.7.2 = INTEGER: 5000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.7.3 = INTEGER: 5000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.7.4 = INTEGER: 5000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.7.5 = INTEGER: 5000 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.8.1 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.8.2 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.8.3 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.8.4 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.8.5 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.9.1 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.9.2 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.9.3 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.9.4 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.9.5 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.10.1 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.10.2 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.10.3 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.10.4 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.10.5 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.11.1 = "" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.11.2 = "" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.11.3 = "" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.11.4 = "" SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.11.5 = ""

As it can be seen above, the first check is ICMP echo (type 1 -> OK), the second one path jitter (type 29 -> not ok, paessler expects type 23), the third one DNS (type 8 -> OK), the fourth one TCP connect (type 6 -> OK) and the last one UDP jitter (type 9 -> OK). I have taken the values which Paessler expects from their manual, which can be found here: https://www.paessler.com/manuals/prtg/cisco_ip_sla_sensor

It seems like Paessler should map "29" to path-jitter as well, as this could/should fix the issue. The response of Greg Campion back in 2014 was not valid - all OIDs are reported, Greg has only seen more OIDs because he had more checks (namely 38) configured compared to Vladislav, who only had a single IP SLA monitor configured.

Created on Aug 29, 2016 1:47:19 PM

Last change on Aug 30, 2016 10:26:33 AM by Torsten Lindner [Paessler Support]



Votes:

0

Pascal, I'm sorry, support for further SLA-Types is currently not planned. We'll put it one the wish list.

Created on Aug 30, 2016 11:29:42 AM by Torsten Lindner [Paessler Support]



Votes:

0

It's not a new SLA type, it's just a different type ID for an existing type. Updating/patching PRTG wouldn't help though - I've written an SNMP proxy in Python which changed the ID from 29/34 to 23 (path-jitter) and the sensor had no longer shown an error, all reported values were zero though.

After contacting Cisco it turned out while some of these devices do support path jitter measurements, they do not offer the required SNMP table for polling the measurement data, which is: rttMonJitterStatsTable (1.3.6.1.4.1.9.9.42.1.3.5) For all others with a similar problem, trying to run snmpwalk on "1.3.6.1.4.1.9.9.42.1.3.5" should be sufficient - if it returns no instance found, you're out of luck with path jitter measurements.

We've now switched over to UDP jitter measurements and they work like a charm.

Created on Sep 2, 2016 1:14:50 PM



Votes:

0

Hi there,

Having the same issues trying to get path-jitter for ip SLA going. Anyone get this to work properly (or at all)?

thanks, Jay

Created on Sep 22, 2016 9:34:12 PM



Votes:

0

smeego78, which exact error do you get? Can you send a screenshot showing the full error message?

Created on Sep 26, 2016 7:48:58 AM by Torsten Lindner [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.