NetXMS Support Forum

С таблицами MAC адресов посложнее - сейчас есть только универсальный код. Его надо будет перенести в GENERIC драйвер, добавив новую точку входа, и тогда уже сделать новый для 2960, который будет правильно обрабатывать FDB для конкретной модели. Кстати, а какой драйвер сервер выбрал для 2960 (это видно на закладке Overview в панели Object Details)?

Hi!

Situations will not help this. Source of this problem is that node behind the switch/router can be polled before switch or router that is down, so NetXMS still consider it up and so mark node as down before marking router as down. This problem will be addressed in upcoming 1.2.5 release (issue https://www.radensolutions.com/chiliproject/issues/180).

Best regards,
Victor

Hi!

You have to create DCI on some node with source "Internal" and parameter name "Dummy", and use a transformation script of that DCI to make an aggregate value.

Best regards,
Victor

Hi!

You have to change DCI data type to "Integer".

Best regards,
Victor

Похоже придется делать отдельный драйвер для 2960, который будет корректно обрабатывать эту ситуацию.
То, что нет информации под  .1.3.6.1.2.1.17.7.1.2.2.1.2 - это нормально.

Ноды надо добавлять в контейнер. Правый клик на контейнере - потом "Create node".

Если у vpn'а нет своих интерфейсов с IP адресами (IPSEC например), то NetXMS сервер не может автоматически найти хосты на другой стороне. Надо добавить вручную хотя-бы один хост с агентом или SNMP на другой стороне туннеля, тогда discovery должен пойти дальше.

Нашел такое примечание на сайте Cisco (http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_55_se/configuration/guide/swmibs.html):

The BRIDGE-MIB supports the context of a single VLAN. By default, SNMP messages using the configured community string always provide information for VLAN 1. To obtain the BRIDGE-MIB information for other VLANs, for example VLAN x, use this community string in the SNMP message: configured community string @x.

Если у вас не VLAN 1, поробуйте community@vlan в SNMP WALK.

Судя по результатам SNMP walk, устройство таки неправильно сообсчает IP адреса. Я добавлю обработку такой ситуации в NetXMS сервер.

Пришлите пожалуйста результат SNMP WALK для следующих объектов:

.1.3.6.1.2.1.17.1.4.1.2
.1.3.6.1.2.1.17.7.1.2.2.1.2
.1.3.6.1.2.1.17.4.3.1.1

Очень интересная ситуация - судя по скриншотам, на loopback интерфейсе устройство сообщает внешний IP адрес, а на собственно ethernet интерфейсе - 127.0.0.1. Поскольку NetXMS сервер loopback интерфейсы (с типом 24) игнорирует, получается странная ситуация. Вопрос в причине перепутанных адресов - это либо баг в NetXMS сервере, либо в SNMP агенте на устройстве. Попробуйте получить список интерфейсов и IP адресов через snmp walk:

nxsnmpwalk -c community device_address .1.3.6.1.2.1.2.2.1.2
nxsnmpwalk -c community device_address .1.3.6.1.2.1.2.2.1.3
nxsnmpwalk -c community device_address .1.3.6.1.2.1.4.20.1

Hi!

You can use File.Count parameter on remote agent and set a threshold on data collection error. For example, if you have mapped problematic server's share on disk S:, you can add parameter File.Count(S:\) and detect collection errors.

Best regards,
Victor

Добрый день!

Мы обычно рекомендуем PostgreSQL в качестве базы данных. С Nagios плагинами проблем не должно быть, их можно запускать с любого агента как ExternalParameter.

Hi!

Yes, it is current limitation in zoning support. I have added a feature request for that.

Best regards,
Victor

Hi!

Is it for all addresses or only for some? What switches you are using in your network? Is it possible to read forwarding database from switches (Tools -> Info -> Switch forwarding database)?

Best regards,
Victor