TCP-IP крупным планом

ARP Кэш

Эффективность функционирования ARP во многом зависит от ARP кэша (ARP cache), который присутствует на каждом хосте. В кэше содержатся Internet адреса и соответствующие им аппаратные адреса. Стандартное время жизни каждой записи в кэше составляет 20 минут с момента создания записи.

Содержимое ARP кэша можно увидеть с использованием команды arp(8). Опция -a показывает все записи, содержащиеся в кэше:

bsdi % arp -a
sun (140.252.13.33) at 8:0:20:3:f6:42
svr4 (140.252.13.34) at 0:0:c0:c2:9b:26

48-битные Ethernet адреса приведены в виде шести шестнадцатиричных чисел, разделенных двоеточиями. Дополнительные функции команды arp обсуждаются в разделе "Команда arp" главы 4.

ARP запрос и ARP отклик, сгенерированные

Рисунок 4.4 ARP запрос и ARP отклик, сгенерированные при запросе на Telnet соединение.

На рисунке А.3 в приложении А показан реальный вывод команды tcpdump, которую мы запустили на рисунке 4.4. Так как это первый пример вывода tcpdump в тексте, Вам стоит посмотреть приложение, чтобы увидеть как мы преобразовали вывод, чтобы он стал более красивым и читаемым.

Мы удалили 4 заключительные строки из вывода tcpdump, которые соответствуют разрыву соединения (более подробно рассматривается в главе 18), так как они не имеют отношения к нашему обсуждению.

В строке 1 приводится аппаратный адрес источника (bsdi), в данном случае - 0:0:c0:6f:2d:40. Аппаратный адрес назначения ff:ff:ff:ff:ff:ff, являющийся широковещательным адресом Ethernet. Каждый Ethernet интерфейс на кабеле получит фрейм и обработает его, как показано на рисунке 4.2.

Следующее поле вывода в строке 1, arp, означает, что тип фрейма (frame type) установлен в 0x0806, что означает либо ARP запрос, либо ARP отклик.

Значение 60, напечатанное после слов arp и ip, в каждой из 5 строк означает длину фрейма Ethernet. Так как размер ARP запроса и ARP отклика составляет 42 байта (28 байт - ARP сообщение, 14 байт - Ethernet заголовок), каждый фрейм дополняется до минимума Ethernet: 60 байт.

Если обратиться к рисунку 1.7, то можно увидеть, что минимальный размер (60 байт) включает в себя 14-байтный Ethernet заголовок, однако не включает 4-байтный Ethernet завершитель. В некоторых книгах минимум приводится как 64 байта, что включает в себя и Ethernet завершитель. Мы целенаправленно не включили 14 байт заголовка Ethernet в минимум из 46 байт, показанных на рисунке 1.7. Максимальный размер составляет 1500 байт. Обычно эта величина называется максимальный блок передачи (MTU - maximum transmission unit) (См. рисунок 2.5). Мы часто используем понятие MTU, потому что оно ограничивает размер IP датаграммы, однако оно никак не связано с минимальным размером. Большинство драйверов устройств или интерфейсных плат автоматически дополняют Ethernet фреймы до минимального размера. IP датаграммы в строках 3, 4 и 5 (содержащие TCP сегменты) меньше чем минимум и также будут дополнены до 60 байт.

Следующее поле в строке 1, "arp кто имеет" (arp who-has), идентифицирует фрейм как ARP запрос с IP адресом svr4 в качестве адреса назначения и IP адресом bsdi в качестве адреса отправителя. tcpdump по умолчанию приводит имена хостов соответствующие IP адресам. (В разделе "Беспричинный ARP" мы воспользуемся опцией -n, чтобы посмотреть реальные IP адреса в ARP запросе.)

В строке 2 мы видим, что ARP запрос распространяется как широковещательный, тогда как адрес назначения ARP отклика это адрес bsdi (0:0:c0:6f:2d:40). ARP отклик посылается непосредственно запрашивающему хосту; он не является широковещательным.

tcpdump печатает для этого фрейма arp reply вместе с именем хоста и аппаратным адресом отвечающего.

В строке 3 отправляется первый TCP сегмент, содержащий требование об установлении соединения. Аппаратный адрес назначения это адрес хоста назначения (svr4). Мы рассмотрим этот сегмент более подробно в главе 18.

Число, которое печатается в каждой строке, после номера строки - это время (в секундах) когда пакет был принят программой tcpdump. В каждой строке после первой содержится разница во времени (в секундах) с предыдущей строкой. Это значение приводится в скобках. Как видно из рисунка, время между отправкой ARP запроса и получением ARP отклика составляет 2,2 мс. Первый TCP сегмент послан через 0,7 мс после этого. Таким образом, для динамического определения адреса с использованием ARP, в данном примере, потребовалось менее чем 3 мс.

И последнее на что следует обратить внимание в выводе tcpdump: мы не увидим ARP запрос от svr4, когда он посылает свой первый TCP сегмент (строка 4). Дело в том, что svr4 уже имеет данные о bsdi в своем ARP кэше, так как, когда система получает ARP запрос, помимо того что она посылает ARP отклик, она также сохраняет аппаратный адрес и IP адрес запросившего в своем ARP кэше. Это логично, так как если запросивший собирается послать IP датаграмму, то получившему скорее всего придется отправить ответ на эту датаграмму.

ARP запрос на несуществующий хост

Что произойдет, если запрашиваемый хост выключен или не существует вообще? Попробуем указать несуществующий Internet адрес - идентификатор сети и идентификатор подсети будет от нашего локального Ethernet, однако указанного идентификатора хоста не существует. На рисунке 3.10 мы видели, что идентификаторов хостов с 36-го по 62-ой не существуют (идентификатор хоста 63 - широковещательный адрес). В данном примере мы будем использовать идентификатор хоста 36.

в этот раз telnet на IP адрес, а не на имя хоста (hostname)
bsdi % date ; telnet 140.252.13.36 ; date
Sat Jan 30 06:46:33 MST 1993
Trying 140.252.13.36 ...
telnet: Unable to connect to remote host : Connection timed out
Sat Jan 30 06:47:49 MST 1993 прошло 76 секунд

bsdi % arp -a проверяем ARP кэш
? (140.252.13.36) at (incomplete)

На рисунке 4.5 мы видим вывод tcpdump.

1 0.0 arp who-has 140.252.13.36 tell bsdi
2 5.509069 ( 5.5091) arp who-has 140.252.13.36 tell bsdi
3 29.509745 (24.0007) arp who-has 140.252.13.36 tell bsdi

ARP запрос на несуществующий хост.

Рисунок 4.5 ARP запрос на несуществующий хост.

Сейчас мы не указываем опцию -e, так как мы уже знаем, что ARP запрос широковещательный.

Здесь интересно посмотреть, с какой частотой рассылаются ARP запросы: 5,5 секунд после первого запроса и снова через 24 секунды. (Мы рассмотрим тайм-ауты TCP и алгоритм повторных передач более подробно в главе 21.) Полное время, показанное в выводе tcpdump, составляет 29,5 секунды. Однако вывод от команды date перед и после команды telnet показывает, что запрос на соединение от Telnet клиента длился в течении 75 секунд. И действительно, мы увидим позже, что большинство BSD реализаций устанавливают ограничение в 75 секунд для завершения запроса на установление TCP соединения.

В главе 18, при рассмотрении последовательности TCP сегментов, которые посылаются в процессе установления соединения, мы увидим, что моменты отправки ARP запросов полностью совпадают с отправкой сегментов TCP SYN.

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

"Беспричинный" ARP

Другая характеристика ARP, которую стоит рассмотреть - "беспричинный" ARP (gratuitous ARP). Он проявляется, когда хост посылает ARP запрос, основываясь на собственном IP адресе. Обычно это делается, когда интерфейс конфигурируется во время загрузки.

Если мы запустим tcpdump на хосте sun при загрузке хоста bsdi, то увидим пакет, показанный на рисунке 4.7.

1 0.0 0:0:c0:6f:2d:40 ff:ff:ff:ff:ff:ff arp 60:
arp who-has 140.252.13.35 tell 140.252.13.35

Формат ARP запроса или отклика при работе с Ethernet.

Рисунок 4.3 Формат ARP запроса или отклика при работе с Ethernet.

