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

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], и найдите альтернативные способы определения маршрута к пункту назначения. В чем их преимущества и недостатки?

На главную

Содержание раздела