New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


PRTG does not work with path-jitter

Votes:

0

Your Vote:

Up

Down

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 by  Vladislav (0) 1



12 Replies

Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  Vladislav (0) 1

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



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  Vladislav (0) 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  ddrago1 (0)



Votes:

0

Your Vote:

Up

Down

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 Support]



Votes:

0

Your Vote:

Up

Down

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 by  Pascal Mathis (0) 1

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



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  Pascal Mathis (0) 1



Votes:

0

Your Vote:

Up

Down

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 by  smeego78 (0) 1



Votes:

0

Your Vote:

Up

Down

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]



Please log in or register to enter your reply.


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.