Глава 7 Протокол ICMP

7.1 Введение

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

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

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

Рис. 7.1. Пакетирование сообщения ICMP

7.2 Сообщения об ошибках ICMP

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

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

Рис. 7.2. Сообщение ICMP направляется по пути трафика.

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

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

Реально ICMP не имеет средств предоставить отчет об ошибках выделенному операционному центру. Для этого служит протокол SNMP (см. главу 20).

7.2.1 Типы сообщений об ошибках

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

Рис. 7.3. Типы сообщений об ошибках ICMP


Таблица 7.1 Сообщения об ошибках ICMP

Сообщение Описание
Destination Unreachable (недостижимая точка назначения) Датаграмма не может достичь хоста назначения, утилиты или приложения.
Time Exceeded (время закончилось) Маршрутизатор определил завершение времени жизни, или закончилось время на сборку фрагментов в хосте назначения.
Parameter Problem (проблема с параметром) В заголовке IP неверный параметр.
Source Quench (подавление источника) Перегружен маршрутизатор или система назначения (системам рекомендуется не отправлять это сообщение).
Redirect (перенаправление) Хост направил датаграмму на неверный локальный маршрутизатор.

7.2.2 Обязанность по отправке сообщения ICMP

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

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

7.2.3 Входящие сообщения ICMP

Что происходит при получении хостом сообщения ICMP? Рассмотрим пример, когда производится попытка обращения по зарезервированному (и, следовательно, недостижимому) адресу сети:

> telnet 10.1.1.1

Trying 10.1.1.1 ...

telnet: connect: Host is unreachable

Произошло то, что и должно было произойти,— в сообщении указано на недостижимость хоста (Host is unreachable).

Чтобы определить, какой из маршрутизаторов послал сообщение ICMP, можно использовать команду traceroute:

> traceroute 10.1.1.1

traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets

> nomad-gateway (128.121.50.50) 2 ms 2 ms 2 ms

> liberty-gateway (130.94.40.250) 91 ms 11 ms 78 ms

> 
border2-hssi2-0.NewYork.mci.net (204.70.45.9) !H !H !H

Маршрутизатор New York послал сообщение Destination Unreachable, которое отображается на экране как !Н.

Функции traceroute основаны на ICMP-сообщении Time Expired и формируются следующим образом:

■ Создается короткое сообщение UDP, которое имеет заголовок IP с установленным в 1 полем TTL.

■ Трижды отправляется датаграмма.

■ Первый маршрутизатор (в примере — nomad-gateway) устанавливает значение Time-to-Live (время жизни) в 0, отбрасывает датаграмму и отправляет источнику ICMP-сообщение Time Expired.

■ Функция traceroute идентифицирует пославший сообщение маршрутизатор и трижды выводит само сообщение.

■ Значение Time-to-Live устанавливается в 2, и сообщение посылается дальше.

■ Процесс повторяется с увеличением Time-to-Live на каждом шаге.

Если можно достичь точки назначения, то в итоге можно получить полный путь до него.

7.3 Когда не нужно посылать сообщение ICMP

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

■ Маршрутизации и доставке ICMP-сообщений messages

■ Широковещательных и многоадресных датаграммах

■ Фрагментах датаграмм, кроме первых

■ Сообщениях, чей адрес источника не идентифицирует уникальный хост (например, IP-адреса источников 127.0.0.1 или 0.0.0.0)

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

Сообщение ICMP переносится в части данных датаграммы IP. Каждое сообщение ICMP начинается тремя одинаковыми полями: полем типа (Type), полем кода (Code), обеспечивающим более подробное описание ошибки, и полем контрольной суммы (Checksum). Формат оставшейся части сообщения определяется типом сообщения.

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

В сообщение включается и контрольная сумма ICMP, начиная от поля Type.

7.4.1 Сообщение Destination Unreachable

