Архитектура протоколов для обмена управляющей информацией между менеджером и агентом 3 страница

- длина поля «Содержимое» (1347 байт)

- длина поля «Длина» (следующие 2 байта)

 

2.3.2.3 Содержимое данных (Content)

В этом поле записывается содержимое передаваемых данных ИЭ, тип и структура которых определены в предшествующем тэге.

Например, BER-кодирование значения INTEGER (ИЭ, значение которых выражено целым числом является всегда примитивным. Октеты содержимого могут состоять из одного или нескольких байт. Первой передается старшая цифра содержимого (целого числа).

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

Целое число со значением нуль кодируется одним октетом00.

Примеры BER-кодирования значений INTEGER представлены в таблице 9.

Таблица 9. Примеры BER-кодирования значений INTEGER

Значение целого (‘Dec)	BER-код (‘Hex)
	02 01 00 - значение поля «Содержимое» - целое число, равное 0. - длина поля «Содержимое» (1 байт)   - тэг, обозначающие, что в поле «Содержимое», передается целое число (код тэга – 00010 - INTEGER), простого типа (значение 6-го бита равно 0), а тэг относится к классу универсальный – UNI (биты 8 и 7 имеют значение 0)
	02 01 3b
	02 02 00 7f
	02 02 00 80
	02 02 01 00
	02 02 0D 8F
	02 03 06 86 D7
-128	02 01 80
-129	02 02 ff 7f

Информационный элемент NULL

Тип NULL обозначает нулевую величину, используемую в качестве параметра алгоритмов.

Кодирование для типа NULL является всегда примитивным, октеты содержимого пусты. BER-представление значения NULL может иметь одну из приведенных ниже форм (зависит от используемого представления октетов длины).

Краткая форма)

Полная форма, т.е. T-L-V)

Кодирование октетов конца содержимого.

Октеты конца содержимого (End-of-contents - EOC), кодируются универсальным тэгом, имеют простой тип, код тэга 00000, длину 0 байт, а содержимое - отсутствует:

Тэг Длина Содержимое

Отсутствует

Другие примеры кодирования поля «Содержимое»:

Строки бит (Bitstring type) передаются в том виде как они есть, однако, есть проблема в том, что поле длины указывает длину в байтах, а не в битах. Поэтому первый байт поля данных будет указывать сколько бит последнего байта не используется.

Например, если необходимо передать строку бит: 0 1001 1111 (длиной 9 бит), то после BER-кодирования, передаваемая последовательность выглядит так:

· 00 0 00011 – тэг, определяет – класс – UNI, простой тип, строка бит

· 00000011 – поле длины (содержимое в 3 байта для передачи 9-ти бит!)

· 00000111 – первый байт содержимого указывает, что в последнем байте не используется 7 бит.

· 01001111 – первый байт данных (8 бит).

· 10000000 – еще один бит данных – остаток строки бит (семь последних бит не используется!),

Таким образом, вместо передачи девяти бит 0 1001 1111, при BER-кодировании будет передана последовательность из пяти байт (40 бит!) – 03 03 07 4F 80 ’Hex!

Строки символов IA5

Тип IA5_String представляет любые последовательности IA5-символов (международный алфавит IA5 - эквивалентен ASCII). Длина строки может быть любой, включая нуль.

Этот тип используется для адресов электронной почты и неструктурированных имен.

BER-кодирование величины IA5_String может быть примитивным или структурированным. При примитивном кодировании октеты содержимого представляют собой символы IA5 в ASCII-кодах.

 

Рассмотрим примеры представления значения IA5-строки “[email protected]”.

 

Короткая форма октетов длины	c e n t @ n e i c. n s k. s u 12 1163 65 6e 74 40 6e 65 69 63 2e 6e 73 6b 2e 73 75 T L V
Длинная форма октетов длины	c e n t @ n e i c. n s k. s u 12 81 1163 65 6e 74 40 6e 65 69 63 2e 6e 73 6b 2e 73 75 T L V

 

Среди приведенных в табл. 5 различных типов данных информационных элементов, особое место занимает тип данных под названием «Идентификатор объекта», широко используемый для обозначения управляемых объектов.

