Что такое icmp сообщение об ошибке

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

Сообщения об ошибках «пункт назначения недоступен»

Изначально ICMP требовался для того, чтобы маршрутизатор мог сообщить о проблемах при доставке пакета. Если маршрутизатор не в состоянии направить пакет по нужному пути, он генерирует сообщение об ошибке типа 3 и посылает его компьютеру-источнику. Поскольку генерация такого рода сообщений была основной задачей ICMP, сообщения «пункт назначения недоступен» имеют наибольшее количество вариантов. Шестнадцать (0—15) кодов ошибок сообщения «пункт назначения недоступен» приведены в табл. 3.6.

Таблица 3.6

Сообщения об ошибках ICMP типа пункт назначения недоступен

Код

Описание

0

Сеть недоступна (network unreacnable)

1

Компьютер недоступен (host unreachable)

2

Протокол недоступен (protocol unreachable)

3

Порт недоступен (port unreachable)

4

Фрагментация необходима, но запрещена (fragmentation needed and DF set)

5

Маршрутизация на заказ не удалась (source route failed)

6

Сеть назначения неизвестна (destination network unknown)

7

Компьютер назначения неизвестен (destination host unknown)

8

Компьютер-источник изолирован (устарело) (source host isolated)

9

Доступ в сеть назначения запрещен (destination network administratively prohibited)

10

Доступ в компьютер назначения запрещен (destination host administratively prohibited)

11

Для этого типа службы сеть недоступна (network unreachable ,for type-of-service, TOS)

12

Для этого типа службы компьютер недоступен (host unreachable for type-of-service, TOS)

13

Связь запрещена из-за фильтрации (communication administratively prohibited by filtering)

14

He соблюдается приоритет хоста (host precedence violation)

15

Снижение приоритета (precedence cutoff in effect)

Протокол IP не гарантирует доставку данных. С другой стороны, он почти всегда успешно справляется с доставкой. Если IP не удается доставить датаграмму, значит, возникла сетевая проблема, например ошибки при маршрутизации. Если вы внимательно изучили табл. 3.6, то, наверное, заметили, что большинство сообщений об ошибках относятся либо к компьютеру, либо к сети. Как правило, сообщения, относящиеся к компьютеру, означают проблему с доставкой, а сообщения, относящиеся к сети, — проблему с маршрутизацией. Так, например, код ошибки «сеть недоступна» означает проблему с маршрутизацией. На рис. 3.13 изображен формат ICMP-сообщения «пункт назначения недоступен».

Формат сообщения подобен общему формату, изображенному на рис. 3.12. Тип сообщения в поле типа равен трем, а поле кода (Code) соответствует коду ошибки от 0 до 15. Кроме того, в ICMP-сообщении содержится заголовок IР-датаграммы, вызвавшей его появление, и первые 64 бита (восемь байт) ее данных.

32 бита

Позиции битов

0                   7

8                   15

16                                              31

Тип (3)

Код (0-15)

Контрольная сумма

Не используется (заполняется нулями)

IP-заголовок, включая опции и первые 64 бита данных их первоначальной датаграммы

Рис. 3.13. Формат ICMP-сообщения «пункт назначения недоступен»

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

Сообщения об ошибках перенаправления

Чтобы выяснить, по какому маршруту послать пакет, переключатели пакетов TCP/IP пользуются таблицами маршрутизации. Маршрутизация пакета основывается на номере сети назначения, а идентификатор сети назначения — это часть IP-адреса. Каждый маршрутизатор знает своего соседа, то есть следующую «остановку», которых может быть несколько, на пути пакета данных. В некоторых случаях к определенной сети могут вести несколько маршрутов. Для постоянного слежения за состоянием сети маршрутизаторы периодически обмениваются сообщениями. Тем не менее таблицы маршрутизации обновляются не очень часто. Исходные данные для них хранятся в местных файлах конфигурации — это минимально необходимая для начала работы маршрутизатора информация, как правило, адрес другого маршрутизатора или шлюза.

Компьютеры обновляют свои таблицы, основываясь на информации от маршрутизаторов и сообщения о перенаправлении ICMP — один из способов решать эту задачу.

Предположим, что ваш компьютер посылает датаграмму на компьютер коллеги, расположенный, как показано на рис. 3.14, в другой физической сети. Чтобы послать датаграмму, необходимо обратиться к маршрутизатору. Предположим, что датаграмма посылается маршрутизатору номер 2. Исследовав свою таблицу, маршрутизатор обнаружит, что компьютер коллеги находится на расстоянии одного «прыжка» от маршрутизатора номер 1 и что именно ему следует послать датаграмму. В результате датаграмма отправляется к маршрутизатору номер 1.

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

32 бита

Позиции битов

0                    7

8                     15

16                                          31

Тип (5)

Код (0-3)

Контрольная сумма

IP-адрес маршрутизатора

IP-заголовок, включая опции и первые 64 бита данных их первоначальной датаграммы

Рис.

3.15. ICMP-сообщение о перенаправлении (тип 5)

