ICMP-протокол обмена управляющей информацией

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

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

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

Таблица 6.6.

Сообщения «Запрос эха» и «Ответ на эхо» являются компонентами утилиты ping, широко используемой для диагностики работоспособности сетевых устройств. Поскольку как «Запрос эха», так и «Ответ на эхо» передаются в IP-пакетах, то успешный прием ответа свидетельствует о работоспособности основных компонентов сетевой транспортной системы, т.е. успешной маршрутизации, работоспособности IP-модулей на конечных станциях. На рис. 6.8. представлен формат этих сообщений.

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

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

Поле «Необязательные данные» имеет переменную длину и содержит данные, которые необходимо вернуть отправителю.

Сообщение «Получатель недостижим» (Тип=3) генерируется маршрутизатором в ситуации, когда он не может доставить пакет по назначению. Его формат представлен на рис. 6.9.

Это сообщение содержит поле «Код», которое уточняет причину невозможности доставки пакета. Некоторые из кодов представлены в таблице 6.7.

Таблица 6.7

Формат сообщения «Подавление источника» (Тип=4) аналогичен формату сообщения типа 3, но значение поля «Код» в нем всегда равно 0. Сообщение «Подавление источника» отправляется маршрутизатором хосту-отправителю в ответ на каждый, полученный в состоянии перегрузки маршрутизатора, пакет. Отправители этих пакетов, получая такие ICMP-сообщения, уменьшают интенсивность отправки очередных пакетов, что способствует устранению перегрузки.

Сообщение «Изменение маршрута» (Тип=5) отправляется маршрутизатором хосту-отправителю, находящемуся с ним в одной физической сети, для того, чтобы сообщить об использовании хостом неоптимального маршрута к узлу назначения. В сообщении (рис.6.10) указывается адрес маршрутизатора, использование которого является предпочтительным.

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

Из поля «Заголовок IP- пакета…» узел узнает, для какой сети/узла необходимо направлять пакеты указанному маршрутизатору. Значения поля «Код» (0-3) уточняют условия применения рекомендуемого маршрута (0 – для всей сети, 1 – для данного хоста, 2 – для данной сети при заданном в IP-пакете требовании к обслуживанию, 3 - для данного хоста при заданном в IP-пакете требовании к обслуживанию).

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

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

Сообщения «Запрос/Ответ метки времени» (Тип = 13/14, Код=0) используется для синхронизации счетчиков времени различных хостов сети Internet. Формат этих сообщений представлен на рис. 6.11. В 32-битных полях «Время ...» записывается время в миллисекундах, прошедшее после полуночи по универсальному скоординированному времени (UСT/GMT). «Время отправления» (Originate timestamp) - это время, которое отправитель фиксировал последний раз перед посылкой Запроса метки времени. «Время получения» (Receive timestamp) - это время, когда сообщение-запрос впервые «увидел» получатель сообщения. Эти два поля копируются в сообщение-ответ и дополняются полем «Время отправки ответа»(Transmit timestamp) - это время, которое фиксировал в последний раз компьютер, отправляющий ответное сообщение. Располагая этими тремя временными отсчетами и дополнив их временной меткой получения ответа, хост инициировавший этот обмен имеет возможность вычислить сетевую задержку ответа и, прибавив ее к метке «Время отправки ответа»,получить текущее значение часов запрашиваемого хоста, по которому он может синхронизовать свои часы.

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

IP маршрутизация

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

Если станция назначения является непосредственно присоединенной к той же ЛВС, что и станция-отправитель, то из таблицы физических адресов (ARP-таблицы), отправителя, извлекается физический адрес узла назначения, пакет инкансулируется в кадр канального протокола и передается к станции назначения. В противном случае, пакет отправляется по адресу маршрутизатора, который был указан в таблице маршрутизации станции-отправителя в качестве следующего узла на маршруте в целевую сеть, или по адресу маршрутизатора, указанного при конфигурировании станции в качестве шлюза по умолчанию (default router, default gateway). Этот шлюз обязательно имеет физический интерфейс в той же ЛС, что и станция-отправитель.

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

Каждая строка в таблице маршрутизации содержит следующую информацию:

· IP-адрес сети (узла) назначения,

· IP-адрес следующего маршрутизатора, способного обеспечить передачу пакета в эту сеть (этому узлу),

· «стоимость» маршрута в целевую сеть,

· имя выходного интерфейса.

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

Поиск в таблице маршрутизации ведется следующим образом. Прежде всего, сканируется ее первый столбец с целью нахождения записи, точно соответствующей адресу назначения пакета. Если такая запись обнаруживается, то пакет отправляется по адресу, указанному в столбце «Следующий маршрутизатор». Если такой записи не обнаружено, то ищется запись, соответствующая сети назначения. Заметим, что в таблице могут быть несколько таких записей, определяющих маршруты к сети назначения и к ее подсетям. Адреса всех таких записей совпадают, в пределах их сетевых префиксов, с адресом назначения пакета. В этом случае, предпочтение отдается записи, для которой длина маски наибольшая. Если адрес назначения не совпадает ни с одной из записей таблицы, то ищется строка, определяющая маршрут по умолчанию, т.е. маршрут к узлу с более полной информацией о возможных путях передачи этого пакета. В случае, когда ни один из перечисленных вариантов не реализуется, пакет уничтожается и узлу-отправителю отправляется ICMP-сообщение «Хост недостижим». В качестве примера, рассмотрим процедуру маршрутизации в сети, изображенной на рис. 6.12.