Два первых поля в Ethernet заголовке - поля источника и назначения Ethernet. Специальный адрес назначения Ethernet, состоящий из всех единиц, означает широковещательный адрес. Фреймы с таким адресом будут получены всеми Ethernet интерфейсами на кабеле.

Двухбайтовый тип фрейма (frame type) Ethernet указывает, данные какого типа, пойдут следом. Для ARP запроса или ARP отклика это поле содержит 0x0806.

Выражения аппаратный (hardware) и протокол (protocol) используются для описания полей в пакетах ARP. Например, ARP запрос запрашивает аппаратный адрес (в данном случае Ethernet адрес) соответствующий адресу протокола (в данном случае IP адрес).

Поле hard type указывает на тип аппаратного адреса. Для Ethernet это значение равно единице. Prot type указывает тип адреса протокола, к которому будет приведено соответствие. Для IP адресов используется значение 0x0800. По своему целевому назначению это значение соответствует полю типа во фрейме Ethernet, который содержит IP датаграмму. (См. рисунок 2.1.)

Два следующих однобайтных поля, hard size и prot size, указывают на размеры в байтах аппаратного адреса и адреса протокола. В ARP запросах и откликах они составляют 6 для Ethernet и 4 для IP адреса.

Поле op указывает на тип операции: ARP запрос (значение устанавливается в 1), ARP отклик (2), RARP запрос (3) и RARP отклик (4). (Мы поговорим о RARP в главе 5.) Это поле необходимо, так как поля типа фрейма (frame type) одинаковы для ARP запроса и ARP отклика.

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

Для ARP запроса все поля заполнены, за исключением аппаратного адреса назначения. Когда система получает ARP запрос, который предназначается ей, она вставляет свой аппаратный адрес, меняет местами адреса источника и назначения, устанавливает поле op в значение 2 и отправляет отклик.

Формат пакета ARP

На рисунке 4.3 показан формат ARP запроса и формат ARP отклика, в случае использования Ethernet и IP адресов. (ARP можно использовать в других сетей, при этом он способен устанавливать соответствие не только для IP адресов. Первые четыре поля, следующие за полем типа фрейма, указывают на типы и размеры заключительных четырех полей.)

Команда arp

Мы использовали эту команду с флагом -a, чтобы отобразить все записи ARP кэша. Существуют и другие опции.

Суперпользователь может использовать опцию -d, чтобы удалить запись из ARP кэша. (Это было сделано перед запуском некоторых примеров, чтобы показать изменения ARP.)

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

Ключевое слово pub в конце командной строки с опцией -s приведет к тому, что система будет функционировать как ARP агент для этого хоста. Система будет отвечать на ARP запросы для IP адресов, соответствующих имени хоста, при этом ответ будет содержать указанный Ethernet адрес. Если объявленный адрес это адрес самой отвечающей системы, это означает, что система работает как уполномоченный агент ARP для указанного имени хоста.

Краткие выводы

ARP это основной протокол, который используется практически во всех реализациях TCP/IP. Обычно его функционирование не зависит от используемых приложений или воли системного администратора. ARP кэш является фундаментом этой работы. Мы использовали команду arp, чтобы просмотреть или модифицировать кэш. Каждая запись в кэше имеет таймер, который используется для удаления незавершенных или завершенных записей. Команда arp отображает модифицированные записи в ARP кэше.

Мы посмотрели обычное функционирование ARP и специализированные версии: уполномоченный агент ARP (когда маршрутизатор отвечает на ARP запросы для хостов, находящихся на другом интерфейсе маршрутизатора) и "беспричинный" ARP (посылающий ARP запросы для своего собственного IP адреса, обычно во время загрузки).

Пример

Пример

Если мы введем команду
% ftp bsdi
будет выполнена следующая последовательность действий. (См. рисунок 4.2.)
Приложение, FTP клиент, вызывает функцию gethostbyname(3), чтобы конвертировать имя хоста (bsdi) в 32-битный IP адрес. Эта функция в DNS (Domain Name System) называется разборщиком (resolver) , мы опишем это подробно в главе 14. Подобное преобразование осуществляется с использованием DNS или, если существует маленькая сеть, то с помощью статического файла хостов (/etc/hosts). FTP клиент требует установить TCP соединение с указанным IP адресом. TCP посылает запрос на установление соединения удаленному хосту, посылая IP датаграммы по указанному IP адресу. (Мы рассмотрим как это делается более подробно в главе 18.) Если хост назначения подключен к сети (Ethernet, Token ring, или к другому концу канала точка-точка), IP датаграмма может быть послана непосредственно хосту. Если хост назначения находится в удаленной сети, IP маршрутизатор определяет Internet адрес непосредственно подключенного маршрутизатора следующей пересылки, чтобы послать туда IP датаграмму. В обоих случаях IP датаграмма посылается либо хосту, либо маршрутизатору, подключенные непосредственно к данной сети. Если используется Ethernet, посылающий хост должен конвертировать 32-битный адрес в 48-битный Ethernet адрес. Или другими словами, осуществить преобразование из логического Internet адреса в соответствующий физический аппаратный адрес. Этим занимается ARP. ARP работает в широковещательных сетях, где много хостов или маршрутизаторов подключено к одной и той же сети. ARP посылает фрейм Ethernet, который называется ARP запрос (ARP request), каждому хосту в сети. Подобный метод рассылки называется широковещательным запросом (broadcast). На рисунке 4.2 широковещательный запрос показан пунктирными линиями. ARP запрос содержит IP адрес хоста назначения (имя которого bsdi) и запрос "если Вы владелец этого IP адреса, пожалуйста сообщите мне Ваш аппаратный адрес".

Пример "беспричинного" ARP.

Рисунок 4.7 Пример "беспричинного" ARP.

(Мы использовали флаг -n программы tcpdump, чтобы напечатать адреса в цифровом десятичном виде вместо имен хостов.) В терминах полей ARP запроса, адрес протокола отправителя и адрес протокола назначения идентичны: 140.252.13.35 (что соответствует хосту bsdi). Адрес источника в заголовке Ethernet, 0:0:c0:6f:2d:40 как показано программой tcpdump, эквивалентен аппаратному адресу отправителя (из рисунка 4.4).

"Беспричинный" ARP предоставляет две характеристики. Он позволяет хосту определить, существует ли другой хост с тем же самым IP адресом. Хост bsdi не ожидает отклика на свой запрос, однако если отклик принят, на консоли возникает сообщение об ошибке "обнаружен дублирующий IP адрес с Ethernet адресом: a:b:c:d:e:f". Это предупреждение системному администратору о том, что одна из систем неправильно сконфигурирована. Если хост, посылающий "беспричинный" ARP, только что изменил свой аппаратный адрес (может быть потому, что хост был выключен, удалена интерфейсная плата и затем хост был перезагружен), этот пакет заставляет другой хост на кабеле, который имеет запись в своем кэше для старого аппаратного адреса, обновить ARP кэш соответствующим образом. Малоизвестный факт о протоколе ARP [Plummer 1982] заключается в том, что если хост получает ARP запрос для IP адреса, который он уже имеет в кэше, содержимое кэша обновляется аппаратным адресом отправителя (Ethernet адресом) из запроса ARP. Это делается для любого запроса ARP, полученного хостом. (Повторим, что ARP запросы широковещательные, поэтому такие действия осуществляются всеми хостами в сети каждый раз при появлении ARP запроса.) [Bhide, Elnozahy, and Morgan 1991] описывает приложения, которые используют эту характеристику ARP. Она позволяет запасному (backup) файл-серверу занять место вышедшего из строя сервера с использованием "беспричинного" ARP запроса с запасным аппаратным адресом, однако с тем же IP адресом, который имел вышедший из строя хост. При этом все пакеты, направляемые серверу, вышедшему из строя, будут посланы на запасной сервер, а пользовательские приложения не будут знать о том, что основной сервер вышел из строя.

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

Наблюдения за всеми системами в подсети, используемой в этой книге, показывает, что SunOS 4.1.3 и 4.4BSD используют "беспричинный" ARP при загрузке, а SVR4 не поддерживает эту характеристику.

Пример уполномоченного ARP.

Рисунок 4.6 Пример уполномоченного ARP.

