Для выявления различных неполадок в сети существует несколько утилит, которые позволяют определить, на каком уровне модели OSI произошел сбой, или указаны неверные настройки сетевых протоколов. Одна из таких утилит – ping.
Эта утилита позволяет определить ошибки на сетевом уровне (layer 3), используя протокол ICMP (Internet Control Message Protocol) – протокол межсетевых управляющих сообщений. Формат использования этой утилиты довольно прост: ping 194.87.0.50 (где 194.87.0.50 – IP-адрес удаленного компьютера). Если сеть работает корректно, в результате выводится время ожидания прихода ответа от удаленного компьютера и время жизни пакета (TTL, time to live, количество 'хопов', после которого пакет был бы отброшен; этот параметр показывает, сколько оставалось допустимых переходов у пакета-ответа).
Протокол ICMP находится на стыке двух уровней – сетевого и транспортного. Основной принцип действия этого протокола – формирование ICMP эхо-запроса (echo-request) и эхо-ответа (echo-reply). Запрос эха и ответ на него может использоваться для проверки достижимости хоста- получателя и его способности отвечать на запросы. Также прохождение эхо-запроса и эхо-ответа проверяет работоспособность основной части транспортной системы, маршрутизацию на машине источника, работоспособность и корректную маршрутизацию на роутерах между источником и получателем, а также работоспособность и правильность маршрутизации получателя.
Таким образом, если на посланный echo-request возвращается корректный echo-reply от машины, которой был послан запрос, можно сказать, что транспортная система работает корректно. И если браузер не может отобразить web-страницу, то проблема, по всей видимости, не в первых трех уровнях модели OSI.
Из примера видно, что по умолчанию размер посылаемого пакета - 32 байта, далее выводится время задержки ответа и TTL. В этом примере показано успешное выполнение команды ping. В случаях, когда запросы echo request посылаются, но echo reply не возвращаются, выводится сообщение об истечении времени ожидания ответа.
Traceroute
Утилита traceroute также использует протокол ICMP для определения маршрута прохождения пакета. При отсылке traceroute устанавливает значение TTL последовательно от 1 до 30. Каждый маршрутизатор, через который проходит пакет на пути к назначенному хосту, уменьшает значение TTL на единицу. С помощью TTL происходит предотвращение зацикливания пакета в 'петлях' маршрутизации, иначе 'заблудившиеся' пакеты окончательно перегрузили бы сеть. Однако, при выходе маршрутизатора или линии связи из строя требуется несколько дополнительных переходов для понимания, что данный маршрут потерян и его необходимо обойти. Чтобы предотвратить потерю датаграммы, поле TTL устанавливается на максимальную величину.
Когда маршрутизатор получает IP-датаграмму с TTL, равным 0 или 1, он уничтожает ее и посылает хосту, который ее отправил, ICMP-сообщение 'время истекло' (time exceeded). Принцип работы traceroute заключается в том, что IP-датаграмма, содержащая это ICMP-сообщение, имеет в качестве адреса источника IP-адрес маршрутизатора.
Теперь легко понять, как работает traceroute. На хост назначения отправляется IP- датаграмма с TTL, равным единице. Первый маршрутизатор, который должен обработать датаграмму, уничтожает ее (так как TTL равно 1) и отправляет ICMP-сообщение об истечении времени (time exceeded). Таким образом определяется первый маршрутизатор в маршруте. Затем traceroute отправляет датаграмму с TTL, равным 2, что позволяет получить IP-адрес второго маршрутизатора. Так продолжается до тех пор, пока датаграмма не достигнет хоста назначения. Утилита traceroute может посылать в качестве такой датаграммы UDP-сообщение с номером порта, который заведомо не будет обработан приложением (порт выше 30000), поэтому хост назначения ответит 'порт недоступен' (port unreachable). При получении такого ответа делается вывод, что удаленный хост работает корректно. В противном случае максимального значения TTL (по умолчанию 30) не хватило для того, чтобы его достигнуть.
Рассмотрим пример выполнения утилиты traceroute.
traceroute to netserv1.chg.ru (193.233.46.3), 30 hops max, 38 byte packets 1 n3-core.mipt.ru (194.85.80.1) 1.508 ms 0.617 ms 0.798 ms 2 mipt-gw-eth0.mipt.ru (193.125.142.177) 2.362 ms 2.666 ms 1.449 ms 3 msu-mipt-atm0.mipt.ru (212.16.1.1) 5.536 ms 5.993 ms 10.431 ms 4 M9-LYNX.ATM6-0.11.M9-R2.msu.net (193.232.127.229) 12.994 ms 7.830 ms 6.816 ms 5 Moscow-BNS045-ATM4-0-3.free.net (147.45.20.37) 12.228 ms 7.041 ms 8.731 ms 6 ChgNet-gw.free.net (147.45.20.222) 77.103 ms 75.234 ms 92.334 ms 7 netserv1.chg.ru (193.233.46.3) 96.627 ms 94.714 ms 134.676 ms Пример 16.1.
Первая строка содержит имя и IP-адрес хоста назначения, максимальное значение TTL и размер посылаемого пакета (38 байт). Последующие строки начинаются с TTL, после чего следует имя хоста, или маршрутизатора и его IP-адрес. Для каждого значения TTL отправляются три датаграммы. Для каждой возвращенной датаграммы определяется и выводится время возврата. Если в течение 3-х секунд на каждую из 3-х датаграмм не был получен ответ, то посылается следующая датаграмма, а вместо значения времени выводится звездочка. Время возврата – это время прохождения датаграммы от источника (хоста, выполняющего программу traceroute ) до маршрутизатора. Если нас интересует время, потраченное на пересылку между, например, 5 и 6 узлом, необходимо вычесть из значения времени TTL 6 время TTL 5.
В каждой из операционных систем сетевая часть утилиты реализована практически одинаково, но реализация на уровне приложений различается.
В ОС Solaris используется утилита traceroute. В качестве параметра задается IP-адрес, или доменное имя удаленного хоста, связь до которого требуется проверить. В примере, приведенном выше, видно успешное выполнение traceroute и корректную работу сете- зависимых уровней (физический, канальный, сетевой).
В ОС Windows утилита
