Протокол управления сообщениями Интернета (ICMP). Что такое ICMP

Основные понятия, стандарты и организации, действующие в области ИС.

Взаимодействие открытых систем(Open Systems Interconnection (OSI ))

Взаимодействие открытых систем - правила сопряжения систем с открытой архитектурой от различных производителей.

Архитектура безопасности(Security architecture)

Архитектура безопасности - официальное дополнение ISO к модели OSI, определяющее меры безопасности в информационной сети.

Архитектура безопасности предполагает:

Предотвращение чтения сообщений любыми лицами;

Защиту трафика от его анализа посторонними;

Обнаружение изменений потоков сообщений;

Определение искажений блоков данных.

В зависимости от используемых методов различают:

Сети со слабой защитой, в которых усилия нарушителя пропорциональны затратам отправителя;

Сети с сильной защитой, требующие резкого увеличения затрат нарушителя.

Базовая эталонная модель взаимодействия открытых систем (Модель OSI)

(Стандарт ISO 7498 (Open systems interconnection basic reference model))

Базовая эталонная модель взаимодействия открытых систем - стандарт ISO, определяющий процесс информационного взаимодействия двух или более систем, в виде совокупность информационных взаимодействий уровневых подсистем.

Система обработки сообщений (Message Handling System (MHS ))

Система обработки сообщений - в модели OSI - система агентов сообщений пользователя, агентов передачи сообщений, хранения сообщений и устройств доступа, обеспечивающая работу электронной почты.

Уровень (Layer)

Уровень - в модели OSI - набор структур и программ, обеспечивающих обработку определенного класса событий.

Уровень выступает единицей декомпозиции совокупности функций, обеспечивающих информационное взаимодействие прикладных процессов.

В модели OSI выделяют семь уровней информационного взаимодействия:

7- прикладной уровень: передача информации между программами;

6- уровень представления: шифрование, кодирование и сжатие данных;

5- сеансовый уровень: установка, поддержка и разрыв соединения;

4- транспортный уровень: точность доставки, уровень качества услуг;

3- сетевой уровень: маршруты передачи, обработка и передача сообщений;

2- канальный уровень: управление каналом связи, доступ к среде передачи и адресация;

1- физический уровень: cвязь на уровне аппаратуры.

Уровни не зависят друг от друга и состоят из активных объектов, которые:

Взаимодействуют с другими объектами того же уровня;

Предоставляют сервис смежному с ним верхнему уровню;

Получают сервис от смежного с ним нижнего уровня;

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

Семиуровневая модель ВОС.

Модель Взаимодействия Открытых Систем (OSI).

Эталонная модель OSI, иногда называемая стеком OSI представляет собой 7-уровневую сетевую иерархию, разработанную Международной организацией по стандартам (International Standardization Organization - ISO). Эта модель содержит в себе по сути 2 различных модели:

Горизонтальную модель на базе протоколов, обеспечивающую механизм взаимодействия программ и процессов на различных машинах

Вертикальную модель на основе услуг, обеспечиваемых соседними уровнями друг другу на одной машине

В горизонтальной модели двум программам требуется общий протокол для обмена данными. В вертикальной - соседние уровни обмениваются данными с использованием интерфейсов API.

Уровень 7, прикладной

Прикладной уровень отвечает за доступ приложений в сеть. Задачами этого уровня является перенос файлов, обмен почтовыми сообщениями и управление сетью. (FTP, Telnet,…)

Уровень 6, представления

Этот уровень обеспечивает преобразование данных (кодирование, компрессия и т.п.). Обеспечивает независимость прикладных процессов от различных форм представления данных.

Уровень 5, сеансовый

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

Уровень 4, транспортный

Транспортный уровень делит потоки информации на достаточно малые фрагменты (пакеты) для передачи их на сетевой уровень. В стеке TCP/IP происзодит контроль целостности передачи данных. (TCP).

Уровень 3, сетевой

На этом уровне происходит маршрутизация пакетов на основе преобразования MAC-адресов в сетевые адреса. Сетевой уровень обеспечивает также прозрачную передачу пакетов на транспортный уровень. (IP).

Уровень 2, канальный

Канальный уровень обеспечивает создание, передачу и прием кадров данных. Этот уровень обслуживает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов. Спецификации IEEE 802.x делят канальный уровень на два подуровня: управление логическим каналом (LLC) и управление доступом к среде (MAC). LLC обеспечивает обслуживание сетевого уровня, а подуровень MAC регулирует доступ к разделяемой физической среде. (Ethernet).

Уровень 1, физический

Физический уровень получает пакеты данных от вышележащего канального уровня и преобразует их в оптические или электрические сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи на приемный узел. Механические и электрические/оптические свойства среды передачи определяются на физическом уровне и включают:

· Тип кабелей и разъемов

· Разводку контактов в разъемах

· Схему кодирования сигналов для значений 0 и 1

На сетевом уровне формируется IP-пакет: DATA|IP-заголовок

На канальном уровне формируется кадр: DATA|IP-заголовок|Ethernet-заголовок:

· 1 IP-паке в один кадр

· 1 IP-пакет разбивается на несколько кадров

· Несколько IP-пакетов помещаются в 1 кадр

3. TCP/IP, распределение протоколов по уровням ВОС.

Transmission Control Protocol/Internet Protocol (TCP/IP) - это промышленный стандарт стека протоколов, разработанный для глобальных сетей.

Стандарты TCP/IP опубликованы в серии документов, названных Request for Comment (RFC). Документы RFC описывают внутреннюю работу сети Internet. Некоторые RFC описывают сетевые сервисы или протоколы и их реализацию, в то время как другие обобщают условия применения.

Так как стек TCP/IP был разработан до появления модели взаимодействия открытых систем ISO/OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.

Структура протоколов TCP/IP приведена на рисунке 2.1. Протоколы TCP/IP делятся на 4 уровня.

Рис. 2.1. Стек TCP/IP

(уровень IV ) соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня: Ethernet, Token Ring, FDDI, Fast Ethernet, PPP и т.д..

(уровень III ) - уровень межсетевого взаимодействия, который занимается передачей пакетов с использованием различных транспортных технологий локальных сетей, территориальных сетей, линий специальной связи и т. п. В качестве основного протокола сетевого уровня (в терминах модели OSI) в стеке используется протокол IP . Протокол IP является дейтаграммным протоколом, то есть он не гарантирует доставку пакетов до узла назначения. Также протоколы RIP, OSPF, ICMP и др.