Компьютер-передатчик выясняет, что следующие датаграммы лучше слать маршрутизатору, IP-адрес которого содержится в ICMP-сообщении. Другими словами, получив ICMP-сообщение о перенаправлении, ICMP-модуль компьютера должен исследовать содержимое заголовка IP-датаграммы (в теле сообщения) и IP-адрес маршрутизатора (второе 32-битное слово в заголовке сообщения). IP-заголовок даст адрес, по которому датаграммы шли неверным маршрутом, а IP-адрес маршрутизатора — тот маршрутизатор, который нужно использовать следующим. Эта информация может потребоваться для обновления таблицы маршрутизации сетевого компьютера. В табл. 3.7 приведены четыре кода сообщений о перенаправлении (тип 5). В примере на рис. 3.14 маршрутизатор пошлет сообщение типа 5 с кодом 1 (перенаправление для хоста).

Таблица 3.7

ICMP-сообщения об ошибках перенаправления (тип 5)

Код

Описание

0

Перенаправление для сети

1

Перенаправление для хоста (сетевого компьютера)

2

Перенаправление для сети по типу сетевой службы (TOS)

3

Перенаправление для хоста по типу сетевой службы (TOS)

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

Ошибки типа «лимит времени исчерпан»

Как известно, ошибки в таблицах маршрутизации могут привести к зацикливанию пакета между двумя маршрутизаторами. Это может случиться, когда каждый из них считает, что соседний маршрутизатор — наилучшее место для передачи пакета по назначению. Заголовок IP-датаграммы содержит специальное поле «время существования» (Time-to-Live, TTL), в котором время существования датаграммы ограничивается. Каждый маршрутизатор на пути пакета уменьшает время его существования. Время существования также уменьшается каждую секунду, которую пакет проводит во входной или выходной очереди маршрутизатора.

Как только время существования в поле TTL IP-датаграммы сравняется с нулем, сетевые программы уничтожат пакет и вышлют ICMP-сообщение «лимит времени исчерпан» (тип 11) компьютеру-источнику пакета. Формат ICMP-сообщения «лимит времени исчерпан» такой же, как у сообщения «пункт назначения недоступен», но поле Туре равно 11 вместо 3. Сообщения «лимит времени исчерпан» бывают двух видов, как показано в табл. 3.8. Код 0 устанавливается в случае, если датаграмма исчерпала время существования во время пересылки (например, из-за описанного выше зацикливания). Код 1 устанавливается, если произошел сброс таймера сборки фрагментов датаграммы до того, как все фрагменты прибыли.

Таблица 3.8

ICMP-сообщения об ошибках «лимит времени исчерпан» (тип 11)

Код

Описание

0

Поле время существования (TTL) сравнялось с нулем во время передачи датаграммы

1

Таймер сборки фрагментов истек

Когда компьютер-получатель принимает датаграмму с установленным флагом «фрагмент-продолжение», запускается таймер сборки фрагментов. Все фрагменты обязаны появиться до того, как этот таймер истечет. Если таймер истек, а датаграмма все еще не собрана, она уничтожается. В этом случае генерируется ICMP-сообщение типа 11 с кодом 1.

Ошибки «неверный параметр»

Компьютеры и маршрутизаторы высылают такое сообщение, если источник проблемы с маршрутизацией или доставкой неизвестен. Существуют два типа таких ICMP-сообщений, как показано в табл. 3.9.

Таблица 3.9

ICMP-сообщение об ошибке «неверный параметр» (тип 12)

Код

Описание

0

Неверный IP-заголовок

1

Необходимая опция отсутствует

Сообщение с кодом 1 генерируется, если датаграмма не содержит всех необходимых для нормальной работы TCP/IP атрибутов (опций). Предположим, вы разработали криптозащищенный протокол для работы с приложениями государственной важности. Если программа-клиент попытается передать запрос к серверу и не приложит специального секретного ключа к датаграмме, сервер ответит сообщением об ошибке типа «необходимая опция отсутствует». Сообщение типа «неверный IP-заголовок» генерируется во всех остальных случаях, когда источник ошибки невозможно распознать. На рис. 3.16 приведен формат сообщения ICMP «неверный параметр». Поле указателя (pointer) идентифицирует тот байт датаграммы, который привел к возникновению ICMP-сообщения. Для сообщений с кодом 1 («необходимая опция отсутствует») поле указателя равно нулю.

32 бита

Позиции битов

0                 7

8                    15

16                                        31

Тип (12)

Код (0-1)

Контрольная сумма

Указатель

Не используется (заполняется нулями)

IP-заголовок, включая опции и первые 64 бита данных их первоначальной датаграммы

Рис. 3.16. Формат ICMP -сообщения «неверный параметр» (тип 12)

Сообщение об ошибке «столкновение данных»

