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.

Article Comments

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]


Jun, 2018 - Permalink

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.


Jun, 2018 - Permalink

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]


Jun, 2018 - Permalink