SNMP мониторинг сетевого оборудования: настройка и ловушки — АйТи Фреш
🌐 Сети и связь 📅 09.04.2026 ⏱️ 12 мин чтения ✍️ АйТи Фреш 👁 —

SNMP мониторинг сетевого оборудования: настройка и ловушки

Основы протокола SNMP для сетевого администратора

SNMP (Simple Network Management Protocol) — это де-факто стандарт мониторинга сетевого оборудования, который живёт уже десятилетиями. Да, gNMI, NETCONF и REST API активно развиваются, но на практике подавляющее большинство коммутаторов, маршрутизаторов, точек доступа и ИБП всё равно опрашиваются именно по SNMP. Протокол работает по схеме «менеджер — агент»: станция управления (NMS) шлёт запросы GET/SET к агенту на устройстве, а агент при необходимости сам инициирует асинхронные уведомления — trap или inform.

Версий протокола три. SNMPv1 — откровенно устаревшая, community string гуляет по сети в открытом виде. SNMPv2c — то, что мы чаще всего видим в корпоративных сетях: появился GetBulk для массового опроса, чуть лучше обработка ошибок, но аутентификация всё та же — community string без шифрования. SNMPv3 — единственный вариант с нормальной безопасностью: поддерживает аутентификацию (authNoPriv, authPriv) и шифрование (DES, AES-128/256). Если у вас продакшн — только третья версия, без компромиссов.

Каждый управляемый параметр устройства имеет свой OID (Object Identifier) — числовую иерархию вида 1.3.6.1.2.1.2.2.1.10. Запомнить эти цифры невозможно, поэтому существуют MIB-файлы, которые дают человекочитаемые имена — например, ifInOctets. Стандартные MIB описаны в RFC: IF-MIB, HOST-RESOURCES-MIB и другие. Вендоры добавляют свои приватные MIB для специфичных метрик — температура процессора, состояние вентиляторов, уровень PoE и прочее. Без вендорских MIB вы будете видеть только числовые OID, что крайне неудобно.

Порты и транспорт

SNMP работает по UDP: порт 161 — для запросов GET/SET, порт 162 — для приёма trap-уведомлений. В SNMPv3 с inform-сообщениями есть подтверждение доставки на уровне протокола, поэтому inform надёжнее обычных trap-ов — об этом часто забывают. На межсетевых экранах открывайте именно UDP, не TCP:

# iptables — разрешить SNMP-опрос с NMS 10.0.1.50
iptables -A INPUT -p udp -s 10.0.1.50 --dport 161 -j ACCEPT
iptables -A INPUT -p udp --dport 162 -j ACCEPT

Отдельная боль — среды с NAT. Trap-ы там регулярно теряются: агент отправляет trap на IP менеджера, а тот может быть за NAT и фактически недоступен напрямую. Решение простое — прописывайте trap destination на реально маршрутизируемый адрес. Либо переходите на inform: при потере пакета будет retransmit, и уведомление всё-таки дойдёт.

Установка SNMP-утилит и загрузка MIB

На сервере мониторинга под Ubuntu/Debian поставьте пакет snmp — это клиентские утилиты — и snmp-mibs-downloader для стандартных MIB-файлов:

apt update
apt install -y snmp snmp-mibs-downloader libsnmp-dev

# Загрузить стандартные MIB
download-mibs

# Раскомментировать строку для автозагрузки MIB
sed -i 's/^mibs :$/# mibs :/' /etc/snmp/snmp.conf

После этого snmpwalk, snmpget и snmpbulkwalk начнут выдавать человекочитаемые имена вместо числовых OID — работать станет значительно комфортнее. Вендорские MIB (Cisco, MikroTik, Huawei) скачиваются с сайта производителя и кладутся в /usr/share/snmp/mibs/ или ~/.snmp/mibs/.

Проверка связи с устройством

Первый шаг при диагностике — просто убедиться, что агент на устройстве вообще отвечает:

# SNMPv2c — опрос sysDescr
snmpget -v2c -c public 192.168.1.1 sysDescr.0

# Полный обход дерева интерфейсов
snmpwalk -v2c -c public 192.168.1.1 ifDescr

# BulkWalk — значительно быстрее для больших таблиц
snmpbulkwalk -v2c -c public -Cr25 192.168.1.1 ifTable