Механизм контроля потока данных гарантирует, что передатчик не будет передавать быстрее, чем приемник в состоянии принять и обработать. Другими словами, гарантируется, что входной буфер приемника не переполнится. Протокол TCP обеспечивает механизм управления потоком в качестве одной из сетевых служб. К сожалению, управление потоком возможно лишь тогда, когда протокол ориентирован на соединение. Поскольку IP не ориентирован на соединение, он не умеет управлять потоком данных. Поскольку маршрутизаторы работают на уровне IP, в их входных очередях может создаваться аналог транспортной пробки в часы пик в результате слишком большого количества вновь приходящих IP-пакетов. Если маршрутизатор не успевает обработать все приходящие пакеты, то «лишние» пакеты уничтожаются, а компьютеру-источнику пакета направляется ICMP-сообщение об ошибке «столкновение данных» (тип 4). Сообщение «столкновение данных» указывает компьютеру на необходимость снизить скорость передачи. На самом деле, механизм сообщений «столкновение данных» является некоторым подобием управления потоком данных на уровне IP. Для каждого уничтоженного в результате столкновения пакета, маршрутизатор высылает ICMP-сообщение. Как только компьютер получает его, он тут же снижает скорость передачи.

Если маршрутизатор продолжает передавать ICMP-сообщения «столкновение данных», компьютер продолжает снижать скорость передачи. Как только ICMP-сообщения перестают появляться, компьютер вновь начинает увеличивать скорость. И так до тех пор, пока не будет достигнута оптимальная скорость. Формат сообщения

ICMP «столкновение данных» тот же, что и у сообщения «пункт назначения недоступен», только поле типа имеет значение 4. Сообщение «столкновение данных» бывает только единственного вида, то есть поле кода у него всегда имеет значение 0 — других кодов не бывает.

2004 г.

4.4.4. Протокол передачи команд и сообщений об ошибках (ICMP)

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

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

  • передачу отклика на пакет или эхо на отклик;

  • контроль времени жизни дейтограмм в системе;

  • реализует переадресацию пакета;

  • выдает сообщения о недостижимости адресата или о некорректности параметров;

  • формирует и пересылает временные метки;

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

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

  • icmp-сообщение об ошибке.

  • При мультикастинг или широковещательной адресации.

  • Для фрагмента дейтограммы (кроме первого).

  • Для дейтограмм, чей адрес отправителя является нулевым, широковещательным или мультикастинговым.

Эти правила призваны блокировать потоки дейтограмм, посылаемым в отклик на мультикастинг или широковещательные ICMP-сообщения.

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

Рис. 4.4.4.1. Схема вложения ICMP-пакетов в Ethernet-кадр

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

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

icmp-сообщение

Описание сообщения
Тип Код
0   Эхо-ответ (ping-отклик)
3   Адресат недостижим
0 * Сеть недостижима
1 * ЭВМ не достижима
2 * Протокол не доступен
3 * Порт не доступен
4 * Необходима фрагментация сообщения
5 * Исходный маршрут вышел из строя
6 * Сеть места назначения не известна
7 * ЭВМ места назначения не известна
8 * Исходная ЭВМ изолирована
9 * Связь с сетью места назначения административно запрещена
10 * Связь с ЭВМ места назначения административно запрещена
11 * Сеть не доступна для данного вида сервиса
12 * ЭВМ не доступна для данного вида сервиса
13 * Связь административно запрещена с помощью фильтра.
14 * Нарушение старшинства ЭВМ
15 * Дискриминация по старшинству
4 0 * Отключение источника при переполнении очереди
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   Отклик на запрос адресной маски

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

Рис. 4.4.4.1. Схема вложения ICMP-пакетов в Ethernet-кадр

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

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

icmp-сообщение

Описание сообщения
Тип Код
0   Эхо-ответ (ping-отклик)
3   Адресат недостижим
0 * Сеть недостижима
1 * ЭВМ не достижима
2 * Протокол не доступен
3 * Порт не доступен
4 * Необходима фрагментация сообщения
5 * Исходный маршрут вышел из строя
6 * Сеть места назначения не известна
7 * ЭВМ места назначения не известна
8 * Исходная ЭВМ изолирована
9 * Связь с сетью места назначения административно запрещена
10 * Связь с ЭВМ места назначения административно запрещена
11 * Сеть не доступна для данного вида сервиса
12 * ЭВМ не доступна для данного вида сервиса
13 * Связь административно запрещена с помощью фильтра.
14 * Нарушение старшинства ЭВМ
15 * Дискриминация по старшинству
4 0 * Отключение источника при переполнении очереди
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   Отклик на запрос адресной маски

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

Рис. 4.4.4.2. Формат эхо-запроса и отклика ICMP

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

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

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

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

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

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

Рис. 4.4.4.3. Формат ICMP-сообщения «адресат не достижим»

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

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

Если буфер приема сообщения переполнен, ЭВМ посылает сообщение типа 4 для каждого из не записанных в буфер сообщений.

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

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

Рис. 4.4.4.4. Формат icmp-запроса снижения загрузки

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

Рис. 4.4.4.4. Формат icmp-запроса снижения загрузки

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