Существует много причин прекращения доставки датаграммы. Разорванная связь физически не позволит маршрутизатору достичь подсети назначения или выполнить пересылку в точку следующего попадания. Хост назначения может стать недоступным при отключении его для проведения профилактики.

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

Рис. 7.4. Формат ICMP-сообщения Destination Unreachable

Формат сообщения Destination Unreachable показан на рис. 7.4. Поле Type (в нашем случае 3) идентифицирует именно этот тип сообщения. Поле Code отражает причину отправки сообщения. Полный список кодов этого поля представлен в таблице 7.2.


Таблица 7.2 Коды ошибок сообщения Destination Unreachable

Код Смысл
0 Сеть недостижима.
1 Хост недостижим.
2 Запрашиваемый протокол не поддерживается в точке назначения.
3 Порт недостижим (недоступно удалённое приложение).
4 Необходима фрагментация, но установлен флаг "Не фрагментировать".
5 Неверен маршрут от источника.
6 Неизвестна сеть назначения.
7 Неизвестен хост назначения.
8 Хост источника изолирован.
9 Административно запрещены коммуникации с сетью назначения.
10 Административно запрещены коммуникации с хостом назначения.
11 Сеть недостижима для заданного типа обслуживания.
12 Хост недостижим для заданного типа обслуживания.

7.4.2 Сообщение Time Exceeded

Пересылаемая датаграмма может быть отброшена по тайм-ауту при уменьшении до нуля ее времени жизни (TTL). Еще один тайм-аут может возникнуть в хосте назначения, когда завершится время, выделенное на сборку, а прибыли еще не все фрагменты датаграммы. В обоих случаях формируется сообщение Time Exceeded для источника датаграммы. Формат этого сообщения показан на рис. 7.5.

Рис. 7.5. Формат ICMP-сообщения Time Exceeded

Значения кодов (см. таблицу 7.3) отражают причину тайм-аута.


Таблица 7.3 Коды сообщения Time Exceeded

Код Смысл
0 Завершилось время жизни датаграммы.
1 Завершилось время на сборку фрагментов датаграммы.

7.4.3 Сообщение Parameter Problem

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

Рис. 7.6. Формат ICMP-сообщения Parameter Problem

Поле Pointer (указатель) сообщения Parameter Problem идентифицирует октет, в котором выявлена ошибка. На рис. 7.6 показан формат сообщения Parameter Problem, а в таблице 7.4 — значения кодов ошибок.


Таблица 7.4 Коды сообщения Parameter Problem

Код Смысл
0 Значение в поле указателя специфицирует ошибочный октет.
1 Отсутствует требуемый вариант (используется военными для указания на отсутствие параметров безопасности)
2 Неверная длина

7.4.4 Проблемы перегрузок

Протокол IP очень прост: хост или маршрутизатор обрабатывают датаграмму и посылают ее как можно быстрее. Однако доставка не всегда проходит гладко. Могут возникнуть различные проблемы.

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

Маршрутизатор может переполнить свои буферы и далее будет вынужден отбрасывать некоторые поступающие датаграммы. Медленное соединение через региональную сеть (например, на скорости 56 Кбит/с) между двумя скоростными локальными сетями (например, в 10 Мбит/с) может создать затор на пути следования датаграмм. Из-за этого в сети возникнут перегрузки, которые также приведут к отбрасыванию датаграммы и, следовательно, к созданию еще большего трафика.

7.4.5 Сообщение Source Quench

Сообщение Source Quench (подавление источника) показано на рис. 7.7. Оно позволяет попытаться решить проблему перегрузок, хотя и не всегда успешно. Механизмы для подавления источника перегрузки сети должны создавать разработчики конкретных продуктов, но остается открытым конкретный вопрос:

Когда и кому маршрутизатор или хост должен отправлять сообщение Source Quench?Рис. 7.7. Формат ICMP-сообщения Source Quench

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

