snmp что это простыми словами

Протокол управления SNMP

Для регулирования устройств в IP-сетях нередко применяется SNMP. Эта аббревиатура расшифровывается как Simple Network Management Protocol. По сути, это стандартизированный интернет-протокол, который помогает отследить используемые сетевые устройства: маршрутизаторы, адаптеры, коммутаторы и т. д. Основное условие, чтобы оборудование было включено через IP и использовали определенное программное обеспечение.

Разберемся, как работает протокол SNMP, из каких компонентов он состоит и какие версии используются.

Подробнее о протоколе

SNMP является протоколом прикладного уровня, который необходим для обмена информацией между несколькими сетевыми машинами. Это не просто приложение, а свод используемых правил, который является частью модели TCP/IP. Протокол контролируется и управляется IETF.

При помощи протокола сисадмин может выполнять мониторинг сети, чтобы оценить ее производительность и изменить конфигурацию устройств. Поэтому SNMP стал довольно распространен и его применяют в сетях любого типа и объема. Причем чем больше сеть, тем лучше удается использовать функционал приложения. Он позволяет не только просматривать, но и управлять сетью через единый интерфейс.

Основное преимущество протокола – наличие интерфейса с автоматическими оповещениями и другими командами. Это избавляет от необходимости ручного ввода всех команд.

Архитектура

Разобравшись в вопросе, что такое SNMP, можно перейти к рассмотрению его архитектуры. Она состоит из следующих компонентов:

1. Сетевая станция управления.

Подробнее поговорим о каждом элементе. Начать стоит с сетевой станции управления, или Network Management Station. Именно NMS позволяет отслеживать используемые устройства, анализировать сведения, собранные мастер-агентами, определять производительность системы и создавать графические отчеты на основе полученных данных. Встроенный менеджер используется для прямой связи с агентами протокола.

2. Агенты.

Эта группа компонентов включает в себя ряд подгрупп. Начнем с мастер-агентов, которые служат для связи сетевых менеджеров и субагентов. Они анализируют поступающие запросы и отсылают их субагентам, затем получают информацию, создают ответ и отсылают его менеджеру.

Если запрос некорректен, неверно сформулирован или информация закрыта для доступа, то мастер-агент отправляет уведомление об этом.

Другой вид агента – это субагент. Он представляет собой специальное программное обеспечение, которое поставляется вендором вместе с сетевой машиной. Субагент получает запросы от мастер-агента и потом обратно пересылает ему собранную информацию. Соответствующий субагент используется вместе с отдельным управляемым компонентом.

3. Управляемые компоненты.

Представляют собой подключенные к сети компьютеры и устройства или специальное ПО, имеющее встроенный субагент. К числу устройств могут относиться коммутаторы, маршрутизаторы и серверы, а также современные гаджеты. Что касается ПО с субагентами, то к нему относят антивирусные программы, серверы резервного копирования и т. д.

Также в качестве компонентов протокола SNMP стоит выделить MIB и OID. Первый термин обозначает базу управляющей информации, в ней содержатся сведения об оборудовании. Каждая сетевая машина имеет свою таблицу с MIB-данными, в ней – данные о состоянии картриджа (у принтеров), о поступающем трафике (у коммутатора) и т. д.

OID представляет собой идентификатор объекта. MIB снабжается своим уникальным ID, который и позволяет идентифицировать устройство. OID существует в числовом виде, по сути – это числовой аналог существующего пути к файлу.

Принципы работы

Теперь подробнее поговорим о назначении и принципе действия протокола SNMP. Изначально протокол разрабатывался как инструмент для управления глобальной сетью. Однако благодаря гибкой структуре удалось приспособить SNMP для всех устройств сети и осуществлять контроль, наблюдение и настройки при помощи единой консоли. Все это послужило распространению протокола и его активному применению.

Работа SNMP строится на обмене информацией между менеджерами и агентами. Этот процесс осуществляется посредством протокола UDP. Реже используется TCP или протокол MAC-уровня.

В SNMP используется семь различных вариантов PDU, которые отвечают за получение данных с устройства, изменение или присваивание новых сведений, уведомления об ошибках, извлечение данных и т. д.

PDU состоит из конечного набора полей, в которых прописывается нужная информация. В частности, это поля:

Функционирование SNMP подразумевает использование специальных сетевых портов. По умолчанию – это UDP-порты 161 и 162. Запросы поступают на порт SNMP 161. Далее с него отправляется ответ менеджеру. При отправке запроса он идентифицируется при помощи ID, что в дальнейшем позволяет связать запрос менеджера с поступившим ответом.

Порт 162 отвечает за прием ловушек агента. При использовании DLTS и TLS агент использует для пересылки сообщений порт 10162, а менеджер – 10161.

