Hi DataMiner Community, I need second opinion on the issue for which I am trying to find the Root cause.
Element was running just fine, and suddenly it showed this 'SNMP++: Invalid Target' error in StreamViewer. Also, there are other 13 elements running same protocol version without any issues. Wireshark was checked, and there is no SNMP traffic sent to device (SNMP Agent). Obviously, there is an issue with SNMP discovery...
New element was created, with just duplicating the previous element with this error, so all configurations are the same. Hostname specified is the same, and all SNMP settings are the same. I was not able to reproduce the issue (Image below).
I am pasting the comment I added on task in collab.
"
There are 3 elements with "SNMP++: Invalid Target" issue: RECT11.SDM.PROD.RPK.NZ, RECT11.TEMU.PROD.RPK.NZ, and DMR11.TEMU.PROD.RPK.NZ.
First two elements run Enatel driver, and last one runs NEC iPasolink driver. Both Enatel and NEC iPasolink driver are also assigned to other elements, and they are all running production versions. Because the same version of the driver is used by other elements, and they work correctly, this should exclude the possibility that the driver implementation is causing problems here.
It was observed that for all of those 3 elements, hostname was specified in element wizard (not explicit Ip Address), but when command nslookup was run in cmd prompt all hostnames were correctly resolved by DNS.
Wireshark was also used to check if there is any traffic being sent to devices, and It was observed that no SNMP traffic was sent to devices whose elements have" SNMP++: Invalid Target" error in stream viewer.
The elements have been duplicated, with completely identical configurations, and the 'SNMP++: Invalid Target' error is no longer present. I couldn't reproduce this problem, so it's most likely caused by caching incorrect DNS information.
"
Client is asking for an explanation, did anyone had the same issue, or maybe know more about the root cause of this?
Hi Matej,
You analysis on this all seems to make sense.
Now, in order to know the root cause, I don't think anyone can just reply to this. This could be various things and would need to be further investigated:
- Could indeed be a caching bug in DM
- Or the element could have been corrupted due to various reasons. Ex: element was updated from one protocol (version) to another with breaking changes, the element config was wrongly modified by code (QActions, Automation scripts...), etc.
So yeah, it could be many different things. Now I think the question is "is it worth it to further run such investigations?". If this is something that has been re-occurring, then I would say yes, if not, then I would be tempted to say let's be happy everything is fixed, let's keep it in the back of our mind and let's investigate further if it ever happens again.
As far as I'm concerned, this is the first time I hear about such issue.
Thank you for the response Simon. I just wanted to hear another opinion and possibly find out if anyone else has encountered this issue.
This looks like a software issue, but as the situation has been resolved, we can no longer troubleshoot the problem. When the issue occurs again, I would advise you to keep it in that state and report a software issue to get assistance.
Thank you, Jan-Klaas, for the advice and suggestion. We will keep a close eye on this…
You mention that you got the elements working again by duplicating them with the exact same configuration. Does that mean that restarting the elements didn't rectify the situation?
I was told not to restart the elements, so I didn’t do that. Element duplication has been done only.
Of course, the above answer is made considering the fact you mentioned that you were not able to reproduce the issue. If you find a way to reproduce it, then for sure it would be worth further investigating.