Основные протоколы интернет

Простой протокол управления сетью

Разбить на страницы
Показывать лекцию целиком

Простой протокол управления сетью (SNMP — Simple Network Management Protocol) – это структура для управления устройствами в сети Интернет, c использованием набора протоколов TCP/IP. Он обеспечивает ограниченный набор функций контроля и управления над параметрами устройств сети Интернет — например, мостами, маршрутизаторами и другими сетевыми устройствами Он поддерживает слежение за состоянием сетевых устройств и сетевого трафика.

Концепция

SNMP использует концепцию менеджера и агента. То есть менеджер, обычно хост, управляет и контролирует набор агентов, обычно это – маршрутизаторы. SNMP — протокол прикладного уровня, в котором несколько станций менеджера управляют набором агентов. Протокол разработан для прикладного уровня так, чтобы он мог управлять устройствами, выпущенными различными изготовителями и установленными на различных физических сетях. Другими словами, SNMP освобождает задачи управления и от физических характеристик управляемых устройств, и от основной технологии организации сети. Это может использоваться в неоднородной сети Интернет, образованной из различных локальных сетей LAN и общедоступных телекоммуникационных сетей широкого назначения (WAN), которые связаны маршрутизаторами, выпущенными различными изготовителями.

Менеджеры и агенты

Станция управления, названная менеджером, является хостом, который выполняет SNMP-программу клиента. Управляемая станция, названная агентом, является маршрутизатором (или хостом), который выполняет SNMP-программу сервера. Управление достигается с помощью простого взаимодействия между менеджером и агентом.

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

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

Агенты могут также внести вклад в процесс управления. Управляемая программа сервера, выполняемая агентом, может проверить внешнюю среду, и если она замечает что-то необычное, она может послать сообщение предупреждения (названное ловушкой) менеджеру.

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

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

    Компоненты управления

    Чтобы выполнить задачи управления, SNMP использует другие два протокола: структура управляющей информации (SMI – Structure of Management Information) и база управляющей информации (MIB – Management Information Base).

    Другими словами, управление сетью Интернет осуществляется при взаимодействии трех протоколов: SNMP, SMI и MIB.

    Рассмотрим взаимодействие между этими протоколами.

    Задачи SNMP

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

    Задачи SMI

    Чтобы использовать SNMP, нам нужны правила описания объектов управления и правила присвоения имен объектам. Это особенно важно, потому что объекты в SNMP формируют иерархическую структуру (объект может иметь объект-родителя и некоторые объекты-детей), и часть имени может быть унаследована от родителя. Нам также нужны правила для того, чтобы определить тип объектов. Какие типы объектов обрабатываются SNMP? SNMP может обрабатывать простые или структурированные типы. Какие простые типы он может обрабатывать? Каковы размеры этих типов? Каков диапазон этих типов? Кроме того — как каждый из этих типов закодирован?

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

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

    Задачи MIB

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

    Аналогия

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

    Прежде чем составлять программу, должен быть предопределен синтаксис языка (типа C или C++). Язык также определяет структуру переменных (простой, структурированный, указатель и так далее) и имена переменных. Например, имя переменной должно быть представлено символами от 1 до N по длине и начинаться с буквы, сопровождаемой алфавитно-цифровыми символами. Язык также определяет тип используемых данных (целое число, с плавающей запятой, символ и т. д.). В программировании правила описания переменных определены языком. В управлении сетью правила описания управляемых и контролируемых устройств определены SMI.

    Большинство компьютерных языков требует, чтобы переменные были объявлены в каждой программе. Декларация называет каждую переменную и определяет предопределенный тип. Например, если программа имеет две переменные (целое число, названное счетчик, и массив, названный степень типа символ), они должны быть объявлены в начале программы:

    int счетчик;
