sanyasi Опубликовано 18 февраля, 2014 Жили были Zabbix и тысяча свитчей D-Link 1228/ME Всё у них было хорошо - мак адрес устройства снимался по OID .1.3.6.1.2.1.17.1.1.0 и ответ приходил в виде строки snmpwalk -Ou -Oq -v2c -c public 192.168.126.10 1.3.6.1.2.1.17.1.1.0 17.1.1.0 "00 22 B0 67 4B C3 " Внезапно появилась новая партия свитчей... и всё стало совсем плохо snmpwalk -Ou -Oq -v2c -c public 192.168.129.22 1.3.6.1.2.1.17.1.1.0 17.1.1.0 "xT.@l " Техподдержка D-Link посоветовала добавить ключ -Ox (print all strings in hex format) snmpwalk -Ox -Ou -Oq -v2c -c public 192.168.129.22 1.3.6.1.2.1.17.1.1.0 17.1.1.0 "78 54 2E 40 6C 20 " Но Zabbix то пользуется libsnmp, и похоже tcpdump сталкивается с такой-же проблемой интерпретации snmp ответа от д-линка. 14:05:10.142120 IP 192.168.126.10.snmp > TSL2.37806: GetResponse(37) 17.1.1.0=00_22_b0_67_4b_c3 - нормальный свитч 15:00:37.442608 IP 192.168.129.22.snmp > TSL2.34341: GetResponse(37) 17.1.1.0="xT.@l " - ненормальный Дампы ответов вроде одинаковые. По всей видимости - проблема в интерпретаторе snmp. Вопросы: 1) есть ли у кого мысли, что могло так вскружить голову snmp (может новые модные мак адреса д-линка совпадают с какой-нибудь последовательностью?) 2) как вы получаете мак адрес простых устройств d-link (может есть другие oid которые работают) 3) может както можно научить Zabbix правильно интерпритировать полученное значение? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 18 февраля, 2014 (изменено) Это блинки странные могут выдать строкой, а могут выдать в хексе, посему накарябали свой класс на пхп для работы с сими железками по снмп, в котором учли эту хрень. Изменено 18 февраля, 2014 пользователем pppoetest Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
witch Опубликовано 18 февраля, 2014 Аналогичная фигня с 1100-06/ме Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 18 февраля, 2014 sanyasi, а с какой модели и ревизии снимаете МАС? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 18 февраля, 2014 это нормально. нужно скормит заббиксу миб, в котором будет hint типа для oid'а Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 19 февраля, 2014 Попробуйте OID .1.3.6.1.4.1.171.12.15.2.1.0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sanyasi Опубликовано 19 февраля, 2014 Попробуйте OID .1.3.6.1.4.1.171.12.15.2.1.0 Спасибо, Не всё так просто оказалось... "Нормальная" версия свитча" snmpwalk -Ou -Oq -v2c -c public 192.168.110.33 enterprises.171.12.42.3.2.5.0 enterprises.171.12.42.3.2.5.0 "84-C9-B2-8D-42-20" snmpwalk -Ou -Oq -v2c -c public 192.168.110.33 enterprises.171.12.15.2.1.0 enterprises.171.12.15.2.1.0 "84:C9:B2:8D:42:60" Тут Ваш миб давал ошибочное значение... Зато нашелся миб (правда с какимито вражескими разделителями) который работает на всех устройствах. Аномальная версия snmpwalk -Ou -Oq -v2c -c public 192.168.129.22 enterprises.171.12.42.3.2.5.0 enterprises.171.12.42.3.2.5.0 "78-54-2E-40-6C-20" snmpwalk -Ou -Oq -v2c -c public 192.168.129.22 enterprises.171.12.15.2.1.0 enterprises.171.12.15.2.1.0 "78:54:2E:40:6C:20" В ней оба запроса выдают правильное значение... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 19 февраля, 2014 sanyasi Просто у свитча куча мак-адресов, такое частенько бывает, даже на L2-свитчах Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 21 февраля, 2014 Да, согласен, что-то тут не так: аномалия на 1228/ME -> 3028: pri# snmpwalk -v 2c -c private 172.16.0.161 .1.3.6.1.4.1.171.12.42.3.2.5.0 SNMPv2-SMI::enterprises.171.12.42.3.2.5.0 = STRING: "5C-D9-98-BD-3C-DF" pri# snmpwalk -v 2c -c private 172.16.0.161 .1.3.6.1.4.1.171.12.15.2.1.0 SNMPv2-SMI::enterprises.171.12.15.2.1.0 = STRING: "00:22:B0:04:0F:21" реальный МАС свича: 5C-D9-98-BD-3C-DF Хотя с нормальных неперпрошитых свичей всё правильно выдаёт Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rz3dwy Опубликовано 21 февраля, 2014 Да, согласен, что-то тут не так: аномалия на 1228/ME -> 3028: pri# snmpwalk -v 2c -c private 172.16.0.161 .1.3.6.1.4.1.171.12.42.3.2.5.0 SNMPv2-SMI::enterprises.171.12.42.3.2.5.0 = STRING: "5C-D9-98-BD-3C-DF" Если посмотреть MIB, то это DHCP-RELAY-MGMT-MIB::swDHCPRelayOption82RemoteID.0 В конфиге это config dhcp_relay option_82 remote_id default pri# snmpwalk -v 2c -c private 172.16.0.161 .1.3.6.1.4.1.171.12.15.2.1.0 SNMPv2-SMI::enterprises.171.12.15.2.1.0 = STRING: "00:22:B0:04:0F:21" реальный МАС свича: 5C-D9-98-BD-3C-DF А вот это MSTP-MIB::swMSTPName.0 И в конфиге: config stp mst_config_id name 00:22:B0:04:0F:21 revision_level 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...