Рис. 4.4.4.5. Формат ICMP-запроса переадресации

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

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

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

Рис. 4.4.4.6. Формат ICMP-сообщений об имеющихся маршрутах

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

Рис. 4.4.4.6. Формат ICMP-сообщений об имеющихся маршрутах

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

Рис. 4.4.4.7 Формат запроса маршрутной информации

Так как следующий прогон (hop) дейтограммы определяется на основании локальной маршрутной таблицы, ошибки в последней могут привести к зацикливанию пакетов. Для подавления таких циркуляций используется контроль по времени жизни пакета (TTL). При ликвидации пакета по истечении TTL маршрутизатор посылает отправителю сообщение «время истекло», которое имеет формат (рис. 4.4.4.8):

Рис. 4.4.4.8. Формат сообщения «время (ttl) истекло»

Значение поля код определяет природу тайм-аута (см. табл. 4.4.4.1).

Когда маршрутизатор или ЭВМ выявили какую-либо ошибку, не из числа описанных выше (например, нелегальный заголовок дейтограммы), посылается сообщение «конфликт параметров». Это может произойти при неверных параметрах опций. При этом посылается сообщение вида (рис. 4.4.4.9):

Рис. 4.4.4.8. Формат сообщения «время (ttl) истекло»

Значение поля код определяет природу тайм-аута (см. табл. 4.4.4.1).

Когда маршрутизатор или ЭВМ выявили какую-либо ошибку, не из числа описанных выше (например, нелегальный заголовок дейтограммы), посылается сообщение «конфликт параметров». Это может произойти при неверных параметрах опций. При этом посылается сообщение вида (рис. 4.4.4.9):

Рис. 4.4.4.9. Формат сообщения типа «конфликт параметров»

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

В процессе трассировки маршрутов возникает проблема синхронизации работы часов в различных ЭВМ. К счастью синхронизация внутренних часов ЭВМ требуется не так часто (например, при выполнении синхронных измерений), негативную роль здесь могут играть задержки в каналах связи. Для запроса временной метки другой ЭВМ используется сообщение запрос временной метки, которое вызывает отклик с форматом (рис. 4.4.4.10):

Рис. 4.4.4.10. Формат ICMP-запроса временной метки

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

  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, как для локальной сети, так и для «окрестного» Интернет.

При работе с субсетью важно знать маску этой субсети. Как уже отмечалось выше, IP-адрес содержит секцию адреса ЭВМ и секцию адреса сети. Для получения маски субсети ЭВМ может послать «запрос маски» в маршрутизатор и получить отклик, содержащий эту маску. ЭВМ может это сделать непосредственно, если ей известен адрес маршрутизатора, либо прибегнув к широковещательному запросу. Ниже описан формат таких запросов-откликов (рис. 4.4.4.11).

Рис. 4.4.4.10. Формат ICMP-запроса временной метки

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

  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, как для локальной сети, так и для «окрестного» Интернет.

При работе с субсетью важно знать маску этой субсети. Как уже отмечалось выше, IP-адрес содержит секцию адреса ЭВМ и секцию адреса сети. Для получения маски субсети ЭВМ может послать «запрос маски» в маршрутизатор и получить отклик, содержащий эту маску. ЭВМ может это сделать непосредственно, если ей известен адрес маршрутизатора, либо прибегнув к широковещательному запросу. Ниже описан формат таких запросов-откликов (рис. 4.4.4.11).

Рис. 4.4.4.11. Формат запроса (отклика) маски субсети

Поле тип здесь специфицирует модификацию сообщения, тип=17 — это запрос, а тип=18 — отклик. Поля идентификатор и номер по порядку, как обычно, обеспечивают взаимную привязку запроса и отклика, а поле адресная маска содержит 32-разрядную маску сети.

Назад: 4.4.3.2. Качество обслуживание (QoS) в локальных сетях и не только
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.5. Протокол XTP

Начало

> Основы TCP/IP

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

Для передачи сообщений протокола ICMP по сети IP используются дейтаграммы обычного формата. Сообщение ICMP в данном случае помещается в поле DATA. Заголовок дейтаграммы, которая предназначена для переноса сообщений ICMP, имеет следующие значения полей:

  • SERVICE TYPE = 0
  • PROTOCOL = 1 (ICMP)
  • TIME TO LIVE – устанавливается в соответствии с типом сообщения в секундах
  • SOURCE IP ADDRESS – адрес источника сообщения ICMP
  • DESTINATION IP ADDRESS– адрес станции назначения для данного сообщения ICMP

Структура сообщения ICMP

TYPE ICMP Сообщение
0 Echo Reply
3 Destination Unreachable
4 Source Quench
5 Redirect
8 Echo Request
11 Time Exceeded
12 Parameter Problem
13 Timestamp Request
14 Timestamp Reply
15 Information Request
16 Information Reply
17 Address Mask Request
18 Address Mask Reply