(уровень II ) называется основным. На этом уровне функционируют протокол управления передачейTCP (Transmission Control Protocol) и протокол дейтаграмм пользователя UDP (User Datagram Protocol). Протокол TCP обеспечивает надежную передачу сообщений между удаленными прикладными процессами за счет образования виртуальных соединений. Протокол UDP обеспечивает передачу прикладных пакетов дейтаграммным способом, как и IP, и выполняет только функции связующего звена между сетевым протоколом и многочисленными прикладными процессами.

(уровень I ) называется прикладным. WWW, Telnet, SMTP и т.д..

Протоколы IP, ARP, RARP.

Основу транспортных средств стека протоколов TCP/IP составляет протокол межсетевого взаимодействия - Internet Protocol (IP). Документ – RFC 791. К основным функциям протокола IP относятся:

· перенос между сетями различных типов адресной информации в унифицированной форме,

· сборка и разборка пакетов при передаче их между сетями с различным максимальным значением длины пакета.

Состав IP-кадра:

· Заголовок 20байт

· внутри заголовка 2 блока по 32бита для IP-адресов источника и назначения

· Поле данных

В большинстве типов локальных и глобальных сетей определяется такое понятие как максимальный размер поля данных кадра или пакета, в которые должен инкапсулировать свой пакет протокол IP. Эту величину обычно называют максимальной единицей транспортировки - Maximum Transfer Unit, MTU. Сети Ethernet имеют значение MTU, равное 1500 байт

ARP (Address Resolution Protocol) протокол служит для установления соответствия между IP и MAC адресом (ARP – когда изв. IP, RARP – когда изв. MAC). MAC-адрес – 48бит, прошит в каждой железке (байта – производитель, ещё 3 байта – уникальный номер железки).

В сетях используется IP-адресация, как более гибкая. IP-адрес не привязан к железу.

С помощью ARP заполняется специальная таблица – ARP-кэш, с динамическими записями.

2 узла – А и Б, А знает IP Б и хочет отправить ему данные:

1) А посылает широковещательный ARP запрос с IP адресом Б

2) Б видит свой IP и посылает широковещательный ответ со своим MACом

3) A получает MAC Б, помещает его в ARP-кэш и формиреут Ethernet-кадр (данные|IP-заголовок(IP-адреса)|Ethernet-заголовок(MAC адреса))

Для дальнейшей передачи ARP-запросы не нужны.

RARP – Reverse ARP. Одно из применений – старт бездисковых станций, не знающих в начальный момент своего IP-адреса.

Протоколы TCP , ICMP , UDP.

Transmission Control Protocol (TCP) (протокол управления передачей) - один из основных сетевых протоколов Интернета, предназначенный для управления передачей данных в сетях и подсетях TCP/IP.

Выполняет функции протокола транспортного уровня модели OSI.

TCP - это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета.

Единицей данных протокола TCP является сегмент. Информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байт. Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера "вырезается" некоторая непрерывная часть данных, называемая сегментом.

Соединение в протоколе TCP идентифицируется парой полных адресов обоих взаимодействующих процессов (оконечных точек). Адрес каждой из оконечных точек включает IP-адрес (номер сети и номер компьютера) и номер порта (FTP – 21, HTTP – 80 и т.д.). Одна оконечная точка может участвовать в нескольких соединениях.

Установление соединения выполняется в следующей последовательности:

· При установлении соединения одна из сторон является инициатором. Она посылает запрос к протоколу TCP на открытие порта для передачи (active open).

· После открытия порта протокол TCP на стороне процесса-инициатора посылает запрос процессу, с которым требуется установить соединение.

· Протокол TCP на приемной стороне открывает порт для приема данных (passive open) и возвращает квитанцию, подтверждающую прием запроса.

· Для того чтобы передача могла вестись в обе стороны, протокол на приемной стороне также открывает порт для передачи (active port) и также передает запрос к противоположной стороне.

· Сторона-инициатор открывает порт для приема и возвращает квитанцию. Соединение считается установленным. Далее происходит обмен данными в рамках данного соединения.

Используется квитирование (подтверждение передачи данных)

ICMP (Internet Control Message Protocol - межсетевой протокол управляющих сообщений) - сетевой протокол, входящий в стек протоколов TCP/IP. В основном ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных, например, запрашиваемая услуга недоступна, или хост, или маршрутизатор не отвечают. Также на ICMP возлагаются некоторые сервисные функции.

Каждое сообщение протокола ICMP передается по сети внутри пакета IP. Пакеты IP с сообщениями ICMP маршрутизируются точно так же, как и любые другие пакеты, без приоритетов, поэтому они также могут теряться. Кроме того, в загруженной сети они могут вызывать дополнительную загрузку маршрутизаторов. Для того, чтобы не вызывать лавины сообщения об ошибках, потери пакетов IP, переносящие сообщения ICMP об ошибках, не могут порождать новые сообщения ICMP.

Существует несколько типов сообщений ICMP. Каждый тип сообщения имеет свой формат, при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (TYPE), 8-битного поля кода (CODE), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (CHECKSUM). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку.

UDP (User Datagram Protocol - протокол пользовательских датаграмм) - это транспортный протокол для передачи данных в сетях IP без установления соединения. Он является одним из самых простых протоколов транспортного уровня модели OSI. В отличие от TCP, UDP не гарантирует доставку пакета. Это позволяет ему гораздо быстрее и эффективнее доставлять данные для приложений, которым требуется большая пропускная способность линий связи, либо требуется малое время доставки данных.

Маршрутизаторы. Принцип работы маршрутизатора. Протоколы маршрутизации.

Протоколы маршрутизации. Изучение статических маршрутов и протокола RIP в сети, использующей маршрутизаторы Cisco

Протокол передачи команд и сообщений об ошибках ( ICMP - internet control message protocol, RFC-792, - 1256) выполняет различные и не только диагностические функции. При пересылке пакетов промежуточные узлы не информируются о возникших проблемах, поэтому ошибка в маршрутной таблице может восприниматься как неисправность в узле адресата и достоверно диагностироваться не будет. ICMP-протокол сообщает об ошибках в IP-дейтаграммах, но не дает информации об ошибках в самих ICMP-сообщениях. ICMP использует IP, а IP-протокол должен использовать ICMP. В случае ICMP-фрагментации сообщение об ошибке будет выдано только один раз на дейтаграмму, даже если ошибки были в нескольких фрагментах. Подводя итоги, можно сказать, что ICMP -протокол:

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

ICMP -сообщения об ошибках никогда не выдаются:

• в ответ на ICMP-сообщение об ошибке;
• при мультикастинг-е или широковещательной адресации;
• для фрагмента дейтаграммы (кроме первого);
• для дейтаграмм, чей адрес отправителя является нулевым, широковещательным или мультикастинговым.

