SNMP. Протокол мониторинга и управления сетевыми устройствами

Что это: Протокол мониторинга и управления сетевыми устройствами через MIB/OID.
Зачем нужен: Чтобы система мониторинга могла опрашивать коммутатор и получать состояние портов, железа, загрузки и событий.
Что делает: Отдает метрики по запросу менеджера мониторинга и может отправлять уведомления о событиях через traps/informs.

Версии SNMP

Версия	Особенности
SNMPv1	Старый вариант, минимум безопасности.
SNMPv2c	Часто встречается, community string вместо нормальной аутентификации.
SNMPv3	Рекомендуемый вариант: пользователи, аутентификация, шифрование, контроль доступа.

Что можно снимать с коммутатора?

Группа метрик	Примеры
Интерфейсы	Admin/oper status, скорость, MTU, alias/description.
Трафик портов	In/Out octets, packets, unicast, multicast, broadcast.
Ошибки портов	Errors, discards, drops, unknown protocols.
L2/Bridge	MAC-таблица, bridge-порты, STP-состояния, topology changes.
Система	Uptime, hostname, contact, location.
Ресурсы	CPU, память, иногда storage.
Железо	Температура, вентиляторы, блоки питания, модули, transceiver/DDM.
PoE	Потребление, бюджет, состояние PoE-портов.
События	Link up/down, hardware alarms, STP changes, authentication failures.

Ключевые принципы

MIB описывает структуру данных.
OID указывает конкретную метрику.
Polling — мониторинг сам опрашивает устройство.
Trap — устройство само отправляет событие.
Counter нужно считать по разнице значений за интервал.
64-bit counters важны для быстрых портов, иначе счетчики быстро переполняются.

Когда использовать?

Централизованный мониторинг портов.
Контроль загрузки uplink.
Поиск ошибок на интерфейсах.
Контроль температуры, питания, вентиляторов.
Инвентаризация портов и описаний.
Алерты по link down/up и hardware fault.

Лучшие практики

Использовать SNMPv3.
Ограничивать доступ ACL только с серверов мониторинга.
Делать read-only доступ для мониторинга.
Не использовать одинаковые community на всей сети.
Для высокоскоростных портов использовать 64-битные счетчики.
Не опрашивать устройство слишком часто без необходимости.
Traps не заменяют polling, а дополняют его.

Типовые ошибки

Использование SNMPv2c с простой community.
Открытый SNMP со всей сети.
Мониторинг берет 32-битные счетчики на 1G/10G+ портах.
Нет описаний портов, из-за чего метрики непонятны.
Слишком частый опрос создает лишнюю нагрузку.
Ожидание, что все vendor-specific метрики будут одинаковыми на разных моделях.