Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации

Cisco Small Business Switches Model Object Identifiers (OIDs)

Objective

The Simple Network Management Protocol (SNMP) is an Internet-standard protocol used to manage devices on IP networks. The SNMP messages are used to inspect and communicate information about managed objects. SNMP uses Management Information Bases (MIBs) to store available objects in a hierarchical or tree-structured namespace that contains object identifiers (OIDs). An OID identifies the information in the MIB hierarchy that can be read or set via SNMP.

This article provides the list of model object identifiers of all Cisco Small Business Switches.

Applicable Devices

• Sx200 Series
• Sx220 Series
• Sx250 Series
• Sx300 Series
• Sx350 Series
• SG350X Series
• Sx500 Series
• Sx550X Series

Software Version

• 1.1.1.2 — Sx220
• 1.4.7.05 — Sx200, Sx300, Sx500
• 2.2.8.04 — Sx250, Sx350, SG350X, Sx550X

Cisco Small Business Switches Model OIDs

Note: The private Object IDs are placed under: enterprises(1).cisco(9).otherEnterprises(6).ciscosb(1).switch001(101).

Sx200 Series Switches

Любой, кто знаком с сетями, слышал о Протокол SNMP. SNMP — это тип протокола, который позволяет администраторам контролировать состояние оборудования и программного обеспечения. Устройства с поддержкой SNMP можно контролировать удаленно с помощью инструментов мониторинга сети, чтобы отслеживать производительность и доступность. MIBs и OIDs некоторые из секретных ингредиентов этого важного протокола.

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

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

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

Менеджер SNMP — это система, которая отвечает за связь с подключенными устройствами агента SNMP. Здесь находится ваше решение для мониторинга сети. Менеджер SNMP запрашивает агентов, получает ответы от агентов и устанавливает переменные агентов.

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

• ПОЛУЧИТЬ — Отправляется, когда менеджер SNMP пытается получить информацию из MIB, чтобы выяснить значение переменной.
• ОТВЕТ — Агент отправляет RESPONSE менеджеру SNMP при ответе на запрос GET. Это предоставляет менеджеру SNMP переменные, которые были запрошены изначально.
• GetNext — Менеджер SNMP отправляет это сообщение агенту для получения информации от следующего OID в дереве MIB..
• GetBulk — Агент SNMP использует сообщение GETBULK для извлечения таблиц данных, используя множество различных команд GETNEXT.
• УСТАНАВЛИВАТЬ — SET — это сообщение, отправляемое менеджером SNMP агенту для изменения конфигурации и выдачи команд.
• TRAP — Оповещение, отправленное агентом SNMP, чтобы уведомить SNMP Manager, когда событие происходит в устройстве.

Что такое MIB?

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

Ресурсы, хранящиеся в MIB, называются управляемыми объектами или переменными управления. Самый простой способ думать о MIB — это центральный центр данных внутри устройства. MIB содержит все данные о производительности, которые доступны при загрузке инструмента мониторинга сети.

Что такое OID?

Внутри MIB есть много различных управляемых объектов, которые могут быть идентифицированы OID или Идентификатор объекта. OID это адрес, который используется для различения устройств в иерархии MIB. OID используется для ссылки на уникальные характеристики и навигации по переменным на подключенном устройстве. Значение этих идентификаторов варьируется от текста к числам и счетчикам. Существует два основных типа управляемых объектов:

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

Они часто изображаются в виде дерева. OID форматируется в виде строки чисел, как показано ниже:

Каждый из этих номеров предоставляет вам соответствующую информацию. Например:

OID почти всегда начинаются с одинаковой последовательности чисел; 1.3.6.1.4.1. Мы рассмотрим, что означают эти цифры, более подробно ниже:

1 iso — ISO это имя группы, которая запустила стандарт OID .3 org — организация, указанная рядом с этой цифрой .6 dod — Министерство обороны США .1 интернет — определяет, что общение будет происходить через интернет .4 private — указывает, что устройство изготовлено частной компанией .1 предприятие — утверждает, что производитель является предприятием

В большинстве случаев OID будут предоставляться поставщиком, у которого вы приобрели устройство.

SNMP получает запросы и ловушки SNMP

