[sanyasi]

Жили были 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 правильно интерпритировать полученное значение?

[pppoetest]

Это блинки странные могут выдать строкой, а могут выдать в хексе, посему накарябали свой класс на пхп для работы с сими железками по снмп, в котором учли эту хрень.

Edited February 18, 2014 by pppoetest

[witch]

Аналогичная фигня с 1100-06/ме

[terrible]

sanyasi, а с какой модели и ревизии снимаете МАС?

[srg555]

это нормально. нужно скормит заббиксу миб, в котором будет hint типа для oid'а

[terrible]

Попробуйте OID .1.3.6.1.4.1.171.12.15.2.1.0

[sanyasi]

Попробуйте 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"

 

В ней оба запроса выдают правильное значение...

[srg555]

sanyasi

Просто у свитча куча мак-адресов, такое частенько бывает, даже на L2-свитчах

[terrible]

Да, согласен, что-то тут не так:

аномалия на 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

 

Хотя с нормальных неперпрошитых свичей всё правильно выдаёт

[rz3dwy]

Да, согласен, что-то тут не так:

аномалия на 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