Последнее изменение файла: 2019.08.15
Скопировано с www.bog.pp.ru: 2023.06.06
Bog BOS: SNMP, MIB, RMON
SNMP (Simple Network Management Protocol) - это набор стандартов,
обеспечивающих мониторинг и управление удаленными устройствами, программами
и системами. В статье описывается архитектура системы
управления, история развития стандарта,
формат описания (SMI) моделей управляемых
устройств (MIB, Management Information Base),
протокол обмена данными SNMP,
базовая MIB
(Internet MIB, Internet MIB-II,
SNMPv2 MIB), специфические модули MIB:
Приведенная информация достаточна для понимания работы и использования
протоколов SNMPv1 и SNMPv2c. Если вам требуется использование SNMPv3 или
написание собственного агента SNMP - читайте RFC.
В описании архитектуры SNMP определяются следующие роли
субъектов управления (entity):
сетевая станция управления (NMS, Network Management Station) - выдает
запросы на получение или изменение данных и обрабатывает ответы
агент - субъект управления, встроенный в устройство или программу;
отвечает на запросы станции управления, извлекая данные из
устройства или оказывает на устройство управляющее воздействие;
стандарт не определяет механизм работы агента, например, бывают агенты,
которые при обработке запроса посылают запросы подчиненным агентам
прокси агент - передает SNMP запросы для обработки другим агентам,
не разбираясь в содержимом запроса
Это действительно роли, т.к. одна и та же программа может
выступать в роли агента при получении запросов от вышестоящей станции
управления и быть станцией управления для нижестоящих агентов. При построении
иерархических систем управления требуется возможность управлять самой
станцией управления. В такую станцию управления встраивается агент и она
называется субъектом "двойного назначения" (dual-role entity).
Главный агент (master-agent), субагент и протокол
взаимодействия (AgentX, DPI, SMUX, EMANATE).
В обычном режиме работы станция управления по очереди
опрашивает множество агентов, собирая данные, но в заранее определенных
аварийных ситуациях агент может послать станции управления незапрошенное
(unsolisted) сообщение. В SNMPv1 для этого используются trap, в SNMPv2 и SNMPv3
- извещения (notification) и информационные сообщения (inform).
Trap и извещения не требуют ответа от станции управления.
Способ задания адреса получателя незапрошенных сообщений стандартами не
определен.
Протокол взаимодействия между станцией управления и агентом
основан на обмене сообщениями PDU (Protocol Data Unit), инкапсулированными
в пакеты транспортного протокола. Каждое сообщение содержит команду
станции управления на чтение значения переменной при сборе информации
или команду изменения значения переменной при управлении устройством.
Переменными в стандарте SNMP называются экземпляры
(instance) объектов.
Объект имеет тип (синтаксис, семантика и кодировка при передаче по сети) и имя.
Переменная имеет тип, имя и значение.
Имена объектов являются иерархическими (образуют дерево) и записываются в
символьном (OBJECT DESCRIPTOR) или числовом (OBJECT IDENTIFIER) формате
(одному идентификатору может соответствовать несколько дескрипторов).
Идентификатор
объекта соответствует идентификатору объекта в дереве регистрации объектов ISO,
т.е. все идентификаторы объектов SNMP образуют одно единое дерево, точнее
ветку с корнем iso.org.dod.internet глобального дерева объектов ISO.
Простые имена (sub-identifier) записываются слева направо (более значимые
слева) и разделяются точками (не более 128 штук).
Простое имя не может быть нулем. Желательно,
чтобы все простые дескрипторы были уникальны, тогда вместо полного дескриптора
объекта его можно однозначно адресовать простым дескриптором.
Простые дескрипторы внутри одного модуля должны быть уникальны.
Объекты могут иметь скалярный тип, являться таблицами
или строками таблицы (таблицы не могут быть вложенными). Каждая таблица
имеет ровно один подчиненный объект типа строка. Объект типа строка таблицы
состоит из одного или нескольких скалярных объектов.
Переменные могут быть экземплярами только скалярных объектов.
Идентификатор переменной состоит из двух частей: идентификатора объекта,
экземпляром которого она является, и суффикса. Для скалярного объекта,
не входящего в строку,
суффиксом переменной служит число 0, т.е. объект скалярного типа имеет ровно
один экземпляр.
Для объектов, являющихся частью строки таблицы, суффиксом идентификатора
переменной служит индекс строки таблицы: один или несколько простых
идентификаторов, разделенных точками.
Т.е. объект типа строка таблицы может иметь
несколько экземпляров, однозначно идентифицируемых индексом.
Индекс указывается при описании строки таблицы в виде перечня идентификаторов
скалярных объектов, значения экземпляров которых (т.е. значения переменных)
однозначно идентифицируют строку таблицы, а значит и каждую ячейку таблицы.
Пример скалярного объекта:
дескриптор объекта: system.sysDescr
дескриптор переменной: system.sysDescr.0
значение переменной: "APC Embedded PowerNet SNMP Agent"
пример переменной: at.atTable.atEntry.atPhysAddress.192.168.0.1
пример значения этой переменной: 00:C0:34:00:00:A0
Обрабатываемый агентом список объектов и их типов
закладывается в него разработчиком, а станция управления получает эту
информацию с помощью MIB (Management Information Base). MIB - текстовый
файл, описывающий доступные объекты и их типы на языке, определяемом
стандартом SMI (Structure and Identification of Management Information).
Агент не использует этот файл при работе. MIB делится на модули,
некоторые модули принимаются в виде стандартов, некоторые модули создаются
разработчиками оборудования.
Разработчик управляемого оборудования (разработчик агента)
должен предоставить список поддерживаемых агентом модулей.
При описании модуля указывается какие объекты обязательны для
реализации, а какие - нет. При описании агента можно указывать какие модули
он поддерживает, в каком объеме и с какими модификациями.
Административная модель SNMP определяет алгоритмы
аутентификации и шифрования, используемые ключи, способ аутентификации
управляющей станции и агента (точнее говоря, его текущего рабочего контекста),
способ определения прав доступа к информации. PDU обрабатывается целиком
в рамках одного контекста. Контекст позволяет агенту
отличать одно управляемое им устройство от другого. В SNMPv1 и SNMPv2c
имя сообщества (community name) определяет все параметры административной
модели (контекст, алгоритмы аутентификации и шифрования и т.д.).
В большинстве реализаций (стандарт использования имени сообщества отсутствует)
оно используется в качестве пароля (передается в открытом виде и легко
перехватывается и подделывается) и для определения контекста (имя сообщества
определяет набор доступных объектов - MIB View), шифрование не применяется.
Обычно при конфигурации агента определяются отдельные имена сообщества
для чтения объектов, записи объектов и посылки trap. Способ задания
имени сообщества не стандартизован.
Имеется множество версий SMI, протокола SNMP и MIB:
SNMPv1 (RFC 1155-1157, RFC 1212),
SNMPv2 (RFC 1441-1452, она же называется SNMPv2p или SNMPv2 classic или
SNMPv2 party-based),
SNMPv2c (RFC 1901-1908, community-based SNMPv2: SNMPv2 с использованием
механизма авторизации с помощью имени сообщества из SNMPv1, единственный
"прижившийся" вариант SNMPv2)
и SNMPv3 (RFC 2570-2576, RFC 2578-2580),
не считая множества промежуточных вариантов (SNMPv2 usec или SNMPv2u - RFC1910,
SNMPv2*, SNMP-NG, SNMPv2*, SNMPv1+, SNMPv1.5, SNMP++).
Первым реальноиспользуемым набором стандартов SNMP
были RFC-1155, RFC-1156 и RFC-1157, определяющие SMI,
протокол SNMP и Internet MIB.
RFC-1212 внес уточнения в стандарт SMI (введено явное описание
индекса строки, описаны алгоритмы вставки и удаления строк таблицы).
RFC-1213 внес изменения в Internet MIB (MIB-II)
на основе нового SMI. RFC-1215 добавил возможность описания trap.
RFC-1441 по RFC-1552 определили новые версии SMI, протокола SNMP
и Internet MIB. Дополнительно была определена party-based административная
модель безопасности. К сожалению, она оказалось слишком сложной для реализации,
к тому же среди разработчиков возникли разногласия. В результате, были
приняты RFC-1901 по RFC-1908, совмещающие новые версии SMI, протокола SNMP
и Internet MIB с административной моделью SNMPv1 (community-based).
Более того, т.к. при работе агента не используется MIB и SMI, то возможно
использовать в различных комбинациях старые и новые MIB, SMIv1 и SMIv2,
протокол SNMPv1 и SNMPv2. Например, можно взять старую MIB, переписать ее на
SMIv2 для использования станцией управления, общающейся с агентами с помощью
протокола SNMPv2 (кроме trap).
Таким же типичным примером является использование
протокола SNMPv1 совместно с MIB, написанными для SNMPv2 (однако, при этом
нельзя использовать 64-битные числа).
Основные отличия SNMPv2c от SNMPv1:
нельзя использовать тире в именах (а как же mib-2?!)
текстуальные соглашения вместо простых производных типов
добавлена возможность указывать единицы измерения при описании объектов
64-битные целые и переименование Counter в Counter32 и т.д.
формальное описание требований к реализации агентов
формальное описание реализации конкретного агента
ACCESS заменен на MAX-ACCESS, нельзя использовать write-only,
появились права доступа read-create
статус mandatory заменен на current, убран статус optional
индексирование экземпляров можно описывать с помощью AUGMENTS
убран тип NetworkAddress
аккуратно определена возможность создания и удаления строк таблицы
trap заменены на извещения (notification), Trap PDU на SNMPv2-Trap PDU
Описание MIB делится на модули, каждый модуль обычно
размещается в отдельном текстовом файле и содержит конструкцию:
имя-модуля DEFINITIONS ::= BEGIN
IMPORTS
что, ... FROM откуда
...;
ровно один вызов макро MODULE-IDENTITY
вызовы макро OBJECT-IDENTITY,
TEXTUAL-CONVENTION,
OBJECT-TYPE,
NOTIFICATION-TYPE (TRAP-TYPE для SNMPv1),
OBJECT-GROUP, NOTIFICATION-GROUP,
MODULE-COMPLIANCE,
AGENT-CAPABILITIES
END
Управляющая станция может компилировать модель MIB из одного или нескольких
модулей. Макросы, объекты и типы (не составные),
определенные в одном модуле MIB,
могут импортироваться в другой модуль MIB.
Перечень экспортируемых объектов может быть задан оператором EXPORTS.
Имена (дескрипторы) модулей должны
быть уникальны. Простые дескрипторы внутри одного модуля должны быть уникальны.
Различные версии одного и того же модуля должны иметь одинаковые имена.
Каждый модуль MIB содержит
описание модуля (обязательно и ровно одно): MODULE-IDENTITY
текстуальные соглашения (синонимы ранее определенных типов данных):
TEXTUAL-CONVENTION
описания объектов: OBJECT-TYPE, OBJECT-IDENTITY
описания trap (notification): NOTIFICATION-TYPE (SNMPv2),
TRAP-TYPE (SNMPv1)
формальное описание требований к реализации агентов: OBJECT-GROUP,
NOTIFICATION-GROUP, MODULE-COMPLIANCE
формальное описание реализации конкретного агента: AGENT-CAPABILITIES
Модуль является текстовым файлом и пишется на адаптированном подмножестве
OSI ASN.1 (Abstract Syntax Notation One, ISO 8824:1987, ITU-X.208).
"Адаптированном"
настолько, что знание оригинального ASN.1 только помешает пониманию SNMP
(конечно, если нет потребности программировать кодирование/декодирование PDU,
для чего необходимо знание Basic Encoding Rules - BER).
"Адаптированное подмножество" определяется стандартом SMI (Structure and
Identification of Management Information, Structure of Management Information),
которое задает список стандартных типов и набор макросов ASN.1,
которые допустимо использовать при создании модуля. При использовании
каждого макроса (кроме trap) определяется идентификатор объекта
(trap определяет целое число).
Допускается непосредственное определение идентификаторов и дескрипторов
объектов и использование операторов IMPORTS и EXPORTS (в SNMPv2 оператор
EXPORTS отменен и экспортируются все описания). Использование
других средств ASN.1 и написание собственных макросов не допускается.
Версии SMI:
SMIv1 (RFC-1155); расширение SMIv1 для MIB-II (RFC-1212);
описание trap для SMIv1 (RFC-1215); модули: RFC1155-SMI, RFC-1212, RFC-1215
версия для SNMPv2 (RFC-1442), позднее названная SMIv2
версия SMIv2 для SNMPv2c (RFC-1902, RFC-1903 и RFC-1904); модули:
SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF
версия SMIv2 для SNMPv3 (RFC-2578, RFC-2579 и RFC-2580)
При определении дескриптора объекта указывается дескриптор вышестоящего
объекта и простой идентификатор объекта. Например, определение корня ветки
iso.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) выглядит так
(2 тире подряд отмечают начало комментария):
org OBJECT IDENTIFIER ::= { iso 3 } -- "iso" = 1
dod OBJECT IDENTIFIER ::= { org 6 }
internet OBJECT IDENTIFIER ::= { dod 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
или
mib-2 OBJECT IDENTIFIER ::= { iso org(3) dod(6) internet(1) mgmt(2) 1 }
Стандартные типы (модуль RFC1155-SMI для SNMPv1,
модуль SNMPv2-SMI для SNMPv2):
INTEGER (-2147483648..2147483647) или Integer32 (только в SMIv2),
также представляет перечислимый тип
Counter или Counter32 (в SMIv2): монотонно возрастающее целое от
0 до 2^32-1 с потерей бита
переполнения, начальное значение не определено, может сбрасываться
при инициализации устройства и в другие явно описанные моменты
времени
Gauge или Gauge32 (в SMIv2): неотрицательное целое от 0 до 2^32-1,
"заклинивающееся" при переходе через максимум
OCTET STRING (SIZE (0..65535), рекомендуется ограничиться 255 символами)
OBJECT IDENTIFIER (не более 128 простых имен)
NULL (заменен на zeroDotZero {0 0} в SMIv2)
TimeTicks (неотрицательное целое, отсчитывающее время в сотых долях секунды
от некоторой опорной точки по модулю 2^32, переполняется за 497 дней)
Opaque (произвольный ASN.1 тип закодированный как OCTET STRING,
для совместимости со старыми MIB, мне встречалась один раз)
NetworkAddress (отсылка на IpAddress, исчез в SNMPv2)
IpAddress (OCTET STRING of length 4, сетевой порядок байт)
Counter64 (в SMIv2)
Unsigned32 (в SMIv2)
SEQUENCE OF (таблица)
SEQUENCE {} (список, строка таблицы)
DisplayString (ASCII, до 255 символов, добавлен в MIB-II, превратился
в текстуальное соглашение в SNMPv2)
PhysAddress (OCTET STRING, добавлен в MIB-II, превратился
в текстуальное соглашение в SNMPv2)
Стандартные текстуальные соглашения (понятие введено в SNMPv2,
модуль SNMPv2-TC, позволяют вводить синонимы ранее
определенных типов переменных, уточнить
семантику объектов, воспринимаются только человеком):
TestAndIncr (INTEGER, позволяет производить атомарные (неделимые)
операции над совокупностью объектов, станция управления для
установки такой переменной должна предъявить его точное текущее
значение, только в этом случае оно увеличивается на 1)
AutonomousType (OBJECT IDENTIFIER, ссылка на независимое поддерево MIB)
InstancePointer (OBJECT IDENTIFIER, obsolete, ссылка на экземпляр
(заменен на VariablePointer) или строку таблицы (заменен на RowPointer))
VariablePointer (OBJECT IDENTIFIER, ссылка на экземпляр объекта:
ifInOctets.3)
RowPointer (OBJECT IDENTIFIER, ссылка на строку таблицы, точнее на
первый доступный объект строки)
RowStatus (INTEGER, позволяет создавать и удалять строки)
active (read-write)
notInService (read-write, строка не имеет соответствия в устройстве)
notReady (read-only, не хватает информации для применения строки
к устройству)
createAndGo (write-only, создать строку и сделать ее активной)
createAndWait (write-only, создать неактивную строку)
destroy (write-only, удалить строку)
TimeStamp - TimeTicks, причем начало эпохи соответствует тому моменту
времени, когда sysUpTime равен нулю
TimeInterval (INTEGER, в сотых долях секунды)
DateAndTime (OCTET STRING, 8 или 11 байт, "2d-1d-1d,1d:1d:1d.1d,1a1d:1d",
YYMDHmsd+HM, где d - сотые секунды, + - знак относительно UTC, HM - разница
с UTC)
StorageType (INTEGER, потеряется ли информации при отключении питания
или перезагрузке)
other
volatile (RAM)
nonVolatile (NVRAM)
permanent (можно изменять, но не удалять, частично ROM)
readOnly (ROM)
TDomain (OBJECT IDENTIFIER, тип транспортного протокола, например,
snmpUDPDomain)
TAddress (OCTET STRING (SIZE (1..255)), адрес транспортного уровня,
для UDP - 4 байта IP адрес, 2 байта - номер порта)
Макросы:
MODULE-IDENTITY (обеспечивает контактную информацию разработчиков и
историю создания модуля)
LAST-UPDATED
ORGANIZATION
CONTACT-INFO
DESCRIPTION
список REVISION и их DESCRIPTION в обратном хронологическом
порядке
OBJECT-IDENTITY (позволяет в дополнение к определению идентификатора
объекта (как в OBJECT IDENTIFIER) определить его статус и описание)
STATUS
current
deprecated (устарело, но пока поддерживается)
obsolete (устарело и не поддерживается)
DESCRIPTION
REFERENCE (описательная ссылка на другой модуль)
OBJECT-TYPE (определение синтаксиса и семантики объекта)
SYNTAX (описание структуры данных)
базовый тип (включая последовательности и таблицы), возможно
с ограничением размера или интервала значений, набора символов
текстуальное соглашение
BITS { список через запятую простых дескрипторов
объектов и простых идентификаторов в круглых скобках }
(множество именованных бит)
UNITS (единицы измерения)
MAX-ACCESS (максимальный уровень доступа, может быть ограничен
текущей авторизацией, в SMIv1 назывался ACCESS и мог иметь значение
write-only, но теперь все
значения упорядочены от наименьших прав доступа до максимальных)
not-accessible
accessible-for-notify (только для выдачи извещения, trap)
read-only
read-write
read-create (чтение, запись и создание)
STATUS: current, deprecated, obsolete (в SMIv1 были mandatory и
optional, перенесены в отдельное описание)
DESCRIPTION
REFERENCE (описательная ссылка на другой модуль)
INDEX { список через запятую имен объектов } (определяет индекс
базовой строки таблицы)
неотрицательное целое образует один простой идентификатор,
нумерация начинается с 1
строка фиксированной длины или переменной длины с ключевым словом
IMPLIED, каждый байт образует простой идентификатор
строка переменной длины без ключевого слова IMPLIED,
длина и каждый байт образуют простой идентификатор
идентификатор объекта с ключевым словом IMPLIED,
каждый простой идентификатор объекта образует простой идентификатор
идентификатор объекта без ключевого слова IMPLIED, количество
простых идентификаторов и каждый простой идентификатор объекта
образуют простые идентификаторы
IpAddress образует 4 простых идентификатора в обычной
десятичной записи: a.b.c.d
AUGMENTS имя-объекта (определяет индекс вспомогательной строки таблицы,
ссылаясь на описание базовой строки таблицы, т.е. имеющей INDEX)
DEFVAL { значение по умолчанию } (используется при создании строки
таблицы, если не все элементы строки определены)
TRAP-TYPE (только в SNMPv1; единственный макрос, определяющий целое число
вместо идентификатора объекта; число используется в качестве подтипа
enterpriseSpecific trap;
задает описания trap, специфичных для устройств)
ENTERPRISE { идентификатор объекта } (идентификатор объекта в
в ветке enterprise, помещается в поле enterprise Trap-PDU; если
в описании указано { mib-2 11 }, то в PDU помещается
sysObjectID)
VARIABLES { список возвращаемых переменных } (идентификаторы объектов)
DESCRIPTION
REFERENCE
NOTIFICATION-TYPE (определяемый дескриптор объекта задает имя извещения;
введен в SNMPv2)
OBJECTS { список идентификаторов объектов } (посылаются агентом)
STATUS: current, deprecated, obsolete
DESCRIPTION
REFERENCE
TEXTUAL-CONVENTION (введен в SNMPv2, текстуальные соглашения
позволяют вводить синонимы ранее определенных типов переменных,
текстуальное соглашение позволяет уточнить семантику
объектов и воспринимается только человеком)
DISPLAY-HINT (только для базовых типов INTEGER и OCTET STRING,
лавры разработчиков оператора FORMAT языка Фортран долго не давали им
спать по ночам ;)
INTEGER: первый символ определяет формат вывода
x - шестнадцатеричный
d - десятичный (положение десятичной точки может быть
задано в виде: "d-2")
o - восьмеричный
b - двоичный
OCTET STRING: одна или несколько спецификаций форматирования из
5 частей:
* (необязательная, очередной октет строки используется как
счетчик повторений спецификации форматирования)
число октетов строки, обрабатываемых данной спецификацией
формат вывода
x - шестнадцатеричный
d - десятичный
o - восьмеричный
a - ASCII
символ - разделитель (не обязателен)
символ - терминатор при повторении спецификации
(не обязателен)
STATUS: current, deprecated, obsolete
DESCRIPTION
REFERENCE
SYNTAX (описание структуры данных, также как в OBJECT-TYPE)
OBJECT-GROUP (введен в SNMPv2 для группирования объектов из этого модуля
с целью облегчения описания требований к реализации, модуль SNMPv2-CONF,
определяет идентификатор объекта)
OBJECTS { список-имен-объектов-через-запятую }
STATUS: current, deprecated, obsolete
DESCRIPTION
REFERENCE
NOTIFICATION-GROUP (введен в SNMPv2 для группирования извещений
из этого модуля с целью
облегчения описания требований к реализации, модуль SNMPv2-CONF,
определяет идентификатор объекта)
MODULE-COMPLIANCE (введен в SNMPv2 для формального описания требований
к реализации модулей MIB агентом,
модуль SNMPv2-CONF, определяет идентификатор объекта)
STATUS: current, deprecated, obsolete
DESCRIPTION
REFERENCE
MODULE [ идентификатор-модуля ] имя-модуля (может быть опущено, если
соответствие определяется для текущего модуля)
GROUP идентификатор-группы DESCRIPTION текст (перечень
условнообязательных, т.е. групп, зависящих от реализации конкретных
протоколов или других групп)
GROUP ...
OBJECT имя-объекта (уточнение синтаксиса или прав доступа для
объектов, входящих в обязательные или условнообязательные группы)
SYNTAX уточнение-синтаксиса
WRITE-SYNTAX уточнение-синтаксиса-для-записи
MIN-ACCESS
not-accessible
accessible-for-notify
read-only
read-write
read-create
OBJECT ...
MODULE ...
AGENT-CAPABILITIES (введен в SNMPv2 для формального описания возможностей
агента (относительно OBJECT-TYPE и NOTIFICATION-TYPE, а не
MODULE-COMPLIANCE!), модуль SNMPv2-CONF, определяет идентификатор объекта
(может быть извлечен из sysORID))
PRODUCT-RELEASE текст
STATUS: current, obsolete (deprecated не бывает)
DESCRIPTION
REFERENCE
перечень поддерживаемых модулей
SUPPORTS [ идентификатор-модуля ] имя-модуля
INCLUDES { список-идентификаторов-групп-через-запятую }
перечень описаний вариантов реализации объектов или извещений
VARIATION идентификатор-извещения
ACCESS not-implemented
DESCRIPTION текст
VARIATION идентификатор-объекта
SYNTAX уточнение-синтаксиса
WRITE-SYNTAX уточнение-синтаксиса-для-записи
ACCESS (реализованный уровень доступа)
not-implemented
accessible-for-notify
read-only
read-write
read-create
write-only (для совместимости с SNMPv1)
CREATION-REQUIRES { список-имен-объектов-через-запятую}
(определяет элементы строки, которые должны быть
установлены станцией управления в явном виде при
создании строки)
Все имена объектов MIB входят в ветку iso.org.dod.internet.mgmt.mib
(1.3.6.1.2.1). Ветка iso.org.dod.internet.mgmt.mib-2 имеет точно такой же
идентификатор - 1.3.6.1.2.1 (!).
Частные объекты входят в ветку
iso.org.dod.internet.private.enterprises (1.3.6.1.4.1).
Например, коммутатор Allied Telesyn:
iso.org.dod.internet.private.enterprises.alliedTelesyn.mibObject.fstswitchMib
(1.3.6.1.4.1.207.8.32).
circuitIfMIB (Circuit to Interface Translation,
CIRCUIT-IF-MIB, RFC-3201)
frsldMIB (Frame Relay Service Level Defs, FRSLD-MIB, RFC-3202)
experimental
private
enterprises
security
snmpV2
snmpDomains
snmpUDPDomain
snmpProxys
rfc1157Proxy
snmpModules
snmpMIB
snmpMIBObjects
snmpTrap
Не все группы (подветки), определенные
в стандартных MIB SNMPv1, обязаны быть реализованы в конкретном агенте, но если
подветка реализована, то она должна быть реализована полностью.
В SNMPv2 формальные требования определяются макросом MODULE-COMPLIANCE,
а возможности конкретной реализации - макросом AGENT-CAPABILITIES.
Протокол SNMP основывается на обмене PDU (Protocol Data Unit)
между станцией и агентом, для чего
обычно используется транспортный протокол UDP
(стандартный порт - 161, для trap - 162) для обмена сообщениями.
Может также использоваться TCP, IPX или протокол MAC уровня.
Отображение PDU на транспортный механизм описывается модулем SNMPv2-TM
(snmpUDPDomain, формат адреса: SnmpUDPAddress, "1d.1d.1d.1d/2d").
Каждое сообщение самодостаточно и содержит номер версии,
имя сообщества (community) и само PDU. Номера версий (SNMPv2p не использует
поле версии):
0 - SNMPv1 protocol
1 - SNMPv2c protocol
2 - SNMPv2u protocol
3 - SNMPv3 protocol
Стандарт не рекомендует посылать
сообщения длинее 484 байта (фрагментация UDP датаграмм нежелательна,
особенно, если возможна потеря пакетов при маршрутизации;
данное ограничение ее гарантирует для минимального MTU;
в случае использования только ethernet,
размер PDU можно увеличить до 1200 байт).
Формальный максимум - 64 КБ, но ограничения реализации обычно меньше.
Для кодирования PDU используется Basic Encoding Rules (BER из ASN.1).
Типы PDU:
GetRequest (номер запроса и список идентификаторов экземпляров объектов)
GetNextRequest (номер запроса и список идентификаторов экземпляров объектов,
в ответ для каждого имени посылается имя и значение лексиграфически
следующего ему объекта (в числовом формате имен),
к которому имеются права доступа; GetNextRequest ( sysUpTime )
вернет Response ( sysUpTime.0 = "123471" ))
GetBulkRequest (введен в SNMPv2 для массовых запросов)
Response (номер исходного запроса, статус (noError(0), tooBig(1),
noSuchName(2), badValue(3), readOnly(4), genErr(5), noAccess(6), wrongType(7),
wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11),
inconsistentValue(12), resourceUnavailable(13), commitFailed(14),
undoFailed(15), authorizationError(16), notWritable(17),
inconsistentName(18)),
номер ошибочной переменной, список имен и значений экземпляров объектов,
вместо значения может возвращаться: noSuchObject, noSuchInstance,
endOfMibView)
SetRequest (номер запроса, список имен и устанавливаемых значений
переменных; в начале делаются максимально возможные проверки корректности
запроса, на втором этапе изменяются значения переменных;
может потребоваться создать переменную (экземпляр объекта);
присвоение всем переменным из одного запроса происходит одновременно;
если, несмотря на все предварительные проверки, присвоение одной из
переменных оказывается невозможным, то все ранее сделанные в этом
запросе изменения откатываются (commitFailed, undoFailed))
Trap (SNMPv1, посылается агентом при возникновении определенной ситуации:
sysObjectID, IP адрес агента, подтип trap, time-stamp, список имен и
значений объектов, тип trap:
coldStart(0)
warmStart(1)
linkDown(2), первым элементов в списке объектов должен быть ifIndex
linkUp(3), первым элементов в списке объектов должен быть ifIndex
authenticationFailure(4), попытка неавторизованного доступа
egpNeighborLoss(5)
enterpriseSpecific(6), подробности указываются в подтипе (см. TRAP-TYPE)
SNMPv2-Trap (посылается агентом при возникновении определенной ситуации,
список имен и значений переменных начинается с sysUpTime.0 и snmpTrapOID.0,
имена и значения дополнительных переменных определяются пунктом OBJECTS
макроса NOTIFICATION-TYPE)
InformRequest (введен в SNMPv2, позволяет передавать сообщение от
одной управляющей станции к другой,
список имен и значений переменных начинается с sysUpTime.0 и snmpTrapOID.0,
имена и значения дополнительных переменных определяются пунктом OBJECTS
макроса NOTIFICATION-TYPE; в ответ посылается Response;
в реальности используется агентами как v2trap с подтверждением)
Report (введен в SNMPv2, использование и семантика определяется отдельно
для каждой административной политики доступа)
Internet MIB (RFC-1156, iso.org.dod.internet.mgmt.mib, 1.3.6.1.2.1) описан в формате RFC-1155 и включает группы (все read-only, кроме ifAdminStatus, at, ipDefaultTTL, ipRoutingTable):
system
sysDescr (описание устройства (entity): имя, номер версии и т.д.)
Internet MIB-II (RFC-1213, iso.org.dod.internet.mgmt.mib-2, 1.3.6.1.2.1 совпадает с "просто" MIB) описан в формате SMI RFC-1155 с
усовершенствованиями RFC-1212. Изменения по сравнению с Internet MIB:
system
sysContact (read-write, имя администратора и как его найти)
ipRoutingDiscards (число удаленных из-за недостатка места
строк таблицы маршрутизации)
tcp (tcpConnState стала read-write и добавилось состояние
deleteTCB(12))
tcpInErrs (число полученных сегментов с ошибками)
tcpOutRsts (число посланных сегментов с флагом RST)
udp
udpTable (таблица слушателей UDP)
udpEntry
udpLocalAddress (0.0.0.0 - слушает на всех интерфейсах)
udpLocalPort
egp (множество добавлений)
transmission: для каждого типа интерфейса ifType определяется
поддерево (в MIB-II не стандартизовано)
ethernet-csmacd
iso88023-csmacd
lapb
sdlc
ppp
snmp (узел может иметь несколько SNMP агентов или станций)
snmpInPkts
snmpOutPkts
snmpInBadVersions
snmpInBadCommunityNames
snmpInBadCommunityUses
snmpInASNParseErrs
snmpInTooBigs
snmpInNoSuchNames
snmpInBadValues
snmpInReadOnlys
snmpInGenErrs
snmpInTotalReqVars (количество объектов, успешно извлеченных
командами Get-Request и Get-Next)
snmpInTotalSetVars
snmpInGetRequests
snmpInGetNexts
snmpInSetRequests
snmpInGetResponses
snmpInTraps
snmpOutTooBigs
snmpOutNoSuchNames
snmpOutBadValues
snmpOutGenErrs
snmpOutGetRequests
snmpOutGetNexts
snmpOutSetRequests
snmpOutGetResponses
snmpOutTraps
snmpEnableAuthenTraps (read-write, enabled(1), disabled(2),
должен ли агент посылать trap в случае ошибки аутентификации)
В RFC-1354 предложена усовершенствованная замена для
ipRouteTable в виде структуры ipForward (ip.24), позволяющей задавать
маршруты с учетом не только конечного адреса, но и полиси, AS и
адреса следующего хопа.
В SNMPv2 (модуль SNMPv2-MIB) от Internet MIB
(ветка iso.org.dod.internet.mgmt.mib-2) остались только группы system и snmp,
все остальное было выделено в отдельные модули:
system (добавления относительно MIB-II)
sysORLastChange (TimeStamp, значение sysUpTime в моммент
последнего изменения sysORID)
sysORTable (таблица, описывающая поддерживаемые данным агентом модули)
sysOREntry (индекс для доступа к экземпляру объекта: sysORIndex)
sysORIndex (INTEGER)
sysORID (OBJECT IDENTIFIER, ссылка на AGENT-CAPABILITIES)
sysORDescr
sysORUpTime (TimeStamp)
snmp (добавления относительно MIB-II, при этом
объекты 2, 8-22, 24-29
переведены в состояние obsolete)
snmpSilentDrops (неудач при посылке ошибки tooBig)
snmpTrapOID (OBJECT IDENTIFIER, accessible-for-notify,
послылается как вторая переменная в SNMPv2-Trap PDU)
snmpTrapEnterprise (OBJECT IDENTIFIER, accessible-for-notify,
используется при преобразовании RFC1157 Trap-PDU в SNMPv2-Trap-PDU)
Ветка iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTraps(5) описывает "стандартные" trap:
coldStart
warmStart
linkDown (определен в модуле IF-MIB)
linkUp (определен в модуле IF-MIB)
authenticationFailure
egpNeighborLoss (определен в модуле ???)
Ветка iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpSet(6) позволяет нескольким управляющим станциям координировать
изменение переменных одного агента:
snmpSetSerialNo (TestAndIncr, read-write)
Ветка iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBConformance(2) задает формальные требования к минимальной реализации
SNMPv2-MIB агентами:
snmpMIBCompliances
snmpBasicCompliance (обязательно д.б. реализованы группы snmpGroup,
snmpSetGroup, systemGroup, snmpBasicNotificationsGroup; группа
snmpCommunityGroup д.б. реализована при использовании административной
модели, основанной на именах сообщества)
snmpMIBGroups (группировка объекта для использования в snmpMIBCompliances)
Bridge MIB (RFC-1493) определяет поддерево dot1dBridge
под mib-2 (1.3.6.1.2.1.17) для управления
мостом (коммутатором, IEEE 802.1D).
Порт в большинстве случае совпадает с интерфейсом
в той части трафика, которая обрабатывается по алгоритмам моста.
Некоторые типы физической реализации (X.25) позволяют
иметь несколько портов на обном интерфейсе. Данный стандарт рассматривает
только прозрачные мосты (например, Ethernet). Bridge Id состоит из
2 байт приоритета и 6 байтового MAC адреса. Port Id состоит из 1 байта
приоритета и 1 байта номера порта.
Подгруппы:
dot1dBase (информация для портов всех типов)
dot1dBaseBridgeAddress (MAC адрес уникально идентифицирующий мост,
рекомендованное значение - минимальный из MAC адресов портов)
dot1dBaseNumPorts
dot1dBaseType (unknown(1), transparent-only(2), sourceroute-only(3),
srt(4) - оба типа)
dot1dBasePortTable (таблица всех портов)
dot1dBasePortEntry (индекс доступа к экземпляру: dot1dBasePort)
dot1dBasePort (номер порта)
dot1dBasePortIfIndex (номер интерфейса ifIndex)
dot1dBasePortCircuit (для многопортовых интерфейсов
уникальный индекс порта в интерфейсе)
dot1dBasePortDelayExceededDiscards (число кадров,
отброшенных из-за чрезмерных задержек)
dot1dBasePortMtuExceededDiscards (число кадров,
отброшенных из-за чрезмерного размера
dot1dStp (информация, связанная с протоколом покрывающего дерева)
dot1dStpPriority (read-write, первые 2 байта Bridge ID)
dot1dStpTimeSinceTopologyChange (в 1/100 секунды)
dot1dStpTopChanges (число изменений топологии)
dot1dStpDesignatedRoot (Bridge Id назначенного корня)
dot1dStpRootCost (расстояние до корня от данного моста)
dot1dStpRootPort (номер корневого порта моста)
dot1dStpMaxAge (в 1/100 секунды, более старая информация,
полученная из сети, отбрасывается; это реальный MaxAge в сети)
dot1dStpHelloTime (в 1/100 секунды, интервалы между посылками
Hello; это реальный HelloTime в сети)
dot1dStpHoldTime (в 1/100 секунды, BPDU посылается не чаще указанного
времени)
dot1dStpForwardDelay (в 1/100 секунды, пауза перед переходом моста
в другое состояние; это реальный ForwardDelay в сети)
dot1dStpBridgeMaxAge (read-write, в 1/100 секунды, но должно быть
целым; 600 - 4000 секунд; если данный мост
является корнем, то вся сеть использует данное значение как MaxAge)
dot1dStpBridgeHelloTime (read-write, в 1/100 секунды, но должно быть
целым; 100 - 1000 секунд; если данный мост
является корнем, то вся сеть использует данное значение как
HelloTime
dot1dStpBridgeForwardDelay (read-write, в 1/100 секунды,
но должно быть целым; 400 - 3000 секунд; если данный мост
является корнем, то вся сеть использует данное значение как
ForwardDelay
dot1dStpPortTable (таблица STP информации для портов)
dot1dStpPortEntry (индекс доступа к экземпляру: dot1dStpPort)
dot1dStpPort (номер порта)
dot1dStpPortPriority (read-write, 0 - 255)
dot1dStpPortState (состояние порта в результате работы
STA: disabled(1), blocking(2), listening(3), learning(4),
forwarding(5), broken(6))
dot1dTpPortTable (информация о портах прозрачного моста)
dot1dTpPortEntry (индекс доступа к экземпляру: dot1dTpPort)
dot1dTpPort (номер порта)
dot1dTpPortMaxInfo (максимальный размер MAC кадра,
MTU плюс размер инкапсуляции)
dot1dTpPortInFrames (учитываются только кадры, обрабатываемые
по алгоритмам моста)
dot1dTpPortOutFrames
dot1dTpPortInDiscards (число корректных, но отфильтрованных
кадров)
dot1dStatic (статическая таблица адресов)
dot1dStaticTable (таблица, созданная администратором, может содержать
как индивидуальные, так и груповые и широковещательные адреса)
dot1dStaticEntry (индекс доступа к экземпляру:
dot1dStaticAddress, dot1dStaticReceivePort)
dot1dStaticAddress (read-write, MAC адрес получателя)
dot1dStaticReceivePort (read-write, номер порта, с
которого должен прийти кадр, чтобы быть обработанным этой
записью; 0 означает любой порт, для которого нет
специфической информации)
dot1dStaticAllowedToGoTo (read-write; список портов, на
которые разрешается направлять кадры, пришедшие с
dot1dStaticReceivePort и имеющие адрес получателя
dot1dStaticAddress; битовая маска - каждый байт представляет
очередные 8 портов, наиболее значащий бит представляет порт
с наименьшим номером из 8)
MIB повторителя (RFC-1516) определяет поддерево
snmpDot3RptrMgt под mib-2 (1.3.6.1.2.1.22) для управления
повторителем. Не включает управление
MAU (описано отдельно). Понятие "интерфейс" применяется
только к устройству управления, но не к обычным портам повторителя.
Подгруппы:
rptrBasicPackage
rptrRptrInfo (информация о повторителе в целом)
rptrGroupCapacity (максимальное число групп портов)
net-snmp (пакеты net-snmp и net-snmp-utils,
бывший ucd-snmp до версии 4.9.2, в 5.0 поменялся синтаксис команд)
позволяет посылать SNMP запросы и обрабатывать ответы, устанавливать агенты SNMP на компьютер,
посылать и получать SNMP сообщения (trap). Включает в себя библиотеку API для разработки
собственных программ. Имеется поддержка шифрования SNMPv2 и SNMPv3.
В командах запросов первым параметром указывается
IP адрес или DNS имя запрашиваемого устройства, вторым параметром -
дескриптор или идентификатор объекта (возможны сокращения).
Примеры использования пакета ucd-snmp (net-snmp 5.1.2) для
извлечения информации из агентов SNMPv1 (дополнительные MIB необходимо поместить
в /usr/share/snmp/mibs/):
узнать число интерфейсов
snmpget -m all -v1 -c сообщество [-p порт] IP-адрес IF-MIB::ifNumber.0
получение количества байт, вышедших с первого интерфейса
snmpget -m all -v1 -c сообщество [-p порт] IP-адрес interfaces.ifTable.ifEntry.ifOutOctets.1
получение количества байт, вышедших с каждого интерфейса (номера м.б. не по порядку)
snmpget -m all -v1 -c сообщество [-p порт] IP-адрес IF-MIB::ifOutOctets
получение полного дерева объектов, поддерживаемых агентом (может занять много места и времени)
snmpwalk -m all -v1 -c сообщество IP-адрес .iso
получение из простого дескриптора объекта полного дескриптора:
snmptranslate -m all -Of -IR простой-дескриптор
получение из простого дескриптора объекта полного дескриптора в числовом формате:
snmptranslate -m all -On -IR простой-дескриптор
получение из полного дескриптора объекта полного идентификатора:
snmptranslate -m all -To полный-дескриптор
snmpget -c пароль public -v 2c -m +SUN-STOREDGE-3310-MIB адрес ctlrUniqueID.0
(предварительно SUN-STOREDGE-3310-MIB.txt в ~/.snmp/mibs/)
получение привязки MAC адресов к портам для классического коммутатора (BRIDGE-MIB):
snmpwalk -c public -v 2c адрес SNMPv2-SMI::mib-2.17.4.3.1.2| awk -F. '{print $7,$8,$9,$10,$11,$12}'|awk '{printf "%d %02x%02x%02x%02x%02x%02x\n",$9,$1,$2,$3,$4,$5,$6}'
получение привязки MAC адресов к портам для коммутатора без BRIDGE-MIB по VLAN1:
snmpwalk -c public -v 2c адрес SNMPv2-SMI::mib-2.17.7.1.2.2.1.2| awk -F. '{print $10,$11,$12,$13,$14,$15}'|awk '{printf "%d %02x%02x%02x%02x%02x%02x\n",$9,$1,$2,$3,$4,$5,$6}'
RFC-3216. SMIng Objectives. C. Elliott, D. Harrington, J. Jason, J. Schoenwaelder, F. Strauss, W. Weiss. December 2001.
RFC-3144. Remote Monitoring MIB Extensions for Interface Parameters Monitoring. D. Romascanu. August 2001.
RFC-3014. Notification Log MIB. R. Kavasseri. November 2000.
RFC-2981. Event MIB. R. Kavasseri (Ed. of this version). October 2000.
RFC-2922. Physical Topology MIB. A. Bierman, K. Jones. September 2000.
RFC-2896. Remote Network Monitoring MIB Protocol Identifier Macros. A. Bierman, C. Bucci, R. Iddon. August 2000.
RFC-2895. Remote Network Monitoring MIB Protocol Identifier Reference. A. Bierman, C. Bucci, R. Iddon. August 2000. (Obsoletes RFC2074)
RFC-2864. The Inverted Stack Table Extension to the Interfaces Group MIB. K. McCloghrie, G. Hanson. June 2000.
RFC-2863. The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June 2000. (Obsoletes RFC2233)
RFC-2819. Remote Network Monitoring Management Information Base. S. Waldbusser. May 2000. (Obsoletes RFC1757)
RFC-2790. Host Resources MIB. S. Waldbusser, P. Grillo. March 2000.
RFC-2789. Mail Monitoring MIB. N. Freed, S. Kille. March 2000.
RFC-2788. Network Services Monitoring MIB. N. Freed, S. Kille. March 2000.
RFC-2742. Definitions of Managed Objects for Extensible SNMP Agents. L. Heintz, S. Gudur, M. Ellison. January 2000.
RFC-2741. Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B. Wijnen, M. Ellison, Ed., D. Francisco. Ed. January 2000
RFC-2737. Entity MIB (Version 2). K. McCloghrie, A. Bierman. December 1999.
RFC-2720. Traffic Flow Measurement: Meter MIB. N. Brownlee. October 1999.
RFC-2674. Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions. E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie. August 1999.
RFC-2666. Definitions of Object Identifiers for Identifying Ethernet Chip Sets. J. Flick. August 1999.
RFC-2665. Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick, J. Johnson. August 1999.
RFC-2613. Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0. R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser. June 1999.
RFC-2594. Definitions of Managed Objects for WWW Services. H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder. May 1999.
RFC-2593. Script MIB Extensibility Protocol Version 1.0. J. Schoenwaelder, J. Quittek. May 1999.
RFC-2592. Definitions of Managed Objects for the Delegation of Management Scripts. D. Levi, J. Schoenwaelder. May 1999.
RFC-2580. Conformance Statements for SMIv2. K. McCloghrie, D. Perkins, J. Schoenwaelder. April 1999.
RFC-2579. Textual Conventions for SMIv2. K. McCloghrie, D. Perkins, J. Schoenwaelder. April 1999.
RFC-2578. Structure of Management Information Version 2 (SMIv2). K. McCloghrie, D. Perkins, J. Schoenwaelder. April 1999.
RFC-2576. Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. R. Frye, D. Levi, S. Routhier, B. Wijnen. March 2000.
RFC-2575. View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. April 1999.
RFC-2574. User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. April 1999.
RFC-2573. SNMP Applications. D. Levi, P. Meyer, B. Stewart. April 1999.
RFC-2572. Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. April 1999.
RFC-2571. An Architecture for Describing SNMP Management Frameworks. B. Wijnen, D. Harrington, R. Presuhn. April 1999.
RFC-2570. Introduction to Version 3 of the Internet-standard Network Management Framework. J. Case, R. Mundy, D. Partain, B. Stewart. April 1999.
RFC-2564. Application Management MIB. C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia. May 1999.
RFC-2438. Advancement of MIB specifications on the IETF Standards Track. M. O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. October 1998.
RFC-2287. Definitions of System-Level Managed Objects for Applications. Krupczak, C. and J. Saperia. April 1997.
RFC-2233. The Interfaces Group MIB using SMIv2. K. McCloghrie, F. Kastenholz. November 1997.
RFC-2108. Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie. February 1997.
RFC-2096. IP Forwarding Table MIB. F. Baker. January 1997.
RFC-2089. V2ToV1: Mapping SNMPv2 onto SNMPv1 Within a Bilingual SNMP Agent. Wijnen, B. and D. Levi. January 1997.
RFC-2074. Remote Network Monitoring MIB Protocol Identifiers. A. Bierman, R. Iddon. January 1997.
RFC-2021. Remote Network Monitoring Management Information Base Version 2 using SMIv2. S. Waldbusser. January 1997.
RFC-2013. SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2. K. McCloghrie. November 1996.
RFC-2012. SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2. K. McCloghrie. November 1996.
RFC-2011. SNMPv2 Management Information Base for the Internet Protocol using SMIv2. K. McCloghrie. November 1996.
RFC-1910. User-based Security Model for SNMPv2. G. Waters. February 1996. (SNMP2 usec или SNMPv2u, не прижилось, но идеи использованы в SNMPv3)
RFC-1909. An Administrative Infrastructure for SNMPv2. K. McCloghrie. February 1996.
RFC-1908. Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose and S. Waldbusser. January 1996.
RFC-1907. Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose and S. Waldbusser. January 1996.
RFC-1906. Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose and S. Waldbusser. January 1996.
RFC-1905. Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose and S. Waldbusser. January 1996.
RFC-1904. Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996.
RFC-1903. Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996.
RFC-1902. Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996.
RFC-1901. Introduction to Community-based SNMPv2. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996.
RFC-1759. Printer MIB. R. Smith, F. Wright, T. Hastings, S. Zilles and J. Gyllenskog. March 1995.
RFC-1757. Remote Network Monitoring Management Information Base. S. Waldbusser. February 1995.
RFC-1643. Definitions of Managed Objects for the Ethernet-like Interface Types. F. Kastenholz. July 1994.
RFC-1628. UPS Management Information Base. J. Case. May 1994.
RFC-1612. DNS Resolver MIB Extensions. R. Austein and J. Saperia. May 1994.
RFC-1611. DNS Server MIB Extensions. R. Austein and J. Saperia. May 1994.
RFC-1592. Simple Network Management Protocol: Distributed Protocol Interface, Version 2.0. Wijnen, B., Carpenter, G., Curran, K., Sehgal, A. and G. Waters. March 1994.
RFC-1573. Evolution of the Interfaces Group of MIB-II. K. McCloghrie, F. Kastenholz. January 1994. (Obsoleted by RFC-2233)
RFC-1516. Definitions of Managed Objects for IEEE 802.3 Repeater Devices. D. McMaster, K. McCloghrie. September 1993
RFC-1493. Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, and K. McCloghrie. July 1993.
RFC-1452. Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
RFC-1451. Manager-to-Manager Management Information Base. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
RFC-1450. Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
RFC-1449. Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
RFC-1448. Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
RFC-1447. Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2). K. McCloghrie, J. Galvin. April 1993.
RFC-1446. Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993.
RFC-1445. Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993.
RFC-1444. Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
RFC-1443. Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
RFC-1442. Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
RFC-1441. Introduction to version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
RFC-1354. IP Forwarding Table MIB. F. Baker. July 1992. (усовершенствованная ipRouteTable - ipForwardTable ::= { ip 24 })
-RFC-1353. Definitions of Managed Objects for Administration of SNMP Parties. K. McCloghrie, J. Davin, J. Galvin. July 1992.
-RFC-1352. SNMP Security Protocols. Galvin, J., McCloghrie, K., and J. Davin. July 1992.
-RFC-1351. SNMP Administrative Model. J. Davin, J. Galvin, K. McCloghrie. July 1992.
RFC-1303. A Convention for Describing SNMP-based Agents. K. McCloghrie, M. Rose. February 1992. (предшественник AGENT-CAPABILITIES для SNMPv1)
RFC-1270. SNMP Communications Services. F. Kastenholz. October 1991. (почему транспортный уровень лучше для реализации SNMP, чем сетевой или физический; почему UDP лучше, чем TCP)
RFC-1224. Techniques for Managing Asynchronously Generated Alerts. L. Steinberg. May 1991. (предлагаются алгоритмы по предотвращению "trap шторма" и потери trap)
RFC-1215. A Convention for Defining Traps for use with the SNMP. M. Rose, Editor. March 1991.
RFC-1213. Management Information Base for Network Management of TCP/IP-based internets:MIB-II. K. McCloghrie, M.T. Rose. Mar-01-1991.
RFC-1212. Concise MIB Definitions. M. Rose, K. McCloghrie, Editors. March 1991
RFC-1155. Structure and Identification of Management Information for TCP/IP-based Internets. M. Rose, K. McCloghrie. May 1990
RFC-1156. Management Information Base for network management of TCP/IP-based internets. K. McCloghrie, M.T. Rose. May-01-1990.
RFC-1157. Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin. May-01-1990.