Архитектура протоколов для обмена управляющей информацией между менеджером и агентом 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 байт |