Извлечение данных с устройств с SNMP может быть выполнено одним из двух способов; с SNMP Получить запрос или SNMP Trap. Запрос на получение SNMP — это когда пользователь запрашивает данные о производительности устройства. Как только агент SNMP получает этот запрос, он отправляет обратно OID, которые могут быть прочитаны системой мониторинга SNMP..

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

Без SNMP-ловушек устройства могут передавать данные только при опросе. Ловушки SNMP также используют MIB. Эти MIB имеют свои собственные условия оповещения, которые находятся внутри устройства. Системе мониторинга SNMP необходимо настроить эти MIB, иначе они не смогут получить доступ к прерываниям, отправленным устройством..

Как использовать MIB и OID

Как мы уже говорили выше, каждое сетевое устройство с поддержкой SNMP будет иметь свою собственную таблицу MIB со многими различными OID. В большинстве MIB так много OID, что было бы практически невозможно записать всю информацию. Вместо того, чтобы делать это вручную, вы должны использовать инструмент мониторинга сети, такой как Монитор производительности сети SolarWinds или Paessler PRTG Сетевой монитор.

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

MIB и написание собственных MIB

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

Новый MIB должен иметь свое собственное место в дереве, где он не будет сталкиваться с любым существующим MIB. Лучший способ написать MIB — использовать существующий MIB в качестве шаблона. Изменение имен и определений в MIB дает пользователю прочную основу для продвижения вперед. Если вы решите пойти по этому пути, рекомендуется выполнить его через проверку синтаксиса MIB, чтобы убедиться, что он работает..

Винтики в машине

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

При загрузке инструмента сетевого мониторинга агенты SNMP отправляют данные со всей сети. Информация, которую вы видите на экране, подается из прерываний SNMP и запросов Get. Вы можете просматривать эти данные в форме графиков и диаграмм, но эти данные фактически записываются в MIB и идентифицируются с помощью OID..

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

Management Information Base (MIB, база управляющей информации) — виртуальная база данных, используемая для управления объектами в сети связи. Наиболее часто это понятие связывают с Simple Network Management Protocol (SNMP), но также оно используется в более широком смысле — в контексте модели управления сети OSI/ISO. Хотя термин MIB предназначен для обозначения всей доступной информации об объекте, он также часто используется для обозначения конкретного подмножества, которое правильнее называть MIB-модулем.

Объекты в MIB, согласно RFC 2578, определяются с помощью подмножества «Structure of Management Information Version 2» (SMIv2) стандарта ASN.1. Программное обеспечение, выполняющее разбор, называется MIB-компилятором.

База данных имеет иерархическую (древовидную) структуру. К записям можно обратиться через идентификаторы объектов (англ. object identifier, OID). Базы MIB обсуждаются в документациях RFC, в частности в RFC 1155 и сопутствующих ему RFC 1213 и RFC 1157.

Abstract Syntax Notation One (ASN. 1)Править

В области телекоммуникаций и компьютерных сетей Abstract Syntax Notation One — это язык для описания абстрактного синтаксиса данных, используемый OSI. Стандарт записи, описывающий структуры данных для представления, кодирования, передачи и декодирования данных. Он обеспечивает набор формальных правил для описания структуры объектов, которые не зависят от конкретной машины.

ASN.1 является ISO- и ITU-T-совместимым стандартом, первоначально был определён в 1984 году в рамках CCITT X.409:1984. Из-за широкого применения ASN.1 в 1988 году перешёл в свой собственный стандарт X.208. Начиная с 1995 года, существенно пересмотренный ASN.1 описывается стандартом X.680.

Адаптированное подмножество SMI (Structure of Management Information) указано в SNMP для определения множества связанных объектов MIB; такие множества называются модулями MIB.

В России ASN.1 стандартизирован по ГОСТ Р ИСО/МЭК 8824-1-2001 и ГОСТ Р ИСО/МЭК 8825-93.

Иерархия MIBПравить

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

Управляемый объект (также MIB-объект, объект или просто MIB) является одной из конкретных характеристик управляемого устройства. Управляемые объекты состоят из одного или более экземпляра объекта (определяется их OID-ами), которые по существу являются переменными.

Есть два типа управляемых объектов:

• Скалярные (scalar) объекты определяют один экземпляр объекта.
• Табличные (tabular) объекты определяют несколько связанных экземпляров объектов, сгруппированных в таблицы MIB.

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

Идентификатор объекта (OID) однозначно определяет управляемый объект в иерархии MIB.

SNMPv1 и SMI-специфичные типы данных

Первая версия SMI (SMIv1) определяет использование нескольких специфичных для SMI типов данных, которые разделены на две категории:

• Простые типы данных
• Типы данных Application-wide

Простые типы данных

В SNMPv1 SMI определены три простых типа данных:

• Целочисленный тип данных (integer data type) — целое число со знаком в диапазоне от -2^31 до 2^31-1.
• Строки октетов (Octet strings) — упорядоченные последовательности, содержащие от 0 до 65535 октетов.

Типы данных Application-wide

В SNMPv1 SMI существуют следующие типы данных application-wide:

• Сетевые адреса (Network addresses) представляют собой адреса из определённого семейства протоколов. SMIv1 поддерживает только 32-битные (IPv4) адреса (SMIv2 обычно использует строки октетов для представления адресов. В SMIv1 тип данных — явные IPv4-адреса.)
• Счётчики (Counters) — неотрицательные целые числа, увеличивающиеся до тех пор, пока не достигнут максимального значения, после чего сбрасываются до нуля. SNMPv1 задаёт 32 бита в качестве размера счётчика.
• Отметка времени (Time ticks) представляет прошедшее с какого-то события время, измеряемое в сотых долях секунды.
• Opaques — произвольная кодировка, используемая для передачи произвольных строк информации, которые не удовлетворяют строгой типизации данных в SMI.
• Целочисленные (Integers) — представляют информацию в виде целых чисел со знаком. Этот тип данных переопределяет целочисленный тип данных, который имел произвольную точность в ASN.1, но ограниченную точность в SMI.
• Беззнаковые целочисленные (Unsigned integers) — информация в виде беззнаковых целых чисел, полезная если все значения всегда неотрицательны. Этот тип данных переопределяет целочисленный тип данных, который имел произвольную точность в ASN.1, но ограниченную точность в SMI.

SNMPv1 SMI определяет сильноструктурированные таблицы, которые используются для группировки экземпляров табличного объекта (т.е. объекта, содержащего несколько переменных). Таблицы состоят из нуля и более строк, которые индексируются так, чтобы SNMP мог получить или изменить целую строку одной командой Get, GetNext или Set.

SMIv2 и структура управляющей информации

Вторая версия SMI (SMIv2) описана в RFC 2578 и RFC 2579. Она улучшает и дополняет специфичные для SMIv1 типы данных, такие как строки битов, сетевые адреса и счётчики. Битовые строки определены только в SMIv2 и содержат нуль и более битов, определяющих значение. Сетевые адреса представляют собой адрес из определённого семейства протоколов. Счётчики — неотрицательные целые числа, увеличивающиеся до тех пор, пока не достигнут максимального значения, после чего сбрасываются до нуля. В SMIv1 был определен размер счётчика в 32 бита. В SMIv2 определены и 32-, и 64-битные счётчики.

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

• MIB-модули содержат определения взаимосвязанных управляемых объектов.
• Заявления о соответствии предоставляют систематический способ описания группы управляемых объектов, которые должны быть реализованы в соответствии со стандартом.
• Заявления о возможности используются для указания точного уровня поддержки, который требует агент по отношению к группе MIB. NMS может регулировать его поведение по отношению к агентам в соответствии с заявлениями о возможностях, связанными с каждым агентом.

Обновление баз MIBПравить

Существует большое количество баз MIB, определённых как организациями по стандартизации (например, IETF), так и частными предприятиями и другими организациями.

Базы MIB от IETF

Базы MIB содержатся в 318 RFC из первых 5000 RFC от IETF. Данный список — лишь малая часть написанных баз MIB:

• SNMP — SMI:RFC 1155 — Определяет структуру управляющей информации (SMI)
• MIB-I: RFC 1156 — Исторически сложилось, что используется с CMOT, не используется с SNMP
• SNMPv2-SMI: RFC 2578 — Структура управляющей информации, версия 2 (SMIv2)
• MIB-II: RFC 1213 — База управляющей информации для сетевого управления в TCP/IP
• SNMPv2-MIB: RFC 3418 — База управляющей информации (MIB) для SNMP
• TCP-MIB: RFC 4022 — База управляющей информации для TCP
• UDP-MIB: RFC 4113 — База управляющей информации для UDP
• IP-MIB: RFC 4293 — База управляющей информации для IP
• IF-MIB: RFC 2863 — Группа интерфейсов MIB

Базы MIB от IEEE

IETF и IEEE согласились передать базы MIB, связанные с работой IEEE (например, Ethernet) соответствующим рабочим группам в IEEE. Это процесс ещё не закончен и лишь малая часть его выполнена.

• Сетевой мост
  IEEE 802.1ap-2008 объединила связанные с сетевыми мостами RFC от IEEE и IETF в восемь связанных баз MIB.
• IEEE 802.1ap-2008 объединила связанные с сетевыми мостами RFC от IEEE и IETF в восемь связанных баз MIB.

Внешние ссылкиПравить

• ByteSphere’s MIB Database Архивная копия от 19 июня 2012 на Wayback Machine, свободное онлайн-хранилище для тысяч баз SNMP MIB.
• MIBSearch Архивная копия от 26 мая 2006 на Wayback Machine, свободная поисковая система для файлов баз SNMP MIB.
• SimpleWeb MIBs Архивная копия от 19 июня 2012 на Wayback Machine
• MIB index, ICIR Архивная копия от 21 июня 2012 на Wayback Machine.
• MIB Compilers and Loading MIBs, Cisco Архивная копия от 21 июня 2012 на Wayback Machine.
• ipMonitor’s SNMP Center Архивировано 3 января 2013 года.
• MIB Depot Архивная копия от 23 декабря 2008 на Wayback Machine — обширный список баз MIB
• PEN (Private Enterprise Number) registry Архивная копия от 15 июня 2012 на Wayback Machine
• PEN request authority Архивная копия от 15 июня 2012 на Wayback Machine
• В.Г. Олифер, Н.А. Олифер — Компьютерные сети. Принципы, технологии, протоколы Архивная копия от 16 декабря 2009 на Wayback Machine
• MIB Search — Поиск по MIB.

Приветствую тебя, гость и постоянный читатель. Пришлось в последнее время внедряться в сетевой мониторинг. Очень актуальная тема для мониторинга — SNMP (Simple Network Management Protocol). Часто приходилось использовать SNMP, но руки не доходили до его описания. Сегодня хочу изложить свое понимание данной технологии.

Архитектура протокола SNMP

Сеть, использующая SNMP для управления содержит три основных компонента:

• SNMP менеджер — ПО, устанавливаемое на ПК администратора (системы мониторинга)
• SNMP агент — ПО, запущенное на сетевом узле, за которым осуществляется мониторинг.
• SNMP MIB — MIB это Management information base. Этот компонент системы обеспечивает структурированость данных, которыми обмениваются агенты и менеджеры. По сути — это некая база данных в виде текстовых фалов.

Давайте попытаемся рассмотреть обозначенные компоненты.

SNMP менеджер и SNMP агент

Для понимания назначения компонентов, можно сказать, что SNMP менеджер является прослойкой (интерфейсом) между операторомадминистратором и сетевым узлом с запущенным SNMP агентом. Так же, можно сказать, что SNMP агент — это интерфейс между SNMP менеджером и железным оборудованием на сетевом узле. Если провести аналогию протокола SNMP с клиент-серверной архитектурой (например, веб-сервера) то веб-сервер работает как служба на некотором порту, а пользователь силами браузера обращается к веб-серверу как клиент. Это четко обозначенная архитектура с выраженным клиентом и сервером. В случае SNMP роли клиента и сервера несколько размыты. Например, SNMP агент является своего рода службой, работающей на устройстве (за которым производится мониторинг) и обрабатывает запросы на определенном порту udp/161, то есть фактически является сервером. А SNMP менеджер является своего рода клиентом, который обращается к серверу SNMP агенту. В SNMP существует т.н. Trap. Это запрос от агента к менеджеру. Точнее даже не запрос, а уведомление. При отправке данного уведомления, агент и менеджер «меняются ролями». То есть, менеджер в таком случае должен являться сервером, работающем на порту udp/162, а агент является клиентом. В последних версиях SNMP trap может именоваться как извещение (notification).

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