Текущий документ по требованиям к хостам (RFC 1812) оговаривает в качестве особого пункта, что сообщения Source Quench вовсе не нужно посылать. Работа должна выполняться более совершенным механизмом управления нагрузкой в сети.

7.4.6 Сообщения Redirect

К локальной сети может быть подключено более одного маршрутизатора. Когда локальный хост посылает датаграмму не на тот маршрутизатор, последний пересылает ее и отправляет хосту источника ICMP-сообщение Redirect (перенаправление), как показано на рис. 7.8. Хост должен переключить последующий трафик на более короткий путь.

Рис. 7.8. Коррекция маршрутизации на хосте посредством сообщения Redirect

Сообщение Redirect используется и для выключения маршрутизатора системным администратором. Хост может быть сконфигурирован с единственным маршрутизатором по умолчанию; при этом он будет динамически определять возможности пересылки через другие маршрутизаторы.

Рис. 7.9. Формат ICMP-сообщения Redirect

Формат сообщения о перенаправлении показан на рис. 7.9. Коды этого сообщения перечислены в таблице 7.5. Некоторые протоколы маршрутизации способны выбирать путь доставки на основе содержимого поля типа обслуживания (TOS) датаграммы. Коды 2 и 3 предоставляют некоторые сведения да такого выбора.


Таблица 7.5 Коды перенаправления

Код Смысл
0 Перенаправление датаграммы в сеть
1 Перенаправление датаграммы в хост
2 Перенаправление датаграммы в сеть на основе значения из поля типа обслуживания
3 Перенаправление датаграммы в хост на основе значения из поля типа обслуживания

7.4.7 Управление поступающими сообщениями ICMP

Что должен делать хост, получивший сообщение ICMP? Реализации различных разработчиков по-разному отвечают на этот вопрос. В некоторых из них хосты игнорируют все или многие такие сообщения. Стандарты TCP/IP оставляют большую свободу выбора в решении этого вопроса. Для различных типов сообщений ICMP предлагаются следующие рекомендации:

Destination Unreachable Доставить ICMP-сообщение на транспортный уровень. Выполняемые действия должны зависеть от того, является ли причина вывода сообщения временной или постоянной (например, административный запрет на пересылку).
Redirect Хост обязан обновить таблицу маршрутизации.
Source Quench Доставить ICMP-сообщение на транспортный уровень или в модуль обработки ICMP.
Time Exceeded Доставить на транспортный уровень.
Parameter Problem Доставить ICMP-сообщение на транспортный уровень с необязательным уведомлением пользователя.

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

7.5 Исследование MTU по пути

При пересылке большого объема данных (например, при копировании файлов по сети) с одного хоста на другой размер датаграмм существенно влияет на производительность. Заголовки IP и TCP требуют не менее 40 дополнительных байт.

■ Если данные пересылаются в 80-байтовых датаграммах, дополнительная нагрузка составит 50%.

■ Если данные пересылаются в 400-байтовых датаграммах, дополнительная нагрузка составит 10%.

■ Если данные пересылаются в 4000-байтовых датаграммах, дополнительная нагрузка составит 1%.

Для минимизации дополнительной нагрузки лучше отсылать датаграммы наибольшего размера. Однако этот размер ограничивается значением максимального элемента пересылки (Maximum Transmission Unit — MTU) для каждого из носителей. Если датаграмма будет слишком большой, то она будет фрагментирована, а этот процесс снижает производительность. (С точки зрения пользователя, качество сети определяется двумя параметрами: интервалом пересылки (от начала пересылки до ее завершения) и временем ожидания (задержкой доступа к сети, занятой другими пользователями). Увеличение размера датаграммы приводит к снижению интервала пересылки, но увеличению ожидания для других пользователей. Грубо говоря, нагрузка на сеть будет выглядеть как пиковые импульсы с очень небольшой нагрузкой между ними, что считается самым неудачным вариантом загрузки сети. Гораздо лучше, когда сеть нагружается равномерно. — Прим. пер.)

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

