Как называется утилита использующая icmp трафик. ICMP протокол диагностики перегрузки сети. Протоколы TCP, ICMP, UDP

Можно представить ряд ситуаций, когда протокол 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 - 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 – Значения поля Тип сообщения

ICMP (ang. Internet Control Message Protocol) - это один из протоколов сетевого уровня в модели ISO/OSI. Его задачей является обслуживание функции контроля правильности работы сети. С его помощью передаются всякого рода, низкоуровневые сводки, с раскроенными неправильностями во время сетевых связей. Практически целая коммуникация между данными компьютерами или другими устройствами при употреблении протокола ICMP происходит незаметным для конечнего пользователя образом. Единичными исключениями являются здесь инструменты ping и traceroute.
Коммуникация, ицпользующая протокол ICMP, состоит в пересылке подходящих информаций об ошибках, раскроенных во время связи между двумя устройствами. Одиночная информация существует в виде пакета, сформированного надлежащим образом (ang. Datagram), который следовательно будет подвергнутый инкапсуляции в рамке протокола IP. Протокол ICMP, вопреки всеобщему мнению, не использует в своей работе протоколы TCP, ни UDP. Итак, не пользуется никакими сетевыми портами.
Устройство пакета ICMP следующее:

Заголовок в 4 байтов - первый байт определяет тип пакета, второй - код операции, третий и четвёртый представляют собой контрольную сумму.
. Поле данных с долготой зависимой от типа пакета и его функции. В некоторых случаях может быть установленным с уровня инструмента, напр. догадливая команда ping в Виндоуз устанавливает размер данных пакета ECHO_REQUEST на 32 байта, а версия, встречающаяся в системах Юникс на 56 байтов.

Список некоторых типов сводок протокола ICMP:

Тип Значение

0 Echo Reply (поворот эха - "ответ на ping")
1 - 2 Забронированные
3 Destination Unreachable (недостожимость места предназначения)
4 Source Quench (сдержание отправителя)
5 Redirect Message (измени трассирование)
6 Alternate Host Address (альтернативный адрес хоста)
7 Забронированные
8 Echo Request (требование эха)
9 Router Advertisement (объявление маршрутизатора (рутера))
10 Router Solicitation (выбор рутера)
11 Time Exceeded (превышение лимита времени)
12 Parameter Problem (проблема с параметром)
13 Timestamp (требование временного шифра)
14 Timestamp Reply (поворот временного шифра)
15 Information Request (требование информации)
16 Information Reply (поворот информации)
17 Address Mask Request (требование адресной маски)
18 Address Mask Reply (поворот адресной маски)
19 Забронированные для безопасности
20 - 29 Забронированные
30 Traceroute (слежка трассы)
31 Datagram Conversion Error (ошибка конверсии дейтаграммы)
32 Mobile Host Redirect (изменение адреса мобильного узла)
33 IPv6 Where-Are-You (вопрос IPv6 "где ты")
34 IPv6 Here-I-Am (ответ IPv6 "я здесь")
35 Mobile Registration Request (просьба регистрировать мобильный узел)
36 Mobile Registration Reply (ответ на проьбу регистрировать мобильный узел)
37 Domain Name Request (требование названия домена)
38 Domain Name Reply (поворот названия домена)
39 SKIP Algorithm Discovery Protocol
40 Photuris, Security failures
41-255 Забронированные
Поле кода операции в заголовке пакета ICMP определяет вид содержания в сообщении, зависимого от его типа. Например, пакет типа 3, то есть Destination Unreachable может заключать следующие коды операции во втором байте заголовка:
0 Целевая сеть недостижимая
1 Целевое устройство (хост) недостижимое
2 Целевой протокол недостижимый (или необслуживаемый)
3 Целевой порт недостижимый
4 Пакет должен быть подвергнутый фрагментации, а установили флаг DF (не фрагментируй)
5 Traceroute неправильная
6 Неизвестная целевая сеть
7 Целевое устройство (хост) неизвестное
8 Хост отправителя недоступный
9 Доступ в сеть воспрещённый
10 Доступ в устройство воспрещённый
11 Установка поля Type of Service (в заголовке IP) делает невозможным доступ в целевую сеть
12 Установка поля Type of Service (в заголовке IP) делает невозможным доступ в целевую сеть
13 Коммуникация воспрещённая

Примеры работы протокола ICMP:

Ping - один из инструментов, выступающих практически в каждой операционной системе, обслуживающей протокол TCP/IP. С его помощью пакеты ICMP ECHO_REQUEST отправляются в целевой компьютер. Дистанционная машина, после получения такого сообщения должна ответить при помощи ECHO_REPLY. Поэтому можно определить следующее: Конфигурация сети делает возможной связь с дистанционной машиной, и оценку её нагрузки на основании информаций, касающихся количества потерянных пакетов и времени ответа.
. Traceroute - инструмент, делающий возможным определение, через какие маршрутизаторы проходит пакет по дороге к дистанционному компьютеру. Сначала, локальный компьютер посылает пакет ECHO_REQUEST в дистанционное устройство, с параметром ТТЛ (TTL -Time to Live), установленным на 1. Первый рутер уменьшает ТТЛ на один, значит до нуля, удаляет пакет и отсылает адресату сообщение ICMP TIME_EXCEEDED. Целевой компьютер, после получения такой информации, возобновляет высылку ECHO_REQUEST, но ц ТТЛ установленным на стоимость 2. Первый рутер уменьшает ТТЛ на 1, второй сделает то же самое, устанавливая 0, и вновь удалит пакет, и отошлёт сообщение TIME_EXCEEDED. Такая ситуация повтаряется так долго, что даже пакет доберётся до дистанционного комньютера, который тогда отошлёт отправителю сообщение ECHO_REPLY.

effort ), которая доставляет дейтаграмму от ее первоначального источника до ее конечного пункта назначения. Однако он имеет два дефекта: отсутствие контроля ошибок и отсутствие механизмов помощи в доставке.

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

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

Рис. 6.1.

Значение поля протокола в дейтаграмме IP - это "1", оно указывает, что данные IP - это ICMP -сообщение.

Типы сообщений

ICMP -сообщения разделены на две широкие категории: отчет об ошибке сообщения и запрос , как это показано на рис. 6.2.

Рис. 6.2.

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

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

Таблица 6.1. ICMP сообщения

Категория	Тип	Сообщение
Сообщения отчета об ошибках	3	Конечный пункт не достижим
	4	подавление источника
	11	Время истекло
	12	Проблемы параметров
	5	Переназначение
	8 или 0	Эхо запрос и ответ
	13 или 14	Метка времени запрос и ответ
	17 или 18	Маска адреса запрос и ответ
	10 или 9	Маршрутизатор затребование и извещение

Формат сообщения

ICMP -сообщение имеет 8-байтовый заголовок и раздел данных переменного размера. Хотя общий формат заголовка различен для каждого типа сообщения, первые 4 байта - общие для всех. Как показывает рис. 6.3. , первое поле , ICMP , определяет тип сообщения . Поле кода определяет основание для конкретного типа сообщения. Последнее общее поле – это поле контрольной суммы. Остальная часть заголовка задана для каждого типа сообщения.

Рис. 6.3.

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

Сообщения ошибки

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