Итак, как я уже сказал, SNMP менеджер отправляет запросы агенту на порт udp/161 (если конфигурационно в агенте не задан другой порт) с произвольного порта из эфемерного диапазона. В запросе SNMP менеджера указывается порт и адрес источника (о полной структуре пакета SNMP опишу ниже). Далее агент принимает пакет и обрабатывает (если выполняются нижеописанные условия). В процессе обработки, формируется ответ, который отправляется на порт взятый из исходного запроса. Ответ отправляется с udp/161 порта. Можно сказать, что SNMP агент таким образом предоставляет доступ SNMP менеджеру к данным, хранящимся в базе MIB. При этом, в момент отправки, SNMP менеджер вставляет в PDU некий ID (RequestID), а агент в ответном PDU вставляет данный ID без изменения, для того чтобы менеджер не путал пакеты от разных агентов. SNMP агент может быть настроен на посылку Trap уведомлений, которую он выполняет с эфимерного порта на udp/162 порт SNMP менеджера.

SNMP PDU (или сообщения SNMP протокола)

Выше я упомянул о единице обмена между узлами SNMP — PDU (Protocol Data Unit), давайте разберем данное понятие. Для обмена между агентом и менеджером используется определенный набор сообщений PDU команд:

• GetReponse – ответ от агента к менеджеру, возвращающий запрошенные значения переменных.
• GetRequest — запрос к агенту от менеджера, используемый для получения значения одной или нескольких переменных.
• GetNextRequest — запрос к агенту от менеджера, используемый для получения следующего в иерархии значения переменной.
• SetRequest — запрос к агенту на установку значения одной или нескольких переменных.
• GetBulkRequest – запрос к агенту на получение массива данных (тюнингованная GetNextRequest). (Этот PDU был введен в SNMPv2.)
• InformRequest – одностороннее уведомление между менеджерами. Может использоваться, например для обмена информацией о MIB (соответствие символьных OID — цифровым). В ответ менеджер формирует аналогичный пакет в подтверждение того, что исходные данные получены. (Этот PDU был введен в SNMPv2.)

Как видно, в зависимости от версии протокола, набор команд разный (например InformRequest и GetBulkRequest полноценно появился только во второй версии SNMP). Компонент SNMP MIB рассмотрим ниже.

Структура PDU

Рассмотрение структуры PDU не обязательно, но это поможет более глубоко понять логику работы SNMP. Все PDU (кроме Trap) состоят из определенного набора полей, в которые записывается необходимая информация:

Что данные поля обозначают:

• версия — содержит версию SNMP
• пароль (community) —  содержит последовательность символов, описывающую принадлежность к группе (об этом ниже)
• идентификатор запроса – это тот самый набор символов, который связывает в единое целое запросответ.
• 0 (NoError) – Нет ошибок,
• 1 (TooBig) — Объект не вмещается в одно Response сообщение,
• 2 (NoSuchName) – не существующая переменная,
• 3 (BadValue) – при попытке установить значение задано недопустимое значение или совершена синтаксическая ошибка,
• 4 (ReadOnly) – при Set запросе была попытка изменить read-only переменную,
• 5 (GenErr) – другие ошибки.
• Индекс ошибки – не нашел внятного описания ( но смысл в том, что содержит некий индекс переменной, к которой относится ошибка
• Поле связанные переменные может содержать одну или более переменную (для запросов Get – это только имя переменных, для Set – имя и устанавливаемое значение, для Response – имя и запрошенное значение).

При этом, содержимое Trap PDU содержит некоторые дополнительные поля (вместо заголовка запроса):

• Фирма – характеризующее производителя хоста
• Тип trapуведомления, может быть следующим:
  0 (Coldstart) и 1 (Warmstart) – объект возвращен в начальное состояние (между ними имеется некая разница, но какая?..),2 (Linkdown) – интерфейс опущен, при этом, поле переменной содержит интерфейс о котором идет речь,3 (Linkup) – интерфейс поднялся, при этом, поле переменной содержит интерфейс о котором идет речь,4 (Authenticationfailure) – менеджер прислал мессадж с неверной строкой community,5 (EGPneighborloss) – затрудняюсь что либо сказать ),6 (Entrprisespecific) – данный тип Trap сообщает о том, что в следующем поле содержится специализированный для данного вендора тип трапа.