Когда какой-либо другой хост в подсети 140.252.1 (скажем, gemini) хочет послать IP датаграмму хосту sun на адрес 140.252.1.29, gemini сравнивает идентификатор сети (140.252) и идентификатор подсети (1), и если они идентичны, отправляет ARP запрос в верхний Ethernet (на рисунке 4.6) на IP адрес 140.252.1.29. Маршрутизатор netb распознает этот IP адрес как принадлежащий одному из dialup хостов и отвечает, отправив аппаратный адрес этого Ethernet интерфейса в кабель 140.252.1. Хост gemini посылает IP датаграмму в netb по Ethernet, а netb направляет датаграмму в sun по SLIP каналам с дозвоном (dialup). Это делает его прозрачным для всех хостов подсети 140.252.1, так как хост sun действительно находится "позади" маршрутизатора netb.

Если мы запустим команду arp на хосте gemini после общения с хостом sun, то увидим, что оба эти адреса принадлежат подсети 140.252.1 (netb и sun) и что им соответствует один аппаратный адрес. Как правило, это основная причина, по которой используется уполномоченный агент ARP.

gemini % arp -a
появится много строк про хосты из подсети 140.252.1
netb (140.252.1.183) at 0:80:ad:3:6a:80
sun (140.252.1.29) at 0:80:ad:3:6a:80

Еще одна деталь на рисунке 4.6, которую необходимо объяснить, это отсутствие IP адреса под квадратиком, который обозначает маршрутизатор netb (SLIP канал). Почему на обоих концах SLIP канала нет IP адреса, как между bsdi и slip? В разделе "Команда ifconfig" главы 3, из вывода команды ifconfig, мы заметили, что адрес назначения SLIP канала 140.252.1.183. NetBlazer не требует наличия IP адресов на каждом конце SLIP канала. (Это позволяет сэкономить несколько столь ценных в настоящее время IP адресов.) Он определяет какой хост посылает пакет в зависимости от того по какому последовательному интерфейсу прибыл пакет, поэтому нет необходимости каждому хосту на SLIP канале использовать уникальный IP адрес для своего канала с маршрутизатором. Все dialup хосты используют адрес 140.252.1.183 в качестве адреса назначения для своих SLIP каналов.

Уполномоченный агент ARP обеспечивает доставку датаграмм к маршрутизатору sun, однако как это делают другие хосты из подсети 140.252.13? Для направления датаграмм в другие хосты должна использоваться маршрутизация. Где-либо в сети 140.252 должны быть сделаны записи в таблице маршрутизации, поэтому все датаграммы, направляющиеся в подсеть 140.252.13 или в указанные хосты этой подсети, будут направляться на маршрутизатор netb. Этот маршрутизатор знает, как доставить датаграммы в их конечный пункт назначения, отправляя их через маршрутизатор sun.

Уполномоченный агент ARP также называется смешанным (promiscuous ARP) или расщепленным (ARP hack). Эти имена появились благодаря другому использованию уполномоченных агентов ARP: они применялись для того, чтобы спрятать друг от друга две физические сети между которыми находился маршрутизатор. В этом случае обе физические сети использовали один и тот же идентификатор сети, так как маршрутизатор, находящийся между ними, был сконфигурирован как уполномоченный ARP агент, чтобы отвечать на ARP запросы из одной сети к хостам в другой сети. Эта техника использовалась в прошлом, чтобы спрятать группу хостов с более старой версией TCP/IP на отдельном физическом кабеле. Две причины, по которым приходилось отделять эти "устаревшие" хосты, заключались в том, что, во-первых, они не могли поддерживать разделение на подсети и, во-вторых, использовали старые широковещательные адреса (идентификатор хоста состоял из всех нулевых бит вместо современного стандарта, при котором идентификатор хоста состоит из единичных битов).

Примеры ARP

В этом разделе мы воспользуемся командой tcpdump, чтобы посмотреть, как в действительности работает ARP при запуске обычного TCP приложения, например, Telnet. В приложении А содержится дополнительная информация о работе программы tcpdump.

Протоколы определения адреса: ARP и RARP.

Рисунок 4.1 Протоколы определения адреса: ARP и RARP.

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

RARP, в основном, используется системами без жестких дисков (бездисковые рабочие станции или X терминалы), однако здесь требуется ручная конфигурация с участием системного администратора. Мы рассмотрим RARP в главе 5.

Реакция ARP на ввод пользователя: ftp hostname.

Рисунок 4.2 Реакция ARP на ввод пользователя: ftp hostname.

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

Фундаментальная концепция, заложенная в ARP, заключается в следующем. Сетевой интерфейс имеет аппаратный адрес (48-битное значение для Ethernet или Token ring). Фреймы, которыми обмениваются на аппаратном уровне, должны адресоваться к корректному интерфейсу. Однако TCP/IP испоьзует собственную схему адрессации: 32-битные IP адреса. Знание IP адреса хоста не позволяет ядру послать датаграмму этому хосту. Драйвер Ethernet должен знать аппаратный адрес пункта назначения, чтобы послать туда данные. В задачу ARP входит обеспечение динамического соответствия между 32-битными IP адресами и аппаратными адресами, используемыми различными сетевыми технологиями.

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

Тайм-аут ARP кэша

Для записей, вводимых в ARP кэш, обычно устанавливается тайм-аут. (В разделе "Команда arp" мы увидим, что команда arp позволяет системному администратору поместить в кэш определенную запись, и на нее тайм-аут распространяться не будет.) Реализации, произошедшие от Berkeley, обычно установливают тайм-аут, в 20 минут для завершенной записи и 3 минуты для незавершенной записи. (Мы видели незавершенную запись в предыдущем примере, когда заставили отправить ARP запрос на несуществующий хост.) Эти реализации обычно перестартовывают 20-минутный тайм-аут для записи каждый раз, когда эта запись используется.

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

Типичный пример

Чтобы посмотреть как функционирует ARP, мы запустим команду telnet, чтобы подсоединиться к discard (discard server - сервер, не предоставляющий пользователю никаких услуг) серверу.

bsdi% arp -a проверяем, что ARP кэш пуст
bsdi% telnet svr4 discard подсоединяемся к серверу
Trying 140.252.13.34 ...
Connected to svr4.
Escape character is '^]' .
^] нажимаем Control и правую квадратную скобку,
telnet> quit чтобы получить приглашение Telnet и закрыть сессию
Connection closed.

Пока осуществляются эти действия, мы запускаем команду tcpdump с опцией -e на другом хосте (sun). Это позволит нам посмотреть аппаратные адреса (48-битные адреса Ethernet).

1 0.0 0:0:c0:6f:2d:40 ff:ff:ff:ff:ff:ff arp 60:
arp who-has svr4 tell bsdi
2 0.002174 (0.0022) 0:0:c0:c2:9b:26 0:0:c0:6f:2d:40 arp 60:
arp reply svr4 is-at 0:0:c0:c2:9b:26
3 0.002831 (0.0007) 0:0:c0:6f:2d:40 0:0:c0:c2:9b:26 ip 60:
bsdi.1030>svr4.discard: S 596459521:596459521 (0)
win 4096 <mss 1024> [tos 0x10]
4 0.007834 (0.0050) 0:0:c0:c2:9b:26 0:0:c0:6f:2d:40 ip 60:
svr4.discard>bsdi.1030: S 3562228252:3562228252 (0)
ack 596459522 win 4096 <mss 1024>
5 0.009615 (0.0018) 0:0:c0:6f:2d:40 0:0:c0:c2:9b:26 ip 60:
bsdi.1030>svr4.discard: . ack 1 win 4096 [tos 0x10]

Уполномоченный агент ARP

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

Для того чтобы лучше описать работу уполномоченных агентов ARP, мы рассмотрим пример. Из рисунка 3.10 видно, что система sun подключена к двум сетям Ethernet. Однако в действительности это не так, в чем можно убедиться, если сравнить этот рисунок с рисунком, который приведен на внутренней стороне обложки. Между sun и подсетью 140.252.1 находится маршрутизатор, который выступает в роли уполномоченного агента ARP, при этом все выглядело так, как будто sun находится в подсети 140.252.1. На рисунке 4.6 показано, что Telebit NetBlazer, названный netb, находится между подсетью и хостом sun.

Упражнения Вернемся к команде

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