Устройство молчит? Проверяйте по порядку: 1) включён ли SNMP на самом устройстве; 2) совпадает ли community string; 3) не режет ли ACL на устройстве адрес вашего NMS; 4) проходит ли UDP 161 через межсетевой экран. Мы в таких ситуациях всегда запускаем tcpdump -i eth0 udp port 161 на обеих сторонах — сразу видно, где пакет теряется.

Работа с MIB Browser

Для навигации по дереву OID удобен консольный snmptranslate:

# Найти OID по имени
snmptranslate -On IF-MIB::ifInOctets
# .1.3.6.1.2.1.2.2.1.10

# Найти имя по OID
snmptranslate -Of .1.3.6.1.2.1.2.2.1.10
# iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets

# Показать дерево потомков
snmptranslate -Tp IF-MIB::ifTable

Если нужен графический интерфейс — возьмите iReasoning MIB Browser, кроссплатформенный и бесплатной версии вполне хватает. Для быстрого поиска стандартных OID прямо в браузере есть oidref.com — иногда удобнее, чем лезть в консоль.

Настройка SNMPv3 на оборудовании

Для продакшна — только SNMPv3 с authPriv, никаких компромиссов. Community string в SNMPv2c идёт по сети открытым текстом. При MITM-атаке его перехватывают элементарно, и дальше у злоумышленника есть доступ к чтению, а нередко и к записи конфигурации устройства. Мы видели такие инциденты — неприятно.

Пример настройки SNMPv3 на Cisco IOS:

! Создаём view — какие OID доступны
snmp-server view MONITORING iso included

! Создаём группу с authPriv
snmp-server group MONITOR-GRP v3 priv read MONITORING

! Создаём пользователя (SHA + AES128)
snmp-server user monitor-user MONITOR-GRP v3 auth sha MyAuthPass123 priv aes 128 MyPrivPass456

! Trap destination
snmp-server host 10.0.1.50 version 3 priv monitor-user

На MikroTik RouterOS:

/snmp set enabled=yes
/snmp community remove [find]
/snmp set trap-community="" trap-version=3

# Создаём SNMPv3 пользователя
/snmp community add name=v3user security=private \
  authentication-protocol=SHA1 authentication-password=MyAuthPass123 \
  encryption-protocol=AES encryption-password=MyPrivPass456 \
  addresses=10.0.1.50/32

Проверка SNMPv3 с клиента

После настройки проверьте связь утилитой snmpwalk с указанием параметров безопасности:

# authPriv — полная защита
snmpwalk -v3 -u monitor-user -l authPriv \
  -a SHA -A MyAuthPass123 \
  -x AES -X MyPrivPass456 \
  192.168.1.1 sysUpTime.0

# authNoPriv — только аутентификация без шифрования
snmpwalk -v3 -u monitor-user -l authNoPriv \
  -a SHA -A MyAuthPass123 \
  192.168.1.1 sysDescr.0

Частая ошибка — несовпадение Engine ID при настройке inform-сообщений. Engine ID агента смотрите командой snmpget -v3 -u monitor-user -l authPriv -a SHA -A pass -x AES -X pass 192.168.1.1 snmpEngineID.0. На Cisco IOS Engine ID генерируется автоматически из IP-адреса, но на ряде платформ его придётся задавать вручную — иначе inform просто не заработают.

Настройка SNMP Trap и Inform

SNMP trap — асинхронное уведомление от устройства к NMS. Чем принципиально отличается от polling? При polling вы узнаёте о проблеме только на следующем цикле опроса — через минуту, пять, десять. Trap приходит немедленно: link down, высокая температура, ошибка питания — всё это прилетает в момент события. Для быстрого реагирования trap-ы критичны.

На сервере мониторинга настройте демон snmptrapd:

# /etc/snmp/snmptrapd.conf

# Для SNMPv2c
authCommunity log,execute,net public

# Для SNMPv3
createUser -e 0x80001F88043139322E3136382E312E31 monitor-user SHA MyAuthPass123 AES MyPrivPass456
authUser log,execute monitor-user

# Логирование в файл
[snmptrapd] logoption f /var/log/snmptrapd.log

# Обработчик — вызов скрипта при получении trap
traphandle default /usr/local/bin/trap_handler.sh

Запуск демона:

systemctl enable snmptrapd
systemctl start snmptrapd

# Проверка — отправить тестовый trap
snmptrap -v2c -c public 127.0.0.1 '' .1.3.6.1.4.1.99999 \
  .1.3.6.1.4.1.99999.1 s "Test trap message"

