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

Формат ICMP сообщения для эхо запроса и эхо отклика.

Рисунок 7.1 Формат ICMP сообщения для эхо запроса и эхо отклика.

Так же, как в случае других ICMP запросов, в отклике сервера должены содержаться поля идентификатора (identifier) и номера последовательности (sequence number). Кроме того, любые дополнительные данные, посланные клиентам, должны быть отражены эхом.

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

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

Исторически сложилось так, что программа ping посылает эхо запрос один раз в секунду, печатая каждый эхо отклик в момент его возвращения. Однако новые разработки требуют указания опции -s, чтобы программа работала подобным образом. По умолчанию новые реализации посылают только один эхо запрос и выдают сообщение "host is alive" (хост доступен), если эхо отклик получен, или "no answer" (не отвечает), если отклик не получен в течение 20 секунд.

IP опция временной марки

Опция IP временной марки во многом напоминает опцию записи маршрута. На рисунке 7.7 показан формат IP опции временной марки (сравните с рисунком 7.3).

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

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

Мы рассмотрели стандартный вывод команды ping для локальных, глобальных сетей и каналов SLIP (с дозвоном и выделенных), и рассчитали пропускную способность последовательных линий выделенных SLIP каналов. ping также позволяет использовать IP опцию записи маршрута. Мы использовали эту IP опцию, чтобы посмотреть как используется маршрут по умолчанию. Мы вернемся к этой теме в главе 9. Также мы рассмотрели IP опцию временной марки, однако она имеет ограниченную практическую ценность.

Упражнения

Нарисуйте временной график вывода программы ping для SLIP канала из раздела "Программа Ping". Рассчитайте RTT, если SLIP канал между bsdi и slip имеет скорость 9600 бит/сек. Считайте, что по умолчанию передается 56 байт данных. Текущая программа ping в BSD позволяет нам указать шаблон для раздела данных ICMP сообщения. (Первые 8 байт раздела данных не заполняются шаблоном, а в тот момент, когда пакет отправляется, они хранятся здесь.) Если мы укажем шаблон 0xc0, повторно рассчитайте ответ на предыдущее упражнение. (Подсказка: просмотрите раздел "SLIP: IP по последовательной линии" главы 2.) Влияет ли использование SLIP со сжатием (CSLIP, глава 2, раздел "SLIP с компрессией (CSLIP)") на временные интервалы, которые мы рассматривали в разделе "Программа Ping", при работе команды ping?

Рассмотрите рисунок 2.4. Замечаете ли Вы разницу между pingом на loopback адрес и pingом на Ethernet адрес?

На главную

Ненормальный вывод

Следующий пример был рассмотрен автором и является исходной точкой для дальнейшего описания ICMP сообщений о перенаправлении в главе 9. Мы посылаем ping на хост aix, находящийся в подсети 140.252.1, с хоста slip (доступ осуществляется через SLIP соединение с дозвоном на компьютере sun) с опцией записи маршрута. При этом получаем следующий вывод:

slip % ping -R aix
PING aix (140.252.1.92): 56 data bytes
64 bytes from 140.252.1.92: icmp_seq=0 ttl=251 time=650 ms
RR: bsdi (140.252.13.35)
sun (140.252.1.29)
netb (140.252.1.183)
aix (140.252.1.92)
gateway (140.252.1.4) почему используется этот маршрутизатор?
netb (140.252.1.183)
sun (140.252.13.33)
bsdi (140.252.13.66)
slip (140.252.13.65)
64 bytes from aix: icmp_seq=1 ttl=251 time=610 ms (same route)
64 bytes from aix: icmp_seq=2 ttl=251 time=600 ms (same route)
^?
--- aix ping statistics ---
4 packets transmitted, 3 packets recieved, 25% packet loss
round-trip min/avg/max = 600/620/650 ms

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

Странность этого вывода заключается в том, что исходящая датаграмма (ICMP эхо запрос) направляется непосредственно от netb к aix, а возвращается (ICMP эхо отклик) от aix через маршрутизатор gateway, перед тем как попасть в netb. То что мы видим здесь, является характеристикой IP маршрутизации, которую мы опишем ниже. На рисунке 7.6 показан путь датаграммы.

Общий формат опции маршрута в IP заголовке.

Рисунок 7.3 Общий формат опции маршрута в IP заголовке.

Код (code) - однобайтовое поле, содержащее тип IP опции. Для опции RR установлено значение 7. Длина (len) - это полный размер в байтах опции RR, в данном случае 39. (Несмотря на то, что существует возможность указать опцию RR с размером меньше максимального, ping всегда предоставляет поле опции размером 39 байт, что позволяет записать до 9 IP адресов. Несмотря на то, что существует ограничение в размере опций в IP заголовке, оно, тем не менее, позволяет указать размер меньше максимального.)

Указатель (ptr) - это индекс в 39-байтной опции, который указывает на то, где хранится следующий IP адрес. Его минимальное значение 4, что указывает на первый IP адрес. Когда следующий IP адрес записывается в список, значение ptr меняется следующим образом: 8, 12, 16 и так до 36. После того как записан девятый адрес, ptr устанавливается в значение 40, указывая на то, что список полон. А теперь давайте зададим себе такой вопрос.

Когда маршрутизатор (который по определению имеет несколько интерфейсов) записывает свой IP адрес в список, какой IP адрес он записывает? Это должен быть адрес либо входящего интерфейса, либо исходящего. RFC 791 [Postel 1981a] указывает, что маршрутизатор записывает IP адрес исходящего интерфейса. Однако, мы увидим, что когда исходный хост (хост, запустивший ping) получает ICMP эхо отклик с включенной опцией RR, он вносит в список IP адрес своего входящего интерфейса.

Общий формат опции временной марки в IP заголовке.

Рисунок 7.7 Общий формат опции временной марки в IP заголовке.

Для опции временной марки поле кода (code) устанавливается в 0x44. Два поля длина (len) и указатель (ptr) такие же как в опции записи маршрута: полная длина опции (обычно 36 или 40) и указатель на следующий доступный пункт (5, 9, 13 и так далее).

Размер двух следующих полей составляет 4 бита: OF - поле переполнения (overflow) и FL - поле флагов (flags). Функционирование опции временной марки определяется полем флагов (flags), как показано на рисунке 7.8.

флаги (flags)	Описание
0	Запись только временных марок. Это как раз то, что мы показали на рисунке 7.7.
1	Каждый маршрутизатор записывает свой IP адрес и временную марку. Места в списке опций хватает только на четыре такие пары.
3	Отправитель устанавливает список опций, который должен состоять из 4-х пар IP адресов 0 (ноль) временных марок. Маршрутизатор записывает свою временную марку только в том случае, если следующий IP адрес из списка совпадает с IP адресом маршрутизатора.

Обычный пример

Давайте попробуем запустить программу ping с опцией RR. Мы запустили ping с хоста svr4 на хост slip. Промежуточный роутер (bsdi) обрабатывает датаграмму, следующий вывод будет получен от svr4:

svr4 % ping -R slip
PING slip (140.252.13.65): 56 data bytes
64 bytes from 140.252.13.65: icmp_seq=0 ttl=254 time=280 ms
RR: bsdi (140.252.13.66)
slip (140.252.13.65)
bsdi (140.252.13.35)
svr4 (140.252.13.34)
64 bytes from 140.252.13.65: icmp_seq=1 ttl=254 time=280 ms (same route)
64 bytes from 140.252.13.65: icmp_seq=2 ttl=254 time=280 ms (same route)
^?
--- slip ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 270/276/280 ms

На рисунке 7.4 показаны 4 пересылки, через которые проходит пакет (по две в каждом направлении), а также IP адреса добавляемые к списку RR при каждой пересылке.

Опция записи IP маршрута

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

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

Самая большая проблема, однако, заключается в ограниченном размере IP заголовка, в который должен поместиться список IP адресов. Из рисунка 3.1 видно, что поле длины заголовка (header length) в IP заголовке составляет 4 бита, что ограничивает размер IP заголовка в пределах пятнадцати 32-битных слов (60 байт). Так как фиксированный размер IP заголовка составляет 20 байт, а RR опция использует 3 байта для своей установки (что мы опишем ниже), то остается 37 байт (60-20-3) на список адресов, а это, в свою очередь, позволяет поместить туда до 9 IP адресов. На заре развития ARPANET 9 IP адресов - было очень много, однако, в настоящее время, подобный размер существенно ограничивает работу команды ping с опцией -R. (В главе 8 мы рассмотрим программу Traceroute, которая используется для отслеживания маршрута, по которому двигается датаграмма.) Несмотря на все ограничения, опция записи маршрута работает и предоставляет возможность пронаблюдать, как обрабатываются опции IP. На рисунке 7.3 показан общий формат опции записи маршрута в IP датаграмме.

Программа Ping

Мы будем называть программу ping, которая посылает эхо запросы - клиент, а хост, на который посылаются эхо запросы - сервер. Большинство реализаций TCP/IP поддерживают Ping сервер непосредственно в ядре - сервер не является пользовательским процессом. (Два сервиса, работающие с ICMP запросами, которые мы описали в главе 6, маска адреса и запросы временной марки, также обрабатываются непосредственно в ядре.) На рисунке 7.1 показаны ICMP эхо запрос и эхо отклик.

Программа ping с опцией записи маршрутизации.

Рисунок 7.4 Программа ping с опцией записи маршрутизации.

Маршрутизатор bsdi добавляет в список разные IP адреса в зависимости от направления движения датаграммы. Он всегда добавляет IP адрес исходящего интерфейса. Однако, когда ICMP эхо отклик достигает системы, которая инициировала запрос (svr4), она добавляет в список IP адрес входящего интерфейса.

Мы можем наблюдать за обменом пакетами с хоста sun, на котором запущена программа tcpdump с опцией -v (просмотр IP опций). На рисунке 7.5 показан вывод.

1 0.0 svr4>slip: icmp: echo request (ttl 32, id 35835,
optlen=40 RR{39}=RR{#0.0.0.0/0.0.0.0/0.0.0.0/
0.0.0.0/0.0.0.0/0.0.0.0/0.0.0.0/0.0.0.0/0.0.0.0} EOL)