Эта сеть содержит три подсети: 149.100.1.0/25 149.100.1.128/26, 149.100.2.0/24, которые объединены двумя маршрутизаторами М₁ и М₂. При этом маршрутизатор М₂ является и шлюзом в Интернет. Адреса интерфейсов маршрутизаторов показаны на рисунке. Предположим, что станция С₆ имеет пакет с адресом назначения 149.100.1.159. Таблица маршрутизации узла С₆ представлена в таблице 6.8.

Таблица 6.8.

Первая строка таблицы определяет закольцовывающий интерфейс. Вторая строка описывает маршрут по умолчанию и флаг G уточняет, что узел 149.100.2.1 является маршрутизатором. Третья запись таблицы не имеет флага Н, следовательно, она определяет сеть; нет в ней и флага G и это говорит о том, что определяется маршрут к непосредственно подключенной сети и интерфейсом к ней является интерфейс станции С₆, имеющий адрес149.100.2.21.

Прежде всего С₆ производит поиск адреса станции С₂, или сети, к которой С₂ принадлежит в своей таблице. Поскольку ни тот, ни другой в ней не присутствуют, то пакет будет отправлен в соответствии с маршрутом по умолчанию на маршрутизатор М₂ с адресом 149.100.2.1 через интерфейс Eth0. Таблица маршрутизации М2 может иметь следующий вид.

Таблица 6.9.

Выполнив поиск в этой таблице маршрутизатор М₂ найдет, что наиболее полно согласуется с адресом назначения маршрут, определенный в строке 5, и отправит пакет к маршрутизатору М₁ через интерфейс Eth1. Таблица маршрутизации М₁ представлена ниже.

Таблица 8.10.

В ней представлен маршрут с адресом назначения точно соответствующим адресу назначения пакета. Поэтому последний передается на интерфейс Eth0 и доставляется станции С₂ с IP-адресом 149.100.1.159.

Бесклассовая маршрутизация

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

В 1993 году была предложена технология бесклассовой маршрутизации (Classless InterDomain Routing, CIDR). Она базируется на использовании масок переменной длины, но уже не для разбиения сетей на подсети, а для объединения их в бесклассовые блоки (суперсети). По сути, CIDR – это констатация необходимости выделять сети непрерывными блоками в соответствии с каким-то административным или географическим принципом, что даст возможность последующего «суммирования» записей к этим сетям в таблицах маршрутизаторов.

Рассмотрим пример. Документ RFC 1466 рекомендует, чтобы новые адреса класса С в Европе назначались из диапазона 194.0.0.0 - 195.255.255.255. В этот диапазон входят 131072 сетей класса С, и все их адреса имеют одинаковые 7 старших бит. В таблицах маршрутизаторов других (неевропейских) стран может быть единственная запись с IP адресом 194 и маской 254.0.0.0, определяющая маршрут ко всем этим сетям класса С через одну точку на магистрали Интернет. Дальнейшая последовательность битов в адресе (это биты, следующие за 194 или 195), в свою очередь, может быть распределена в иерархическом порядке, например, по странам или по поставщикам сервиса. Это позволит объединить маршруты к региональным сетям в таблицах европейских маршрутизаторов с использованием дополнительных, после седьмого, битов маски.

При выборе записи в таблице маршрутизации протоколы, поддерживающие технологию CIDR, используют принцип "лучшее совпадение - это наиболее длинное совпадение (longest match)". Это означает, что из нескольких записей, удовлетворяющих условию совпадения битов сетевого префикса, выбирается та, у которой он более длинный. Предположим, что один из Европейских провайдеров (пусть провайдер Z) использует другой маршрутизатор для связи с магистралью Internet, чем все остальные европейские провайдеры. Ему принадлежат 16 сетей класса С, адреса которых образуют непрерывный блок 194.0.16.0 - 194.0.31.255. Записи в таблицах магистральных маршрутизаторов для этой группы сетей имеют вид: 194.0.16.0/20 (маска 255.255.240.0). Адрес назначения 194.0.22.1 конкретного пакета в пределах первых 20 бит совпадает с адресом блока сетей провайдера Z и, в пределах первых 7 бит с адресом блока сетей, определенного записью (194.0.0.0, 254.0.0.0), представляющей маршрут ко всем сетям Европы (в том числе и к сетям провайдера Z). Однако, так как маска 255.255.240 "длиннее" чем маска 254.0.0.0, будет использована запись таблицы маршрутизации, которая указывает на этот индивидуальный маршрут к блоку сетей провайдера Z.

• ⇐ Назад
• 1
• 23