Сообщение ICMP состоит из заголовка сообщения и собственно сообщения. Заголовок сообщения ICMP может занимать до 8 байтов – два 32-х разрядных слова. Собственно сообщение ICMP не имеет фиксированной длины, поэтому размер данного поля определяется типом сообщения. В заголовке сообщения  размещается идентификатор типа сообщения ICMP. В таблице приведены значения поля TYPE ICMP и типы сообщений, которые соответствуют этим значениям.

Сообщения ICMP можно условно разделить на парные и непарные. Парные сообщения состоят из двух компонентов – запрос (Request) и ответ (Reply). Сообщение типа ответ высылается станцией назначения только в ответ на полученное от источника сообщение типа запрос. К сообщениям такого типа относятся Echo Request/Reply. Непарные сообщения формируются асинхронно при возникновении какой либо проблемы при передаче дейтаграммы, и передается в адрес источника данной дейтаграммы. К сообщениям подобного типа относятся сообщения Destination Unreachable и Source Quench.

Сообщения ICMP

Структура заголовка сообщений ICMP

Заголовки всех сообщений ICMP имеют примерно одинаковый формат. В четырех первых байтах заголовка сообщений ICMP размещаются поля TYPE, CODE и CHECKSUM.

Поле TYPE

В этом поле заголовка сообщений ICMP размещается код, который соответствует типу сообщения.

Поле CODE

В поле CODE некоторых сообщений ICMP может быть размещен код  дополнительной диагностической
информации.

Поле CHECKSUM

В этом поле заголовка сообщений ICMP размещается контрольная сумма данного сообщения. Эта контрольная сумма вычисляется суммированием всех полей, начиная с поля TYPE. При вычислении контрольной суммы значение поля CHECKSUM полагается равным 0.

Сообщение Destination Unreachable

Сообщение Destination Unreachable (цель недоступна) — принадлежит к непарным  сообщениям ICMP. Это сообщение формируется в том случае, если запрошенный сетевой ресурс является недоступным для запрашивающей его станции.

0 7 15 31
TYPE=3 CODE=0…12 CHECKSUM
UNUSED=0
Internet Header+64 первых бита дейтаграммы

В поле CODE сообщения Destination Unreachable размещается код, который соответствует типу запрошенного недоступного сетевого ресурса или конкретизирует причину, из-за  которой  этот ресурс недоступен в данном случае.
Возможные значения поля CODE приведены в таблице:

CODE Значение
0 Network Unreachable
1 Host Unreachable
2 Protocol Unreachable
3 Port Unreachable
4 Fragmentation Need & DF set
5 Source Route Failed
6 Destination Network Unknown
7 Destination Host Unknown
8 Source Host Isolated
9 Communication with destination Network Administratively Prohibited
10 Communication with destination Host Administratively Prohibited
11 Network Unreachable for type of service
12 Host Unreachable for type of service

Сообщения данного типа могут быть сформированы как станцией назначения (CODE=2 и 3), так и одним из промежуточных маршрутизаторов – шлюзов (CODE=0,1,6 и т.д.). При этом в качестве адреса источника должен быть указан IP адрес узла, который обнаружил проблему. Например, сообщение №1 — Host Unreachable может быть сформировано последним маршрутизатором, который пытается доставить сообщение до хоста по непосредственно подключенной сети. Для того, чтобы станция – источник смогла правильно интерпретировать диагностическое сообщение, в тело сообщения Destination Unreachable помещается заголовок и первые 8 байт исходной дейтаграммы.

Сообщение Time Exceeded

Сообщение Time Exceeded – (истекло время) принадлежит к непарным сообщениям ICMP. Это сообщение должно
быть  сформировано в том случае, если в процессе передачи дейтаграммы истекло допустимое время её существования в сети или на хосте.

0 7 15 31
TYPE=11 CODE=0 или 1 CHECKSUM
UNUSED=0
Internet Header+64 первых бита дейтаграммы

Значение поля CODE в сообщении Time Exceeded используется для уточнения причины, по которой дейтаграмма прекратила существование:

  • CODE=0 — в процессе передачи дейтаграммы поле TTL приняло значение 0
  • CODE=1 – таймер дефрагментации установился в 0 до полной сборки принятого сообщения

Сообщение Parameter Problem

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

0 7 15 31
TYPE=12 CODE=0 или 1 CHECKSUM
POINTER UNUSED=0
Internet Header+64 первых бита дейтаграммы

В поле CODE данного сообщения размещается признак типа диагностической информации. В том случае, если в этом поле находится код «0», значение поля Pointer сообщения Parameter Problem соответствует номеру байта в заголовке исходного сообщения, который не может быть адекватно интерпретирован. Например, значение Pointer=1, в данном случае указывает на возникновение проблемы с интерпретацией поля Type Of Service исходного сообщения.

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

Сообщение Source Quench

Сообщение Source Quench – (сдерживание источника) принадлежит к непарным сообщениям ICMP. Это сообщение должно быть сформировано в том случае, если в процессе передачи дейтаграммы возникла угроза перегрузки.

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

