Hi,

So i have this SNMP Custom Advanced (Multi OID's) sensor and it is not doing its job.. The sensor reports the following: No response (check: firewalls, routing, snmp settings of device, IPs, SNMP version, community, passwords etc) (SNMP error # -2003)

Now you would say "Ooohhh" I think i spotted the issue.. Well that is where you are wrong.. On the same device i also added a SNMP Custom sensor (Single OID, 1.3.6.1.2.1.2.2.1.8) and that one works just fine. It reports the Port status based on a value lookup.

I did some extra testing on the probe server and performed a walk on the device im trying to monitor, it reports the following:

Paessler SNMP Tester 5.2.3
4-4-2018 14:03:37 (6 ms) : Device: 10.20.146.211
4-4-2018 14:03:37 (9 ms) : SNMP V1
4-4-2018 14:03:37 (12 ms) : Custom OID 1.3.6.1.2.1.2.2.1.8
4-4-2018 14:03:37 (94 ms) : SNMP Datatype: ASN_INTEGER
4-4-2018 14:03:37 (97 ms) : -------
4-4-2018 14:03:37 (100 ms) : Value: 1
4-4-2018 14:03:37 (103 ms) : Done
  • This works for every OID in the range..

So i know for sure that the Probe server has access and is able to read the value just fine.. In the SNMP Custom Advanced im reading the following OID range: 1.3.6.1.2.1.2.2.1.8 - 1.3.6.1.2.1.2.2.8.8.

So i cannot figure out why the SNMP Custom Advanced is failing for no apparent reason while the SNMP Custom sensor works just fine?!...

Article Comments

Hello Randy,

Can you please use the SNMP Tester again and perform a Walk against the OID 1.3.6.1.2.1.2.2.1? Thanks in advance!

Best regards, Felix


Apr, 2018 - Permalink

Hello Felix,

Thanks for the reply. Here is the information you requested:

Paessler SNMP Tester 5.2.3

12-4-2018 09:38:22 (6 ms) : Device: 10.20.146.211
12-4-2018 09:38:22 (9 ms) : SNMP V1
12-4-2018 09:38:22 (12 ms) : Walk 1.3.6.1.2.1.2.2.2
12-4-2018 09:38:22 (191 ms) : 1.3.6.1.2.1.2.2.2.1 = "2" [ASN_INTEGER]
12-4-2018 09:38:23 (375 ms) : 1.3.6.1.2.1.2.2.2.2 = "Up0" [ASN_OCTET_STR]
12-4-2018 09:38:23 (560 ms) : 1.3.6.1.2.1.2.2.2.3 = "76" [ASN_INTEGER]
12-4-2018 09:38:23 (745 ms) : 1.3.6.1.2.1.2.2.2.4 = "1536" [ASN_INTEGER]
12-4-2018 09:38:23 (928 ms) : 1.3.6.1.2.1.2.2.2.5 = "144000" [ASN_UNSIGNED]
12-4-2018 09:38:23 (1110 ms) : 1.3.6.1.2.1.2.2.2.7 = "1" [ASN_INTEGER]
12-4-2018 09:38:23 (1289 ms) : 1.3.6.1.2.1.2.2.2.8 = "1" [ASN_INTEGER]
12-4-2018 09:38:24 (1468 ms) : 1.3.6.1.2.1.2.2.2.9 = "7673643" [ASN_TIMETICKS]
12-4-2018 09:38:24 (1646 ms) : 1.3.6.1.2.1.2.2.2.10 = "577371732" [ASN_COUNTER]
12-4-2018 09:38:24 (1827 ms) : 1.3.6.1.2.1.2.2.2.14 = "10" [ASN_COUNTER]
12-4-2018 09:38:24 (2008 ms) : 1.3.6.1.2.1.2.2.2.16 = "563901887" [ASN_COUNTER]
12-4-2018 09:38:24 (2187 ms) : 1.3.6.1.2.1.2.2.2.20 = "0" [ASN_COUNTER]

Regards, Randy


Apr, 2018 - Permalink

Hello Randy,

Thanks, unfortunately, the SNMP Walk was performed against the OID 1.3.6.1.2.1.2.2.2 and not 1.3.6.1.2.1.2.2.1. Was it a typo in your initial question or in the latest walk results? In your next reply, please do additionally forward a screenshot of the SNMP Custom Advanced Sensor's settings page. This illustrates which OIDs were exactly chosen.

Best regards, Felix


Apr, 2018 - Permalink

Hi Felix,

Yes, i noticed when i pressed the send button. But i couldn't change it anymore because of the wait for moderation. + I was like well.... the data is for the .2 is the same as .1 (Its only Port 2 instead of Port 1 on the switch) But below i have pasted the output for Port 1. (.1)

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3
16-4-2018 10:05:37 (1 ms) : Device: 10.20.146.211
16-4-2018 10:05:37 (1 ms) : SNMP V1
16-4-2018 10:05:37 (2 ms) : Walk 1.3.6.1.2.1.2.2.1
16-4-2018 10:05:38 (181 ms) : 1.3.6.1.2.1.2.2.1.1 = "1" [ASN_INTEGER]
16-4-2018 10:05:38 (359 ms) : 1.3.6.1.2.1.2.2.1.2 = "Lan" [ASN_OCTET_STR]
16-4-2018 10:05:38 (540 ms) : 1.3.6.1.2.1.2.2.1.3 = "6" [ASN_INTEGER]
16-4-2018 10:05:38 (716 ms) : 1.3.6.1.2.1.2.2.1.4 = "1536" [ASN_INTEGER]
16-4-2018 10:05:38 (897 ms) : 1.3.6.1.2.1.2.2.1.5 = "100000000" [ASN_UNSIGNED]
16-4-2018 10:05:38 (1077 ms) : 1.3.6.1.2.1.2.2.1.7 = "1" [ASN_INTEGER]
16-4-2018 10:05:39 (1258 ms) : 1.3.6.1.2.1.2.2.1.8 = "1" [ASN_INTEGER]
16-4-2018 10:05:39 (1437 ms) : 1.3.6.1.2.1.2.2.1.9 = "69145513" [ASN_TIMETICKS]
16-4-2018 10:05:39 (1614 ms) : 1.3.6.1.2.1.2.2.1.10 = "1443603825" [ASN_COUNTER]
16-4-2018 10:05:39 (1792 ms) : 1.3.6.1.2.1.2.2.1.14 = "163" [ASN_COUNTER]
16-4-2018 10:05:39 (1972 ms) : 1.3.6.1.2.1.2.2.1.16 = "1479850965" [ASN_COUNTER]
16-4-2018 10:05:40 (2148 ms) : 1.3.6.1.2.1.2.2.1.20 = "0" [ASN_COUNTER]
--------------------------------------------------------------------------------------------

Regards, Randy


Apr, 2018 - Permalink

Hello Randy,

If you enter the settings page of the device, which SNMP version is marked for the "Credentials for SNMP Devices"? According to the results of the SNMP Tester, this needs to be SNMP v1.

Best regards, Felix


Apr, 2018 - Permalink

Hi Felix,

I know its V1. As mentioned in my starting post, i already sucessfully configured the "Single" OID sensor. That one is working just fine, i know how to configure them :) The multi OID is simply not working.


