Duplicate nodes created, Bug NX-1876, opened June-11, still unassigned

Started by tfines, July 29, 2020, 03:55:22 AM

Previous topic - Next topic

tfines

NX-1876 concerns how NetXMS 3.3 and 3.4 continue to add duplicates of nodes when a remotely monitored network happens to have the same address space as the NetXMS network.
Our server currently runs NetXMS 3.4.178.

I opened the ticket on June 11, and as of today, July 29, the ticket hasn't been assigned.

Example:
Remote network, 192.168.16.0/24, Zone 14
Local network, 192.168.16.0/24, Zone 0

NetXMS produces duplicate nodes for systems with NetXMS agents and others -- we have duplicates of printers discovered via SNMP.  They get created both in our zone and the remote zone. 

I have attached screen shots of an example of a duplicate system with the agent, and a duplicate printer.  Notice how the assigned names are different too, with the local, correct hostname, having the domain name included.

I both cases I have noted the 'creation time' of these nodes.  For whatever reason, the incorrect remote node gets created first.

I also highlight that the AgentID, which I *think* is supposed to be unique in NetXMS, is the same on both the correctly created local node and the duplicate remote node.

I really do like NetXMS, but this really is a big problem for us, as we are an MSP and will have remote networks which may have the same 192.168.xx.0/24 address space.  Please look at this problem.  I am happy to provide more information, screen shots, etc.


Alex Kirhenshtein

Hello.

Please provide your support contract ID, I'll check why issue is still pending and prioritize it.

tfines

Hi,

We don't have a contract.  I'd previously reported NX-1865, which was taken care of pretty quickly. That's why I was surprised this one was still unassigned... I understand if you have to address contracted customers first.  Thanks for replying and taking a look at it.

Ted

Victor Kirhenshtein

Response time for community support is really not guaranteed, and depends on multiple factors, mostly complexity of the issue and available resources. We always try to do our best but we cannot cannot promise fast handling for all issues. This bug will be looked at when someone from the team will have time.

Best regards,
Victor

tfines

Thanks, Victor. I appreciate all the work you guys are doing!