BER-кодирование этого типа данных значительно отличается от других типов данных и для его понимания необходимо рассмотреть некоторые аспекты, посвященные структуре управляющей информации (раздел 2.3.3.) и базам данных управляющей информации (MIB – раздел 2.3.4).

Рассмотрим более подробно этот тип данных.

Идентификатор объекта (OID).

 

Тип OBJECT IDENTIFIER – OID используется для идентификации содержимого таких информационных элементов (ИЭ), как:

· алгоритмов в X.509,

· атрибутов Directory Information Base (DIB) в протоколах DAP (X.501), LDAP

· управляемых объектов в MIB и др.

BER-кодирование OBJECT IDENTIFIER является всегда примитивным.

Значения OBJECT IDENTIFIER присваиваются при регистрации информационного элемента соответствующей организацией.

Рассмотрим использование OBJECT IDENTIFIER – OID в системах управления для обозначения управляемых объектов в MIB.

В этом случае OID кодируется последовательностью целых чисел, указывающих путь к ИЭ в MIB.

Правила кодирования идентификаторов объектов будут рассмотрены в разделе 2.3.3 – структура управляющей информации.

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

 

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

В рекомендациях ITU-T X.208…X.209 стандартизована вершина глобального дерева (дерево наследования), представленная на рис. 13. Все информационные элементы (объекты управления) в ветвях дерева имеют свой номер, согласно регистрации этого объекта в рамках соответствующей организации.

 

Рисунок 13 – Дерево объектов MIT

 

Система организации объектов MIT аналогична системе доменных имен, являющимися объектами для другой известной базы данных – таблице доменных имен – DNS.

При кодировании ИЭ, относящихся к вершине дерева MIT есть исключение.

Например, чтобы указать путь к объекту – MIB (дерево iso.dod.internet.mgmt, см. рис. 13), вершина MIT записывается в виде последовательности следующих целых чисел, разделенных точкой (подчеркнута вершина MIT):

1.3. 6.1.2.1 – числовая форма идентификатора объекта в дереве MIT.

Поскольку заранее известно, что первое число в вершине дерева (x) всегда равно 0 (itu-t), 1 (iso) или 2 (joint-iso-itu), а второе число (y) меньше 40, то при передаче Идентификатора объекта можно уменьшить количество передаваемой информации, если первые два числа, идентифицирующие вершину дерева MIT, закодировать одним байтом.

Например, для объекта iso.org (x=1.y=3) в вершине дерева сокращенная форма записи выглядит в виде:

40 х + у = 40*1 + 3 =43'Dec или 2В 'Hex.

 

Остальные числа могут быть больше 256, поэтому Идентификатор объекта, находящегося ниже, например, объект MIB (iso.org.dod.internet.mgmt.mib, или в числовой нотации 1.3.6.1.2.1) будет передан следующей последовательностью октетов:

T L V

06 05 2b 06 01 02 01

- значение OID (путь к объекту MIB)

- длина содержимого (число байт в OID)

- тэг, указывающий, что следующие за ним байты кодируют длину и содержимое ИЭ, имеющегт тип – OID.

 

В таблице 10 представлены некоторые OID и их значения.

Таблица 10 – Некоторые OID и их значения

Величина OID	Назначение OID
{ 0 0 }	Стандарты ITU-T
{ 1 0 }	Стандарты ISO
{ 1 3 6 }	iso.org.dod – департамент обороны США
{ 1 3 6 1 }	iso.org.dod.internet – объекты сети Интернет
{ 1 2 840 }	iso.member-body. ANSI (US)
{ 2 5 }	Служба каталогов (X.500)
{ 2 5 8 }	Служба каталогов - алгоритмы

2.3.4 Базы данных управляющей информации – MIB

 

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

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

К сожалению, для таких крупных сетевых элементов ТфОП как АТС не существует открытых MIB, что в значительной степени затрудняет посторенние централизованной автоматизированной системы управления ТфОП.

В данной работе мы будем рассматривать детализацию управляемых объектов для сети Интернет.

Существует несколько версий MIB, используемых производителями оборудования и ПО для сетей Интернет и локальных сетей. Приведем некоторые примеры MIB:

1. MIB I (так называемая Internet MIB - RFC 1065, 1066, 1155, 1156, 1157, 1158 и др.) – база данных, определяющая основные имена в дереве MIT, группы Интернет-объектов (ARP, IP. TCP, UDP и т.п.). Обязательна для любого оборудования, обслуживающего сетевые объекты в Интернете. Обеспечивает диагностику ошибок, и конфигурацию различных устройств, оснащенных агентом с MIB-I. Включает в себя около 170 объектов.

2. MIB II (RFC-1213 и др.). Расширяет и детализирует отдельные группы объектов.

3. RMON-1 MIB (RFC 1757). Для управления удаленными объетами вводятся 10 новых групп объектов (см. ниже).

4. RMON-II MIB (RFC 2819). Расширяет количество объектов в приведенных выше группах.

 

В приведенных MIB постепенно были определены следующие элементы дерева MIT-Internet:

 

1. Путь к корню глобального дерева iso.org.dod:

internet OBJECT IDENTIFIER::= { iso(1) org(3) dod(6) 1 }

 

2. Основные имена в локальном дереве Internet:

directory OBJECT IDENTIFIER::= { internet 1 }

mgmt OBJECT IDENTIFIER::= { internet 2 }

experimental OBJECT IDENTIFIER::= { internet 3 }

private OBJECT IDENTIFIER::= { internet 4 }

 

3. Для ветви mgmt.mib (2.1.) определены десять групп объектов, корневые имена (алиасы) которых следующие:

system OBJECT IDENTIFIER::= { mib-2 1 }

interfaces OBJECT IDENTIFIER::= { mib-2 2 }

at OBJECT IDENTIFIER::= { mib-2 3 }

ip OBJECT IDENTIFIER::= { mib-2 4 }

icmp OBJECT IDENTIFIER::= { mib-2 5 }

tcp OBJECT IDENTIFIER::= { mib-2 6 }

udp OBJECT IDENTIFIER::= { mib-2 7 }

egp OBJECT IDENTIFIER::= { mib-2 8 }

transmission OBJECT IDENTIFIER::= { mib-2 10 }

snmp OBJECT IDENTIFIER::= { mib-2 11 }

 

Поясним назначение корневых имен поддерева MIB-II:

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

2. Interfaces - содержит 23 объекта, необходимых для ведения статистики сетевых интерфейсов агентов (количество интерфейсов, размер MTU, скорость передачи, физические адреса и т.д.) – именно эту ветвь дерева MIB предстоит в основном исследовать в данной работе с помощью протокола SNMP.

3. AT (3 объекта) - отвечают за трансляцию адресов (Address Translation). Была включена в MIB I. Сейчас почти не используется. Примером использования объектов AT может послужить простая ARP таблица соответствия физических (MAC) адресов сетевых карт IP адресам хостов.

4. IP (42 объекта) - данные о проходящих IP пакетах (количество запросов, ответов, отброшенных пакетов).

5. ICMP (26 объектов) – информация о контрольных сообщениях (входящие/исходящие сообщения, ошибки и т.д.).

6. TCP (19 объектов) - все, что касается одноименного транспортного протокола (алгоритмы, константы, соединения, открытые порты и т.п.).

7. UDP (6 объектов) - аналогично, только для UDP протокола (входящие/исходящие датаграммы, порты, ошибки).

8. EGP (20 объектов) - данные о трафике Exterior Gateway Protocol (используется маршрутизаторами, объекты хранят информацию о принятых/отосланных/отброшенных кардах).

9. Transmission - зарезервирована для специфических MIB.

10. SNMP (29 объектов) - статистика по SNMP - входящие/исходящие пакеты, ограничения пакетов по размеру, ошибки, данные об обработанных запросах и многое другое.

 

Каждый из этих объектов представлен в MIB в виде дерева, растущего вниз. Каждый элемент этого дерева (объект управления) однозначно идентифицируется в этом дереве в форме символьной (iso.org.dod ….) или цифро-точечной (1.3.6 …).

Например:

· к адресу администратора мы можем обратиться посредством такого пути: system.syscontact.0,

· ко времени работы системы system.sysUpTime.0,

· к описанию системы (версия, ядро и другая информация об ОС): system.sysDescr.0

С другой стороны те же данные могут задаваться и в цифро-точечной нотации.