Apr, 2018 - Permalink

Hello Randy,

Could you please provide a screenshot of the settings page of the SNMP Custom (Advanced) sensor?

Best regards, Felix


Apr, 2018 - Permalink

Sorry for the slow reactions. But Im not getting any e-mails that a reaction has been posted.

You request: https://imgur.com/a/P3bxucc

The lookup table: https://imgur.com/a/n672AhG

Regards, Randy


Apr, 2018 - Permalink

Hi Randy,

The next step is to run a WireShark capture on the host where the probe of PRTG is installed and where the sensors are configured. Create a capture filter (not display filter) and forward the pcap file after the sensor failed at least once. The filter can look like this (without the quotation marks): udp port 161

Please forward the results to support@paessler.com and refer to this article. Thanks!

Best regards, Felix


Apr, 2018 - Permalink

Hi Felix,

I think we finally located the issue with the assistantance of WireShark. (https://imgur.com/a/P3bxucc) It seems like 7+ OID's in a simultaneous GET is not working. (No response) When i create a sensor with only 6 OID's for a single-get, it works fine and i get a response. I dont know if this is a limitation of our agent, or SNMP v1.. This does kind-off sucks, because i need to monitor at least 7 of the 8 switch ports :( But it seems like PRTG can only do 6 max in a single sensor... (And I prefer not having 8 SNMP Port sensors for each switch, to much clutter(

Maybe there is a way to rebuild this sensor so it you can choose for a "Single" for-loop kind of approach, or a multiget. Other idea is to let you specify a max multi-get value, so it only does 5 at the time for example.

EG:

(for-loop aproach) Get-request OID-1 Get-request OID-2 Get-request OID-3 Get-request OID-4 Get-request OID-5 Get-request OID-6 Get-request OID-7 Get-request OID-8 Get-request OID-9 Get-request OID-10 Result = X

Or

(for-loop aproach max value) Get-request OID-1 OID-2 OID-3 OID-4 OID-5 Get-request OID-6 OID-7 OID-8 OID-9 OID-10 Result = X

Instead of (Single Get) Get-request OID-1 OID-2 OID-3 OID-4 OID-5 OID-6 OID-7 OID-8 OID-9 OID-10 Result = X

Regards, Randy


Apr, 2018 - Permalink

Hello Randy,

According to the WireShark capture the PRTG sensor successfully sends the multi get commands, but the device refuses to answer for any reason. We just can tell that the response does not arrive at the PRTG host.

This appears to be a limitation of the target's SNMP daemon, if you check interface 7 manually, does it return values? One thing you can try is to enable Single Get in the SNMP Compatibility Options of the device within PRTG to see if the device answers correctly then.

Best regards, Felix


May, 2018 - Permalink

Hi Felix,

Yes! Enabling Single Get fixed my issue. I've never seen this option, but it was exaclty what i needed as mentioned in my previous comment. It seems our SNMP daemon is only capable of answering a multi-get of 6. It would be great as "future" feature to be able to specify a sort of "max" multi-get value in the Compatibility options. That would reduce load a bit, instead of single-gets the application does 2 multi-gets of 5 OID's each for example. But for now, this works perfectly!

Thanks again Felix!

Regards, Randy


May, 2018 - Permalink