NetXMS Support Forum

Yes, they LLDP implementation is full of inconsistencies. In LLDP local port table switch reports lldpLocPortIdSubtype as 7 (which is "local") and lldpLocPortId as number from 1 to 10, however when looking from other device we see that switch advertises same ports as Id subtype 5 ("interface name"). According to specification it is "a port identifier based on the ifName MIB object, defined in IETF RFC 2863.". However, it doesn't match actual interface name as reported via interface MIB.
Let's check walk results for OID .1.3.6.1.2.1.31.1.1.1.1 in case they report different names via ifTable and ifXTable. If this is not the case then all we can do is to add special handling in LLDP code for that particular type of switches.

Best regards,
Victor

Probably one of GetDCIValue calls return null value which is later used in arithmetic operation. You may need to add check for null values.

Best regards,
Victor

Сообщения отправляются по событиям. Можно в правило, в котором происходит отправка сообщения, добавить дополнительный скрипт-фильтр, который проверит наличие и статус соответствующего аларма.

Карта сети строится для узлов, которые добавлены в мониторинг. Если хочется их добавить автоматически, то надо еще включить network discovery (в меню Configuration).

LLDP supports multiple options for port identification. In the log I see that those devices use identification type 5 - interface name, but from what you have described it looks like information provided through LLDP MIB is inconsistent with INTERFACE MIB. Could you please provide output of SNMP WALK for .1.0.8802.1.1.2.1.3.7.1 and .1.0.8802.1.1.2.1.4.1.1 on two connected switches?

Best regards,
Victor

I suppose you are building from source. Try to do make install again, but before remove directory /usr/local/lib/netxms (and preferably everything from /use/local/lib as well). Then start server under debugger as per this instruction: https://wiki.netxms.org/wiki/Running_NetXMS_under_debugger and post output here.

Best regards,
Victor

Just added two new configuration options for version 3.3: driver blacklisting and switching SNMP probing into one OID per request mode. Either one should fix this issue.

Best regards,
Victor

If log ends abruptly that likely means server process crash. I suggest to upgrade to latest version (3.2.400), and if problem persist we will continue to debug it. There were lot of fixes since 3.1.261, so it is better to try upgrade first.

Best regards,
Victor

You can do full edit if you export dashboard into XML, edit it, and then import back. XML for individual elements can be edited directly from GUI (including layout properties).

Best regards,
Victor

Yes, that should be enough for building topology. Could you set debug level to 6, run topology poll on few switches, and provide server log file along with console output for the poll?

Best regards,
Victor

Another approach would be to set option "this is IP address of remote management node" in communication options.

Best regards,
Victor

Hi,

we decided to drop combined server/console package as part of overall effort to reduce number of packages and thus required support efforts. Actually we did expect that in most cases server is installed on separate machine and users are connected from remote workstations.

Best regards,
Victor

Hello!

I suppose netxmsd is not starting for some reason. Can you share netxmsd log file?

Best regards,
Victor

Hi all!

NetXMS 3.2 patch release 2 (version 3.2.400) is officially published. Changes since 3.2 patch release 1:

- Proxy nodes does not collect DCI data from SNMP nodes marked as down
- Configurable address block size and inter-block delay for active network discovery
- Fixed server memory leak in instance discovery code
- Fixed broken Net.ArpCache and Net.IP.RoutingTable lists in Linux agent
- Fixed issues:
        NX-791 (CPU Count DCI not supported on HP-UX)
        NX-1440 (After netxmsd restart custom schedule DCIs does not have value)
        NX-1607 (Primary IP address should not be used for topology if it is not present on any interface)
        NX-1768 (Server configuration variable Objects.Interfaces.UseAliases has no options to select)
        NX-1773 ("Apply policy" in context menu of node is meaningless and does nothing)
        NX-1803 (Configuration import with "Replace existing object tools" checkbox set does not replace them)

Best regards,
Victor

Since version 3.2 NetXMS we start adding support for EtherNet/IP communication protocol (https://en.wikipedia.org/wiki/EtherNet/IP). This message merely indicates that server cannot connect to device on EtherNet/IP TCP port (44818 by default) - which is expected unless you have EIP capable device.

Best regards,
Victor