Возвращает левые данные по snmp

[Lurker]

запрашиваю данные по snmp. Zabbix выдаёт какой-то бред.
запрашиваю другой программой тот-же OID-получаю нормальные данные

https://yadi.sk/d/m-IQ4Tjiz8yQa

На радикал тоже залил, но ругается на количество ссылок. Простите что не слишком удобно получается.

[yukra]

запрашиваю данные по snmp. Zabbix выдаёт какой-то бред.
запрашиваю другой программой тот-же OID-получаю нормальные данные

https://yadi.sk/d/m-IQ4Tjiz8yQa

На радикал тоже залил, но ругается на количество ссылок. Простите что не слишком удобно получается.

Проблема компьютеров в том, что они делают то, что мы им приказываем, а не то, что мы от них хотим.


1.3.6.1.2.1.2.2.1.2.2 - это не "один" OID, а таблица c OID'ами, вам нужно настраивать не айтем, а прототип айтема https://www.zabbix.com/documentation...d_%D0%BE%D0%B2

[Lurker]

1)Таблица это 1.3.6.1.2.1.2.2.1.2

https://www.zabbix.com/documentation/2.2/ru/manual/config/items/itemtypes/snmp/special_mibs

У меня же конкретный элемент 1.3.6.1.2.1.2.2.1.2.2
2)Обнаружение уже настроено. Оно отработало и создало данный элемент.

[yukra]

1)Таблица это 1.3.6.1.2.1.2.2.1.2

https://www.zabbix.com/documentation/2.2/ru/manual/config/items/itemtypes/snmp/special_mibs

У меня же конкретный элемент 1.3.6.1.2.1.2.2.1.2.2
2)Обнаружение уже настроено. Оно отработало и создало данный элемент.

[root@zabbix ~]# snmpwalk -On -v 2c -c public 192.168.33.76 1.3.6.1.2.1.2.2.1.2
.1.3.6.1.2.1.2.2.1.2.1 = STRING: GigabitEthernet1/1
.1.3.6.1.2.1.2.2.1.2.2 = STRING: GigabitEthernet1/2
.1.3.6.1.2.1.2.2.1.2.3 = STRING: GigabitEthernet1/3
.1.3.6.1.2.1.2.2.1.2.4 = STRING: GigabitEthernet1/4
.1.3.6.1.2.1.2.2.1.2.5 = STRING: GigabitEthernet1/5
.1.3.6.1.2.1.2.2.1.2.6 = STRING: GigabitEthernet1/6
.1.3.6.1.2.1.2.2.1.2.7 = STRING: GigabitEthernet1/7
.1.3.6.1.2.1.2.2.1.2.8 = STRING: GigabitEthernet1/8
.1.3.6.1.2.1.2.2.1.2.9 = STRING: GigabitEthernet1/9
.1.3.6.1.2.1.2.2.1.2.10 = STRING: GigabitEthernet1/10
.1.3.6.1.2.1.2.2.1.2.11 = STRING: GigabitEthernet1/11
.1.3.6.1.2.1.2.2.1.2.12 = STRING: GigabitEthernet1/12
.1.3.6.1.2.1.2.2.1.2.13 = STRING: GigabitEthernet1/13
.1.3.6.1.2.1.2.2.1.2.14 = STRING: GigabitEthernet1/14

[Lurker]

yukra всё как я и говорил.
1.3.6.1.2.1.2.2.1.2 таблица
1.3.6.1.2.1.2.2.1.2.2 элемент

1.3.6.1.2.1.2.2.1.2.2 - это не "один" OID, а таблица c OID'ами

[root@zabbix ~]# snmpwalk -On -v 2c -c public 192.168.33.76 1.3.6.1.2.1.2.2.1.2

если как вы утверждаете таблица это
1.3.6.1.2.1.2.2.1.2.2
то почему вы сделали snmp walk
1.3.6.1.2.1.2.2.1.2
?

Добавил 4-й скрин по ссылке в 1-м посте.
там видно, что в большинстве(а по факту в подавляющем большинстве, просто не стал скринить весь список)
1.3.6.1.2.1.2.2.1.2.7 возвращает НЕ верное значение, но иногда проскакивает верное.

[yukra]

yukra всё как я и говорил.
1.3.6.1.2.1.2.2.1.2 таблица
1.3.6.1.2.1.2.2.1.2.2 элемент



