NetXMS Support Forum

Да, это ошибка в системном шаблоне. Поменяйте 1 на размер пула.

Could you please provide results of SMNP walk on OIDs .1.3.6.1.2.1.17.4.3.1 and .1.3.6.1.2.1.17.7.1.2.2.1 for that device?

Best regards,
Victor

Пока я вижу только один возможный путь появления таких дубликатов - если в процессе network discovery сервер нашел оба адреса, но на SNMP они не отзувались - то добавлены были оба. Позже, когда SNMP агент стал отвечать, сервер добавил остальные интерфейсы и добавил ноды в соответствующие подсети. Могло такое быть что изначально это устройство на SNMP запросы с сервера не отвечало?

Проверьте threshold на параметре размера пула потоков DATACOLLECTION. Событие должно генерироваться если load average > размера пула, а сейчас похоже стоит очень низкое значение.

Hi,

does your switch provide FDB information via SNMP?

Best regards,
Victor

Hi,

currently drivers can be written only in C++. If you know C++ you can built one.

To be able to create new driver we need at least MIBs for device (ideally also indicate places where to find relevant information) and either dump of SNMP walk or (preferred) access to test device over SNMP.

Best regards,
Victor

Hi,

yes, this patch will be included into 2.0.4 release.

Best regards,
Victor

Do you by any chance run netxmsd under non-root user? If yes, it has no access to raw sockets and so cannot use ICMP. You should either run netxmsd as root or give access to raw sockets using this instruction: https://wiki.netxms.org/wiki/How_to_enable_ICMP_ping_for_NetXMS_server_running_under_non-root_account.

Best regards,
Victor

Hi,

so switches always return "unknown" for admin state? Or don't return it at all? Could you please provide result of SNMP walk on .1.3.6.1.2.1.2.2.1 for such switch?

Because switch interfaces do not have IP addresses, they stuck in unknown state - because you can only ping management address of a switch. Unknown statuses effectively ignored, so you will get node down event for example when switch stop responding to ICMP ping. You can also set expected state for interfaces to IGNORE - that way interface objects will always have NORMAL status.

Best regards,
Victor

Hi,

could you please try to apply attached patch and check if server will handle gateway restart correctly?

Best regards,
Victor

For processing SYS_IF_DOWN/SYS_IF_UP events script could be easier, because you have interface index as fifth parameter:


iface = GetInterfaceObject($node, $event->parameters[5]);
return (iface != null) ? iface->alias : "no info";


Best regards,
Victor

Hi,

do you have "instance" field actually filled for DCI (it is on "Thresholds" tab in DCI properties)?

Best regards,
Victor

Добрый день,

так точно не должно быть. Покажите пожалуйста детальную информацию по продублировавшимся устройствам - скриншот overview для обеих копий, и скриншот закладки Interfaces для обеих копий.

Hi,

server will re-send SMS if driver returns failure. You should see messages like "Failed to send SMS (will retry)" in server's log on debug level 3 and higher. Because SMS is actually sent, most likely agent for some reason cannot get final OK from modem and so considers SMS sending as failure. You can confirm this by setting debug level on agent to 5 and looking for lines starting with text "SMS:".

Best regards,
Victor

Template seems normal, nothing unusual. Even if agent returns texts in some fields server should handle it correctly. There were some fixes in 2.0.4, you can try to re-enable this template when 2.0.4 will be available. If it will not help, then the only way to debug issue will be to run netxmsd under debugger and wait for crash.

Best regards,
Victor