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 SNMP Table sensor

Votes:

0

Your Vote:

Up

Down

Hi, I have tried to use the SNMP Table sensor on 2 different devices with no luck.

I have checked the devices that i use for the right table OID in the Paessler MIB importer and everything seems to be ok.

i have walked through all the steps here.

I get this error no matter what i do: The OID you entered is not supported by this system or the table is empty. (code: PE249)

The devices i have tried are a Compellent SAN and A Nimble SAN.

Any advice?

mib oid snmp snmp-custom-table

Created on Feb 15, 2017 2:38:18 PM by  Søren Graungaard (0) 1

Last change on Feb 16, 2017 9:28:57 AM by  Luciano Lingnau [Paessler Support]



Best Answer

Accepted Answer

Votes:

0

Your Vote:

Up

Down

It works now because I wanted it to work. :P

Honestly? No idea, the custom sensor's only purpose was to validate the SNMP Communication and credentials. Other than that, the Table sensor on 1.3.6.1.4.1.37447.1.2 should have always worked. Could it be that you were using the preceding . (dot) in the OID? That won't work and will lead to said message:

The OID you entered is not supported by this system or the table is empty. (code: PE249)

You should preferably always work with OID's without the preceding dot in PRTG.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Feb 17, 2017 9:58:09 AM by  Luciano Lingnau [Paessler Support]



8 Replies

Votes:

0

Your Vote:

Up

Down

Hello Søren,
thank you for your KB-Post.

What OID's did you use? Please beware that you won't be able to see the Table's OID in our MIB Importer. For instance, when importing the IF-MIB (the MIB from the example in the tutorial), the OID's visible in the tester will be for instance:

  • 1.3.6.1.2.1.2.2.1.8 Please beware that this isn't the Table's OID. Since the MIB Importer doesn't fully support tables (since oidlib sensors never deploy tables) it is somewhat tricky to find the correct OID. In the case above, the correct OID for the table is 1.3.6.1.2.1.2.2. The actual MIB looks like this:
  • 1.3.6.1.2.1.2.2 (ifTable)
    • 1.3.6.1.2.1.2.2.1 (ifEntry)
      • 1.3.6.1.2.1.2.2.1.1 (ifIndex)
      • 1.3.6.1.2.1.2.2.1.2 (ifDescr)
      • 1.3.6.1.2.1.2.2.1.8 (ifOperStatus)

Most common MIB implementations will follow this pattern. You have to "leave out" everything (inclusive) the latest .1. in the OID to get the OID of the Table. For instance, since you mentioned Compellent SANs:

To monitor the scServerStatus from the scServerTable: The MIB Importer will display the following OID for the scServerStatus: 1.3.6.1.4.1.16139.2.27.1.3 - But this is the OID of the column. To figure the OID of the table, leave out everything after the last .1 (including the .1). Which leaves you with:

  • 1.3.6.1.4.1.16139.2.27 (scServerTable)

Keep in mind that the best way to generate the required lookups is to deploy the library sensor first, it will automatically create the appropriate lookups, which you can use with the Table Sensor later on. Remember to adjust the lookup to actually modify the sensor's status based on the response. More details are available here:

And lastly. If you continue getting errors trying to deploy the Table Sensor, use the OID of the table in our SNMP Tester and confirm whenever you get any reply when you do a walk of the OID.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Feb 16, 2017 12:36:45 PM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Thanks for the answer.

I think i got the OID correct, I tried .1.3.6.1.4.1.37447.1.2 as you can see below.

  • .1.3.6.1.4.1.37447.1.2 - VolTable
    • .1.3.6.1.4.1.37447.1.2.1 - VolEntry
      • .1.3.6.1.4.1.37447.1.2.1.3 - VolName
      • and so on.

When i try to do a walk on the table .1.3.6.1.4.1.37447.1.2 nothin happens it just writes.

Paessler SNMP Tester 5.2.3 Computername: ServerName Interface: (xxx.xxx.xxx.xxx)
16-02-2017 14:42:24 (3 ms) : Device: xxx.xxx.xxx.xxx
16-02-2017 14:42:24 (5 ms) : SNMP V2c
16-02-2017 14:42:24 (6 ms) : Walk .1.3.6.1.4.1.37447.1

Should I get some kind of response in the SNMP Tester when i walk the Table OID?

Created on Feb 16, 2017 2:03:24 PM by  Søren Graungaard (0) 1

Last change on Feb 16, 2017 2:18:16 PM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Yes, the output would look similar to the following:

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 Computername: ServerName Interface: XXX.XXX.XXX.XXX
16/02/2017 15:18:44 (1 ms) : Device: XXX.XXX.XXX.XXX
16/02/2017 15:18:44 (2 ms) : SNMP V2c
16/02/2017 15:18:44 (3 ms) : Walk 1.3.6.1.2.1.25.3.3
16/02/2017 15:18:44 (4 ms) : 1.3.6.1.2.1.25.3.3.1.1.14 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (5 ms) : 1.3.6.1.2.1.25.3.3.1.1.15 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (6 ms) : 1.3.6.1.2.1.25.3.3.1.1.16 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (7 ms) : 1.3.6.1.2.1.25.3.3.1.1.17 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (8 ms) : 1.3.6.1.2.1.25.3.3.1.1.18 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (9 ms) : 1.3.6.1.2.1.25.3.3.1.1.19 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (10 ms) : 1.3.6.1.2.1.25.3.3.1.1.20 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (12 ms) : 1.3.6.1.2.1.25.3.3.1.1.21 = "0.0" [ASN_OBJECT_ID]
16/02/2017 15:18:44 (13 ms) : 1.3.6.1.2.1.25.3.3.1.2.14 = "24" [ASN_INTEGER]
16/02/2017 15:18:44 (15 ms) : 1.3.6.1.2.1.25.3.3.1.2.15 = "7" [ASN_INTEGER]
16/02/2017 15:18:44 (17 ms) : 1.3.6.1.2.1.25.3.3.1.2.16 = "18" [ASN_INTEGER]
16/02/2017 15:18:44 (19 ms) : 1.3.6.1.2.1.25.3.3.1.2.17 = "8" [ASN_INTEGER]
16/02/2017 15:18:44 (21 ms) : 1.3.6.1.2.1.25.3.3.1.2.18 = "10" [ASN_INTEGER]
16/02/2017 15:18:44 (22 ms) : 1.3.6.1.2.1.25.3.3.1.2.19 = "39" [ASN_INTEGER]
16/02/2017 15:18:44 (24 ms) : 1.3.6.1.2.1.25.3.3.1.2.20 = "22" [ASN_INTEGER]
16/02/2017 15:18:44 (25 ms) : 1.3.6.1.2.1.25.3.3.1.2.21 = "18" [ASN_INTEGER]

