<![CDATA[Dynamic IP adresses on Nodes creating duplicate nodes - options?]]>I have set ResolveDNStoIPOnStatusPoll to yes to try and get NetXMS to pick up when the IP has changed however I have also got UseSNMPTrapsForDiscovery turned on.

Before Status polling can update the IP address when it does it's next status poll, the device with the new IP has already sent a trap - causing NetXMS to add a new duplicate node via Discovery.

I could set NetworkDiscoverMergeDuplicateNodes to yes - except that deletes the old Node with all the old node DCI history - which I want to keep.

Is there a way to delay the Discovery processing of traps for 5 minutes till status polling has had a chance to update the IP address?

Alternatively - and as a better solution - a simple option - RetryProcessingTrapsFromUnknownIPafterxxxMinutes - which allows Status Polling to update the IP of the existing Node and when xxx has passed (5 minutes as the default) - the trap is then properly associated to the correct device, no discovery is triggered, and no duplicate is created.

I cannot turn off UseSNMPTrapsForDiscovery as that I find the thousands of devices that are turned on only a few times each year - all with dynamic IP's.

]]>https://forum.netxms.org/topic/6060/dynamic-ip-adresses-on-nodes-creating-duplicate-nodes-optionsRSS for NodeFri, 13 Nov 2026 07:15:11 GMTMon, 22 Jul 2019 09:05:38 GMT60<![CDATA[Reply to Dynamic IP adresses on Nodes creating duplicate nodes - options? on Fri, 02 Aug 2019 09:01:03 GMT]]>These nodes do respond to snmp but DNS may not have updated at the point in time the first trap is received.

Agree - the filtering script on discovery looks to be the best option but status polling at one minute intervals may be easier - just use discovery script to wait two minutes and see if device now updated. I could also possibly use sysDescription in the filter script as the - do not add if match.

Will look again into the MAC matching theory and once I have identified what PrimaryName is as a $node variable, will try again.

]]>https://forum.netxms.org/post/26215https://forum.netxms.org/post/26215Fri, 02 Aug 2019 09:01:03 GMT<![CDATA[Reply to Dynamic IP adresses on Nodes creating duplicate nodes - options? on Mon, 29 Jul 2019 07:23:25 GMT]]>Do those nodes respond to SNMP or only send traps? If interface list can be read then theoretically NetXMS server should match discovered node to existing one by MAC address.
Also, nodes discovered via traps pass through same discovery filter script, so you may do additional filtering here - for example, get DNS name from IP address and check if it is name of existing node. If your DNS is consistent that should prevent duplicate creation.

Best regards,
Victor

]]>https://forum.netxms.org/post/26194https://forum.netxms.org/post/26194Mon, 29 Jul 2019 07:23:25 GMT<![CDATA[Reply to Dynamic IP adresses on Nodes creating duplicate nodes - options? on Sat, 27 Jul 2019 10:04:47 GMT]]>Well - it all looked hopeful - except my nodes have an IP as their primary Host Name and not the Node name - which prevents the IP being updated.

Cannot find anywhere on how to set primaryHostName for a node or even where it is stored. Only reference I found is here:
https://wiki.netxms.org/wiki/NXSL:CreateNode

I want to add to my status or configuration poll hook - or even just as a script - a way to set Primary Host Name to the Node name.

if (($node->primaryHostName != $node->name)) {
   if (($node->name != null) && ($node->primaryHostName != ""))
    {
      ChangeThePrimaryHostNameOfTheObject($node, $node->name);
    }
}

any help would be appreciated.

]]>https://forum.netxms.org/post/26180https://forum.netxms.org/post/26180Sat, 27 Jul 2019 10:04:47 GMT<![CDATA[Reply to Dynamic IP adresses on Nodes creating duplicate nodes - options? on Fri, 26 Jul 2019 13:43:55 GMT]]>Turned off discovery from traps, exported all the duplicates and then deleted them.

Long Term Solution will be, when I have time, to have a filter script on discovery so that when a node is discovery from a trap, filter script does a DNS resolution and if the name comes back as an existing node, do not add node - just let status polling with the resolve DNStoIP set to yes update the node that now has a new IP.

It means I lose that first trap - but I can live with that. I just hope the above allows the DNStoIP pick up the new IP and then pick up the SYS_NODE_UP against the new IP - which I expect it will.

]]>https://forum.netxms.org/post/26177https://forum.netxms.org/post/26177Fri, 26 Jul 2019 13:43:55 GMT