bsdi % rsh svr4 arp -a

чтобы проверить, что ARP кэш также пуст на хосте назначения? (Эта команда исполнит команду arp -a на хосте svr4.)

Опишите тест, который позволит определить, корректно ли обрабатывает определенный хост "беспричинные" ARP запросы. Шаг номер 7 в разделе "Пример" может занять определенное время (миллисекунды), потому что пакет отправлен и ARP ожидает ответа. Как Вы думаете, обработает ли ARP несколько датаграмм, которые прибыли от IP на тот же адрес назначения в течение этого периода времени? В конце раздела "Примеры ARP" мы упомянули, что RFC Host Requirements и Berkeley реализации отличаются с точки зрения обработки тайм-аутов для активных записей ARP. Что произойдет, если клиент Berkeley постарается установить контакт с сервером, который был выключен и из него была удалена плата Ethernet? Изменится ли что-нибудь, если сервер выдаст "беспричинный" ARP запрос при загрузке?

На главную

Введение

Введение

Проблема, которую мы будем обсуждать в этой главе, заключается в том, что IP адреса имеют какое-либо значение только в семействе протоколов TCP/IP. Канальные уровни, такие как Ethernet или Token ring, имеют собственную схему адресации (в основном 48-битные адреса); сетевые уровни, в свою очередь, используют эти канальные уровни. Сеть Ethernet, может быть использована различными сетевыми уровнями в одно и то же время. Компьютеры использующие разные сетевые протоколы могут находиться на одном и том же физическом кабеле.
Когда фрейм Ethernet отправляется от одного хоста по локальной сети к другому, по его 48-битному Ethernet адресу определяется, к какому интерфейсу он должен быть доставлен. Драйвер сетевой платы никогда не смотрит на IP адрес назначения в IP датаграмме.
Другими словами возникает необходимость установить соответствие между двумя различными формами адресов: 32-битными IP адресами и каким-либо типом адресов канального уровня. RFC 826 [Plummer 1982] - официальная спецификация ARP.
На рисунке 4.1 показаны два протокола, которые мы рассмотрим в этой и следующей главах: протокол определения адреса (ARP - address resolution protocol) и обратный протокол определения адреса (RARP - reverse address resolution protocol).

Формат пакета RARP

Формат пакета RARP практически идентичен пакету ARP (см. рисунок 4.3). Единственное отличие заключается в том, что поле тип фрейма (frame type) для запроса или отклика RARP установлено в 0x8035, а поле op имеет значение 3 для RARP запроса и значение 4 для RARP отклика.

RARP запрос является широковещательным, а RARP отклик обычно персональный.

Краткие выводы

RARP используется большинством бездисковых систем при загрузке, для получения свох IP адресов. Формат пакета RARP практически идентичен пакету ARP. Запрос RARP широковещательный, в нем содержится аппаратный адрес отправителя, при этом он спрашивает кого-либо послать ему его IP адрес. Отклик обычно персональный.

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

Несмотря на то что концепция RARP довольно проста, реализация RARP сервера зависит от системы. Также надо отметить, что не все TCP/IP реализации предоставляют RARP сервер.

Несколько RARP серверов в сети

Еще одна особенность заключается в том, что RARP запросы посылаются в виде широковещательных запросов аппаратного уровня, как показано на рисунке 5.2. Это означает, что они не перенаправляются маршрутизаторами. Чтобы позволить бездисковым системам загружаться, даже если RARP сервер выключен, в сети обычно существуют несколько RARP серверов (на одном и том же кабеле).

По мере того как количество серверов растет (чтобы повысить надежность), увеличивается сетевой траффик, так как каждый сервер посылает RARP отклик на каждый RARP запрос. Бездисковые системы, которые посылают RARP запросы, обычно используют первый полученный ими RARP отклик. (Мы никогда не имели подобных проблем с ARP, потому что только один хост посылает ARP отклик.) Более того, существует вероятность, что несколько RARP серверов отправят отклики одновременно, увеличивая тем самым количество коллизий в Ethernet.

Примеры RARP

В нашей сети мы можем заставить хост sun загружаться из сети, вместо того чтобы загружаться с локального диска. Если мы запустили RARP сервер и tcpdump на хосте bsdi, то получим вывод, показанный на рисунке 5.1. Мы используем флаг -e, чтобы команда tcpdump показывала аппаратные адреса:

1 0.0 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
2 0.13 (0.13) 0:0:c0:6f:2d:40 8:0:20:3:f6:42 rarp 42:
rarp reply 8:0:20:3:f6:42 at sun
3 0.14 (0.01) 8:0:20:3:f6:42 0:0:c0:6f:2d:40 ip 65:
sun.26999>bsdi.tftp: 23 RRQ "8CFC0D21.SUN4C"

RARP серверы как пользовательские процессы

Основная задача RARP сервера заключается в том, чтобы предоставить соответствие между аппаратными адресами и IP адресами для множества хостов (все бездисковые системы в сети). Необходимая информация содержится в дисковом файле (обычно /etc/ethers в UNIX системах). Так как ядро обычно не читает дисковые файлы, функция RARP сервера реализуется с использованием пользовательского процесса, который не является частью ядра TCP/IP.

Далее, можно отметить, что RARP запросы передаются в качестве Ethernet фреймов со специфическим полем типа фрейма Ethernet (0x8035 на рисунке 2.1). Это означает, что RARP сервер должен обладать способностью отправлять и принимать Ethernet фреймы подобного типа. В приложении А мы опишем как для приема подобных фреймов используются BSD Packet Filter, Sun Network Interface Tap и SVR4 Data Link Provider Interface. Так как посылка и прием подобных фреймов зависит от системы, реализация RARP сервера также зависит от системы.

RARP запрос при отсутствии в сети RARP сервера.

Рисунок 5.2 RARP запрос при отсутствии в сети RARP сервера.

Когда тайм-аут достигает определенного предела (больше чем 42,80 секунды), он сбрасывается вновь в 5,34 секунды.

Подобное увеличение значения тайм-аута - это наилучший подход, так как каждый раз используется одно и то же значение. На рисунке 6.8 мы увидим неверный подход, с помощью которого осуществляются тайм-ауты и повторные передачи, а в главе 21 мы рассмотрим метод используемый в TCP.

Реализация RARP сервера

Тогда как концепция RARP довольно проста, реализация RARP сервера сильно зависит от системы и довольно сложна. Напротив, реализация ARP сервера проста и является, как правило, частью реализации ядра TCP/IP. Так как ядро знает собственные IP адреса и аппаратные адреса, при получении ARP запроса для одного из IP адресов оно просто формирует отклик с соответствующим аппаратным адресом.

Упражнения

Упражнения

Требуется ли для RARP отдельное поле типа фрейма (frame type)? Может ли быть использовано одно и то же значение 0x0806 для ARP и RARP? Если в сети находится несколько RARP серверов, как они могут сделать так, чтобы предотвратить коллизии своих ответов? Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Введение

Введение

Когда загружается система с локальным диском, она обычно получает свой IP адрес из конфигурационного файла, который считывается с диска. Однако для систем, не имеющих диска, таких как X терминалы или бездисковые рабочие станции, требуются другой способ определения собственного IP адреса.
Каждая система в сети имеет уникальный аппаратный адрес, который назначается производителем сетевого интерфейса (сетевой платы). Принцип работы RARP заключается в том, что бездисковая система может считать свой уникальный аппаратный адрес с интерфейсной платы и послать RARP запрос (широковещательный фрейм в сеть), где потребует кого-нибудь откликнуться и сообщить IP адрес (с помощью RARP отклика).
Несмотря на то что концепция довольно проста, ее реализация как правило значительно сложнее чем ARP, который был описан в предыдущей главе. Официальная спецификация RARP находится в RFC 903 [Finlayson et al. 1984].

Запрос и отклик RARP.

Рисунок 5.1 Запрос и отклик RARP.

Запрос RARP широковещательный (строка 1), а отклик RARP (строка 2) персональный. Вывод в строке 2, at sun, означает, что RARP отклик содержит IP адрес хоста sun (140.252.13.33).

