NetXMS Support Forum

Not sure if this is a bug or the intended behaviour, but if you update the server to 4.1.404 and leave NXMC on 4.1.333, then "Rename" is greyed out on nodes.  Not a fluke, I've seen this happen on two different installs.

With some Cisco SB switches, if you put them in stack mode then every possible potential interface in a stack is enumerated with SNMP. For example  gi1/0/1 - gi8/0/52 [and the equivalent FastEthernet as well] even if this is a "stack" of just one switch. As an example, I am look at an SG500-28P that has nearly 1000 interfaces, of which only 28 are real physical interfaces, a few are VLANs and the rest are just "imaginary".

They all have an operation state of "notPresent" so should be straightforward enough to filter out, hide or disregard, but can I do this in NetXMS?

Just looking at a server where the NodeDiscoveryPoller queue is over 600000. I can see in the logs that it is trying many many IP address starting with 172.
I found that I had added a discovery target of 172.28.15.0 with a netmask of /0. I don't actually know what this means to NetXMS, was it trying from 0.0.0.0 to 255.255.255.255 inclusive?
I think a warning that a netmask of /0 means way more IP addresses than you'd usually want would be a good idea here.

I find the Object Details > Interfaces view a bit unwieldy due to how many columns there are [I am still scrolling with a 2560x1440 screen], but I appreciate the ability to just export all this info to CSV [useful when assembling a report on a switch].
It would be nice to have a customisable list of fields to choose.
Maybe even some task-focused presets, for example:
- All [obvious]
- Topology: Name, Alias, Description, the 5 Peer* columns, *State columns
- Other use cases I haven't thought of

I don't have an answer for you but I can say that this doesn't happen to me with 4.1.333.

Address filter is empty, just filtering on SNMP/SSH/agent protocol.
Following hints in this thread
https://www.netxms.org/forum/general-support/discovery-through-proxy/15/
I increased ThreadPool.Discovery.BaseSize from 1 to 4 and enabled parallel processing, then restarted the service.
The expected node was then discovered by the next day [as with the other system, log level is such that they were rotated away so I don't know exactly when].

I am going to assume that other things I wasn't specifically looking for have been discovered as well.

16:12:21.546 *D* [topology.cdp       ] CDP(sw1 [165174]): remote IP address 192.168.10.5
16:12:21.547 *D* [topology.cdp       ] CDP(sw1 [165174]): node object for remote IP 192.168.10.5 not found

It's found this from the CDP neighbours table, presumably, but there's no hint of this in the UI. It's good information to know about, although could be optional.
Maybe the interface list is not the place for this information, it's already eleventy columns wide and needs another column like I need a hole in the head

Server.QueueSize.Current(NodeDiscoveryPoller) history over last 30 days is always in range 800-900. Does this indicate a resource issue on the server or do I need to increase the number of pollers somewhere?

Anyway. It still will not acquire this node, even though all the conditions appear to be right.


2022.07.01 14:12:52.785 *D* [poll.discovery     ] Starting active discovery check on range 10.127.10.3 - 10.127.10.3 (snmp=true tcp=true bs=1024 delay=0)
2022.07.01 14:12:54.291 *D* [poll.discovery     ] Active discovery - node 10.127.10.3 responded to ICMP probe
2022.07.01 14:12:54.291 *D* [poll.discovery     ] Checking address 10.127.10.3 in zone 0 (source: Active Discovery)
2022.07.01 14:12:54.292 *D* [poll.discovery     ] New node queued: 10.127.10.3/24
2022.07.01 14:12:54.292 *D* [poll.discovery     ] Starting SNMP check on range 10.127.10.3 - 10.127.10.3
2022.07.01 14:12:54.293 *D* [poll.discovery     ] NodePoller: processing address 10.127.10.3/24 in zone 0 (source type Active Discovery, source node [0])
2022.07.01 14:12:55.806 *D* [poll.discovery     ] Active discovery - node 10.127.10.3 responded to SNMP probe
2022.07.01 14:12:55.806 *D* [poll.discovery     ] Checking address 10.127.10.3 in zone 0 (source: Active Discovery)
2022.07.01 14:12:55.808 *D* [poll.discovery     ] Potential node 10.127.10.3 rejected (IP address already queued for polling)
2022.07.01 14:12:57.320 *D* [poll.discovery     ] Active discovery - node 10.127.10.3 responded to SNMP probe
2022.07.01 14:12:57.320 *D* [poll.discovery     ] Checking address 10.127.10.3 in zone 0 (source: Active Discovery)
2022.07.01 14:12:57.321 *D* [poll.discovery     ] Potential node 10.127.10.3 rejected (IP address already queued for polling)
2022.07.01 14:13:04.879 *D* [poll.discovery     ] Starting TCP check on range 10.127.10.3 - 10.127.10.3
2022.07.01 14:13:04.968 *D* [poll.discovery     ] Finished active discovery check on range 10.127.14.3 - 10.127.10.3



'show queues':
Node discovery poller            : 887

So is that 887 nodes waiting to be added?

It doesn't seem to like a /32 netmask for this purpose. I get no error in the GUI when adding and scanning a test discovery target with a /32 but this is logged:


2022.07.01 14:00:08.686 *D* [poll.discovery     ] Invalid address range 10.127.10.3/32


[Yes, "Subnet" is ticked and not "Address range"].
Changed it to a range of one IP address and the discovery runs as expected.

The active discovery interval is 1800s, passive is 900s. I last made any changes to NetXMS around 18:00 then posted here. 04:48 the next day, it's discovered.

2022.06.17 04:48:44.046 *D* [event.proc         ] EVENT SYS_NODE_ADDED [1] at {0} (ID:12649088 F:0x0001 S:0 TAGS:"NewObjects") FROM SW6: Node added
2022.06.17 04:48:44.046 *D* [                   ] Name for node 118685 was resolved to SW6
2022.06.17 04:48:44.046 *D* [poll.conf          ] ConfPoll(SW6 [118685]): node name resolved


Doesn't make any sense! Similar story [probably] with the other switch on site that wasn't discovering, but in that case because I increased the log level my logs only go back to 0200 and it seems to have been added before then.
Version is 4.1.377

Currently have debug level on 5.
Have a /24 subnet with multiple nodes that NetXMS has discovered previously. Two new hosts were added to this network but I just cannot get NetXMS to discover them automatically.
"Active discovery - node 172.22.141.37 responded to ICMP probe via proxy" is logged but that's it, it doesn't log that it took any further action on that specific IP.
If I add the node manually it works instantly, ie, the host is configured with the correct SNMP community.
"Starting SNMP check on range" is logged for the IP range that covers that host, but that's it.
It also mentions that it knows this host from another node's ARP cache.

https://github.com/netxms/netxms/blob/master/src/flow-collector/nxflowd/nxflowd.h

Looks like it? But has been there perhaps since 2009, maybe?

Yes, the VLANs are reported against the switchports correctly with both GENERIC and CISCO-SB driver [here I am discussing CBS350-24FP-4X].
The "Location" field is no longer populated once switching to CISCO-SB. I think this is not a problem, with GENERIC it shows the location as "0/1/0/29" for interface te1/0/1, I am not sure that location is correct.

The driver is detected as GENERIC and the Node type is Unknown.
But...it actually does an OK job anyway as GENERIC as it finds the name/version/Serial, so I think this is really just a cosmetic issue.
I have overridden the driver with the CISCO-SB one and done a configuration (full) poll.