Устранение неполадок с подключением в сетях Windows (часть 5)

• Устранение неполадок с подключением в сетях Windows (часть 1)

• Устранение неполадок с подключением в сетях Windows (часть 2)

• Устранение неполадок с подключением в сетях Windows (часть 3)

подпишитесь на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в реальном времени

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

В демонстрационных целях я выполнил для www.espn.com. Единственная причина, по которой я выбрал именно этот сайт, заключается в том, что это один из немногих известных мне сайтов, который не блокирует ICMP-трафик. Вы можете увидеть результат маршрута трассировки ниже. Я буду ссылаться на этот вывод в остальной части статьи.

Отслеживание маршрута до www.espn.com [199.181.132.250] с использованием не более 30 переходов:

Если вы посмотрите на выше, вы заметите, что каждая строка вывода содержит несколько разных фрагментов информации. Первая часть информации, которая находится в крайней левой части каждой строки, — это номер прыжка. Как я объяснял в предыдущей статье, работает, отправляя ping-запрос на указанный хост. Первоначально значение TTL запросов установлено равным 1. Это гарантирует, что запрос не будет выполнен после первого перехода. Представляется информация о переходе, а затем запрос ICMP передается снова, но на этот раз со значением TTL, равным 2. Процесс повторяется снова и снова, каждый раз увеличивая значение TTL на 1, пока указанный хост не будет окончательно достиг. При этом может сообщить, сколько переходов должен был сделать запрос, чтобы достичь удаленного хоста. Если вы посмотрите на последнюю строку выходных данных выше, вы увидите, что она начинается с числа 20. Это потому, что для достижения указанного хоста потребовалось 20 прыжков.

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

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

Второе, что вам нужно знать о времени ответа, это то, что звездочка указывает на то, что время ожидания запроса истекло. Это может указывать или не указывать на проблему, в зависимости от того, как отображается звездочка. Если вы посмотрите на прыжок номер 19 в выходных данных выше, вы заметите, что все три значения времени отклика представлены в виде звездочек. Когда вы видите три звездочки подряд, это обычно означает, что устройство, которое пингуется на узле, имеет свой брандмауэр, настроенный на отклонение пакетов ICMP, это приведет к тайм-ауту каждого из таймеров, а в последнем столбце будут просто отображаться слова Запрос Время вышло.

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

На первый взгляд сбой канала выглядит так же, как когда маршрутизатор или хост блокирует ICMP-запросы. При возникновении сбоя вы не увидите сообщение об ошибке. Фактически процесс завершается стандартным сообщением Trace Complete.

Есть два хороших признака того, что произошел сбой соединения. Одним из признаков является то, что после определенной точки трассировки время ожидания каждого возвращаемого результата истекает. Еще одним признаком сбоя канала является то, что TRACERT проходит полные 30 переходов. Ни одно из этих условий не гарантирует, что произошел сбой канала, даже если они происходят вместе. Например, мой веб-сайт (www.brienposey.com) в данный момент работает нормально, но когда я запускаю для него TRACERT, проявляются оба этих симптома, как показано в выводе ниже:

Отслеживание маршрута до www.brienposey.com [24.235.10.4]

не более 30 переходов:

Трассировка завершена.

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

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

Что может показаться вам интересным, так это то, что хост, к которому вы отслеживаете маршрут, не всегда будет идентифицирован. Например, если вы посмотрите на самое начало первого примера вывода выше, вы заметите, что мы ввели команду Сразу же после этого преобразовал www.espn.com в IP-адрес 199.181.132.250. Если вы перейдете к концу примера вывода, вы заметите, что в конце концов достигает места назначения, но не идентифицирует место назначения по имени (по крайней мере, не в этом случае).

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

Вывод

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

• Устранение неполадок с подключением в сетях Windows (часть 1)

• Устранение неполадок с подключением в сетях Windows (часть 2)

• Устранение неполадок с подключением в сетях Windows (часть 3)

подпишитесь на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в реальном времени