This is the output of a walk against the hrProcessorTable(1.3.6.1.2.1.25.3.3 ) from the HOST-RESOURCES-MIB. Essentially the result that you've received either means that the device doesn't implement this table or that you have a general SNMP problem. Try walking 1.3.6, do you get a valid reply?

Created on Feb 16, 2017 2:21:05 PM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Ok, when I do a walk of .1.3.6 i can see that .1.3.6.1.4.1.37447.1.2 doesnt show, it jumps directly to the table data.

16-02-2017 15:22:06 (1659 ms) : 1.3.6.1.4.1.2021.13.14.2.1.3.1 = "/nimble/lib/nimble_snmp.so" [ASN_OCTET_STR]
16-02-2017 15:22:06 (1666 ms) : 1.3.6.1.4.1.2021.13.14.2.1.4.1 = "" [ASN_OCTET_STR]
16-02-2017 15:22:06 (1675 ms) : 1.3.6.1.4.1.2021.13.14.2.1.5.1 = "1" [ASN_INTEGER]
16-02-2017 15:22:06 (1683 ms) : 1.3.6.1.4.1.37447.1.2.1.2.0 = "0" [ASN_UNSIGNED]
16-02-2017 15:22:06 (1693 ms) : 1.3.6.1.4.1.37447.1.2.1.2.1 = "1" [ASN_UNSIGNED]
16-02-2017 15:22:06 (1704 ms) : 1.3.6.1.4.1.37447.1.2.1.2.2 = "2" [ASN_UNSIGNED]
16-02-2017 15:22:06 (1712 ms) : 1.3.6.1.4.1.37447.1.2.1.2.3 = "3" [ASN_UNSIGNED]

Is this a problem with the Nimble SNMP implementation or something else?

Created on Feb 16, 2017 2:27:03 PM by  Søren Graungaard (0) 1

Last change on Feb 17, 2017 8:01:17 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Søren,

Well, this is only a partial walk but the following looks like the beginning of the VolTable at 1.3.6.1.4.1.37447.1.2:

  • 16-02-2017 15:22:06 (1683 ms) : 1.3.6.1.4.1.37447.1.2.1.2.0 = "0" [ASN_UNSIGNED]
  • 16-02-2017 15:22:06 (1693 ms) : 1.3.6.1.4.1.37447.1.2.1.2.1 = "1" [ASN_UNSIGNED]
  • 16-02-2017 15:22:06 (1704 ms) : 1.3.6.1.4.1.37447.1.2.1.2.2 = "2" [ASN_UNSIGNED]
  • 16-02-2017 15:22:06 (1712 ms) : 1.3.6.1.4.1.37447.1.2.1.2.3 = "3" [ASN_UNSIGNED]

I've highlighted the Table in the OID in bold and the Index in the OID in italics. It looks like it's all there. Please perform the following:

  1. In PRTG, deploy an SNMP Custom sensor on 1.3.6.1.4.1.37447.1.2.1.2.1 - Do you get a Value of 1?
  2. Troubleshoot the sensor until it comes up (essentially, the SNMP Credentials in PRTG)
  3. Try deploying the Custom Table sensor on 1.3.6.1.4.1.37447.1.2 again.



Best Regards,
Luciano Lingnau [Paessler Support]

Created on Feb 17, 2017 8:10:29 AM by  Luciano Lingnau [Paessler Support]

Last change on Feb 17, 2017 8:12:14 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Now it works :D

Do you know why it is working now, because i have already tried 1.3.6.1.4.1.37447.1.2 alot of times? Is it the custom sensor on 1.3.6.1.4.1.37447.1.2.1.2.1 the cause?

Created on Feb 17, 2017 8:30:50 AM by  Søren Graungaard (0) 1



Accepted Answer

Votes:

0

Your Vote:

Up

Down

It works now because I wanted it to work. :P

Honestly? No idea, the custom sensor's only purpose was to validate the SNMP Communication and credentials. Other than that, the Table sensor on 1.3.6.1.4.1.37447.1.2 should have always worked. Could it be that you were using the preceding . (dot) in the OID? That won't work and will lead to said message:

The OID you entered is not supported by this system or the table is empty. (code: PE249)

You should preferably always work with OID's without the preceding dot in PRTG.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Feb 17, 2017 9:58:09 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Dooh, it was the leading . that was the problem...

Thanks for your help, I have learned alot :)

Created on Feb 17, 2017 10:24:13 AM by  Søren Graungaard (0) 1



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.