Так system.sysUpTime.0 соответствует значение 1.3.0, так как system имеет индекс "1" в группах MIB II, а sysUpTime - 3 в иерархии группы system.

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

В RMON-1 MIB (RFC 1757) объекты управления на удаленном оборудовании разделены на следующие группы объектов:

ethernet statistics, history control, ethernet history, alarm, host, hostTopN, matrix filter, packet capture, event.

В приложении 2 приводится полный список объектов MIB II (RFC 1213) из группы if (interface), необходимый для расшифровки сообщений протокола SNMP в данной работе.

2.3.5 Представление SNMP-сообщений

 

Типы данных, используемые в сообщениях протокола SNMP

 

Выше были приведены основные типы данных, используемые для описания объектов (информационных элементов) в нотации ASN.1 (см. п.2.3.1 и табл.5).

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

 

Простые типы данных (Primitive Types) из класса UNI (00):

· INTEGER - (тэг 02’Hex),

· OCTET STRING - (тэг 04’Hex),

· NULL - (тэг 05’Hex).

· OBJECT IDENTIFIER - (тэг 06’Hex),

· Enumerated INTEGER (кроме 0) - (тэг 0a’Hex)

 

Составные типы данных (Constructor Types) из класса UNI (00):

· SEQUENCE – упорядоченная последовательность (список) из одного или более ИЭ, относящихся к различным типам данных - (тэг 30’Hex)

· SEQUENCE OF – одномерный массив (таблица) ИЭ одного типа данных - (тэг 30’Hex)

 

Помимо этого (в дополнение к ASN.1), в SNMP определены следующие типы данных (Defined Types), относящиеся к прикладному классу application-wide (01):

· NetworkAddress  - Этот тип данных представляет выбор (Choice) из сетевых адресов одного или нескольких семейств протоколов (например X.25, IP, CCS-7 и т.д.). На данный момент определен один класс сетевых адресов – это IpAddress. Этот ИЭ определен тэгом прикладного класса (app или 01) и представляет IP-адрес длиной 32 бита (т.е. IPv4). Адрес представлен как СТРОКА из 4-х ОКТЕТОВ (OCTET STRING). При BER-кодировании адреса используется только примитивная форма. Тэг для ИЭ, характеризующего IP-адрес определен как 01 0 00000’bin или 40’hex.

· Counter (счетчик) - Этот тип данных представляет неотрицательное целое число, которое монотонно увеличивается, пока не достигает максимального значения, после чего обнуляется и начинает увеличиваться снова с ноля. Максимальное значение счетчика определено как 2³²-1 (4294967295’dec). При BER-кодировании этого ИЭ используется только примитивная форма. Тэг для ИЭ, характеризующего Counter определен как 01 0 00001’bin или 41’hex.

· Gauge (размер, величина) - Этот тип данных представляет неотрицательное целое число, которое может увеличиться или уменьшиться, но фиксируется в максимальном значении. Максимальное значение счетчика определено как 2³²-1 (4294967295’dec). При BER-кодировании этого ИЭ используется только примитивная форма. Тэг для ИЭ, характеризующего Gauge определен как 01 0 00010’bin или 42’hex

· TimeTicks (временная метка) - Этот тип данных представляет неотрицательное целое число, которое обозначает время в сотых долях секунды начиная с некоторого события. При BER-кодировании этого ИЭ используется только примитивная форма. Тэг для ИЭ, характеризующего TimeTicks определен как 01 0 00011’bin или 43’hex

· Opaque (Непрозрачный, мутный) - Этот тип ИЭ поддерживает способность передавать произвольный ASN.1 синтаксис (например, зашифрованные данные). Значение кодируется, используя ASN.1 и BER как строка октетов (OCTET STRING). Тэг для ИЭ, характеризующего Opaque определен как 01000100’bin или 44’hex. Для расшифровки типа данных Opaque обе взаимодействующие стороны должны поддерживать соответствующий синтаксис.

 

Приведем вышеописанные типы данных, используемые в протоколе SNMP, а также в соответствующих MIB при описании ИЭ, в форме таблицы:

Таблица 11 – Типы данных ИЭ, используемые в протоколе SNMP и MIB

