TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) - Сидни Фейт

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.