Эти правила призваны блокировать потоки дейтаграмм, посылаемые в отклик на мультикастинг- или широковещательные ICMP -сообщения. Особенности протокола ICMPv6 описаны в документе RFC-2463. В IPv6 на протокол ICMP возложены функции управления группами ( IGMP ).

ICMP -сообщения имеют свой формат, а схема их вложения аналогична UDP или TCP и представлена на рис. 3.1 .

Все ICMP пакеты начинаются с 8-битного поля типа ICMP и его кода (15 значений).

Рис. 3.1.

По существу, значения полей типа и кода выполняют почти ту же функцию, что и порт в ТСР и UDP -протоколах.

Код уточняет функцию ICMP -сообщения. Таблица 3.1 этих кодов приведена ниже (символом * помечены сообщения об ошибках, остальные являются запросами).

Процедура "отключение источника" (quench, поле тип ICMP=4 ) позволяет управлять потоками данных в каналах Интернет . Не справляясь с обработкой дейтаграмм, ЭВМадресат (или транзитное сетевое устройство) может послать запрос "отключить источник" отправителю, который может сократить темп посылки пакетов, например, вдвое, или вовсе прервать их посылку. Специальной команды, отменяющей прежние запреты, не существует. Если сообщения об отключении прекращаются, источник может возобновить посылку пакетов или увеличить частоту их отправки. Ниже (на рис. 3.2) представлен формат эхозапроса ( ping ) и отклика для протокола ICMP .

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

Поле тип определяет, является ли этот пакет запросом (8) или откликом (0). Поле контрольная сумма представляет собой 16-разрядное дополнение по модулю 1 контрольной суммы всего ICMP -сообщения, начиная с поля тип . Поле данные служит для записи информации, возвращаемой отправителю. При выполнении процедуры ping эхозапрос с временной меткой в поле данные посылается адресату. Если адресат активен, он принимает IP -пакет, меняет адрес отправителя и получателя местами и посылает его обратно. ЭВМ-отправитель, восприняв этот отклик, может сравнить временную метку, записанную им в пакет, с текущим показанием внутренних часов и определить время распространения пакета ( RTT - round trip time ). Размер поля данные не регламентирован и определяется предельным размером IP -пакета.

Таблица 3.1. Типы и коды ICMP-сообщений

ICMP-сообщение		описание сообщения
Тип	код
0		Эхо-ответ (ping-отклик)
3		Адресат недостижим
	0	* Сеть недостижима
	1	* ЭВМ недостижима
	2	* Протокол недоступен
	3	* Порт недоступен
	4	* Необходима фрагментация сообщения (установлен флаг DF)
	5	* Маршрутизация отправителя нереализуема
	6	* Сеть места назначения неизвестна
	7	* ЭВМ места назначения неизвестна
	8	* Исходная ЭВМ изолирована (устарело)
	9	* Связь с сетью места назначения административно запрещена
	10	* Связь с ЭВМ места назначения административно запрещена
	11	* Сеть не доступна для данного вида сервиса (TOS)
	12	* ЭВМ не доступна для данного вида сервиса (TOS)
	13	* Связь административно запрещена с помощью фильтра
	14	* Нарушение старшинства ЭВМ
	15	* Дискриминация по старшинству
4	0	* Отключение источника при переполнении очереди (quench)
5		Переадресовать (изменить маршрут)
	0	Переадресовать дейтаграмму в сеть (устарело)
	1	Переадресовать дейтаграмму на ЭВМ
	2	Переадресовать дейтаграмму для типа сервиса (ToS) и сети
	3	Переадресовать дейтаграмму для типа сервиса и ЭВМ
8	0	Эхо запроса (ping-запрос)
9	0	Объявление маршрутизатора
10	0	Запрос маршрутизатора
11		Для дейтаграммы время жизни истекло (ttl=0):
	0	*при передаче
	1	* тайм-аут при сборке (случай фрагментации)
12		* Проблема с параметрами дейтаграммы
	0	* Ошибка в IP-заголовке
	1	* Отсутствует необходимая опция
13		Запрос временной метки
14		Временная метка-отклик
15		Запрос информации (устарел)
16		Информационный отклик (устарел)
17		Запрос адресной маски
18		Отклик на запрос адресной маски

Рис. 3.2.

Рис. 3.2a.

Так как в пакете ICMP нет поля порт , то при запуске нескольких процессов PING одновременно может возникнуть проблема с тем, какому из процессов следует передать тот или иной отклик. Для преодоления этой неопределенности следует использовать уникальные значения полей идентификатор .

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

Эта процедура позволяет не только диагностировать, но и оптимизировать маршрут . Например, команда traceroute cernvm.cern.ch , выданная в ЭВМ SUN (ИТЭФ), может отобразить на экране (в скобках указаны IP -адреса узлов и значения времени жизни дейтаграмм, значения RTT приводится в миллисекундах) (таблица 3.1.1.):

Таблица 3.1.1.

traceroute to crnvma cern ch		(128 141 2 4) 30 hops max, 40 byte packets
1	itep-fddi-bbone	(193.124.224.50) 3 ms 2 ms 3 ms
2	msu - tower .moscow.ru.radio- msu .net	(193.124.137.13) 3 ms 3 ms 3 ms
3	npi- msu .moscow.ru.radio- msu .net	(193.124.137.9) 27 ms 3 ms 9 ms
4	desy.hamburg.de.radio- msu .net	(193.124.137.6) 556 ms 535 ms 535 ms
5	* 188.1.133.56	(188.1.133.56) 637ms 670ms
6	duesseldorf2.empb.net	(193.172.4.12) 740ms(ttl=59!) 839ms(ttl=59!) 2066ms(ttl=59!)
7	bern3.empb.net	(193.172.4.30) 2135ms (ttl=58!) 1644ms (ttl=58!) 1409ms (ttl=58!)
8	cernh3.euro-hep.net	(193.172.24.10) 1808ms 1508ms 1830ms
9	cgate1.cern.ch	(192.65.185.1) 1116ms 1270ms 1278ms
10	crnvma.cern.ch	(128.141.2.4) 1132ms 1362ms 1524ms

Отсюда видно, что наиболее узкими участками маршрута (на момент выполнения процедуры) являются Гамбург-Дюссельдорф-Берн-CERN. Следует иметь в виду, что канал МГУ-Гамбург был спутниковым и 500мс задержки здесь вносит удвоенное время распространения сигнала до спутника и обратно. Участок Гамбург-Дюссельдорф (X.25, квота 256кбит/с) был общим для потока данных из Германии в США. Передача IP поверх X.25 также снижает эффективную широкополосность канала. Остальные связи обладают недостаточной пропускной способностью. Программа ping показывает для данных участков в часы пик высокую долю потерянных пакетов. Таким образом, имея карту связей и используя указанные процедуры, вы можете успешно диагностировать ситуацию в сети. Продвинутые же программисты могут легко написать свои диагностические программы, базирующиеся на ICMP , как для локальной сети, так и для "окрестного" Интернет .