char степень [40];

    Заметим, что декларации называют переменные (счетчик и степень) и определяют тип каждой переменной. Поскольку типы предопределены в языке, программа знает диапазон и размер каждой переменной.

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

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

    Мы можем сравнить задачу управления сетью и задачу написания программы:

  • Обе задачи нуждаются в правилах. В управлении сетью правила устанавливает SMI.
  • Обе задачи нуждаются в декларациях (объявлении) переменных. В управлении сетью это делает MIB.
  • Обе задачи выполняют действия операторами. В управлении сетью это делается SNMP.
    •

    Общие замечания

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

    (рис 15.1) Общий процесс управления

    MIB находит объект, чтобы сохранить полученное в сообщении число пользовательских дейтаграмм UDP. SMI, с помощью других вложенных в него протоколов, кодирует имя объекта. SNMP создает сообщение, называемое GetRequest, и инкапсулирует его в закодированное сообщение. Конечно, реальный процесс более сложен, чем этот общий процесс, поэтому сначала рассмотрим каждый протокол отдельно.

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

    Структура управляющей информации, версия 2 (SMIv2) — компонент для управления сетью. Его функции:

  • Присвоить имена объектам.
  • Определить тип данных, которые могут быть сохранены в объекте.
  • Показывать, как кодировать данные для передачи по сети.
    •

    SMI выделяет три атрибута для того, чтобы обрабатывать объект: имя, тип данных и метод кодирования. ( Рис 15.2.).

    (рис 15.2) Атрибуты объектов

    Имя

    SMI требует, чтобы каждый управляемый объект (такой как маршрутизатор, переменная в маршрутизаторе, значение и т. п.) имел уникальное имя. Чтобы присвоить глобальное имя объекту, SMI использует идентификатор объекта, который является иерархическим и основан на структуре дерева ( Рис 15.3.).

    (рис 15.3) Идентификация объекта

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

    Объекты, которые используются в SNMP, расположены в адресе после объекта mib-2, поэтому их идентификатор всегда начинается с 1.3.6.1.2.1.

    Тип

    Второй атрибут объекта — тип сохраняемых в нем данных. Определяя тип данных, SMI пользуется фундаментальными ASN.1-определениями и дополняет некоторые их новыми определениями. Другими словами, SMI — и поднабор, и супернабор ASN.1.

    SMI использует две широких категории типа данных: простые и структурированные. Мы сначала определим простые типы, а затем покажем, как структурированные типы могут быть построены из одних простых ( Рис 15.4.).

    (рис 15.4) Тип данных

    Простой тип

    Простой тип – это частичка типа данных, некоторые из них прямо поступают в ASN.1, некоторые дополняются SMI. Большинство важных единиц даны в таблице 15.1. Первые 5 — из ASN.1; следующие семь определены SMI.

    Тип данных
    Тип Размер Описание
    INTEGER 4 байта Целое со значением между 0 и 231-1
    Integer 32 4 байта То же самое, что и INTEGER
    Unsigned32 4 байта Значения без знака между 0 и 231
    OCTET STRING Переменный Строка байтов не более 65 535 байтов длины
    OBJECT IDENTIFIER Переменный Идентификатор объекта
    IPAdress 4 байта IP-адрес, состоящий из четырех байтов
    Counter32 4 байта Целое, значение которого может быть увеличено от 0 до 232; когда оно достигает максимального значения, оно свертывается назад в нуль
    Counter64 8 байтов 64-битовый счетчик
    Gauge32 4 байта Тот же самый 32-битовый счетчик (counter32), но он достигает максимального значения и не сворачивается в ноль; он остается там, пока не сбрасывается
    TimeTics 4 байта Считает значение, в котором записано время в 1/100 секунды
    BITS Строка бит
    Opaque Переменный Неинтерпретируемая строка

    Структурированный тип

    Комбинируя простой и структурированный типы данных, мы можем создать новые структурированные типы данных. SMI определяет два вида структурированных типов данных: sequence (последовательности) и sequence of (последовательности из).

  • Sequence (последовательность). Тип данных sequence (последовательности) – это комбинация простых типов данных, не обязательно одного типа. Это аналог понятий struct (структура) или record (комбинированный), используемых в языках программирования, таких как C.
  • Sequence of (последовательность из). Тип данных sequence of (последовательность из) — комбинация из простых типов данных одного типа или комбинации последовательного типа данных одного типа. Это аналог понятия массив, используемого в языках программирования, таких как C.
    •

    Рисунок 15.5. показывает концептуальный обзор типов данных.

    (рис 15.5) Концептуальные типы данных

    Метод кодирования

    SMI использует другой стандарт, основные правила кодирования (BER — Basic Encoding Rules), чтобы кодировать данные, которые будут переданы по сети. BER определяет, что каждая часть данных кодируется в формате тройки: тег, длина и значение, как проиллюстрировано на рисунке 15.6.

    (рис 15.6) Формат длины
  • Тег. Тег – однобайтовое поле, которое определяет тип данных. Оно составлено из трех подполей: класс (2 бита), формат (1 бит), и номер (5 битов). Подполе класса определяет область действия данных. Определены четыре класса: универсальный (00), прикладной (01), контекстно-определенный (10) и частный (11). Универсальные типы данных взяты из ASN.1 (INTEGER, OCTET STRING и ObjectIdentifeir). Прикладные типы данных — те, которые добавлены SMI (IPAddress, Counter, Gauge и TimeTicks). Пять контекстно-определенных типов данных имеют значения, которые могут измениться от одного протокола к другому. Частные типы данных определяются поставщиком.

    Подполе "Формат" указывает, являются ли данные простыми (0) или структурированными (1). Далее подполе "номера" делит простые или структурированные данные на подгруппы. Например, в универсальном классе, с простым форматом, INETGER имеет значение 2, OCTET STRING имеет значение 4, и так далее. Таблица 15.2. показывает типы данных, которые мы используем в этой лекции, и их теги в двоичных и шестнадцатеричных числах.

    Коды для типов данных
    Тип данных Класс Формат Номер Тег (двоичный) Тег (шестнад.)
    INTEGER (Целый) 00 0 00010 00000010 02
    OCTET STRING (октет последовательностей) 00 0 00100 00000100 04
    OBJECT IDENTIFIER (ИДЕНТИФИКАТОР ОБЪЕКТА) 00 0 00110 00000110 06
    NULL (ПУСТОЙ УКАЗАТЕЛЬ) 00 0 00101 00000101 05
    Последовательность, последовательность из 00 1 10000 00110000 30
    IPAddress (IP-адрес) 01 0 00000 01000000 40
    Counter (Счетчик) 01 0 00001 01000001 41
    Gauge (Шаблон) 01 0 00010 01000010 42
    TimeTicks (Сигналы времени) 01 0 00011 01000011 43
  • (рис 15.7) Формат длины
  • Значение. Поле кодирует значение данных в соответствии с правилами, определенными в правилах кодирования (например, ANSI).
    •

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

    Пример 1

    Рисунок 15.8. показывает, как определяется INTEGER 14:

    (рис 15.8) Пример 1 INTEGER 14

    Пример 2

    Рисунок 15.9. показывает, как определяется OCTET STRING "H1":

    (рис 15.9) Пример 2 OCTET STRING "H1"

    Пример 3

    Рисунок 15.10. показывает, как определяется OBJECT Identifier 1.3.6.1 (iso.dod.internet):

    (рис 15.10) Пример 3 ObjectIdentifier 1.3.6.1

    Пример 4

    Рисунок 15.11. показывает, как определить IPAddress 131.21.14.8:

    (рис 15.11) Пример 4 IPAdress 131.21.14.8

    MIB

    База управляющей информации (MIB2 — Management Information Base 2) – это второй компонент, используемый в сетевом управлении. Каждый агент имеет свой собственный MIB2, являющийся отображением всех объектов, которыми может управлять менеджер. Объекты в MIB2 разбиты по категориям на 10 групп: система (sys), интерфейс (if), адрес трансляции (at), ip, icmp, tcp, udp, egp, trans и snmp. Эти группы в адресе находятся после обозначения объекта MIB2 в дереве объектов идентификации ( Рисунок 15.12.).

    (рис 15.12) MIB-2

    Организация доступа MIB-переменных

    Чтобы показать доступность различных переменных, мы используем как пример udp-группы. Имеются четыре простых переменных в группах и одна последовательность записей (таблица). Рисунок 15.13. показывает переменные и таблицу.

    (рис 15.13) udp-группа

    Мы покажем, как иметь доступ к каждому объекту.

    Простая переменная

    Чтобы организовать доступ любой простой переменной, мы используем групповой id ( 1.3.6.1.2.1.7 ), сопровождаемый id переменной. Ниже показано, как организовать доступ к каждой переменной:

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

    Таблицы

    Чтобы идентифицировать таблицу, мы сначала используем id. Группа udp имеет только одну таблицу (с id 5), как это показано на рисунке 15.14.

    (рис 15.14) udp-переменные и таблицы

    Для организации таблицы мы должны использовать следующие адреса:

    Однако таблица в этом дереве не на уровне листа. Мы не можем иметь доступ к таблице, пока не определим вход (последовательность) в таблице (с id 1), как это показано ниже:

    Этот вход также не имеет листов, и нам он недоступен. Нам нужно определить каждый объект входа. Это две переменные в листе дерева. Хотя мы можем обратиться к их образцам, мы должны определить, какой именно образец нам нужен. В любой момент таблица может иметь несколько значений для каждой пары местный адрес / местный порт. Чтобы обратиться к определенному образцу (строке) таблицы, мы должны добавить индекс к вышеупомянутым id. В MIB индексы массивов — не целые числа (подобно большинству языков программирования). Индексы базируются на значении одной или более областей во входах. В нашем примере udpTable определяется местным адресом и номером местного порта. Например, рисунок 15.15. показывает таблицу с четырьмя строками и значениями для каждого поля. Индекс каждой строки — комбинация двух значений.

    (рис 15.15) Индексы для udpTable

    Чтобы обратиться к образцу местного адреса для первой строки, мы используем идентификатор, увеличенный на индекс образца:

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

    Лексикографическое упорядочение

    Одна интересная точка зрения о MIB-переменных — то, что идентификаторы объекта (включая идентификаторы образца) находятся в лексикографическом порядке. Таблицы упорядочиваются в соответствии правилам строки-столбца, и это означает, что нужно идти от столбца к столбцу, а в каждом столбце нужно идти от вершины до основания, как показано на рисунке 15.16.

    (рис 15.16) Лексикографическое упорядочение

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

    SNMP

    SNMP использует и SMI, и MIB в управлении сетью Интернет. Он – прикладная программа, которая позволяет быть:

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

    PDU

    SNMPv3 определяет восемь типов пакетов (или PDUs): GetRequest, GetNextRequest, GetBulkRequest, SetRequest, Response, Trap, InformRequest и Report ( Рис. 15.17.).

    (рис 15.17) SNMP PDUs

    GetRequest

    GetRequest PDU посылается от менеджера (клиента) к агенту (серверу), чтобы извлечь значение переменной или набора переменных.

    GetNextRequest

    GetNextRequest PDU посылают от менеджера к агенту, чтобы извлечь значение переменной. Найденное значение – это значение объекта, следующего после определенного в таблице Objectid в PDU. Этот запрос главным образом используется, чтобы извлечь значения входов в таблице. Если менеджер не знает индексов входов, он не может извлечь значения. Однако он может применить GetNextRequest и определить Objectid таблицы. Поскольку первый вход имеет Objectid непосредственно после Objectid таблицы, значение первого входа возвращается менеджеру. Менеджер может использовать этот Objectid, чтобы получить значение следующего, и так далее.

    GetBulkRequest

    GetBulkRequest PDU посылают от менеджера к агенту, чтобы извлечь большое количество данных. Он может применяться вместо кратного числа GetRequest и GetNextRequest PDUs.

    SetRequest

    SetRequest PDU посылают от менеджера к агенту, чтобы установить (сохранить) значение в переменной.

    Ответ (Response)

    Ответ PDU посылают от агента к менеджеру в ответ на GetRequest или GetNextRequest. Он содержит значение(я) переменной(ых), которую запрашивает менеджер.

    Ловушка (Trap)

    Ловушку (также ее называют ловушкой SNMPv2, чтобы отличить от ловушки SNMPvl) PDU посылают от агента к менеджеру, чтобы сообщить о событии. Например, если агент перезагружен, он информирует менеджера и сообщает время перезагрузки.

    InformRequest

    Inform Request PDU посылают от одного менеджера другому удаленному менеджеру, чтобы получить значение некоторых переменных от агентов, которые управляются удаленным менеджером. Удаленный менеджер отвечает Ответом PDU.

    PDU-рапорт (Report)

    PDU-рапорт разработан, чтобы сообщить о некоторых типах ошибок между менеджерами.

    Формат

    Формат для восьми SNMP PDUs показан на рисунке 15.18. GetBulkRequest PDU отличается от других PDU двумя областями, как показано на рисунке.

    (рис 15.18) Формат SNMP PDU

    Поля перечислены ниже.

  • PDU-тип (PDU type). Это поле определяет тип PDU (см. таблицу 15.4).
  • Запрос ID (Request ID). Это поле — порядковый номер, используется менеджером в запросе PDU и повторяется агентом в ответе. Он нужен, чтобы сравнить запрос и ответ.
  • Состояние ошибки (Error Status). Это целое число, которое используется только в ответе PDUs, чтобы показать типы ошибок, о которых сообщает агент. Его значение — 0 в запросе PDUs. Таблица 15.3. содержит список типов ошибок, которые могут произойти.
    Типы ошибок
    Состояние Название Значение
    0 noError Нет ошибки
    1 TooBig Слишком большой ответ для размещения в одном сообщении
    2 NoSuchName Переменная не существует
    3 BadValue Значение, которое должно быть сохранено, недопустимо
    4 readOnly Значение не может быть изменено
    5 genErr Другие ошибки
  • Не ретранслируемая (Non-repeaters). Это поле используется только в GetBulkRequest и удаляет ошибку поля состояния, которая является пустой в запросе PDUs.
  • Индекс ошибки (Error index). Индекс ошибки — смещение, которое говорит менеджеру, какая переменная вызвала ошибку.
  • Максимальное повторение (Max-repetition). Это поле также используется только в GetBulkRequest и заменяет поле индекса ошибки, которое является пустым в PDUs-запросе.
  • VarBindList. Это набор переменных с соответствующими значениями, которые менеджер хочет извлечь или установить. Значения являются нулевыми в GetRequest и GetNextRequest. В PDU-ловушке он показывает переменные и значения, связанные с определенным PDU.
    •

    Сообщения

    SNMP не посылает отдельные PDU, он включает PDU в сообщение. Сообщение в SNMPv3 состоит из четырех элементов: версия, заголовок, параметры защиты и данные (которые включает кодируемый PDU), как показано в рисунке 15.19.

    (рис 15.19) SNMP-сообщение

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

    Чтобы определять тип PDU, SNMP использует метку. Класс контекстно-зависим (10), формат структурирован (1), и числа — 0, 1, 2, 3, 5, 6, 7, 8 ( табл. 15.4.).

    Обратите внимание, что SNMPv 1 определяет A4 для "ловушки", которая на сегодняшний день является устаревшей.

    Коды для SNMP-сообщений
    Данные Класс Номер Полный тег (двоичный) Полный тег (шестнадцатеричный)
    GetRequest 10 1 00000 10100000 A0
    GetNextRequest 10 1 00001 10100001 A1
    Response 10 1 00010 10100010 A2
    SetRequest 10 1 00011 10100011 A3
    GetBulkRequest 10 1 00101 10100101 A5
    InformRequest 10 1 00110 10100110 A6
    Trap (SNMPv2) 10 00111 10100111 A7
    Report 10 1 01000 10101000 A8

    Пример 1

    В этом примере менеджер станции (SNMP-клиент) использует сообщение GetRequest, чтобы извлечь номер UDP-дейтаграммы, которую получил маршрутизатор.

    Есть только один объект VarBind (переменная – связка). Соответствующий MIB соотносит эту информацию, содержащуюся в udpInDatagram, с идентификатором объекта 1.3.6.1.2.1.7.1.0. Менеджер хочет извлечь значение. Рис.15.20. показывает в общем виде пакет с иерархической структурой. На рисунке используются белые и цветные участки для последовательностей и серые для PDU. OCTET STRING.

    (рис 15.20) Пример 1

    Список VarBind (см. рис.15.20.) имеет длину 0F (15) и состоит только из одной последовательности VarBind, длиной OD (13). В начале списка переменная указывает тип 06 и длину списка 09. Длина дальнейшего сообщения 00.). Сообщение GetRequest PDU имеет длину ID (29).

    Имеются три октета последовательностей: параметры безопасности, модель безопасности и флаги. Затем следуют два целых числа, которые определяют максимальный размер (1024) и ID сообщения (64). Есть заголовок длинной 12, который не показан (для простоты). Имеется одно целое число — версия (версия 3). Полностью сообщение составляет 52 байта.

    Рисунок 15.21. показывает реальное сообщение, посылаемое менеджером станции (клиентом) к агенту (серверу).

    (рис 15.21) GetRequest сообщение

    UDP-порты

    SNMP использует услуги UDP на двух заданных портах, 161 и 162. Заданный порт 161 задействован сервером (агентом), и заданный порт 162 отведен клиенту (менеджеру).

    Агент (сервер) производит пассивное открытие порта 161. Затем он ждет подключения от менеджера (клиента). Менеджер (клиент) производит активное открытие, используя кратковременный порт. Сообщение запроса посылается от клиента серверу, задействуя кратковременный порт как исходный порт и заданный порт 161 как порт пункта назначения. Сообщение ответа посылают от сервера к клиенту, использующему заданный порт 161 как исходный порт и кратковременный порт как порт пункта назначения.

    Менеджер (клиент) производит пассивное открытие порта 162. Затем он ждет подключения от агента (сервера). Агент (сервер) производит активное открытие, используя кратковременный порт, всякий раз, когда посылает сообщение-ловушку (Trap). Это подключение является только односторонним, от сервера к клиенту ( Рис.15.22.).

    (рис 15.22) Номер портов для SMNP

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

    Краткие итоги

  • Простой протокол управления сетью (SNMP) — структура для управления устройствами Интернета с использованием набора протоколов TCP/IP.
  • Менеджер, обычно хост, управляет и контролирует набор агентов, обычно маршрутизаторов.
  • Менеджер — хост, который выполняет SNMP-программу клиента.
  • Агент — маршрутизатор или главный компьютер, который выполняет SNMP-программу сервера.
  • SNMP освобождает задачи управления и от физических характеристик управляемых устройств, и от основной технологии организации сети.
  • SNMP использует услуги двух других протоколов: структура информации управления (SMI) и основы информации управления (MIB).
  • SMI определяет тип данных объектов имен, которые могут быть сохранены в объекте, и кодирует данные.
  • SMI-объекты называются согласно иерархической структуре дерева.
  • SMI типы данных определены согласно нотации абстрактного синтаксиса 1 (ASN.l).
  • SMI использует основные правила кодирования (BER), чтобы кодировать данные.
  • MIB — совокупность групп объектов, которые могут управляться SNMP.
    •

    Задачи и упражнения

  • Покажите кодирование для INTEGER 1456.
  • Покажите кодирование для OCTET STRING "Hello Grey".
  • Покажите кодирование для произвольного OCTET STRING длиною 1000.
  • Покажите, как кодируется следующая запись (последовательность):
    INTEGER OCTET STRING IP Адрес
    2345 "COMPUTER" 185.32.1.5
  • Покажите, как кодируется следующая запись (последовательность):
    Time Tick INTEGER Object Id
    12000 14564 1.3.6.1.2.1.7
  • Покажите, как кодируется следующий массив (последовательность из...):
    INTEGER OCTET STRING Счетчик
    2345 "COMPUTER" 345
    1123 "DISK" 1430
    3456 "MONITOR" 2313
  • Декодируйте следующие выражения:
  • 02 04 01 02 14 32;
  • 30 06 02 01 11 02 01 14 ;
  • 30 09 04 03 41 43 42 02 02 14 14 ;
  • 30 0A 40 04 23 51 62 71 02 14 12.
    •

    Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.

    Страницы:

    Простой протокол управления сетью (SNMP — Simple Network Management Protocol) – это структура для управления устройствами в сети Интернет, c использованием набора протоколов TCP/IP. Он обеспечивает ограниченный набор функций контроля и управления над параметрами устройств сети Интернет — например, мостами, маршрутизаторами и другими сетевыми устройствами Он поддерживает слежение за состоянием сетевых устройств и сетевого трафика.

    Концепция

    SNMP использует концепцию менеджера и агента. То есть менеджер, обычно хост, управляет и контролирует набор агентов, обычно это – маршрутизаторы. SNMP — протокол прикладного уровня, в котором несколько станций менеджера управляют набором агентов. Протокол разработан для прикладного уровня так, чтобы он мог управлять устройствами, выпущенными различными изготовителями и установленными на различных физических сетях. Другими словами, SNMP освобождает задачи управления и от физических характеристик управляемых устройств, и от основной технологии организации сети. Это может использоваться в неоднородной сети Интернет, образованной из различных локальных сетей LAN и общедоступных телекоммуникационных сетей широкого назначения (WAN), которые связаны маршрутизаторами, выпущенными различными изготовителями.

    Менеджеры и агенты

    Станция управления, названная менеджером, является хостом, который выполняет SNMP-программу клиента. Управляемая станция, названная агентом, является маршрутизатором (или хостом), который выполняет SNMP-программу сервера. Управление достигается с помощью простого взаимодействия между менеджером и агентом.

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

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

    Агенты могут также внести вклад в процесс управления. Управляемая программа сервера, выполняемая агентом, может проверить внешнюю среду, и если она замечает что-то необычное, она может послать сообщение предупреждения (названное ловушкой) менеджеру.

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

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

    Компоненты управления

    Чтобы выполнить задачи управления, SNMP использует другие два протокола: структура управляющей информации (SMI – Structure of Management Information) и база управляющей информации (MIB – Management Information Base).

    Другими словами, управление сетью Интернет осуществляется при взаимодействии трех протоколов: SNMP, SMI и MIB.

    Рассмотрим взаимодействие между этими протоколами.

    Задачи SNMP

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

    Задачи SMI

    Чтобы использовать SNMP, нам нужны правила описания объектов управления и правила присвоения имен объектам. Это особенно важно, потому что объекты в SNMP формируют иерархическую структуру (объект может иметь объект-родителя и некоторые объекты-детей), и часть имени может быть унаследована от родителя. Нам также нужны правила для того, чтобы определить тип объектов. Какие типы объектов обрабатываются SNMP? SNMP может обрабатывать простые или структурированные типы. Какие простые типы он может обрабатывать? Каковы размеры этих типов? Каков диапазон этих типов? Кроме того — как каждый из этих типов закодирован?

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

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

    Задачи MIB

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

    Аналогия

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

    Прежде чем составлять программу, должен быть предопределен синтаксис языка (типа C или C++). Язык также определяет структуру переменных (простой, структурированный, указатель и так далее) и имена переменных. Например, имя переменной должно быть представлено символами от 1 до N по длине и начинаться с буквы, сопровождаемой алфавитно-цифровыми символами. Язык также определяет тип используемых данных (целое число, с плавающей запятой, символ и т. д.). В программировании правила описания переменных определены языком. В управлении сетью правила описания управляемых и контролируемых устройств определены SMI.

    Большинство компьютерных языков требует, чтобы переменные были объявлены в каждой программе. Декларация называет каждую переменную и определяет предопределенный тип. Например, если программа имеет две переменные (целое число, названное счетчик, и массив, названный степень типа символ), они должны быть объявлены в начале программы:

    int счетчик;
