NetXMS Support Forum

So overall there are three things can affect node status:

- Alarms
- Status of node interfaces
- DCIs that have "Use this DCI for node status calculation" option set.

A node can nave alarm that belong to some alarm category that is not visible to given user. There is user right "View all alarm categories" that should be set for administrative users. Could be that this right did not get set after one of the upgrades.

How status of interfaces is transferred to node depends on status propagation settings for interfaces and status calculation settings for a node. If these are not default then node status could be different from status of underlying interfaces.

Check DCIs if "Use this DCI for node status calculation" is not set.

nxdbmgr - NetXMS utility for database operations has built-in mechanism for database migration.

nxdbmgr migrate <source>

where source is the name of netxms configuration file that points to the database you are migrating from. There's a number of options that allow to skip DCI data, etc and it's possible to migrate DCI data afterwards after starting NetXMS with the new database.

There's an outdated wiki post on that, it does not list all possible options: https://wiki.netxms.org/wiki/How_to_migrate_to_another_database

There's a big delay after "Checking SNMP..." line, which means that NetXMS is not getting any reply from the device.
Try running
snmpget -v 2c -c public DEVICE_IP 1.3.6.1.2.1.1.1.0
on NetXMS server - there should be some output. If there's none, please check community string and SNMP protocol versions supported by the device.

Make a script in scrip library, e.g. GetNodeName:
r = "";
for (n : GetAllNodes())
{
  if (n->ipAddr == $event->parameters[1])
  {
    r = n->name;
    break;
  }
}
return r;

In event template call it like this:
*OSPF State change* %[GetNodeName] %1 from %2 to %3

The script will be called in the context of the event, so the first parameter of the event where you have the IP address will be available there.

Please share the text output of full configuration poll

А в Object Details -> Overview что написано в строке Driver?

Hi!

Peer manual specification is not possible now, i've created a ticket for that, but there's no exact schedule when this could be implemented. https://track.radensolutions.com/issue/NX-1973

As for adding inventory information to nodes that have no agent and no snmp - currently inventory is populated only by server and is read-only. As developer resources are limited, some manual way could be implemented only if someone requests paid developmet (or, possibly contributes a working code for this).
Currently it's possible to store such information in custom attributes, but there's no way to display that information in the GUI.
Or, alternatively it's possible to create a push dci on the node and use a script object tool that have input field and will update the push DCI.

Да, есть какой-то баг в NetXMS, посмотрим при возможности в чем там дело. Но и сами MIB файлы похоже не соответствуют всем стандартам.

Порт - в смысле интерфейс? С интерфейсами так не получится, их статус жестко определяет при статус полле - по данным с netxms агента, snmp или icmp.
Ну разве что менять expected status интерфейса на обратный текущему, но это так себе идея.

It's the same with session agent.

Hopefully one day this issue will be implemented and life will become easier: https://track.radensolutions.com/issue/NX-1961

Can you show output of status and configuration poll for this host?

You have timestamp with year 1969 - is time on your netxms server correct?
In object details - Overview on the right hand side there is a table called Capabilities? That's communication method available for particular node. What's the value of isSNMP there? If it's No, try running Full configuration poll for that node.
Are you able to get values for these OID using snmpget from command line of the sever where NetXMS is running?

Proxies should not be required, if your servers is able to communicate to these subnets directly.
Passive discovery requires that there's netxms agent or SNMP agent on the remote machines - this way we are getting neighbors from arp tables (and not sure from where exactly in case of SNMP).
For active scanning nodes should reply either ICMP, SNMP or netxms agent - if none is happening we can not discover a node.

You can try temporarily increasing netxms server debug log
nxadm -c "debug 7"
and manually launching a scan of a subnet to better understand what's happening.
Or, alternatively you can try capturing network traffic to that subnet with tcpdump, this can also give some insight.

Thanks for the follow up

Could be added at some point in the future.
Created an issue for that: https://track.radensolutions.com/issue/NX-1971