Основные протоколы интернет

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

Разбить на страницы
Показывать лекцию целиком

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

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

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

(рис 6.1) Инкапсуляция сообщения ICMP

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

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

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

(рис 6.2) Сообщения ICMP

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

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

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

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

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

(рис 6.3) Основной формат ICMP

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

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

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

  • пункт назначения недостижим,
  • подавление источника,
  • время истекло,
  • проблемы параметра,
  • переназначение.
    •  (рис 6.4) Типы сообщений отчета об ошибках

    Все сообщения об ошибках содержат раздел данных (рис. 6.5), который включает заголовок IP первоначальной дейтаграммы плюс первые 8 байт данных в этой дейтаграмме. Первоначальный заголовок дейтаграммы добавляется, чтобы дать первоначальному источнику, который получает сообщение об ошибках, информацию непосредственно о самой дейтаграмме. Включены 8 байт данных, потому что, согласно форматам UDP- и TCP-протоколов, первые 8 байт обеспечивают информацию о номерах порта (UDP и TCP) и порядковом номере (TCP). Эта информация необходима, чтобы источник мог сообщить протоколам (TCP или UDP) об ошибке. ICMP формирует пакет данных об ошибке, который затем инкапсулируется в дейтаграмму IP (см. (рис. 6.5).

    (рис 6.5) Содержание поля данных для сообщения об ошибках

    Недостижимый пункт назначения

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

    (рис 6.6) Формат cообщения "конечный пункт недостижим"

    Поле кода для этого типа определяет причину для удаления дейтаграммы.

  • Код 0. Сеть недостижима, возможно, из-за аппаратного отказа. Этот тип сообщения может быть сгенерирован только маршрутизатором.
  • Код 1. Хост недостижим. Это может также произойти из-за аппаратного отказа. Этот тип сообщения может быть сгенерирован только маршрутизатором.
  • Код 2. Протокол недостижим. Дейтаграмма IP может доставить данные, принадлежащие протоколам высокого уровня, например, TCP или OSPF (Open Shortest Path First). Если хост пункта назначения получает дейтаграмму, которую нужно доставить, например, к протоколу TCP, но протокол TCP не функционирует в настоящее время, посылается сообщение с кодом 2. Этот тип сообщения генерируется только хостом пункта назначения.
  • Код 3. Порт недостижим. Прикладная программа (процесс), для которой предназначена дейтаграмма, не функционирует в настоящее время.
  • Код 4. Фрагментация требуется, но установлено поле дейтаграммы D (не фрагментировать). Другими словами, передатчик дейтаграммы определил, что дейтаграмма не фрагментирована, но маршрутизация невозможна без фрагментации.
  • Код 5. Исходная маршрутизация не может быть достигнута. Другими словами, один или более маршрутизаторов, определенных в исходной опции маршрутизации, не могут быть пройдены.
  • Код 6. Сеть пункта назначения неизвестна. Он отличается от кода 0. В коде 0 маршрутизатор знает, что сеть пункта назначения существует, но она в настоящее время недостижима. При коде 6 маршрутизатор не имеет никакой информации о сети пункта назначения.
  • Код 7. Хост пункта назначения неизвестен. Он отличается от кода 1. В коде 1 маршрутизатор знает, что хост пункта назначения существует, но в данный момент он недостижим. При коде 7 маршрутизатор не подозревает о существовании хоста пункта назначения.
  • Код 8. Хост источника изолирован.
  • Код 9. Связь с сетью пункта назначения административно запрещена.
  • Код 10. Связь с хостом пункта назначения административно запрещена.
  • Код 11. Сеть недостижима для указанного типа обслуживания. Этот код отличается от кода 0. Здесь маршрутизатор может направить дейтаграмму по новому маршруту, если источник запрашивал доступный тип обслуживания.
  • Код 12. Хост недостижим для указанного типа обслуживания. Он отличается от кода 1. Здесь маршрутизатор может направить дейтаграмму "в обход", если источник запросил доступный тип обслуживания.
  • Код 13. Хост недостижим, потому что администратор поместил его в фильтр.
  • Код 14. Хост недостижим, потому что у хоста нарушен приоритет. Сообщение посылается маршрутизатором, чтобы указать, что запрошенный для пункта назначения приоритет не разрешается.
  • Код 15. Хост недостижим, потому что его приоритет был отключен. Это сообщение возникает, когда сетевые операторы присвоили минимальный приоритет для работы сети, но дейтаграмму посылали с приоритетом ниже этого значения.
    •

    Заметим, что не достижимые пунктом назначения сообщения могут быть созданы или маршрутизатором, или хостом пункта назначения. Код 2 и код 3 сообщения могут быть созданы только хостом пункта назначения; сообщения остающихся кодов могут быть созданы только маршрутизаторами.

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

    Подавление источника

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

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

    Есть некоторые пункты, которые заслуживают более подробного пояснения.

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

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

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

    Превышение времени

    Сообщение о превышении времени генерируется в двух случаях.

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

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

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

    В сообщении превышения времени код 0 используется только маршрутизаторами, чтобы показать, что значение поля времени жизни — ноль. Код 1 применяется только хостом пункта назначения, чтобы показать, что в пределах установленного времени не прибыли все фрагменты.

    Проблемы параметров

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

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

    В общем формате для сообщения "проблемы параметров" используются в поле тип значение "12", а в поле код - "0" или "1". Во втором байте вводится 8-битовое поле указателя.

    Поле кода в этом случае определяет причину для отказа от дейтаграммы и показывает точно, что вышло из строя:

  • Код 0.Есть ошибка или неопределенность в одном из полей заголовка. В этом случае значение в поле указателя указывает на байт с проблемой. Например, если значение — ноль, то первый байт — недопустимое поле.
  • Код 1.Требуемая часть опции отсутствует. В этом случае указатель не используется.
    •

    Переназначение

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

    Однако хосты не принимают участие в процессе модификации таблиц маршрутизации, потому что хостов в Интернете намного больше, чем маршрутизаторов. Обновление таблиц маршрутизации хостов динамически создает недопустимый трафик. Хосты обычно используют статическую маршрутизацию. Когда хост возникает, его таблица маршрутизации имеет ограниченное число входов. Он обычно знает только адрес IP одного маршрутизатора, заданного по умолчанию. По этой причине хост может послать дейтаграмму, которая предназначена для другой сети, неправильному маршрутизатору. В этом случае маршрутизатор, который получает дейтаграмму, отправит дейтаграмму правильному маршрутизатору. Однако чтобы обновить таблицу маршрутизации хоста, он посылает сообщение переназначения хосту. Это понятие переназначения показано на рис. 6.7. Хост A хочет послать дейтаграмму хосту Б. Маршрутизатор R2 — очевидно самый эффективный выбор направления, но хост не выбрал маршрутизатор R2. Дейтаграмма вместо этого идет в R1. R1, после сравнения со своей таблицей, находит, что пакет должен был уйти в R2. Он посылает пакет R2 и, в то же самое время, посылает сообщение переназначения хосту А. Таблица маршрутизации хоста А может теперь быть модифицирована.

    (рис 6.7) Концепция переназначения

    Формат сообщения переназначения показан на рис. 6.8. Заметим, что IP-адрес соответствующего адресата дается во второй строке.

    (рис 6.8) Формат сообщения "переназначение"

    Хотя сообщение переназначения относится к сообщениям об ошибке, оно отличается от других сообщений этого класса. В этом случае маршрутизатор не удаляет дейтаграмму, а посылает ее соответствующему маршрутизатору. Поле кода для сообщения переназначения уточняет (детализирует) переназначение:

  • Код 0.Переназначение для заданного сетью маршрута.
  • Код 1.Переназначение для заданного хостом маршрута.
  • Код 2.Переназначение для заданного сетевого маршрута, основанного на указанном типе обслуживания.
  • Код 3.Переназначение для заданного хостом маршрута, основанного на указанном типе обслуживания.
    •

    Запрос

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

    (рис 6.9) Сообщения запроса

    Эхо-запрос и ответ

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

    Комбинация сообщений запроса эха и ответа эха определяет, могут ли две системы (хосты или маршрутизаторы) связаться друг с другом.

    Хост или маршрутизатор могут послать сообщение запроса эха другому хосту или маршрутизатору. Хост или маршрутизатор, который получает сообщение запроса эха, создает сообщение ответа эха и возвращает его первоначальному передатчику.

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

    Запрос эха и сообщения ответа эха могут также использоваться хостом, чтобы видеть, достижим ли другой хост. На пользовательском уровне это делается вызовом программы тестирования каналов сетей пакетной коммутации (утилита PING – Packet Internet Groper). Сегодня большинство систем включает в себя версии утилиты PING, которая может создать серию (вместо только одного) запросов эха и сообщений ответа эха, обеспечивая статистическую информацию.

    Запрос эха, вместе с ответом эха, может подтвердить, действительно ли узел функционирует должным образом. Узлу, который должен быть проверен, посылают сообщение запроса эха. Дополнительное поле данных содержит сообщение, которое должно быть повторено отвечающим узлом в его сообщении ответа эха. Рис. 6.10. показывает формат ответа эха и сообщения запроса эха. Идентификатор и поле порядкового номера формально не определены в соответствии с протоколом и могут использоваться произвольно передатчиком. Например, поле идентификатора может определить группу возникших проблем, а порядковый номер может сохранить запись метода обработки конкретных сообщений запроса эха, которые посылает передатчик. Идентификатор часто совпадает с ID процесса, который порождает запрос.

    (рис 6.10) Сообщение эхо–запроса и эхо-ответа

    Запрос метки времени и ответ

    Два устройства (хосты или маршрутизаторы) могут использовать запрос метки времени и сообщения запроса, метки времени и ответа, чтобы определить время прохождения "туда и обратно" (round–trip), необходимое для дейтаграммы IP. Он может также применяться, чтобы синхронизировать генераторы в двух устройствах. Формат этих двух сообщений показан на рис. 6.11.

    (рис 6.11) Формат сообщения метки времени – запроса и метки времени - ответа

    Три поля метки времени — каждый 32 бита длиной. Каждое поле может содержать число, которое представляет время, измеренное в миллисекундах от полуночи Универсального времени (прежде называемое Значением времени по Гринвичу). (Заметим, что 32 бита могут представлять числа от 0 до 4,294,967,295, но метка времени в данном случае не может превысить 86 400 000 = 24 x 60 x 60 x 1000.)

    Источник создает сообщение запроса метки времени. Источник заполняет поле исходной метки времени значением Универсального времени в соответствии с показанием своих часов во время отправления. Другие два поля метки времени заполнены нулями.

    Пункт назначения создает сообщение ответа метки времени. Пункт назначения копирует первоначальное значение метки времени с сообщения запроса в то же самое поле в его сообщении ответа. Затем заполняет поле метки времени получения значением Универсального времени по показанию его часов в тот момент времени, когда запрос был получен. Наконец, он заполняет поле метки времени отправления значением Универсального времени по показанию его часов в тот момент времени, в который сообщение ответа отбывает.

    Запрос метки времени и сообщения ответа метки времени могут использоваться, чтобы вычислить одностороннее время или время прохождения туда и обратно, требуемое для дейтаграммы, чтобы пройти от источника до пункта назначения и затем опять назад. Формулы следующие:

    Время передачи = значение метки времени получения – значение первоначальной метки времени;

    Время приема = время возвращения пакета – значение передачи метки времени;

    Время прохождения туда и обратно = время передачи + время получения.

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

    Например, учитывая следующую информацию:

    Значение первоначальной метки времени: 46;

    Значение метки времени получения: 59;

    Значение метки времени отправления: 60;

    Время прибытия пакета: 67;

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

    Время передачи = 59 – 46 = 13 миллисекунд;

    Время получения = 67 – 60 = 7 миллисекунд.

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

    Разница во времени = метки времени получения – -(исходная метка времени + односторонняя продолжительность времени).

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

    Разница во времени = 59 – (46 + 10) = 3.

    Запрос маски адреса и ответ

    Адрес IP хоста содержит сетевой адрес, адрес подсети и идентификатор хоста. Хост может знать свой полный адрес IP, но он не может знать, какая часть адреса определяет сетевой и адрес подсети и какая часть соответствует идентификатору хоста. Например, хост может знать свой адрес IP на 32 бита как

    10011111 00011111 11100010 10101011

    Но он не знает, что левые 20 битов — сетевые и адреса подсети, и остающиеся 12 бит — его идентификатор хоста. В этом случае хост нуждается в следующей маске:

    11111111 11111111 11110000 00000000

    Единицы в маске идентифицируют позицию битов, используемых для сетевого идентификатора (netid) и идентификатора сети (subnetid). Нули идентифицируют позицию битов для хоста (hostid). Например, применяя вышеупомянутую маску к вышеупомянутому адресу, мы имеем

    Чтобы получить свою маску, хост посылает сообщение запроса маски адреса маршрутизатору местной сети (LAN). Если хост знает адрес маршрутизатора, он посылает запрос непосредственно маршрутизатору, если не знает, передает сообщение широковещательно. Маршрутизатор, получающий адрес, — сообщение запроса маски — отвечает с сообщением ответа маски адреса, обеспечивая необходимую маску для хоста. Она может быть применена к полному IP-адресу, чтобы получить его адрес подсети.

    Формат запроса маски адреса и ответа маски адреса показан на рисунке 6.12. Поле маски адреса в сообщении запроса заполнено нолями. Когда маршрутизатор посылает ответ маски адреса назад хосту, это поле содержит фактическую маску (единицы для netid и subnetid и нули для hostid).

    (рис 6.12) Формат сообщения запрос и ответ маски

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

    Когда станция впервые загружается извне, она может запросить свой полный IP-адрес, используя протокол определения сетевого адреса по местоположению – RARP (этот протокол мы рассмотрим далее). После получения своего IP-адреса она может использовать запрос маски адреса и ответ, чтобы узнать, какая часть адреса определяет подсеть.

    Ходатайство маршрутизатора и извещение

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

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

    (рис 6.13) Формат сообщения о связях маршрутизатора

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

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

    В ICMP контрольная сумма вычисляется по полному сообщению (заголовок и данные).

    Вычисление контрольной суммы

    Передатчик выполняет следующие шаги, используя арифметику дополнения единицами:

  • Поле контрольной суммы устанавливается на ноль.
  • Вычисляется сумма всех слов на 16 бит (заголовок и данные).
  • Сумма дополняется, чтобы получить контрольную сумму.
  • Контрольная сумма сохраняется в поле контрольной суммы.
    •

    Испытание контрольной суммы

    Приемник выполняет следующие шаги, используя арифметику дополнения единицами:

  • Вычисляется сумма всех слов (заголовок и данные).
  • Сумма дополняется.
  • Если результат, полученный в шаге 2, — 16 нулей, сообщение принято; иначе — оно удаляется.
    •

    Алгоритмы работы модулей блок-схемы ICMP

    В данном случае рассматривается упрощенная версия блок-схемы, состоящая из двух модулей. Рис. 6.14. показывает эти два модуля.

    (рис 6.14) Блок-схема модулей ICMP

    Основные алгоритмы работы модулей ICMP даны на рис. 6.15., рис. 6.16.

    (рис 6.16) Алгоритм работы модуля ввода ICMP(рис 6.15) Алгоритм работы модуля вывода ICMP

    Входной модуль

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

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

    Модуль вывода

    Модуль вывода отвечает за создание запроса ходатайства или сообщения об ошибках, которые нужны протоколам более высокого уровня или протоколам IP. Модуль получает запрос от IP, UDP или TCP, чтобы послать одно из ICMP-сообщений об ошибках. Если запрос от IP, модуль вывода должен сначала проверить, что запрос разрешен. Напомним, что ICMP-сообщение не может быть создано для четырех ситуаций: для пакета IP, несущего сообщение об ошибках ICMP; для фрагментированного пакета IP; для пакетов IP, рассылаемых по многим адресам; или для пакета IP, имеющего адрес IP 0.0.0.0 или 127.X.Y.Z. Алгоритм работы модуля показан на рис.6.16.

    Можно отметить, что модуль вывода (оператор 1 на рис. 6.16) может также получить запрос от прикладной программы, чтобы послать один из запросов ICMP или сообщений ходатайства.

    Краткие итоги

  • Протокол управления сообщениями Интернета (ICMP – Internet Control Message Protocol) был разработан для устранения недостатков протокола IP — отсутствия контроля ошибок и отсутствия механизмов помощи в доставке.
  • ICMP-сообщения разделены на две широких категории: отчет об ошибке сообщения и запрос.
  • Сообщение об ошибке переносит данные о проблемах, возникающих при обмене сообщениями, с которыми маршрутизатор или хост (пункт назначения) могут столкнуться, когда они обрабатывают пакет IP.
  • Сообщения запроса помогают хосту или сетевому менеджеру получить заданную информацию от маршрутизатора или другого хоста.
  • Обрабатываются пять типов ошибок: пункт назначения недостижим, подавление источника, время истекло, проблемы параметра, переназначение.
  • Сообщение "конечный пункт недостижим" посылается, когда маршрутизатор не может выбрать маршрут дейтаграмме или хост не может доставить дейтаграмму, она отклоняется и маршрутизатор или хост посылает назад к хосту источника, который ввел дейтаграмму.
  • Сообщение подавления источника посылается источнику, когда маршрутизатор или хост удаляет дейтаграммы из-за перегрузки.
  • Сообщение о превышении времени генерируется в двух случаях: Первый случай — когда пакет перемещается по петле или в цикле. Второй случай — когда все фрагменты, которые составляют сообщение, не достигают хоста пункта назначения в пределах некоторого срока.
  • Если маршрутизатор или хост пункта назначения обнаруживают неоднозначное или отсутствующее значение в любом поле дейтаграммы, он удаляет его из дейтаграммы и посылает назад к источнику сообщение о проблемах параметра.
  • Чтобы обновить таблицу маршрутизации, хост посылает сообщение переназначения другому хосту.
  • В дополнение к сообщению ошибки, ICMP может также диагностировать некоторые сетевые проблемы. Это достигается с помощью сообщения запроса.
  • Комбинация сообщений запроса эха и ответа эха определяет, могут ли две системы (хосты или маршрутизаторы) связаться друг с другом.
  • Два устройства (хосты или маршрутизаторы) могут использовать запрос метки времени и сообщения запроса, метки времени и ответа, чтобы определить время прохождения "туда и обратно" (round–trip), необходимое для дейтаграммы IP.
  • Адрес IP хоста содержит сетевой адрес, адрес подсети и идентификатор хоста. Хост может знать свой полный адрес IP, но он не может знать, какая часть адреса определяет сетевой и адрес подсети и какая часть соответствует идентификатору хоста. В этом случае хост нуждается в маске.
  • Ходатайство маршрутизатора и сообщения извещения маршрутизатора могут помочь узнать, являются ли маршрутизаторы действующими и исправными.
  • Блок-схема модулей ICMP содержит два модуля: модуль ввода и модуль вывода.
    •

    Задачи и упражнения

  • Хост A посылает запрос метки времени к хосту B и не получает ответ. Обсудите три возможных случая и соответствующие им действия.
  • IP-адрес рабочей станции – 198.123.46.219. Если маска подсети 255.255.255.192, каков идентификатор подсети? К какому классу принадлежит сеть?
  • Почему имеется ограничение на генерацию ICMP-сообщения в ответ на ошибочное ICMP-сообщение об ошибках?
  • Хост A посылает дейтаграмму хосту B. Хост B не получает дейтаграмму, а хост A не получает извещение об ошибке. Дайте два варианта объяснения, как это может произойти.
  • Какая цель включения IP-заголовка и 8 первых байт данных дейтаграммы в сообщение "отчет об ошибках"?
  • Каково максимальное значение указателя поля в сообщении "проблема параметров"?
  • Приведите примеры ситуаций, в которых никогда не будет получено сообщение "переназначение".
  • Составьте таблицу, показывающую, какие ICMP-сообщения посылаются маршрутизатором, какие — промежуточным хостом и какие — пунктом назначения.
  • Может ли вычисление времени передачи, времени приема, времени получения или времени передачи и приема (туда и обратно) иметь отрицательное значение? Почему да или почему нет? Приведите примеры.
  • Почему время прохождения пакета в одну сторону не равно времени прохождения "туда и обратно", деленному на два?
  • Каков минимальный размер IP-пакета? Каков максимальный размер IP-пакета?
  • Как можно определить пакет IP, если он включает в себя ICMP-сообщение?
  • Вычислите контрольную сумму для следующего ICMP-пакета:

    Тип: Эхо-запрос, Идентификатор: 123, Порядковый номер: 25, Сообщение: Hello.

  • Маршрутизатор получает IP-пакет с адресом источника 130.45.3.3 и адресом пункта назначения 201.23.4.6. Маршрутизатор не может найти адрес в таблице маршрутизации. Заполните поле IP-адреса пункта назначения (насколько вы можете) для сообщения ICMP.
  • TCP получает сегмент с адресом пункта назначения 234. TCP проверяет и не может найти порт, открытый для этого пункта назначения. Заполните поле для посылаемого в этом случае ICMP-сообщения.
  • ICMP-сообщение поступает с заголовком (шестнадцатеричным):
    03 0310 20 00 00 00 00
    Каков тип сообщения? Какой код? Какова цель сообщения?
  • Компьютер посылает запрос метки времени. Если его часы показывают 5:20:30 утра (Универсальное время), покажите входное сообщение.
  • Повторите 17 для времени 15:40: 30 (Универсальное время).
  • Компьютер получает запрос метки времени от другого компьютера в 14:34:20. Значение исходной метки времени 52,453,000. Если часы передатчика на 5 мсек. медленнее, каково время передачи в одну сторону?
  • Компьютер посылает запрос метки времени к другому компьютеру. Он получает соответствующую метку времени ответа 3:46:07. Значения исходной метки, полученной метки и промежуточной метки — 13,560,000, 13,562,000, 13,565,300 соответственно. Каково время распространения при передаче? Каково время получения? Какое время туда и обратно? Какова разность между генератором передатчика и приемника?
  • Два компьютера находятся на расстоянии 8000 км. Каково минимальное время для прохождения сообщения от одного к другому?
    •

    Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.

    Страницы:

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

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

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

    (рис 6.1) Инкапсуляция сообщения ICMP

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

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

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

    (рис 6.2) Сообщения ICMP

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

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

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

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

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

    (рис 6.3) Основной формат ICMP

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

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

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

  • пункт назначения недостижим,
  • подавление источника,
  • время истекло,
  • проблемы параметра,
  • переназначение.
    •  (рис 6.4) Типы сообщений отчета об ошибках

    Все сообщения об ошибках содержат раздел данных (рис. 6.5), который включает заголовок IP первоначальной дейтаграммы плюс первые 8 байт данных в этой дейтаграмме. Первоначальный заголовок дейтаграммы добавляется, чтобы дать первоначальному источнику, который получает сообщение об ошибках, информацию непосредственно о самой дейтаграмме. Включены 8 байт данных, потому что, согласно форматам UDP- и TCP-протоколов, первые 8 байт обеспечивают информацию о номерах порта (UDP и TCP) и порядковом номере (TCP). Эта информация необходима, чтобы источник мог сообщить протоколам (TCP или UDP) об ошибке. ICMP формирует пакет данных об ошибке, который затем инкапсулируется в дейтаграмму IP (см. (рис. 6.5).

    (рис 6.5) Содержание поля данных для сообщения об ошибках

    Недостижимый пункт назначения

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

    (рис 6.6) Формат cообщения "конечный пункт недостижим"

    Поле кода для этого типа определяет причину для удаления дейтаграммы.

  • Код 0. Сеть недостижима, возможно, из-за аппаратного отказа. Этот тип сообщения может быть сгенерирован только маршрутизатором.
  • Код 1. Хост недостижим. Это может также произойти из-за аппаратного отказа. Этот тип сообщения может быть сгенерирован только маршрутизатором.
  • Код 2. Протокол недостижим. Дейтаграмма IP может доставить данные, принадлежащие протоколам высокого уровня, например, TCP или OSPF (Open Shortest Path First). Если хост пункта назначения получает дейтаграмму, которую нужно доставить, например, к протоколу TCP, но протокол TCP не функционирует в настоящее время, посылается сообщение с кодом 2. Этот тип сообщения генерируется только хостом пункта назначения.
  • Код 3. Порт недостижим. Прикладная программа (процесс), для которой предназначена дейтаграмма, не функционирует в настоящее время.
  • Код 4. Фрагментация требуется, но установлено поле дейтаграммы D (не фрагментировать). Другими словами, передатчик дейтаграммы определил, что дейтаграмма не фрагментирована, но маршрутизация невозможна без фрагментации.
  • Код 5. Исходная маршрутизация не может быть достигнута. Другими словами, один или более маршрутизаторов, определенных в исходной опции маршрутизации, не могут быть пройдены.
  • Код 6. Сеть пункта назначения неизвестна. Он отличается от кода 0. В коде 0 маршрутизатор знает, что сеть пункта назначения существует, но она в настоящее время недостижима. При коде 6 маршрутизатор не имеет никакой информации о сети пункта назначения.
  • Код 7. Хост пункта назначения неизвестен. Он отличается от кода 1. В коде 1 маршрутизатор знает, что хост пункта назначения существует, но в данный момент он недостижим. При коде 7 маршрутизатор не подозревает о существовании хоста пункта назначения.
  • Код 8. Хост источника изолирован.
  • Код 9. Связь с сетью пункта назначения административно запрещена.
  • Код 10. Связь с хостом пункта назначения административно запрещена.
  • Код 11. Сеть недостижима для указанного типа обслуживания. Этот код отличается от кода 0. Здесь маршрутизатор может направить дейтаграмму по новому маршруту, если источник запрашивал доступный тип обслуживания.
  • Код 12. Хост недостижим для указанного типа обслуживания. Он отличается от кода 1. Здесь маршрутизатор может направить дейтаграмму "в обход", если источник запросил доступный тип обслуживания.
  • Код 13. Хост недостижим, потому что администратор поместил его в фильтр.
  • Код 14. Хост недостижим, потому что у хоста нарушен приоритет. Сообщение посылается маршрутизатором, чтобы указать, что запрошенный для пункта назначения приоритет не разрешается.
  • Код 15. Хост недостижим, потому что его приоритет был отключен. Это сообщение возникает, когда сетевые операторы присвоили минимальный приоритет для работы сети, но дейтаграмму посылали с приоритетом ниже этого значения.
    •

    Заметим, что не достижимые пунктом назначения сообщения могут быть созданы или маршрутизатором, или хостом пункта назначения. Код 2 и код 3 сообщения могут быть созданы только хостом пункта назначения; сообщения остающихся кодов могут быть созданы только маршрутизаторами.

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

    Подавление источника

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

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

    Есть некоторые пункты, которые заслуживают более подробного пояснения.

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

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

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

    Превышение времени

    Сообщение о превышении времени генерируется в двух случаях.

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

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

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

    В сообщении превышения времени код 0 используется только маршрутизаторами, чтобы показать, что значение поля времени жизни — ноль. Код 1 применяется только хостом пункта назначения, чтобы показать, что в пределах установленного времени не прибыли все фрагменты.

    Проблемы параметров

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

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

    В общем формате для сообщения "проблемы параметров" используются в поле тип значение "12", а в поле код - "0" или "1". Во втором байте вводится 8-битовое поле указателя.

    Поле кода в этом случае определяет причину для отказа от дейтаграммы и показывает точно, что вышло из строя:

  • Код 0.Есть ошибка или неопределенность в одном из полей заголовка. В этом случае значение в поле указателя указывает на байт с проблемой. Например, если значение — ноль, то первый байт — недопустимое поле.
  • Код 1.Требуемая часть опции отсутствует. В этом случае указатель не используется.
    •

    Переназначение

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

    Однако хосты не принимают участие в процессе модификации таблиц маршрутизации, потому что хостов в Интернете намного больше, чем маршрутизаторов. Обновление таблиц маршрутизации хостов динамически создает недопустимый трафик. Хосты обычно используют статическую маршрутизацию. Когда хост возникает, его таблица маршрутизации имеет ограниченное число входов. Он обычно знает только адрес IP одного маршрутизатора, заданного по умолчанию. По этой причине хост может послать дейтаграмму, которая предназначена для другой сети, неправильному маршрутизатору. В этом случае маршрутизатор, который получает дейтаграмму, отправит дейтаграмму правильному маршрутизатору. Однако чтобы обновить таблицу маршрутизации хоста, он посылает сообщение переназначения хосту. Это понятие переназначения показано на рис. 6.7. Хост A хочет послать дейтаграмму хосту Б. Маршрутизатор R2 — очевидно самый эффективный выбор направления, но хост не выбрал маршрутизатор R2. Дейтаграмма вместо этого идет в R1. R1, после сравнения со своей таблицей, находит, что пакет должен был уйти в R2. Он посылает пакет R2 и, в то же самое время, посылает сообщение переназначения хосту А. Таблица маршрутизации хоста А может теперь быть модифицирована.

    (рис 6.7) Концепция переназначения

    Формат сообщения переназначения показан на рис. 6.8. Заметим, что IP-адрес соответствующего адресата дается во второй строке.

    (рис 6.8) Формат сообщения "переназначение"

    Хотя сообщение переназначения относится к сообщениям об ошибке, оно отличается от других сообщений этого класса. В этом случае маршрутизатор не удаляет дейтаграмму, а посылает ее соответствующему маршрутизатору. Поле кода для сообщения переназначения уточняет (детализирует) переназначение:

  • Код 0.Переназначение для заданного сетью маршрута.
  • Код 1.Переназначение для заданного хостом маршрута.
  • Код 2.Переназначение для заданного сетевого маршрута, основанного на указанном типе обслуживания.
  • Код 3.Переназначение для заданного хостом маршрута, основанного на указанном типе обслуживания.
    •

    Запрос

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

    (рис 6.9) Сообщения запроса

    Эхо-запрос и ответ

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

    Комбинация сообщений запроса эха и ответа эха определяет, могут ли две системы (хосты или маршрутизаторы) связаться друг с другом.

    Хост или маршрутизатор могут послать сообщение запроса эха другому хосту или маршрутизатору. Хост или маршрутизатор, который получает сообщение запроса эха, создает сообщение ответа эха и возвращает его первоначальному передатчику.

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

    Запрос эха и сообщения ответа эха могут также использоваться хостом, чтобы видеть, достижим ли другой хост. На пользовательском уровне это делается вызовом программы тестирования каналов сетей пакетной коммутации (утилита PING – Packet Internet Groper). Сегодня большинство систем включает в себя версии утилиты PING, которая может создать серию (вместо только одного) запросов эха и сообщений ответа эха, обеспечивая статистическую информацию.

    Запрос эха, вместе с ответом эха, может подтвердить, действительно ли узел функционирует должным образом. Узлу, который должен быть проверен, посылают сообщение запроса эха. Дополнительное поле данных содержит сообщение, которое должно быть повторено отвечающим узлом в его сообщении ответа эха. Рис. 6.10. показывает формат ответа эха и сообщения запроса эха. Идентификатор и поле порядкового номера формально не определены в соответствии с протоколом и могут использоваться произвольно передатчиком. Например, поле идентификатора может определить группу возникших проблем, а порядковый номер может сохранить запись метода обработки конкретных сообщений запроса эха, которые посылает передатчик. Идентификатор часто совпадает с ID процесса, который порождает запрос.

    (рис 6.10) Сообщение эхо–запроса и эхо-ответа

    Запрос метки времени и ответ

    Два устройства (хосты или маршрутизаторы) могут использовать запрос метки времени и сообщения запроса, метки времени и ответа, чтобы определить время прохождения "туда и обратно" (round–trip), необходимое для дейтаграммы IP. Он может также применяться, чтобы синхронизировать генераторы в двух устройствах. Формат этих двух сообщений показан на рис. 6.11.

    (рис 6.11) Формат сообщения метки времени – запроса и метки времени - ответа

    Три поля метки времени — каждый 32 бита длиной. Каждое поле может содержать число, которое представляет время, измеренное в миллисекундах от полуночи Универсального времени (прежде называемое Значением времени по Гринвичу). (Заметим, что 32 бита могут представлять числа от 0 до 4,294,967,295, но метка времени в данном случае не может превысить 86 400 000 = 24 x 60 x 60 x 1000.)

    Источник создает сообщение запроса метки времени. Источник заполняет поле исходной метки времени значением Универсального времени в соответствии с показанием своих часов во время отправления. Другие два поля метки времени заполнены нулями.

    Пункт назначения создает сообщение ответа метки времени. Пункт назначения копирует первоначальное значение метки времени с сообщения запроса в то же самое поле в его сообщении ответа. Затем заполняет поле метки времени получения значением Универсального времени по показанию его часов в тот момент времени, когда запрос был получен. Наконец, он заполняет поле метки времени отправления значением Универсального времени по показанию его часов в тот момент времени, в который сообщение ответа отбывает.

    Запрос метки времени и сообщения ответа метки времени могут использоваться, чтобы вычислить одностороннее время или время прохождения туда и обратно, требуемое для дейтаграммы, чтобы пройти от источника до пункта назначения и затем опять назад. Формулы следующие:

    Время передачи = значение метки времени получения – значение первоначальной метки времени;

    Время приема = время возвращения пакета – значение передачи метки времени;

    Время прохождения туда и обратно = время передачи + время получения.

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

    Например, учитывая следующую информацию:

    Значение первоначальной метки времени: 46;

    Значение метки времени получения: 59;

    Значение метки времени отправления: 60;

    Время прибытия пакета: 67;

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

    Время передачи = 59 – 46 = 13 миллисекунд;

    Время получения = 67 – 60 = 7 миллисекунд.

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

    Разница во времени = метки времени получения – -(исходная метка времени + односторонняя продолжительность времени).

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

    Разница во времени = 59 – (46 + 10) = 3.

    Запрос маски адреса и ответ

    Адрес IP хоста содержит сетевой адрес, адрес подсети и идентификатор хоста. Хост может знать свой полный адрес IP, но он не может знать, какая часть адреса определяет сетевой и адрес подсети и какая часть соответствует идентификатору хоста. Например, хост может знать свой адрес IP на 32 бита как

    10011111 00011111 11100010 10101011

    Но он не знает, что левые 20 битов — сетевые и адреса подсети, и остающиеся 12 бит — его идентификатор хоста. В этом случае хост нуждается в следующей маске:

    11111111 11111111 11110000 00000000

    Единицы в маске идентифицируют позицию битов, используемых для сетевого идентификатора (netid) и идентификатора сети (subnetid). Нули идентифицируют позицию битов для хоста (hostid). Например, применяя вышеупомянутую маску к вышеупомянутому адресу, мы имеем

    Чтобы получить свою маску, хост посылает сообщение запроса маски адреса маршрутизатору местной сети (LAN). Если хост знает адрес маршрутизатора, он посылает запрос непосредственно маршрутизатору, если не знает, передает сообщение широковещательно. Маршрутизатор, получающий адрес, — сообщение запроса маски — отвечает с сообщением ответа маски адреса, обеспечивая необходимую маску для хоста. Она может быть применена к полному IP-адресу, чтобы получить его адрес подсети.

    Формат запроса маски адреса и ответа маски адреса показан на рисунке 6.12. Поле маски адреса в сообщении запроса заполнено нолями. Когда маршрутизатор посылает ответ маски адреса назад хосту, это поле содержит фактическую маску (единицы для netid и subnetid и нули для hostid).

    (рис 6.12) Формат сообщения запрос и ответ маски

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

    Когда станция впервые загружается извне, она может запросить свой полный IP-адрес, используя протокол определения сетевого адреса по местоположению – RARP (этот протокол мы рассмотрим далее). После получения своего IP-адреса она может использовать запрос маски адреса и ответ, чтобы узнать, какая часть адреса определяет подсеть.

    Ходатайство маршрутизатора и извещение

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

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

    (рис 6.13) Формат сообщения о связях маршрутизатора

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

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

    В ICMP контрольная сумма вычисляется по полному сообщению (заголовок и данные).

    Вычисление контрольной суммы

    Передатчик выполняет следующие шаги, используя арифметику дополнения единицами:

  • Поле контрольной суммы устанавливается на ноль.
  • Вычисляется сумма всех слов на 16 бит (заголовок и данные).
  • Сумма дополняется, чтобы получить контрольную сумму.
  • Контрольная сумма сохраняется в поле контрольной суммы.
    •

    Испытание контрольной суммы

    Приемник выполняет следующие шаги, используя арифметику дополнения единицами:

  • Вычисляется сумма всех слов (заголовок и данные).
  • Сумма дополняется.
  • Если результат, полученный в шаге 2, — 16 нулей, сообщение принято; иначе — оно удаляется.
    •

    Алгоритмы работы модулей блок-схемы ICMP

    В данном случае рассматривается упрощенная версия блок-схемы, состоящая из двух модулей. Рис. 6.14. показывает эти два модуля.

    (рис 6.14) Блок-схема модулей ICMP

    Основные алгоритмы работы модулей ICMP даны на рис. 6.15., рис. 6.16.

    (рис 6.16) Алгоритм работы модуля ввода ICMP(рис 6.15) Алгоритм работы модуля вывода ICMP

    Входной модуль

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

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

    Модуль вывода

    Модуль вывода отвечает за создание запроса ходатайства или сообщения об ошибках, которые нужны протоколам более высокого уровня или протоколам IP. Модуль получает запрос от IP, UDP или TCP, чтобы послать одно из ICMP-сообщений об ошибках. Если запрос от IP, модуль вывода должен сначала проверить, что запрос разрешен. Напомним, что ICMP-сообщение не может быть создано для четырех ситуаций: для пакета IP, несущего сообщение об ошибках ICMP; для фрагментированного пакета IP; для пакетов IP, рассылаемых по многим адресам; или для пакета IP, имеющего адрес IP 0.0.0.0 или 127.X.Y.Z. Алгоритм работы модуля показан на рис.6.16.

    Можно отметить, что модуль вывода (оператор 1 на рис. 6.16) может также получить запрос от прикладной программы, чтобы послать один из запросов ICMP или сообщений ходатайства.

    Краткие итоги

  • Протокол управления сообщениями Интернета (ICMP – Internet Control Message Protocol) был разработан для устранения недостатков протокола IP — отсутствия контроля ошибок и отсутствия механизмов помощи в доставке.
  • ICMP-сообщения разделены на две широких категории: отчет об ошибке сообщения и запрос.
  • Сообщение об ошибке переносит данные о проблемах, возникающих при обмене сообщениями, с которыми маршрутизатор или хост (пункт назначения) могут столкнуться, когда они обрабатывают пакет IP.
  • Сообщения запроса помогают хосту или сетевому менеджеру получить заданную информацию от маршрутизатора или другого хоста.
  • Обрабатываются пять типов ошибок: пункт назначения недостижим, подавление источника, время истекло, проблемы параметра, переназначение.
  • Сообщение "конечный пункт недостижим" посылается, когда маршрутизатор не может выбрать маршрут дейтаграмме или хост не может доставить дейтаграмму, она отклоняется и маршрутизатор или хост посылает назад к хосту источника, который ввел дейтаграмму.
  • Сообщение подавления источника посылается источнику, когда маршрутизатор или хост удаляет дейтаграммы из-за перегрузки.
  • Сообщение о превышении времени генерируется в двух случаях: Первый случай — когда пакет перемещается по петле или в цикле. Второй случай — когда все фрагменты, которые составляют сообщение, не достигают хоста пункта назначения в пределах некоторого срока.
  • Если маршрутизатор или хост пункта назначения обнаруживают неоднозначное или отсутствующее значение в любом поле дейтаграммы, он удаляет его из дейтаграммы и посылает назад к источнику сообщение о проблемах параметра.
  • Чтобы обновить таблицу маршрутизации, хост посылает сообщение переназначения другому хосту.
  • В дополнение к сообщению ошибки, ICMP может также диагностировать некоторые сетевые проблемы. Это достигается с помощью сообщения запроса.
  • Комбинация сообщений запроса эха и ответа эха определяет, могут ли две системы (хосты или маршрутизаторы) связаться друг с другом.
  • Два устройства (хосты или маршрутизаторы) могут использовать запрос метки времени и сообщения запроса, метки времени и ответа, чтобы определить время прохождения "туда и обратно" (round–trip), необходимое для дейтаграммы IP.
  • Адрес IP хоста содержит сетевой адрес, адрес подсети и идентификатор хоста. Хост может знать свой полный адрес IP, но он не может знать, какая часть адреса определяет сетевой и адрес подсети и какая часть соответствует идентификатору хоста. В этом случае хост нуждается в маске.
  • Ходатайство маршрутизатора и сообщения извещения маршрутизатора могут помочь узнать, являются ли маршрутизаторы действующими и исправными.
  • Блок-схема модулей ICMP содержит два модуля: модуль ввода и модуль вывода.
    •

    Задачи и упражнения

  • Хост A посылает запрос метки времени к хосту B и не получает ответ. Обсудите три возможных случая и соответствующие им действия.
  • IP-адрес рабочей станции – 198.123.46.219. Если маска подсети 255.255.255.192, каков идентификатор подсети? К какому классу принадлежит сеть?
  • Почему имеется ограничение на генерацию ICMP-сообщения в ответ на ошибочное ICMP-сообщение об ошибках?
  • Хост A посылает дейтаграмму хосту B. Хост B не получает дейтаграмму, а хост A не получает извещение об ошибке. Дайте два варианта объяснения, как это может произойти.
  • Какая цель включения IP-заголовка и 8 первых байт данных дейтаграммы в сообщение "отчет об ошибках"?
  • Каково максимальное значение указателя поля в сообщении "проблема параметров"?
  • Приведите примеры ситуаций, в которых никогда не будет получено сообщение "переназначение".
  • Составьте таблицу, показывающую, какие ICMP-сообщения посылаются маршрутизатором, какие — промежуточным хостом и какие — пунктом назначения.
  • Может ли вычисление времени передачи, времени приема, времени получения или времени передачи и приема (туда и обратно) иметь отрицательное значение? Почему да или почему нет? Приведите примеры.
  • Почему время прохождения пакета в одну сторону не равно времени прохождения "туда и обратно", деленному на два?
  • Каков минимальный размер IP-пакета? Каков максимальный размер IP-пакета?
  • Как можно определить пакет IP, если он включает в себя ICMP-сообщение?
  • Вычислите контрольную сумму для следующего ICMP-пакета:

    Тип: Эхо-запрос, Идентификатор: 123, Порядковый номер: 25, Сообщение: Hello.

  • Маршрутизатор получает IP-пакет с адресом источника 130.45.3.3 и адресом пункта назначения 201.23.4.6. Маршрутизатор не может найти адрес в таблице маршрутизации. Заполните поле IP-адреса пункта назначения (насколько вы можете) для сообщения ICMP.
  • TCP получает сегмент с адресом пункта назначения 234. TCP проверяет и не может найти порт, открытый для этого пункта назначения. Заполните поле для посылаемого в этом случае ICMP-сообщения.
  • ICMP-сообщение поступает с заголовком (шестнадцатеричным):
    03 0310 20 00 00 00 00
    Каков тип сообщения? Какой код? Какова цель сообщения?
  • Компьютер посылает запрос метки времени. Если его часы показывают 5:20:30 утра (Универсальное время), покажите входное сообщение.
  • Повторите 17 для времени 15:40: 30 (Универсальное время).
  • Компьютер получает запрос метки времени от другого компьютера в 14:34:20. Значение исходной метки времени 52,453,000. Если часы передатчика на 5 мсек. медленнее, каково время передачи в одну сторону?
  • Компьютер посылает запрос метки времени к другому компьютеру. Он получает соответствующую метку времени ответа 3:46:07. Значения исходной метки, полученной метки и промежуточной метки — 13,560,000, 13,562,000, 13,565,300 соответственно. Каково время распространения при передаче? Каково время получения? Какое время туда и обратно? Какова разность между генератором передатчика и приемника?
  • Два компьютера находятся на расстоянии 8000 км. Каково минимальное время для прохождения сообщения от одного к другому?
    •

    Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^