2 0.267746 (0.2677) slip>svr4: icmp: echo reply (ttl 254, id 1976,
optlen=40 RR{39}=RR{140.252.13.66/140.252.13.65/
140.252.13.35/#0.0.0.0/0.0.0.0/0.0.0.0/0.0.0.0/ 0.0.0.0/0.0.0.0} EOL)

Работа программы ping с записью

Рисунок 7.6 Работа программы ping с записью маршрута, показывающая характеристику IP маршрутизации.

Проблема заключается в том, что aix не знает как послать IP датаграмму, направляющуюся в подсеть 140.252.13 к netb. Однако, aix имеет в своей таблице маршрутизации пункт по умолчанию, который сообщает о необходимости посылать все датаграммы на маршрутизатор gateway, если не существует конкретного маршрута к пункту назначения. Маршрутизатор gateway знает значительно больше о существующих маршрутах, чем любой другой хост в подсети 140.252.1. (В этой сети Ethernet присутствует более чем 150 хостов, и вместо того чтобы каждому иметь запущенный демон маршрутизации, они используют пункт "по умолчанию" (default), который указывает на маршрутизатор gateway.)

Вопрос, на который пока нет ответа, заключается в том, почему gateway не послал сообщение ICMP о перенаправлении (глава 9, раздел "ICMP ошибки перенаправления") на aix, чтобы обновить его таблицу маршрутизации? По некоторым причинам (возможно потому, что датаграмма, генерирующая перенаправление, является ICMP эхо запросом) перенаправление не произошло. Однако, если мы используем Telnet и подключимся к серверу дневного времени на aix, ICMP перенаправление произойдет, и таблица маршрутизации aix будет обновлена. Если мы затем запустим ping со включенной опцией записи маршрута, маршрут покажет, что датаграммы идут от netb к aix и назад к netb без дополнительной пересылки через маршрутизатор gateway. Мы рассмотрим сообщения ICMP о перенаправлении более подробно в разделе "ICMP ошибки перенаправления" главы 9.

Работа программы в глобальных сетях

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

gemini % ping vangogh.cs.berkeley.edu
PING vangogh.cs.berkeley.edu: 56 data bytes
64 bytes from (128.32.130.2): icmp_seq=0. time=660. ms
64 bytes from (128.32.130.2): icmp_seq=5. time=1780. ms
64 bytes from (128.32.130.2): icmp_seq=7. time=380. ms
64 bytes from (128.32.130.2): icmp_seq=8. time=420. ms
64 bytes from (128.32.130.2): icmp_seq=9. time=390. ms
64 bytes from (128.32.130.2): icmp_seq=14. time=110. ms
64 bytes from (128.32.130.2): icmp_seq=15. time=170. ms
64 bytes from (128.32.130.2): icmp_seq=16. time=100. ms
^? вводим символ прерывания
---- vangogh.CS.Berkeley.EDU PING Statistics ----
17 packets transmitted, 8 packets received, 52% packet loss
round-trip (ms) min/avg/max = 100/501/1780

Эхо запросы и эхо отклики с номерами последовательности 1, 2, 3, 4, 6, 10, 11, 12 и 13 были потеряны. Также обратите внимание на значительную разницу между величинами времен возврата. (Количество потерянных пакетов, а именно 52%, является ненормальным. Это неприемлимо для Internet даже в рабочие дни после полудня.)

При работе в глобальных сетях можно встретиться с дублированием пакетов (один и тот же номер последовательности появляется дважды или несколько раз), также может возникнуть перемешивание номеров последовательности (номер последовательности N+1 появляется перед номером последовательности N).

Работа программы в локальных сетях

Вывод программы ping при работе в локальных сетях обычно выглядит следующим образом:

bsdi % ping svr4
PING svr4 (140.252.13.34): 56 data bytes
64 bytes from 140.252.13.34: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=1 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=2 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=3 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=4 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=5 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=6 ttl=255 time=0 ms
64 bytes from 140.252.13.34: icmp_seq=7 ttl=255 time=0 ms
^? чтобы остановить ping, вводим символ прерывания
--- svr4 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms

Когда принимается ICMP эхо отклик, печатается номер последовательности, затем параметр время жизни (TTL) и рассчитанное время возврата. (TTL это поле времени жизни в IP заголовке. В настоящее время программа ping в BSD печатает полученное TTL каждый раз, когда принимается эхо отклик - некоторые реализации этого не делают. Мы рассмотрим использование TTL в главе 8 с программой traceroute.)

Как видно из примера, приведенного выше, эхо отклики возвращаются в том же порядке, в котором были отправлены (0, 1, 2 и так далее).

ping может рассчитать время возврата, так как он сохраняет время, когда был отправлен эхо запрос, в разделе данных ICMP сообщения. Когда отклик возвращается, эти данные извлекаются и сравниваются с текущим временем. Обратите внимание на то, что посылающая система, bsdi, во всех случаях рассчитала время возврата равное 0 мс. Это объясняется тем, что программе доступен таймер с низким разрешением. Система BSD/386 может использовать только таймер с дискретом 10 мс. (Мы обсудим это более подробно в приложении В.) Позже, с использованием вывода команды tcpdump, мы увидим, что в системах с часами с более высоким разрешением (Sun) разница во времени между ICMP эхо запросом и эхо откликом составляет примерно 4 мс.

Первая строка вывода содержит IP адрес хоста назначения, даже если было указано имя (svr4). Это означает, что имя было преобразовано в IP адрес. Мы рассмотрим процедуру преобразования и DNS в главе 14. После запуска программы ping проходит несколько секунд, перед тем как появляется первая строка вывода с напечатанным IP адресом, это время необходимо DNS, чтобы определить IP адрес, соответствующий имени хоста.

На рисунке 7.2 показан вывод tcpdump для этого примера.

1 0.0 bsdi > svr4: icmp: echo request
2 0.003733 (0.0037) svr4 > bsdi: icmp: echo reply

3 0.998045 (0.9943) bsdi > svr4: icmp: echo request
4 1.001747 (0.0037) svr4 > bsdi: icmp: echo reply

5 1.997818 (0.9961) bsdi > svr4: icmp: echo request
6 2.001542 (0.0037) svr4 > bsdi: icmp: echo reply

7 2.997610 (0.9961) bsdi > svr4: icmp: echo request
8 3.001311 (0.0037) svr4 > bsdi: icmp: echo reply

9 3.997390 (0.9961) bsdi > svr4: icmp: echo request
10 4.001115 (0.0037) svr4 > bsdi: icmp: echo reply

11 4.997201 (0.9961) bsdi > svr4: icmp: echo request
12 5.000904 (0.0037) svr4 > bsdi: icmp: echo reply

13 5.996977 (0.9961) bsdi > svr4: icmp: echo request
14 6.000708 (0.0037) svr4 > bsdi: icmp: echo reply

15 6.996764 (0.9961) bsdi > svr4: icmp: echo request
16 7.000479 (0.0037) svr4 > bsdi: icmp: echo reply

SLIP каналы с дозвоном (Dialup)

При использовании SLIP каналов с дозвоном существуют некоторые отличия, так как на каждом конце канала присутствуют модемы. Модемы, которые используются между системами netb и sun, предоставляют то, что называется модуляцией V.32 (9600 бит/сек), контроль ошибок V.42 (также иногда называемый LAP-M) и сжатие данных V.42bis. Это означает, что наши простые вычисления, которые были достаточно точны для выделенного канала, где известны все параметры, в таких условиях практически неверны.

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

В следующем примере мы послали ping на хост gemini с хоста sun.

sun % ping gemini
PING gemini: 56 data bytes
64 bytes from gemini (140.252.1.11): icmp_seq=0. time=373. ms
64 bytes from gemini (140.252.1.11): icmp_seq=1. time=360. ms
64 bytes from gemini (140.252.1.11): icmp_seq=2. time=340. ms
64 bytes from gemini (140.252.1.11): icmp_seq=3. time=320. ms
64 bytes from gemini (140.252.1.11): icmp_seq=4. time=330. ms
64 bytes from gemini (140.252.1.11): icmp_seq=5. time=310. ms
64 bytes from gemini (140.252.1.11): icmp_seq=6. time=290. ms
64 bytes from gemini (140.252.1.11): icmp_seq=7. time=300. ms
64 bytes from gemini (140.252.1.11): icmp_seq=8. time=280. ms
64 bytes from gemini (140.252.1.11): icmp_seq=9. time=290. ms
64 bytes from gemini (140.252.1.11): icmp_seq=10. time=300. ms
64 bytes from gemini (140.252.1.11): icmp_seq=11. time=280. ms
----gemini PING Statistics----
12 packets transmitted, 12 packets received, 0% packet loss
round-trip (ms) min/avg/max = 280/314/373

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

Также обратите внимание на то, что первый RTT больше чем следующие, а остальные уменьшаются в процессе работы команды и их диапазон находится между 280 и 300 мс. Если не останавливать программу примерно минуту или две, RTT останутся в этом диапазоне, никогда не уменьшаясь меньше чем 260 мс. Если рассчитать ожидаемый RTT для скорости 9600 бит/сек (упражнение 2 главы 7), величина составит 180 миллисекунд, таким образом мы ошиблись в расчете примерно в 1,5 раза от реального значения.

Если программа ping будет работать в течение 60 секунд, то среднее RTT при использовании V.42 и V.42bis составит 277 миллисекунд. (Это лучше, чем значение, полученное в предыдущем примере, так как программа работала долше, при этом значение RTT застабилизировались в определенном диапазоне.) Если выключить сжатие данных V.42bis, то среднее значение составит 330 миллисекунд. Если выключить контроль ошибок V.42 (который также выключается при выключении сжатия данных V.42bis), среднее значение составит 300 миллисекунд. Эти параметры модемов влияют на RTT, однако все же лучше использовать контроль ошибкок и сжатие данных.

Введение

Введение

Программа Ping предназначена для проверки доступности удаленного хоста. Программа посылает ICMP эхо запрос на хост и ожидает возврата ICMP эхо отклика. (На рисунке 6.3 приведен список типов ICMP сообщений.)
Обычно, если Вы не можете послать Ping на хост, то не сможете получить доступ к этому хосту, используя Telnet или FTP. С другой стороны, если Вы не можете зайти на хост с помощью Telnet, Ping, как правило, начальная точка, с которой начинается идентификация проблемы. Помимо этого, с помощью Ping можно оценить время возврата пакета от хоста, что дает представление о том, "насколько далеко" находится хост.
В этой главе мы воспользуемся программой Ping в качестве диагностического средства, а также для дальнейшего рассмотрения ICMP. Кроме упомянутого выше, Ping имеет опции записи маршрута и временной марки. Раздел 11 [Stevens 1990] содержит исходные тексты программы Ping.
Раньше можно было считать верным утверждение, что если мы не можем послать Ping на хост, то не сможем работать с хостом и с использованием Telnet или FTP. В настоящее время это утверждение не является верным. Связано это с тем, что в сети Internet появились повышенные требования к секретности. Маршрутизаторы поддерживают списки доступа, появились шлюзы, использующие технологию firewall. В настоящее время доступность хоста основывается не только на доступности IP уровня, а также от того, какой используется протокол и какой при этом работает порт. Ping может показывать хост как недоступный, однако мы можем получить доступ через Telnet на порт 25 (почтовый сервер).

Выделенные SLIP каналы

Давайте рассмотрим время возврата при работе по SLIP каналам, так как они обычно работают в асинхронном режиме с низкими скоростями, например 9600 бит/сек или меньше. Обратимся к расчету пропускной способности последовательной линии, приведенному в разделе "Вычисление загруженности последовательной линии" главы 2. Предположим, скорость SLIP канала между хостами bsdi и slip составляет 1200 бит/сек.

Оценить время возврата можно следующим образом. Во-первых, обратимся к примеру вывода Ping, показанному ранее. По умолчанию, ICMP сообщение содержит 56 байт данных. А также, 20 байт IP заголовка и 8 байт ICMP заголовка, что в сумме дает размер IP датаграммы - 84 байта. (Мы можем проверить это, запустив tcpdump -e, с помощью этой опции можно посмотреть размеры Ethernet фреймов.) Из раздела "SLIP: IP по последовательной линии" главы 2 мы знаем, что в начало и в конец датаграммы добавляется по меньшей мере два дополнительных байта, а именно - байт END. Не исключено, что при создании фреймов SLIP будут добавлены дополнительные байты, однако это зависит от величины каждого байта в датаграмме. Предположим, что скорость составляет 1200 бит/сек, в байте 8 бит, один старт-бит и один стоп-бит, при этом скорость будет 120 байт/сек или 8,33 мс на один байт. Время возврата составит (86 x 8,33 x 2) или 1433 мс. (Здесь умножается на 2 потому, что мы рассчитываем время возврата - то есть время, за которое пакет ушел и вернулся.)

Следующий вывод должен подтвердить правильность наших вычислений:

svr4 % ping -s slip
PING slip: 56 data bytes
64 bytes from (192.42.62.1): icmp_seq=0. time=1480. ms
64 bytes from (192.42.62.1): icmp_seq=1. time=1480. ms
64 bytes from (192.42.62.1): icmp_seq=2. time=1480. ms
64 bytes from (192.42.62.1): icmp_seq=3. time=1480. ms
^?
---- slip PING Statistics ----
5 packets transmitted, 4 packets received, 20% packet loss
round-trip (ms) min/avg/max = 1480/1480/1480

(Опция -s необходима для SVR4, чтобы посылать один запрос каждую секунду.) Время возврата составляет почти 1,5 секунды, однако программа все еще посылает ICMP эхо запросы с интервалом в 1 секунду. Это означает, что будет выдано два эхо запроса (в момент времени 0 и в момент времени 1), перед тем как вернется первый отклик (момент времени 1,480). Именно поэтому программа считает, что один пакет потерян. В действительности он не был потерян, скорее всего он еще просто не вернулся.

Мы снова обратимся к медленному SLIP каналу в главе 8, когда будем рассматривать работу программы traceroute.

Вывод ping при работе в локальной сети.

Рисунок 7.2 Вывод ping при работе в локальной сети.

Время между отправкой эхо запроса и приемом эхо отклика составляет 3,7 мс. Также мы видим, что эхо запросы посылаются с интервалом примерно в 1 секунду.

Часто бывает, что первое время возврата больше чем все остальные. Это происходит в том случае, если аппаратный адрес назначения отсутствует в ARP кэше отправителя. Как мы помним из главы 4, отправка ARP запроса и получение ARP отклика может занять несколько миллисекунд, только после этого отправляется первый эхо запрос. Это проиллюстрировано в следующем примере:

sun % arp -a убедимся, что ARP кэш пуст

sun % ping svr4
PING svr4: 56 data bytes
64 bytes from svr4 (140.252.13.34): icmp_seq=0. time=7. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=1. time=4. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=2. time=4. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=3. time=4. ms
^? вводим символ прерывания
---- svr4 PING Statistics ----
4 packet transmitted, 4 packets received, 0% packets loss
round-trip (ms) min/avg/max = 4/4/7

Дополнительные 3 миллисекунды в первом RTT скорее всего потрачены на отправку ARP запроса и получение отклика.

Этот пример был запущен на хосте sun, который имеет таймер с разрешением в одну микросекунду, но не смотря на это, программа ping печатает время возврата только с разрешением в одну миллисекунду. В предыдущем примере, запущенном под BSD/386 Version 0.9.4, время возврата равно 0 миллисекунд, так как таймер имеет разрешение в 10 миллисекунд. Следующий вывод получен с использованием BSD/386 Version 1.0, где есть таймер с разрешением в одну микросекунду. Существует версия программы ping, которая имеет более высокое временное разрешение.

bsdi % ping svr4
PING svr4 (140.252.13.34): 56 data bytes
64 bytes from 140.252.13.34: icmp_seq=0 ttl=255 time=9.304 ms
64 bytes from 140.252.13.34: icmp_seq=1 ttl=255 time=6.089 ms
64 bytes from 140.252.13.34: icmp_seq=2 ttl=255 time=6.079 ms
64 bytes from 140.252.13.34: icmp_seq=3 ttl=255 time=6.096 ms
^? вводим символ прерывания
--- svr4 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 6.079/6.880/9.304 ms

Вывод программы tcpdump c записью опций маршрутизации.

Рисунок 7.5 Вывод программы tcpdump c записью опций маршрутизации.

Вывод optlen=40 указывает на то, что пространство опций в IP заголовке, используемое в данном случае, равно 40 байтам. (Обратите внимание, длина IP заголовка должна быть кратна 4 байтам.) RR {39} означает, что включена опция записи маршрута, а длина ее поля составляет 39. Затем приводится список из 9 IP адресов, знак (#) показывает на который из IP адресов указывает поле ptr в заголовке опции RR. Так как мы наблюдали за пакетами с хоста sun (см. рисунок 7.4), то видели только ICMP эхо запросы с пустым списком и ICMP эхо отклики, в списке которых содержится 3 адреса. Мы удалили оставшиеся строки в выводе tcpdump, так как они практически идентичны тем, которые показаны на рисунке 7.5.

Комбинация EOL в конце записи маршрута указывает на IP опцию "конец списка" (end of list). Опция EOL имеет значение 0. В поле опций IP заголовка, состоящего из 40 байт присутствует 39 байт данных RR. Так как пространство опций устанавливается в 0, перед тем как датаграмма отсылается, последний байт 0 следующий за 39-ю байтами данных RR интерпретируется как EOL. Если в поле опций IP заголовка присутствует несколько опций и появляется необходимость использовать байты заполнения перед началом следующей опции, используется специальный символ "нет операции" (NOP - no operation), значение которого равно единице.

На рисунке 7.5 SVR4 устанавливает в поле TTL в эхо запросе значение 32, а BSD/386 устанавливает значение 255. (Это значение печатается как 254, потому что маршрутизатор bsdi уже успел уменьшить это значение на единицу.) Все новые системы устанавливают TTL ICMP сообщений по максимуму (255).

Необходимо отметить, что две системы, BSD/386 и SVR4, из трех TCP/IP реализаций, описываемых в качестве примера в этой книге, поддерживают опцию записи маршрута. Таким образом, они корректно обновляют RR список при перенаправлении датаграммы. Также они корректно отражают RR список из входящих ICMP эхо запросов в исходящий ICMP эхо отклик. SunOS 4.1.3, однако, обновляет RR список, когда перенаправляет датаграмму, но не отображает RR список. Solaris 2.x исправляет эту проблему.

Значение флагов в опции временной марки.

Рисунок 7.8 Значение флагов в опции временной марки.

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

Обычное значение для временной марки это количество миллисекунд после полуночи, UTC, что напоминает запрос и отклик временной марки ICMP (глава 6, раздел "ICMP запрос и отклик временной марки"). Если маршрутизатор не поддерживает подобный стандарт, он может вставить то представление времени, которое он использует, однако затем он должен установить в единицу старшие биты временной марки, чтобы указать на нестандартный формат.

Заданные ограничения, которые мы рассматривали с опцией записи маршрута, с опцией временной марки становятся еще более жесткими. Если осуществляется запись и IP адресов и временных марок (флаги установлены в единицу), то можно сохранить только 4 подобные пары. Сохранение только временной марки практически бесполезно, потому что мы не имеем представления, какому маршрутизатору соответствует определенная временная марка (если только мы не имеет фиксированную топологию, которая никогда не изменяется). Если установить флаги в значение 3, то появится возможность выбрать, каким маршрутизаторам необходимо вставлять их временные марки. Более глобальная проблема заключается в том, что мы не можем контролировать то, насколько точно маршрутизаторы устанавливают временные марки. Поэтому довольно сложно оценить время пересылки между маршрутизаторами с использованием этой IP опции. Вскоре мы увидим, что программа traceroute (см. главу 8) предоставляет более совершенный способ оценки времени пересылки между маршрутизаторами.

Функционирование программы Traceroute

В разделе "Опция записи IP маршрута" главы 7 мы описали IP опцию записи маршрута (RR). Возникает вопрос, зачем писать новое приложение, когда данная опция уже реализована? Существует три причины. Во-первых, исторически не все маршрутизаторы поддерживают опцию записи маршрута, из чего следует, что некоторые маршруты становятся неиспользуемыми. (Traceroute не требует каких-либо специальных характеристик на промежуточных маршрутизаторах.)

Во-вторых, запись маршрута обычно осуществляется в одном направлении. Отправитель включает опцию, а получатель должен вставить все значения из принятого IP заголовка и каким-либо образом вернуть их отправителю. В разделе "Опция записи IP маршрута" главы 7 мы видели, что большинство реализаций сервера Ping (функция ICMP эхо отклика, встроенная в ядро) отображают входящий RR список, однако при этом удваивается количество записанных IP адресов (путь туда и обратно), помимо этого существует еще несколько ограничений, которые будут рассмотрены в следующем параграфе. (Traceroute требует только того, чтобы на пункте назначения присутствовал работающий UDP модуль - никаких специальных серверных приложений не требуется.)

Третья и основная причина заключается в том, что размер, предоставляемый для опций в IP заголовке, недостаточен для того, чтобы обработать большинство маршрутов. В поле опций IP заголовка входит всего 9 IP адресов. Если во времена ARPANET этого хватало, на сегодняшний день этого слишком мало.

Traceroute использует ICMP и поле TTL в IP заголовке. Поле TTL (время жизни) это 8-битное поле, которое отправитель устанавливает в какое-либо значение. Рекомендуемое исходное значение указано в Assigned Numbers RFC и в настоящее время равно 64. Более старые системы устанавливают это значение в 15 или 32. Мы видели в некоторых примерах работы программы Ping (глава 7), что ICMP эхо отклики часто отправляются с TTL, установленным в максимальное значение - 255.

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

RFC 1009 [Braden and Postel 1987] требует, чтобы маршрутизатор, задерживающий датаграмму на время большее чем 1 секунда, уменьшал TTL на количество секунд. Совсем немногие маршрутизаторы удовлетворяют этому требованию. Современные требования к маршрутизаторам, Router Requirements RFC [Almquist 1993], делают это требование необязательным, позволяя маршрутизаторам использовать поле TTL в качестве счетчика пересылок.

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

Когда маршрутизатор получает IP датаграмму с TTL равным либо 0, либо 1, он не должен отправлять эту датаграмму дальше. (Хост приемник должен доставить подобную датаграмму в приложение, так как датаграмма не может быть смаршрутизировна. Как правило, системы не должны получать датаграммы с TTL равным 0.) Если такую датаграмму получает маршрутизатор, он уничтожает ее и посылает хосту, который ее отправил ICMP сообщение "время истекло" (time exceeded). Принцип работы Traceroute заключается в том, что IP датаграмма, содержащая это ICMP сообщение, имеет в качестве адреса источника IP адрес маршрутизатора.

Теперь мы можем понять, как работает Traceroute. На хост назначения отправляется IP датаграмма с TTL, установленным в единицу. Первый маршрутизатор, который должен обработать датаграмму, уничтожает ее (так как TTL равно 1) и отправляет ICMP сообщение об истечении времени (time exceeded). Таким образом, определяется первый маршрутизатор в маршруте. Затем Traceroute отправляет датаграмму с TTL равным 2, что позволяет получить IP адрес второго маршрутизатора. Это продолжается до тех пор, пока датаграмма не достигнет хоста назначения. Однако, если датаграмма прибыла именно на хост назначения, он не уничтожит ее и не сгенерирует ICMP сообщение об истечении времени, так как датаграмма достигла своего конечного назначения. Как можно определить, что датаграмма достигла конечного пункта назначения?

В UDP датаграммах, которые посылает Traceroute, устанавливается несуществующий номер UDP порта (больше чем 30000), что делает невозможным обработку этой датаграммы каким-либо приложением. Поэтому когда прибывает подобная датаграмма, UDP модуль хоста назначения генерирует ICMP сообщение "порт недоступен" (port unreachable) (см. раздел "ICMP ошибка недоступности порта" главы 6). Все что необходимо в этом случае, Traceroute это определить тип принятого ICMP сообщения - либо об истечении времени, либо о недоступности порта - именно таким образом мы узнаем, доставлена ли датаграмма в пункт назначения.

Программа Traceroute должна уметь устанавливать поле TTL в исходящих датаграммах. Не все интерфейсы TCP/IP поддерживают это, и не все реализации предоставляют эту возможность, однако большинство современных систем предоставляют. А это означает, что Traceroute может быть запущена. Однако обычно требуется, чтобы эту программу запускал суперпользователь.

ICMP сообщение об истечении времени

Рисунок 8.2 ICMP сообщение об истечении времени ("time exceeded").

В сообщении, которое генерируется, когда TTL достигает нуля, поле code равно нулю.

Существует возможность, что хост пошлет ICMP сообщение "время истекло в течении повторной сборки" (time exceeded during reassembly) в том случае, если время истекло в течении повторной сборки фрагментированной датаграммы. (Мы подробно рассмотрим фрагментацию и повторную сборку в разделе "Фрагментация IP" главы 11.) В этом случае поле code устанавливается в единицу.

Строки с 9-ой по 14-ую на рисунке 8.1 соответствуют трем датаграммам, которые посылаются с TTL равным 2. Они достигают конечного пункта назначения, при этом генерируется ICMP сообщение о недоступности порта.

Попробуем рассчитать время возврата, которое соответствует SLIP каналу, как это было сделано в разделе "Программа Ping" главы 7, когда при работе программы Ping была установлена скорость канала - 1200 бит/сек. Исходящая UDP датаграмма содержит 12 байт данных, 8 байт UDP заголовка, 20 байт IP заголовка и 2 байта (минимум) для создания SLIP фреймов (см. раздел "SLIP: IP по последовательной линии" главы 2), что в целом составляет 42 байта. В отличие от Ping, размер возвращающихся датаграмм изменяется. На рисунке 6.9, мы видели, что возвращаемое ICMP сообщение содержит IP заголовок датаграммы, которая вызвала ошибку и первые 8 байт данных, которые следуют за IP заголовком (содержащие UDP заголовок, в данном случае traceroute). При этом мы получаем 20+8+20+8+2 или 58 байт. При скорости передачи в 960 байт/сек, ожидаемое RTT составляет (42+58/960) или 104 миллисекунды. Это сопоставимо со значением, рассчитанным для svr4 и равным 110 миллисекундам.

Номер порта источника на рисунке 8.1 достаточно большой (42804). traceroute устанавливает номер порта источника IP датаграмм, которые она посылает в логическое ИЛИ (logical OR), со своим идентификатором процесса (32768). В этом случае, если traceroute запущена несколько раз на одном и том же хосте, каждый процесс просматривает номер порта источника в UDP заголовке, который возвращается в ICMP сообщении, и обрабатывает только те сообщения, которые были отправлены в качестве отклика на его запрос.

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

Во-вторых, не существует гарантии того, что путь, по которому вернется ICMP сообщение, совпадет с путем, по которому traceroute отправила UDP датаграмму. Это означает, что время возврата, которое печатает программа, может не совпадать со временем, потребовавшимся на передачу исходящей датаграммы и возвращенного сообщения. (Возможен вариант, что UDP датаграмма дойдет от источника до маршрутизатора за 1 секунду, однако ICMP сообщение проделает обратный путь за 3 секунды, при этом время возврата будет напечатано как 4 секунды.)

В-третьих, IP адрес, который возвращается в сообщение ICMP, это IP адрес интерфейса, на который маршрутизатор принял UDP датаграмму. Тогда как при использовании опции записи маршрута (см. раздел "Опция записи IP маршрута" главы 7) записывается IP адрес исходящего интерфейса. Так как каждый маршрутизатор по умолчанию имеет 2 или более интерфейсов, запуск traceroute от хоста А к хосту В может отличаться от того, который запущен с хоста В на хост А. Действительно, если мы запустим traceroute от хоста slip к svr4, вывод будет следующим:

slip % traceroute svr4
traceroute to svr4 (140.252.13.34), 30 hops max, 40 byte packets
1 bsdi (140.252.13.66) 110 ms 110 ms 110 ms
2 slip (140.252.13.34) 110 ms 120 ms 110 ms

В этом случае IP адрес, напечатанный для хоста bsdi, это адрес SLIP интерфейса (140.252.13.66), тогда как до этого адрес был 140.252.13.35, что соответствовало интерфейсу Ethernet. Так как traceroute пытается определить имя, связанное с IP адресом, имена будут различны. (В нашем примере оба интерфейса bsdi имеют одно и то же имя.)

Обратимся к рисунку 8.3. На нем показаны две локальные сети, соединенные через маршрутизаторы. Два маршрутизатора соединены по каналу точка-точка. Если мы запустим traceroute с хоста в левой локальной сети на хост в правой локальной сети, IP адреса для маршрутизатора будут if1 и if3. При использовании другого пути, будут получены адреса if4 и if2. Два интерфейса if2 и if3 имеют один и тот же идентификатор сети, тогда как два других интерфейса имеют разные идентификаторы сетей.

Идентификация интерфейсов программой traceroute.

Рисунок 8.3 Идентификация интерфейсов программой traceroute.

И в заключение отметим, что при работе с глобальными сетями вывод traceroute значительно легче читать, если вместо IP адресов печатаются читаемые имена доменов. Однако, так как в ICMP сообщении, принимаемом при работе traceroute, содержится IP адрес, он и будет выдан, если преобразовать IP адрес в имя домена не удалось. В этом случае администратор должен позаботиться о том, чтобы принятый IP адрес мог быть корректно трансформирован в имя домена. Мы опишем, как IP адреса конвертируются в имена с использованием DNS, в разделе "Запросы указателя" главы 14.

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

Traceroute это незаменимое средство при работе с сетями TCP/IP. Оно функционирует довольно просто: отправляет UDP датаграммы, начинающиеся с TTL 1, увеличивает TTL на единицу, для того чтобы определить пересылку через каждый встретившийся маршрутизатор. Каждый маршрутизатор, который отбрасывает UDP датаграмму, возвращает сообщение ICMP об истечении времени (ICMP time exceeded), а пункт конечного назначения генерирует ICMP сообщение о недоступности порта (ICMP port unreachable).

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

Упражнения

Что произойдет, если IP модуль уменьшит входящий TTL на единицу, а затем проверит на равенство нулю? Как traceroute рассчитывает RTT? Сравните это с расчетом RTT, который осуществляет ping. (Это и следующее упражнения основано на реальных проблемах, которые возникли при разработке traceroute и взяты из комментариев к исходным текстам traceroute.) Представьте, что между источником и пунктом назначения находится 3 маршрутизатора (R1, R2 и R3), средний маршрутизатор (R2) уменьшил на единицу TTL, однако некорректно перенаправил IP датаграмму, когда входящий TTL был равен единице. Опишите, что произойдет. Что Вы увидите, если запустите traceroute? Представьте еще раз, что между источником и конечным пунктом назначения находится 3 маршрутизатора. При этом хост, который является пунктом назначения, работает с ошибкой. Он использует входящий TTL в качестве исходящего TTL для ICMP сообщения. Опишите, что произойдет, и как Вы это можете увидеть. Мы могли бы запустить tcpdump на SLIP канале между sun и netb, когда запускали пример с рисунка 8.8. Если мы укажем опцию -v, то можем увидеть значение TTL для возвращающихся ICMP сообщений. При этом, мы увидим, что входящий TTL от netb равен 255, от butch равен 253, от Gabby равен 252 и от enss142.UT.westnet.net равен 249. Дает ли это какую-либо дополнительную информацию о том, где существуют отсутствующие маршрутизаторы? SunOS и SVR4 предоставляют версию программы ping с опцией -l, что позволяет использовать свободную маршрутизацию от источника. В страницах помощи говорится, что это идентично использованию опции -R (которая указывает на то, что необходима запись маршрута). Если Вы имеете доступ к обеим этим системам, попробуйте использовать эти две опции вместе. Что произойдет? Если Вы можете просмотреть датаграммы с использованием tcpdump, опишите что будет происходить. Сравните пути прохождения ping и traceroute с разных рабочих станций на один и тот же хост. Сравните время возврата для ping и traceroute. Мы указали traceroute о необходимости использовать исходный номер порта назначения UDP, равный 33435, и увеличивать его на единицу для каждого следующего отправляемого пакета. В разделе "Номера портов" главы 1 говорится, что обычно номера динамически назначаемых портов находятся в диапазоне от 1024 до 5000, при этом порт назначения Traceroute никогда не будет занят на хосте, который является пунктом назначения. Является ли это справедливым для Solaris 2.2? (Подсказка: прочитайте раздел "Solaris 2.2" приложения E.) Прочитайте RFC 1393 [Malkin 1993b], и найдите альтернативные способы определения маршрута к пункту назначения. В чем их преимущества и недостатки?

На главную

Общий формат опции маршрутизации

Рисунок 8.6 Общий формат опции маршрутизации от источника в IP заголовке.

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

Поле code устанавливается в 0x83 для свободной маршрутизации от источника, и в 0x89 для жесткой маршрутизации от источника. Поля len и ptr идентичны тем, что мы описали в разделе "Опция записи IP маршрута" главы 7.

Опции маршрутизации от источника обычно называются "маршрутизацией от источника с записью" (source and record route) (LSRR - свободная и SSRR - жесткая), так как список IP адресов обновляется в процессе того, как датаграмма проходит по маршруту. Происходит следующее: Отправляющий хост берет из приложения маршрут от источника, удаляет первый пункт (он становится адресом назначения для датаграммы), перемещает все оставшиеся пункты влево на один пункт (где лево - показано на рисунке 8.6) и помещает исходный адрес назначения на место последнего пункта в списке. Указатель все еще указывает на первый пункт списка (значение указателя равно 4). Каждый маршрутизатор, который обрабатывает датаграмму, проверяет, является ли этот адрес адресом назначения. Если нет, датаграмма обрабатывается как обычная. В этом случае должна быть использована свободная маршрутизация от источника, иначе мы не получим датаграмму. Если маршрутизатор является пунктом назначения и указатель не больше чем длина, в этом случае (1) следующий адрес в списке (куда указывает ptr) становится адресом назначения датаграммы, (2) IP адрес, соответствующий исходящему интерфейсу, замещает собой только что использованный адрес источника, и (3) указатель увеличивается на 4.

Все это лучше показать на примере. На рисунке 8.7 мы предположили, что посылающее приложение на хосте S отправляет датаграмму к D, указав маршрут от источника как R1, R2 и R3.

Опция IP маршрутизации от источника

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

Идея, заложенная в маршрутизации от источника, заключается в том, что отправитель сам указывает маршрут по которому пройдет датаграмма. Существует две формы: Жесткая (strict) маршрутизация от источника. Отправитель указывает точный путь, по которому должна пройти IP датаграмма. Если маршрутизатор обнаруживает, что следующая пересылка, указанная в маршрутизации от источника, не является непосредственно подключенной сетью, возвращается ICMP ошибка "маршрутизация от источника невозможна" (source route failed). Свободная (loose) маршрутизация от источника. Отправитель указывает список IP адресов, через который должна пройти IP датаграмма, однако датаграмма может также пройти через другие маршрутизаторы между любыми двумя адресами, указанными в списке.

Traceroute позволяет использовать маршрутизацию от источника.

Некоторые свободно распространяемые исходные тексты программы Traceroute содержат дополнения, которые позволяют установить свободную маршрутизацию от источника. Однако стандартные версии обычно не включают эту опцию. Комментарии к дополнениям гласят: "исходные тексты программы Traceroute, написанные Van Jacobson (весна 1988 года), поддерживали эту характеристику, однако она была удалена по требованию людей, которые вывели из строя свои шлюзы". Для того чтобы показать пример, приведенный в этом разделе, автор установил эти дополнения и модифицировал их таким образом, чтобы можно было использовать оба типа маршрутизации от источника.

На рисунке 8.6 показан формат опции маршрутизации от источника.

Пример IP маршрутизации от источника.

Рисунок 8.7 Пример IP маршрутизации от источника.

На этом рисунке символ (#) означает поле указателя, которое может принимать значение 4, 8, 12 и 16. Поле длины всегда будет 15 (3 IP адреса + 3 байта). Обратите внимание на то, как меняется IP адрес назначения в IP датаграмме при каждой пересылке.

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

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

Пример traceroute, показывающий несимметричные маршруты.

Рисунок 8.11 Пример traceroute, показывающий несимметричные маршруты.

Исходящий маршрут (TTL 1-11) отличается от обратного маршрута (TTL 11-21), это является хорошей иллюстрацией того, что маршрутизация в Internet может быть несимметричной.

Этот вывод также иллюстрирует проблему, которую мы обнаружили при рассмотрении рисунка 8.3. Сравните вывод для TTL 2 и 19: оба относятся к маршрутизатору gateway.tuc.noao.edu, однако IP адреса различны. Так как traceroute идентифицирует входящий интерфейс, это означает, что мы прошли через маршрутизатор с разных сторон, в тот момент, когда использовали исходящий маршрут (TTL 2) и когда использовали обратный маршрут (TTL 19). Точно так же можно сравнить TTL 3 и 18, TTL 4 и 17.

Примеры traceroute при использовании

Примеры traceroute при использовании жесткой маршрутизации от источника

Опция -G в нашей версии traceroute идентична опции -g, описанной ранее, однако она определяет жесткую маршрутизацию от источника вместо свободной. Посмотрим что произойдет, если указан неверный жесткий маршрут от источника. Обратимся к рисунку 8.5, на котором показана нормальная последовательность маршрутизаторов для датаграмм, двигающихся из нашей подсети к NSFNET через netb, gateway, butch и gabby. (Мы отбросили суффиксы доменов, .tuc.noao.edu и .telcom.arizona.edu, во всех строках вывода, показанных ниже, чтобы сделать их более читаемыми.) Мы указали жесткий маршрут от источника, который не использует butch, а пытается пройти непосредственно от gateway к gabby. Это не должно сработать, что показано на рисунке 8.9.

sun % traceroute -G netb -G gateway -G gabby westgate
traceroute to westgate (192.80.43.2), 30 hops max, 40 byte packets
1 netb (140.252.1.183) 272 ms 257 ms 261 ms
2 gateway (140.252.1.4) 263 ms 259 ms 234 ms
3 gateway (140.252.1.4) 263 ms !S * 235 ms !S

Примеры traceroute с использованием

Примеры traceroute с использованием свободной маршрутизации от источника

Опция -g программы traceroute позволяет нам указать промежуточные маршрутизаторы, которые должны быть использованы при свободной маршрутизации от источника. Эта опция может быть указана до 8 раз. (Причина того, что указывается именно 8, а не 9 раз, заключается в том, что программный интерфейс, который будет использоваться, потребует, чтобы последний пункт являлся конечным пунктом назначения.)

Повторно обратимся к рисунку 8.4, из которого видно, что маршрутизация к NIC, nic.ddn.mil, была осуществлена через сеть NASA. На рисунке 8.8 мы заставим датаграммы пройти через NSFNET, вместо того чтобы использовать маршрутизатор enss142.UT.westnet.net (192.31.39.21) в качестве промежуточного маршрутизатора:

sun % traceroute -g 192.31.39.21 nic.ddn.mil
traceroute to nic.ddn.mil (192.112.36.5), 30 hops max, 40 byte packets
1 netb.tuc.noao.edu (140.252.1.183) 256 ms 256 ms 235 ms

2 butch.telcom.arizona.edu (140.252.104.2) 234 ms 228 ms 234 ms
3 Gabby.Telcom.Arizona.EDU (128.196.128.1) 234 ms 257 ms 233 ms

4 enss142.UT.westnet.net (192.31.39.21) 294 ms 288 ms 295 ms

5 t3-2.Denver-cnss97.t3.ans.net (140.222.97.3) 294 ms 286 ms 293 ms
6 t3-3.Denver-cnss96.t3.ans.net (140.222.96.4) 293 ms 288 ms 294 ms
7 t3-1.St-Louis-cnss80.t3.ans.net (140.222.80.2) 294 ms 318 ms 294 ms
8 * t3-1.Chicago-cnss24.t3.ans.net (140.222.24.2) 318 ms 295 ms
9 t3-2.Cleveland-cnss40.t3.ans.net (140.222.40.3) 319 ms 318 ms 324 ms
10 t3-1.New-York-cnss32.t3.ans.net (140.222.32.2) 324 ms 318 ms 324 ms
11 t3-1.Washington-DC-cnss56.t3.ans.net (140.222.56.2) 353 ms 348 ms 325 ms
12 t3-0.Washington-DC-cnss58.t3.ans.net (140.222.58.1) 348 ms 347 ms 325 ms
13 t3-0.enss145.t3.ans.net (140.222.145.1) 353 ms 348 ms 325 ms

14 nsn-FIX-pe.sura.net (192.80.214.253) 353 ms 348 ms 325 ms
15 GSI.NSN.NASA.GOV (128.161.252.2) 353 ms 348 ms 354 ms
16 NIC.DDN.MIL (192.112.36.5) 354 ms 347 ms 354 ms

Работа в локальной сети

А сейчас запустим traceroute. Мы будем использовать сети, показанные на рисунке, приведенном на внутренней стороне обложки, и пройдем по маршруту от svr4 к slip через маршрутизатор bsdi. Выделенный SLIP канал между bsdi и slip имеет скорость 9000 бит/сек.

svr4 % traceroute slip
traceroute to slip (140.252.13.65), 30 hops max, 40 byte packets
1 bsdi (140.252.13.35) 20 ms 10 ms 10 ms
2 slip (140.252.13.65) 120 ms 120 ms 120 ms

Первая строка, без номера содержит имя и IP адрес пункта назначения и указывает на то, что величина TTL не может быть больше 30. Размер датаграммы установлен в 40 байт, из которых 20 байт отводится на IP заголовок, 8 байт на UDP заголовок и 12 байт на пользовательские данные. (В 12 байтах пользовательских данных содержится номер последовательности, который увеличивается на единицу при отправке каждой следующей датаграммы, копия исходящего TTL и время, когда датаграмма была отправлена.)

Следующие две строки вывода начинаются с TTL, после чего следует имя хоста или маршрутизатора и их IP адреса. Для каждого значения TTL отправляется 3 датаграммы. Для каждого возвращенного ICMP сообщения рассчитывается и печатается время возврата (round-trip). Если ответ не получен в течении пяти секунд на любую из трех датаграмм, печатается звездочка, после чего отправляется следующая датаграмма. В нашем примере первые три датаграммы имели TTL, установленный в единицу, а ICMP сообщения вернулись через 20, 10 и 10 миллисекунд. Следующие три датаграммы были отправлены с TTL равным 2, а ICMP сообщения вернулись с задержкой 120 миллисекунд. Так как TTL со значением 2 достигло конечного пункта назначения, программа прекратила свою работу.

Времена возврата (round-trip) рассчитывается программой traceroute на хосте отправителе. Они представляют из себя полные времена возврата от программы traceroute к маршрутизатору. Если необходимо расчитать время, затраченное на каждую пересылку, мы должны вычесть значение, полученное как TTL N, из значения, полученного как TTL N+1.

На рисунке 8.1 показан вывод tcpdump для данного исполнения программы traceroute. То что первый пробный пакет к bsdi имел RTT равное 20 миллисекундам, а следующие два имели RTT равное 10 миллисекундам объясняется тем, что был осуществлен ARP обмен.

Значение, которое выбирается как номер UDP порта назначения, начинается с величины 33435 и увеличивается на единицу каждый раз, когда отправляется следующая датаграмма. Номер порта может быть изменен с использованием опции командной строки. UDP датаграмма содержит 12 байт пользовательских данных, как упоминалось ранее, в том случае, если в выводе traceroute мы видим, что отправляются датаграммы размером в 40 байт.

Когда IP датаграмма имеет TTL равное единице, tcpdump печатает комментарий [ttl 1]. Подобное сообщение печатается, когда TTL равно 0 или 1, чтобы предупредить нас о том, что в датаграмме что-то не в порядке. В данном случае мы ожидаем увидеть TTL равное 1, однако некоторые другие приложения получат предупреждение о том, что датаграмма скорее всего не достигла своего конечного пункта назначения. Скорее всего мы никогда не увидим датаграммы с TTL равным 0, если только маршрутизатор, который отправил ее в кабель, не вышел из строя.

1 0.0 arp who-has bsdi tell svr4
2 0.000586 (0.0006) arp reply bsdi is-at 0:0:c0:6f:2d:40

3 0.003067 (0.0025) svr4.42804>slip.33435: udp 12 [ttl 1]
4 0.004325 (0.0013) bsdi>svr4: icmp: time exceeded in-transit

5 0.069810 (0.0655) svr4.42804>slip.33436: udp 12 [ttl 1]
6 0.071149 (0.0013) bsdi>svr4: icmp: time exceeded in-transit

7 0.085162 (0.0140) svr4.42804>slip.33437: udp 12 [ttl 1]
8 0.086375 (0.0012) bsdi>svr4: icmp: time exceeded in-transit

9 0.118608 (0.0322) svr4.42804>slip.33438: udp 12
10 0.226464 (0.1079) slip>svr4: icmp: slip udp port 33438 unreachable

11 0.287296 (0.0608) svr4.42804>slip.33439: udp 12
12 0.395230 (0.1079) slip>svr4: icmp: slip udp port 33439 unreachable

13 0.409504 (0.0143) svr4.42804>slip.33440: udp 12
14 0.517430 (0.1079) slip>svr4: icmp: slip udp port 33440 unreachable

Traceroute на nic.ddn.mil со свободной

Рисунок 8.8 traceroute на nic.ddn.mil со свободной маршрутизацией от источника через NSFNET.

Создается впечатление, что было сделано 16 пересылок со средним RTT около 350 миллисекунд, тогда как обычный маршрут, показанный на рисунке 8.4, состоял только из 13 пересылок, и среднее RTT равнялось примерно 322 миллисекундам. Из этого можно сделать вывод, что маршрут по умолчанию предпочтительнее. (Существуют и другие ограничения, в соответствии с которыми принимаются решения о прокладке маршрута; в том числе организационные или политические.)

Мы сказали "создается впечатление, что было сделано 16 пересылок", так как имели возможность сравнить этот вывод с нашим предыдущим примером через NFSNET (см. рисунок 8.5), который показал 3 отсутствующих маршрута в примере, который использует свободную маршрутизацию от источника. (Это, возможно, было вызвано ошибками в работе маршрутизаторов при генерации ICMP сообщения об истечении времени при получении датаграмм, маршрутизируемых от источника.) Маршрутизатор gateway.tuc.noao.edu отсутствует между netb и butch, а маршрутизаторы Westgate.Telcom.Arizona.edu и uu-ua.AZ.westnet.net отсутствуют между Gabby и enss142.UT.westnet.net. Вполне возможно, что мы не видим эти маршрутизаторы так как они не могут корректно обработать входящие датаграммы со свободной маршрутизации от источника. В действительности, при использовании NSFNET осуществляется 19 пересылок между источником и NIC. В упражнении 5 главы 8 будет продолжено рассмотрение отсутствующих маршрутизаторов.

Из этого примера видна еще одна проблема. В командной строке мы должны указать IP адрес маршрутизатора enss142.UT.westnet.net вместо его имени. Это происходит потому, что процедура определяющая соответствие между именем и адресом (возвращается имя по заданному IP адресу, раздел "Запросы указателя", главы 14), или наоборот, когда задается имя, а возвращается IP адрес, не работает. Функции определения адреса по имени и имени по адресу используют два различных файла в системе DNS (Domain Name System), и не все администраторы синхронизируют эти два файла друг с другом. Нет ничего необычного в том, что в одном направлении DNS работает, но не работает в другом.

Вместо первого RTT для TTL равного 8 мы видим в выводе звездочку (*). Это указывает на то, что был отработан тайм-аут и на первую посылку в течении пяти секунд не был получен отклик.

И последнее, на что необходимо обратить внимание, сравнивая этот рисунок с рисунком 8.4, заключается в том, что маршрутизатор nsn-FIX-pe.sura.net подключен как к NSFNET, так и к сети NASA.

Traceroute от хоста sun.tuc.noao.edu к хосту aw.com.

Рисунок 8.5 traceroute от хоста sun.tuc.noao.edu к хосту aw.com.

После того как датаграмма вышла из сети telcom.arizona.edu она попадает в региональную сеть western.net (TTL 6 и 7). Затем датаграмма попадает на магистраль (backbone) NSFNET, t3.ans.net, которая используется Advanced Network & Services. (T3 это общепринятая аббревиатура для каналов 45 Мбит/сек, которые используются в качестве магистралей.) И последняя сеть это alter.net, точка подсоединения к Internet для aw.com.

Traceroute от sun к nic.ddn.mil.

Рисунок 8.4 traceroute от sun к nic.ddn.mil.

Чтобы включить этот пример в текст, мы запустили его для не-DDN узлов (не военные узлы) от nic.ddn.mil к rs.internic.net, новый "InterNIC".

Когда датаграмма выходит из сети tuc.noao.edu, она попадает в сеть telcom.arizona.edu. Затем она попадает в сеть Национального агентства по аэронавтике США (NASA Science Internet), nsn.nasa.gov. Маршрутизаторы с TTL равным 6 и 7 находятся в лаборатории Jet Propulsion (JPL). Сеть sura.net (в выводе TTL равно 11) это сеть Исследовательской ассоциации университетов (Southeastern Universities Research Association Network). GSI (TTL равно 12) это Government Systems, Inc., оператор для NIC.

Второе RTT для TTL равного 6 (590) почти в два раза больше, чем два другие RTT (234 и 262). Это показывает динамику IP маршрутизации. Подобное может произойти где-нибудь по пути от источника к маршрутизатору если какой-нибудь промежуточный маршрутизатор задержал датаграмму. Однако мы не можем сказать, была ли задержена исходящая датаграмма или возвращающееся ICMP сообщение.

RTT для первой попытки с TTL равным 3 (204) меньше, чем RTT для первой попытки с TTL равной 2 (233). Так как каждое полученное RTT является полным временем прохода от посылающего хоста к маршрутизатору, это вполне объснимо.

В примере на рисунке 8.5 показана работа программы Traceroute от хоста sun на хост нашего издателя.

sun % traceroute aw.com
traceroute to aw.com (192.207.117.2), 30 hops max, 40 byte packets
1 netb.tuc.noao.edu (140.252.1.183) 227 ms 227 ms 234 ms
2 gateway.tuc.noao.edu (140.252.1.4) 233 ms 229 ms 234 ms

3 butch.telcom.arizona.edu (140.252.104.2) 233 ms 229 ms 234 ms
4 Gabby.Telcom.Arizona.EDU (128.196.128.1) 264 ms 228 ms 234 ms
5 Westgate.Telcom.Arizona.EDU (192.80.43.2) 234 ms 228 ms 234 ms

6 uu-ua.AZ.westnet.net (192.31.39.233) 263 ms 258 ms 264 ms
7 enss142.UT.westnet.net (192.31.39.21) 263 ms 258 ms 264 ms

8 t3-2.Denver-cnss97.t3.ans.net (140.222.97.3) 293 ms 288 ms 275 ms
9 t3-3.Denver-cnss96.t3.ans.net (140.222.96.4) 283 ms 263 ms 261 ms
10 t3-1.St-Louis-cnss80.t3.ans.net (140.222.80.2) 282 ms 288 ms 294 ms
11 t3-1.Chicago-cnss24.t3.ans.net (140.222.24.2) 293 ms 288 ms 294 ms
12 t3-2.Cleveland-cnss40.t3.ans.net (140.222.40.3) 294 ms 288 ms 294 ms
13 t3-1.New-York-cnss32.t3.ans.net (140.222.32.2) 323 ms 318 ms 324 ms
14 t3-1.Washington-DC-cnss56.t3.ans.net (140.222.56.2) 323 ms 318 ms 324 ms
15 t3-0.Washington-DC-cnss58.t3.ans.net (140.222.58.1) 324 ms 318 ms 324 ms
16 t3-0.enss136.t3.ans.net (140.222.136.1) 323 ms 318 ms 324 ms

17 Washington.DC.ALTER.NET (192.41.177.248) 323 ms 377 ms 324 ms
18 Boston.MA.ALTER.NET (137.39.12.2) 324 ms 347 ms 324 ms
19 AW-gw.ALTER.NET (137.39.62.2) 353 ms 378 ms 354 ms

20 aw.com (192.207.117.2) 354 ms 349 ms 354 ms

Traceroute с жесткой маршрутизацией

Рисунок 8.9 traceroute с жесткой маршрутизацией от источника, который не работает.

Здесь необходимо обратить внимание на выражение !S, следующее за RTT для TTL равного 3. Это означает, что программа traceroute получила ICMP сообщение "маршрутизация от источника не сработала" (source route failed): type равняется 3 и code равняется 5 на рисунке 6.3. Звездочка во втором RTT для TTL равного 3 указывает на то, что на эту посылку не был получен ответ. Это как раз то что мы ожидали, так как для gateway не существует возможности послать датаграмму непосредственно к gabby.

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

На рисунке 8.10 показан вывод tcpdump, соответствующий этому примеру. Этот вывод получен на SLIP канале между sun и netb. Мы указали опцию -v для tcpdump, чтобы получить информацию о маршрутизации от источника. При этом появляется часть вывода, который нам не нужен, как, например, идентификатор датаграммы. Этот вывод был удален. Сокращение SSRR означает "жесткая маршрутизация от источника с записью" (strict source and record route).

1 0.0 sun.33593 > netb.33435: udp 12 [ttl 1]
(optlen=16 SSRR{#gateway gabby westgate} EOL)
2 0.270278 (0.2703) netb > sun: icmp: time exceeded in-transit
3 0.284784 (0.0145) sun.33593 > netb.33436: udp 12 [ttl 1]
(optlen=16 SSRR{#gateway gabby westgate} EOL)
4 0.540338 (0.2556) netb > sun: icmp: time exceeded in-transit
5 0.550062 (0.0097) sun.33593 > netb.33437: udp 12 [ttl 1]
(optlen=16 SSRR{#gateway gabby westgate} EOL)
6 0.810310 (0.2602) netb > sun: icmp: time exceeded in-transit
7 0.818030 (0.0077) sun.33593 > netb.33438: udp 12 (ttl 2,
optlen=16 SSRR{#gateway gabby westgate} EOL)
8 1.080337 (0.2623) gateway > sun: icmp: time exceeded in-transit
9 1.092564 (0.0122) sun.33593 > netb.33439: udp 12 (ttl 2,
optlen=16 SSRR{#gateway gabby westgate} EOL)
10 1.350322 (0.2578) gateway > sun: icmp: time exceeded in-transit
11 1.357382 (0.0071) sun.33593 > netb.33440: udp 12 (ttl 2,
optlen=16 SSRR{#gateway gabby westgate} EOL)
12 1.590586 (0.2332) gateway > sun: icmp: time exceeded in-transit
13 1.598926 (0.0083) sun.33593 > netb.33441: udp 12 (ttl 3,
optlen=16 SSRR{#gateway gabby westgate} EOL)
14 1.860341 (0.2614) gateway > sun:
icmp: gateway unreachable - source route failed
15 1.875230 (0.0149) sun.33593 > netb.33442: udp 12 (ttl 3,
optlen=16 SSRR{#gateway gabby westgate} EOL)
16 6.876579 (5.0013) sun.33593 > netb.33443: udp 12 (ttl 3,
optlen=16 SSRR{#gateway gabby westgate} EOL)
17 7.110518 (0.2339) gateway > sun:
icmp: gateway unreachable - source route failed

Время возврата traceroute при

Время возврата traceroute при использовании свободной маршрутизации от источника

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

Добиться этого можно, если указать свободную маршрутизацию от источника с назначением по свободному маршруту и указать посылающий хост в качестве конечного пункта назначения. Например, с хоста sun мы можем найти маршрут к и от хоста bruno.cs.colorado.edu (см. рисунок 8.11).

sun % traceroute -g bruno.cs.colorado.edu sun
traceroute to sun (140.252.13.33), 30 hops max, 40 byte packets
1 netb.tuc.noao.edu (140.252.1.183) 230 ms 227 ms 233 ms
2 gateway.tuc.noao.edu (140.252.1.4) 233 ms 229 ms 234 ms

3 butch.telcom.arizona.edu (140.252.104.2) 234 ms 229 ms 234 ms
4 Gabby.Telcom.Arizona.EDU (128.196.128.1) 233 ms 231 ms 234 ms
5 NSIgate.Telcom.Arizona.EDU (192.80.43.3) 294 ms 258 ms 234 ms

6 JPL1.NSN.NASA.GOV (128.161.88.2) 264 ms 258 ms 264 ms
7 JPL2.NSN.NASA.GOV (192.100.15.2) 264 ms 258 ms 264 ms
8 NCAR.NSN.NASA.GOV (128.161.97.2) 324 ms * 295 ms

9 cu-gw.ucar.edu (192.43.244.4) 294 ms 318 ms 294 ms

10 engr-gw.Colorado.EDU (128.138.1.3) 294 ms 288 ms 294 ms
11 bruno.cs.colorado.edu (128.138.243.151) 293 ms 317 ms 294 ms
12 engr-gw-ot.cs.colorado.edu (128.138.204.1) 323 ms 317 ms 384 ms
13 cu-gw.Colorado.EDU (128.138.1.1) 294 ms 318 ms 294 ms

14 enss.ucar.edu (192.43.244.10) 323 ms 318 ms 294 ms

15 t3-1.Denver-cnss97.t3.ans.net (140.222.97.2) 294 ms 288 ms 384 ms
16 t3-0.enss142.t3.ans.net (140.222.142.1) 293 ms 288 ms 294 ms

17 Gabby.Telcom.Arizona.EDU (192.80.43.1) 294 ms 288 ms 294 ms
18 Butch.Telcom.Arizona.EDU (128.196.128.88) 293 ms 317 ms 294 ms

19 gateway.tuc.noao.edu (140.252.104.1) 294 ms 289 ms 294 ms
20 netb.tuc.noao.edu (140.252.1.183) 324 ms 321 ms 294 ms
21 sun.tuc.noao.edu (140.252.13.33) 534 ms 529 ms 564 ms

Введение

Введение

Программа Traceroute, написанная Van Jacobson, - отладочное средство, которое позволяет лучше понять устройство протоколов TCP/IP. Обычно две последовательные датаграммы отправленные от одного и того же источника к одному и тому же пункту назначения проходят по одному и тому же маршруту, однако гарантировать этого невозможно. Traceroute позволяет нам посмотреть маршрут, по которому двигаются IP датаграммы от одного хоста к другому. С помощью Traceroute можно воспользоваться IP опцией маршрутизации от источника.
В страницах помощи о программе Traceroute говорится: "Разработана Van Jacobson по предложению Steve Deering. Отлажена и настроена C. Philip Wood, Tim Seaver и Ken Adelman."

Вывод при работе в глобальных сетях

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

На рисунке 8.4 показано как отправляется запрос от sun к Сетевому информационному центру (NIC - Network Information Center).

sun % traceroute nic.ddn.mil
traceroute to nic.ddn.mil (192.112.36.5), 30 hops max, 40 byte packets

1 netb.tuc.noao.edu (140.252.1.183) 218 ms 227 ms 233 ms
2 gateway.tuc.noao.edu (140.252.1.4) 233 ms 229 ms 204 ms

3 butch.telcom.arizona.edu (140.252.104.2) 204 ms 228 ms 234 ms
4 Gabby.Telcom.Arizona.EDU (128.196.128.1) 234 ms 228 ms 204 ms
5 NSIgate.Telcom.Arizona.EDU (192.80.43.3) 233 ms 228 ms 234 ms

6 JPL1.NSN.NASA.GOV (128.161.88.2) 234 ms 590 ms 262 ms
7 JPL3.NSN.NASA.GOV (192.100.15.3) 238 ms 223 ms 234 ms
8 GSFC3.NSN.NASA.GOV (128.161.3.33) 293 ms 318 ms 324 ms
9 GSFC8.NSN.NASA.GOV (192.100.13.8) 294 ms 318 ms 294 ms
10 SURA2.NSN.NASA.GOV (128.161.166.2) 323 ms 319 ms 294 ms
11 nsn-FIX-pe.sura.net (192.80.214.253) 294 ms 318 ms 294 ms
12 GSI.NSN.NASA.GOV (128.161.252.2) 293 ms 318 ms 324 ms

13 NIC.DDN.MIL (192.112.36.5) 324 ms 321 ms 324 ms

Вывод tcpdump для примера traceroute от svr4 к slip.

Рисунок 8.1 Вывод tcpdump для примера traceroute от svr4 к slip.

ICMP cообщение "время истекло при передаче" (time exceeded in transit) это то, что мы ожидаем увидеть от маршрутизатора bsdi, в том случае если он уменьшит на единицу TTL и оно станет равным нулю. ICMP сообщение придет от маршрутизатора даже в том случае, если IP датаграмма, которая была уничтожена, направлялась на slip.

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

Вывод tcpdump для traceroute с

Рисунок 8.10 Вывод tcpdump для traceroute с неработающей жесткой маршрутизацией от источника.

Обратите внимание на то, что каждая UDP датаграмма, посланная sun, имеет в качестве назначения netb, а не хост назначения (westgate). Мы описали это с помощью примера, показанного на рисунке 8.7. Два других маршрутизатора указаны с опцией -G (gateway и gabby), а конечный пункт назначения (westgate) появляется в списке опций SSRR для первой пересылки.

Также из этого вывода можно заметить, что тайм-аут, используемый traceroute (время между строками 15 и 16), составляет 5 секунд.

Более подробно

На рисунке 9.4 показан формат сообщения ICMP о перенаправлении.

Более сложные таблицы маршрутизации

Хост sun является маршрутизатором по умолчанию для всех хостов в нашей подсети, так как он имеет SLIP канал с дозвоном, который подключен к Internet (см. рисунок на внутренней стороне обложки).

sun % netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 171 le0
127.0.0.1 127.0.0.1 UH 1 766 lo0
140.252.1.183 140.252.1.29 UH 0 0 sl0
default 140.252.1.183 UG 1 2955 sl0
140.252.13.32 140.252.13.33 U 8 99551 le0

Первые два пункта таблицы маршрутизации sun идентичны первым двум пунктам для хоста svr4: маршрут, указывающий на хост slip, через маршрутизатор bsdi и loopback маршрут.

Третья строка отличается. Это прямой маршрут (флаг G не установлен) на хост (флаг H установлен), соответствующий каналу точка-точка, интерфейс SLIP. Если мы посмотрим на вывод команды ifconfig,

sun % ifconfig sl0
sl0: flags=1051<UP, POINTOPOINT, RUNNING>
inet 140.252.1.29 --> 140.252.1.183 netmask ffffff00

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

Пункт по умолчанию это непрямой маршрут (флаг G), указывающий на сеть (нет флага H). Адрес маршрутизатора - 140.252.1.183, (адрес на другом конце SLIP канала), а не локальный IP адрес SLIP интерфейса (140.252.1.29) (так как это непрямой маршрут).

Необходимо обратить внимание на то, что третья и четвертая строки в выводе команды netstat (интерфейс sl0) создаются программным обеспечением SLIP при установлении канала SLIP, они удаляются, когда канал SLIP отключается.

Действия, выполняемые IP уровнем.

Рисунок 9.1 Действия, выполняемые IP уровнем.

Формат ICMP сообщения запроса маршрутизатора.

Рисунок 9.6 Формат ICMP сообщения запроса маршрутизатора.

Функционирование хоста

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

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

Пока текущий маршрутизатор по умолчанию функционирует, он отправляет объявления каждые 10 минут с временем жизни в 30 минут. Это означает, что маршрут по умолчанию в таблице маршрутизации хоста не будет удален по тайм-ауту, даже если одно или два объявления будут потеряны.

Функционирование маршрутизатора

Когда маршрутизатор стартует, он начинает периодически рассылать объявления на все интерфейсы, которые поддерживают групповой и широковещательный тип адресации. В действительности эти объявления не периодические, они рассылаются случайным образом. Это сделано для того, чтобы объявления не перемешивались и не синхронизировались с другими маршрутизаторами в той же подсети. Обычный интервал между объявлениями составляет от 450 до 600 секунд. Время жизни по умолчанию для каждого объявления составляет 30 минут.

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

Помимо периодических объявлений, маршрутизатор отвечает на запросы от хостов. Он отвечает на запросы объявлением маршрутизатора.

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

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

ICMP ошибка о недоступности хоста (host unreachable) отправляется маршрутизатором, когда он получает IP датаграмму, которую невозможно перенаправить. (На рисунке 6.10 мы показали формат ICMP сообщений о недоступности.) Мы сможем пронаблюдать это в нашей сети, если выключим SLIP канал с дозвоном на маршрутизаторе sun и попробуем отправить пакет через SLIP канал с любого другого хоста, указав sun как маршрутизатор по умолчанию.

Ранние реализации TCP/IP в BSD генерировали и ошибки о недоступности хоста, и ошибки о недоступности сети, в зависимости от того, принадлежал ли пункт назначения локальной подсети или нет. 4.4BSD генерирует только ошибку о недоступности хоста.

Обратимся снова к выводу команды netstat запущенной на маршрутизаторе sun, вывод показан в предыдущем разделе. Мы видим, что пункт таблицы маршрутизации, который соответствует SLIP каналу, добавляется, когда SLIP канал включается, и удаляется, когда SLIP канал выключается. Это означает, что когда SLIP канал отключен, маршрута по умолчанию на sun не существует. Однако мы не будем пытаться изменить все таблицы маршрутизации у хостов в нашей маленькой сети, оставив им возможность самим удалить свои маршруты по умолчанию. Вместо этого мы посчитаем ICMP сообщения о недоступности хоста, сгенерированные sun для любых пакетов, которые он не может перенаправить.

Мы можем увидеть это, запустив ping с svr4 на хост, находящийся на другом конце SLIP канала (в настоящее время этот хост выключен):

svr4 % ping gemini
ICMP Host Unreachable from gateway sun (140.252.13.33)
ICMP Host Unreachable from gateway sun (140.252.13.33)
^? символ прерывания

На рисунке 9.2 мы показали вывод команды tcpdump для этого примера. (Команда запущена на хосте bsdi).

1 0.0 svr4 > gemini: icmp: echo request
2 0.00 (0.00) sun > svr4: icmp: host gemini unreachable

3 0.99 (0.99) svr4 > gemini: icmp: echo request
4 0.99 (0.00) sun > svr4: icmp: host gemini unreachable

ICMP ошибки перенаправления

ICMP ошибка перенаправления отправляется маршрутизатором на хост, пославший IP датаграмму, когда датаграмма должна быть послана на другой маршрутизатор. Подобная концепция довольно проста. Мы привели три составные части этой концепции на рисунке 9.3. Увидеть ICMP перенаправление можно только когда хост имеет выбор, на какой маршрутизатор послать пакет. (Обратитесь к примерам, которые мы приводили на рисунке 7.6.) Предположим, что хост посылает IP датаграмму на R1. Подобное решение принято потому, что R1 - это маршрутизатор по умолчанию для этого хоста. R1 принимает датаграмму, просматривает свою таблицу маршрутизации, и определяет, что маршрутизатором следующей пересылки является R2, и именно туда необходимо отправить датаграмму. Когда R1 отправляет датаграмму на R2, он определяет, что отправляет ее на тот же самый интерфейс, с которого датаграмма была получена (локальная сеть, к которой подключен хост и два маршрутизатора). В этом случае маршрутизатор отправляет ошибку перенаправления на хост, пославший датаграмму. R1 посылает ICMP перенаправление на хост, сообщая тем самым, что следующие датаграммы необходимо посылать на R2 вместо R1.

ICMP сообщение о перенаправлении.

Рисунок 9.4 ICMP сообщение о перенаправлении.

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

код	Описание
0	перенаправление для сети
1	перенаправление для хоста
2	перенаправление для типа сервиса (TOS) и сети
3	перенаправление для типа сервиса (TOS) и хоста

ICMP сообщения поиска маршрутизатора

ICMP сообщения поиска маршрутизатора (ICMP Router Discovery Messages)

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

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

RFC 1256 [Deering 1991] содержит формат этих ICMP сообщений. На рисунке 9.6 показан формат ICMP сообщения запроса маршрутизатора. На рисунке 9.7 показан формат ICMP сообщения объявления маршрутизатора, которое рассылается маршрутизаторами.

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

Инициализация таблицы маршрутизации

Мы никогда не упоминали о том, как создаются пункты в таблице маршрутизации. Когда инициализируется интерфейс (обычно, когда адрес интерфейса устанавливается командой ifconfig), автоматически создается прямой маршрут для этого интерфейса. Для каналов точка-точка и loopback интерфейса устанавливается маршрут к хосту (то есть устанавливается флаг H). Для широковещательных интерфейсов, таких как Ethernet, маршрутом является сама эта сеть.

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

route add default sun 1
route add slip bsdi 1

Третий аргумент (default и slip) это пункты назначения, четвертый аргумент это маршрутизатор (gateway) и последний аргумент это показатель маршрутизации. Команда route использует показатель маршрутизации следующим образом: она устанавливает флаг G, если показатель больше чем 0, и не устанавливает флаг G, если показатель равен 0.

К сожалению, совсем немногие системы содержат команды route в своих стартовых файлах. В 4.4BSD и BSD/386 это /etc/netstat, в SVR4 - /etc/inet/rc.inet, в Solaris 2.x - /etc/rc2.d/S69inet, в SunOS 4.1.x - /etc/rc.local и в AIX 3.2.2 - /etc/rc.net.

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

Существует еще один способ заполнить таблицу маршрутизации с помощью запуска демона маршрутизации (см. главу 10) или с помощью нового протокола определения маршрутов (раздел "ICMP сообщения поиска маршрутизатора").

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

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

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

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

Нет маршрута к пункту назначения

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

Ответ зависит от того, какого рода IP датаграмма обрабатывается, то есть была ли она сгенерирована непосредственно этим хостом или она должна быть перенаправлена (в том случае, если хост выступает в роли маршрутизатора). Если датаграмма была сгенерирована этим хостом, приложению, которое отправило датаграмму, возвращается ошибка "хост недоступен" (host unreachable) или "сеть недоступна" (network unreachable). Если датаграмма должна быть перенаправлена, посылающему хосту возвращается ICMP собщение о недоступности хоста. Мы рассмотрим эту ошибку в следующем разделе.

Перенаправлять или не перенаправлять

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

Большинство Berkeley реализаций, имеют переменную ядра, названную ipforwarding (или похоже). (См. приложение Е.) Некоторые системы (BSD/386 и SVR4, например) перенаправляют датаграммы, если эта переменная установлена в ненулевое значение. В SunOS 4.1.x определено три значения для этой переменной: -1 обозначает, что перенаправление никогда не будет осуществляться и что никогда нельзя будет сменить значение этой переменной, 0 обозначает, что перенаправление не осуществляется, однако значение переменной устанавливается в 1, когда два или более интерфейсов активизированы, и 1 обозначает, что перенаправление осуществляется всегда. У Solaris 2.x также существует три значения, а именно 0 (перенаправление не осуществляется), 1 (перенаправление осуществляется всегда) и 2 (перенаправление осуществляется только тогда, когда активизированы два или более интерфейсов).

В более ранних реализациях 4.2BSD датаграммы перенаправляются по умолчанию. При этом, если система сконфигурирована неверно, возникает очень много проблем. Именно поэтому данная опция ядра должна быть всегда по умолчанию установлена в значение "без перенаправления" (never forward), пока системный администратор специально не включит перенаправление.

Пример

Пример

Посмотрим ICMP перенаправления в действии на примере нашей сети (на внутренней стороне обложки). Мы показали всего три хоста (aix, solaris и gemini) и два маршрутизатора (gateway и netb) в верхней части сети, в действительности там более 150 хостов и 10 маршрутизаторов. Большинство хостов считают gateway маршрутизатором по умолчанию, так как он предоставляет доступ к Internet.
Как можно получить доступ из подсети 140.252.1 к нижней подсети (4 нижние хоста на рисунке)? Во-первых, вспомним, что если на конце SLIP канала находится единственный хост, используется уполномоченный агент ARP (глава 4, раздел "Уполномоченный агент ARP"). Это означает, что для хостов в верхней сети 140.252.1 не требуется специальных средств, для того чтобы получить доступ к хосту sun (140.252.1.29). Доступ обеспечит программное обеспечение уполномоченного агента ARP на netb.
Однако, если на удаленном конце SLIP канала присутствует сеть, то необходима маршрутизация. Одно из возможных решений заключается в том, чтобы каждый хост и маршрутизатор знали о том, что маршрутизатор netb является шлюзом в сеть 140.252.13. Этого можно добиться путем внесения статического маршрута в каждую таблицу маршрутизации на каждом хосте или запустив на каждом хосте маршрутизирующий демон. Однако существует более простой способ (метод, который обычно используется) - использовать ICMP перенаправление.
Запустим программу ping с хоста solaris в верхней сети на хост bsdi (140.252.13.35) в нижней сети. Так как идентификаторы подсети различны, уполномоченный агент ARP не может быть использован. Предположим, что статический маршрут не установлен, поэтому при посылке первого пакета будет использован маршрут по умолчанию на маршрутизатор gateway. Ниже мы приводим таблицу маршрутизации, перед тем как запустили ping:
solaris % netstat -rn
Routing Table:
Destination Gateway Flags Ref Use Interface
-------------- --------------- ------- --- ------- --------------
127.0.0.1 127.0.0.1 UH 0 848 lo0
140.252.1.0 140.252.1.32 U 3 15042 le0
224.0.0.0 140.252.1.32 U 3 0 le0
default 140.252.1.4 UG 0 5747

(Пункт 224.0.0.0 используется для групповой адресации IP. Мы опишем это в главе 12.) Если указать опцию -v в командной строке ping, то будут видны все ICMP сообщения принятые хостом. Нам необходимо указать эту опцию, чтобы увидеть сообщения о перенаправлении, которые будут посланы.
solaris % ping -sv bsdi
PING bsdi: 56 data bytes
ICMP Host redirect from gateway gateway (140.252.1.4)
to netb (140.252.1.183) for bsdi (140.252.13.35)
64 bytes from bsdi (140.252.13.35): icmp_seq=0. time=383. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=1. time=364. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=2. time=353. ms
^? символ прерывания
----bsdi PING Statistics----
4 packets transmitted, 3 packets received, 25% packet loss
round-trip (ms) min/avg/max = 353/366/383

Перед тем как мы получим первый ответ на ping, хост примет ICMP перенаправление от маршрутизатора по умолчанию gateway. Если мы затем посмотрим таблицу маршрутизации, то увидим, что появился новый маршрут к хосту bsdi. (Этот пункт выделен жирным шрифтом.)
solaris % netstat -rn
Routing Table:
Destination Gateway Flags Ref Use Interface
--------------- --------------- -------- --- ------- -------------
127.0.0.1 127.0.0.1 UH 0 848 lo0
140.252.13.35 140.252.1.183 UGHD 0 2
140.252.1.0 140.252.1.32 U 3 15045 le0
224.0.0.0 140.252.1.32 U 3 0 le0
default 140.252.1.4 UG 0 5749

Pltcmm мы впервые видиv флаг D, который означает, что маршрут был установлен с использованием ICMP перенаправления. Флаг G обозначает, что это непрямой маршрут к шлюзу (netb), а флаг H обозначает, что это маршрут к хосту (как мы и ожидали), а не маршрут к сети.
Так как это маршрут к хосту, добавленный путем перенаправления, он обслуживает только хост bsdi. Если затем мы попробуем получить доступ к хосту svr4, будет сгенерировано еще одно перенаправление, и будет создан еще один маршрут к хосту. Точно так же, попытка получить доступ к хосту slip создаст еще один маршрут. Каждое перенаправление на конкретный хост приводит к созданию нового маршрута к хосту. Все три хоста в подсети (bsdi, svr4 и slip) будут обслуживаться одним маршрутом к сети, указывающим на маршрутизатор sun. Однако, ICMP перенаправления создают маршруты к хостам, а не маршруты к сетям, так как маршрутизатор, генерирующий перенаправление в данном примере (gateway), не имеет представления о структуре подсетей в сети 140.252.13.

Пример ICMP перенаправления.

Рисунок 9.3 Пример ICMP перенаправления.

Перенаправления используются для того, чтобы позволить хосту с минимальным знанием о маршрутах поддерживать и обновлять свою таблицу маршрутизации. Как правило, формирование таблицы маршрутизации хоста начинается с создания маршрута по умолчанию (R1 или R2 из нашего примера на рисунке 9.3), при этом с использованием перенаправления хост может обновить свою таблицу маршрутизации. ICMP перенаправление позволяет TCP/IP хостам полностью полагаться на интеллектуальность маршрутизаторов в вопросе выбора маршрутов. Маршрутизаторы R1 и R2 в нашем примере должны точно представлять топологию подключенных сетей, тогда как хосты, подключенные к локальной сети, могут начинать свою маршрутизацию с маршрута по умолчанию, узнавая затем более подробно о новых маршрутах из принятых перенаправлений.

Принципы маршрутизации

Прежде чем начать обсуждение IP маршрутизации, необходимо понять, что именно ядро обновляет в таблице маршрутизации. Информация, содержащаяся в таблице маршрутизации, необходима IP уровню для принятия решения о маршрутизации. В разделе "IP маршрутизация" главы 3 мы показали, каким образом IP просматривает свою таблицу маршрутизации. Поиск совпадающего адреса хоста. Поиск совпадающего адреса сети. Поиск пункта по умолчанию. (Пункт по умолчанию обычно указывается в таблице маршрутизации как сеть с идентификатором сети равным нулю.)

Совпавший адрес хоста используется всегда перед совпавшим адресом сети.

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

Простая таблица маршрутизации

Давайте рассмотрим типичные таблицы маршрутизации. На хосте svr4 мы запустили команду netstat с опцией -r, чтобы просмотреть таблицу маршрутизации, и с опцией -n, которая печатает IP адреса в цифровом формате, а не в виде имен. (Мы сделали это, потому что некоторые пункты таблицы маршрутизации это сети, а не хосты. Без опции -n команда netstat просматривает файл /etc/networks, и берет оттуда имена сетей. При этом может получиться некоторая путаница, потому что в выводе команды помимо имен хостов появятся имена сетей.)

svr4 % netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 0 emd0
127.0.0.1 127.0.0.1 UH 1 0 lo0
default 140.252.13.33 UG 0 0 emd0
140.252.13.32 140.252.13.34 U 4 25043 emd0

В первой строке говорится, что для пункта назначения 140.252.13.65 (хост slip) шлюз (маршрутизатор), на который будут посылаться пакеты, это 140.252.13.35 (bsdi). Хост slip подсоединен к bsdi через SLIP канал, а bsdi находится в той же сети Ethernet, что и данный хост.

Для конкретного маршрута может быть показано 5 различных флагов.

Маршрут активен.

Маршрут подключен к шлюзу (маршрутизатору). Если этот флаг не установлен, считается, что пункт назначения подключен непосредственно.

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

Маршрут был создан посредством перенаправления ("ICMP ошибки перенаправления").

Маршрут был модифицирован посредством перенаправления ("ICMP ошибки перенаправления").

Флаг G очень важен, потому что именно этот флаг определяет различие между непрямым маршрутом (indirect route) и прямым маршрутом (direct route). (Флаг G не устанавливается для прямого маршрута.) Отличие заключается в том, что у пакета, направляющегося по прямому маршруту, IP адрес и адрес канального уровня указывают на конечный пункт назначения (рисунок 3.3). Когда пакет отправляется по непрямому маршруту, IP адрес указывает на конечный пункт назначения, а адрес канального уровня указывает на маршрутизатор следующей пересылки. Мы видели подобный пример этого на рисунке 3.4. В этой таблице маршрутизации мы видим непрямой маршрут (флаг G установлен), при этом IP адрес пакета, который будет передаваться по этому маршруту, будет совпадать с IP адресом конечного пункта назначения (140.252.13.65), а адрес канального уровня будет указывать на соответствующий маршрутизатор, IP адрес которого 140.252.13.35.

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

Колонка счетчика обращений (reference count) сообщает о количестве использований каждого маршрута. Протоколы, ориентированные на соединения, такие как TCP, занимают маршрут все время, пока соединение установлено. Если установить Telnet соединение между хостами svr4 и slip, то счетчик обращений будет установлен в 1. Если установить еще одно Telnet соединение, счетчик будет показывать 2, и так далее.

Следующая колонка (use) показывает количество пакетов, прошедших по этому маршруту. Если запустить программу ping, которая отправит 5 пакетов, счетчик установится в значение 5 (Естественно, при условии, что никто больше не использует этот маршрут). Последняя колонка интерфейс (interface) сообщает нам имя локального интерфейса.

Вторая строка в выводе относится к loopback интерфейсу (глава 2, раздел "Интерфейс Loopback"), который всегда имеет имя lo0. Флаг G не установлен, так как маршрут не ведет к маршрутизатору. Флаг H указывает, что адрес назначения (127.0.0.1) это адрес хоста, а не адрес сети. Когда флаг G не установлен, это указывает на прямой маршрут, в колонке gateway указывается IP адрес исходящего интерфейса.

Третья строка вывода описывает маршрут по умолчанию. Каждый хост должен иметь один или несколько маршрутов по умолчанию. Этот пункт указывает на то, что необходимо посылать пакеты на маршрутизатор 140.252.13.33 (sun), если не был найден конкретный маршрут. Это означает, что хост svr4 может получить доступ к другим системам в Internet через маршрутизатор sun (и его SLIP канал) воспользовавшись этим единственным пунктом таблицы маршрутизации. Возможность установить маршрут по умолчанию это одна из наиболее мощных концепций IP маршрутизации. Флаги для этого маршрута (UG) говорят о том, что маршрут указывает на маршрутизатор.

Здесь мы специально назвали sun маршрутизатором, а не хостом, потому что когда он работает как маршрутизатор по умолчанию, используются его функции IP перенаправления, при этом он не выступает в роли хоста.

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

И последняя строка указывает на подключенный Ethernet. Флаг H не установлен, это указывает на то, что адрес назначения (140.252.13.32) это адрес сети, при этом идентификатор хоста установлен в 0. И действительно, 5 младших битов установлены в 0 (рисунок 3.11). Это прямой маршрут (флаг G не установлен), поэтому в колонке gateway указывается IP адрес исходящего интерфейса.

Существует еще один немаловажный аспект, оказывающий влияние на маршрутизацию, однако он не отражен в выводе команды netstat. Это маска подсети, связанная с адресом назначения (140.252.13.32). Когда адрес пункта назначения сравнивается с IP адресом 140.252.13.33, адрес перед сравнением, логически суммируется с маской подсети, связанной с этим адресом назначения (0xffffffe0 из раздела "Пример подсети" главы 3). Так как ядро знает каждый интерфейс, связанный с каждым пунктом таблицы маршрутизации, и так как каждый интерфейс имеет маску подсети, каждый пункт таблицы маршрутизации имеет собственную маску подсети.

Сложность таблицы маршрутизации хоста зависит от топологии сетей, к которым хост имеет доступ. Самый простой (однако наименее интересный) случай - это когда хост вообще не подключен к сетям. Протоколы TCP/IP могут использоваться на этом хосте, однако только для общения с самим собой! Таблица маршрутизации в данном случае содержит единственный пункт соответствующий loopbackv интерфейсу. Хост подключен к одной локальной сети и имеет возможность получить доступ к хостам только в этой локальной сети. Таблица маршрутизации имеет 2 пункта: один для loopback интерфейса и один для локальной сети (например, Ethernet). Возможен вариант, когда другие сети (например, Internet) доступны через один маршрутизатор. В этом случае обычно используется пункт по умолчанию, указывающий на этот маршрутизатор. И последнее, когда добавляются маршруты к хостам или сетям. Примером этого может служить маршрут к хосту slip через маршрутизатор bsdi.

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

Предположим, что адрес назначения принадлежит хосту sun, 140.252.13.33. Во-первых, осуществляется поиск совпадающего адреса хоста. Два пункта хостов в таблице (slip и localhost) не совпадают, поэтому поиск в таблице маршрутизации осуществляется снова на предмет совпадающего адреса сети. Совпадение найдено в пункте 140.252.13.32 (идентификатор сети и идентификатор подсети совпали), поэтому используется интерфейс emd0. Это прямой маршрут, поэтому адрес канального уровня будет являться адресом назначения. Предположим, что адрес назначения это адрес хоста slip, 140.252.13.65. Первый поиск в таблице маршрутизации на предмет совпадающего адреса хоста заканчивается успешно. Это непрямой маршрут, поэтому IP адрес назначения остается 140.252.13.65, а адресом канального уровня будет адрес канального уровня маршрутизатора 140.252.13.35, используется интерфейс emd0. Теперь мы посылаем датаграмму по Internet на хост aw.com (192.207.117.2). Первый поиск в таблице маршрутизации на предмет совпадающего адреса хоста заканчивается неудачей, поэтому осуществляется поиск на предмет совпадающего адреса сети. Он также завершается неудачно. И последний шаг это поиск пункта по умолчанию, который заканчивается успешно. Маршрут является непрямым через маршрутизатор 140.252.13.33 с использованием интерфейса emd0. В нашем последнем примере мы послали датаграмму на свой собственный хост. Существует 4 способа сделать это, используя имя хоста, IP адрес хоста, loopback имя или loopback IP адрес:

ftp svr4
ftp 140.252.13.34

ftp localhost
ftp 127.0.0.1

В двух первых случаях второй поиск в таблице маршрутизации приведет к совпадению с сетью 140.252.13.32, и пакет посылается через Ethernet драйвер. Как мы показали на рисунке 2.4, пакет, предназначенный на собственный IP адрес хоста, посылается в loopback драйвер, который ставит пакет во входную очередь IP.

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

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

Различные значения code для ICMP перенаправления.

Рисунок 9.5 Различные значения code для ICMP перенаправления.

Существуют три IP адреса, которые должен знать получатель ICMP перенаправления: (1) IP адрес, который вызвал перенаправление (находится в IP заголовке, возвращенном как данные в ICMP сообщении о перенаправлении), (2) IP адрес маршрутизатора, который послал перенаправление (является IP адресом источника IP датаграммы, содержащей перенаправление) и (3) IP адрес маршрутизатора, который должен быть использован (находится в байтах с 4-го по 7-ой в ICMP сообщении).

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

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

Переменная ядра с именем ip_sendredirects (или похожим). (См. приложение Е.) Большинство современных систем (4.4BSD, SunOS 4.1.x, Solaris 2.x и AIX 3.2.2, например) включают эту переменную по умолчанию. Другие системы, например, SVR4, имеют эту переменную по умолчанию выключенной.

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

И в заключение стоит повториться, что маршрутизаторы должны посылать только перенаправления к хостам (codes 1 или 3 на рисунке 9.5), а не перенаправления к сетям. Из-за разделения на подсети не всегда можно однозначно указать, когда должно быть послано перенаправление к сети вместо перенаправления к хосту. Некоторые хосты воспринимают принятое перенаправление к сети как перенаправление к хосту, в том случае если маршрутизатор послал неверный тип (type).

Реализация

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

Эти два ICMP сообщения достаточно новы и поддерживаются не всеми системами. В нашей сети их поддерживает только Solaris 2.x (демон in.rdisc). Несмотря на то, что RFC рекомендует использовать групповую адресацию IP, где это возможно, поиск маршрутизаторов может осуществляться с использованием широковещательных сообщений.

Сообщение ICMP о недоступности хоста в ответ на ping.

Рисунок 9.2 Сообщение ICMP о недоступности хоста в ответ на ping.

Когда маршрутизатор sun обнаруживает, что на хост gemini нет маршрута, он отвечает на эхо запрос сообщением о недоступности хоста.

Если мы включим SLIP канал, подключающий нас к Internet, и попробуем послать ping на несуществующий в Internet IP адрес, то рано или поздно получим сообщение об ошибке. Интересно посмотреть, как далеко уйдет пакет по Internet, перед тем как будет получена ошибка:

sun % ping 192.82.148.1 этот IP адрес не подключен к Internet
PING 192.82.148.1: 56 data bytes
ICMP Host Unreachable from gateway enss142.UT.westnet.net (192.31.39.21)
for icmp from sun (140.252.1.29) to 192.82.148.1

Обратившись к рисунку 8.5, мы увидим, что пакет прошел через шесть маршрутизаторов, перед тем как было определено, что IP адрес не существует. Только когда он дошел до пределов NSFNET магистрали, была выявлена ошибка. Это произошло из-за того, что шесть маршрутизаторов, которые перенаправляли пакет, отправляли его на пункт назначения по умолчанию. И только когда пакет достиг NSFNET магистрали, маршрутизатор, имеющий полное представление о каждой сети, подключенной к Internet, смог определить ошибку. Это иллюстрирует тот факт, что большинство маршрутизаторов функционируют, не представляя себе полной топологии сетей.

[Ford, Rekhter, and Braun 1993] определяет домены маршрутизации верхнего уровня (top-level routing domain) как маршрутизаторы, поддерживающие и обрабатывающие информацию о большинстве узлов Internet и не использующие маршрутов по умолчанию. В Internet существует пять доменов маршрутизации верхнего уровня: NFSNET магистраль, Commercial Internet Exchange (CIX), NASA Science Internet (NSI), SprintLink и European IP Backbone (EBONE).

Упражнения

Упражнения

Как Вы думаете, почему существуют два типа ICMP перенаправлений - на сеть и на хост? Обратитесь к таблице маршрутизации хоста svr4, показанной в начале раздела "Принципы маршрутизации". Является ли необходимым указание маршрута на хост slip (140.252.13.65)? Что изменится, если этот пункт будет удален из таблицы маршрутизации? Представьте, что существует кабель между 4.2BSD и 4.3BSD хостами. Также представьте, что идентификатор сети - 140.1. Хост 4.2BSD распознает в качестве широковещательных адресов только адреса с идентификаторами хостов, установленными во все нули (140.1.0.0), тогда как хост 4.3BSD обычно отправляет широковещательные сообщения с идентификаторами хостов, состоящих из всех единичных битов (140.1.255.255). Также, хост 4.2BSD по умолчанию старается перенаправить входящие датаграммы, даже если он имеет только один интерфейс. Опишите, что произойдет, когда хост 4.2BSD получает IP датаграммы с адресом назначения 140.1.255.255. Продолжим предыдущее упражнение. Представьте себе, что кто-либо исправил эту проблему, добавив запись в ARP кэш на одной из систем в подсети 140.1. (воспользовавшись командой arp), сказав при этом, что IP адрес 140.1.255.255 соответствует Ethernet адресу из всех единичных битов (широковещательный запрос Ethernet). Опишите, что произойдет в этом случае. Просмотрите таблицу маршрутизации Вашей системы и опишите каждую запись. Назад
Компания | Услуги | Для клиентов | Библиотека | Галерея | Cофт | Линки
На главную

Введение

Введение

Маршрутизация - это одна из наиболее важных функций IP. На рисунке 9.1 показана упрощенная модель того, что реализуется на IP уровене. Датаграммы, которые должны быть смаршрутизированы, могут генерироваться как локальным хостом, так и каким-либо удаленным хостом. В последнем случае наш хост должен быть сконфигурирован как маршрутизатор, иначе датаграммы, получаемые через сетевые интерфейсы и не предназначенные нашему хосту, будут молча удалены.
На рисунке 9.1 также показан демон маршрутизации, который обычно является пользовательским процессом. Наиболее часто в Unix системах используются демоны routed и gated. Термин демон (daemon) означает, что процесс работает "в фоновом режиме" и его функционирование не оказывает влияние на систему в целом. Демоны обычно стартуют, когда система загружается, и живут все время, пока система работает. Протоколы маршрутизации, используемые на конкретном хосте, определяют, как будет происходить обмен информацией о маршрутах с удаленными маршрутизаторами. (Заинтересованные читатели могут обратиться к [Perlman 1992] для получения более подробной информации.) Мы вкратце рассмотрим динамическую маршрутизацию и протокол обмена информацией о маршрутизации (RIP - Routing Information Protocol) в главе 10. В этой главе мы рассмотрим, как IP уровень принимает решения о маршрутизации.
IP уровень обращается к таблице маршрутизации, которая показана на рисунке 9.1 (на загруженных хостах подобное обращение может происходить несколько сот раз в секунду), однако демон маршрутизации обновляет таблицу значительно реже (примерно один раз каждые 30 секунд). Таблица маршрутизации также может быть обновлена, когда принимается ICMP сообщение о перенаправлении (ICMP redirect), мы увидим это в разделе "ICMP ошибки перенаправления", когда будем рассматривать команду route. Эта команда обычно исполняется при загрузке системы и устанавливает некоторые исходные маршруты. Также в этой главе мы будем использовать команду netstat, для просмотра таблиц маршрутизации.