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

Аналогично определяем и заполняем таблицу для второго сообщения!


3.2.4. Поля протокола SNMP

Наконец, мы добрались до расшифровки самого SNMP-сообщения. Чтобы разобрать отдельные его составляющие, приведем все поля, относящиеся к протоколу SNMP отдельно.

Итак, фрагмент SNMP-сообщения, вложенного в информационную часть протоколов UDP/IP/Ethernet выглядит так:

30 81 fb 02 01 00

0030: 04 06 76 6d 31 35 2d 31a0 81 ed 020435 97 ac

0040: 550201000201003081de300c06 08 2b 06

0050: 01 02 01 01 03 00 05 00300e060a 2b 06 01 02

0060: 01020201 05010500 30 0e 060a2b 06 01 02

0070: 01 02 02 01 08 01 05 00 30 0e 06 0a 2b 06 01 02

0080: 01 02 02 01 09 01 05 00 30 0e 06 0a 2b 06 01 02

0090: 01 02 02 01 0a 01 05 00 30 0e 06 0a 2b 06 01 02

00a0: 01 02 02 01 0b 01 05 00 30 0e 06 0a 2b 06 01 02

00b0: 01 02 02 01 0c 01 05 00 30 0e 06 0a 2b 06 01 02

00c0: 01 02 02 01 0d 01 05 00 30 0e 06 0a 2b 06 01 02

00d0: 01 02 02 01 0e 01 05 00 30 0e 06 0a 2b 06 01 02

00e0: 01 02 02 01 10 01 05 00 30 0e 06 0a 2b 06 01 02

00f0: 01 02 02 01 11 01 05 00 30 0e 06 0a 2b 06 01 02

0100: 01 02 02 01 12 01 05 00 30 0e 06 0a 2b 06 01 02

0110: 01 02 02 01 13 01 05 00 30 0e 06 0a 2b 06 01 02

0120: 01 02 02 01 14 01 05 00

Для упрощения расшифровки данного сообщения, разобъем это сообщение на отдельные составляющие в соответствии с форматом, приведенным в разделе 2.2 и на рис. 7, 8 и 9, а также в соответствии с правилами кодирования SNMP-сообщений:

3081 fb

040676 6d 31 35 2d 31

a081 ed

020435 97 ac 55

020100

020100

3081de

300c06 08 2b 06 01 02 01 01 03 00 05 00

300e06 0a 2b 06 01 02 01 02 02 01 05 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 08 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 09 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0a 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0b 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0c 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0d 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0e 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 10 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 11 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 12 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 13 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 14 01 05 00


Учитывая рекомендации, приведенные в разделе 2.3, применим к данному формату конструкцию T-L-V, чтобы расшифровать отдельные ИЭ сообщения SNMP:

Конструкция – T-L-V (Tag-Length-Value)

3081 fb