Гораздо полезнее заранее знать наибольший допустимый размер датаграммы, которую можно переслать по заданному пути. Существует очень простой механизм исследования MTU по пути (Path MTU discovery), позволяющий узнать это значение. Для такого исследования:

■ Флаг "Не фрагментировать" заголовка IP устанавливают в 1.

■ Размер MTU по пути первоначально устанавливают в значение MTU для локального интерфейса.

■ Если датаграмма будет слишком велика для одного из маршрутизаторов, то он пошлет обратно ICMP-сообщение Destination Unreachable с кодом 4.

■ Хост источника уменьшит размер датаграммы и повторит попытку.

Какое же значение нужно выбрать для следующей попытки? Спецификация IP предполагает сохранение значения MTU и его доступность для протоколов транспортного уровня. Если маршрутизатор имеет современное программное обеспечение, то он будет включать в пересылаемое дальше по сети сообщение Destination Unreachable размер MTU (см. рис. 7.10). Иногда средства защиты конфигурируются на полное исключение всех входящих сообщений ICMP, что не позволяет использовать механизм определения MTU по пути следования датаграммы.

Рис. 7.10. Сообщение Destination Unreachable приносит результат исследования размера

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

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

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

7.6 Сообщения запросов ICMP

Не все сообщения ICMP сигнализируют об ошибках. Некоторые из них извлекают из сети полезные сведения. Работает ли хост X? Не выключен ли хост Y? Как долго движется датаграмма до хоста Z и обратно? Какова маска подсети хоста источника?

Ответы на эти вопросы дают следующие сообщения ICMP:

Эхо-запросы и эхо-ответы обеспечивают обмен информацией между хостами и маршрутизаторами.

■ Запросы и ответы о маске адреса позволяют системе исследовать присвоенную интерфейсу маску адреса.

■ Запросы и ответы временной метки служат для извлечения сведений об установке времени на целевой системе. Ответы на такие запросы дают информацию, необходимую для оценки времени обработки датаграмм на хосте.

На рис. 7.11 представлено обслуживание запросов ICMP. Программа Ping посылает эхо-сообщение "Вы в рабочем состоянии?", которое используется в ежедневной работе сетевого администратора. Запросы о маске адреса применяются от случая к случаю, а запросы о временной метке вообще редко.

Рис. 7.11. Сообщение запроса ICMP

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

Эхо-запросы (Echo Request) и эхо-ответы (Echo Reply) применяются для проверки активности системы. Код типа 8 применяется в запросах, а код 0 — в ответах. Количество октетов в поле данных переменно и может выбираться отправителем.

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

Рис. 7.12. Формат ICMP-сообщений Echo Request и Echo Reply

Широко известная команда ping доступна почти во всех системах TCP/IP, а ее работа основана на ICMP-сообщениях для эхо-запросов и эхо-ответов. В приведенном ниже диалоге сначала тестируется хост ring.bell.com. Затем отсылается последовательность из 14 сообщений, содержащих по 64 октета каждое. Отметим, что сообщения 0, 1 и 2 были потеряны. Справа приводятся сведения о пути туда и обратно.

> ping ring.bell.com

ring.bell.com is alive

> ping -s ring.bell.com 64 14

64 bytes from ring.bell.com: icmp_seq=3. time = 21. ms

64 bytes from ring.bell.com: icmp_seq=4. time = 18. ms

64 bytes from ring.bell.com: icmp_seq=5. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=6. time = 19. ms

64 bytes from ring.bell.com: icmp_seq=7. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=8. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=9. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=10. time = 18. ms

64 bytes from ring.bell.com: icmp_seq=11. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=12. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=13. time = 17. ms


-ring.bell.com PING Statistics-

14 packets transmitted, 11 packets received, 21% packet loss

round-trip (ms) min/avg/max = 17/17/21

7.6.2 Маска адреса

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

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

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