Скрипт обработки trap-уведомлений

Скрипт-обработчик получает данные trap через stdin:

#!/bin/bash
# /usr/local/bin/trap_handler.sh

LOGFILE="/var/log/snmp_traps_processed.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

# Читаем hostname и IP
read HOST
read IP

# Читаем OID/value пары
VARBINDS=""
while read OID VAL; do
  VARBINDS="$VARBINDS $OID=$VAL"
done

echo "[$TIMESTAMP] Host=$HOST IP=$IP $VARBINDS" >> $LOGFILE

# Отправка в Telegram при критических trap-ах
if echo "$VARBINDS" | grep -q 'linkDown\|coldStart\|authenticationFailure'; then
  curl -s -X POST "https://api.telegram.org/bot${TG_BOT_TOKEN}/sendMessage" \
    -d chat_id="${TG_CHAT_ID}" \
    -d text="🚨 SNMP Trap: $HOST ($IP) — $VARBINDS"
fi

Не забудьте сделать скрипт исполняемым: chmod +x /usr/local/bin/trap_handler.sh. Без этого demон молча проигнорирует обработчик, и вы будете долго гадать, почему trap-ы никуда не попадают.

Ключевые OID для мониторинга оборудования

Перед тем как что-то мониторить, нужно понять — а что вообще опрашивать? За 15 лет работы с сетями я выделил несколько групп OID, которые реально нужны на типичном сетевом устройстве:

МетрикаOIDMIB
Описание устройства1.3.6.1.2.1.1.1.0 (sysDescr)SNMPv2-MIB
Uptime1.3.6.1.2.1.1.3.0 (sysUpTime)SNMPv2-MIB
Имя интерфейса1.3.6.1.2.1.2.2.1.2 (ifDescr)IF-MIB
Статус интерфейса1.3.6.1.2.1.2.2.1.8 (ifOperStatus)IF-MIB
Входящий трафик1.3.6.1.2.1.31.1.1.1.6 (ifHCInOctets)IF-MIB
Исходящий трафик1.3.6.1.2.1.31.1.1.1.10 (ifHCOutOctets)IF-MIB
Ошибки входящие1.3.6.1.2.1.2.2.1.14 (ifInErrors)IF-MIB
Загрузка CPU (Cisco)1.3.6.1.4.1.9.9.109.1.1.1.1.8 (cpmCPUTotal5minRev)CISCO-PROCESS-MIB
Свободная RAM (Cisco)1.3.6.1.4.1.9.9.48.1.1.1.6 (ciscoMemoryPoolFree)CISCO-MEMORY-POOL-MIB
Температура (Cisco)1.3.6.1.4.1.9.9.13.1.3.1.3 (ciscoEnvMonTemperatureValue)CISCO-ENVMON-MIB

Если у вас интерфейсы от 1 Гбит/с и выше — забудьте про SNMPv1. 32-битные счётчики на гигабитном порту переполняются буквально за секунды, и вместо реального трафика вы получите мусор. Только SNMPv2c или v3, только ifHCInOctets/ifHCOutOctets с поддержкой Counter64.

Расчёт скорости из счётчиков

Счётчики ifHCInOctets/ifHCOutOctets сами по себе — просто монотонно растущие числа. Скорость из них не считается напрямую: берёте два последовательных значения, вычитаете, делите на интервал между опросами — вот и получаете байт в секунду:

# Формула:
# speed_bps = (counter_now - counter_prev) * 8 / interval_seconds

# Пример на Python:
import time
from pysnmp.hlapi import *

def get_counter(host, community, oid):
    iterator = getCmd(
        SnmpEngine(),
        CommunityData(community),
        UdpTransportTarget((host, 161)),
        ContextData(),
        ObjectType(ObjectIdentity(oid))
    )
    errorIndication, errorStatus, errorIndex, varBinds = next(iterator)
    if errorIndication:
        raise Exception(str(errorIndication))
    return int(varBinds[0][1])

oid_in = '1.3.6.1.2.1.31.1.1.1.6.1'  # ifHCInOctets, ifIndex=1
c1 = get_counter('192.168.1.1', 'public', oid_in)
time.sleep(60)
c2 = get_counter('192.168.1.1', 'public', oid_in)