0 7 15 31
TYPE=4 CODE=0 или 1 CHECKSUM
UNUSED=0
Internet Header+64 первых бита дейтаграммы

При передаче этого сообщения в качестве адреса назначения должен быть использован адрес IP источника первичного сообщения. Для того, чтобы станция – источник смогла правильно интерпретировать диагностическое сообщение, в тело сообщения Destination Unreachable помещается заголовок и первые 8 байт исходной дейтаграммы.

Сообщение Redirect

Сообщение Redirect – (изменение маршрута) принадлежит к непарным сообщениям ICMP. Это сообщение должно быть  сформировано в том случае, если при получении дейтаграммы шлюз обнаруживает, что для её передачи был выбран неудачный маршрут. На рисунке приведен пример использования сообщения Redirect для изменения неверного маршрута.

В данном случае хост А(10.40.0.2) отправляет дейтаграмму в направлении хоста В(10.10.0.2) используя для этого в качестве шлюза маршрутизатор R2. После того, как маршрутизатор R2 получает дейтаграмму, он определяет, что данная дейтаграмма адресована в направлении 10.10.0.0. Кратчайший маршрут для достижения этой сети для
маршрутизатора R2 лежит через маршрутизатор R4, который в данном случае подключен к тому сегменту сети, из которого была получена принятая дейтаграмма.

Маршрутизатор R2 направляет дейтаграмму по направлению R4 (красная стрелка на рисунке) и одновременно формирует сообщение ICMP Redirect, в котором он рекомендует хосту А впредь для передачи дейтаграмм в направлении сети использовать в качестве шлюза маршрутизатор R4.

0 7 15 31
TYPE=5 CODE=0/1/2/3 CHECKSUM
Gateway Internet Address
Internet Header+64 первых бита дейтаграммы

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

CODE Значение
0 Redirect Datagram for networks
1 Redirect Datagram for host
2 Redirect Datagram for the Type of service and networks
3 Redirect Datagram for the Type of service and host


Ссылки по теме:

  • RFC 792

Аннотация: Описан протокол ICMP и его приложения, контроль доступности и управление перегрузкой, типы и коды ICMP, протокол управления перегрузкой для дейтаграмм DCCP

Протокол передачи команд и сообщений об ошибках ( 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 значений).

Схема вложения ICMP-пакетов в Ethernet-кадр

Рис.
3.1.
Схема вложения ICMP-пакетов в Ethernet-кадр

По существу, значения полей типа и кода выполняют почти ту же функцию, что и порт в ТСР и 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 Отклик на запрос адресной маски

Формат эхо-запроса и отклика ICMP

Рис.
3.2.
Формат эхо-запроса и отклика ICMP

Рис.
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 msutower.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).

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

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

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

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

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

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

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

Формат ICMP-запроса снижения загрузки

Рис.
3.4.
Формат ICMP-запроса снижения загрузки

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

Формат ICMP-запроса переадресации

Рис.
3.5.
Формат ICMP-запроса переадресации

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

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

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

Формат ICMP-сообщений об имеющихся маршрутах

Рис.
3.6.
Формат ICMP-сообщений об имеющихся маршрутах

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

Формат запроса маршрутной информации

Рис.
3.7.
Формат запроса маршрутной информации

Если вы работаете с ОС Windows, а конфигурационными сетевыми параметрами являются IPадрес вашей ЭВМ, сетевая маска и адреса GW и DNS, то процедуры переадресации, скорее всего к вам отношения не имеют.

Так как следующий прогон (hop) дейтаграммы определяется на основании локальной маршрутной таблицы, ошибки в последней могут привести к зацикливанию пакетов. Причиной зацикливания могут быть и многие другие причины. Для подавления таких циркуляций используется контроль по времени жизни пакета (TTL). При ликвидации пакета по истечении TTL маршрутизатор посылает отправителю сообщение «время истекло», которое имеет формат (рис. 3.8):

Формат сообщения "время (TTL) истекло"

Рис.
3.8.
Формат сообщения «время (TTL) истекло»

Значение поля код определяет природу таймаута (см. табл. 3.1).

Когда маршрутизатор или ЭВМ выявили какую-либо ошибку, не из числа описанных выше (например, нелегальный заголовок дейтаграммы), посылается сообщение «конфликт параметров». Это может произойти, например, при неверных параметрах опций. В этом случае посылается сообщение вида (рис. 3.9):

Формат сообщения типа "конфликт параметров"

Рис.
3.9.
Формат сообщения типа «конфликт параметров»

Поле указатель отмечает октет дейтаграммы, который создал проблему. Код=1 применяется для сообщения о том, что отсутствует требуемая опция (например, опция безопасности при конфиденциальных обменах); поле указатель при значении поля код=1 не используется.

В процессе трассировки маршрутов возникает проблема синхронизации работы часов в различных ЭВМ. К счастью, синхронизация внутренних часов ЭВМ требуется не так часто (например, при выполнении синхронных измерений), негативную роль здесь могут играть задержки в каналах связи. Для запроса временной метки другой ЭВМ используется сообщение запрос временной метки, которое вызывает отклик с форматом (рис. 3.10):