если как вы утверждаете таблица это
1.3.6.1.2.1.2.2.1.2.2
то почему вы сделали snmp walk
1.3.6.1.2.1.2.2.1.2
?

Добавил 4-й скрин по ссылке в 1-м посте.
там видно, что в большинстве(а по факту в подавляющем большинстве, просто не стал скринить весь список)
1.3.6.1.2.1.2.2.1.2.7 возвращает НЕ верное значение, но иногда проскакивает верное.

оу. точно, я не прав с оидом.
А у вас случайно нет второго хоста с данным ip-адресом? такое ощущение что 2 устройства "борятся" за обладание этим 172.16.222.222

[Kos]

Lurker, было бы проще сориентироваться, если бы Вы указали версию Вашего Zabbix-сервера и показали бы правило обнаружения и прототип элемента данных.
Мониторинг по SNMP - область, в которой возможности Zabbix-а довольно интенсивно развиваются, и от версии может зависеть многое.

[Lurker]

А у вас случайно нет второго хоста с данным ip-адресом? такое ощущение что 2 устройства "борятся" за обладание этим 172.16.222.222

на 100% гарантировать не могу, но из одной подсети один комп получается ВСЕГДА(раз 40 пробовал) правильное значение, а заббикс почти всегда неправильное
целевой коммутатор в другой подсети и пакет проходит через фаервол чекпоинт. Всегда одну ноду. Я не вижу причин по которой пакеты от одного клиента будут лететь в одну сторону, а от другого в другую.
dhcp не выдавал такой адрес.
Теоретически кто-то мог бы забить статику, но проверить это пока не могу. И всё равно странно получается, с учётом вышеизложенного.

