Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам
В предыдущей части этой серии статей, я говорил, что команду TRACERT можно использовать для диагностирования проблем подключения между локальным узлом и узлами удаленной сети. В той части я показал вам, как использовать основную команду TRACERT, поэтому в этой части я продолжу разговор о ней и объясню, как расшифровывать результаты этой команды.
В целях демонстрации я выполнил команду TRACERT для www.espn.com. Единственной причиной, по которой я выбрал данный конкретный сайт, является то, что это один из тех сайтов, которые не блокируют ICMP трафик, и я знаю это наверняка. Результаты этой команды показаны ниже. Я буду ссылаться на эти результаты в течение всей оставшейся части статьи.
C:\Users\Administrator>TRACERT www.espn.com
Tracing route to www.espn.com [199.181.132.250] over a maximum of 30 hops:
1 2 ms 1 ms <1 ms 147.100.100.100
2 10 ms 10 ms 9 ms 208.104.224.1
3 9 ms 9 ms 9 ms 208.104.1.13
4 9 ms 8 ms 9 ms 208.104.0.13
5 10 ms 9 ms 10 ms 208.104.0.1
6 11 ms 14 ms 10 ms 165.166.125.193
7 11 ms 10 ms 11 ms gig-1-1-3.core01.ncchrl.infoave.net [165.166.22.61]
8 31 ms 31 ms 30 ms 64.200.130.17
9 38 ms 39 ms 40 ms hrndva1wcx2-pos15-3-oc48.wcg.net [64.200.240.213]
10 31 ms 31 ms 31 ms 64.200.249.170
11 31 ms 30 ms 31 ms 4.68.110.5
12 48 ms 35 ms 35 ms vlan99.csw4.Washington1.Level3.net [4.68.17.254]
13 32 ms 31 ms 33 ms ae-92-92.ebr2.Washington1.Level3.net [4.69.134.157]
14 60 ms 53 ms 54 ms ae-2.ebr3.Chicago1.Level3.net [4.69.132.69]
15 86 ms 71 ms 70 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61]
16 137 ms 103 ms 102 ms ae-2.ebr2.Seattle1.Level3.net [4.69.132.53]
17 95 ms 95 ms 95 ms ae-23-52.car3.Seattle1.Level3.net [4.68.105.36]
18 94 ms 95 ms 95 ms WALT-DISNEY.car3.Seattle1.Level3.net [4.71.152.22]
19 * * * Request timed out.
20 97 ms 95 ms 98 ms 199.181.132.250
Trace complete.
Если вы посмотрите на вышеприведенные данные TRACERT, то заметите, что каждая строка результатов содержит несколько различных частей информации. Первая часть информации, расположенная с левой стороны показывает номер прыжка. Как я объяснял в предыдущей части, TRACERT работает путем отправки запроса ping на указанный хост. Изначально TTL значение запроса установлено на 1. Это обеспечивает сбой запроса после первого прыжка. Информация о прыжке предоставляется, после чего ICMP запрос передается снова, но на этот раз его TTL значение установлено на 2. Этот процесс повторяется снова и снова, каждый раз увеличивая TTL значение на 1 до тех пор, пока указанный узел не будет достигнут. Благодаря этому команда TRACERT способна давать информацию о том, сколько прыжков запросу пришлось сделать, чтобы достичь удаленного узла. Если вы посмотрите на данные выше, вы увидите, что последняя цифра в левом ряду будет 20. Это означает, что запросу потребовалось выполнить 20 прыжков, чтобы достичь указанного узла.
Следующие три части информации в каждой строке отображают количество времени, которое потребовалось, чтобы достичь маршрутизатора или узла, на который ссылается конкретная строка. Если вы просмотрите список, то заметите, что время соединения, как правило, увеличивается с каждым прыжком. Вам нужно знать две вещи об этом времени.
Во-первых, отображаются три различных временных промежутка для каждого прыжка. Как я уже говорил, трассировка маршрута основана на концепции отправки нескольких ICMP запросов. Когда мы работали с командой ping, вы видели, что она всегда возвращалась с различными значениями, как способом измерения потери пакетов. Эта же концепция применима и для трассировки маршрута, за исключением того, что длительность времени, необходимая запросу, измеряется три раза, а не четыре.
Второе, что вам нужно знать о времени ответа, это то, что звездочки указывают на то, что время запроса вышло. Это может указывать на проблему, а может и не указывать, в зависимости от того, как появляются звездочки. Если вы посмотрите на прыжок номер 19, то увидите, что все три времени ответа представлены звездочками. Когда вы видите три звездочки подряд, это обычно означает, что устройство, которое опрашивается во время прыжка, имеет файервол, настроенный на блокирование ICMP пакетов, что вызывает таймаут таймеров, а в последнем столбце будет надпись «Превышен интервал ожидания для запроса».
Следует учитывать, что, хотя это самый распространенный случай, он не единственный. Трассировка маршрута также выдает три звездочки, когда нужное устройство недоступно. Конечно, здесь возникает вопрос, как отличить сайт, блокирующий ICMP пакеты, от сбоя в соединении? На самом деле это может быть довольно сложным делом.
На первый взгляд сбой в соединении выглядит идентично ситуации, когда маршрутизатор или узел блокирует ICMP запросы. Когда возникает сбой, вы не увидите сообщений об ошибке. На самом деле процесс заканчивается стандартным сообщением «Трассировка завершена».
Существует два отличных знака, указывающих на сбой в соединении. Одним знаком будет результат, в котором по достижении определенной точки все последующие запросы будут возвращаться с превышенным интервалом ожидания. Другим знаком будет ситуация, в которой команда TRACERT выполняет все 30 прыжков. Ни один из этих знаков, однако, не гарантирует наличие сбоя соединения, даже если они встречаются вместе. К примеру, мой веб сайт (www.brienposey.com) отлично работает на данный момент, и все же, когда я запускаю команду TRACERT на нем, оба этих симптома присутствуют в результате:
C:\Users\Administrator>TRACERT www.brienposey.com
Tracing route to www.brienposey.com [24.235.10.4]
over a maximum of 30 hops:
1 1 ms 1 ms <1 ms 147.100.100.100
2 8 ms 12 ms 8 ms 208.104.224.1
3 9 ms 8 ms 9 ms 208.104.1.9
4 10 ms 9 ms 8 ms 208.104.0.9
5 10 ms 12 ms 11 ms 208.104.0.5
6 12 ms 10 ms 9 ms 165.166.18.1
7 15 ms 23 ms 13 ms gig2-2-1.c01.scclma.infoave.net [165.166.22.17]
8 13 ms 12 ms 13 ms 66.192.166.9
9 31 ms 30 ms * peer-01-ge-0-0-0-1.asbn.twtelecom.net [64.129.249.10]
10 56 ms 57 ms 55 ms bb2-p6-0.ipltin.sbcglobal.net [151.164.242.59]
11 55 ms 53 ms 55 ms ded2-g8-0.ipltin.sbcglobal.net [151.164.42.159]
12 59 ms 56 ms 56 ms Winnet-1148485.cust-rtr.ameritech.net [66.73.221.254]
13 64 ms 63 ms 68 ms 216-24-2-237.ip.win.net [216.24.2.237]
14 68 ms 68 ms 64 ms fa0-0.cust-gw2.noc.win.net [216.24.30.69]
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace complete.
Если вы видите результаты, подобные этим, они могут указывать на то, что возник сбой соединения, но они этого не гарантируют. Единственным способом убедиться в этом, является попытка выполнить команду TRACERT к нескольким сайтам. Следует помнить, что каждый последующий прыжок находится все дальше от вас. Чем дальше от вас находится проблема, тем сложнее будет ее определить, поскольку тестирование других сайтов может включать другие маршруты. Когда вы выполняете TRACERT для различных сайтов, вам нужно обращать внимание на маршруты, по которым проходит запрос, чтобы определить, имеет ли место сбой в соединении.
Последняя часть информации, отображаемая в каждом ряду, — это данные о маршрутизаторе или узле, который ответил на ICMP запрос. TRACERT будет определять каждый узел или маршрутизатор по названию, когда это возможно, но вы не всегда будете получать полное разрешение имени. Например, если посмотреть на вышеприведенные результаты, видно, что половина маршрутизаторов определена по названию, а вторая половина нет. Это, как правило, не является проблемой.
Самое интересное то, что узел, для которого вы выполняете трассировку маршрута, не всегда будет определяться. Например, если взглянуть на самое начало первого примера, вы заметите, что мы ввели команду TRACERT WWW.ESPN.COM. Сразу же после этого TRACERT разрешила название www.espn.com в IP адрес 199.181.132.250. Но если вы посмотрите в самый конец этого примера, то обратите внимание на то, что TRACERT постепенно достигает места назначения, но не определяет место назначения по названию (по крайней мере, не в этом случае).
Такое поведение не является проблематичным, поскольку так и должно быть. Причина, по которой я показал вам это, заключается в том, что если вы выполняете команду TRACERT к сайту, вы не должны думать, что процесс был неудачным только потому, что узел назначения не был определен по названию.
В этой части я показал вам, как расшифровывать результаты использования команды TRACERT. В следующей части я покажу вам, как использовать команду Route для просмотра таблиц маршрутизации машины.
www.windowsnetworking.com