T L (……… V ……

020100

T L V

040676 6d 31 35 2d 31

T L V

a081 ed

T L (……… V ……

020435 97 ac 55

T L V

020100

T L V

020100

T L V

3081 de

T L (……… V ……

300c06 08 2b 06 01 02 01 01 03 00 05 00

T L (T L ( V=OID ))

Остальные части кодируются аналогично:

300e06 0a 2b 06 01 02 01 02 02 01 05 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 08 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 09 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0a 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0b 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0c 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0d 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 0e 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 10 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 11 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 12 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 13 01 05 00

300e06 0a 2b 06 01 02 01 02 02 01 14 01 05 00

Учитываем, что ИЭ, кодируемые тэгом=30 или a0, содержащим в 6-м бите единицу, имеют составной тип, следовательно, внутри этих элементов содержатся другие ИЭ по принципу матрешки.

Расшифруем теперь отдельные части SNMP-сообщения:

3081 fb

T L (……… V ……

– Заголовок протокола SNMP (флаг), содержащий тэг (30 - Sequence) и длину содержимого (81 fb – длинный формат, обозначающий, что в поле «Длина» содержится 1 байт, а его значение – fb’hex или 251 байт)

020100

T L V

– Версия протокола SNMP (Тэг=02, что означает целое число в поле «содержимое», длина этого содержимого равна 1 байту, а 00 в поле содержимое – означает, что используется версия SNMPv1)

040676 6d 31 35 2d 31

T L V

– поле “Community” длиной 6 байт, в котором содержится строка октетов (тэг=04), кодирующих содержимое в формате IA5.

В данном случае поля 76 6d 31 35 2d 31’hex означают, что пароль доступа к полю “Community” – vm15-1

a081 ed

T L (……… V ……

– имя PDU-SNMP. В данном случае – это Get-request (тэг=a0), а длина содержимого в этом PDU составляет ed’hex или 237’dec байт

Далее, учитывая, что имя данного PDU – Get, используем его формат (см. рис. 7 и 8 в разделе 2.2, а также форму записи на языке ASN.1 в разделе 2.3.5.3 для заголовка Get-PDU):

Заголовок SNMP Заголовок PDU (для Get, GetNext, Set, Response) Переменные (Идентификаторы объектов в MIB, значения параметров)
Версия Пароль (Community) Тип PDU Идентификатор PDU Статус ошибки Индекс ошибки Имя (Tag) Длина (L) Значение (Value)
Vers – 1 По умолчанию: public См. табл.1 Целое значение от 0 до 232-1 См. табл.2 См. ниже *** **** Имя (Tag) Длина (L)
T L V T L V T L V T L V T L V T L V T L T L V
                                             

Или в форме ASN.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

}

020435 97 ac 55

T L V

– идентификатор данного запроса (request-id). Используется для того, чтобы связывать запросы и ответы на них в пары. В данном случае длина этого идентификатора равна 4 байтам, а так как поле содержимого кодируется целым числом (тэг=02’hex, что означает INTEGER), то значение идентификатора будет 35 97 ac 55’hex или 899132501’dec

020100

T L V

– статус ошибки (error-status). Как указано выше, для запросов это значение всегда=0 (always 0)

020100

T L V

– индекс ошибки (error-index). Также как и для статуса, как указано выше, в запросах это значение всегда=0 (always 0)

3081 de

T L (……… V ……

– Тэг=30 (Sequence), означает, что далее идет составной тип данных (последовательность) длиной de’hex или 222’dec байт. В данном случае, в соответствии с форматом Get-PDU – это последовательность переменных (variable-bindings).

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

300c06 08 2b 06 01 02 01 01 03 00 05 00

T L (T L ( V=OID ))

Как видно, что первая переменная представляет собой также последовательность (тэг=30, следовательно, тип ИЭ - составной).

Выделим элементы этой последовательности:

300c– последовательность переменных общей длиной 0c’hex или 12 байт

T L (… V …

06 08 2b 06 01 02 01 01 03 00 05 00– или более детально:

(T L ( V=OID ), T L )

06 08

(T L

– Тэг=06, следовательно, 1-я переменная в этой последовательности – это идентификатор объекта – OID, длиной 8 байт

2b 06 01 02 01 01 03 00

( V=OID ),

- содержимое первой переменной (OID), которое в цифро-точечной нотации означает 1.3.6.1.2.1.1.3.0, что означает – менеджер запрашивает значение переменной, находящейся в базе данных (MIB) по пути (см. п.2.3.4):

iso.org.dod.internet.mgmt.mib.sys

1 . 3 . 6 . 1 . 2 . 1 . 1

(напомним, что 2b=1.3 – вершина дерева iso.org)

По этому пути для объектов группы system находится запрашиваемая переменная – sysUpTime (OID=3 в иерархии группы объектов system) – время с момента последней перезагрузки объекта.

Итак, в запросе Get, менеджер спрашивает: сколько времени прошло с момента последней перезагрузки объекта, что выглядит так:

iso.org.dod.internet.mgmt.mib.sys.sysUpTime.0

1 . 3 . 6 . 1 . 2 . 1 . 1 . 3 .0

2b 06 01 02 01 01 03 00

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

05 00

T L )

- Вторая переменная в данной последовательности, означает NULL (тэг=05), что в данном случае означает алгоритмический 0, т.е. окончание первой переменной.

Аналогично расшифруем остальные переменные в сообщении №1.

300e06 0a 2b 06 01 02 01 02 02 01 05 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 08 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 09 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 0a 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 0b 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 0c 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 0d 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 0e 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 10 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 11 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 12 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 13 0105 00

300e06 0a 2b 06 01 02 01 02 02 01 14 0105 00

Во-первых, отметим, что все оставшиеся ИЭ имеют одинаковую длину (0e’hex или 14 байт) и представляют собой последовательности (тэг=30), каждая из которых содержит по две переменные:

· идентификатор объекта (OID – тэг=06, длина 0a’hex или по 10 байт) и

· алгоритмический конец переменной, обозначенный как NULL (тэг=05, длина=00, а содержимое - отсутствует).

Во-вторых, отметим, что все объекты, идентификаторы которых указаны в данном запросе – находятся по одному пути:

2b 06 01 02 01 02 02 01, который означает:

iso.org.dod.internet.mgmt.mib.if.ifTable.ifEntry, или

1 . 3 . 6 . 1 . 2 . 1 .2 . 2 . 1

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

Итак, группа объектов if , принадлежащая ветви MIB

iso.org.dod.internet.mgmt.mib.if

1 . 3 . 6 . 1 . 2 . 1 .2,

содержит 22 элемента (объекта управления), находящихся в подветви if.ifTable.ifEntry (или 2.2.1).


Более детальное описание этих объектов см. в приложении 2, а также в документе RFC-1213, здесь же кратко приводятся идентификаторы этих объектов:

Объекты if ::= { interfaces 2 } (RFC-1213)

ifTable OBJECT-TYPE ::= { interfaces 2 }

ifEntry OBJECT-TYPE ::= { ifTable 1 }

IfEntry ::= SEQUENCE {

ifIndex ::= { ifEntry 1 }

ifDescr ::= { ifEntry 2 }

ifType ::= { ifEntry 3 }

ifMtu ::= { ifEntry 4 }

ifSpeed ::= { ifEntry 5 }

ifPhysAddress ::= { ifEntry 6 }

ifAdminStatus ::= { ifEntry 7 }

ifOperStatus ::= { ifEntry 8 }

ifLastChange ::= { ifEntry 9 }

ifInOctets ::= { ifEntry 10 }

ifInUcastPkts ::= { ifEntry 11 }

ifInNUcastPkts ::= { ifEntry 12 }

ifInDiscards ::= { ifEntry 13 }

ifInErrors ::= { ifEntry 14 }

ifInUnknownProtos ::= { ifEntry 15 }

ifOutOctets ::= { ifEntry 16 }

ifOutUcastPkts ::= { ifEntry 17 }

ifOutNUcastPkts ::= { ifEntry 18 }

ifOutDiscards ::= { ifEntry 19 }

ifOutErrors ::= { ifEntry 20 }

ifOutQLen ::= { ifEntry 21 }

ifSpecific ::= { ifEntry 22 }

}

Теперь, обращаясь к трассировке сообщения №1, видим, что из 22-х возможных объектов, менеджера в нашем запросе интересуют следующие объекты (их идентификаторы приведены в конце пути 2b 06 01 02 01 02 02 01):

05 01 - ifSpeed ::= { ifEntry 5 }

08 01 - ifOperStatus ::= { ifEntry 8 }

09 01 - ifLastChange::= { ifEntry 9 }

0a 01 - ifInOctets ::= { ifEntry 10 }

0b 01 - ifInUcastPkts ::= { ifEntry 11 }

0c 01 - ifInNUcastPkts ::= { ifEntry 12 }

0d 01 - ifInDiscards ::= { ifEntry 13 }

0e 01 - ifInErrors ::= { ifEntry 14 }

10 01 - ifOutOctets ::= { ifEntry 16 }

11 01 - ifOutUcastPkts ::= { ifEntry 17 }

12 01 - ifOutNUcastPkts ::= { ifEntry 18 }

13 01 - ifOutDiscards ::= { ifEntry 19 }

14 01 - ifOutErrors ::= { ifEntry 20 }

Единица (01’hex) в конце пути указывает на то, что запрашивается элемент массива из база данных.

В контрольной работе необходимо также привести текстовое описание каждого из запрашиваемых объектов.

ВНИМАНИЕ:

В приложении 2 и в документе RFC-1213 это описание приводится на английском языке. В ответах, помещаемых по прилагаемым в контрольной работе формам, необходимо это описание приводить на русском языке!

Ответим на оставшиеся вопросы по сообщению №1 и впишем эти ответы в прилагаемые формы.

Определить из приведенных сообщений:

1. Фирму-поставщика оборудования сетевых интерфейсов

2. MAC-адреса источника и назначения

3. Тип протокола, обслуживаемого данным Ethernet-кадром

4. Версию протокола сетевого уровня

5. Приоритет сетевого уровня для данной дейтаграммы

6. Длину пакета сетевого уровня (в байтах)

7. Время жизни данной дейтаграммы

8. Протокол транспортного уровня (Dec’код и название)

9. Сетевой адрес отправителя

10. Сетевой адрес назначения

11. Транспортный порт отправителя

12. Транспортный порт получателя

13. Тип и версию протокола прикладного уровня

14. Длину дейтаграммы транспортного уровня (в байтах)

15. Тип и класс тэга протокола прикладного уровня

16. Длину сообщения протокола прикладного уровня

17. Длину и содержимое поля Community

18. Тип PDU и его длину (в байтах)

18.1. Для PDU типа Get-Request

18.1.1. Значение идентификатора запроса -RequestID

18.1.2. Значения полей ErrorStatus и Errorlndex

18.1.3. Длину поля, содержащего набор запрашиваемых характеристик

18.1.4. Перечень запрашиваемых характеристик (атрибутов) управляемого объекта*

18.2. Для PDU типа GetResponse

18.2.1. Значение идентификатора запроса –RequestID

18.2.2. Значения полей ErrorStatus и Errorlndex

18.2.3. Длину поля, содержащего набор характеристик управляемого объекта

18.2.4. Перечень характеристик (атрибутов) управляемого объекта*

18.2.5. Значения характеристик (атрибутов) управляемого объекта*


№ вопроса Для PDU типа Get-Request
  Hex’ значение Dec’ или текстовое значение
00 00 1d 00 20 af – Сетевой интерфейс фирмы Cabletron – Сетевой интерфейс фирмы 3COM  
00 00 1d 90 58 20 00 20 af e8 e2 8e MAC-адрес назначения MAC-адрес источника
08 00 протокол IPv4
4-я версия
000 – низкий приоритет
01 1a 282 байта
TTL=64 транзита
17 – UDP протокол
d4 a4 00 66 212.164.00.102
d4 a4 c4 f6 212.164.196.246
c0 7c 49351 - DP
00 a1 161 - SNMP
00 a1 161 - SNMP
01 06 262 байта
Класс UNI, тип составной, последовательность (Sequence)
81 fb fb’hex или 251 байт
06 76 6d 31 35 2d 31 Поле “Community” длиной 6 байт, содержимое: vm15-1
a0 81 ed – имя PDU-SNMP. В данном случае – это Get-request (тэг=a0). Длина содержимого в этом PDU составляет ed’hex или 237’dec байт
18.1.1 35 97 ac 55 899132501’dec
18.1.2 Оба поля имеют значение 00
18.1.3 81 de 222’dec байт – длина поля переменных

Для Get-Request (вопрос18.1.4):

  Наименование атрибута (OID) Значение атрибута (характеристики)
Hex’ 2b 06 01 02 01 01 03 00 Краткое описание объекта sysUpTime на русском языке (см. приложение 2 и RFC-1213) Перевести на русский «The time (in hundredths of a second) since the network management portion of the system was last re-initialized»
Dec’ 1.3.6.1.2.1.1.3.0
Текст iso.org.dod.internet.mgmt.mib.sys.sysUpTime.0
Hex’ 2b 06 01 02 01 02 02 01 05 01 Краткое описание объекта ifSpeed на русском языке (см. приложение 2 и RFC-1213)
Dec’ 1.3.6.1.2.1.2.2.1.5.1
Текст ifSpeed
Hex’ 2b 06 01 02 01 02 02 01 08 01 Краткое описание объекта ifOperStatus на русском языке (см. приложение 2 и RFC-1213)
Dec’ 1.3.6.1.2.1.2.2.1.8.1
Текст ifOperStatus
Hex’ 2b 06 01 02 01 02 02 01 09 01 Краткое описание объекта ifLastChange на русском языке (см. приложение 2 и RFC-1213)
Dec’ 1.3.6.1.2.1.2.2.1.9.1
Текст ifLastChange
Hex’ 2b 06 01 02 01 02 02 01 0a 01   -//-//-//-
Dec’ 1.3.6.1.2.1.2.2.1.10.1
Текст ifInOctets
  … и т.д. (т.е. заполнить всю форму)

Расшифруем теперь сообщение №2

2. Сообщение №2

Af e8 e2 8e 00 00 1d 7c 63 f1 08 00 45 00

C bf 00 00 3e 11 70 56 d4 a4 c4 f1 d4 a4

A1 c0 7a 01 23 7b 84 30 82 01 17 02 01

D 31 a2 82 01 09 02 04 35 97

Ac 59 02 01 00 02 01 00 30 81 fa 30 0f 06 08 2b

D4 70 30 11 06 0a

B 06 01 02 01 02 02 01 05 03 42 03 00 fa 00 30

F 06 0a 2b 06 01 02 01 02 02 01 08 03 02 01 01

F 06 0a 2b 06 01 02 01 02 02 01 09 03 43 01

A 2b 06 01 02 01 02 02 01 0a 03 41

00a0: 04 04 12 5a 5d 30 11 06 0a 2b 06 01 02 01 02 02

00b0: 01 0b 03 41 03 08 6f da 30 0f 06 0a 2b 06 01 02

00c0: 01 02 02 01 0c 03 41 01 07 30 0f 06 0a 2b 06 01

00d0: 02 01 02 02 01 0d 03 41 01 00 30 0f 06 0a 2b 06

00e0: 01 02 01 02 02 01 0e 03 41 01 00 30 12 06 0a 2b

00f0: 06 01 02 01 02 02 01 10 03 41 04 13 a1 03 ca 30

A 2b 06 01 02 01 02 02 01 11 03 41 03 08

D 32 30 0f 06 0a 2b 06 01 02 01 02 02 01 12 03

F 06 0a 2b 06 01 02 01 02 02 01 13

F 06 0a 2b 06 01 02 01 02 02 01

0140: 14 03 41 01 00

Все поля, относящиеся к заголовкам протоколов Ethernet, IP, UDP расшифруем аналогично и сразу заполним в предлагаемую форму, тем самым ответим на первые 14 вопросов.

№ вопроса Для PDU типа Get-Request Для PDU типа Get-Response
  Hex’ значение Dec’ или текстовое значение Hex’ значение Dec’ или текстовое значение
00 00 1d   00 20 af – Сетевой интерфейс фирмы Cabletron – Сетевой интерфейс фирмы 3COM 00 00 1d   00 20 af – Сетевой интерфейс фирмы Cabletron – Сетевой интерфейс фирмы 3COM
00 00 1d 90 58 20 00 20 af e8 e2 8e MAC-адрес назначения   MAC-адрес источника 00 20 af e8 e2 8e 00 00 1d 90 58 20 MAC-адрес назначения MAC-адрес источника
08 00 протокол IPv4 08 00 протокол IPv4
4-я версия 4-я версия
000 – низкий приоритет 000 – низкий приоритет
01 1a 282 байта 01 37 311 байт
TTL=64 транзита 3e TTL=62 транзита
17 – UDP протокол 17 – UDP протокол
d4 a4 00 66 212.164.00.102 d4 a4 c4 f6 212.164.196.246
d4 a4 c4 f6 212.164.196.246 d4 a4 00 66 212.164.00.102
c0 7c 49351 - DP c0 7c 49351 - DP
00 a1 161 - SNMP 00 a1 161 - SNMP
00 a1 161 - SNMP 00 a1 161 - SNMP
01 06 262 байта 01 23 291 байт

Наши рекомендации