SNMP не собираются данные

Started by MaG, February 25, 2013, 03:04:52 PM

Previous topic - Next topic

MaG

пытаюсь настроить мониторинг железки по 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-агент но хочется естественно по-нормальному сделать. что где можно посмотреть? что попробовать?

Victor Kirhenshtein

А если nxsnmpget запустить, что он скажет?

MaG

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

работает но показания отличаются

Victor Kirhenshtein

Странно. А как выглядит overview для этого хоста в консоли? Там стоит флажок isSNMP?

MaG

стоит 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 ****

MaG

какую ещё инфу предоставить? могу дать мибы и доступ к железке

Victor Kirhenshtein

Доступ к железке получить было бы очень полезно. Пишите мне на майл - victor-at-netxms.org.

Victor Kirhenshtein

Спасибо за доступ! Проблема в том, что это устройство не возвращает 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, и позволяет собирать данные. Я могу прислать патч для сервера или новый бинарник, если надо.

MaG

Виктор, спасибо за помощь!
думаю патч лучше тут выложить и включить в будущие версии - таких устройств много.

Victor Kirhenshtein

Надо заменить файлы node.cpp и snmp.cpp в каталоге src/server/core на приложенные.

wizarom

подниму эту тему, чтоб не плодить похожих.

Пытаюсь подключить по 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:~$


Подскажите, где чего еще смотреть? что не так?

Victor Kirhenshtein

Похоже на баг в нашей SNMP библиотеке. Вы могли бы получить tcpdump'ом полные пакеты, отсылаемые и получаемые snmpget и nxsnmpget?

wizarom

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-туннеля, все ок.

как быть?

pipyta

как по мне, то тут нет ничего удивительного, что пакет не может к Вам вернуться через IP ethX ибо смысла в  этом нет.  Маршрутизатор смаршрутизировал ваши пакеты по своей таблице, а вот на клиенте уже своя таблица маршрутов поэтому  и такие расхождения.
Сам столкнулся с похожей проблемой. Можно попробовать поиграться с iptables , но я смысла особого не видел городить огород и просто использовал Ip тунелей, благо у меня  там статический openvpn.

Victor Kirhenshtein

Моя рекомендация вообщем-то такая-же: использовать IP адрес туннеля как primary host name. Странно что snmpget принимает ответы с другого IP - технически понятно как это сделать, но это поперек всех стандартов. Если IP адрес туннеля динамический, то можно использовать DNS имя.