На рис. 7.13 показан формат запроса маски адреса и ответа на него. Тип 17 применяется для запроса, а тип 18 — для ответа. В общем случае можно игнорировать идентификатор и последовательный номер.

Рис. 7.13. Формат ICMP-сообщений Address Mask

На практике более предпочтительный метод определения маски адреса предоставляют протоколы загрузки, например Dynamic Host Configuration Protocol или BOOTP. Эти протоколы более эффективны, поскольку обеспечивают полный набор конфигурационных параметров. Кроме того, операции выполняются более точно, в том числе и некорректные.

7.6.3 Временная метка и ответ на Timestamp

Сообщение с ответом на Timestamp предоставляет сведения о времени в системе. Оно предназначено для оценки буферизации и обработки датаграммы на удаленной системе. Отметим следующие поля:

Originate timestamp (исходная временная метка) Время последнего обращения к сообщению в системе-отправителе
Receive timestamp (временная метка получения) Время первого обращения к сообщению отвечающей системы
Transmit timestamp (временная метка пересылки) Время последнего обращения к сообщению отвечающей системы

По возможности, возвращаемое время должно измеряться в миллисекундах относительно полуночи по универсальному времени (Universal Time), которое ранее называлось временем по Гринвичу (Greenwich Mean Time). Большинство реализаций реально возвращает одно и то же время в полях Receive timestamp и Transmit timestamp.

Протокол ICMP обеспечивает очень простой способ синхронизации систем по времени. Однако это несколько грубая синхронизация, поскольку на нее влияют задержки в сети. Существует более совершенный протокол сетевого времени (Network Time Protocol), который был разработан для синхронизации по времени в Интернете.

Тип 13 используется для запросов, а 14 — для ответов. Формат сообщения представлен на рис. 7.14.

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

7.7 Просмотр действий в ICMP

Ниже показана часть отчета о статистике протоколов команды netstat. Приведенный фрагмент посвящен протоколу ICMP. В отчете отражены операции ICMP, выполненные после последней инициализации.

> netstat -s


icmp:

 1075 calls to icmp_error


 Output histogram:

  echo reply: 231

  destination unreachable: 1075


 2 messages with bad code fields

 0 messages < minimum length

 21 bad checksums

 0 messages with bad length


 Input histogram:

  echo reply: 26

  destination unreachable: 1269

  source quench: 2

  echo: 231

 231 message responses generated

Система отправила 1075 сообщений Destination Unreachable. Был получен 231 запрос Echo Requests, на каждый из которых был отправлен ответ. Было получено 26 ответов Echo Replies.

Локальная система зафиксировала 21 сообщение ICMP, полученное с неверной контрольной суммой ICMP.

Системой было получено 1269 сообщений Destination Unreachable и 2 сообщения Source Quenches.

Следующий далее отчет команды netstat содержит сведения о маршрутизации. Видно, что через сообщения Redirect были динамически обнаружены новые маршрутизаторы. Было 12 отчетов о недостижимости точки назначения (Destination Unreachable). Для выбора маршрута по умолчанию было использовано около 349 подстановочных символов (wildcard).

> netstat -rs

routing:

 0 bad routing redirects

 0 dynamically created routes

 2 new routers due to redirects 

 2 destinations found unreachable

 349 uses of a wildcard route

7.8 Обнаружение маршрутов

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

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

Протокол исследования маршрутов (Router Discovery) предоставляет надежный метод, основанный на сообщениях ICMP, для отслеживания маршрутизаторов локальной сети. Основная идея состоит в периодическом объявлении маршрутизаторами о своем присутствии. Хостам нужно прослушивать такие сообщения.

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

Подключающийся к сети хост может быть не способен к ожиданию при поиске маршрутизаторов локальной сети. Такой хост самостоятельно запрашивает маршрутизаторы об отправке их объявлений о присутствии на собственный адрес. Для этого лучше всего использовать сообщение Router Solicitation (настоятельная просьба к маршрутизаторам) в многоадресной рассылке по адресу "все маршрутизаторы" (224.0.0.2). Поскольку не все системы поддерживают многоадресные рассылки, иногда применяется широковещательная рассылка (255.255.255.255).