Формат ICMP-запроса временной метки

Рис.
3.10.
Формат ICMP-запроса временной метки

Поле тип=13 указывает на то, что это запрос, а тип=14 — на то, что это отклик. Поле идентификатор и номер по порядку используются отправителем для связи запроса и отклика. Поле исходная временная метка заполняется отправителем непосредственно перед отправкой пакета. Поле временная метка на входе заполняется маршрутизатором при получении этого пакета, а временная метка на выходе — непосредственно перед его отправкой.

При работе с субсетью важно знать маску этой субсети. Как уже отмечалось выше, IPадрес содержит секцию адреса ЭВМ и секцию адреса сети. Для получения маски субсети ЭВМ может послать «запрос маски» в маршрутизатор и получить отклик, содержащий эту маску. ЭВМ может это сделать непосредственно, если ей известен адрес маршрутизатора, либо прибегнуть к широковещательному запросу. Ниже описан формат таких запросовоткликов (рис. 3.11).

Формат запроса (отклика) маски субсети

Рис.
3.11.
Формат запроса (отклика) маски субсети

Поле тип здесь специфицирует модификацию сообщения, тип=17 — это запрос, а тип=18 — отклик. Поля идентификатор и номер по порядку, как обычно, обеспечивают взаимную привязку запроса и отклика, а поле адресная маска содержит 32-разрядную маску сети.

Процесс интеграции услуг в Интернет несколько лет назад перешел в практическую плоскость и вслед за IPтелефонией, настала очередь цифрового телевидения. Главным транспортным средством для мультимедиа-данных является протокол UDP (RTP/RTCP). Но в протоколе UDP нет встроенных средств для подавления перегрузки. Возможность использования ICMP(4) трудно рассматривать всерьез, так как этот механизм достаточно груб и включается тогда, когда перегрузка уже привела к потере пакетов. Решить проблему управления перегрузкой в потоках без гарантии доставки должен новый протокол DCCP.

Internet Control Message Protocol (ICMP) is a network layer protocol used to diagnose communication errors by performing an error control mechanism. Since IP does not have an inbuilt mechanism for sending error and control messages. It depends on Internet Control Message Protocol(ICMP) to provide error control. 

ICMP is used for reporting errors and management queries. It is a supporting protocol and is used by network devices like routers for sending error messages and operations information. For example, the requested service is not available or a host or router could not be reached.

Uses of ICMP 

ICMP is used for error reporting if two devices connect over the internet and some error occurs, So, the router sends an ICMP error message to the source informing about the error. For Example, whenever a device sends any message which is large enough for the receiver, in that case, the receiver will drop the message and reply back ICMP message to the source.

Another important use of ICMP protocol is used to perform network diagnosis by making use of traceroute and ping utility. We will discuss them one by one.

Traceroute: Traceroute utility is used to know the route between two devices connected over the internet. It routes the journey from one router to another, and a traceroute is performed to check network issues before data transfer. 

Ping: Ping is a simple kind of traceroute known as the echo-request message, it is used to measure the time taken by data to reach the destination and return to the source, these replies are known as echo-replies messages.

How Does ICMP Work?

ICMP is the primary and important protocol of the IP suite, but ICMP isn’t associated with any transport layer protocol (TCP or UDP) as it doesn’t need to establish a connection with the destination device before sending any message as it is a connectionless protocol.

The working of ICMP is just contrasting with TCP, as TCP is a connection-oriented protocol whereas ICMP is a connectionless protocol. Whenever a connection is established before the message sending, both devices must be ready through a TCP Handshake.

ICMP packets are transmitted in the form of datagrams that contain an IP header with ICMP data. ICMP datagram is similar to a packet, which is an independent data entity. 

ICMP Packet Format

ICMP header comes after IPv4 and IPv6 packet header. 

In the ICMP packet format, the first 32 bits of the packet contain three fields:

Type (8-bit): The initial 8-bit of the packet is for message type, it provides a brief description of the message so that receiving network would know what kind of message it is receiving and how to respond to it. Some common message types are as follows:

  • Type 0 – Echo reply
  • Type 3 – Destination unreachable
  • Type 5 – Redirect Message
  • Type 8 – Echo Request
  • Type 11 – Time Exceeded
  • Type 12 – Parameter problem

Code (8-bit): Code is the next 8 bits of the ICMP packet format, this field carries some additional information about the error message and type.

Checksum (16-bit): Last 16 bits are for the checksum field in the ICMP packet header. The checksum is used to check the number of bits of the complete message and enable the ICMP tool to ensure that complete data is delivered.

The next 32 bits of the ICMP Header are Extended Header which has the work of pointing out the problem in IP Message. Byte locations are identified by the pointer which causes the problem message and receiving device looks here for pointing to the problem.

The last part of the ICMP packet is Data or Payload of variable length. The bytes included in IPv4 are 576 bytes and in IPv6, 1280 bytes.

