Архитектура протоколов для обмена управляющей информацией между менеджером и агентом 4 страница
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
4.3. The GetResponse-PDU
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
4.4. The SetRequest-PDU
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
4.5. The Trap-PDU
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [5]
OBJECT IDENTIFIER,
agent-addr -- address of object generating
NetworkAddress, -- trap
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present even
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the network
-- entity and the generation of the
trap
variable-bindings -- "interesting" information
VarBindList
}
3. Методические указания к выполнению контрольной работы
Ниже приводятся примеры трассировок протокола SNMP, включая заголовки протоколов, обеспечивающих передачу сообщений SNMP по сети IP.
Пример трассировки сообщений протокола SNMP, включая заголовки транспортных протоколов UDP/IP/Ethernet (в Hex’ коде):
0000: 00 00 1d 90 58 2000 20 af e8 e2 8e08 0045 00
0010: 01 1a 0b 25 00 00 40 11 00 09 d4 a4 00 66 d4 a4
0020: c4 f6c0 7c00 a101 064a 5130 81 fb02 01 00
0030: 04 06 76 6d 31 35 2d 31a0 81 ed02 04 35 97 ac
0040: 55 02 01 00 02 01 00 30 81 de 30 0c 06 08 2b 06
0050: 01 02 01 01 03 00 05 00 30 0e 06 0a 2b 06 01 02
0060: 01 02 02 01 05 01 05 00 30 0e 06 0a 2b 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
Рисунок 15 – Трассировка SNMP-сообщения
Общая длина приведенного сообщения – 296 байт и складывается из следующих частей (поля протокола стека SNMP/UDP/IP/Ethernet выделены цветом):
296 байт = 14 Ethernet + 20 IP + 8 UDP + 254 SNMP
В данной трассировке администратором сети запрашивается следующая информация об управляемом объекте:
system.sysUpTime.0
interfaces.ifTable.ifEntry.ifSpeed.1
interfaces.ifTable.ifEntry.ifOperStatus.1
interfaces.ifTable.ifEntry.ifLastChange.1
interfaces.ifTable.ifEntry.ifInOctets.1
interfaces.ifTable.ifEntry.ifInUcastPkts.1
interfaces.ifTable.ifEntry.ifInNUcastPkts.1
interfaces.ifTable.ifEntry.ifInDiscards.1
interfaces.ifTable.ifEntry.ifInErrors.1
interfaces.ifTable.ifEntry.ifOutOctets.1
interfaces.ifTable.ifEntry.ifOutUcastPkts.1
interfaces.ifTable.ifEntry.ifOutNUcastPkts.1
interfaces.ifTable.ifEntry.ifOutDiscards.1
interfaces.ifTable.ifEntry.ifOutErrors.1
В данном пособии детально рассматривается расшифровка всех полей стека протоколов SNMP/UDP/IP/Ethernet.
3.1 Варианты заданий
Варианты заданий к контрольной работе приводятся в приложении ???. Здесь приведем один из вариантов задания и пример его расшифровки.
Вариант задания № n
Заданы следующие сообщения:
1. Сообщение №1
D 90 58 20 00 20 af e8 e2 8e 08 00 45 00
A 0b 25 00 00 40 11 00 09 d4 a4 00 66 d4 a4
C4 f6 c0 7c 00 a1 01 06 4a 51 30 81 fb 02 01 00
D 31 35 2d 31 a0 81 ed 02 04 35 97 ac
De 30 0c 06 08 2b 06
E 06 0a 2b 06 01 02
E 06 0a 2b 06 01 02
E 06 0a 2b 06 01 02
E 06 0a 2b 06 01 02
A 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
E 06 0a 2b 06 01 02
E 06 0a 2b 06 01 02
0120: 01 02 02 01 14 01 05 00
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
В сообщении №1 администратором сети запрашивается следующая информация об управляемом объекте:
system.sysUpTime.0
interfaces.ifTable.ifEntry.ifSpeed.1
interfaces.ifTable.ifEntry.ifOperStatus.1
interfaces.ifTable.ifEntry.ifLastChange.1
interfaces.ifTable.ifEntry.ifInOctets.1
interfaces.ifTable.ifEntry.ifInUcastPkts.1
interfaces.ifTable.ifEntry.ifInNUcastPkts.1
interfaces.ifTable.ifEntry.ifInDiscards.1
interfaces.ifTable.ifEntry.ifInErrors.1
interfaces.ifTable.ifEntry.ifOutOctets.1
interfaces.ifTable.ifEntry.ifOutUcastPkts.1
interfaces.ifTable.ifEntry.ifOutNUcastPkts.1
interfaces.ifTable.ifEntry.ifOutDiscards.1
interfaces.ifTable.ifEntry.ifOutErrors.1
В сообщении №2 в ответном сообщении Response от агента доставляется следующая информация об управляемом объекте:
system.sysUpTime.0=7591024
interfaces.ifTable.ifEntry.ifSpeed.3=64000
interfaces.ifTable.ifEntry.ifOperStatus.3=1
interfaces.ifTable.ifEntry.ifLastChange.3=0
interfaces.ifTable.ifEntry.ifInOctets.3=68311645
interfaces.ifTable.ifEntry.ifInUcastPkts.3=552922
interfaces.ifTable.ifEntry.ifInNUcastPkts.3=7
interfaces.ifTable.ifEntry.ifInDiscards.3=0
interfaces.ifTable.ifEntry.ifInErrors.3=0
interfaces.ifTable.ifEntry.ifOutOctets.3=329319370
interfaces.ifTable.ifEntry.ifOutUcastPkts.3=527666
interfaces.ifTable.ifEntry.ifOutNUcastPkts.3=0
interfaces.ifTable.ifEntry.ifOutDiscards.3=0
interfaces.ifTable.ifEntry.ifOutErrors.3=0
1. Задание:
Расшифровать приведенные в hex’кодах сообщения управляющего протокола, в соответствии с поставленными ниже в пп. 1…18 вопросами.
Ответы оформить в соответствии с прилагаемыми ниже требованиями.
Для расшифровки сообщений используйте сведения в прилагаемых файлах – rfc1213, rfc1700, ETHERNET VENDOR ADDRESS.doc, ETHER TYPES.doc, а также сведения, полученные на лекциях и практических занятиях.
2. Определить из приведенных сообщений:
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. Значения характеристик (атрибутов) управляемого объекта*
Примечание:
1. Ответы на эти 18 вопросов оформить в виде таблиц, как показано в п.3.3 – Правила оформления контрольной работы.
2. Ответы на вопросы в пунктах, отмеченных (*), привести в виде отдельной таблицы (см.п 3.3)
3.2 Методические указания к расшифровке сообщений протокола SNMP
Итак, в сообщении №1 приведена следующая 16-ричная трассировка:
D 90 58 20 00 20 af e8 e2 8e 08 00 45 00
A 0b 25 00 00 40 11 00 09 d4 a4 00 66 d4 a4
C4 f6 c0 7c 00 a1 01 06 4a 51 30 81 fb 02 01 00
D 31 35 2d 31 a0 81 ed 02 04 35 97 ac
De 30 0c 06 08 2b 06
E 06 0a 2b 06 01 02
E 06 0a 2b 06 01 02
E 06 0a 2b 06 01 02
E 06 0a 2b 06 01 02
A 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
E 06 0a 2b 06 01 02
E 06 0a 2b 06 01 02
0120: 01 02 02 01 14 01 05 00
Начнем расшифровку данного примера трассировки с протоколов нижних уровней.
3.2.1.Поля протокола Ethernet: 00 00 1d 90 58 2000 20 af e8 e2 8e 08 00
| 1. Фрагмент трассировки заголовка Ethernet в Hex’-коде | |||||||||||||
| 1d | af | e8 | e2 | 8e | |||||||||
| 2. Формат заголовка протокола Ethernet (всего - 14 байт) | |||||||||||||
| MAC-DA (Адрес сетевой платы назначения) 6 байт | MAC-SA (Адрес сетевой платы источника) 6 байт | Length/ Type (Protocol) 2 байта | |||||||||||
| 3. Кодировка полей протокола Ethernet | |||||||||||||
| Vendor 3 байта | Serial Number 3 байта | Vendor 3 байта | Serial Number 3 байта | dod IP 2 байта |
Первые 3 байта MAC-адресов отведены для кода фирмы (вендора), выпускающей данное оборудование. Некоторые коды фирм приведены в RFC-1700 (см. RFC-1700, раздел – ethernet vendor address components, а также приложение 4 к данному пособию). Согласно этому разделу расшифруем коды вендоров:
00 00 1d – Сетевой интерфейс фирмы Cabletron
00 20 af – Сетевой интерфейс фирмы 3COM
Последние 3 байта MAC-адресов отведены для серийного номера конкретной сетевой платы, который может быть назначен динамически, запрограммирован вендором или устанавливаться администратором сети.
Последние два байта заголовка протокола Ethernet, кодируют либо длину Ethernet-кадра (для версий IEEE 802.3), либо тип обслуживаемого протокола вышележащего уровня (для версий Ethernet II).
В таблице 2.1 приведены некоторые коды этого поля. Полный перечень см. в RFC-1700 (в разделе – ether types,а также в приложении 5).
Таблица 2.1 - Некоторые коды протоколов в Ethernet II (см. RFC-1700)
| Десятичный код | Hex | Описание |
| 0 … 1500 | 00 00 … 05 DC | Поле длины IEEE 802.3 |
| 08 00 | Internet протокол (IPv4) | |
| 08 01 | X.75 Internet | |
| 08 05 | X.25 уровень 3 | |
| 08 06 | Протокол трансляции адреса (ARP) | |
| 80 35 | Реверсивный протокол ARP (RARP) | |
| 81 37-81 38 | NetWare IPX/SPX | |
| 81 4C | SNMP over Ethernet (см. RFC-1089) |
Расшифруем эти два байта в нашем случае:
08 00 – Эта кодировка означает, что данный Ethernet-кадр перевозит в поле данных IP-датаграмму (данные Internet-протокола версии 4 (IPv4)).
3.2.2. Поля протокола IP (заголовок IP-датаграммы)
Формат заголовка протокола IPv4 (5 слов по 32 бита):
| Версия | Длина IP-заголовка (HLength) | Тип сервиса ToS  | Длина IP-пакета (дейтаграммы), включая заголовки IP и UDP | ||||||||||||||||||||||||||||
| Идентификатор фрагмента | Флаги | Указатель фрагмента | |||||||||||||||||||||||||||||
| Время жизни (TTL) | Протокол, которому предоставлена услуга | Контрольная сумма заголовка | |||||||||||||||||||||||||||||
| IP-адрес отправителя – Source (откуда) | |||||||||||||||||||||||||||||||
| IP-адрес получателя – Destination (куда) |
Приведем расшифровку заголовка IP из трассировки сообщения №1:
45 00
0010: 01 1a 0b 25 00 00 40 11 00 09 d4 a4 00 66 d4 a4
0020: c4 f6
Ниже в таблице приведена расшифровка заголовка IP-датаграммы:
| Версия | Длина IP-заголовка (HLength) | Тип сервиса ToS | Длина IP-пакета (дейтаграммы), включая заголовки IP и UDP | |||||||||||||||||||||||||||||
| 01 1а‘hex=282’Dec (байт) | ||||||||||||||||||||||||||||||||
| Prio | D | T | R | C | x | |||||||||||||||||||||||||||
| Идентификатор фрагмента | Флаги | Указатель фрагмента | ||||||||||||||||||||||||||||||
| 0b 25 | 00 00 | |||||||||||||||||||||||||||||||
| Время жизни (TTL) | Протокол, которому предоставлена услуга | Контрольная сумма заголовка | ||||||||||||||||||||||||||||||
| 40’hex (64’Dec) | 11’hex (17’Dec - UDP) | 00 09 | ||||||||||||||||||||||||||||||
| IP-адрес отправителя – Source (откуда) | ||||||||||||||||||||||||||||||||
| d4’hex 212’Dec | a4’hex 164’Dec | 00’hex 00’Dec | 66’hex 102’Dec | |||||||||||||||||||||||||||||
| IP-адрес получателя – Destination (куда) | ||||||||||||||||||||||||||||||||
| d4’hex 212’Dec | a4’hex 164’Dec | c4’hex 196’Dec | f6’hex 246’Dec | |||||||||||||||||||||||||||||
Из расшифровки видно, что IP-пакет длиной 282 байта, перевозящий данное SNMP-сообщение, направляется от устройства с адресом IP – 212.164.00.102 к устройству с адресом IP – 212.164.196.246, при этом время жизни IP-пакета в сети ограничено значением TTL=64, что допускает 64 транзитных пункта.
Также видно, что приоритет данного пакета самый низкий (0), и для обслуживания SNMP-сообщения используется ненадежный протокол UDP (код – 11’hex или 17’dec).
Поле контрольная сумма заголовка вычисляется с использованием операций сложения 16-разрядных слов заголовка по модулю 1.
Обратите внимание, здесь осуществляется контрольное суммирование слов заголовка, а не всей дейтаграммы.
3.2.3. Поля протокола UDP (Заголовок UDP-датаграммы)
Фрагмент (заголовок) UDP-датаграммы: c0 7c00 a101 064a 51
Формат заголовка протокола UDP:
| Порт отправителя (от кого) | Порт назначения (кому) | ||||||||||||||||||||||||||||||
| Длина UDP-пакета | Контрольная сумма заголовка |
Полный перечень номеров UDP-портов приведен в RFC-1700.
Номера портов от 0 до 255 стандартизованы и закреплены за наиболее известными сервисными протоколами.
Номер порта 161 закреплен за сообщениями протокола SNMP. Для SNMP-сообщений типа Trap, выделен порт с номером 162. Использовать эти «очень известные порты» в прикладных задачах не рекомендуется.
В интервале 255-1023 многие номера портов также заняты, поэтому прежде чем использовать какой-то порт в своей программе, следует заглянуть в RFC-1700.
Номера портов с 4096 по 65536, назначаются динамически по согласованию сторон, участвующих в обмене информацией.
Длина сообщения (UDP-пакета) равна числу байт в UDP-датаграмме, включая заголовок UDP.
Поле UDP контрольная сумма содержит код, полученный в результате контрольного суммирования UDP-заголовка и поля «данные».
Ниже в таблице приведена расшифровка заголовка UDP-датаграммы:
| 1-ое 32-х разрядное слово UDP-заголовка | |||||||||||||||||||||||||||||||
| Порт отправителя (от кого) | Порт назначения (кому) | ||||||||||||||||||||||||||||||
| c0 7c (49351’Dec) | 00 a1 (161’Dec - SNMP) | ||||||||||||||||||||||||||||||
| 2-ое 32-х разрядное слово UDP-заголовка | |||||||||||||||||||||||||||||||
| Длина UDP-пакета | Контрольная сумма заголовка | ||||||||||||||||||||||||||||||
| 01 06 (262’Dec байт) | 4a 51 |
Из данной расшифровки видно, что UDP-дейтаграмма, обслуживающая SNMP-сообщение, имеет общую длину 262 байта и предназначена для приложения с портом 161. Со стороны источника используется динвмически назначенный порт с номером 49351.
Итак, расшифрованную информацию из заголовков Ethernet/IP/UDP сведем в таблицу по прилагаемой в задании форме (т.е. заполним в твблице ответы на первые 14 вопросов):
Определить из приведенных сообщений
1. Фирму-поставщика оборудования сетевых интерфейсов
2. MAC-адреса источника и назначения
3. Тип протокола, обслуживаемого данным Ethernet-кадром
4. Версию протокола сетевого уровня
5. Приоритет сетевого уровня для данной дейтаграммы
6. Длину пакета сетевого уровня (в байтах)
7. Время жизни данной дейтаграммы
8. Протокол транспортного уровня (Dec’код и название)
9. Сетевой адрес отправителя
10. Сетевой адрес назначения
11. Транспортный порт отправителя
12. Транспортный порт получателя
13. Тип и версию протокола прикладного уровня
14. Длину дейтаграммы транспортного уровня (в байтах)