n/n	Тип данных	Тэг
‘hex	‘bin
Простые типы данных (primitive)
	INTEGER		00 00 0010
	OCTET STRING		00 00 0100
	NULL		00 00 0101
	OBJECT IDENTIFIER (OID)		00 00 0110
	Enumerated INTEGER	0a	00 00 1010
	IpAddress		01 00 0000
	Counter		01 00 0001
	Gauge		01 00 0010
	TimeTicks		01 00 0011
	Opaque		01 00 0100
Составные типы данных (constructor)
	SEQUENCE		00 11 0000
	SEQUENCE OF		00 11 0000
	Сообщения протокола
	Get	a0	10 10 0000
	Get-Next	a1	10 10 0001
	Response	a2	10 10 0010
	Set	a3	10 10 0011
	Trap	a4	10 10 0100

 

Порядок передачи элементов сообщений протокола SNMP

Правила кодирования (BER – Х.209) задают структуру тэга для каждого ИЭ. Рассмотрим подробнее эти поля:

SNMP-сообщение				Структура ИЭ, входящих в SNMP-сообщение
ИЭ 1			T	TAG
ИЭ 2
Информационный элемент (ИЭ i)
L	Длина (Length)
V	Значение (Value, Content)
…
ИЭ n

 

Рисунок 13 – Структура SNMP-сообщения и входящих в него ИЭ

 

В SNMP-PDU принят следующий порядок передачи:

 

 

Рисунок 14 – Порядок передачи бит и байт в сообщениях SNMP

 

Например, в SNMP-последовательности 30 81 fb 02 01 00 04 06 …, представленной ниже в таблице в двоичном коде, первым будет передавться байт 30, затем 81, затем fb, затем 02 и т.д.

Внутри каждого байта сначала передается младший бит (1-й), в данном случае это 0, затем 2-й (0), затем 3-й (0), затем 4-й (0), затем пятый (1) и т.д.

 

Основные понятия протокола SNMP в нотации ASN.1

Используя вышеприведенные сведения об языке ASN.1, сообщениях протокола SNMP и типах данных, представим основные сведения о протоколе SNMP в форме нотации ASN.1.

1. Общий формат сообщения SNMP в нотации ASN.1 выглядит следующим образом:

RFC1157- SNMP DEFINITIONS::= BEGIN

SNMP-Message::=

SEQUENCE {

version

INTEGER {

version-1 (0)

},

community

OCTET STRING,

SNMP-PDUs

ANY

}

2. Область данных протокола SNMP может содержать пять различных типов протокольных блоков данных (PDU), соответствующих пяти командам протокола SNMP:

SNMP-PDUs ::=

CHOICE {

get-request

GetRequest-PDU,

get-next-request

GetNextRequest-PDU,

get-response

GetResponse-PDU,

set-request

SetRequest-PDU,

trap

Trap-PDU,

}

3. Для каждого типа PDU имеется определение его формата. Например, формат блока GetRequest-PDU описан следующим образом:

GetRequest-PDU::=

IMPLICIT SEQUENCE {

request-id

RequestID,

error-status

ErrorStatus,

error-index

Errorlndex,

variable-bindings

VarBindList

}

 

 

4. Определение элементов в общей конструкции PDU-SNMP

 

Далее для каждого формата следуют определения элементов PDU. Например, для запросов и ответов определены следующие элементы и соответствующие типы данных:

 

-- request/response information

 

RequestID::=

INTEGER

ErrorStatus::=

INTEGER {

noError(0),

tooBig(1),

noSuchName(2),

badValue(3),

readOnly(4)

genErr(5)

}

ErrorIndex::=

INTEGER

-- variable bindings

VarBind::=

SEQUENCE {

name

ObjectName,

value

ObjectSyntax

}

VarBindList::=

SEQUENCE OF

VarBind

4.1 The GetRequest-PDU

GetRequest-PDU::=

[0]

IMPLICIT SEQUENCE {

request-id

RequestID,

error-status -- always 0

ErrorStatus,

error-index -- always 0

ErrorIndex,

variable-bindings

VarBindList

}

4.2. The GetNextRequest-PDU

GetNextRequest-PDU::=

[1]

IMPLICIT SEQUENCE {

request-id

RequestID,

error-status -- always 0