ICMP in DDoS Attacks

In Distributed DOS (DDoS) attacks, attackers provide so much extra traffic to the target, so that it cannot provide service to users. There are so many ways through which an attacker executes these attacks, which are described below.

Ping of Death Attack

Whenever an attacker sends a ping, whose size is greater than the maximum allowable size, oversized packets are broken into smaller parts. When the sender re-assembles it, the size exceeds the limit which causes a buffer overflow and makes the machine freeze. This is simply called a Ping of Death Attack. Newer devices have protection from this attack, but older devices did not have protection from this attack.

ICMP Flood Attack

Whenever the sender sends so many pings that the device on whom the target is done is unable to handle the echo request. This type of attack is called an ICMP Flood Attack. This attack is also called a ping flood attack. It stops the target computer’s resources and causes a denial of service for the target computer.

Smurf Attack

Smurf Attack is a type of attack in which the attacker sends an ICMP packet with a spoofed source IP address. These type of attacks generally works on older devices like the ping of death attack.

Types of ICMP Messages

Type Code        Description
0 – Echo Reply 0 Echo reply
3 – Destination Unreachable 0 Destination network unreachable
1 Destination host unreachable
2 Destination protocol unreachable
3 Destination port unreachable
4 Fragmentation is needed and the DF flag set
5 Source route failed
5 – Redirect Message 0 Redirect the datagram for the network
1 Redirect datagram for the host
2 Redirect the datagram for the Type of Service and Network
3 Redirect datagram for the Service and Host
8 – Echo Request 0 Echo request
9 – Router Advertisement 0 Use to discover the addresses of operational routers
10 – Router Solicitation 0
11 – Time Exceeded 0 Time to live exceeded in transit
1 Fragment reassembly time exceeded.
12 – Parameter Problem 0 The pointer indicates an error.
1 Missing required option
2 Bad length
13 – Timestamp 0 Used for time synchronization
14 – Timestamp Reply 0 Reply to Timestamp message

Source Quench Message

A source quench message is a request to decrease the traffic rate for messages sent to the host destination) or we can say when receiving host detects that the rate of sending packets (traffic rate) to it is too fast it sends the source quench message to the source to slow the pace down so that no packet can be lost. 

ICMP will take the source IP from the discarded packet and inform the source by sending a source quench message. The source will reduce the speed of transmission so that router will be free from congestion.  

Source Quench Message with Reduced Speed

When the congestion router is far away from the source the ICMP will send a hop-by-hop source quench message so that every router will reduce the speed of transmission.

Parameter Problem

Whenever packets come to the router then the calculated header checksum should be equal to the received header checksum then only the packet is accepted by the router. 

If there is a mismatch packet will be dropped by the router. 

ICMP will take the source IP from the discarded packet and inform the source by sending a parameter problem message. 

Time Exceeded Message

When some fragments are lost in a network then the holding fragment by the router will be dropped then ICMP will take the source IP from the discarded packet and informs the source, of discarded datagram due to the time to live field reaching zero, by sending the time exceeded message.  

Destination Un-reachable

The destination is unreachable and is generated by the host or its inbound gateway to inform the client that the destination is unreachable for some reason. 

There is no necessary condition that only the router gives the ICMP error message time the destination host sends an ICMP error message when any type of failure (link failure, hardware failure, port failure, etc) happens in the network. 

Redirection Message

Redirect requests data packets are sent on an alternate route. The message informs a host to update its routing information (to send packets on an alternate route). 

Example: If the host tries to send data through a router R1 and R1 sends data on a router R2 and there is a direct way from the host to R2. Then R1 will send a redirect message to inform the host that there is the best way to the destination directly through R2 available. The host then sends data packets for the destination directly to R2. 
The router R2 will send the original datagram to the intended destination. 
But if the datagram contains routing information then this message will not be sent even if a better route is available as redirects should only be sent by gateways and should not be sent by Internet hosts. 

Whenever a packet is forwarded in the wrong direction later it is re-directed in a current direction then ICMP will send a re-directed message.

For more, you can refer to Types of ICMP (Internet Control Message Protocol) Messages.

FAQs

1. What is ICMP used for?

Internet Control Message Protocol (ICMP) is used for error reporting. Error Reporting by ICMP works by sending messages to the sender from the receiver in the case when data is not received.

2. Is ICMP the same as ping?

ICMP and ping are two different things, but they are somehow related. ICMP is a protocol that manages the messages between the devices and Ping is produced using ICMP.

3. How does ICMP ping work?

ICMP ping is a way to check whether there is a connection established between two devices on the internet. We can check packet loss or any delay that happens within the network with the help of ICMP ping.

Возможно, вам также будет интересно:

  • Что такое hl2 exe ошибка приложения
  • Что такое h81 0 directx ошибка
  • Что такое google process gapps произошла ошибка как исправить
  • Что такое game exe ошибка приложения
  • Что такое fix для исправления ошибки

  • Понравилась статья? Поделить с друзьями:
    0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии