Протокол 1СМР

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

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

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

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

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

Сообщения ICMP требуют двух уровней инкапсуляции. На рис. 6.9 показана схема инкапсуляции сообщений ICMP в IP-дейтаграмму.

Сообщения ICMP начинаются с трех одинаковых полей:

q «Тип»,

q «Код»,

q «Контрольная сумма».

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

Поле «Тип» (длиной 8 байт) определяет смысл сообщения и его формат (табл. 6.5).

Сообщения «Ответ на эхо» и «Запрос эха» (типы 0, 8) помогают сетевым администраторам и пользователям идентифицировать возникающие в проблемы. Эти сообщения очень часто используются при отладке сети. За эха и ответ на него применяются для проверки достижимости получателя дейтаграммы и его способности отвечать на запросы. Так как эхо переда в IP-дейтаграммах, то успешный прием ответа свидетельствует о том, что основные части транспортной системы работоспособны, то есть: маршрутизация выполняется, все промежуточные маршрутизаторы функционируют, получа­тель активен и работает корректно, программное обеспечение протоколов IP и ICMP выполняет свои функции. Во многих системах программа, которую пользо­ватели используют для запроса эха, называется ping. На рис. 6.10 показан при­мер работы программы ping, входящей в стек протоколов Microsoft TCP/IP.

Таблица 6.5. Значения поля «Тип»

Значение поля	Тип сообщения ICMP
	Ответ на эхо
	Получатель недостижим
	Подавление источника
	Изменение маршрута(переназначение)
	Запрос эха
	Время жизни дейтаграммы истекло
	Ошибка параметра
	Запрос временной метки
	Передача временной метки
	Запрос маски адреса
	Ответ на запрос маски адреса

На рис. 6.11 показан формат сообщений запроса эха и ответа на него.

С:\ping ds.internic.net

Pinging ds.internic.net [192.20.239.132] with 32 bytes of data:

Reply from 192.20.239.132: bytes=32 time=101ms TTL=243

Reply from 192.20.239.132: bytes=32 time=100ms TTL=243

Reply from 192.20.239.132: bytes=32 time=120ms TTL=243

Reply from 192.20.239.132: bytes=32 time=120ms TTL=243

Рис. 6.10. Пример работы программы ping

Тип - 8 или 0 (8 бит)	Код - 0 (8 бит)	Контрольная сумма (16 бит)
Идентификатор (16 бит)	Номер (16 бит)
Необязательные данные
…

Рис. 6.11. Формат сообщения запроса эха и ответа на него

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

Сообщение «Получатель недостижим» (тип 3) посылается маршрутизатором, если он не может доставить IP-дейтаграмму по назначению. На рис. 6.12 пока­зан формат этого сообщения.

Тип - 3	Код - 0-12	Контрольная сумма (16 бит)
Не используется (должно быть равно 0) (32 бита)
IP-заголовок и первые 64 бита исходной дейтаграммы
…

Рис. 6.12. Формат сообщения «Получатель недостижим»

Это сообщение содержит поле «Код», которое показывает, почему IP-дейта­грамму не удается доставить получателю (табл. 6.6).

Таблица 6.6. Причины невозможности доставки (поле «Код»)

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

Получатель дейтаграммы может быть недостижим по следующим причинам:

q оборудование временно неработоспособно,

q указан несуществующий адрес получателя,

q маршрутизатор не имеет маршрута передачи,

q сеть недостижима из-за чрезмерной удаленности и т. д.

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

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

Тип—4	Код—0	Контрольная сумма (16 бит)
Не используется (должно быть равно 0) (32 бита)
IP-заголовок и первые 64 бита исходной дейтаграммы
…

Рис. 6.13. Формат сообщения «Подавление источника»

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

Тип - 5	Код - 0-3	Контрольная сумма (16 бит)
IP-адрес рекомендуемого маршрутизатора (32 бита)
IP-заголовок и первые 64 бита исходной дейтаграммы
…

Рис. 6.14. Формат сообщения «Изменение маршрута»

Каждое сообщение содержит 32-битовое поле «IP-адрес рекомендуемого маршрутизатора». Это поле содержит адрес маршрутизатора, который впредь должен использовать отправитель при отправке дейтаграмм по исходному IP-ад­ресу. Поле «IP-заголовок и первые 64 бита исходной дейтаграммы» содержит заголовок IP и первые 64 бита дейтаграммы, которая вызвала сообщение ICMP. Отправитель из этой дейтаграммы выделяет адрес устройства, которое либо на­ходится на неоптимальном маршруте, либо временно не работает. Поле «Код» в сообщении об изменении маршрута указывает более конкретную причину, кото­рая привела к появлению этого сообщения (табл. 6.7). Например, код 0 означает недоступность участка сети, код 1 — недоступность устройства, коды 2 и 3 — невозможность предоставления сервиса и т. д.

Таблица 6.7. Поле «Код» в сообщениях «Изменение маршрута»

Значение поля	Смысл сообщения
	Переадресация дейтаграммы для сети
	Переадресация дейтаграммы для устройства
	Переадресация дейтаграммы для типа сервиса и сети
	Переадресация дейтаграммы для типа сервиса и устройства

Сообщение ICMP «Время жизни дейтаграммы истекло» (тип 11) посылается отправителю при обнулении счетчика времени жизни дейтаграммы или при пре­вышении времени ожидания формирования фрагментов дейтаграммы. Такие со­общения возникают при слишком длинном пути до получателя дейтаграммы, когда времени жизни дейтаграммы не хватает для прохождения всего пути. На рис. 6.15 показан формат сообщения о превышении времени.

Тип—11	Код— 0-1	Контрольная сумма (16 бит)
Не используется (должно быть равно 0)
Заголовок IP и первые 64 бита исходной дейтаграммы
…

Рис. 6.15. Формат сообщения «Время жизни дейтаграммы истекло»

Поле «Код» объясняет причину возникновения сообщения (табл. 6.8).

Таблица 6.8. Поле «Код» в сообщениях «Время жизни дейтаграммы истекло»

Значение поля	Смысл сообщения
	Время жизни дейтаграммы истекло
	Истекло время ожидания фрагмента при сборке

Сообщение ICMP «Ошибка параметра» (тип 12) посылается маршрутизато­ром при обнаружении неправильного параметра в заголовке, что не позволяет завершить обработку дейтаграммы. При этом дейтаграмма уничтожается. Одной из причин возникновения этих сообщений могут быть неправильные аргументы в поле «Опции» заголовка IP-дейтаграммы. Сообщение посылается только в том случае, если ошибка приводит к ликвидации дейтаграммы. На рис. 6.16 показан формат сообщения «Ошибка параметра».

Поле «Указатель» необходимо для идентификации ошибочного байта в дей­таграмме.

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

Тип - 12	Код - 0-1	Контрольная сумма (16 бит)
	Указатель (8 бит)	Не используется (должно быть равно 0)
	IP-заголовок и первые 64 бита исходной дейтаграммы
	…

Рис. 6.16. Формат сообщения «Ошибка параметра»

Тип - 13 или 14	Код- 0	Контрольная сумма (16 бит)
Идентификатор (16 бит)	Номер (16 бит)
IP-заголовок и первые 64 бита исходной дейтаграммы (32 бита)
Временная метка отправителя (32 бита)
Временная метка приема (32 бита)
Временная метка передачи (32 бита)

Рис. 6.17. Формат сообщений запроса и передачи временной метки

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

Тип - 17 или 18	Код(0)	Контрольная сумма (16 бит)
Идентификатор (16 бит)	Номер (16 бит)
Маска адреса (32 бита)

Рис. 6.18. Формат сообшений запроса и передачи маски адреса

Поле «Тип» в сообщении указывает, является ли сообщение запросом (17) или ответом (18). В поле «Маска адреса» помещается ответ на запрос.

Дата добавления: 2015-07-13