В строке 3 мы видим, что как только sun получил свой IP адрес, он выдал TFTP запрос на чтение (RRQ) файла 8CFC0D21.SUN4C. (TFTP это простой протокол передачи файлов - Trivial File Transfer Protocol. Мы рассмотрим его более подробно в главе 15.) Восемь шестнадцатиричных цифр в имени файла это шестнадцатиричное представление IP адреса 140.252.13.33 хоста sun. Это IP адрес, который мы получили в отклике RARP. Оставшаяся часть имени файла, SUN4C, указывает на тип системы, которая загружается.

В строке 3 tcpdump сообщает, что это IP датаграмма длиной 65, а не UDP датаграмма (которая в действительности является ей), так как мы запустили tcpdump с флаго -e, чтобы получить в выводе аппаратные адреса. Еще один момент на, который необходимо обратить внимание на рисунке 5.1, заключается в том, что длина Ethernet фрейма в строке 2 меньше чем установленный минимум (который, как мы упоминали в разделе "Примеры ARP" главы 4, должен быть равен 60 байтам). Причина этого заключается в том, что мы запустили tcpdump на системе, которая посылает этот Ethernet фрейм (bsdi). Приложение, rarpd, пишет 42 байта в устройство пакетного фильтра BSD (BSD Packet Filter) (14 байт - Ethernet заголовок и 28 байт - отклик RARP), именно это и видит tcpdump. Однако драйвер устройства Ethernet дополняет этот короткий фрейм до минимального размера, необходимого для передачи (60 байт). Если бы мы запустили tcpdump на другом компьютере, длина составила бы 60 байт.

Также мы видим, что когда бездисковая система получает свой IP адрес в отклике RARP, она осуществляет TFTP запрос, чтобы прочитать загрузочный имидж. Сейчас мы не будем подробно рассматривать, как загружаются бездисковые системы. (В главе 16 описывается последовательность загрузки бездисковых X терминалов с использованием RARP, BOOTP и TFTP.)

На рисунке 5.2 показаны пакеты, которые появляются в том случае, если в сети нет RARP сервера. Адрес назначения каждого пакета - широковещательный адрес Ethernet. Адрес Ethernet, следующий за who-is, это аппаратный адрес хоста которому требуется информация, а адрес Ethernet, следующий за tell, это аппаратный адрес отправителя.

Обратите внимание на частоту повторных передач. Первая повторная передача происходит через 6,55 секунд, затем интервал увеличивается до 42,80 секунд, затем через 5,34 секунды, затем через 6,55 секунд и снова через 42,79 секунды. Если мы рассчитаем разницу между каждым тайм-аутом, мы заметим эффект удвоения: между 5,34 и 6,55 - 1,21 секунды, между 6,55 и 8,97 - 2,42 секунды, между 8,97 и 13,80 - 4,83 секунды и так далее.

1 0.0 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
2 6.55 ( 6.55) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
3 15.52 ( 8.97) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
4 29.32 (13.80) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
5 52.78 (23.46) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
6 95.58 (42.80) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
7 100.92 ( 5.34) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
8 107.47 ( 6.55) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
9 116.44 ( 8.97) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
10 130.24 (13.80) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
11 153.70 (23.46) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
12 196.49 (42.79) 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42

Другие возможные варианты

Существуют другие способы получить время и дату. Мы описали сервис дневного времени и сервис времени в разделе "Стандартные простые сервисы" главы 1. Первый возвращает текущую дату и время в формате, понятном для человека - в виде строк ACSII символов. Мы можем проверить работу этого сервиса с использованием команды telnet:

sun % telnet bsdi daytime
Trying 140.252.13.35 ...
Connected to bsdi.
Escape character is '^]'. первые три строки - вывод Telnet клиента
Wed Feb 3 16:38:33 1993 это вывод сервиса дневного времени
Connection closed by foreign host. это опять вывод Telnet клиента

Сервер времени возвращает 32-битное двоичное значение, содержащее количество секунд после полуночи 1 января 1900 года, UTC. (Команда rdate, которую мы упоминали ранее, использует сервис времени TCP.)

Для получения более точного времени используется протокол сетевого времени (NTP - Network Time Protocol), который описан в RFC 1305 [Mills 1992]. Этот протокол использует определенную технику поддержания точности часов для группы систем в локальной или глобальной сети с точностью до миллисекунды. Для более подробного изучения функционирования этого протокола, необходимо обратиться к RFC. Open Software Foundation (OSF) Distributed Computing Environment (DCE) определяет сервис распределенного времени (DTS - Distributed Time Service), который также осуществляет синхронизацию часов между хостами. [Rosenberg, Kenney, and Fisher 1992] более подробно описывает этот сервис. В Unix системах Berkeley существует демон timed(8) , который используется для синхронизации часов систем, находящихся в локальной сети. В отличие от NTP и DTS, timed не работает в глобальных сетях.

Генерация ICMP ошибки о недоступности

Рисунок 6.8 Генерация ICMP ошибки о недоступности порта в ответ на TFTP запрос.

ICMP ошибка о недоступности порта возвращается немедленно (строка 4). Однако TFTP клиент игнорирует ICMP сообщение и посылает следующую UDP датаграмму примерно через 5 секунд (строка 5). Это повторяется трижды, перед тем как клиент прекращает свои попытки.

Обратите внимание на то, что ICMP сообщения передаются между хостами без номера порта назначения, тогда как каждая 20-байтовая UDP датаграмма выходит из указанного порта (2924) в указанный порт (8888).

Число 20 в конце каждой UDP строки это длина данных в UDP датаграмме. В данном примере 20 - это сумма двухбайтного кода операции (opcode) TFTP, 9-байтного имени (temp.foo) и 9-байтной строки netascii. (На рисунке 15.1 подробно описано содержимое пакета TFTP.)

Если мы запустим тот же пример с опцией -e команды tcpdump, то увидим точную длину каждого ICMP сообщения о недоступности порта, которое возвращается отправителю. Длина составляет 70 байт. (см. рисунок 6.9).

ICMP ошибка недоступности порта

ICMP ошибка недоступности порта (ICMP Port Unreachable Error)

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

Если UDP принимает датаграмму, порт назначения которой не соответствует порту, который обслуживается каким-либо процессом, UDP выдает ICMP сообщение о недоступности порта. Попробуем получить ошибку недоступности порта с использованием TFTP клиента. (TFTP подробно описан в главе 15.)

TFTP сервер использует заранее-известный UDP порт 69. Однако большинство программ TFTP клиента позволяют указать другой порт с помощью команды connect. В данном случае мы указали порт 8888:

bsdi % tftp
tftp> connect svr4 8888 указываем имя сервера и номер порта
tftp> get temp.foo пробуем получить файл
Transfer timed out. 25 секунд спустя истекает время таймера
tftp> quit

Команда connect сохраняет имя хоста, с которым необходимо установить соединение, и номер порта на этом хосте для дальнейшего использования командой get. После того как введена команда get, UDP датаграмма посылается на порт 8888 хоста svr4. На рисунке 6.8 показан вывод команды tcpdump, иллюстрирующий обмен пакетами.

Перед тем как послать UDP датаграмму на svr4, отправляется ARP запрос, для того чтобы определить аппаратный адрес (строка 1). Возвращается ARP отклик (строка 2), после чего отправляются UDP датаграммы (строка 3). (Мы оставили ARP запрос-отклик в выводе команды tcpdump, чтобы напомнить Вам, что этот обмен необходим перед отправкой первой IP датаграммы с одного хоста на другой. В следующих примерах мы не будем приводить ARP обмен.)

1 0.0 arp who-has svr4 tell bsdi
2 0.002050 (0.0020) arp reply svr4 is-at 0:0:c0:c2:9b:26

3 0.002723 (0.0007) bsdi.2924 > svr4.8888: udp 20
4 0.006399 (0.0037) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

5 5.000776 (4.9944) bsdi.2924 > svr4.8888: udp 20
6 5.004304 (0.0035) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

7 10.000887 (4.9966) bsdi.2924 > svr4.8888: udp 20
8 10.004416 (0.0035) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

9 15.001014 (4.9966) bsdi.2924 > svr4.8888: udp 20
10 15.004574 (0.0036) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

11 20.001177 (4.9966) bsdi.2924 > svr4.8888: udp 20
12 20.004759 (0.0036) svr4 > bsdi: icmp: svr4 udp port 8888 unreachable

ICMP сообщение.

Рисунок 6.2 ICMP сообщение.

