пытаюсь настроить мониторинг железки по snmp. её mib-файлы в сервер добавил, оиды видятся правильно.
при добавлении DCI вылезает ошибка:
Возникла ошибка. Подробная информация приведена в протоколе ошибок.
java.lang.NullPointerException
в старой консоли при GET выдаёт communication error.
данные не собираются.
с этого сервера с помощью snmpget данные с железки получаю:
snmpget -v1 -c public 10.10.10.10 .1.3.6.1.4.1.11195.1.5.5.1.4.1
iso.3.6.1.4.1.11195.1.5.5.1.4.1 = INTEGER: -27
в настройках ноды версию (хотя и 2с тоже работает) и комьюнити указал.
версия netxms 1.2.5
понимаю что можно сделать через push-агент но хочется естественно по-нормальному сделать. что где можно посмотреть? что попробовать?
А если nxsnmpget запустить, что он скажет?
root@netxms:/usr/local/netxms/bin# snmpget -v1 -c public 10.255.0.162 .1.3.6.1.4.1.11195.1.5.5.1.4.1
iso.3.6.1.4.1.11195.1.5.5.1.4.1 = INTEGER: -27
root@netxms:/usr/local/netxms/bin# ./nxsnmpget -v1 -c public 10.255.0.162 .1.3.6.1.4.1.11195.1.5.5.1.4.1
.1.3.6.1.4.1.11195.1.5.5.1.4.1 [INTEGER]: -28
работает но показания отличаются
Странно. А как выглядит overview для этого хоста в консоли? Там стоит флажок isSNMP?
стоит isSNMP=No
при пуле выдаёт:
[26.02.2013 14:40:20] **** Poll request sent to server ****
[26.02.2013 14:40:20] Poll request accepted
[26.02.2013 14:41:46] Starting configuration poll for node 8marta8
[26.02.2013 14:41:46] Checking node's capabilities...
[26.02.2013 14:41:46] Checking SNMP...
[26.02.2013 14:42:18] Capability check finished
[26.02.2013 14:42:18] Checking interface configuration...
[26.02.2013 14:42:18] Unable to get interface list from node
[26.02.2013 14:42:18] Interface configuration check finished
[26.02.2013 14:42:18] Checking node name
[26.02.2013 14:42:18] Node name is OK
[26.02.2013 14:42:18] Finished configuration poll for node 8marta8
[26.02.2013 14:42:18] Node configuration was not changed after poll
[26.02.2013 14:42:18] **** Poll completed successfully ****
какую ещё инфу предоставить? могу дать мибы и доступ к железке
Доступ к железке получить было бы очень полезно. Пишите мне на майл - victor-at-netxms.org.
Спасибо за доступ! Проблема в том, что это устройство не возвращает sysObjectId (.1.3.6.1.2.1.1.2.0), хотя по стандарту все должны его возвращать, а NetXMS пытается этот OID читать для оперделения того, есть SNMP на хосте или нет. Я добавил sysDescr (.1.3.6.1.2.1.1.1.0) как альтернативный тестовый OID, теперь устройство определяется как поддерживающее SNMP, и позволяет собирать данные. Я могу прислать патч для сервера или новый бинарник, если надо.
Виктор, спасибо за помощь!
думаю патч лучше тут выложить и включить в будущие версии - таких устройств много.
Надо заменить файлы node.cpp и snmp.cpp в каталоге src/server/core на приложенные.
подниму эту тему, чтоб не плодить похожих.
Пытаюсь подключить по SNMP коробку под управлением dd-wrt. Диагностика приводит к следующей ситуации:
rain@rub-s-mon:~$ snmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.2.0
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
rain@rub-s-mon:~$ snmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips
rain@rub-s-mon:~$ nxsnmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.2.0
Request timed out
rain@rub-s-mon:~$
Подскажите, где чего еще смотреть? что не так?
Похоже на баг в нашей SNMP библиотеке. Вы могли бы получить tcpdump'ом полные пакеты, отсылаемые и получаемые snmpget и nxsnmpget?
Quote from: Victor Kirhenshtein on April 30, 2013, 04:32:30 PM
Похоже на баг в нашей SNMP библиотеке. Вы могли бы получить tcpdump'ом полные пакеты, отсылаемые и получаемые snmpget и nxsnmpget?
вот что у меня получилось
snmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips
sudo tcpdump -vvv -s 1514 port 161 and host 192.168.1.1 or 10.10.50.10
00:59:00.616406 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 71)
10.10.1.13.53215 > 192.168.1.1.snmp: [bad udp cksum 4224!] { SNMPv2c { GetRequest(28) R=1788996865 system.sysDescr.0 } }
00:59:00.620446 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 134)
10.10.50.10.snmp > 10.10.1.13.53215: [udp sum ok] { SNMPv2c { GetResponse(91) R=1788996865 system.sysDescr.0="Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips" } }
при этом ответ почему то идет от 10.10.50.10 - а это адрес интерфейса tun (openvpn) на 192.168.1.1 (поднят туннель 10.10.50.0 между сетями 192.168.1.0/24 и 10.10.1.0/24)
но snmpget этот ответ устраивает...
а в случае с nxsnmpget
nxsnmpget -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.1.1.0
Request timed out
sudo tcpdump -vvv -s 1514 port 161 and host 192.168.1.1 or 10.10.50.10
01:09:49.119563 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69)
10.10.1.13.55689 > 192.168.1.1.snmp: [bad udp cksum 9952!] { SNMPv2c { GetRequest(26) R=24175 system.sysDescr.0 } }
01:09:49.122712 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 132)
10.10.50.10.snmp > 10.10.1.13.55689: [udp sum ok] { SNMPv2c { GetResponse(89) R=24175 system.sysDescr.0="Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips" } }
ну и раз теперь все видно то:
nxsnmpget -c public -v 2c 10.10.50.10 .1.3.6.1.2.1.1.1.0
.1.3.6.1.2.1.1.1.0 [STRING]: Linux DD-WRT 2.6.24.111 #3413 Sat Aug 7 06:49:52 CEST 2010 mips
то есть если опросить по адресу используемом для openvpn-туннеля, все ок.
как быть?
как по мне, то тут нет ничего удивительного, что пакет не может к Вам вернуться через IP ethX ибо смысла в этом нет. Маршрутизатор смаршрутизировал ваши пакеты по своей таблице, а вот на клиенте уже своя таблица маршрутов поэтому и такие расхождения.
Сам столкнулся с похожей проблемой. Можно попробовать поиграться с iptables , но я смысла особого не видел городить огород и просто использовал Ip тунелей, благо у меня там статический openvpn.
Моя рекомендация вообщем-то такая-же: использовать IP адрес туннеля как primary host name. Странно что snmpget принимает ответы с другого IP - технически понятно как это сделать, но это поперек всех стандартов. Если IP адрес туннеля динамический, то можно использовать DNS имя.
понятно, что совсем не по стандартам. будем использовать адреса туннелей.
спасибо за помощь! :)