Когда маршрутизатор не может доставить дейтаграмму по месту назначения, он посылает отправителю сообщение "адресат недостижим" ( destination unreachable). Формат такого сообщения показан ниже (на рис. 3.3).

Рис. 3.3. Формат ICMP-сообщения "адресат недостижим"

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

Так как в сообщении содержится Интернет -заголовок и первые 64-бита дейтаграммы, легко понять, какой адрес оказался недостижим. Этот тип ICMP -сообщения посылается и в случае, когда дейтаграмма имеет флаг DF=1 ("не фрагментировать"), а фрагментация необходима. В поле код в этом случае будет записано число 4.

Если буфер приема сообщения переполнен, ЭВМ посылает сообщение типа 4.

Так как собственные часы различных ЭВМ имеют свое представление о времени, протокол ICMP , среди прочего, служит для синхронизации работы различных узлов, если это требуется (запросы временных меток). Протокол синхронизации NTP ( network time protocol ) описан в RFC-1119.

Когда дейтаграммы поступают слишком часто и принимающая сторона не справляется с этим потоком, отправителю может быть послано сообщение с требованием резко сократить информационный поток (quenchзапрос). Снижение потока должно продолжаться до тех пор, пока не прекратятся quenchзапросы. Такое сообщение имеет формат, показанный на рис. 3.4 .

Рис. 3.4.

В Internet таблицы маршрутизации остаются без изменений достаточно долгое время, но иногда они все же меняются. Если маршрутизатор обнаружит, что ЭВМ использует неоптимальный маршрут , он может послать ей ICMP - запрос переадресации. При этом следует учитывать, что этой возможностью может воспользоваться и хакер . Формат такого сообщения отображен на рисунке 3.5 .

Рис. 3.5.

Поле Internet-адрес маршрутизатора содержит адрес маршрутизатора, который ЭВМ должна использовать, чтобы посланная дейтаграмма достигла места назначения, указанного в ее заголовке. В поле internet -заголовок кроме самого заголовка лежит 64 первых бита дейтаграммы, вызвавшей это сообщение. Поле код специфицирует то, как нужно интерпретировать адрес места назначения (см. табл. 3.1).

Команды переадресации маршрутизатор посылает только ЭВМ и никогда другим маршрутизаторам. Рассмотрим конкретный пример. Пусть некоторая ЭВМ на основе своей маршрутной таблицы посылает пакет маршрутизатору M1. Он, просмотрев свою маршрутную таблицу, находит, что пакет следует переслать маршрутизатору M2. Причем выясняется, что пакет из M1 в M2 следует послать через тот же интерфейс , через который он попал в M1. Это означает, что M2 доступен и непосредственно для ЭВМ-отправителя. В такой ситуации M1 посылает ICMP - запрос переадресации ЭВМ-отправителю указанного пакета с тем, чтобы она внесла соответствующие коррективы в свою маршрутную таблицу (либо чтобы администратор поменял IPадрес или маску ЭВМ).

Маршрутная таблица может загружаться из файла, формироваться менеджером сети, но может создаваться и в результате запросов и объявлений, посылаемых маршрутизаторами. После загрузки системы маршрутизатор посылает широковещательный запрос . Один или более маршрутизаторов посылают в ответ сообщения об имеющейся маршрутной информации. Кроме того, маршрутизаторы периодически (раз в 450600 сек.) широковещательно объявляют о своих маршрутах, что позволяет другим маршрутизаторам скорректировать свои маршрутные таблицы. В RFC-1256 описаны форматы ICMP -сообщений такого рода (см. рис. 3.6). Из--за своей уязвимости данная технология в последнее время практически не используется.

Рис. 3.6.

Поле число адресов характеризует количество адресных записей в сообщении. Поле длина адреса содержит число 32-битных слов, необходимых для описания адреса маршрутизатора. Поле время жизни предназначено для записи продолжительности жизни объявленных маршрутов (адресов) в секундах. По умолчанию время жизни равно 30 мин. Поля уровень приоритета представляют собой меру приоритетности маршрута по отношению к другим маршрутам данной подсети. Чем больше этот код, тем выше приоритет. Маршрут по умолчанию имеет уровень приоритета 0. Формат запроса маршрутной информации (8 октетов,

Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) играет в сети вспомогательную роль, а именно позволяет маршрутизатору сообщить конечному узлу об ошибках, с которыми он столкнулся при передаче какого-либо IP-пакета от данного конечного узла.

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

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

Каждое сообщение протокола ICMP передается по сети внутри пакета IP. Пакеты IP с сообщениями ICMP маршрутизируются точно так же, как и любые другие пакеты, без приоритетов, поэтому они тоже могут теряться. Кроме того, в загруженной сети они могут вызывать дополнительную загрузку маршрутизаторов. При потере IP-пакетов, переносящих сообщения ICMP, маршрутизаторы не должны порождать новые пакеты, чтобы не вызвать массу сообщений об ошибках.

Существует несколько типов сообщений ICMP, каждый из которых имеет свой формат, хотя при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (Type), 8-битного поля кода (Code), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (Checksum). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку. Это делается для того, чтобы узел-отправитель смог более точно проанализировать причину ошибки, так как все протоколы прикладного уровня стека TCP/IP содержат наиболее важную информацию для анализа в первых 64 битах своих сообщений. Поле Тип сообщения может иметь значения, представленные в табл. 2.14 .

Протокол ICMP предоставляет сетевым администраторам средства для тестирования достижимости узлов сети. Эти средства представляют собой очень простой эхо-протокол, включающий обмен двумя типами сообщений: эхо-запросом и эхо-ответом .

Компьютер или маршрутизатор посылают по интерсети эхо-запрос, в котором указывают IP-адрес узла, достижимость которого нужно проверить. Узел, который получает эхо-запрос, формирует и отправляет эхо-ответ и возвращает сообщение узлу-отправителю запроса. В запросе могут содержаться некоторые данные, которые должны быть возвращены в ответе.

Так как эхо-запрос и эхо-ответ передаются по сети внутри IP-пакетов, то их успешная доставка означает нормальное функционирование всей транспортной системы сети.

Таблица 2.14 – Значения поля Тип сообщения

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

Как мы не раз отмечали, протокол IP доставляет данные, руководствуясь принципом «по возможности», то есть не предпринимает мер для гарантированной передачи данных адресату. Это свойство «необязательности» протокола IP компенсируется протоколами более высоких уровней стека TCP/IP, например TCP на транспортном уровне и в какой-то степени DNS на прикладном уровне. Они берут на себя обязанности по обеспечению надежности, применяя такие известные приемы, как нумерация сообщений, подтверждение доставки, повторная посылка данных.

Протокол ICMP также служит дополнением, компенсирующим ненадежность протокола IP, но несколько другого рода. Он не предназначен для исправления возникших при передаче пакета проблем: если пакет потерян, ICMP не может послать его заново. Задача ICMP другая - он является средством оповещения отправителя о «несчастных случаях», произошедших с его пакетами. Пусть, например, протокол IP, работающий на каком-либо маршрутизаторе, обнаружил, что пакет для дальнейшей передачи по маршруту необходимо фрагментировать, но в пакете установлен признак DF (не фрагментировать). Протокол IP, обнаруживший, что он не может передать IP-пакет далее по сети, прежде чем отбросить пакет, должен отправить диагностическое ICMP-сообщение конечному узлу-источнику.

Для передачи по сети ICMP-сообщение инкапсулируется в поле данных IP-пакета. IP-адрес узла-источника определяется из заголовка пакета, вызвавшего инцидент.

Сообщение, прибывшее в узел-источник, может быть обработано там либо ядром операционной системы, либо протоколами транспортного и прикладного уровней, либо приложениями, либо просто проигнорированы. Важно, что обработка ICMP-сообщений не входит в обязанности протоколов IP и ICMP.

Заметим, что некоторые из пакетов могут исчезнуть в сети, не вызвав при этом никаких оповещений. В частности, протокол ICMP не предусматривает передачу сообщений о проблемах, возникающих при обработке IP-пакетов, несущих ICMP-сообщения об ошибках. Такое решение было принято разработчиками протокола, чтобы не порождать «штормы» в сетях, когда количество сообщений об ошибках лавинообразно возрастает.

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

Рис. 1. Формат ICMP-сообщения

Заголовок ICMP-сообщения состоит из 8 байт:

• тип (1 байт) - числовой идентификатор типа сообщения;
• код (1 байт) - числовой идентификатор, более тонко дифференцирующий тип ошибки;
• контрольная сумма (2 байта) - подсчитывается для всего ICMP-сообщения.

Содержимое оставшихся четырех байтов в заголовке и поле данных зависит от значений полей типа и кода.

На рис. 2 показана таблица основных типов ICMP-сообщений. Эти сообщения можно разделить на две группы (помеченные на рисунке условными символами):

• сообщения об ошибках;
• сообщения запрос-ответ.

Сообщения типа запрос-ответ связаны в пары: эхо-запрос - эхо-ответ, запрос маски -ответ маски, запрос времени - ответ времени. Отправитель сообщения-запроса всегда рассчитывает на получение соответствующего сообщения-ответа.

Рис. 2. Типы и коды ICMP-сообщений

Сообщения, относящиеся к группе сообщений об ошибках, конкретизируются уточняющим кодом. На рисунке показан фрагмент таблицы кодов для сообщения об ошибке недостижимости узла назначения, имеющей тип 3. Из таблицы мы видим, что это сообщение может быть вызвано различными причинами, такими как неверный адрес сети или узла (код О или 1), отсутствием на конечном узле-адресате необходимого протокола прикладного уровня (код 2 - «протокол недостижим») или открытого порта UDP/TCP (код 3 - «порт недостижим»). Узел (или сеть) назначения может быть также недостижим по причине временной неработоспособности аппаратуры или из-за того, что маршрутизатор не имеет данных о пути к сети назначения. Всего таблица содержит 15 кодов. Аналогичные таблицы кодов существуют и для других типов сообщений об ошибках.

Протокол ICMP

Межсетевой протокол управляющих сообщений (ICMP - Internet Control Message Protocol) разработан для того, чтобы маршрутизаторы в Интернете сообщали об ошибках или предоставляли информацию о нестандартных усло­виях работы сети. Он является необходимой частью протокола IP. И обеспе­чивает обратную связь, оповещение отправителя данных о проблемах, возни­кающих в коммуникационном оборудовании.

Протокол ICMP - это механизм сообщения об ошибках. Он обеспечивает маршрутизаторам, обнаруживающим ошибки, способ сообщения об ошибке первоначальному источнику. Хотя спецификация протокола определяет допус­тимые способы использования ICMP и предлагает варианты возможных дей­ствий в ответ на ошибки, ICMP не специфицирует полностью действия, кото­рые необходимо предпринять в ответ на все возможные ошибки. Таким образом, ICMP только сообщает о возникших ошибках первоначальному источнику; ис­точник сам должен связать ошибки с конкретными прикладными программа­ми и предпринять действия по исправлению ошибок.

Протокол ICMP выполняет следующие основные функции:

обмен тестовыми сообщениями для выяснения наличия и активности уз­лов сети;

анализ достижимости узлов и сброс пакетов, направленных к недостижи­мым узлам;

изменение маршрутов (Redirect);

уничтожение пакетов с истекшим временем жизни (Time-To-Live);

синхронизация времени в узлах сети;

управление трафиком (регулирование частоты отправки пакетов).

С точки зрения уровневых протоколов, ICMP является частью сетевого уровня. Но по отношению к IP ICMP протокол более высокого уровня, так как он пользуется услугами IP для доставки своих сообщений. Другими словами, каждое сообщение ICMP передается по сети внутри 1Р-дейтаграммы.

ICMP-сообщения бывают двух видов: сообщение-запрос и сообщение об ошибке. Сообщение об ошибке тесно связано с породившей его дейтаграм­мой и всегда содержит заголовок этой IP-дейтаграммы и первые 64 бит ее данных. Это необходимо для того, чтобы узел-источник смог более точно проанализировать причину ошибки, так как все прикладные протоколы стека TCP/IP содержат наиболее важную информацию для анализа в первых 8 байт своего сообщения. Сообщения-запросы передают информацию об определен­ной сети и об определенном компьютере или их используют для диагностичес­ких целей.

IP-пакеты с сообщениями ICMP передаются по сети «на общих основани­ях», без приоритетов, поэтому они тоже могут теряться. В загруженной сети они могут вызвать дополнительную загрузку маршрутизаторов, когда потеря сообщения об ошибке приводит к порождению нового сообщения и т. д., пока канал связи не исчерпает своей пропускной способности. Для того чтобы пре­дотвратить подобные ситуации, в спецификации четко определены правила, руководствуясь которыми компьютер может решить, передавать его ICMP- сообщение или нет.

Правило 1: потеря пакета с ICMP-сообщением никогда не генерирует ново­го ICMP-сообщения.

Правило 2: сообщения об ошибке никогда не генерируются в ответ на IP- дейтаграммы с широковещательными или групповыми адресами, чтобы не вызвать полную перегрузку сети - широковещательный шторм (broadcast storm ).

Правило 3 : при повреждении фрагментированной дейтаграммы, 1СМР-со- общение отправляют только после первого поврежденного фрагмента (так как источник все равно повторит передачу всей дейтаграммы целиком).

Доставка ICMP-пакетов требует двух уровней инкапсуляции. ICMP-пакеты инкапсулируются внутрь IP-дейтаграммы, которая сама передается по каж­дой физической сети в поле данных кадра (рис. 5.29).

Несмотря на то, что сообщения ICMP инкапсулируются и посылаются, ис­пользуя IP, ICMP не считают протоколом более высокого уровня - он является

необходимой частью IP. Протокол IP необходим для транспортировки сообще­ний ICMP, так как им, чтобы достичь своего конечного назначения, надо пере­сечь несколько физических сетей. Поэтому, они не могут быть доставлены только с помощью физической передачи.

Формат ICMP-пакетов. Хотя каждое сообщение ICMP имеет свой соб­ственный формат, все они начинаются с трех одинаковых полей: 8-битового целочисленного поля «Тип», идентифицирующего сообщение, 8-битового поля «Код», обеспечивающего более точную информацию о типе сообщения, и 16­битового поля «Контрольная сумма» (рис. 5.30). Помимо того, сообщения ICMP, сообщающие об ошибках, всегда включают заголовок и первые 64 бит данных дейтаграммы, вызвавшей ошибку. Это необходимо для того, чтобы узел-от­правитель смог более точно проанализировать причину ошибки, так как все протоколы прикладного уровня стека TCP/IP содержат наиболее важную ин­формацию для анализа в первых 64 бит своих сообщений.

Сетевые программы распознают ICMP-сообщения по двум признакам: зна­чению поля «Тип» и значению поля «Код». Контрольная сумма вычисляется не только для ICMP-заголовка, но и для всего сообщения.

Таблица 5.12. Типы сообщений ICMP

сообщения	Описание
	Ответ на эхо (Echo Reply)
	Узел назначения недостижим (Destination Unreachable)
	Подавление источника (Source Quench)
	Перенаправление маршрута (Redirect)
	Запрос эха (Echo Request)
	Информация о маршрутизаторах (Router Advertisement)
	Регистрация маршрутизатора (Router Solicitation)
	Лимит времени для дейтаграммы превышен (Time Exceeded for a Data- gramm)
	Проблема с параметром пакета (Parameter Problem on a Datagramm)
	Запрос метки времени (Timestamp Request)
	Ответ для метки времени (Timestamp Reply)
	Запрос информации (не действует)
	Ответ на запрос информации (не действует)
	Запрос маски адреса (Address Mask Request)
	Ответ на запрос маски адреса (Address Mask Reply)

Типы сообщений ICMP представлены в табл. 5.12. Рассмотрим каждое из этих сообщений и его формат подробнее.

Тестирование достижимости места назначения. Протоколы TCP/IP обеспечивают средства, помогающие сетевым администраторам или пользо­вателям идентифицировать проблемы в сети. Пользователь в качестве одного из широко используемых средств отладки применяют команду, которая вызы­вает сообщения ICMP запроса эха и ответа эха. Компьютер или маршрутиза­тор посылает сообщение запроса эха указанному месту назначения. Любая машина, получившая запрос эха, генерирует ответ на эхо и возвращает его пер­воначальному отправителю. Этот запрос содержит необязательную область данных; ответ содержит копию данных, посланных в запросе. Запрос эха и свя­занный с ним ответ можно использовать для проверки достижимости назначе­ния и его способности отвечать на запросы. Так как и запрос эха, и ответ на него передаются в IP-дейтаграммах, успешный прием ответа свидетельству­ет о работоспособности основных частей транспортной системы. Во-первых, программное обеспечение IP на машине источника выполнило маршрутиза­цию дейтаграммы. Во-вторых, промежуточные маршрутизаторы между ис­точником и получателем работоспособны и корректно маршрутизируют дей­таграммы. В-третьих, машина получателя работает (по крайней мере, она обрабатывает прерывания) и программное обеспечение, как IP, так и ICMP, выполняет свои функции. И, наконец, таблицы маршрутов в маршрутизаторах на всем обратном пути корректны.

Во многих системах команда, которую пользователи вызывают для посыл­ки запроса эха ICMP, называется ping . Усложненные версии этой программы посылают серии запросов эха ICMP, принимают ответы и выдают статистику о потерях дейтаграмм. Они позволяют пользователю указывать длину посы­лаемых данных и интервалы времени между запросами. Менее сложные вер­сии просто посылают запрос эха ICMP и ждут ответа.

Формат сообщения запроса эха и ответа эха. Средства для тестирова­ния достижимости узлов сети представляют собой очень простой эхо-прото­кол, включающий обмен двумя типами сообщений: эхо-запрос и эхо-ответ. Ком­пьютер или маршрутизатор посылают по интерсети эхо-запрос, в котором указывают IP-адрес узла, достижимость которого нужно проверить. Узел, по­лучающий эхо-запрос, формирует и отправляет эхо-ответ и возвращает сооб­щение узлу - отправителю запроса. В запросе могут содержаться некоторые данные, которые должны быть возвращены в ответе.

Рис. 5.30 иллюстрирует формат сообщений запроса эха и ответа на запрос эха. Поле «Необязательные данные» имеет переменную длину и содержит дан­ные, которые надо вернуть отправителю. Ответ на эхо всегда возвращает те же самые данные, что были получены им в запросе. Поля «Идентификатор» и «Последовательный номер» отправитель использует для проверки соответствия ответов запросам. Значение поля «Тип» определяет, является ли сообщение запросом (8) или ответом (0).

Сообщения о недостижимости назначения. Когда маршрутизатор не может доставить IP-дейтаграмму, он посылает сообщение «назначение недо­стижимо» первоначальному отправителю, используя формат, приведенный на рис. 5.31. Поле «Код» в сообщении о недостижимости назначения содержит целое число, которое описывает причину. Возможные значения представлены в табл. 5.13.

Таблица 5.13. Коды сообщений о недостижимости

сообщения	Пояснения
	Сеть недостижима
	Компьютер недостижим
	Протокол недостижим
	Порт недостижим
	Необходима фрагментация
	Ошибка при маршрутизации источника
	Сеть назначения неизвестна
	Компьютер назначения неизвестен
	Компьютер источника изолирован
	Взаимодействие с сетью назначения административно запрещено
	То же с компьютером назначения
	Сеть недостижима из-за класса обслуживания
	Компьютер недостижим из-за класса обслуживания

Хотя протокол ЕР является механизмом ненадежной доставки, дейтаграм­мы не уничтожаются просто так. Всякий раз, когда ошибка мешает маршрути­затору произвести маршрутизацию или доставку дейтаграммы, маршрутиза­тор посылает сообщение о недостижимости назначения его источнику, а затем уничтожает дейтаграмму. Ошибки недостижимости сети обычно являются следствием ошибок маршрутизации; ошибки недостижимости компьютера - следствие ошибок при доставке.

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

Если дейтаграмма содержит опцию маршрутизации источника с некоррект­ным маршрутом, то это может привести к появлению сообщения об ошибке маршрутизации источника. Если шлюзу нужно фрагментировать дейтаграмму, но установлен бит «не фрагментировать», то шлюз посылает сообщение «тре­буется фрагментация» обратно источнику.

Управление потоком дейтаграмм и переполнение сети. Так как IP- протокол не устанавливает соединения, то маршрутизаторы не могут резерви­ровать память или коммуникационные ресурсы до получения дейтаграмм. В результате, трафик может вызвать перегрузку маршрутизаторов, ситуацию, на­зываемую переполнением сети (congestion). Переполнение сети происходит по двум совершенно разным причинам. Во-первых, высокоскоростной компью­тер может генерировать трафик быстрее, чем сеть может передавать его. На­пример, представим суперкомпьютер, генерирующий межсетевой трафик. Дей­таграммам, посылаемым им, может потребоваться передача, в конечном счете, по медленной глобальной сети (WAN), хотя сам суперкомпьютер может быть присоединен к высокоскоростной LAN. Переполнение будет возникать в мар­шрутизаторе, присоединенном к глобальной сети, так как дейтаграммы будут прибывать быстрее, чем их можно послать. Во-вторых, если большому числу компьютеров одновременно нужно посылать дейтаграммы через один марш­рутизатор, этот маршрутизатор может оказаться переполненным, хотя ни один источник в отдельности не вызывает эту проблему.

Когда дейтаграммы прибывают на шлюз или маршрутизатор быстрее, чем он успевает их обрабатывать, он временно ставит их в очередь в своей памя­ти. Если эти дейтаграммы создают небольшую пиковую нагрузку при переда­че дейтаграмм, то такая буферизация решает проблему. Если же трафик про­должает поступать, то, в конечном счете, маршрутизатор или шлюз займет всю память под очередь и вынужден будет удалять новые прибывающие дей­таграммы. Тогда машина для выхода из состояния переполнения использует сообщения о подавлении источника.

Сообщение о подавлении источника требует от источника уменьшить ско­рость передачи дейтаграмм. Обычно переполненные маршрутизаторы посы­лают по одному сообщению о подавлении источника на каждую удаляемую дейтаграмму или используют более сложные технологии выхода из переполне­ния. Формат подавления источника представлен на рис. S.32. Помимо обыч­ных полей ICMP «Тип», «Код» и «Контрольная сумма» и неиспользуемого 32-битового поля, сообщения о подавлении источника имеют поле, содержащее

префикс дейтаграммы. Как и в других сообщениях об ошибках ICMP поле префикса дейтаграммы содержит префикс дейтаграммы, вызвавшей этот зап­рос подавления источника.

Сообщения ICMP, вызывающего эффект, обратный подавлению источника, не существует. Вместо этого, компьютер, принявший сообщения о подавлении источника от некоторой машины, снижает скорость, с которой он посылает ей дейтаграммы. Это происходит до тех пор, пока к нему не перестанут прихо­дить сообщения о подавлении источника. Затем он постепенно увеличивает скорость пока снова не получит сообщения о подавлении источника.

Перенаправление маршрута. Маршрутные таблицы у компьютеров обыч­но статические, так как их конфигурирует администратор сети, а у маршрути­заторов - динамические, формируемые автоматически с помощью протоколов обмена маршрутной информации. Поэтому с течением времени при изменении топологии сети маршрутные таблицы компьютеров могут устаревать.

При изменении топологии сети таблицы маршрутизации в маршрутизаторе или компьютере могут стать некорректными. Изменение может быть времен­ным (например, нужно заменить неисправное оборудование) или постоянным (например, когда в межсетевое взаимодействие включается новая сеть). Мар­шрутизаторы периодически обмениваются информацией о маршрутизации, чтобы отслеживать изменения в сети и своевременно менять маршруты. Для корректировки поведения компьютеров маршрутизатор может использовать сообщение протокола ICMP, называемое «перенаправлением» (Redirect), зап­рашивающее изменение маршрута в таблице маршрутизации компьютера.

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

Преимуществом схемы перенаправления ICMP является ее простота: она позволяет компьютеру знать вначале адрес только одного маршрутизатора в локальной сети. Этот начальный маршрутизатор возвращает сообщение ICMP о перенаправлении всякий раз, когда компьютер посылает дейтаграмму, для которой существует лучший маршрут. Таблица маршрутизации компьютера останется маленькой, но содержит оптимальные маршруты для всех использу­емых назначений.

Сообщения о перенаправлении, тем не менее, не решают проблему распро­странения информации о маршрутах полностью, так как они предназначены только для взаимодействия между маршрутизатором и компьютером в одной физической сети. Каждое сообщение о перенаправлении содержит 32-битовое поле «IP-адрес маршрутизатора» и поле «Префикс дейтаграммы», как это по­казано на рис. 5.33.

Поле «Межсетевой адрес маршрутизатора» содержит IP-адрес маршрути­затора, который должен использовать компьютер при отправлении дейтаграм­мы к назначению, указанному в заголовке дейтаграммы. Поле «Префикс дей­таграммы» содержит заголовок IP и следующие 8 байт дейтаграммы, которая привела к появлению этого сообщения. Поэтому компьютер, принимающий сообщение о перенаправлении ICMP, должен выделить адрес назначения дей­таграммы из префикса дейтаграммы. Поле «Код» в сообщении о перенаправ­лении ICMP более конкретно указывает, как интерпретировать адрес назначе­ния, при этом значения имеют следующий смысл: 0 - перенаправление дейтаграмм для этой сети (устарело), 1 - перенаправление дейтаграмм для этого компьютера, 2 - перенаправление дейтаграмм для этого типа сервиса и сети, 3 - перенаправление дейтаграмм для этого типа сервиса и компьютера. Напомним, что каждый заголовок IP указывает тип сервиса, используемого при маршрутизации. Как правило, маршрутизаторы посылают запросы пере­назначения ICMP только на компьютеры, а не на другие маршрутизаторы.