версия zabbix 3.2
шаблон на других хостах работает.
вкратце вот:
discovery[{#SNMPVALUE},1.3.6.1.2.1.2.2.1.2]

.1.3.6.1.2.1.2.2.1.2.{#SNMPINDEX}

вроде остальные параметры не влияют, но если надо выложу скриншоты.

[Kos]

Спасибо.
Действительно, странно. В конфигурации всё верно, не вижу, к чему придраться.
Даже если бы по какой-то причине на запрос отвечало другое устройство, то всё равно данный OID относится к одним из самых стандартных, т.е. по-любому там должен быть какой-то сетевой интерфейс. Та левота, которая возвращается реально, на наименование сетевого интерфейса не совсем похожа.

Остаётся только ловить tcpdump-ом трафик на Zabbix-сервере и затем его разглядывать каким-нибудь WireShark-ом - глядишь, и найдётся что-то необычное.
Мы, например, в своё время таким образом выловили ошибку конфигурации фаервола, в результате которой Zabbix-агент мог общаться с Zabbix-сервером только в активном режиме, а в пассивном - ни в какую. Оказалось, что из-за хитрого сочетания настроек NAT-а в случае, когда инициатором соединения был Zabbix-сервер, то ответы от Zabbix-агента приходили назад с другого IP, нежели тот, на который они были посланы (и, что логично, отвергались). При этом в логах самого фаервола всё было в полном порядке: нужные пакеты пропускались куда надо (ведь приходили же!). Может, и тут что-либо подобное. Тем более, что SNMP работает не по TCP, а по UDP (т.е. предварительного установления соединения не требует).

[yukra]

на 100% гарантировать не могу, но из одной подсети один комп получается ВСЕГДА(раз 40 пробовал) правильное значение, а заббикс почти всегда неправильное
целевой коммутатор в другой подсети и пакет проходит через фаервол чекпоинт. Всегда одну ноду. Я не вижу причин по которой пакеты от одного клиента будут лететь в одну сторону, а от другого в другую.
dhcp не выдавал такой адрес.
Теоретически кто-то мог бы забить статику, но проверить это пока не могу. И всё равно странно получается, с учётом вышеизложенного.

А с заббикса - проблема только в интерфейсе или в snmpwalk'е тоже данные неправильные?
Может написать скрипт, которые будет снимать подряд 2 запроса: 1.3.6.1.2.1.2.2.1.2.2 и какой нить .1.3.6.1.2.1.1 (system) и найдете что-то интересное в sysName или sysContact?
А оборудование сетевое умное? на роутете можно периодически смотреть соответствие mac-IP и ip-port.

[Lurker]

А с заббикса - проблема только в интерфейсе или в snmpwalk'е тоже данные неправильные?
Может написать скрипт, которые будет снимать подряд 2 запроса: 1.3.6.1.2.1.2.2.1.2.2 и какой нить .1.3.6.1.2.1.1 (system) и найдете что-то интересное в sysName или sysContact?
А оборудование сетевое умное? на роутете можно периодически смотреть соответствие mac-IP и ip-port.

У меня доступ только к веб интерфейсу заббикса
Скрипт могу попросить добавить, но я не могу его написать с первой попытки. А пробовать много раз-меня пошлют.
mac-ip точно нет, т.к. заббикс в другой подсети относительно оборудования.
Ip-port.. хз, а смысл?

[yukra]

У меня доступ только к веб интерфейсу заббикса
Скрипт могу попросить добавить, но я не могу его написать с первой попытки. А пробовать много раз-меня пошлют.

#!/usr/bin/env bash

LOG=/tmp/log.txt
COMM=public
IP=172.16.222.222
SNMPWALK=`which snmpwalk`
func() {
	echo "===============`date`===================" >> ${LOG}
	${SNMPWALK} -On -v 2c -c ${COMM}  ${IP}  1.3.6.1.2.1.2.2.1.2.2 >> ${LOG}
	${SNMPWALK} -On -v 2c -c ${COMM}  ${IP}  1.3.6.1.2.1.1 >> ${LOG}
}
for i in {1..6}; do func; sleep 10; done

mac-ip точно нет, т.к. заббикс в другой подсети относительно оборудования.
Ip-port.. хз, а смысл?

mac-ip нужно смотреть на роутере, который одним интерфейсом подключен к сети с проблемным узлом, во втором случае я имел ввиду конечно mac-port, которые так же нужно на роутере смотреть, но как понимаю у вас нет доступа.
Поэтому я вижу примерно такой вариант решения:
скрипт выше, меняете значение переменной LOG так, что бы мы могли его читать самостоятельно (я не знаю что у вас за веб-сервер и как он настроен, но скорей всего будет достаточно писать в "корневую директорию веб-сервера обрабатывающего запросы к веб-интерфейсу заббикса" и оттуда же читать банально через браузер типа http://zabbix.yourCompanyName.dot/log.txt)
Просите добавить его в cron раз в минуту (только смотрите что бы у пользователя, который будет это запускать хватило прав доступа на запись в указанный выше лог) и смотрите что именно падает в лог.
Если в лог падают "то правильные, то неправильные данные" то сваливаете задачу на коллег с ответственных за сети и пусть дальше сами покапают ибо у вас доступа нет. Если же данные в логе всегда верные (а в заббикс продолжают попадать неверные), то тут без рутовых доступов к серверу сложно что-то придумать.

Зы я не особенно фанат писать на баше и стараюсь обычно избегать этого ... этот пример у меня работает на 4.2.46 (стандартный баш для CentOS7)

[Lurker]

Скрипт не добавили, но меня пустили на сервер по телнету.
попробовал переделать скрипт в команду, но результат неудвлетворительный
[root@mscs-zx-01 ~]# 'which snmpwalk' -On -v 2c -c kbzsnmp 172.16.222.222 1.3.6.1.2.1.1
-bash: which snmpwalk: command not found
[root@mscs-zx-01 ~]# snmpwalk -On -v 2c -c kbzsnmp 172.16.222.222 1.3.6.1.2.1.1 -bash: snmpwalk: command not found
где искать snmpwalk? Я в линуксе не шарю.

[Kos]

Скрипт не добавили, но меня пустили на сервер по телнету.
попробовал переделать скрипт в команду, но результат неудвлетворительный
[root@mscs-zx-01 ~]# 'which snmpwalk' -On -v 2c -c kbzsnmp 172.16.222.222 1.3.6.1.2.1.1
-bash: which snmpwalk: command not found
[root@mscs-zx-01 ~]# snmpwalk -On -v 2c -c kbzsnmp 172.16.222.222 1.3.6.1.2.1.1 -bash: snmpwalk: command not found
где искать snmpwalk? Я в линуксе не шарю.

В первом случае - там должны были быть обратные апострофы (подставить результат выполнения команды, в данном случае - команды which, которая должна вывести полный путь к утилите snmpwalk).
Во втором случае - команда snmpwalk по стандартным путям не найдена (обычно её кладут в /usr/bin, хотя на конкретном дистрибутиве путь может и отличаться).
Видимо, на этой машине snmpwalk просто отсутствует

[Lurker]

А если я попробую сделать yum install net-snmp-utils я могу что-то сломать?