Мы подошли еще к одному важному элементу, который необходим для функционирования SNMP. Речь о ловушках, которые представляют собой способ коммуникации. Агент использует ловушки (Trap) в тех случаях, когда нужно сообщить менеджеру о каком-либо событии. Делается это по той причине, что менеджеры нередко отвечают за определенное количество устройств и несколько управляемых компонентов, поэтому не всегда могут вовремя отследить возникновение ошибки.

При получении ловушки, то есть уведомления, менеджер может выбрать нужное действие. Уведомления, которые присылает ловушка, обозначаются цифрами от 0 до 6. Код ошибки указывает на группу, к которой относится неполадка.

В SNMP используется два вида ловушек – помимо Trap, это еще и Inform. Разница в том, что второй тип ловушек предполагает подтверждение менеджера о ее получении.

Особенности применения

SNMP позволяет сисадмину работать с различными приложениями и облачными сервисами. Протокол имеет функционал для выполнения следующих операций:

Существующие версии

Разработано три версии протокола, которые получили соответствующие названия – SNMPv1, SNMPv2c и SNMPv3. Все они активно используются даже сегодня, однако самой распространенной остается вторая версия. Расскажем о каждой разновидности подробнее:

Вопросы безопасности

Протокол SNMP создавался в те времена, когда угроза взлома и несанкционированного доступа к данным была практически нулевой. Поэтому разработчики не уделяли этой проблеме особого внимания. Версия SNMPv1 практические не имеет защиты от взлома, чем могут воспользоваться злоумышленники.

Вторая версия разрабатывалась с учетом анализа предыдущих недочетов и ошибок протокола. Эта версия SNMP стала более безопасной, однако на деле ее сложно назвать самой стабильной и надежной.

Практически все ошибки безопасности удалось решить только в третьей версии. Для обеспечения безопасности в протоколе применяется несколько моделей: Community-based, Party-based и User-based Security.

Выводы

Сегодня протокол SNMP является наиболее простым и эффективным методом сбора и передачи данными между сетевыми устройствами, мониторинга и управления их работой. Особенно актуальным применение такого протокола является при совмещении устройств, функционирующих на разном ПО и выпущенных разными вендорами. SNMP прост в работе, достаточно надежный, а самое главное – полностью бесплатный для использования. Этим не может похвастать практически ни один существующий набор правил.

Остались вопросы по работе SNMP? Специалисты Xelent обязательно ответят на них – оставьте заявку на сайте или свяжитесь с нами по указанным телефонам.

Источник

Для чего предназначен SNMP: руководство по NMS, MIB, OID, ловушкам и агентам

SNMP (Simple Network Management Protocol) представляет собой коммуникационный протокол, который позволяет отслеживать управляемые сетевые устройства, включая маршрутизаторы, коммутаторы, серверы, принтеры и другие устройства, которые включены через IP через единую систему управления / программное обеспечение.

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

Менеджер (NMS)

Компонент Manager — это просто часть программного обеспечения, которое установлено на компьютере (которое при объединении называется Network Management System), которое проверяет устройства в вашей сети, как часто вы указываете информацию.

Менеджер имеет правильные учетные данные для доступа к информации, хранящейся агентами (что объясняется в следующем разделе), а затем компилирует их в читаемом формате для сетевого инженера или администратора для мониторинга или диагностики проблем или узких мест. Некоторые программные пакеты NMS более сложны, чем другие, что позволяет настраивать сообщения электронной почты или SMS, чтобы предупредить вас о неисправных устройствах в вашей сети, в то время как другие просто опросили устройства для получения более общей информации.

Агенты

SNMP Agent — это часть программного обеспечения, которое поставляется вместе с сетевым устройством (маршрутизатором, коммутатором, сервером, Wi-Fi и т. Д.), Которое при включении и настройке выполняет всю тяжелую работу для Менеджера путем компиляции и хранения всех данных из своего данное устройство в базу данных (MIB).

Эта база данных правильно структурирована, чтобы программное обеспечение менеджера могло легко опросить информацию и даже отправить информацию Менеджеру, если произошла ошибка.

Какие номера портов используют SNMP?

Управляемые сетевые устройства

Управляемые сетевые устройства, в том числе маршрутизаторы, коммутаторы, Wi-Fi, серверы (Windows и другие), настольные ПК, ноутбуки, принтеры, UPS и т. Д., Имеют встроенное в них программное обеспечение агента, которое должно быть либо включено, либо настроено, либо просто настроено правильно для того, чтобы быть опрошены NMS.

MIB-файлы представляют собой набор вопросов, которые SNMP-менеджер может задать агенту. Агент собирает эти данные локально и сохраняет их, как определено в MIB. Таким образом, диспетчер SNMP должен знать эти стандартные и частные вопросы для каждого типа агента.