В этой главе мы рассмотрим ICMP сообщения в целом, некоторые из них подробно: запрос и отклик маски адреса, запрос и отклик временной марки и сообщение о недоступности порта. В главе 7 мы обсудим, с использованием программы Ping, эхо запрос и эхо отклик, а в главе 9 рассмотрим ICMP сообщения, связанные с IP маршрутизацией.

ICMP сообщение, вернувшееся в

Рисунок 6.9 ICMP сообщение, вернувшееся в нашем примере "порт UDP недоступен".

Одно из правил, которому подчиняется ICMP, заключается в том, что ICMP сообщение об ошибке (см. последнюю колонку на рисунке 6.3) должно включать IP заголовок (включая все опции) датаграммы, на которую сгенерирована ошибка. Также ICMP сообщение об ошибке содержит, по крайней мере, первые 8 байт из IP датаграммы, которые следуют за IP заголовком. В нашем примере первые 8 байт, следующие за IP заголовком, содержат UDP заголовок (рисунок 11.2).

Очень важный факт заключается в том, что UDP заголовок содержит номера портов источника и назначения. В данном случае это порт назначения (8888), из-за которого было сгенерировано ICMP сообщение о недоступности порта. Номер порта источника (2924) может быть использован системой, получившей ICMP сообщение об ошибке, чтобы установить соответствие между принятой ошибкой и конкретным пользовательским процессом (в данном случае TFTP клиент).

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

ICMP запрос и отклик маски адреса

ICMP запрос маски адреса используется бездисковыми системами, чтобы получить маску подсети (глава 3, раздел "Маска подсети") во время загрузки. Система посылает широковещательный ICMP запрос. (Это напоминает то, как бездисковые системы с использованием RARP получают свои IP адреса во время загрузки.) Альтернативный метод для бездисковых систем получить маски своих подсетей - протокол BOOTP, о котором рассказано в главе 16. На рисунке 6.4 показан формат ICMP запроса и отклика маски адреса.

ICMP запрос и отклик маски адреса.

Рисунок 6.4 ICMP запрос и отклик маски адреса.

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

Мы можем написать простую программу (которая называется icmpaddrmask), которая выдает ICMP запрос маски адреса и печатает все отклики. Обычно, запрос отправляется на широковещательный адрес, мы поступим точно так же. Адрес назначения (140.252.13.63) это широковещательный адрес для подсети 140.252.13.32 (см. рисунок 3.12).

sun % icmpaddrmask 140.252.13.63
received mask = ffffffe0, from 140.252.13.33 от самого себя
received mask = ffffffe0, from 140.252.13.35 от bsdi
received mask = ffff0000, from 140.252.13.34 от svr4

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

svr4 % ifconfig emd0
emd0: flags=23<UP, BROADCAST, NOTRAILERS.
inet 140.252.13.34 netmask ffffffe0 broadcast 140.252.13.63

Это одна из известных ошибок SVR4 возникающая при обработке ICMP запросов маски адреса.

Мы рассмотрим обмен пакетами для хоста bsdi, используя tcpdump. Вывод показан на рисунке 6.5. Была использована опция -e, которая позволяет посмотреть аппаратные адреса.

1 0.0 8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff ip 60:
sun > 140.252.13.63: icmp: address mask request
2 0.00 (0.00) 0:0:c0:6f:2d:40 ff:ff:ff:ff:ff:ff ip 46:
bsdi > sun: icmp: address mask is 0xffffffe0
3 0.01 (0.01) 0:0:c0:6f:2d:40 8:0:20:3:f6:42 ip 60:
svr4 > sun: icmp: address mask is 0xffff0000

ICMP запрос и отклик временной марки

ICMP запрос временной марки позволяет системе запросить другую систему о текущем времени. Рекомендуемое значение, которое должно быть возвращено, это количество миллисекунд, которые прошли с полуночи в формате UTC, (Универсальное согласованное время - Coordinated Universal Time). (В старых руководствах UTC называется Среднее время по Гринвичу - Greenwich Mean Time.) Одна из основных особенностей ICMP сообщения заключается в том, что оно предоставляет время в с точностью до миллисекунд, тогда как другие методы используемые для получения времени от удаленных систем (например, команда rdate, существующая в некоторых UNIX системах) предоставляют время с точностью до секунд. Недостаток заключается в том, что сообщается только время, прошедшее с полуночи, - запрашивающая система должена знать текущую дату. На рисунке 6.6 показан формат ICMP запроса и формат ICMP отклика временной марки.

ICMP запрос и отклик временной марки.

Рисунок 6.6 ICMP запрос и отклик временной марки.

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

ICMP запрос маски адреса, отправленный

Рисунок 6.5 ICMP запрос маски адреса, отправленный на широковещательный адрес.

Обратите внимание на то, что посылающий хост, sun, принимает ICMP отклик (строка вывода с комментарием "от самого себя", которая была показана ранее), даже если "в кабеле" ничего не было. Это основная характеристика широковещательных запросов: посылающий хост принимает копию широковещательного пакета через внутренний механизм loopback. Так как по определению термин "широковещательный запрос" означает все хосты в локальной сети, сюда же включается и посылающий хост. (Если обратиться к рисунку 2.4, можно увидить, что драйвер Ethernet, определив, что адрес назначения является широковещательным, посылает пакет в сеть и копирует его в интерфейс loopback.)

Затем bsdi отправляет широковещательным запросом отклик, тогда как svr4 посылает отклик только тому, кто отправил запрос. Обычно отклик должен быть персональным, если только IP адрес источника в запросе не установлен в 0.0.0.0, отправка откликов на широковещательный адрес это ошибка, допущенная в BSD/386.

