Stumped - container for umnagaed nodes

[Tursiops]

Containers for Unmanaged nodes suffer from a small problem: Auto-Bind rules are applied during a configuration poll and configuration polls don't run against unmanaged nodes.
You'd probably have to write a separate script and run it on a schedule to make this work. $node->status returns "6" for unmanaged nodes.

In regards to disabled DCIs, I guess you could use a script similar to this:

dciArray = FindAllDCIs($node,"*");
for (dci : dciArray) {
	if (dci->status == 1) return true;
}

Now, the above will be true if there is any DCI on that node that's disabled. If you want to test for a specific one, you'll have to adjust the script accordingly.

[paul]

Fantastic - thanks for the assist - again.

When I was wandering through snmptrap.cpp, I did see the following which might also be of use in the script.

 if ((node->getStatus() != STATUS_UNMANAGED)

[paul]

Finally back to this and stuck at my first container - unknown only.

My autobind / autoremove is as follows - but is not adding nodes that are unknown only.

How did I manage to get this wrong

return $node->status == "5";

[paul]

Need to remember - wait long enough till polling occurs again.

My unknown container works fine based on the above.

What was my "unmanaged" solution? - I just select the container with all relevant nodes, select nodes tab - sort by status - all my unmanaged nodes found - easy as pie

Now, a container for those nodes that communication is down - which is not one of the available status codes - that is going to be tricky.

[victor]

@paul said in Stumped - container for umnagaed nodes:

Now, a container for those nodes that communication is down - which is not one of the available status codes - that is going to be tricky.

You can use runtimeFlags field of Node object - if it has bit 2 set then node in unreachable. Script to match can looks like this:

return ($node->runtimeFlags & 4) != 0;

Please note thoug that meaning of this field is changed in version 3.0.

Alternative approach is to catch SYS_NODE_DOWN event and in action script call BindObject to put node into container, and catch SYS_NODE_UP and use UnbindObject to remove node from container.

Best regards,
Victor

[Tursiops]

Is there a list of version 3 runtime flags?
We happen to be using the unreachable one for templates, so I'll need to do some updates.

Version 2 can be found here: https://wiki.netxms.org/wiki/NXSL:Node:runtimeFlags

[paul]

wow - great to know. As Tursiops notes though - need to see what these represent in v 3 before pushing forward with this completely.

I did implement a solution based on custom attribute, hooked into SYS_NODE_DOWN and SYS_NODE_UNREACHABLE / SYS_NODE_UP. My status polling hook did not have access to the outcome of the status poll (which I now assume the runtime flag does have) which meant that if SYS_NODE_UP was not triggered, container would not update. I can at least get that hook working properly - at last.

The only real problem I have with my solution and if using the runtime flag - the container that holds down devices only stays red even when last device is removed. If I progress to using the runtime flag rather than binding and unbinding via script I expect that problem will also be solved.

I think it stays red as I unbind before the SYS_NODE_UP changes the node colour back to green by clearing the SYS_NODE_DOWN alert. A timing issue and I do not want to add a "wait 5 seconds" to the various hooks - I can live with nothing down but container is red.

[Tursiops]

Just in case someone else looks at this thread looking for runtimeFlags for nodes in 3.0:
https://www.netxms.org/documentation/nxsl-3.0/#node-flags

Now my problem is that I do not actually see an "unreachable" flag in that list...  ???

[victor]

It is now available in "state" attribute (not yet added to documentation). Possible flag values are:

UNREACHABLE = 0x00000001
NETWORK_PATH_PROBLEM = 0x00000002
AGENT_UNREACHABLE  = 0x00010000
SNMP_UNREACHABLE  = 0x00020000
CACHE_MODE_NOT_SUPPORTED  = 0x00080000

Best regards,
Victor

[paul]

Great - "state" attribute works for me

The only thing to know is that a Node, Unreachable because of a Network_Path_problem, will also be SNMP_Unreachable.

So what status will that be?

In my perfect world - a Network_Path_Problem is where my ADSL/BDSL link is down but my 3G backup kicks in - so has a problem but is reachable.

For a Network_Path_Problem where I only have ADSL / BDSL - the upstream device - Router  - is Unreachable - and so is my Switch. Both of those I consider Down.

This would match the 2.2.16 flag of being unreachable - but has 3.0 undone that by having the switch as Network_Path_Problem?

Don't get me wrong - I love the fact that "state" has the various possible values - but it might be better for each of those to be a flag in their own right.

If each one was their own flags - I could have one container for nodes_down (to see who is impacted) and one excluding the Network_Path_Problem - so I can see where the actual problem is.

[victor]

Hi,

flag names didn't change since 2.2, just moved to separate "state" attribute. Runtime flag names from 2.2:

#define NDF_QUEUED_FOR_STATUS_POLL    0x000001
#define NDF_QUEUED_FOR_CONFIG_POLL    0x000002
#define NDF_UNREACHABLE                0x000004
#define NDF_AGENT_UNREACHABLE          0x000008
#define NDF_SNMP_UNREACHABLE          0x000010
#define NDF_QUEUED_FOR_DISCOVERY_POLL  0x000020
#define NDF_FORCE_STATUS_POLL          0x000040
#define NDF_FORCE_CONFIGURATION_POLL  0x000080
#define NDF_QUEUED_FOR_ROUTE_POLL      0x000100
#define NDF_CPSNMP_UNREACHABLE        0x000200
#define NDF_RECHECK_CAPABILITIES      0x000400
#define NDF_POLLING_DISABLED          0x000800
#define NDF_CONFIGURATION_POLL_PASSED  0x001000
#define NDF_QUEUED_FOR_TOPOLOGY_POLL  0x002000
#define NDF_DELETE_IN_PROGRESS        0x004000
#define NDF_NETWORK_PATH_PROBLEM      0x008000
#define NDF_QUEUED_FOR_INSTANCE_POLL  0x010000
#define NDF_CACHE_MODE_NOT_SUPPORTED  0x020000
#define NDF_NEW_TUNNEL_BIND            0x040000

In both 2.2 and 3.0 "unreachable" means that NetXMS server cannot reach the node for any reason. NETWORK_PATH_PROBLEM is an additional indicator to show that most likely node cannot be reached because of network problem on the path between NetXMS server and node (router down. etc.). Server reads routing tables from intermediate routers and builds path between itself and each node, so there is only one such path, and it either has problem or not. If there is redundant link routing eventually changes and node became reachable again, so both "unreachable" and "network path problem" flags will be cleared. NETWORK_PATH_PROBLEM flag determines what event will be generated - SYS_NODE_DOWN (if not set) or SYS_NODE_UNREACHABLE (if set).
To detect problems with non-working links you have interface objects and corresponding events.

Best regards,
Victor

[paul]

Another fantastic explanation. Thanks Victor.

Most important statement: Is unreachable universal? = yes
In both 2.2 and 3.0 "unreachable" means that NetXMS server cannot reach the node for any reason.

Second most important: Clarity on flags - same flag different value - or separate flags:
"NETWORK_PATH_PROBLEM is an additional indicator "

Will look at undoing my customization at some point, though I do like my last time up and last time down custom attributes I current add