char степень [40];

    Заметим, что декларации называют переменные (счетчик и степень) и определяют тип каждой переменной. Поскольку типы предопределены в языке, программа знает диапазон и размер каждой переменной.

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

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

    Мы можем сравнить задачу управления сетью и задачу написания программы:

  • Обе задачи нуждаются в правилах. В управлении сетью правила устанавливает SMI.
  • Обе задачи нуждаются в декларациях (объявлении) переменных. В управлении сетью это делает MIB.
  • Обе задачи выполняют действия операторами. В управлении сетью это делается SNMP.
    •

    Общие замечания

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

    (рис 15.1) Общий процесс управления

    MIB находит объект, чтобы сохранить полученное в сообщении число пользовательских дейтаграмм UDP. SMI, с помощью других вложенных в него протоколов, кодирует имя объекта. SNMP создает сообщение, называемое GetRequest, и инкапсулирует его в закодированное сообщение. Конечно, реальный процесс более сложен, чем этот общий процесс, поэтому сначала рассмотрим каждый протокол отдельно.

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

    Структура управляющей информации, версия 2 (SMIv2) — компонент для управления сетью. Его функции:

  • Присвоить имена объектам.
  • Определить тип данных, которые могут быть сохранены в объекте.
  • Показывать, как кодировать данные для передачи по сети.
    •

    SMI выделяет три атрибута для того, чтобы обрабатывать объект: имя, тип данных и метод кодирования. ( Рис 15.2.).

    (рис 15.2) Атрибуты объектов

    Имя

    SMI требует, чтобы каждый управляемый объект (такой как маршрутизатор, переменная в маршрутизаторе, значение и т. п.) имел уникальное имя. Чтобы присвоить глобальное имя объекту, SMI использует идентификатор объекта, который является иерархическим и основан на структуре дерева ( Рис 15.3.).

    (рис 15.3) Идентификация объекта

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

    Объекты, которые используются в SNMP, расположены в адресе после объекта mib-2, поэтому их идентификатор всегда начинается с 1.3.6.1.2.1.

    Тип

    Второй атрибут объекта — тип сохраняемых в нем данных. Определяя тип данных, SMI пользуется фундаментальными ASN.1-определениями и дополняет некоторые их новыми определениями. Другими словами, SMI — и поднабор, и супернабор ASN.1.

    SMI использует две широких категории типа данных: простые и структурированные. Мы сначала определим простые типы, а затем покажем, как структурированные типы могут быть построены из одних простых ( Рис 15.4.).

    (рис 15.4) Тип данных

    Простой тип

    Простой тип – это частичка типа данных, некоторые из них прямо поступают в ASN.1, некоторые дополняются SMI. Большинство важных единиц даны в таблице 15.1. Первые 5 — из ASN.1; следующие семь определены SMI.

    Тип данных
    Тип Размер Описание
    INTEGER 4 байта Целое со значением между 0 и 231-1
    Integer 32 4 байта То же самое, что и INTEGER
    Unsigned32 4 байта Значения без знака между 0 и 231
    OCTET STRING Переменный Строка байтов не более 65 535 байтов длины
    OBJECT IDENTIFIER Переменный Идентификатор объекта
    IPAdress 4 байта IP-адрес, состоящий из четырех байтов
    Counter32 4 байта Целое, значение которого может быть увеличено от 0 до 232; когда оно достигает максимального значения, оно свертывается назад в нуль
    Counter64 8 байтов 64-битовый счетчик
    Gauge32 4 байта Тот же самый 32-битовый счетчик (counter32), но он достигает максимального значения и не сворачивается в ноль; он остается там, пока не сбрасывается
    TimeTics 4 байта Считает значение, в котором записано время в 1/100 секунды
    BITS Строка бит
    Opaque Переменный Неинтерпретируемая строка

    Структурированный тип

    Комбинируя простой и структурированный типы данных, мы можем создать новые структурированные типы данных. SMI определяет два вида структурированных типов данных: sequence (последовательности) и sequence of (последовательности из).

  • Sequence (последовательность). Тип данных sequence (последовательности) – это комбинация простых типов данных, не обязательно одного типа. Это аналог понятий struct (структура) или record (комбинированный), используемых в языках программирования, таких как C.
  • Sequence of (последовательность из). Тип данных sequence of (последовательность из) — комбинация из простых типов данных одного типа или комбинации последовательного типа данных одного типа. Это аналог понятия массив, используемого в языках программирования, таких как C.
    •

    Рисунок 15.5. показывает концептуальный обзор типов данных.

    (рис 15.5) Концептуальные типы данных

    Метод кодирования

    SMI использует другой стандарт, основные правила кодирования (BER — Basic Encoding Rules), чтобы кодировать данные, которые будут переданы по сети. BER определяет, что каждая часть данных кодируется в формате тройки: тег, длина и значение, как проиллюстрировано на рисунке 15.6.

    (рис 15.6) Формат длины
  • Тег. Тег – однобайтовое поле, которое определяет тип данных. Оно составлено из трех подполей: класс (2 бита), формат (1 бит), и номер (5 битов). Подполе класса определяет область действия данных. Определены четыре класса: универсальный (00), прикладной (01), контекстно-определенный (10) и частный (11). Универсальные типы данных взяты из ASN.1 (INTEGER, OCTET STRING и ObjectIdentifeir). Прикладные типы данных — те, которые добавлены SMI (IPAddress, Counter, Gauge и TimeTicks). Пять контекстно-определенных типов данных имеют значения, которые могут измениться от одного протокола к другому. Частные типы данных определяются поставщиком.

    Подполе "Формат" указывает, являются ли данные простыми (0) или структурированными (1). Далее подполе "номера" делит простые или структурированные данные на подгруппы. Например, в универсальном классе, с простым форматом, INETGER имеет значение 2, OCTET STRING имеет значение 4, и так далее. Таблица 15.2. показывает типы данных, которые мы используем в этой лекции, и их теги в двоичных и шестнадцатеричных числах.

    Коды для типов данных
    Тип данных Класс Формат Номер Тег (двоичный) Тег (шестнад.)
    INTEGER (Целый) 00 0 00010 00000010 02
    OCTET STRING (октет последовательностей) 00 0 00100 00000100 04
    OBJECT IDENTIFIER (ИДЕНТИФИКАТОР ОБЪЕКТА) 00 0 00110 00000110 06
    NULL (ПУСТОЙ УКАЗАТЕЛЬ) 00 0 00101 00000101 05
    Последовательность, последовательность из 00 1 10000 00110000 30
    IPAddress (IP-адрес) 01 0 00000 01000000 40
    Counter (Счетчик) 01 0 00001 01000001 41
    Gauge (Шаблон) 01 0 00010 01000010 42
    TimeTicks (Сигналы времени) 01 0 00011 01000011 43
  • (рис 15.7) Формат длины
  • Значение. Поле кодирует значение данных в соответствии с правилами, определенными в правилах кодирования (например, ANSI).
    •

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

    Пример 1

    Рисунок 15.8. показывает, как определяется INTEGER 14:

    (рис 15.8) Пример 1 INTEGER 14

    Пример 2

    Рисунок 15.9. показывает, как определяется OCTET STRING "H1":

    (рис 15.9) Пример 2 OCTET STRING "H1"

    Пример 3

    Рисунок 15.10. показывает, как определяется OBJECT Identifier 1.3.6.1 (iso.dod.internet):

    (рис 15.10) Пример 3 ObjectIdentifier 1.3.6.1

    Пример 4

    Рисунок 15.11. показывает, как определить IPAddress 131.21.14.8:

    (рис 15.11) Пример 4 IPAdress 131.21.14.8

    MIB

    База управляющей информации (MIB2 — Management Information Base 2) – это второй компонент, используемый в сетевом управлении. Каждый агент имеет свой собственный MIB2, являющийся отображением всех объектов, которыми может управлять менеджер. Объекты в MIB2 разбиты по категориям на 10 групп: система (sys), интерфейс (if), адрес трансляции (at), ip, icmp, tcp, udp, egp, trans и snmp. Эти группы в адресе находятся после обозначения объекта MIB2 в дереве объектов идентификации ( Рисунок 15.12.).

    (рис 15.12) MIB-2

    Организация доступа MIB-переменных

    Чтобы показать доступность различных переменных, мы используем как пример udp-группы. Имеются четыре простых переменных в группах и одна последовательность записей (таблица). Рисунок 15.13. показывает переменные и таблицу.

    (рис 15.13) udp-группа

    Мы покажем, как иметь доступ к каждому объекту.

    Простая переменная

    Чтобы организовать доступ любой простой переменной, мы используем групповой id ( 1.3.6.1.2.1.7 ), сопровождаемый id переменной. Ниже показано, как организовать доступ к каждой переменной:

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

    Таблицы

    Чтобы идентифицировать таблицу, мы сначала используем id. Группа udp имеет только одну таблицу (с id 5), как это показано на рисунке 15.14.

    (рис 15.14) udp-переменные и таблицы

    Для организации таблицы мы должны использовать следующие адреса:

    Однако таблица в этом дереве не на уровне листа. Мы не можем иметь доступ к таблице, пока не определим вход (последовательность) в таблице (с id 1), как это показано ниже:

    Этот вход также не имеет листов, и нам он недоступен. Нам нужно определить каждый объект входа. Это две переменные в листе дерева. Хотя мы можем обратиться к их образцам, мы должны определить, какой именно образец нам нужен. В любой момент таблица может иметь несколько значений для каждой пары местный адрес / местный порт. Чтобы обратиться к определенному образцу (строке) таблицы, мы должны добавить индекс к вышеупомянутым id. В MIB индексы массивов — не целые числа (подобно большинству языков программирования). Индексы базируются на значении одной или более областей во входах. В нашем примере udpTable определяется местным адресом и номером местного порта. Например, рисунок 15.15. показывает таблицу с четырьмя строками и значениями для каждого поля. Индекс каждой строки — комбинация двух значений.

    (рис 15.15) Индексы для udpTable

    Чтобы обратиться к образцу местного адреса для первой строки, мы используем идентификатор, увеличенный на индекс образца:

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

    Лексикографическое упорядочение

    Одна интересная точка зрения о MIB-переменных — то, что идентификаторы объекта (включая идентификаторы образца) находятся в лексикографическом порядке. Таблицы упорядочиваются в соответствии правилам строки-столбца, и это означает, что нужно идти от столбца к столбцу, а в каждом столбце нужно идти от вершины до основания, как показано на рисунке 15.16.

    (рис 15.16) Лексикографическое упорядочение

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

    SNMP

    SNMP использует и SMI, и MIB в управлении сетью Интернет. Он – прикладная программа, которая позволяет быть:

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

    PDU

    SNMPv3 определяет восемь типов пакетов (или PDUs): GetRequest, GetNextRequest, GetBulkRequest, SetRequest, Response, Trap, InformRequest и Report ( Рис. 15.17.).

    (рис 15.17) SNMP PDUs

    GetRequest

    GetRequest PDU посылается от менеджера (клиента) к агенту (серверу), чтобы извлечь значение переменной или набора переменных.

    GetNextRequest

    GetNextRequest PDU посылают от менеджера к агенту, чтобы извлечь значение переменной. Найденное значение – это значение объекта, следующего после определенного в таблице Objectid в PDU. Этот запрос главным образом используется, чтобы извлечь значения входов в таблице. Если менеджер не знает индексов входов, он не может извлечь значения. Однако он может применить GetNextRequest и определить Objectid таблицы. Поскольку первый вход имеет Objectid непосредственно после Objectid таблицы, значение первого входа возвращается менеджеру. Менеджер может использовать этот Objectid, чтобы получить значение следующего, и так далее.

    GetBulkRequest

    GetBulkRequest PDU посылают от менеджера к агенту, чтобы извлечь большое количество данных. Он может применяться вместо кратного числа GetRequest и GetNextRequest PDUs.

    SetRequest

    SetRequest PDU посылают от менеджера к агенту, чтобы установить (сохранить) значение в переменной.

    Ответ (Response)

    Ответ PDU посылают от агента к менеджеру в ответ на GetRequest или GetNextRequest. Он содержит значение(я) переменной(ых), которую запрашивает менеджер.

    Ловушка (Trap)

    Ловушку (также ее называют ловушкой SNMPv2, чтобы отличить от ловушки SNMPvl) PDU посылают от агента к менеджеру, чтобы сообщить о событии. Например, если агент перезагружен, он информирует менеджера и сообщает время перезагрузки.

    InformRequest

    Inform Request PDU посылают от одного менеджера другому удаленному менеджеру, чтобы получить значение некоторых переменных от агентов, которые управляются удаленным менеджером. Удаленный менеджер отвечает Ответом PDU.

    PDU-рапорт (Report)

    PDU-рапорт разработан, чтобы сообщить о некоторых типах ошибок между менеджерами.

    Формат

    Формат для восьми SNMP PDUs показан на рисунке 15.18. GetBulkRequest PDU отличается от других PDU двумя областями, как показано на рисунке.

    (рис 15.18) Формат SNMP PDU

    Поля перечислены ниже.

  • PDU-тип (PDU type). Это поле определяет тип PDU (см. таблицу 15.4).
  • Запрос ID (Request ID). Это поле — порядковый номер, используется менеджером в запросе PDU и повторяется агентом в ответе. Он нужен, чтобы сравнить запрос и ответ.
  • Состояние ошибки (Error Status). Это целое число, которое используется только в ответе PDUs, чтобы показать типы ошибок, о которых сообщает агент. Его значение — 0 в запросе PDUs. Таблица 15.3. содержит список типов ошибок, которые могут произойти.
    Типы ошибок
    Состояние Название Значение
    0 noError Нет ошибки
    1 TooBig Слишком большой ответ для размещения в одном сообщении
    2 NoSuchName Переменная не существует
    3 BadValue Значение, которое должно быть сохранено, недопустимо
    4 readOnly Значение не может быть изменено
    5 genErr Другие ошибки
  • Не ретранслируемая (Non-repeaters). Это поле используется только в GetBulkRequest и удаляет ошибку поля состояния, которая является пустой в запросе PDUs.
  • Индекс ошибки (Error index). Индекс ошибки — смещение, которое говорит менеджеру, какая переменная вызвала ошибку.
  • Максимальное повторение (Max-repetition). Это поле также используется только в GetBulkRequest и заменяет поле индекса ошибки, которое является пустым в PDUs-запросе.
  • VarBindList. Это набор переменных с соответствующими значениями, которые менеджер хочет извлечь или установить. Значения являются нулевыми в GetRequest и GetNextRequest. В PDU-ловушке он показывает переменные и значения, связанные с определенным PDU.
    •

    Сообщения

    SNMP не посылает отдельные PDU, он включает PDU в сообщение. Сообщение в SNMPv3 состоит из четырех элементов: версия, заголовок, параметры защиты и данные (которые включает кодируемый PDU), как показано в рисунке 15.19.

    (рис 15.19) SNMP-сообщение

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

    Чтобы определять тип PDU, SNMP использует метку. Класс контекстно-зависим (10), формат структурирован (1), и числа — 0, 1, 2, 3, 5, 6, 7, 8 ( табл. 15.4.).

    Обратите внимание, что SNMPv 1 определяет A4 для "ловушки", которая на сегодняшний день является устаревшей.

    Коды для SNMP-сообщений
    Данные Класс Номер Полный тег (двоичный) Полный тег (шестнадцатеричный)
    GetRequest 10 1 00000 10100000 A0
    GetNextRequest 10 1 00001 10100001 A1
    Response 10 1 00010 10100010 A2
    SetRequest 10 1 00011 10100011 A3
    GetBulkRequest 10 1 00101 10100101 A5
    InformRequest 10 1 00110 10100110 A6
    Trap (SNMPv2) 10 00111 10100111 A7
    Report 10 1 01000 10101000 A8

    Пример 1

    В этом примере менеджер станции (SNMP-клиент) использует сообщение GetRequest, чтобы извлечь номер UDP-дейтаграммы, которую получил маршрутизатор.

    Есть только один объект VarBind (переменная – связка). Соответствующий MIB соотносит эту информацию, содержащуюся в udpInDatagram, с идентификатором объекта 1.3.6.1.2.1.7.1.0. Менеджер хочет извлечь значение. Рис.15.20. показывает в общем виде пакет с иерархической структурой. На рисунке используются белые и цветные участки для последовательностей и серые для PDU. OCTET STRING.

    (рис 15.20) Пример 1

    Список VarBind (см. рис.15.20.) имеет длину 0F (15) и состоит только из одной последовательности VarBind, длиной OD (13). В начале списка переменная указывает тип 06 и длину списка 09. Длина дальнейшего сообщения 00.). Сообщение GetRequest PDU имеет длину ID (29).

    Имеются три октета последовательностей: параметры безопасности, модель безопасности и флаги. Затем следуют два целых числа, которые определяют максимальный размер (1024) и ID сообщения (64). Есть заголовок длинной 12, который не показан (для простоты). Имеется одно целое число — версия (версия 3). Полностью сообщение составляет 52 байта.

    Рисунок 15.21. показывает реальное сообщение, посылаемое менеджером станции (клиентом) к агенту (серверу).

    (рис 15.21) GetRequest сообщение

    UDP-порты

    SNMP использует услуги UDP на двух заданных портах, 161 и 162. Заданный порт 161 задействован сервером (агентом), и заданный порт 162 отведен клиенту (менеджеру).

    Агент (сервер) производит пассивное открытие порта 161. Затем он ждет подключения от менеджера (клиента). Менеджер (клиент) производит активное открытие, используя кратковременный порт. Сообщение запроса посылается от клиента серверу, задействуя кратковременный порт как исходный порт и заданный порт 161 как порт пункта назначения. Сообщение ответа посылают от сервера к клиенту, использующему заданный порт 161 как исходный порт и кратковременный порт как порт пункта назначения.

    Менеджер (клиент) производит пассивное открытие порта 162. Затем он ждет подключения от агента (сервера). Агент (сервер) производит активное открытие, используя кратковременный порт, всякий раз, когда посылает сообщение-ловушку (Trap). Это подключение является только односторонним, от сервера к клиенту ( Рис.15.22.).

    (рис 15.22) Номер портов для SMNP

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

    Краткие итоги

  • Простой протокол управления сетью (SNMP) — структура для управления устройствами Интернета с использованием набора протоколов TCP/IP.
  • Менеджер, обычно хост, управляет и контролирует набор агентов, обычно маршрутизаторов.
  • Менеджер — хост, который выполняет SNMP-программу клиента.
  • Агент — маршрутизатор или главный компьютер, который выполняет SNMP-программу сервера.
  • SNMP освобождает задачи управления и от физических характеристик управляемых устройств, и от основной технологии организации сети.
  • SNMP использует услуги двух других протоколов: структура информации управления (SMI) и основы информации управления (MIB).
  • SMI определяет тип данных объектов имен, которые могут быть сохранены в объекте, и кодирует данные.
  • SMI-объекты называются согласно иерархической структуре дерева.
  • SMI типы данных определены согласно нотации абстрактного синтаксиса 1 (ASN.l).
  • SMI использует основные правила кодирования (BER), чтобы кодировать данные.
  • MIB — совокупность групп объектов, которые могут управляться SNMP.
    •

    Задачи и упражнения

  • Покажите кодирование для INTEGER 1456.
  • Покажите кодирование для OCTET STRING "Hello Grey".
  • Покажите кодирование для произвольного OCTET STRING длиною 1000.
  • Покажите, как кодируется следующая запись (последовательность):
    INTEGER OCTET STRING IP Адрес
    2345 "COMPUTER" 185.32.1.5
  • Покажите, как кодируется следующая запись (последовательность):
    Time Tick INTEGER Object Id
    12000 14564 1.3.6.1.2.1.7
  • Покажите, как кодируется следующий массив (последовательность из...):
    INTEGER OCTET STRING Счетчик
    2345 "COMPUTER" 345
    1123 "DISK" 1430
    3456 "MONITOR" 2313
  • Декодируйте следующие выражения:
  • 02 04 01 02 14 32;
  • 30 06 02 01 11 02 01 14 ;
  • 30 09 04 03 41 43 42 02 02 14 14 ;
  • 30 0A 40 04 23 51 62 71 02 14 12.
    •

    Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^