speed_mbps = (c2 - c1) * 8 / 60 / 1_000_000
print(f"Входящая скорость: {speed_mbps:.2f} Мбит/с")

Интеграция SNMP с Zabbix

Zabbix — де-факто стандарт для SNMP-мониторинга в большинстве компаний, с которыми мы работаем. Там уже всё есть из коробки: SNMP discovery сам обнаружит интерфейсы, а готовые шаблоны закроют 80% задач по сетевому оборудованию без лишних телодвижений.

Как подключить устройство — по шагам:

  1. В Zabbix Frontend создайте хост, укажите SNMP interfaces (IP, порт 161)
  2. На вкладке Macros задайте {$SNMP_COMMUNITY} или SNMPv3-параметры
  3. Привяжите шаблон — например, Template Net Cisco IOS SNMPv2
  4. Zabbix автоматически обнаружит интерфейсы через LLD (Low-Level Discovery) — руками прописывать каждый порт не придётся

Если используете SNMPv3, в макросах хоста прописываете:

{$SNMPV3_USER}       = monitor-user
{$SNMPV3_AUTH_PASS}  = MyAuthPass123
{$SNMPV3_PRIV_PASS}  = MyPrivPass456
{$SNMPV3_AUTH_PROTO} = SHA
{$SNMPV3_PRIV_PROTO} = AES

Оптимизация SNMP-опроса в Zabbix

Когда мониторишь сотни устройств с тысячами интерфейсов, SNMP poller начинает задыхаться. Мы это проходили. Вот ключевые параметры, которые правим в /etc/zabbix/zabbix_server.conf:

# Количество SNMP poller процессов (по умолчанию 1!)
StartSNMPTrapper=1
StartPollers=10

# Bulk-запросы — запрашивать несколько OID за один пакет
# Настраивается на уровне элемента данных: Use bulk requests = Yes

# Таймаут SNMP (по умолчанию 3 сек — много для LAN)
Timeout=5

Чтобы Zabbix принимал trap-ы, нужно поднять snmptrapd и настроить запись в файл — Zabbix будет читать его и разбирать события:

# /etc/snmp/snmptrapd.conf
authCommunity log public
format2 %V\n%v\n
outputOption s

# Перенаправление в файл для Zabbix
[snmptrapd] logoption f /var/log/snmptrap/snmptrap.log

В конфиге Zabbix Server пропишите: SNMPTrapperFile=/var/log/snmptrap/snmptrap.log

Типичные проблемы и отладка SNMP

За годы внедрений мы видели одни и те же грабли снова и снова. Вот проблемы, на которые уходит больше всего времени при настройке SNMP-мониторинга:

  • Timeout: No Response — встречается чаще всего. Проверяйте последовательно: правильность community/credentials, ACL на самом устройстве, firewall между NMS и агентом, и вообще — запущен ли SNMP-сервис
  • Counter32 wrap-around — 32-битные счётчики на быстрых интерфейсах переполняются и дают бред на графиках. Переходите на ifHCInOctets (Counter64) вместо ifInOctets
  • Index mismatch после перезагрузки — ifIndex запросто меняется после рестарта. Привязывайтесь к ifName или ifAlias, а не к числовому индексу
  • Высокая нагрузка на CPU устройства — polling каждые 10 секунд убивает слабые железки. Для некритичных метрик ставьте интервал 60–300 секунд, и проблема уходит

Отладка с помощью tcpdump и snmpwalk

Когда SNMP ведёт себя непредсказуемо, первое что делаем — смотрим реальный трафик на интерфейсе:

# Захват SNMP-пакетов на сервере мониторинга
tcpdump -i eth0 -nn udp port 161 -vv -X

# Verbose-режим snmpwalk — показывает raw PDU
snmpwalk -v2c -c public -d 192.168.1.1 sysDescr

# Проверка доступности конкретного OID
snmpget -v2c -c public -r 3 -t 5 192.168.1.1 .1.3.6.1.2.1.1.1.0
# -r 3 — три повтора
# -t 5 — таймаут 5 секунд

# Массовая проверка всех коммутаторов из файла
while read IP; do
  RESULT=$(snmpget -v2c -c public -r 1 -t 2 $IP sysName.0 2>&1)
  if echo "$RESULT" | grep -q 'Timeout'; then
    echo "FAIL: $IP"
  else
    echo "OK: $IP — $RESULT"
  fi
done < switches.txt

Безопасность SNMP в корпоративной сети

