Настройка SNMP — достаточно интересная тема, так как протокол SNMP является мощным инструментом в руках системного администратора и критически необходимым в большой сети. Сетевым устройством будет выступать маршрутизатор CISCO.
Немного теории
Общие понятия
Своими словами, чтобы было понятнее — SNMP состоит из 3 частей:
- Агента, настроенного на сетевом устройстве;
- Программы-диспетчера, настроенной на компьютере (компьютер тут Network Management Station, NMS);
- Кроме этого на устройстве есть База Управляющей Информации (MIB), где собственно и хранятся нужные данные.
База заполняется автоматически сетевым устройством. Нужно только выбирать оттуда необходимые данные.
Взаимодействие между диспетчером и агентом происходит 2 разными способами:
- При наступлении определённых заранее событий на устройстве, агент самостоятельно отсылает данные о событии диспетчеру — ловушка SNMP;
- Диспетчер собирает статистику по заранее заданным параметрам, опрашивая с определённым интервалом агента — запрос 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.
Практика
Тут надо поделиться своими наработками. SNMP не такой уж безобидный протокол, как может показаться. Он очень процессорозависимый. Несколько разных программных сборщиков SNMP могут положить CPU любого сетевого устройства. Наблюдал пики под 100% загрузки на коммутаторах вплоть до 9500 серии:
May 8 2024 06:44:57.068 MSK: %SYS-1-CPUFALLINGTHRESHOLD: Threshold: Total CPU Utilization(Total/Intr) 45%/1%.
Заходим на устройство и видим:
#show proc cpu monitor
CPU utilization for five seconds: 59%/2%; one minute: 19%; five minutes: 12%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
588 110149119 360159181 305 51.42% 12.93% 6.75% 0 SNMP ENGINE
..
Может быть и больше. Устройство страдает, поэтому рекомендации:
- Ограничьте количество сборщиков SNMP. Сервера Zabbix (максимум двух) будет вполне достаточно;
- Собирайте только действительно необходимые параметры. Не надо собирать всё подряд, эти данные не будут использоваться.
Тестовая среда
Настраиваться будет маршрутизатор 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
Помимо группы для ловушек были автоматически созданы дополнительные виды.
Здесь чётко видно, что работа агента с запросами и работа агента с ловушками — 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
СПАСИБО!
Рад что пригодилось