Превышен интервал ожидания для запроса tracert что значит
Для системного администратора
—>
Notice: Undefined variable: t in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15
Notice: Undefined variable: r in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15
Рекомендую: Фриланс-биржа | Кэшбэк-сервис | Интернет-бухгалтерия
Решение проблем с соединениями в сетях Windows (часть 5)
В предыдущей части этой серии статей, я говорил, что команду TRACERT можно использовать для диагностирования проблем подключения между локальным узлом и узлами удаленной сети. В той части я показал вам, как использовать основную команду TRACERT, поэтому в этой части я продолжу разговор о ней и объясню, как расшифровывать результаты этой команды.
В целях демонстрации я выполнил команду TRACERT для www.espn.com. Единственной причиной, по которой я выбрал данный конкретный сайт, является то, что это один из тех сайтов, которые не блокируют ICMP трафик, и я знаю это наверняка. Результаты этой команды показаны ниже. Я буду ссылаться на эти результаты в течение всей оставшейся части статьи.
Если вы посмотрите на вышеприведенные данные 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 на нем, оба этих симптома присутствуют в результате:
Если вы видите результаты, подобные этим, они могут указывать на то, что возник сбой соединения, но они этого не гарантируют. Единственным способом убедиться в этом, является попытка выполнить команду TRACERT к нескольким сайтам. Следует помнить, что каждый последующий прыжок находится все дальше от вас. Чем дальше от вас находится проблема, тем сложнее будет ее определить, поскольку тестирование других сайтов может включать другие маршруты. Когда вы выполняете TRACERT для различных сайтов, вам нужно обращать внимание на маршруты, по которым проходит запрос, чтобы определить, имеет ли место сбой в соединении.
Последняя часть информации, отображаемая в каждом ряду, – это данные о маршрутизаторе или узле, который ответил на ICMP запрос. TRACERT будет определять каждый узел или маршрутизатор по названию, когда это возможно, но вы не всегда будете получать полное разрешение имени. Например, если посмотреть на вышеприведенные результаты, видно, что половина маршрутизаторов определена по названию, а вторая половина нет. Это, как правило, не является проблемой.
Самое интересное то, что узел, для которого вы выполняете трассировку маршрута, не всегда будет определяться. Например, если взглянуть на самое начало первого примера, вы заметите, что мы ввели команду TRACERT WWW.ESPN.COM. Сразу же после этого TRACERT разрешила название www.espn.com в IP адрес 199.181.132.250. Но если вы посмотрите в самый конец этого примера, то обратите внимание на то, что TRACERT постепенно достигает места назначения, но не определяет место назначения по названию (по крайней мере, не в этом случае).
Такое поведение не является проблематичным, поскольку так и должно быть. Причина, по которой я показал вам это, заключается в том, что если вы выполняете команду TRACERT к сайту, вы не должны думать, что процесс был неудачным только потому, что узел назначения не был определен по названию.
Заключение
В этой части я показал вам, как расшифровывать результаты использования команды TRACERT. В следующей части я покажу вам, как использовать команду Route для просмотра таблиц маршрутизации машины.
Автор: Брайн Позей (Brien Posey)
Постовой
Скоро для IT-специалистов Воронежа откроется отличный ресурс для поиска работы. В Воронеже работа на дому найдется теперь легко и просто.
Создание и продвижение сайтов в Челябинске. Теперь это просто и доступно всем. Отлтчные специалисты займутся вашим сайтом
Превышен интервал ожидания для запроса tracert что значит
Как выявить, на чьей стороне (вашей или провайдера) проблемы со связью:
Это одно из первых действий, которое вам порекомендуют в техподдержке интернет-провайдера. Действительно, отдельные компоненты ОС Windows (службы, драйверы) могут подвисать, никак об этом не сообщая пользователю. Кстати, и аппаратные компоненты точно так же могут сбойнуть, а для возврата в первоначальное (рабочее) состояние им потребуется аппаратный сброс, который и произойдет в процессе перезапуска компьютера. Если вы подсоединены к Интернету напрямую кабелем провайдера, то переподключитесь к сети с обновлением параметров. Самый чистый вариант — отключение ПК на время не дольше полуминуты. После включения все нестабильные состояния оборудования, как правило, устраняются.
Не помогло? Переходим к следующему шагу.
Если вы подключаете свой компьютер к Интернету через роутер, даже не проверяйте его состояние и не пытайтесь разобраться в состоянии индикаторов. Перезапустите его — ведь сетевые устройства могут зависнуть или сбойнуть точно так же, как и ПК. Кроме того, не все устройства корректно отрабатывают изменения в состоянии сетевого соединения: при обновлении сетевых настроек со стороны провайдера роутер мог не отреагировать автоматически. Перезагружаем его, выключив питание (на 10 секунд), затем снова включаем и проверяем состояние. После этого может понадобиться перезагрузить и компьютер.
Если не помогло — переходим к следующему шагу.
Предположим, что проблема все-таки в вашем компьютере. Единственный способ проверить это — подключиться с другого устройства: подойдет второй ПК, ноутбук, планшет с портом локальной сети. Если вам удается с него подключиться, значит, придется разбираться с вашим компьютером, если нет — переходим к следующему шагу и пускаем в ход «тяжелую артиллерию».
В данном случае тяжелой артиллерией я называю «админские» методы. Для того чтобы ими воспользоваться, не нужно иметь специальных знаний, но представление о происходящем они могут дать вполне точное. Не понадобится и специализированный софт — сгодятся встроенные в ОС утилиты.
Если вы не хотите связываться с консольными утилитами, используйте программу с наглядным графическим интерфейсом, более удобным в ряде случаев. Самая распространенная из них, успешно заменяющая и ping, и tracert, — WinMTR (нажимаем кнопку Download). У нее свои достоинства: маленькая, не требует инсталляции и при этом позволяет легко получить информацию о состоянии канала, а также сбросить отчет в файл нажатием всего одной кнопки. Данная информация важна не только вам — она может пригодиться службе техподдержки. Ведь при использовании консольных команд результаты их работы придется вручную переносить в текстовый файл, а это не самое простое и быстрое занятие.
Запустив WinMTR, достаточно ввести искомый адрес и нажать кнопку «Старт» — она сразу же начнет трассировать маршрут, а затем высветит его в нижнем окне, после чего будет циклически выполнять опрос всех узлов, накапливая статистику до нажатия кнопки «Стоп». В то время можно просмотреть информацию по каждому из серверов, два раза кликнув по его названию мышью.
Как расшифровать показатели пинга и трассировки маршрута
Если использовать для проверки ресурс ya.ru (из-за простоты написания), то команда ping будет выглядеть так:
а ее выполнение продемонстрирует нечто подобное:
В первой строке видно, что запрос к DNS-серверу прошел успешно: утилита получила адрес сервера. Кстати, его не помешает записать на будущее — поможет в другой ситуации выяснить, что не работает: DNS-сервер или вся сеть. Если при наборе ya.ru в адресной строке браузера ничего не происходит или появляется сообщение о невозможности отобразить страницу, вводим адрес 213.180.193.3. Получили доступ к сайту — виновен отказавший DNS, нет — значит, недоступна сеть целиком. Впрочем, задав команде ping в качестве параметра IP-адрес и получив сообщение «Превышен интервал ожидания для запроса», можно прийти к аналогичному выводу.
Следующие строки показывают результат выполнения запроса, причем главное для нашего случая — значение параметра «время» в миллисекундах. Любое число ниже 120 мс можно считать нормальным результатом, хотя, конечно же, чем оно меньше — тем лучше. Когда параметр превышает 200 мс, начинаются притормаживания в онлайн-играх, после 500 мс появляется дискомфорт при работе с веб-страницами.
Еще хуже, если время пинга скачет и появляются сообщения о недоступности пингуемого хоста:
Ответ от 213.180.193.3: число байт=32 время=134 мс TTL=55
Ответ от 213.180.193.3: число байт=32 время=126 мс TTL=55
Ответ от 213.180.193.3: число байт=32 время=2100 мс TTL=55
Превышен интервал ожидания для запроса.
Ответ от 213.180.193.3: число байт=32 время=1982 мс TTL=55
Ответ от 213.180.193.3: число байт=32 время=367 мс TTL=55
При таком качестве связи не то что в любимую игру поиграть, серфинг в Интернете превращается в пытку: страницы грузятся безобразно медленно, изображения недогружаются, создается ощущение, что компьютер безбожно тормозит. Это недалеко от истины: он тратит избыточное количество времени на повторные пересылки утерянных пакетов данных, приостанавливая остальные задачи. Виной тому может быть как роутер или поврежденный кабель внутри квартиры/в парадном, так и проблемы у провайдера.
Для того чтобы окончательно разобраться, запускаем tracert ya.ru
Здесь расклад другой: сперва видим время задержки, после него — доменное имя или адрес сервера. Количество может быть разным, но начало всегда одинаково: первым в списке будет ваш модем, роутер или компьютер (зависит от способа подключения к провайдеру), вторым — оборудование провайдера. Дальше может быть или несколько узлов провайдера, или сразу «большая сеть».
Некоторые из узлов вообще могут не отвечать (в моем примере — № 9), но ошибки здесь нет, ему просто запрещено это делать. Это не проблема, если удалось добраться до конечного узла и время на нем не превышает значения, полученного при помощи команды ping.
Как могут выглядеть ошибки? Самая простая — получение в первой строке сообщения:
1 * * * Превышен интервал ожидания для запроса.
В этом случае, скорее всего, утрачена связь с вашим шлюзом. А значит, проблема на вашей стороне.
Следующая ситуация:
1 Как включить команду ping в Windows 7
По умолчанию брандмауэр Windows 7 блокирует входящие эхо-сообщения, поэтому комманда ping не будет работать корректно. Для решения проблемы надо проделать следующее:
Превышен интервал ожидания для запроса tracert что значит
Posted via ActualForum NNTP Server 1.4
 Re: ��������� ��������� ����������� [new] | |||
