Trap address что это
Ловим snmp трапы mac-notification с устройств Cisco
Несмотря на кажущуюся простоту вопроса, пришлось достаточно долго и нудно собирать информацию по крупицам. В данной публикации я хочу поделиться накопленным опытом.
Итак, mac notification — snmp уведомление, которое будет передавать серверу информацию о mac-адресе устройства на порту коммутатора при включении или отключении этого устройства. Весьма удобная штука, расширяющая возможности мониторинга сети через snmp.
Приступим к настройке
Настройка коммутатора не займет много времени:
Проверить правильность настройки можно в режиме дебага:
Если все настроено верно, то мы увидим что-то вроде этого:
Настройка сервера состоит из нескольких этапов:
#
# SNMPTT v1.4 Configuration File
#
# Linux / Unix
#
# Set to either ‘standalone’ or ‘daemon’
# standalone: snmptt called from snmptrapd.conf
# daemon: snmptrapd.conf calls snmptthandler
# Ignored by Windows. See documentation
mode = standalone
# Set to 1 to allow multiple trap definitions to be executed for the same trap.
# Set to 0 to have it stop after the first match.
# This option should normally be set to 1. See the section ‘SNMPTT.CONF Configuration
# file Notes’ in the SNMPTT documentation for more information.
# Note: Wildcard matches are only matched if there are NO exact matches. This takes
# into consideration the NODES list. Therefore, if there is a matching trap, but
# the NODES list prevents it from being considered a match, the wildcard entry will
# only be used if there are no other exact matches.
multiple_event = 1
# Set to 0 to enable the use of FQDN (Fully Qualified Domain Names). If a host name is
# passed to SNMPTT that contains a domain name, it will not be altered in any way by
# SNMPTT. This also affects resolve_value_ip_addresses.
# Set to 1 to have SNMPTT strip the domain name from the host name passed to it. For
# example, server01.domain.com would be changed to server01
# Set to 2 to have SNMPTT strip the domain name from the host name passed to it
# based on the list of domains in strip_domain_list
strip_domain = 0
# List of domain names that should be stripped when strip_domain is set to 2.
# List can contain one or more domains. For example, if the FQDN of a host is
# server01.city.domain.com and the list contains domain.com, the ‘host’ will be
# set as server01.city.
strip_domain_list = /opt/script.php
Данная статья — всего лишь конкретный пример широкого применения snmp трапов. На Cisco ftp можно найти еще больше интересных функций.
Надеюсь, моя публикация помогла вам сэкономить время.
Протокол управления SNMP
Simple Network Management Protocol (SNMP) — это протокол прикладного уровня, он делает возможным обмен данными между сетевыми устройствами.
SNMP — это не продукт, а свод правил. Он определен Советом по архитектуре Интернета и является частью пакета TCP/IP. SNMP управляется и поддерживается Инженерной группой Интернета (IETF).
Протокол позволяет системному администратору проводить мониторинг, контролировать производительность сети и изменять конфигурацию подключенных устройств. SNMP используют в сетях любого размера: чем крупнее сеть, тем лучше раскрываются преимущества протокола. Он позволяет просматривать, контролировать и управлять узлами через единый интерфейс с функциями пакетных команд и автоматического оповещения.
Таким образом, SNMP избавляет администратора от необходимости ввода команд вручную. Всего были разработаны и развернуты три версии. Все они используются до сих пор, а самой распространенной стала вторая — SNMPv2с.
Архитектура SNMP
Компоненты, составляющие архитектуру SNMP:
Сетевая станция управления — NMS
Network Management Station (NMS) удаленно мониторит управляемые устройства, получает данные, собранные мастер-агентами, отслеживает производительность и представляет полученную информацию в графическом виде. Встроенный менеджер NMS отвечает за связь с агентами.
Агенты
Мастер-агент
Это программа, связывающая сетевых менеджеров и субагентов. Мастер-агент анализирует запросы сетевого менеджера NMS и пересылает их субагентам, собирает и формирует ответы субагентов и отправляет их менеджеру. Мастер-агент уведомляет менеджера, если запрос некорректен или запрошенная информация недоступна.
Субагент
Это программа, поставляемая вендором вместе с сетевым устройством. Субагент пересылает собранную информацию мастер-агенту. У каждого управляемого компонента есть соответствующий субагент.
Управляемый компонент
Это подключенное к сети устройство или программное обеспечение с встроенным субагентом. К таким устройствам относятся не только маршрутизаторы, коммутаторы и серверы, но и IP-видеокамеры, МФУ и IP-телефоны. К софту с субагентами также относятся антивирусные программы, системы резервного копирования, ПО для систем ИБП.
База управляющей информации — MIB
MIB — это иерархическая база данных со сведениями об устройстве. У каждого типа устройства своя MIB-таблица: у принтера в ней содержится информация о состоянии картриджей, а у коммутатора — данные о трафике. Благодаря MIB менеджер знает, какую информацию он может запросить у агента устройства.
Идентификатор объекта — OID
Каждый объект в MIB имеет свой уникальный ID — OID, который представлен в числовом формате и имеет иерархическую структуру. OID — это числовой эквивалент пути к файлу. Он присваивает значения каждой таблице в MIB, каждому столбцу в таблице и каждому значению в столбце.
Например, OID 1.3.6.1.4.868.2.4.1.1.1.3.3562.3. означает iso.org.dod.internet.private.transition.products.chassis.card.slotCps.
cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.3562.3.
Используя первые 6 цифр этого OID, можно пройти по дереву на схеме.
Часть значений в OID содержит данные о производителе устройства, что позволяет быстро получить определенную информацию о девайсе.
Древовидная иерархия MIB и OID в SNMP выглядит несколько запутанной, но у нее есть свои преимущества. Это простая и гибкая система организации сетевых устройств, она работает вне зависимости от размера сети.
Теория и логика работы протокола SNMP
Предназначение
Изначально протокол должен был предоставить системным администраторам инструмент для управления интернетом. Однако, гибкая архитектура SNMP позволила проводить мониторинг всех сетевых устройств и управлять ими с одной консоли. Это и стало причиной распространения SNMP.
Менеджеры и агенты обмениваются данными через протокол UDP. Вместо него также может использоваться TCP, IPX или протокол MAC-уровня. Обмен данными основан на Protocol Data Unit (PDU).
Всего в SNMP семь PDU:
TRAP, GETBULK — есть только во второй и третьей версиях протокола SNMP.
Схема PDU
| IP заголовок | TCP/IP | TCP/IP |
| UDP заголовок | TCP/IP | TCP/IP |
| Версия SNMP | v1/v2/v3 | PDU |
| Строка сообщества | Public, Private | PDU |
| Тип PDU | Get, GetNext, Response, Set, Trap, GetBulk, Inform | PDU |
| ID запроса | Идентификатор запроса | PDU |
| Статус ошибки | 0, 1, 2, 3, 4, 5 | PDU |
| Индекс ошибки | 0, 1 | PDU |
| Связанные переменные | Одна или несколько переменных в запросе | PDU |
Применение
Статусы ошибок и их описание.
Сетевые порты SNMP
По умолчанию SNMP использует UDP-порты 161 и 162. Менеджер отправляет запросы на порт 161 агента. С порта 161 агент отправляет ответ менеджеру. При отправке запроса менеджер добавляет к нему ID, а агент вставляет этот ID в ответ, чтобы менеджер мог связать свой запрос с ответом агента.
Ловушки агент высылает на порт 162 менеджера. Если используется DLTS или TLS, то агент высылает сообщения на порт 10162, а менеджер — на порт 10161. Администратор может изменить порты SNMP, используемые по умолчанию, на любые другие.
Ловушки
Ловушка (Trap) — это важнейший способ коммуникации в SNMP. Менеджер отвечает за большое количество устройств, на многих из них может быть несколько управляемых компонентов. Агент отправляет ловушку по своей инициативе, когда необходимо сообщить менеджеру о событии. Например, ловушка может выслать отчет о перегреве машины или о том, что в тонере закончились чернила.
Получив уведомление, менеджер выбирает нужное действие, например, опрашивает агента, чтобы получить полное представление о том, что произошло. Перечень уведомлений, которые посылает ловушка:
В SNMP есть два типа ловушек: Trap и Inform. Отличия между ними в том, что после получения Inform менеджер подтверждает получение ловушки. В противном случае агент будет отправлять Inform, пока не получит подтверждения. А вот после получения Trap менеджер не отправляет подтверждение. Если сообщение не дошло до менеджера, агент об этом не узнает.
Версии протокола SNMP
SNMPv1
Первая версия протокола создана в 80-х годах XX века. Легка в настройке — требуется только строка community. Версия широко используется до сих пор.
SNMPv2с
Вторая версия протокола SNMP появилась в 1993 году. Разработчики добавили в нее новый запрос GetBulk и ловушку Inform, а также усовершенствовали безопасность.
У этой версии есть два способа коммуницировать с устройствами, поддерживающими SNMPv1: двуязычная система сетевого управления и прокси-агенты. Прокси-агенты выполняют роль мастер-агентов, а в двуязычной системе управления менеджер определяет, какую версию SNMP поддерживает агент, и связывается с ним через SNMPv1 или SNMPv2c.
SNMPv3
Третья версия вышла в 1998 году. Разработчики добавили в SNMP криптографическую защиту, облегчили удаленную настройку и администрирование объектов. Этого удалось достичь за счет определения набора стандартизованных объектов управления, называемых объектами MIB удаленного сетевого мониторинга, — RMON MIB.
Безопасность
Изначально безопасность не была первоочередной задачей разработчиков. Первая версия SNMP была создана для удаленного администрирования во времена, когда угроза несанкционированного доступа была минимальной. Поэтому SNMPv1 слабо защищена от взлома, и злоумышленники могли использовать ее для проникновения в сетевую инфраструктуру.
В работе над второй версией протокола разработчики предложили несколько вариантов решения. Распространение получил вариант SNMPv2c — не самый надежный, но простой в использовании.
Основная проблема с безопасностью в том, что почти все оборудование поддерживает версию SNMPv1. И только часть работает с версиями SNMPv2с и SNMPv3. Именно поэтому самой популярной стала SNMPv2с. Она способна работать с устройствами, которые поддерживают первую или вторую версии SNMP.
Модели безопасности протоколов SNMP по версиям
| SNMPv1 | Community–based security |
| SNMPv2c | Community–based security |
| SNMPv2u | User–based security |
| SNMPv2 | Party–based security |
| SNMPv3 | User–based security |
Community-based Security — модель безопасности на основе строки сообщества. Фактически это идентификатор пользователя или пароль, который отправляется вместе с запросом. Если строка сообщества неверна, агент игнорирует запрос.
Строка сообщества зависит от вендора устройства. Часто вендоры по умолчанию выбирают «PUBLIC» в качестве пароля, поэтому первым делом на новых устройствах нужно изменить строку сообщества для защиты сети от злоумышленников.
Строки сообщества бывают трех видов:
Строка сообщества широко используется из-за своей простоты и наличия внешних систем безопасности.
Party-based Security Model — модель на основе так называемых «сторон». Для коммуникации между менеджером и агентов выбирается логическая сущность, называемая стороной. Она устанавливает протоколы аутентификации и шифрования, а отправитель и получатель соглашаются со способом шифрования и дешифровки данных. Сложность использования модели помешала ее распространению среди пользователей.
User-based Security Model — модель безопасности на основе пользователей. Уровни аутентификации, безопасности и конфиденциальности протоколов и ключей настраиваются у агента и менеджера.
Лучше всего безопасность проработана в третьей версии SNMP за счет USM и VACM. Упрощенно VACM (View-based Access Control Model) можно описать как модель с разными уровнями доступа для групп менеджеров. При получении запроса агент решает, разрешен ли определенной группе менеджеров доступ к чтению, записи и получению уведомлений.
Типичные проблемы безопасности
Если системный администратор не использует SNMP, то он должен отключить его на устройствах.
Практическое применение протокола
С помощью SNMP администратор управляет приложениям и облачными сервисами, администрирует локальную сеть и контролирует состояние сервера с одной консоли.
Возможности SNMP-протокола
Благодаря протоколу администратор может:
При помощи стороннего ПО можно также:
SNMP и переход с IPv4 на IPv6
Протокол по умолчанию должен работать с IPv4 или IPv6. На практике IPv6 создает определенные проблемы для работы SNMP. Эти проблемы связаны объектами MIB, содержащими сетевые адреса. OID в MIB хранят информацию для нескольких уровней TCP/IP, и различия между IPv4 и IPv6 будут отражены в OID.
Отсутствие поддержки IPv6 в существующих объектах MIB проявляется двумя способами:
Эти проблемы решаются также двумя способами:
Инсталляция
Настройка SNMP в Windows
Она подробно описана в документации Microsoft.
Настройка данных агента SNMP
Пуск → Панель управления → Администрирование → Управление компьютером.
Настройка сообщества и ловушек SNMP
Пуск → Панель управления → Администрирование → Управление компьютером.
Настройка безопасности SNMP
Пуск → Панель управления → Администрирование → Управление компьютером.
Настройка SNMP в Linux
Настройка SNMP в CentOS 7
Сначала нужно установить последние обновления при помощи yum/dnf:
затем установить SNMP:
и создать копию конфигурационного файла:
теперь нужно отредактировать настройки агента
Локацию и email лучше указать реальные.
Пора добавить сервис в автозагрузку и перезапустить его:
Как проверить, что сервис запущен:
Опрос агента с помощью утилиты snmpwalk:
Опрос сервера локально командой:
Настройка SNMP в Debian 10
Сначала нужно установить демона, клиента и файлы:
После установки переходим к настройке SNMP в Debian.
Файлом настройки SNMP-агента по умолчанию является /etc/snmp/snmpd.conf. Агент SNMP может быть запущен с настройками по умолчанию. Однако для включения удаленного мониторинга нужно сделать несколько изменений. Для этого создайте резервную копию файла:
Теперь нужно изменить директиву agentAdress. Ее текущие настройки разрешают доступ только с локального компьютера. Для включения удаленного мониторинга необходимо определить IP-адрес интерфейса:
Для настройки аутентификации:
rocommunity предоставляет доступ только на чтение, а rwcommunity дает доступ к чтению/записи. В Access Control section нужно поместить строку
rocommunity S3CUrE 192.168.43.100
Кроме того, можно включить запрос с локального хоста rocommunity S3CUrE localhost:
Затем нужно перезапустить SNMP:
Чтобы добавить сервис в автозагрузку, введите:
SNMP — это простой и эффективный способ для сбора и обмена информацией между сетевыми устройствами, которые выпущены разными вендорами и работают на разном ПО. Этот протокол — не идеальное, но все еще одно из лучших решений для мониторинга и управления. На сегодняшний день нет другого инструмента с сопоставимым уровнем поддержки и использования.
Созданный 30 лет назад SNMP продолжает работать, потому что он обладает характеристиками, которых нет ни у одной из его аналогов. Он простой в использовании, бесплатный и поддерживается практически всеми вендорами.
Разное
Для успешного администрирования сети необходимо знать состояние каждого ее элемента с возможностью изменять параметры его функционирования. Обычно сеть состоит из устройств различных производителей и управлять ею было бы нелегкой задачей если бы каждое из сетевых устройств понимало только свою систему команд. Поэтому возникла необходимость в создании единого языка управления сетевыми ресурсами, который бы понимали все устройства, и который, в силу этого, использовался бы всеми пакетами управления сетью для взаимодействия с конкретными устройствами.
Для того, чтобы проконтролировать работу некоторого устройства сети, необходимо просто получить доступ к его MIB, которая постоянно обновляется самим устройством, и проанализировать значения некоторых переменных.
Важной особенностью протокола SNMP является то, что в нем не содержатся конкретные команды управления устройством. Вместо определения всего возможного спектра таких команд, безусловно загромоздившего бы сам протокол, который считается все-таки простым, определены переменные MIB, переключение которых воспринимается устройством как указание выполнить некоторую команду. Таким образом удается сохранить простоту протокола, но вместе с этим сделать его довольно мощным средством, дающим возможность стандартным образом задавать наборы команд управления сетевыми устройствами. Задача обеспечения выполнения команд состоит, таким образом, в регистрации специальных переменных MIB и реакции устройства на их изменения.
Как происходит адресация в MIB к некоторой ее переменной? По своей структуре MIB представляет из себя дерево, изображенное на рисунке 1.
Каждому элементу соответствует численный и символьный идентификатор. В имя переменной включается полный путь до нее от корневого элемента root. Например, время работы устройства с момента перезагрузки хранится в переменной, находящейся в разделе system под номером 3 и называется sysUpTime. Соответственно, имя переменной будет включать весь путь: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime(3); или на языке чисел: 1.3.6.1.2.1.1.3. Следует заметить, что при этом узлы дерева разделяются точками. Существует стандартная ветвь MIB, относящаяся к разделу управления mgmt, которую обычно поддерживают все сетевые устройства.
Наряду с этим каждый производитель или организация может разработать свой собственный набор переменных и «подвесить» их к дереву MIB. Однако, это делается только в строго определенном ее месте. Если организация разрабатывает свою базу MIB, то на стадии экспериментов переменные могут помещаться в раздел experimental. Однако для официальной регистрации структуры данных некоторой организации ей необходимо получить собственный номер в разделе private-enterprises. Все переменные, адресуемые вниз по ветви данной организации, относятся к продуктам только данного производителя.
Как уже было сказано, каждое сетевое устройство содержит в себе информацию, необходимую для управления им. Эта информация некоторым образом размещена в регистрах устройства. Как же обеспечивается доступ к этой информации некоторой сетевой рабочей станции, выполняющей задачу управления сетью? Для обработки запросов управляющей станции, приходящих в виде SNMP пакетов, служит специальный модуль, называемый Агентом Управления. Агент принимает SNMP пакеты и выполняет соответствующие им действия, т.е. посылает значение запрашиваемой переменной, устанавливает значение переменных, выполняет периодическое обновление информации MIB, выполняет в ответ на установку соответствующих переменных некоторые операции. В роли Управляющей Станции может выступать рабочая станция администратора сети, если на ней запустить какой-либо пакет управления, поддерживающий протокол SNMP. Он позволяет администратору получать конкретную информацию о какой либо стороне функционирования элементов сети, например на уровне карты Ethernet, либо протокола EGP. Примерами таких программ можно назвать Sun NetManager фирмы Sun Microsystems, ориентированный на операционную систему Solaris, и пакет SNMPc фирмы Castle Rock Computing, разработанный для системы Windows. Оба пакета позволяют строить карту сети и работать непосредственно с MIB какого-либо ее узла. Имея подобное мощное средство, администратору сети достаточно открыть документацию по MIB конкретного устройства, например маршрутизатора cisco, и изучить возможности управления, заложенные в нее разработчиками. Так, например, чтобы управлять маршрутизатором cisco, можно войти на него (сделать login пользователем root) и получить on-line доступ к его командам управления. А можно сконфигурировать на данном маршрутизаторе SNMP агента и выполнять все те же команды и получать те же результаты путем работы с переменными его MIB. Как пример такой операции можно просто перегрузить маршрутизатор путем изменения одной переменной его MIB. При этом существуют отдельные команды для загрузки системы из flash-памяти, NVRAM, или TFTP файла.
При помощи SNMP можно выполнять различные тесты функциональных возможностей сетевых устройств, определенные опять же на самих устройствах. Это бывает полезно, поскольку просто наблюдение статистики зачастую не дает полной картины происходящего. Так, например, для раздела, относящегося к интерфейсам Ethernet, определен тест TDR (Time-domain reflectometry), позволяющий определять приблизительное расстояние до повреждения в коаксиальном кабеле. Для того, чтобы запустить TDR тест необходимо установить значение переменной ifExtnsTestTypе (1.3.6.1.2.1.12.2.1.4), содержащей тип выполняемого теста, так, чтобы она содержала идентификатор теста TDR в MIB: 1.3.6.1.2.1.10.7.6.1. Результатом теста будет, во-первых, значение переменной ifExtnsTestResult (1.3.6.1.2.1.12.2.1.5), характеризующей исход теста:
На основании вышеизложенного остается сделать вывод о том, что администратор сети может найти в лице протокола SNMP хорошего помощника, имея полный доступ к описаниям переменных MIB различных сетевых устройств и мощный пакет, который бы облегчал работу с громоздкими именами переменных в SNMP.
Почему SNMP это не очень просто?
Читаем документацию
The strategy implicit in the SNMP is that the monitoring of network state at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the monitoring center(s). A limited number of unsolicited messages (traps) guide the timing and focus of the polling. Limiting the number of unsolicited messages is consistent with the goal of simplicity and
minimizing the amount of traffic generated by the network management function.
Для тех, у кого сложности с английским языком, имеется русский перевод:
Стратегия SNMP заключается в том, что мониторинг состояния сети с любым значимым уровнем детализации выполняется главным образом путем опроса из центра мониторинга. Ограниченное число незапрашиваемых сообщений (trap — прерывание) обеспечивает синхронизацию и активизирует опросы. Ограничение числа незапрашиваемых сообщений согласуется с задачами обеспечения простоты и минимизации трафика, создаваемого системой сетевого управления.
Из этих цитат, вполне понятно, что запросы с типами TRAP и INFORM это не наиболее часто используемая часть SNMP. Статью для начинающих было бы более уместно иллюстрировать примерами использования гораздо более ходовых GET-запросов.
Вообще я настоятельно рекомендую ознакомиться со всеми RFC, связанными с SNMP перед началом работы. Некоторые аспекты SNMP не очевидны и имеет смысл получить о них представление из первоисточника. Начать ознакомление с материалом можно с wiki.
Первые шаги
Помимо обязательного ознакомления с документацией, важно понимать, для чего мы все это делаем. В практике телекома, наиболее часто встречаются следующие задачи:
Задача SNMP-мониторинга выделяется на общем фоне требованием того, что опрашиваемого оборудования много или очень много. Предположим, что именно эту задачу нам и предстоит решать.
Начнем писать код. В тестовом примере мы обратимся по SNMP к собственному хосту и прочитаем значение переменной, заданной OID-ом 1.3.6.1.2.1.1.3.0 и содержащей значение uptime-а хоста:
Предварительно убедившись, что служба SNMP на нашем хосте работает и запустив код на выполнение, получим искомое значение uptime-а (времени безостановочной работы хоста с момента последней загрузки):
Используя это значение, можно осуществлять мониторинг. Если мы обнаруживаем, что значением уменьшилось — значит хост успел перезагрузиться с момента очередного опроса. Если хост не ответил в течение заданного таймаута (после нескольких автоматически сделанных попыток) это, скорее всего, означает, что хост не работает. Все просто?
Подсчитали — прослезились
Не совсем. Вспоминаем о том, что нам предстоит выполнять много запросов. Давайте промеряем, сколько запросов мы можем выполнить в секунду? Внесем небольшое исправление в код:
И запустим его на выполнение:
Почти две с половиной тысячи запросов в секунду! Неплохо?
Не будем торопиться. Мы отправляем запросы на Loopback интерфейс, а он работает несколько быстрее локальной сети. Посмотрим, сколько запросов в секунду мы успеем выполнить к другому хосту в нашей сети:
Не дотягиваем даже до двухсот. Вообще говоря, возможно, этого будет достаточно. Все зависит от задачи. Но мы проводили измерения при условии, что опрашиваемый хост доступен. Что будет если хост не ответит?
Будет несколько попыток доступа (в нашем коде мы задали 3) разделенных таймаутом (1000 мсек). Это означает, что за секунду мы не успеем выполнить ни одного запроса. Поскольку не отвечающий хост является не такой уж большой редкостью, это может стать большой проблемой в реальном проекте.
Идем на рекорд
Что с этим можно сделать? Если бы мы имели дело с каким либо синхронным протоколом (например telnet), особого выбора бы у нас не было. Для того, чтобы увеличить производительность, нам пришлось бы одновременно выполнять много потоков. Но SNMP асинхронен по своей природе! Не надо насильственно втискивать его в синхронные рамки.
Как перейти к асинхронному варианту? В нашем случае, довольно просто:
Запросы все равно что проваливаются в бездонную бочку! Разумеется, ответы будут приходить с задержкой, но приходить они будут тоже довольно быстро. Но как мы узнаем, что хост не ответил?
Очень просто, по истечении заданного количества попыток и таймаутов, SNMP4J вернет нам event, response в котором будет равен null:
Проанализируем результат выполнения:
Мы успеваем сформировать 9174 запросов в секунду, а опрашиваемое устройство успевает обрабатывать запросы со скоростью 283 запроса в секунду. На большую часть запросов оно ответить не успевает (соответственно в логе остаются сообщения «Timeout exceeded»). Разумеется, это не будет проблемой когда мы начнем опрашивать большое количество устройств с разумным интервалом между запросами.
Идем далее
Мы научились получать по SNMP значения скалярных переменных. Но, помимо них, в SNMP есть еще и таблицы (например таблица интерфейсов на устройстве). Как они устроены? Посмотрим MIB-browser:
В OID mgmt.interfaces (1.3.6.1.2.1.2) мы видим скалярную переменную ifNumber (1.3.6.1.2.1.2.1), содержащую количество интерфейсов в таблице, а также набор столбцов. Каждый из столбцов имеет собственный OID. Например столбец содержащий числовой индекс ifIndex интерфейса имеет OID = 1.3.6.1.2.1.2.2.1.1.
Для того, чтобы получить значение этой переменной, необходимо добавить к OID-у индекс интерфейса (например для интерфейса с индексом 123 OID = 1.3.6.1.2.1.2.2.1.1.123). Но как нам получить индексы интерфейсов? Они совсем не обязательно идут по порядку! Например, на моей машине, таблица интерфейсов выглядит так:
Именно для этой цели был придуман запрос GETNEXT. Передавая в этот запрос префикс OID-а, мы получаем OID и значение следующей (в лексикографическом порядке) за этим префиксом переменной. Это означает, что передав префиксы OID-ов столбцов таблицы, мы получим OID-ы и значения первой ее строки. Чтобы получить следующую строку, надо выполнить еще один запрос, передав в него OID-ы, полученные предыдущим запросом. И так до тех пор, пока мы не просмотрим всю таблицу.
Разумеется, с учетом всего сказанного выше, нам следует минимизировать количество запросов (это также необходимо с учетом того, что в рамках одного запроса, согласно RFC, предоставляются консистентные данные, если мы запросим индекс и имя интерфейса двумя последовательными запросами, они возможно не будут соответствовать друг-другу). В рамках 1-ой версии SNMP, мы должны читать всю строку таблицы одним запросом.
Следует заметить, что довольно удобно то, что OID-ы скалярных переменных также представляют собой префиксы. Например, для переменной sysUpTime OID, на самом деле равен 1.3.6.1.2.1.1.3. Мы можем передать его в GETNEXT запрос и получить OID = 1.3.6.1.2.1.1.3.0 вместе с соответствующим значением. Это дает возможность запрашивать скалярные значения вместе с значениями столбцов таблиц, в одном запросе.
Запустив этот код на выполнение, мы получим следующий response:
Мы получили значение uptime-а, индекс первого интерфейса и его имя, закодированное строкой октетов в шестнадцатеричном представлении. Чтобы получить следующие строки, мы должны выполнять последовательные запросы, передавая ранее полученные OID-ы.
С учетом необходимости поддержки возможности асинхронной обработки, это может стать нетривиальной (но вполне решаемой) задачей. К счастью, во 2-ой версии SNMP были добавлены bulk-запросы, автоматизирующие получение табличных данных и минимизирующие количество отсылаемых при этом запросов. Внесем необходимые изменения в код:
Выполнив этот запрос, мы получаем все строки таблицы одним запросом:
Разумеется, если таблица содержит более затребованных 50-ти строк, вновь (как и для 1-ой версии SNMP) потребуется формировать запросы для получения последующих строк, передавая в них OID-ыполученные для последней строки.
О чем я не рассказал?
В этой статье я не рассказал о многом. Я не рассказал о том, как изменять значения некоторых (не всех) переменных SET-запросами. Я не рассказал о том, что такое TRAP-ы и для чего они нужны. Я ни сказал ни слова о том, как разрабатывать SNMP-агенты. И я ни одним словом не обмолвился о 3-ей версии SNMP и привнесенных ей изменениях.
Но даже того о чем я сказал вполне достаточно, чтобы понять, что SNMP — это не просто.