Короткий ответ

Красный SNMP на хосте — это UDP 161, community/SNMPv3 user и ACL источника 10.0.20.50, не «не тот шаблон Cisco». С сервера zabbix.example выполните snmpwalk тем же протоколом, что в UI. Нет walk — не трогайте OID и LLD. Walk есть, item unsupported — ключ/OID. Агент Windows WS-042 тут ни при чём, если интерфейс SNMP отдельный. Пустые графики при живом агенте: нет данных. Серый OID: unsupported.

Симптомы и как отличить

Типичная картина:

  • Monitoring → Hosts: SNMP серый/красный, ZBX может быть зелёный;
  • item'ы sysDescr timeout;
  • после смены IP Zabbix walk с ноутбука есть, с сервера нет;
  • v3: authorizationError, часы не совпадают.

Отличия:

НаблюдениеСлой
ICMP timeoutсеть L3, не SNMP
ICMP OK, UDP 161 timeoutACL/firewall/snmpd
walk OK, часть OID noSuchNameшаблон не для этой модели
только bulk крупных таблиц timeouttimeout/max-repetitions, не «SNMP мёртв»
RAID OID молчитмониторинг RAID

Возможные причины

  1. На устройстве SNMP выключен, слушает только management VRF.
  2. Community не совпало, лишний пробел в UI.
  3. ACL: разрешён IP старого Zabbix, не 10.0.20.50.
  4. Firewall Linux на пути, conntrack UDP короткий, асимметрия маршрута.
  5. SNMPv3: user, auth/priv протокол, engineID после замены железа, время.
  6. Неверный SNMP version в интерфейсе хоста (v2 vs v3).
  7. Редко: IPv6 interface в Zabbix, устройство v4-only; proxy опрашивает из другой подсети без ACL.

Диагностика

Все walk — с 10.0.20.50 или с того proxy, который стоит в Monitored by.

1. SNMPv2c

snmpwalk -v2c -c 'COMMUNITY' -t 3 -r 1 udp:10.0.20.1:161 sysDescr.0
snmpwalk -v2c -c 'COMMUNITY' udp:10.0.20.1:161 1.3.6.1.2.1.1

Подставьте community из UI (в статье плейсхолдер, не боевой). Пустой вывод + timeout — ACL/сеть. Timeout: No Response — то же. Ответ sysDescr — транспорт жив.

2. SNMPv3

snmpwalk -v3 -l authPriv -u zbx-snmp \
  -a SHA -A 'AUTH_PLACEHOLDER' \
  -x AES -X 'PRIV_PLACEHOLDER' \
  udp:10.0.20.1:161 sysDescr.0

Алгоритмы должны совпасть с устройством (SHA/AES типичны; MD5/DES не добавляйте «для совместимости», если железо умеет сильнее).

3. Сравнение источника

Если walk с ноутбука админа успешен, с 10.0.20.50 нет — на железе ACL по source. Это не баг Zabbix. Добавьте IP сервера/proxy, не «any».

ip -4 addr show
# убедитесь, что исходящий к устройству адрес — 10.0.20.50, не другой NIC

Политика маршрута / SNAT на файрволе меняет source — ACL на свитче тогда не узнаёт Zabbix.

4. UI хоста

Interface SNMP: IP, port 161, version, community или v3 context. Bulk — включён по умолчанию; на древнем железе иногда мешает, это вторично после walk.

5. tcpdump точечно

sudo timeout 15 tcpdump -ni eth0 -n udp port 161 and host 10.0.20.1

Запрос ушёл, ответа нет — устройство/ACL. Ответа нет уже на TX — routing.

Решение

Сценарий A. ACL и firewall

На устройстве: allow UDP 161 from 10.0.20.50. На Linux-файрволе Zabbix исходящий обычно уже any; блокируют чаще промежуточные ASA/nft. Не disable firewall на сервере.

Сценарий B. Community/user

Выровняйте UI и железо. Смена community — с двух сторон в одно окно, иначе двойной простой. Предпочтительнее v3 с уникальным user для Zabbix.

Сценарий C. Неверный IP/VLAN

Interface в Zabbix должен быть management-адресом, с которого SNMP отвечает. Не data-plane VLAN без snmpd.

Сценарий D. Version mismatch

v3 в UI + v2c на железе = timeout, не «почти работает». Одна версия.

Сценарий E. Walk жив, шаблон красный

Смените шаблон под вендора, увеличьте Timeout item точечно, выключите bulk на конкретном хосте если walk больших таблиц рвётся. Не увеличивайте глобальный Timeout сервера до 30s.

Доступность «железа» кроме SNMP: ICMP + TCP сервиса, см. мониторинг доступности.

Как проверить, что проблема устранена

snmpwalk -v2c -c 'COMMUNITY' -t 3 udp:10.0.20.1:161 sysDescr.0

В UI иконка SNMP зелёная, Latest data sysDescr свежий. LLD интерфейсов появился без тысячи unsupported. Триггер SNMP unavailable в OK.

Если не помогло

  • Ответ есть раз в N попыток: loss UDP, CPU устройства, слишком частый poll. Реже интервал, не 10s на ifTable.
  • Proxy: ACL на IP proxy, не 10.0.20.50.
  • Контекст SNMPv3 (Cisco) не указан.
  • IPv6 literal в интерфейсе, walk вы делали v4.

Профилактика

  • SNMP только с poller IP, v3 где железо умеет.
  • Item sysUpTime + trigger unavailable как canary, не 400 OID сразу на приёмке.
  • Документировать community в vault.
  • Для RAID/дисков лучше vendor OID + проверка walk при смене прошивки.

Практический чеклист до смены шаблона Cisco или MikroTik: snmpwalk sysDescr и sysUpTime строго с 10.0.20.50; сверка source IP в ACL с ip route get; версия v2c или v3 как в интерфейсе хоста; community из vault. Если walk есть только с ноутбука в VLAN управления, а Zabbix сидит в серверном VLAN, это маршрутизация и ACL, а не «Zabbix не умеет SNMP».

Принтеры и ИБП часто живут на v2c с коротким timeout. Вынесите их в отдельную группу с Timeout item около 5s и редким интервалом, чтобы не убивать общие pollers ядра сети. Не вешайте шаблон ядра на принтер.

Документируйте engineID SNMPv3. Замена железа без обновления UI даёт authorizationError при тех же логине и пароле. Это не повод возвращать community public. Не оставляйте 161/udp с any на периметре.

FAQ

Нужен ли агент на коммутаторе?

Нет. SNMP-хост без ZBX нормален. Не ставьте агент «чтобы зазеленело», если нет ОС под него.

TCP 161 vs UDP

Стандартный SNMP — UDP 161. TCP SNMP редкость. Zabbix interface — UDP.

Можно ли community public для теста и забыть?

Нет. Забудете. Сразу отдельное community и ACL.

snmpbulkwalk vs snmpwalk

Bulk быстрее. Если устройство ломается на bulk — в хосте Zabbix снимите use bulk, подтвердите bulkwalk вручную.

Почему с WS-042 walk работает, с сервера нет?

Вы ходите с другого source IP. ACL. Всегда диагностируйте с poller.

SNMPv1 ещё жив?

На части принтеров. Если только v1 — изолируйте, не используйте v1 на ядре сети. В UI выберите v1 только для этого хоста.