NetXMS Support Forum

If you want to check the website from the agent running on that node, then yes.
(that is not very useful tho, because it may run locally, but may not run remotely)

So usually, you want to check from the NetXMS server.
Here you would set "Source node" to the NetXMS server.

Assuming you are binding from the template then, you would set the DCI parameter as:
ServiceCheck.Custom(%{node_primary_ip},80)

This will replace the %{node_primary_ip} macro in each DCI for the IP address of the node the DCI is bound to.
https://wiki.netxms.org/wiki/UM:Data_Collection#Macros_in_template_items

As a last note, I recommend doing ServiceCheck.HTTP rather than ServiceCheck.Custom, since it will actually check the website returned.
Documentation here: https://wiki.netxms.org/wiki/Subagent:PortCheck

You dont need to create DCIs for this.

Just go to the "Interfaces" tab, all port statuses can be seen there.
(and port's admin status too)

Here is an example of how to bind a template to a node if its running "freeradius" process.
We use this to automatically bind templates which monitor FreeRadius on VMs running it.

searchProcess = "freeradius";
procArray = AgentReadList($node, "System.ProcessList");

if (procArray == null)
  return false;

foreach (process : procArray) {
  if (index(process, searchProcess) != 0)
    return true;
}

return false;



Here is the auto-bind script we use with our MikroTik monitoring template.

return $node->sysDescription ~= "RouterOS";


Here is a bit more complex one.
This one binds a template which monitors a PPPoE access concentrator.
Basically, if a node terminates at least 1 client pppoe connection, this template is bound to it.

transport = CreateSNMPTransport($node);
if (transport == null)
  return false;

// this is the ppp-like connection count OID
oid = ".1.3.6.1.4.1.9.9.150.1.1.1.0";

pppCount = SNMPGetValue(transport, oid);
if (pppCount == null)
  return false;

if (pppCount > 0)
  return true;

return false;


You can find full documentation on NXSL here:
https://wiki.netxms.org/wiki/Scripting_Guide

You can do this with auto-bind templates.
(auto-bind scripts are run on each configuration poll)

We do exactly this in our system, when we add a device NetXMS will basically automatically discover what is available on that device, and start monitoring it.

Again, the same thing I mentioned in the above post.

Go to MIB Explorer, past that oid, and walk it.
You will see actual OIDs which hold values then.

Its the same issue for this OID as the previous one.

There will be other OIDs below the OID you showed us in the screenshot which hold the actual values.
The OID in your screenshot is just a part of the path, not the actual destination where values are held.

Go to MIB Explorer, past that oid, and walk it.
You will see actual OIDs which hold values then

Again, this breaks basic IP communication standards.
Packets like this would not traverse through any SPI firewall, or any NAT.

Even basic iptables firewall on your server would block such packets.
Any network device along the path that does any SPI or NAT will drop these packets.
These packets will be considered as unsolicited packets, since they are not responses to any established UDP stream (because of wrong IP header).

What you quoted from Juniper is for SNMP traps, which behave entirelly differently from RESPONSES to SNMP requests.

Imagine if NetXMS was to implement behaviour for every vendor's broken networking/snmp implementation...
That would be a very fast way to hell...

The correct way here is for the vendor of your device to fix the broken implementation, not for NetXMS to adjust to a broken implementation.

I dont know about any way to make NetXMS do this.

This is the fault of your device, your device needs to respond from the same IP address that the connection was initiated to.
This is a basic IP networking principle, you always respond from the src-address that was the dst-address in the original packet.

I suggest contacting the device manufacturer to fix this.

File > Language > French

I can provide you with built packages from the develop branch if you wish.

This is because you downloaded the generic linux already pre-compiled package.
In this case, you can just run it.

"cd /opt/netxms/bin && chmod 0755 nxagentd && ./nxagentd"

You need to download the source if you want to compile it.

You have to do ./configure inside the NetXMS directory.

Just do "cd netxmsd" and then do configure.

1) Post your NetXMS config file (feel free to strip sensitive info)
2) Run the server under debug (netxmsd.exe -D5) and post the logfile. (make sure to set LogFile=c:\some\path\log.txt in config file)

Router will expose the data over SNMP.
SNMP needs to be configured on the router.

NetXMS will then poll the data from the router using SNMP.

Are you using "Interface::setExpectedState" NXSL functions by any chance?
There was a bug that would cause segfaults that is fixed in develop branch.

If not, your best bet in this case is to contact official Raden support, so they can help you out.
https://www.netxms.org/contact/