• 0 (Coldstart) и 1 (Warmstart) – объект возвращен в начальное состояние (между ними имеется некая разница, но какая?..),
• 2 (Linkdown) – интерфейс опущен, при этом, поле переменной содержит интерфейс о котором идет речь,
• 3 (Linkup) – интерфейс поднялся, при этом, поле переменной содержит интерфейс о котором идет речь,
• 4 (Authenticationfailure) – менеджер прислал мессадж с неверной строкой community,
• 5 (EGPneighborloss) – затрудняюсь что либо сказать ),
• 6 (Entrprisespecific) – данный тип Trap сообщает о том, что в следующем поле содержится специализированный для данного вендора тип трапа.
• Специализированный тип Trap – описан выше

Логика работы протокола SNMP

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

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

Логика работы SNMP при обмене PDU-единицами

(взято частично отсюда http://logic-bratsk.ru/brlug/snmp_my/):

При получении PDU GetRequest, SNMP агент действует по следующему алгоритму:

• Если имя переменной не совпадает в точности с именем одной из переменной, доступных для операции get в нашей MIB, передаем отправителю запроса аналогичное PDU GetResponse, указывая в поле кода ошибки значение noSuchName (2-нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении (=1, в SNMPv1 — ограничение данной реализации SNMP).
• Если размер PDU GetResponse, созданного в соответствии с приведенным ниже описанием, превышает локальное ограничение (Реализация SNMP не обязана принимать сообщения, размер которых превышает определенное значение. Однако по возможности желательна поддержка дейтаграмм больших размеров (RFC1157 SNMP).), передаем отправителю аналогичное PDU GetResponse, указав в поле errorstatus значение TooBig, а в поле error-index — 0. Это обычно происходит, если запрошено больше 1 переменной или длина PDU или общая длина пакета больше стандартных пределов.
• Если для любой переменной, содержащейся в поле связанные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, SNMP агент передает отправителю аналогичное PDU GetResponse, указав в поле error-status значение GenErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.
• Если все нормально, передаем SNMP менеджеру, отправившему полученное сообщение, ответ — GetResponse, в котором для каждой переменной в поле связанные переменные подставлены запрошенные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

При получении PDU GetNextRequest, SNMP агент действует по следующему алгоритму:

• Если после переменной, указанной в запросе, нет следующей переменной, то передаем менеджеру PDU  GetResponse (с содержимым аналогичным исходному запросу), указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении (=1 для SNMPv1), значение переменной = NULL (кажется).
• Если для любой переменной в поле связанные переменные, значение переменной не может быть найдено по причинам, которые отличаются от перечисленных выше, принимающий объект передает менеджеру PDU с исходным содержимым GetResponse, указав в поле error-status значение genErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении. (аналогично вышесказанному)
• Если все нормально, передаем SNMP менеджеру, отправившему PDU, такое сообщение GetResponse, в котором для каждой переменной в поле связанные переменные содержится имя и значение переменной, иерархически следующей за запрошенной переменной в базе MIB. В поле error-status помещается значение noError, а в поле error-index — 0. Значение поля request-id в ответном PDU GetResponse совпадает с идентификатором в принятом сообщении.

При получении PDU SetRequest, SNMP агент действует по следующему алгоритму:

• Если для любой переменной, содержащейся в поле связанные переменные, запись (операция set) не поддерживается в имеющих отношение к делу представлениях MIB, SNMP агент объект передает отправителю запроса аналогичное PDU  GetResponse, указывая в поле кода ошибки значение noSuchName (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.
• Если для любой переменной в запросе, запрашиваемые к изменению значения переменных не соответствуют стандартам (SMI, ASN.1 – об этом ниже), то SNMP агент передает SNMP менеджеру аналогичное PDU GetResponse, указывая в поле кода ошибки значение badValue (нет такого имени), а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении.
• Если для любой переменной в поле связанные переменные, значение переменной не может быть установлено  по причинам, которые отличаются от перечисленных выше, SNMP агент передает менеджеру PDU с исходным содержимым GetResponse, указав в поле error-status значение genErr, а в поле error-index — индекс имени вышеупомянутого объекта в полученном сообщении. (аналогично вышесказанному)
• Если все нормально, агент передает SNMP менеджеру, отправившему PDU, такое сообщение GetResponse, в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.

Логика работы SNMP в картинках

взято отсюда (http://www.manageengine.com/network-monitoring/what-is-snmp.html)

Обмен PDU GET⁄ GET NEXT⁄ GET BULK⁄ SET

Давайте попробуем понять MIB. Это совсем не люди в черном ) Как я уже сказал, это Management information base, то есть набор управляющей информации. Каждый сетевой узел, имеющий на своем борту SNMP агента (читай – поддерживающий протокол SNMP) предоставляет свой набор данных, тот, который в него «вложили» программистыразработчики при проектировании железкипрограммы. То есть в каждом сетевом устройстве с поддержкой SNMP имеется своя база MIB со строго обозначенным набором переменных. Каждая база MIB имеет древовидную структуру, каждый объект в которой характеризуется уникальным идентификатором объекта (Object Identifier, OID).

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

Имеется некая единая общая структура дерева MIB, а так же, имеются единые стандарты и принципы дальнейшего формирования данного дерева, его переменных, др. параметров, за эти правила отвечает некий разработанный стандарт под названием Структура Информации Управления (SMI, Structure of Management Information). Так же, имеется некий стандарт, называемый абстрактный синтаксис нотаций — ASN.1. Который тоже участвует в описании протокола SNMP и базы MIB. А еще имеется базовые правила кодирования BER (Basic Encoding Rules), определяющие кодирование сущностей, применяемых в SNMP.

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

Давайте рассмотрим типичное дерево MIB на рисунке:

Дерево объектов MIB подобно системе DNS (Domain Name System). Тут аналогично имеются символьные имена (аналогично NS имени) и называемые ASN.1 нотацией, и соответствующие им числовые значения (аналогично IP адресам), называемые dot нотацией. Каждый объект в MIB состоит из нескольких чисел, разделенных точками. Числам соответствуют текстовые наименования. При этом, в отличии от DNS — нет какого-то единого централизованного сервера, отвечающего за разолвинг имен. Все разрешения имен из символов в числа происходят силами SNMP менеджера (в зависимости от того, какие сопоставления MIB загружены в менеджер). Весь обмен между узлами SNMP происходит только в числовом виде. В символьном виде, наименования используются только для отображения на экране или в документации.

Часто OID характеризующий определенный объект в дереве MIB сравнивают со структурой телефонных номеров, т.к. они (номера) так же иерархичны и отдельные части номера назначаются различными организациями. Например, международные телефонные номера состоят из кода страны (назначаемого международной организацией) и телефонного номера в том виде, в котором он определен локально в стране. При этом, телефонный номер в стране делится на код областикраярегиона, номер АТС и далее номер абонента, привязанного к АТС. Аналогично — в MIB OID верхнего уровня назначаются международной организацией (ISO IEC ???), ветки OID нижнего уровня назначаются организациями, отвечающими за эти ветки.

Итак, структура OID в дереве MIB:

Данный раздел (iso.org.dod.internet) разветвляется на подразделы, которые в большинстве своем контролируются IANA и состоят (согласно RFC1155) из:

• directory OID=1.3.6.1.1 (iso.org.dod.internet.directory) – зарезервировано для использования в будущем
• mgmt OID=1.3.6.1.2 (iso.org.dod.internet.mgmt) — в этой ветке находится стандартные ответвления объектов.
• experimental OID=1.3.6.1.3 (iso.org.dod.internet.experimental) — это ветка для разработчиков. (не отображено на схеме)
• private OID=1.3.6.1.4 (iso.org.dod.internet.private) – раздел предназначен для использования производителями оборудования.

Итак iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1): данная ветка является базовой для большинства сетевых устройств и содержится практически в любом устройстве. Ветка поделена на базовые группы (которых на текущий момент более 170), характерные для любого сетевого оборудования. Давайте рассмотрим наиболее применяемые:

• iso.org.dod.internet.mgmt.mib-2.system (1.3.6.1.2.1.1) — ветка содержит в себе несколько объектов, характеризующих хост (аптайм, версия ОС и др.), описана в RFC1213.
• iso.org.dod.internet.mgmt.mib-2.interface (1.3.6.1.2.1.2) — содержит объекты, описывающие сетевую подсистему хоста (количество интерфейсов, размер MTU, скорость передачи, физические адреса и т.п.), описана в RFC2863.
• iso.org.dod.internet.mgmt.mib-2.ip (1.3.6.1.2.1.4) – содержит набор объектов, описывающих данные о проходящих IP пакетах (количество запросов, ответов, отброшенных пакетов и мн.др). Описана в RFC1213.
• iso.org.dod.internet.mgmt.mib-2.tcp (1.3.6.1.2.1.6) и iso.org.dod.internet.mgmt.mib-2.udp  (1.3.6.1.2.1.7) — содержат объекты, хранящие в себе информацию, касающуюся соответствующего транспортного протокола. Описана в RFC1213.

Отдельного абзаца так же достоин подраздел iso.org.dod.internet.private (1.3.6.1.4), содержащий в себе поддерево enterprise (1). Данная ветвь контролируется IANA и содержит в себе более 40000 поддеревьев (ознакомьтесь с актуальным списком http://www.iana.org/assignments/enterprise-numbers ). В данной ветке регистрируют свои поддеревья – производители оборудования. Вот пример ответвления:

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

Так же, важным моментом, является то, что любая ветвь базы MIB оканчивается , в которую записывается некоторое значение. При этом, в MIB существует несколько типов переменных. Во-первых, они делятся на переменные «только для чтения» и доступные для изменения, которые не позволяют выполнять запрос SetRequest и позволяют выполнять, соответственно. Во-вторых, имеются строковые переменные, табличные и мн.др., значения которых так же идентифицируются по OID. В целом, если нет желания к программированию для SNMP, то этим пониманием и можно ограничиться.

Безопасность протокола SNMP (или версии протокола SNMP)

Безопасность протокола SNMP — это самый изменяемый раздел спецификации протокола со времени его создания. С каждой версией SNMP, производились попытки усилить безопасность. Первая версия протокола SNMPv1 была самой простой и небезопасной.  Сообщения протокола могли быть подвержены возможности модификации, подмене или прослушиванию. Безопасность протокола базировалась на модели безопасности на основе сообществ (т.н. Community-based Security Model), что подразумевало аутентификацию на основе единой текстовой строки — своеобразного пароля (т.н. community-sting), которая передавалась в теле сообщения в открытом виде. Хотя, данная версия протокола самая незащищенная, она довольно часто применяется в современных сетях, т.к. является самой простой.

В одной из вторых версий SNMP (SNMPv2p) была попытка реализовать аутентификацию на основе сторон (т.н.Party-based Security Model). Технология кроме аутентификации, так же поддерживала возможность шифрования трафика. Данная технология не прижилась, как «сложная и запутанная» ) и в данный момент не используется. После чего SNMP второй версии вернулась к Community-based Security и стала именоваться SNMPv2c и применяется по сей день. SNMPv2 была переписана чуть более чем полностью, в результате чего существенно повышено быстродействие протокола, безопасность.

Давайте рассмотрим работу протокола SNMPv2c (и SNMPv1) с точки зрения безопасности. При рассмотрении структуры пакета PDU было видно, что каждая единица PDU содержит community строку. При этом, SNMP агент содержит список (часто данный список состоит из одного значения) разрешенных строк и описание того, что каждая из строк может делать (фактически – набор прав). В большинстве случаев – это права read/write. При активации функций SNMP на каком-либо хосте, стандартные строки community – это public и private для возможности чтения и для возможности чтения-записи соответственно. Это строки очень желательно менять на свои. Часто, при конфигурировании SNMP о , в котором для каждой переменной в поле связанные переменные подставлены установленные значения переменных. В поле error-status помещается значение NoError, а в поле error-index — 0. Значение поля request-id в ответном PDU совпадает с идентификатором в принятом сообщении.пределяют различные community строки для чтения переменных и для записи.