Требования к хостам Host Requirements RFC гласят, что система не должна отправлять отклик о маске адреса, если она не является полномочным агентом для рассылки масок адресов. (Чтобы являтьься полномочным агентом и рассылать подобные отклики, система должна быть специально сконфигурирована. (См. приложение Е.) Однако, как мы видим из этого примера, большинство реализаций посылают отклик в ответ на полученный запрос. Иногда хосты даже посылают неверные отклики!

Обратимся к следующему примеру. Мы посылаем запрос о маске адреса на свой собственный IP адрес и на loopback адрес:

sun % icmpaddrmask sun
received mask = ff000000, from 140.252.13.33

sun % icmpaddrmask localhost
received mask = ff000000, from 127.0.0.1

В обоих случаях возвращенная маска адреса соответствует адресу loopback, адресу 127.0.0.1 сети класса А. Снова обратившись к рисунку 2.4 мы увидим, что IP датаграммы, посланные на собственный IP адрес хоста (140.252.13.33 в данном примере), в действительности посылаются на loopback интерфейс. ICMP отклик о маске адреса должен соответствовать маске подсети интерфейса, на которой был принят запрос (при этом хост с несколькими интерфейсами может иметь различные маски подсети для каждого интерфейса), а в нашем случае оба запроса получены с интерфейса loopback.

Инкапсуляция ICMP сообщений в IP датаграммы.

Рисунок 6.1 Инкапсуляция ICMP сообщений в IP датаграммы.

Официальная спецификация ICMP находится в RFC 792 [Postel 1981b].

На рисунке 6.2 показан формат ICMP сообщения. Первые 4 байта одинаковы для всех сообщений, однако остальные отличаются в зависимости от типа сообщения. Мы будем показывать точный формат каждого сообщения, по мере того как будем их описывать.

Существует 15 различных значений для поля типа (type), которые указывают на конкретныей тип ICMP сообщения. Для некоторых ICMP сообщений используются различные значения в поле кода (code), подобным образом осуществляется дальнейшее подразделение ICMP сообщений.

Поле контрольной суммы (checksum) охватывает ICMP сообщения целиком. Алгоритм, используемый при этом, такой же как тот, что был описан в разделе "IP заголовок" главы 3 при расчете контрольной суммы IP заголовка. Контрольная сумма ICMP присутствует всегда.

Краткие выводы

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

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

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

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

Обработка ICMP сообщений в 4.4BSD

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

Если в последней колонке указано "ядро", ICMP сообщение обрабатывается ядром, если - "пользовательский процесс", это означает, что сообщение передается всем пользовательским процессам, которые зарегистрированы в ядре так, что могут читать принятые ICMP сообщения. Если подобных пользовательских процессов нет, сообщение молча удаляется. (Эти пользовательские процессы также получают копии всех других ICMP сообщений, даже если те обрабатываются ядром, однако только после того, как ядро обработало сообщение.) Некоторые сообщения полностью игнорируются. И в заключение, если в последней колонке находится строка в кавычках, то эта строка является сообщением об ошибке Unix, соответствующее создавшемуся условию. Некоторые из ошибок мы рассмотрим в следующих главах.

тип	код	Описание	Кем обрабатывается
0	0	эхо отклик	пользовательский процесс
3		назначение недоступно - destination unreachable:
	0	сеть недоступна - network unreachable	"No route to host"
	1	хост недоступен - host unreachable	"No route to host"
	2	протокол недоступен - protocol unreachable	"Connection refused"
	3	порт недоступен - port unreachable	"Connection refused"
	4	необходима фрагментация, но установлен бит DF - fragmentation needed but DF bit set	"Message too long"
	5	сбой маршрутизация от источника - source route failed	"No route to host"
	6	сеть назначения неизвестна - destination network unknown	"No route to host"
	7	хост назначения неизвестен - destination host unknown	"No route to host"
	8	хост назначения изолирован - source host isolated (obsolete)	"No route to host"
	9	сеть назначения административно закрыта - destination network administratively prohibited	"No route to host"
	10	хост назначения административно закрыт - destination host administratively prohibited	"No route to host"
	11	сеть недоступна для TOS - network unreachable for TOS	"No route to host"
	12	хост недоступен для TOS - host unreachable for TOS	"No route to host"
	13	связь административно закрыта - communication administratively prohibited	(игнорируется)
	14	нарушено старшинство для хоста - host precedence violation	(игнорируется)
	15	старшинство разъединено - precedence cutoff in effect	(игнорируется)
4	0	подавление источника - source quench	ядром TCP, игнорируется UDP
5		перенаправление - redirect:
	0	перенаправление в сеть - redirect for network	ядро обновляет таблицу маршрутизации
	1	перенаправление в хост - redirect for host	ядро обновляет таблицу маршрутизации
	2	перенаправление для типа сервиса и сети - redirect for type-of-service and network	ядро обновляет таблицу маршрутизации
	3	перенаправление для типа сервиса и хоста - redirect for type-of-service and host	ядро обновляет таблицу маршрутизации
8	0	эхо запрос - echo request	ядро генерирует отклик
9	0	объявление маршрутизатора - router advertisement	пользовательский процесс
10	0	запрос к маршрутизатору - router solicitation	пользовательский процесс
11		время истекло - time exceeded:
	0	время жизни стало равным 0 в процессе передачи - time-to-live equals 0 during transit	пользовательский процесс
	1	время жизни стало равным 0 в процессе повторной сборки - time-to-live equals 0 during reassembly	пользовательский процесс
12		проблемы с параметрами - parameter problem:
	0	неверный IP заголовок - IP header bad	"Protocol not available"
	1	отсутствует необходимая опция - required option missing	"Protocol not available"
13	0	запрос временной марки - timestamp request	ядро генерирует отклик
14	0	отклик с временной маркой - timestamp reply	пользовательский процесс
15	0	информационный запрос - information request	(игнорируется)
16	0	информационный отклик - information reply	пользовательский процесс
17	0	запрос маски адреса - address mask request	ядро генерирует отклик
18	0	отклик с маской адреса - address mask reply	пользовательский процесс

Обработка ICMP сообщений в 4.4BSD.

Рисунок 6.12 Обработка ICMP сообщений в 4.4BSD.

Примеры

Примеры

Воспользуемся простой программой (которая называется icmptime), которая посылает ICMP запрос временной марки и печатает полученный отклик. Запустим эту программу в нашей маленькой сети:
sun % icmptime bsdi
orig = 83573336, recv = 83573330, xmit = 83573330, rtt = 2 ms
difference = -6 ms

sun % icmptime bsdi
orig = 83577987, recv = 83577980, xmit = 83577980, rtt = 2 ms
difference = -7 ms
Программа выдала три временные марки из ICMP сообщения: исходную (orig), приема (recv) и передачи (xmit). Из этого и следующих примеров видно, что все хосты установили временные марки приема и передачи в одно и то же значение.
Также мы рассчитали время возврата (rtt) , которое рассчитывается как время, когда был принят отклик, минус время, когда был отправлен запрос. difference - это временная марка приема минус исходная временная марка. На рисунке 6.7 показана взаимосвязь между этими значениями.

Сообщение о недоступности ICMP.

Рисунок 6.10 Сообщение о недоступности ICMP.

На рисунке 6.3 мы видели, что существует 16 различных ICMP сообщений о недоступности с кодами от 0 до 15. ICMP сообщение о недоступности порта имеет код 3. На рисунке 6.10 показано, что второе 32-битное слово в ICMP сообщении должно быть установлено в 0. Механизм определения транспортного MTU (глава 2, раздел "Транспортный MTU") позволяет маршрутизатору поместить MTU исходящего интерфейса в младшие 16 бит этого 32-битного значения, когда код равен 4 ("необходима фрагментация, однако установлен бит не фрагментировать "). Мы покажем пример подобной ошибки в разделе "ICMP ошибки о недоступности (требуется фрагментация)" главы 11.

Правила, по которым действует ICMP, позволяют системе вернуть больше чем первые 8 байт раздела данных IP датаграммы, которая вызвала ICMP ошибку, однако большинство Berkeley реализаций возвращают ровно 8 байт. В Solaris 2.2, с использованием опции ip_icmp_return_data_bytes, может быть указано, сколько байт необходимо возвращать, однако по умолчанию возвращаются первые 64 байта данных (приложение E, раздел "Solaris 2.2").

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

На рисунке 6.3 приведены возможные типы ICMP сообщений, как они определяются полями типа (type) и кода (code).

Последние две колонки на рисунке указывают, является ли ICMP сообщение запросом (query) или сообщением об ошибке (error). Подобное разделение необходимо, потому что сообщения об ошибках ICMP иногда обрабатываются специальным образом. Например, ICMP сообщение об ошибке никогда не генерируется в ответ на ICMP сообщение об ошибке. (Если не придерживаться этого правила, то ошибка будет генерироваться на ошибку до бесконечности.)

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

Сообщение об ошибке ICMP никогда не генерируется в ответ на: ICMP сообщение об ошибке. (ICMP сообщение об ошибке, однако, может быть сгенерировано в ответ на ICMP запрос.) Датаграмму, направляющуюся на широковещательный IP адрес (рисунок 3.9) или групповой адрес IP (адрес класса D, рисунок 1.5). Датаграмму, которая посылается широковещательным запросом на канальном уровне. Фрагмент, который не является первым. (Мы опишем фрагментацию в разделе "Фрагментация IP" главы 11.) Датаграмму, адрес источника которой не указывает на конкретный хост. Это означает, что адрес источника не может быть нулевым, loopback адресом, широковещательным или групповым адресом.

тип	код	Описание	запрос	ошибка
0	0	эхо-отклик (отклик-Ping, глава 7)	·
3		назначение недоступно:
	0	сеть недоступна - network unreachable (раздел "ICMP ошибки о недоступности хоста и сети" главы 9)		·
	1	хост недоступен - host unreachable (раздел "ICMP ошибки о недоступности хоста и сети" главы 9)		·
	2	протокол недоступен - protocol unreachable		·
	3	порт недоступен - port unreachable (раздел "ICMP ошибка недоступности порта (ICMP Port Unreachable Error)" главы 6)		·
	4	необходима фрагментация, однако установлен бит “не фрагментировать”- fragmentation needed but don’t-fragment bit set (раздел "ICMP ошибки о недоступности" главы 11)		·
	5	не работает маршрутизация от источника - source route failed (глава 8, раздел "Опция IP маршрутизации от источника")		·
	6	неизвестна сеть назначения - destination network unknown		·
	7	неизвестен хост назначения - destination host unknown		·
	8	хост источник изолирован - source host isolated		·
	9	сеть назначения закрыта администратором - destination network administrativrly prohibited		·
	10	хост назначения закрыт администратором - destination host administrativrly prohibited		·
	11	сеть недоступна для TOS - network unreachable for TOS (глава 9, раздел "ICMP ошибки о недоступности хоста и сети")		·
	12	хост недоступен для TOS - host unreachable for TOS (глава 9, раздел "ICMP ошибки о недоступности хоста и сети")		·
	13	связь административно закрыта путем фильтрации - communication administratively prohibited by filtering		·
	14	нарушено старшинство для хоста - host precedence violation		·
	15	старшинство разъединено - precedence cutoff in effect		·
4	0	подавление источника (элементарное управление потоком данных) - source quench (глава 11, раздел "ICMP ошибка подавления источника")		·
5		перенаправление - redirect (глава 11, раздел "ICMP ошибка подавления источника"):
	0	перенаправление в сеть - redirect for network		·
	1	перенаправление в хост - redirect for host		·
	2	перенаправление для типа сервиса и сети - redirect for type-of-service and network		·
	3	перенаправление для типа сервиса и хоста - redirect for type-of-service and host		·
8	0	эхо запрос - echo request (Ping запрос, глава 7)	·
9	0	объявление маршрутизатора - router advertisement (глава 9, раздел "ICMP сообщения поиска маршрутизатора")	·
10	0	запрос к маршрутизатору - router solicitation (глава 9, раздел "ICMP сообщения поиска маршрутизатора")	·
11		время истекло - time exceeded:
	0	время жизни стало равным 0 в процессе передачи - time-to-live equals 0 during transit (Traceroute, глава 8)		·
	1	время жизни стало равным 0 в процессе повторной сборки - time-to-live equals 0 during reassembly (глава 11, раздел "Фрагментация IP")		·
12		проблемы с параметрами - parameter problem:
	0	неверный IP заголовок - IP header bad		·
	1	отсутствует необходимая опция - required option missing		·
13	0	запрос временной марки - timestamp request (глава 6, раздел "ICMP запрос и отклик временной марки")	·
14	0	отклик с временной маркой - timestamp reply (глава 6, раздел "ICMP запрос и отклик временной марки")	·
15	0	информационный запрос - information request	·
16	0	информационный отклик - information reply	·
17	0	запрос маски адреса - address mask request (глава 6, раздел "ICMP запрос и отклик маски адреса")	·
18	0	отклик с маской адреса - address mask reply (глава 6, раздел "ICMP запрос и отклик маски адреса")	·

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

Рисунок 6.3 Типы сообщений ICMP.

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

Упражнения

Упражнения

В конце раздела "Типы сообщений ICMP" мы привели 5 специальных условий, при которых сообщение об ошибке ICMP не посылается. Что произойдет, если эти 5 условий не соблюдены, а мы послали широковещательную UDP датаграмму на несоответствующий порт в локальном кабеле? Прочитайте Host Requirements RFC [Braden 1989a], чтобы посмотреть, попадает ли генерация ICMP ошибки о недоступности порта под разделы "должен", "следует" или "может". В каком разделе и на какой странице это можно найти? Прочитайте RFC 1349 [Almquist 1992], чтобы посмотреть, как поле типа сервиса IP (см. рисунок 3.2) должно быть установлено для ICMP. Если Ваша система имеет команду netstat, используйте ее, чтобы посмотреть, какой тип ICMP сообщений принимается и посылается. Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Временная диаграмма работы команды tcpdump

Здесь мы приводим временную диаграмму, соответствующую выводу команды tcpdump, приведенному на рисунке 6.11.

Временная диаграмма запроса TFTP на неверный порт.

Рисунок 6.11 Временная диаграмма запроса TFTP на неверный порт.

Время на рисунке увеличивается по направлению вниз, а метки, стоящие крайними слева на рисунке, соответствуют величинам времени в выводе команды tcpdump, приведенном на рисунке 6.8. Метки вверху - это имена хостов и номера портов каждой конечной системы. Однако, вертикальное представление времени на рисунке не точно соответствует реальному времени. При передаче данных UDP или TCP мы показываем пакет с помощью жирной линии.

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

Также необходимо обратить внимание на то, что при работе TFTP клиента используется алгоритм тайм-аутов и повторных передач. TFTP клиент просто осуществляет повторную передачу каждые 5 секунд, всего в течение 25 секунд. Позже мы увидим, что подобный алгоритм протокола TCP значительно лучше.

Устаревший алгоритм тайм-аутов и повторных передач, используемый TFTP клиентом, в настоящее время запрещен Host Requirements RFC. Тем не менее, все три системы в описываемой подсети и Solaris 2.2 до сих пор его используют. AIX 3.2.2 использует экспотенциальный рост тайм-аута, посылая пакеты с интервалом 0, 5, 15 и 35 секунд. В настоящее время рекомендуется именно такой способ расчета тайм-аутов. Более подробно мы обсудим тайм-ауты в главе 21.

И в заключение, обратите внимание на то, что ICMP сообщения вернулись примерно через 3,5 миллисекунды после отправки UDP датаграммы. В главе 7 мы увидим, что это примерно соответствует времени возврата для отклика Ping.

Введение

Введение

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

Взаимосвязь между значениями

Рисунок 6.7 Взаимосвязь между значениями, напечатанными программой icmptime.

Если принять за истину то, что одна половина RTT отводится под запрос, а другая половина под отклик, тогда часы отправителя должны быть настроены как difference минус половина RTT, чтобы иметь то же самое время, как у хоста к которому отправляется запрос. В предыдущем примере часы bsdi отставали на 7 и 8 миллисекунд от часов sun.

Так как временная марка является количеством миллисекунд после полуночи, UTC должны быть всегда меньше чем 86400000 (24х60х60х1000). Эти примеры были исполнены сразу после 16:00 во временной зоне имеющей отставание на 7 часов от UTC, таким образом, приемлемыми являются значения больше чем 82800000 (2300 часов).

Если мы запустим эту программу несколько раз на хост bsdi, то увидим, что последние цифры во временной марке передачи и приема всегда равны нулю. Это происходит из-за того, что программный релиз (Version 0.9.4) имеет часы с точностью 10 миллисекунд. (Мы опишем это в приложении В.)

Если мы запустим программу дважды на хост svr4, то увидим что уже три младшие цифры во временной марке SVR4 равны нулю:

sun % icmptime svr4
orig = 83588210, recv = 83588000, xmit = 83588000, rtt = 4 ms
difference = -210 ms

sun % icmptime svr4
orig = 83591547, recv = 83591000, xmit = 83591000, rtt = 4 ms
difference = -547 ms

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

Если мы обратимся к двум другим хостам в подсети 140.252.1, то увидим, что установка одних часов отличается от установки часов sun на 3,7 секунды, а других на 75 секунд:

sun % icmptime gemini
orig = 83601883, recv = 83598140, xmit = 83598140, rtt = 247 ms
difference = -3743 ms

sun % icmptime aix
orig = 83606768, recv = 83532183, xmit = 83532183, rtt = 253 ms
difference = -74585 ms

Другой интересный пример может быть получен при обращении к маршрутизатору gateway (маршрутизатор Cisco). Из примера видно, что если система возвращает нестандартное значение временной марки (отличающееся от количества миллисекунд после полуночи, UTC), старшие биты в 32-битной временной марке устанавливаются в единицу. Наша программа определяет это и печатает временные марки приема и передачи в треугольных скобках (после установки старших битов в ноль). Мы можем рассчитать разницу между исходной временной маркой и временной маркой приема.

sun % icmptime gateway
orig = 83620811, recv = <4871036>, xmit = <4871036>, rtt = 220 ms

sun % icmptime gateway
orig = 83641007, recv = <4891232>, xmit = <4891232>, rtt = 213 ms

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

И в качестве последнего примера сравним часы sun с часами системы, которые считаются абсолютно точными - сервер NTP. (Мы расскажем о протоколе сетевого времени NTP - Network Time Protocol, ниже.)

sun % icmptime clock.llnl.gov
orig = 83662791, recv = 83662919, xmit = 83662919, rtt = 359 ms
difference = 128 ms

sun % icmptime clock.llnl.gov
orig = 83670425, recv = 83670559, xmit = 83670559, rtt = 345 ms
difference = 134 ms

Если вычесть из разницы (difference) половину RTT, то можно будет сказать, что часы sun торопятся на величину в диапазоне 51,5 - 38,5 миллисекунды.