Настройка SNMP — достаточно интересная тема, так как протокол SNMP является мощным инструментом в руках системного администратора и критически необходимым в большой сети. Сетевым устройством будет выступать маршрутизатор CISCO.

Немного теории

Общие понятия

Своими словами, чтобы было понятнее - SNMP состоит из 3 частей:

1. Агента, настроенного на сетевом устройстве;
2. Программы-диспетчера, настроенной на компьютере (компьютер тут Network Management Station, NMS);
3. Кроме этого на устройстве есть База Управляющей Информации (MIB), где собственно и хранятся нужные данные.

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

Взаимодействие между диспетчером и агентом происходит 2 разными способами:

1. При наступлении определённых заранее событий на устройстве, агент самостоятельно отсылает данные о событии диспетчеру - ловушка SNMP;
2. Диспетчер собирает статистику по заранее заданным параметрам, опрашивая с определённым интервалом агента - запрос SNMP GetRequest.

Это если на устройстве для диспетчера выдано право только на чтение (RO) базы MIB, если же выдано право на запись (RW), то есть дополнительная возможность:

• Диспетчер изменяет заранее заданные параметры в MIB, посылая запрос агенту - запрос SNMP SetRequest

Понятие триггера - если значение параметра, который мониторится со стороны диспетчера, изменяется, то диспетчер выполняет заранее определённое действие (например, посылает сообщение на электронную почту).

Понятие строки сообщества - это пароль, который проверяется при попытке подключения к устройству по SNMP (для версии SNMP 1 и 2). То есть тут нет связки логин/пароль - есть строка сообщества, которая сразу и логин, и пароль.

Последнее, что тут нужно сказать, важный момент: агент и диспетчер используют разные порты. Агент принимает запросы на 161/UDP порту, отправляет информацию диспетчеру на 162/UDP порт.

Версии SNMP

Существует 3 версии SNMP:

• Версия 1 - основной стандарт;
• Версия 2c - доработанная в плане производительности версия 1, не включает в себя безопасность версии 2 и неофициально известна как SNMPv1.5. Доработка заключается в том, что параметры из MIB можно выбирать не по 1, а группой. Есть улучшенная поддержка ошибок, расширен список кодов ошибок;

Operation	Description
get-request	Retrieves a value from a specific variable.
get-next-request	Retrieves a value from a variable within a table.
get-bulk-request	Retrieves large blocks of data, such as multiple rows in a table, that would otherwise require the transmission of many small blocks of data.
get-response	Replies to a get request, get next request, and set request sent by an NMS.
set-request	Stores a value in a specific variable.
trap	Sends an unsolicited message from an SNMP agent to an SNMP manager when some event has occurred.

• Версия 3 - доработана только безопасность по отношению к 2c, а именно шифрование и аутентификация.

В плане реализации работы между версиями разница небольшая, но поскольку только версия 3 безопасна, то именно она является актуальной, а версии 1 и 2c хотя всё ещё боевые, но считаются устаревшими. Хотя на практике из-за простоты настройки повсеместно используется SNMP v2c.

База MIB

Структура базы непривычна для понимания, здесь просто нужно запомнить и со временем ничего непривычного не будет. Это структура перевёрнутого дерева, где ствол - 1 (иногда пишут .1), а ветви обозначаются цифрами начиная тоже с 1 и далее. Уровней вложенности может быть много, в ветке новые ветки и так далее. Большинство веток заканчиваются параметрами. Параметры внутри ветки также нумеруются с 1. Путь к параметру состоит из цифр начиная с со ствола и проходит через ведущие к параметру ветки. Цифры разделяются точками. Такой путь называется OID (Object ID). Важно отметить, что это стандарт - нумерация чётко прописана в данном стандарте и одинакова для всех производителей оборудования, но конкретный производитель может добавлять свои уникальные ветви, которые присутствуют только в его оборудовании.

Диспетчер SNMP (программа) имеет стандартную базу MIB, чтобы программа узнала о специфичных ветках и параметрах конкретного производителя, нужно подгрузить MIB этого производителя.

