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


SNMP traffic sensor sudden SNMP_EXECPTION_NOSUCHINSTANCE

Votes:

0

Your Vote:

Up

Down

We have several SNMP traffic sensors on our firewall and today several of those sensors suddenly produced the following error:

SNMP_EXECPTION_NOSUCHINSTANCE

It only seemed to occur with interfaces/traffic sensors for VLANs. Seeing as how the network was still operating normally I guessed there was something wrong on PRTG's end.

The names of the sensors all start with a number like (086) or (120). I tried re-adding the SNMP traffic sensors to the firewall. The new sensors worked fine.

The problem is that we will lose the configuration and historic data of those traffic sensors if we cannot get them to work again. Is there a specific cause for snmp traffic sensors to suddenly give a SNMP_EXECPTION_NOSUCHINSTANCE error? I already asked if someone changed something in the configuration of the firewall, but that did not seem to be the case.

firewall snmp-error snmp-traffic

Created on Jun 26, 2018 2:18:46 PM by  Freek (8) 1

Last change on Jun 27, 2018 6:57:12 AM by  Luciano Lingnau [Paessler Support]



3 Replies

Votes:

0

Your Vote:

Up

Down

Hello there Freek and thank you for your KB-Post.

Essentially, the "SNMP_EXECPTION_NOSUCHINSTANCE" message indicates that PRTG is querying an interface (an index for that matter) that doesn't exist.

Based on your description, that re-adding the sensor worked fine, it is very likely that the Interface's index (the number in parenthesis) has changed. Under normal circumstances, PRTG is able to recognize this index change, and the sensor should continue working. However, in this case it clearly didn't work as expected.

  • May I ask what precise PRTG version you're running? (This is visible in the footer of every webpage).
  • Please also let me know the value of the "Interface Number" for a working and non-working sensor that refers to the same interface (something like 1:eth0).

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jun 27, 2018 7:04:04 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello, thanks for the quick reply.

Example of the working and non-working sensors:

non-working(123) vlan103
working(149) vlan103

The PRTG version: 18.2.41.1652+

I also noticed that it is possible to change the interface numbers of the traffic sensors. I tried applying the interfaces of a working sensor to a non-working sensor and it started to function again. I might have to dubble check with someone about the firewall we are monitoring and see if anything changed in the configuration.

Created on Jun 27, 2018 7:18:47 AM by  Freek (8) 1

Last change on Jun 27, 2018 7:40:51 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Freek, thank you for your reply.

That's really odd. If the "name" of the interface (vlan103) hasn't changed, PRTG should definitively have picked up the index change and continue working. But indeed, as workaround it should be possible to copy/paste the working Interface Number to get a non-working sensor working again.

You might also want to refer to the following, to make sure that the interface update settings are correct:

Regarding:

I might have to dubble check with someone about the firewall we are monitoring and see if anything changed in the configuration.

Just because the Index changed, it doesn't necessarily mean that someone changed something. For example, a restart/reboot, or state change in a VPN or PPP interface may have triggered the interface number changes. Interface index changes are expected and are part of the standard. And PRTG should be able to recognize these changes, when the configuration is correct (under normal conditions).

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jun 27, 2018 7:47:10 AM by  Luciano Lingnau [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.