Типичный сценарий для маршрутизатора:

■ Каждый интерфейс маршрутизатора конфигурируется с адресом объявления (advertisement address) — 224.0.0.1 или 255.255.255.255 — для локальной сети, подключенной к данному интерфейсу.

■ При инициализации маршрутизатора и использовании многоадресной рассылки маршрутизатор начинает прослушивание адреса многоадресной рассылки для всех маршрутизаторов (224.0.0.2). Кроме того, прослушиваются и широковещательные рассылки.

■ Маршрутизатор объявляет о своем присутствии всем подключенным к локальной сети хостам посредством трансляции сообщения Router Advertisement на адрес объявления такой локальной сети. В объявлении о присутствии перечисляются все IP-адреса маршрутизатора для данного интерфейса.

■ Маршрутизатор напоминает о себе различными периодическими сообщениями Router Advertisement (рекомендуемый период 7–10 мин.).

■ Маршрутизатор посылает объявление о присутствии при запросе об этом от хоста.

Для хоста сценарий выглядит так:

■ Каждый интерфейс хоста конфигурируется с Solicitation Address — 224.0.0.2 или 255.255.255.255.

■ При инициализации хоста начинается прослушивание Router Advertisement.

■ При запуске хост может послать необязательное сообщение Router Solicitation по адресу настоятельных просьб (solicitation address). Маршрутизаторы ответят как по IP-адресу хоста, так и по адресу объявления.

■ Когда хост услышит о новом маршрутизаторе, он добавит маршрут по умолчанию в свою таблицу маршрутизации. Этому элементу таблицы присваивается значение тайм-аута на время жизни (обычно 30 мин), которое указано в Router Advertisement.

■ Тайм-аут на время жизни сбрасывается при получении нового объявления от маршрутизатора. Если время жизни завершается по тайм-ауту, элемент для маршрутизатора удаляется из таблицы маршрутизации хоста.

■ Для объявления всем о корректном отключении от сети маршрутизатор может послать объявления с нулевым значением для времени жизни.

Если имеется более одного маршрутизатора, то как хост определяет тот, которому следует направить данную датаграмму? Каждое объявление маршрутизатора содержит номер предпочтительного уровня (preference level). Если таблица маршрутизации не содержит специальных указаний, выбирается маршрутизатор с наибольшим предпочтительным уровнем. Если он не сможет обеспечить наилучший маршрут, то ответит хосту ICMP-сообщением о перенаправлении.

В ICMP-сообщении Router Advertisement имеет значение типа 9, a Router Solicitation — 10.

7.8.1 Неисправные маршрутизаторы

Исследование маршрутов (маршрутизаторов) помогает хостам определить крах локального маршрутизатора, однако после достаточно длительного периода времени — возможно, через 30 мин. Реализация TCP/IP для хостов предполагает использование встроенного алгоритма для определения неисправности маршрутизатора. Его достоинства очевидны, например:

■ Существование активного сеанса TCP/IP через маршрутизатор

■ Фиксирование получения от маршрутизатора ICMP-сообщений о перенаправлении.

К числу недостатков можно отнести:

■ Невозможность ответа на запросы ARP

■ Множество последовательных тайм-аутов при повторной пересылке в TCP

Если есть причины считать маршрутизатор неисправным, окончательная проверка выполняется по запросу ping.

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

7.9 Дополнительная литература

ICMP определен в RFC 792. RFC 1122 (требования к хостам) и RFC 1812 (требования к маршрутизаторам) содержат несколько очень полезных разъяснений. Исследованию маршрутов посвящен RFC 1256.

Исследование MTU по пути рассмотрено в RFC 1191, а дополнительные рекомендации представлены в RFC 1435.

Загрузка...