Почитать о MIB CISCO. OIDs полезных параметров придётся искать в интернете/документации.

Пример. Путь к стандартной ветке system, где хранятся такие, например, параметры как описание системы (sysDescr) и время прошедшее с запуска системы (sysUpTime) - 1.3.6.1.2.1.1. Путь к параметру sysDescr - 1.3.6.1.2.1.1.1, добавилась ещё 1, так как это первый параметр ветки. Путь к sysUpTime - 1.3.6.1.2.1.1.3 - третий параметр.

Проприетарные ветки производителей всегда располагаются по строго заданному пути iso.org.dod.internet.private.enterprises или в цифровом выражении 1.3.6.1.4.1.

Пример. Для CISCO путь будет 1.3.6.1.4.1.9, а для D-Link 1.3.6.1.4.1.171

Для загрузки MIB CISCO нужно использовать
CISCO IOS MIB Locator.

Подробнее о SNMP можно прочитать в 4 части курса CCNA.

Тестовая среда

Настраиваться будет маршрутизатор CISCO c3725, запущенный из под GNS3 и данные будут поступать в виртуальную машину (VM) Hyper-V. Агент SNMP уже является частью внутренней прошивки (IOS) маршрутизатора, а вот в качестве диспетчера будет использоваться бесплатное ПО - PowerSNMP Free Manager. CISCO рекомендует Free SNMP MIB Browser, не пробовал, не знаю. Соединяются маршрутизатор и VM посредством Облака GNS3. Для этого указываем в свойствах Облака внутренний виртуальный коммутатор, к которому подсоединена сетевая карта VM:

• IP F0/0 маршрутизатора - 192.168.137.2/24
• IP компьютера - 192.168.137.40/24
• IP vEthernet (HUB1) - 192.168.137.1/24

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

SNMPv1/SNMPv2c

Версии настраиваются одинаково, так как версия не указывается при создании SNMP агента (строки сообщества), а лишь при создании ловушек. При создании строки сообщества задаётся лишь или право на чтение (RO), или право на запись (RW).

Пример. В маршрутизаторе настроен пока только интерфейс F0/0, ведущий к облаку (и VM). Введём команду создания агента (строки сообщества):

R1(config)# snmp-server community TEST ro SNMP_ACL

Затем команду:

show snmp group

Создалось 2 группы на чтение - TEST v1 и TEST v2c. Удалим сообщество и группы:

R1(config)# no snmp-server community TEST ro SNMP_ACL
R1(config)# no snmp-server group TEST v1
R1(config)# no snmp-server group TEST v2

Теперь создадим сообщество с правом на запись:

R1(config)# snmp-server community TEST rw SNMP_ACL

Снова введём команду:

show snmp group

Опять создалось 2 группы - v1 и 2c, только уже с правом и на чтение, и на запись:

На диспетчере SNMP для работы можно будет выбрать или 1, или 2 версию агента.

Настройка маршрутизатора

Полная настройка версий 1 и 2:

R1(config)# ip access-list standard SNMP_ACL
R1(config-std-nacl)#permit host 192.168.137.40
R1(config-std-nacl)#exit
R1(config)# snmp-server community TEST ro SNMP_ACL
R1(config)# snmp-server host 192.168.137.40 version 1 TEST - или version 2c TEST
R1(config)# snmp-server enable traps snmp

• Команда 1 - создание списка доступа (SNMP_ACL).
• Команда 2 - разрешает взаимодействие было только с указанным компьютером (192.168.137.40).
• Команда 3 - возврат из режима конфигурирования списка доступа (config-std-nacl)# в режим глобальной конфигурации (config)#.
• Команда 4 - создаём Агент SNMP (строку сообщества TEST) только для чтения (ro) - диспетчер сможет считывать значения параметров, но не сможет записывать новые значения и наконец, привязываем список доступа.
• Команда 5 - указываем куда отсылать данные при срабатывании ловушки (192.168.137.40) и версия 1, для версии 2 будет - 2c вместо 1, имя сообщества (TEST).
• Команда 6 - включаем ловушки и определяем какие именно ловушки нас интересуют (snmp).

В параметр snmp входят следующие ловушки:

authentication linkdown linkup coldstart warmstart

Просмотреть полный перечень возможных ловушек можно командой:

R1(config)# snmp-server enable traps ?

Их там огромное количество:

Настройка VM

Запускаем программу:

Нажатие кнопки Find покажет отсутствие доступных агентов в сети и срабатывание ловушки authentication:

Происходит так потому, что по умолчанию в программе стоит сообщество public, наш агент был опрошен, но отказал в доступе. Меняем public на TEST, агент опять не добавляется - широковещательный запрос. В свойствах ставим IP 192.168.137.2 и сообщество TEST, после чего агент успешно добавляется.

Ещё раз, строка сообщества (community) - это просто пароль, только называется по-другому.

Теперь погасим интерфейс F0/0 и снова включим:

R1(config)# interface f0/0
R1(config-if)# shutdown
R1(config-if)# no shutdown

С небольшой задержкой, ведь связанный интерфейс выключался, прилетают сообщения ловушек, смотрим:

OID отвечающий за состояние F0/0: 1.3.6.1.4.1.9.2.2.1.1.20.1 - первый полезный параметр. Следует обратить на то, что параметр находится в проприетарной ветке оборудования CISCO.

Теперь пробуем добавить этот параметр для мониторинга:

Параметр успешно добавился. Выставляем интервал опроса параметра и триггер: если значение параметра не равно up, то отправить сообщение на e-mail:

Задаём параметры e-mail и гасим F0/0. По истечению таймера состояние параметра изменилось на Timeout error, письмо не пришло - программа не оправляет сообщения по таймауту. Выставил опрос на минимум - 1 секунда, включил/выключил F0/0 ещё раз и вот долгожданное письмо:

A Variable Watch has exceeded its configured limit:
Agent: 192.168.137.2:161
Variable: 1.3.6.1.4.1.9.2.2.1.1.20.1
The Agent's response contained a value of administratively down, which is Not Equal to (!=) the configured limit of up.

SNMPv3

Подробно настройка описана в курсе CCNA R&S 6.0 BRIDGING COURSE. Тут будет посложнее, но и поинтереснее - мозги гарантированно заскрипят 🙂

Настройка маршрутизатора

Удаляем всё что относится к предыдущей настройке кроме списка доступа. Далее, разбил настройку на 2 части, потом будет понятно почему.

Общие шаги

• Шаг 1. Настройте ACL-список (уже сделано);
• Шаг 2. Настройте представление SNMP;
• Шаг 3. Настройте группу SNMP;
• Шаг 4. Настройте пользователя как члена группы SNMP.

Часть 1

Router(config)# snmp-server view SNMP-RO system included
Router(config)# snmp-server view SNMP-RO mib-2 included
Router(config)# snmp-server group TEST v3 priv read SNMP-RO access SNMP_ACL
Router(config)# snmp-server user ADMIN TEST v3 auth sha cisco123 priv aes 128 snmp321
Router(config)# snmp-server enable traps snmp

Агент SNMPv3 настраивается по-другому нежели SNMPv1/SNMPv2:

Вместо строки сообщества создаётся пользователь с паролем (cisco123) и шифрованием (aes 128, ключ шифрования snmp321)  - следует запомнить, что первым указывается пароль пользователя (auth sha cisco123) и вторым ключ шифрования (aes 128 snmp321). Это важно.

Предварительно для пользователя создаётся группа, а ещё ранее вид. Вид определяет с какой частью дерева MIB предстоит работать.

Ещё раз по командам:

• Команда 1 - создание вида (SNMP-RO) для работы с веткой MIB (system).
• Команда 2 - создание вида (SNMP-RO) для работы с веткой MIB (mib-2), mib-2 входит в system - эта команда только для примера, что можно добавлять несколько веток.
• Команда 3 - создание группы (TEST) версии 3 (v3) с аутентификацией и шифрованием (priv) только для чтения (read) для вида (SNMP-RO) и списком доступа (SNMP_ACL).
• Команда 4 - создание пользователя (ADMIN) в группе (TEST) версии 3 (v3) аутентификацией по алгоритму (sha), паролем (cisco123) и шифрованием (priv) по алгоритму (aes 128) и ключом шифрования (snmp321).
• Команда 5 - включаем ловушки и определение типов ловушек (snmp).

Тут надо вспомнить 3 уровня безопасности SNMPv3:

• auth - group using the authNoPriv Security Level (MD5/SHA-1 аутентификация, без шифрования данных);
• noauth - group using the noAuthNoPriv Security Level (без аутентификации и шифрования);
• priv - group using SNMPv3 authPriv security level (MD5/SHA-1 аутентификация, шифрование данных DES/3DES/AES)

Для использования authPriv требуется прошивка с поддержкой криптографии (k9).

Router(config)# snmp-server enable traps snmp
Router(config)# snmp-server host 192.168.137.40 version 3 auth ADMIN

Теперь проверим что получилось:

show shmp group

show snmp user

show running-config | include snmp

По соображениям безопасности пользователи SNMP не показываются в конфигурации.

Часть 2

Подробная настройка получателя ловушек SNMPv3:

R1(config)# snmp-server host 192.168.137.40 version 3 noauth ?
 WORD SNMPv1/v2c community string or SNMPv3 user name

R1(config)# snmp-server host 192.168.137.40 version 3 noauth ADMIN - для начала без пароля и шифрования

• Команда 6 - указываем хост куда отсылать данные при срабатывании ловушки (192.168.137.40) версии 3, без шифрования и аутентификации (noauth) для пользователя (ADMIN).

Проверяем, пользователь как был так и остался, а вот в группах SNMP и в конфигурации интересные изменения:

Появилась новая группа TEST, хотя команды на её создание не было.

И вот такая занятная строка в конфиге:

snmp-server group TEST v3 noauth notify *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.FFFFFFFF0F

Понять что это такое можно выполнив команду:

R1(config)# do show snmp view
*ilmi system - included permanent active
*ilmi atmForumUni - included permanent active
SNMP-RO mib-2 - included nonvolatile active
SNMP-RO system - included nonvolatile active
v1default iso - included permanent active
v1default internet.6.3.15 - excluded permanent active
v1default internet.6.3.16 - excluded permanent active
v1default internet.6.3.18 - excluded permanent active
v1default ciscoMgmt.394 - excluded permanent active
v1default ciscoMgmt.395 - excluded permanent active
v1default ciscoMgmt.399 - excluded permanent active
v1default ciscoMgmt.400 - excluded permanent active
*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.FFFFFFFF0F iso.2.840.10036 - included volatile active
*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.FFFFFFFF0F internet - included volatile active

Помимо группы для ловушек были автоматически созданы дополнительные виды: //blog.ine.com/2008/07/19/snmpv3-tutorial/

Здесь чётко видно, что работа агента с запросами и работа агента с ловушками - 2 абсолютно разных процесса.

Настройка VM

Для начала погасим и включим интерфейс S0/0 (один из дополнительных интерфейсов, интерфейсы по умолчанию на маршрутизаторе выключены), прилетают сообщения ловушек, диспетчер определяет ловушки как версию 2+:

Как видно из рисунка у пользователя ADMIN для ловушек нет шифрования и пароля.

Дальше добавляем агента с указанием версии и атрибутов:

И пробуем добавить параметр 1.3.6.1.4.1.9.2.2.1.1.20.2 - состояние интерфейса S0/0 для мониторинга.

No matching defenition in loaded MIBs

И то же самое для F0/0 - 1.3.6.1.4.1.9.2.2.1.1.20.1. В чем дело? А дело в том, что параметр находится в ветке private, а эту ветку мы не добавляли в вид для работы, добавим:

R1(config)# snmp-server view SNMP-RO private included

Состояние интерфейса отображается корректно. С агентом версии 3 всё.

Настройка ловушек v3 с паролем и шифрованием

Удаляем получателя ловушек:

R1(config)# no snmp-server host 192.168.137.40 version 3 noauth ADMIN
R1(config)# no snmp-server group TEST v3 noauth 
R1(config)# no snmp-server view *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.FFFFFFFF7F iso.2.840.10036
R1(config)# no snmp-server view *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.FFFFFFFF7F internet

Проверяем пользователя, группы, виды, конфигурацию, если что-то удалилось - восстанавливаем (на самом деле удалиться ничего не должно, но когда настраивал, то первые раза 3 каждый раз получалось по-разному). Теперь:

R1(config)# snmp-server host 192.168.137.40 version 3 priv ADMIN

И заново всё проверяем. Автоматически создались виды, пользователь на месте с теми же параметрами, нет новой группы TEST, так как параметры аутентификации и шифрования совпадают с созданной ранее, исходной группой TEST. В конфигурации параметр для автоматически созданных видов дописался к строке группы:

Если теперь погасить/поднять интерфейс, то ловушки не приходят диспетчеру.

Пробуем добавить пользователя для ловушек версии 3, в программе есть такая возможность. Для этого нужно ввести помимо прочего Engine ID. Его можно найти просмотрев пользователя SNMP либо выполнив команду:

R1# show snmp engineID
Local SNMP engineID: 800000090300C20125D00000

Программа ожидает ввода Engine ID в виде 80-00-00-09-03-00-C2-01-25-D0-00-00, автоматического преобразования нет. Вносим реквизиты пользователя, снова гасим/поднимаем интерфейс S0/0, ловушки приходят:

Открываем сообщение ловушки и видим, что пароль и шифрование задействованы:

Индексы интерфейсов

NMS записывает пропускную способность и другую статистику по интерфейсам устройства опрашивая SNMP агента. При этом для каждого интрефейса используется номер индекса. Уникальный номер индекса присваивается динамически при каждой загрузке устройства.

R1(config)# do  show snmp mib ifmib ifindex
 Ethernet0/1: Ifindex = 2
 Ethernet0/3: Ifindex = 4
 VoIP-Null0: Ifindex = 5
 Ethernet0/0: Ifindex = 1
 Null0: Ifindex = 6
 Ethernet0/2: Ifindex = 3

Хорошая практика держать индексы интерфейсов постоянными. Для этого нужно выполнить команду:

R1(config)# snmp-server ifindex persist

После выполнения команды индексы сохраняются в NVRAM и не зависят от перезагрузок устройства.

Установка Net-SNMP

А как же быть со средой Linux? Для Centos:

# yum install net-snmp-utils net-snmp

Далее, если выполнить:

$ snmpget -v 2c -c public 127.0.0.1 .1.3.6.1.2.1.2.2.1.2.2

Получим:

IF-MIB::ifDescr = No Such Object available on this agent at this OID

Конфигурацию демона SNMP после установки нужно отредактировать. Если посмотреть файл /etc/snmp/snmpd.conf, то в нём по умолчанию доступны ветви:

view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1

Соответственно запросы не подпадающие под эти ветви будут возвращаться с ошибкой как выше. Комментируем и оставляем:

view systemview included .1

Затем рестартуем сервис:

# service snmpd restart

Затем:

$ snmpget -v 2c -c private 127.0.0.1 .1.3.6.1.2.1.2.2.1.2.2
IF-MIB::ifDescr.2 = STRING: eth0

Самые основные и нужные команды пакета:

• snmpget — SNMP GET запрос;
• snmpwalk — получает часть дерева значений с помощью SNMP GetNext запросов;
• snmpset — SNMP SET запрос.

На этом рассмотрение базовой работы SNMP завершено.

Если тема заинтересовала, то предлагаю выполнить лабу по SNMP.

Справка по командам CISCO IOS SNMP