NetXMS Support Forum

Hi,

make sure that other UPS software is not running when you try to monitor it via agent - otherwise COM port could be in use and agent may not be able to use it.

Best regards,
Victor

It could also be bug in deduplication (when server decides that two nodes are in fact represent same device and deletes one of them). You can try to turn deduplication off by setting configuration parameter NetworkDiscovery.MergeDuplicateNodes to false. Also, try to set debug level to 6, create node, wait for it to disappear, and show log file filtered by that node name.
Also, try to execute command on debug console

show object name

replacing nme with actual name of disappeared node.

Best regards,
Victor

Those lines won't have switch name, only "FDB" prefix.

idata_sc* tables are only needed for TimescaleDB deployment, so it definitely is export bug.

As for disappearing nodes - do you have any SQL errors in server log?

Best regards,
Victor

Hi,

most likely there is some DLL conflict. I'll try to check if all dependencies for pgsql.ddr were added to installer.

Best regards,
Victor

Hi,

you can set option "repeat event" for threshold - if set, threshold violation event will be re-generated while threshold is still active, and if EPP rule is correct alarm will be updated (you'll see new message and increased repeat count).

Best regards,
Victor

Please try to set debug level to 5, run topology poll on that device, and then show all log messages with prefix FDB.

Best regards,
Victor

Hi,

OID of what? Device or specific DCI you are fetching?

Best regards,
Victor

I think we can add lock option in 3.3. Regarding icon issues before refresh - looks like image library bug. What version you are using?

Best regards,
Victor

Hi,

what exact version you are using? Please show content of table "metadata".

Best regards,
Victor

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