SNMP — протокол с серьёзным потенциалом для злоупотреблений. Через SET можно менять конфигурацию устройства, через GET — получить полную карту топологии сети. Если вы думаете, что это теория — нет, это практика. Что точно делаем для защиты:

  1. Используйте SNMPv3 authPriv — минимум SHA + AES128. MD5 и DES сегодня не защищают — только создают иллюзию безопасности
  2. Ограничьте ACL на устройствах — SNMP-запросы должны приниматься только с IP-адресов NMS, и никак иначе
  3. Отключите SNMP write — если SET-операции не нужны, оставьте только read-only. Зачем держать открытую дверь?
  4. Изолируйте management VLAN — SNMP-трафик не должен ходить через пользовательские сети. Это базовая гигиена
  5. Мониторьте authenticationFailure trap — если кто-то перебирает community string, вы об этом узнаете сразу, а не постфактум
# Cisco IOS — ACL для SNMP
ip access-list standard SNMP_ACL
 permit 10.0.1.50
 permit 10.0.1.51
 deny any log

snmp-server community s3cretRO RO SNMP_ACL
snmp-server community s3cretRW RW SNMP_ACL

# Включить trap при неудачной аутентификации
snmp-server enable traps snmp authentication

В идеале весь SNMP-трафик должен ходить через выделенный management-интерфейс устройства, полностью отдельный от data-plane. Для маршрутизаторов с выходом в интернет — это не рекомендация, это обязательное требование.

Часто задаваемые вопросы

Простая аналогия: trap — это SMS без подтверждения доставки. Отправил и забыл — дошло или нет, агент не знает. Inform работает иначе: агент ждёт подтверждения от NMS и при потере пакета повторяет отправку. Inform есть в SNMPv2c и v3. На практике мы используем inform для критичных событий — link down, отказ питания — а trap оставляем для информационных вещей, где потеря одного уведомления некритична.

Универсального ответа нет — всё зависит от метрики. Трафик и загрузку интерфейсов опрашиваем каждые 60 секунд, иначе графики получаются рваными. Состояние портов — каждые 30–60 секунд, но обязательно дополняем trap-ами: polling обнаружит падение порта через минуту, а trap — мгновенно. Температуру и CPU — раз в 2–5 минут, этого достаточно. Инвентаризацию (sysDescr, версии прошивок) — раз в час или реже. На бюджетных коммутаторах с хилым CPU слишком частый polling легко создаёт проблемы — проверено на практике.

Да, SNMP через VPN работает — мы так мониторим удалённые площадки клиентов. Но есть нюансы. UDP-пакеты при нестабильном VPN теряются, и NMS начинает генерировать ложные Timeout-алерты. Лечится увеличением retries и таймаута. Для trap-ов через VPN обязательно используйте inform — он повторит отправку при потере. И ещё один момент, про который часто забывают: SNMP-ответы с большими таблицами могут не влезать в MTU туннеля и фрагментироваться — это тоже источник загадочных проблем.

Чаще всего проблема в том, что MIB-файлы просто не подключены. Ставите пакет snmp-mibs-downloader, запускаете download-mibs — и половина вопросов отпадает сама. Дальше открываете /etc/snmp/snmp.conf и комментируете строку mibs : — именно с двоеточием, не перепутайте. С вендорскими MIB чуть сложнее: скачиваете файлы с сайта производителя и кладёте их в /usr/share/snmp/mibs/. Потом проверяете командой snmptranslate -IR ifInOctets — если всё сделано правильно, она вернёт числовой OID. Не вернула — смотрите пути и права на файлы.

Нужна помощь с настройкой?

Если не хочется разбираться со всем этим самостоятельно — команда АйТи Фреш настроит мониторинг под вашу инфраструктуру. Больше 15 лет опыта, обслуживание от 15 000 ₽/мес.

📞 Связаться с нами
#SNMP мониторинг#snmpwalk#SNMP trap#SNMPv3 настройка#мониторинг коммутаторов#OID сетевого оборудования#snmptrapd#MIB файлы
Комментарии 0

Оставить комментарий

загрузка...

Подпишитесь на рассылку ITfresh

Каждую неделю мы выпускаем практические гайды для руководителей IT и системных администраторов. Это не просто теория! Здесь вы найдёте всё: безопасность, 1С, миграции, резервные копии и проверенные лайфхаки из наших реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.