| sanich Member ������: Rostov-On-Don |
— | ||
| 18 ��� 08, 20:12����[5680007] �������� | ���������� �������� ���������� | |||
| Re: ��������� ��������� ����������� [new] | |
| weber Member Tracing route to premium2.kamikkadzetv.ru [31.184.193.88] over a maximum of 20 hops 1 1ms 1ms * Request timed out. Превышен интервал ожидания для запроса tracert что значит
Трассировка маршрута к 1 150 ms 110 ms 120 ms max1.eurocom.od.ua [212.15.130.2] 5 120 ms 150 ms 120 ms atm2.0.1-lsr1.kyiv.unn.utel.ua [212.113.63.1] 10 310 ms 331 ms 370 ms lndnuk1icx1.wcg.net [195.66.224.105] | |
PS: не уверен что сюда, если что перенесите куда-нибудь.
Advanced Member
15 340 мс 351 мс * atlnga6lce1-pos5-0.wcg.net [64.200.127.62]
16 311 мс 330 мс 301 мс atlnga6lce1-cuttingedge-atm.wcg.net [64.200.126.70]
17 270 мс 280 мс 301 мс gige.williams-atl.dv2.net [209.51.130.33]
18 350 мс 331 мс 310 мс 209.51.153.146
Silver Member
с другим timeoutом данные примерно теже.
В чём вообще может быть причиа того что данные «пропадают».
При этом если учесть что с одного компьютера без проблем заходит на тот сайт.
С другого (в другой стране находиться), всё ок.
Браузер(IE) сообщает примерно следующее:
Веб сервер найден, ждём ответа.
после этого: Страница не может быть доставленна.
Member
Если у тебя радио канал то может быть его кто начал глушить. у меня было такое. может что то с демоном ДНС. какая операциока хоть. канал какой и т.д.
| ||||
| ||||
|
