NetXMS Support Forum

Hi,

it looks that DCI data processing for some reason takes too long. Do you have any transformation scripts or script thresholds on those push DCIs?

Best regards,
Victor

Hi,

what is NetXMS version, and what are firmware versions on Mikrotiks? We did some fixes recently for handling incorrectly (in a non-standard way) reported LLDP data by some Mikrotik devices, so if version is relatively old upgrade may help. Otherwise I would like to look at SNMP walk results for .1.3.6.1.2.1.2.2, .1.0.8802.1.1.2.1.4.1.1, and .1.0.8802.1.1.2.1.3.7.1 for all involved devices.

Best regards,
Victor

Yes, currently network discovery code assumes that other zones are only fully reachable via proxy. I will think how to fix that.
Out of curiosity, what is the reason for creation of separate zone if everything within that zone is directly reachable from server?

Best regards,
Victor

Hi,

currently MODBUS/TCP is not supported, although we plan to add it.

Best regards,
Victor

Hi,

it should be possible with simple Java application (or maybe even nxshell script) that will receive data in NMEA format, extract coordinates, and update appropriate node object via NetXMS API. This can also be implemented as server module in C++.

Best regards,
Victor

Hi,

this could indicate bottleneck when objects are being saved to database. Try to enable parallel writes by increasing values of parameters ThreadPool.Syncer.BaseSize and ThreadPool.Syncer.MaxSize (I would recommend starting with 3 or 4 and see if there will be any difference). You may also increase value of SyncInterval to reduce number of writes. It also probably worth checking database performance.

Best regards,
Victor

Hi,

you can use script like this:

for(d : FindAllDCIs($node, null, "Signal - * Transceiver Receive Power Sensor"))
{
   value = GetDCIValue($node, d->id);
   if (vmin == null or vmin > value)
      vmin = value;
   if (vmax == null or vmax < value)
      vmax = value;
}
// Here vmin and vmax variables contains min and max values for matching DCIs


Best regards,
Victor

Hello,

yes, it's possible. I can take a look tomorrow at your server. Will send you PM with contact details.

Best regards,
Victor

Hi all!

We just published minor patch release for version 3.8. Only server and agent on FreeBSD 13 are affected. Changes since previous patch release:

- Fixed potential data loss in InfluxDB driver
- Fixed invalid memory access in NXSL VM when using expression variables
- Fixed interface counters access by agent on FreeBSD 13
- Fixed bug in CAS server access
- Fixed bug in report definition processing
- Fixed server deadlock during proxy load rebalancing
- Read system description before interface list during configuration poll
- Separate debug tag for SMTP sender

Best regards,
Victor

Hi,

you can create script DCI that will collect all necessary information into table. For example, create script in script library:

table = new Table();
table->addColumn("Node", DCI::STRING, "Node", true);
table->addColumn("Interface", DCI::STRING, "Interface", true);
table->addColumn("Speed", DCI::INT32, "Speed");

for(n : GetAllNodes())
{
   if (!n->isSNMP)
      continue;
   for(i : n->interfaces)
   {
    row = table->addRow();
    table->set(row, 0, n->name);
    table->set(row, 1, i->name);
    table->set(row, 2, i->speed);
   }
}

return table;


Then create table DCI on any node (I usually use node representing NetXMS server itself) with origin "Script". and set script name as parameter name. Value of this table DCI will contain list of all interfaces on all SNMP capable nodes with their speeds. By changing script you can add more columns and change conditions for inclusion as needed.

Best regards,
Victor

Hi,

I just fixed it. Fix will be included into next release.

Best regards,
Victor

Most likely you are trying to delete event itself, which is not possible, because it is system event. I was talking about processing rule (go to Configuration -> Event Processing policy, and look for SYS_TUNNEL_SETUP_ERROR in rule conditions - there will be rule that generates alarm from that event).

Best regards,
Victor

Then it looks like some agents or even unrelated to NetXMS application attempts to connect to port 4703. Most likely can safely ignore this. To avoid spamming disable or delete EPP rule that process SYS_TUNNEL_SETUP_ERROR event. Alternatively, you can block access to port 4703 on firewall.

Best regards,
Victor

Are you actually using agent tunnels? Usually this error indicates problem with server certificate or one of trusted CA certificates.

Best regards,
Victor

Мне хочется его доделать, просто руки не дошли пока. Постараюсь найти время в ближайшую неделю.