MIB содержат набор значений, как статистических, так и контрольных, которые определяются сетевым устройством. Во многих случаях расширения стандартных значений определяются с помощью Private MIB разными поставщиками сетевых устройств.

Чтобы упростить MIB, подумайте об этом так: MIB-файлы — это набор Вопросов, которые Менеджер может спросить у агента. Агент просто собирает эти вопросы и сохраняет их локально и обслуживает их по NMS по запросу.

Упрощенный пример работы MIB: NMS спросит у сетевого устройства вопрос, в данном случае, что такое ответ на вопрос 2?

Агент управляемых сетевых устройств затем отвечает с ответом на вопрос 2. Чтобы еще больше разбить это, давайте построим еще один пример.

Скажем, мы хотим знать системное время работы устройства.

Распределение номера OID

OID, Object Identifier — это просто номер, составленный MIB, объектом интереса и экземпляром. Каждый идентификатор является уникальным для устройства, и при запросе будет предоставлена ​​информация о том, что было запрошено OID.

Существует два типа OID:

Скаляр — это экземпляр одного объекта — например, имя поставщика устройства. Может быть только одно имя поставщика, так что это будет скалярный OID.

С другой стороны, Tabular может иметь несколько результатов для своего OID — например, процессор Quad Core приведет к 4 различным значениям ЦП.

Ловушки

Ловушки используются, когда устройству необходимо предупредить программное обеспечение сетевого управления о событии без опроса. Ловушки гарантируют, что NMS получает информацию, если определенное событие происходит на устройстве, которое должно быть записано без предварительного опроса NMS.

Управляемые сетевые устройства будут иметь MIB Trap с заранее определенными условиями, встроенными в них. Крайне важно, чтобы система управления сетью объединяла эти MIB, чтобы получать любые ловушки, отправленные данным устройством.

MIB — это номер, который идентифицирует определенные характеристики или значения устройства, но если в системе управления сетью нет определенной MIB, которую отправляет ловушка сетевого устройства, нет способа интерпретировать, что такое MIB, и не будет записывать событие.

Версии (v1, v2c, v3)

Этот протокол прошел несколько пересмотров на протяжении многих лет, начиная с 1988 года, начиная с версии 1. Теперь мы до версии 3, но большинство систем управления сетью поддерживают все версии протокола.

Версия 1

Версия 1 была первой версией протокола, определенного в RFC 1155 и 1157. Эта версия является самой простой из 3-х версий протокола и является самой небезопасной из-за ее простой текстовой аутентификации.

Версия 2 (или 2c)

Версия 2 протокола была введена в 1993 году с большими улучшениями по сравнению с первой версией, включая транспортные сопоставления, элементы структуры MIB и, что самое важное, улучшенные обновления для проверки подлинности и безопасности.

Тем не менее, версии 1 и 2 / 2c имели встроенные риски безопасности, как упоминалось выше, — строки сообщества, которые эквивалентны паролям, где передается по проводу в виде прозрачного / обычного текста, позволяя любому, кто нюхает сеть, получить доступ к строке и могут компрометировать сетевые устройства и, возможно, перенастроить их с помощью SNMP.

Версия 3

Версия 3 протокола, дебютировавшая в 1998 году, сделала большие шаги для обеспечения безопасности набора протоколов, реализовав так называемую «пользовательскую безопасность». Эта функция безопасности позволяет вам устанавливать аутентификацию на основе требований пользователя. 3 уровня аутентификации:

Версия 3 протокола является наиболее безопасной из группы, но с добавленной безопасностью и шифрованием добавлена ​​конфигурация и сложность настройки и конфигурации. Но при работе с сетевыми устройствами более высокого уровня, которые содержат конфиденциальную информацию, вознаграждение перевешивает головную боль при правильной настройке.

Источник

Основы работы с SNMP

Сбор информации о сервере и инфраструктуре – очень важная часть работы системного администратора. Существует множество инструментов для сбора и обработки таких данных, и многие из них основаны на технологии SNMP.

SNMP (simple network management protocol, простой протокол сетевого управления) – это стандартный протокол для управления устройствами в IP-сетях. С его помощью серверы могут обмениваться информацией о своем текущем состоянии, а администратор может изменять предварительно определенные значения. Сам протокол очень простой, однако структура основанных на нём программ может оказаться сложной.

Данная статья ознакомит вас с основами протокола SNMP: базовыми понятиями, методами работы, случаями его применения, различными версиями протокола и т.д.

Базовые понятия

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

Существует много различных версий протокола SNMP. Кроме того, протокол частично реализуется некоторыми сетевыми аппаратными устройствами. Наиболее распространённой является версия SNMPv1, но она имеет много уязвимостей; на самом деле, основными причинами её популярности являются её вездесущность и долгое время существования. Вместо неё рекомендуется использовать более безопасную версию SNMPv3.

