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...