Изменение маршрута является одной из наиболее интересных функций про­токола ICMP - по существу, это один из механизмов автоматической оптими­зации доставки пакетов и адаптации сетей TCP/IP к изменениям топологии.

Запросы «Информация о маршрутизаторах» (типы 9 и 10).

Информация о маршрутизации находится в местных конфигурационных фай­лах и загружается оттуда при запуске компьютера. Чтобы таблица маршрути­зации не содержала устаревших данных она обновляется динамически. ICMP- протокол реализует один из способов ее обновления.

Существует 2 типа сообщений маршрутизаторов:

9 - информация о маршрутизации;

10-регистрация маршрутизатора.

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

Формат сообщения «Информация о маршрутизации» (тип 9) описан в RFC 1256 (рис. 5.34).

В одном ICMP-сообщении может содержаться описание нескольких адре­сов, количество которых указано в поле «Количество адресов». Поле «Размер адреса» задает длину адреса в 32-битовых словах. В настоящее время «Длина поля адреса» всегда равна 2.

Поле «Время существования» задает интервал времени, в течение которо­го информация еще не устарела. Как правило, это 1800 с.

Поле «Приоритет» указывает, какой из адресов следует использовать пер­вым и более интенсивно. Как правило, чем больше значение поля, тем выше приоритет. Маршрутизаторы передают информационные сообщения широко­вещательно через случайные интервалы времени. Обычно через 450...600 с. Поле «Время существования» можно использовать для уведомления, что дан­ный маршрутизатор выключается. При этом содержимое данного поля уста­навливается равным 0.

Формат сообщения «Регистрация» (тип 10) представлен на рис. 5.35.

Запрос «Регистрация» передается 3 раза с интервалом 3 с при запуске мар­шрутизатора и продолжает (при необходимости) передаваться, пока маршру­тизатор не получит информационного сообщения с нужной маршрутной инфор­мацией.

Обнаружение циклических или слишком длинных путей. Как было от­мечено выше для защиты Интернета от перегрузок каждая дейтаграмма име­ет счетчик времени жизни TTL (Time-To-Live). Маршрутизатор декременти­рует счетчик времени жизни всякий раз, когда он обрабатывает дейтаграмму, и удаляет ее, когда счетчик становится нулевым.

Независимо от того, удалил ли маршрутизатор дейтаграмму из-за обнуле­ния счетчика времени жизни или из-за превышения времени ожидания фраг­ментов дейтаграммы, он посылает сообщение ICMP «Лимит времени для дейта­граммы превышен» источнику дейтаграммы определенного формата (рис. 5.36).

Поле «Код» объясняет причину сообщения: 0 - превышено значение счет­чика времени жизни; 1 - превышено время ожидания фрагмента при сборке.

Сообщения о других ситуациях. Когда маршрутизатор или компьютер стал­кивается с проблемой, не укладывающейся в рамки описанных сообщений об ошибках ICMP (например, некорректный заголовок дейтаграммы), связанной с дейтаграммой, он посылает сообщение «Проблема с параметром пакета» первоначальному отправителю. Такую ситуацию может вызвать некоррект­ность аргументов опции. Сообщение, формат которого показан на рис. 5.37, посылается только в том случае, если дейтаграмма должна быть удалена из- за этой ошибки. Для уточнения места ошибки в дейтаграмме отправитель ис­пользует поле «Указатель» в заголовке сообщения для идентификации октета в дейтаграмме, содержащего ошибку.

Синхронизация часов и оценка времени передачи. Стек протоколов TCP/IP включает несколько протоколов, которые могут использоваться для синхрони­зации часов. В сети для этого используется несколько технологий. Одна из про­стейших технологий реализуется сообщениями ICMP для получения значения времени от другой машины. Запрашивающая машина посылает сообщение ICMP «Запрос метки времени» другой машине, ожидая, что вторая машина вернет ей текущее значение времени. Принимающая машина возвращает «От­вет для метки времени» машине, выдавшей запрос. Рис. 5.38 иллюстрирует формат сообщений запроса и ответа временной метки. Поле «Тип» идентифи­цирует сообщение как запрос (13) или ответ (14); поля «Идентификатор» и «Пос­ледовательный номер» используют источник для связи между ответами и зап­росами. Оставшиеся поля специфицируют времена, указанные в миллисекундах после полуночи, по Гринвичу. Поле «Временная метка отправителя» заполняет

первоначальный отправитель перед передачей пакета, поле «Временная метка приема» заполняется сразу после приема запроса, а поле «Временная метка передачи» - непосредственно перед отправкой ответа.

Компьютеры используют эти три поля временных меток для определения ожидаемого времени передачи между ними и синхронизации своих часов. Так как ответ включает поле «Временная метка отправителя», компьютер может вычислить общее время, требуемое для передачи запроса к назначению, фор­мирования ответа на него и возвращения ответа. Так как ответ содержит как время прихода запроса на удаленную машину, так и время выдачи ответа, ком­пьютер может вычислить время передачи по сети, а на его основе - разницу между своими и удаленными часами. На практике бывает трудно точно оце­нить время передачи по сети, так как ГР является технологией с негарантиро­ванной доставкой, дейтаграммы могут бьггь потеряны, задержаны или достав­лены не по порядку, что ограничивает полезность сообщений ICMP о временных метках.

Сообщения запроса и ответа информации. Сообщения ICMP запроса информации и ответа информации (тип 15 и 16) в настоящее время устарели и их использовать не рекомендуется. Они предназначались для обнаружения компьютерами своих IP-адресов при загрузке. Сейчас для определения адреса используют протоколы RARP и ВООТР.

Получение маски подсети. Для применения адресации подсетей компью­теру надо знать, какие биты их 32-битного IP-адреса соответствуют физичес­кой сети, а какие - адресу компьютера. Информация, требуемая для интерпре­тации адреса, представляет собой 32-битовую величину, называемую маской подсети. Чтобы узнать маску подсети, используемую в локальной сети, маши­на может послать сообщение запроса маски адреса маршрутизатору и полу­чить ответ маски адреса. Машина, формирующая запрос, может либо послать сообщение напрямую, если она знает адрес маршрутизатора, либо послать ши­роковещательное сообщение, если не знает его. Рис. 5.39 иллюстрирует фор­мат сообщений маски адреса. Поле «Тип» в сообщении маски адреса указыва­ет, является ли сообщение запросом (17) или ответом (18). Ответ содержит маску адреса подсети в поле «Маска адреса». Как правило, поля «Идентифи­катор» и «Последовательный номер» позволяют машине связать ответ с зап­росом.