Сеть на основе SNMP в основном состоит из SNMP-агентов. Агент – это программа, которая собирает информацию об аппаратном устройстве, систематизирует её в предварительно определенные записи, а также отвечает на запросы с помощью протокола SNMP.

Компонент, который запрашивает данные у агентов, называется менеджером SNMP. SNMP-менеджеры получают данные о всех управляемых устройствах и могут выдавать запросы для сбора информации и устанавливать некоторые свойства.

Менеджеры SNMP

Менеджер SNMP – это машина, которая запрашивает информацию, собранную агентами SNMP. Такая машина гораздо проще устроена, чем клиенты, поскольку она просто запрашивает данные.

Менеджером может быть любая машина, которая может отправлять запросы агентам SNMP, предоставляя валидные учётные данные (например, сервер мониторинга); иногда задачи менеджера выполняет сам администратор с помощью простых утилит для быстрого запроса данных.

Почти все команды SNMP предназначены для менеджера. Например:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest
Response

Кроме того, менеджер может отвечать на Trap и Response.

Агенты SNMP

Агенты SNMP выполняют основную работу. Они отвечают за сбор данных о локальной системе, их хранение в удобном для запросов формате, обновление БД management information base (или просто MIB).

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

Агент определяет, какие менеджеры могут получить доступ к данным. Также агент может выступать в качестве посредника и передавать информацию на устройства, не настроенные для SNMP-трафика.

Агенты SNMP отвечают на большинство команд протокола, среди которых:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest

Также он может отправлять сообщения Trap.

Кратко о MIB

Management Information Base, или MIB – пожалуй, самый сложный компонент системы SNMP. Это иерархическая глобально стандартизированная база данных, которая следует стандартам агентов и менеджеров системы.

Проще всего структуру MIB можно представить в виде перевёрнутого дерева. Каждая ветвь получает порядковый номер (начиная с 1) и уникальную для этого уровня иерархии строку.

Чтобы сослаться на определённый узел, нужно отследить к нему путь в базе. Идентификаторы узла (номера и строки) можно использовать как адрес. Каждый узел в иерархии обозначается точкой. Таким образом, адрес содержит ряд идентификационных строк или чисел, разделенных точками. Такой адрес называется идентификатором объекта (или OID).

MIB предоставляет стандартные ветки, которые может использовать любое устройство. Однако при внедрении SNMP в свое устройство вы можете создавать пользовательские ветки.

Все стандартные ветки принадлежат одной родительской структуре. Эта ветка определяет информацию для спецификации MIB-2 (это пересмотренный стандарт для совместимых устройств).

Базовый путь к этой ветке:

Примечание: По этой ссылке вы найдёте очень удобный ресурс для ознакомления с деревом MIB. Аналогичный инструмент представлен Cisco и называется SNMP Object Navigator. Также похожее дерево можно найти здесь.

Запрашивая информацию устройств, вы заметите, что большинство адресов начинается с 1.3.6.1.2.1.

Команды протокола SNMP

Отчасти протокол SNMP популярен благодаря простым командам. Он выполняет всего несколько операций, но они достаточно гибки.

Следующие блоки данных протокола описывают точные типы сообщений, которые поддерживает протокол:

Версии протокола

С момента выхода протокол SNMP прошел через множество изменений. Первая реализация SNMP, сейчас известная как SNMPv1, появилась в 1988 году и состояла из RFC 1065, RFC 1066 и RFC 1067. Эта версия до сих пор широко поддерживается, однако она имеет множество проблем с безопасностью (например, аутентификация в виде обычного текста), поэтому её использование крайне нежелательно, особенно это касается незащищенных сетей.

Работа над версией 2 данного протокола началась в 1993 году. Эта версия предлагает ряд существенных улучшений представленных ранее стандартов. В этой версии была представлена модель безопасности на основе сторон, которая устраняет уязвимости, связанные с предварительным пересмотром. Тем не менее, новую модель безопасности оказалось достаточно сложно реализовать, потому популярной она не стала.

Поэтому появились дополнительные релизы версии 2, каждый из которых сохранил основную часть усовершенствований версии 2, но изменил модель безопасности. Версия SNMPv2c возобновила модель безопасности на основе сообществ (которая была использована в v1); это была самая популярная версия протокола v2. Другая реализация, SNMPv2u, основана на пользовательской модели безопасности, также не стала популярной.

В 1998 вышла третья версия SNMP (текущая). Она предлагает пользовательскую систему безопасности, которая позволяет устанавливать требования к аутентификации с помощью одной из этих моделей:

Кроме новых моделей аутентификации был реализован механизм контроля доступа, который управляет доступом пользователей к веткам. Версия 3 также может использовать протоколы безопасности SSH или TLS.

Источник

Почему 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 — это не просто.

Источник