NetXMS Support Forum

GITEX started today in Dubai, and our team is participating. If you happen to be there and want to chat with us or get first hand answers to your questions, feel free to visit us at stand H1-C30 (Hall 1).
 

Пока как workaround можно сделать configuration poll hook, в котором находить нужные интерфейсы, и на них вызывать setExcludeFromTopology(true). Что-то вроде этого:

if ($node)
{
   for(iface : $node.interfaces)
   {
      for(a : iface.ipAddressList)
      {
         if (a == "0.1.134.160" or a == "192.168.1.1")
         {
            iface.setExcludeFromTopology(true);
            break;
         }
      }
   }
}

В версии 5.2 добавим какой-то более удобный встроенный механизм.

Task handler Agent.DeployPackage expects parameter string as set of key=value entries separated by semicolons. Currently only one key is supported - "package". So if you have package with ID 123 then setting task parameter to
package=123
should do the trick.

Best regards,
Victor

I mean what NetXMS shows on overview page for those nodes in "Capabilities" section - to check how server sees those devices.

This is firewall design problem in my opinion, as this is perfectly normal traffic pattern. However, I think we can implement configurable option in our SNMP stack to keep pool of sockets and reuse them when possible.
Added feature request to the tracker: https://track.radensolutions.com/issue/NX-2614

Best regards,
Victor

Just fixed it. Official fix will be in 5.1, but if you need it to work in 5.0, you can rebuild web API from source branch stable-5.0 - fix is backported here as well.

Best regards,
Victor

Just added new handler type Agent.ExecuteCommand - it will be available in version 5.1.

Best regards,
Victor

This is because scheduled task handler Action.Execute is intended for use by EPP rules for delayed action execution, and it requires reference to existing event. Also note that it is for executing server actions (that are configured on server side under Configuration -> Actions), not for executing agent-side actions (which we sometimes calling "agent commands" or "agent predefined commands" to avoid this confusion).
For now the only workaround to execute agent command by scheduler is to use scheduled script as in post that you've mentioned. I will add new scheduled task handler in 5.1 for direct agent command execution from scheduled tasks.

Best regards,
Victor

Could you please show capabilities for Ubuntu AP and adjacent router?

We currently does not have an option to configure L2 links manually, although we have this as feature request.

Best regards,
Victor

How do you schedule action execution?

Do those Ubiquity APs support LLDP?

Also, important part of topology-based correlation is ability of the server to find route from itself to managed devices. Try to select one of the Ubiquity APs, choose "route from" from context menu, and select node representing NetXMS server itself as source. Will it show complete IP path?

Best regards,
Victor

Hi,

from error message for checking smtps on port 465, looks that you have to provide server DNS name instead of IP address.

for port 25 - when you do telnet on that port, do you receive initial SMTP response?

Best regards,
Victor

Hi!

You can use object queries. Go to Tools -> Find Object, and use the following query (I assume you are using NetXMS 5.x):

with
Device = { node.name },
ExpectedState = { ['UP','DOWN','IGNORE'][expectedState] },
CurrentState = { ['UNKNOWN','UP','DOWN','TESTING','DORMANT','NOT PRESENT'][operState] }
type == INTERFACE
You will get list of all interfaces with expected state and current state (with some extra default columns).

Then you can export resulting table to CSV by selecting "Export all to CSV" from view menu or toolbar (in top right corner).

Best regards,
Victor

Just fixed it. Fix will be included into next release. Thank you for debugging and providing steps to reproduce!

Best regards,
Victor

Hello!

Can you show what NetXMS discovered for one such tower router (ad-hoh topology map for example, or export if interface table on relevant devices), and what is actual topology. We can troubleshoot topology discovery from there.

Another option for manual correlation is to somehow determine or mark relations between devices. Actual implementation will depend on your setup, below is just one example.
If you have setup like one router per tower with bunch of other devices connected to that router, you can place devices for each tower into separate container. Then you can add custom filter script to EPP rule that process SYS_NODE_DOWN event, and in that script check if device is a main tower router or additional device, and in second case, check current state of main router for the tower (which can be found based on container membership). If tower router is down, then block processing of SYS_NODE_DOWN in question.
Instead of placing devices from each tower into separate container, you can set custom attribute indicating tower number and maybe device role.

Best regards,
Victor