Трассировка не проходит дальше роутера
Решение проблем с соединениями в сетях Windows (часть 5)
В предыдущей части этой серии статей, я говорил, что команду TRACERT можно использовать для диагностирования проблем подключения между локальным узлом и узлами удаленной сети. В той части я показал вам, как использовать основную команду TRACERT, поэтому в этой части я продолжу разговор о ней и объясню, как расшифровывать результаты этой команды.
Если вы посмотрите на вышеприведенные данные TRACERT, то заметите, что каждая строка результатов содержит несколько различных частей информации. Первая часть информации, расположенная с левой стороны показывает номер прыжка. Как я объяснял в предыдущей части, TRACERT работает путем отправки запроса ping на указанный хост. Изначально TTL значение запроса установлено на 1. Это обеспечивает сбой запроса после первого прыжка. Информация о прыжке предоставляется, после чего ICMP запрос передается снова, но на этот раз его TTL значение установлено на 2. Этот процесс повторяется снова и снова, каждый раз увеличивая TTL значение на 1 до тех пор, пока указанный узел не будет достигнут. Благодаря этому команда TRACERT способна давать информацию о том, сколько прыжков запросу пришлось сделать, чтобы достичь удаленного узла. Если вы посмотрите на данные выше, вы увидите, что последняя цифра в левом ряду будет 20. Это означает, что запросу потребовалось выполнить 20 прыжков, чтобы достичь указанного узла.
Следующие три части информации в каждой строке отображают количество времени, которое потребовалось, чтобы достичь маршрутизатора или узла, на который ссылается конкретная строка. Если вы просмотрите список, то заметите, что время соединения, как правило, увеличивается с каждым прыжком. Вам нужно знать две вещи об этом времени.
Во-первых, отображаются три различных временных промежутка для каждого прыжка. Как я уже говорил, трассировка маршрута основана на концепции отправки нескольких ICMP запросов. Когда мы работали с командой ping, вы видели, что она всегда возвращалась с различными значениями, как способом измерения потери пакетов. Эта же концепция применима и для трассировки маршрута, за исключением того, что длительность времени, необходимая запросу, измеряется три раза, а не четыре.
Второе, что вам нужно знать о времени ответа, это то, что звездочки указывают на то, что время запроса вышло. Это может указывать на проблему, а может и не указывать, в зависимости от того, как появляются звездочки. Если вы посмотрите на прыжок номер 19, то увидите, что все три времени ответа представлены звездочками. Когда вы видите три звездочки подряд, это обычно означает, что устройство, которое опрашивается во время прыжка, имеет файервол, настроенный на блокирование ICMP пакетов, что вызывает таймаут таймеров, а в последнем столбце будет надпись «Превышен интервал ожидания для запроса».
Следует учитывать, что, хотя это самый распространенный случай, он не единственный. Трассировка маршрута также выдает три звездочки, когда нужное устройство недоступно. Конечно, здесь возникает вопрос, как отличить сайт, блокирующий ICMP пакеты, от сбоя в соединении? На самом деле это может быть довольно сложным делом.
Если вы видите результаты, подобные этим, они могут указывать на то, что возник сбой соединения, но они этого не гарантируют. Единственным способом убедиться в этом, является попытка выполнить команду TRACERT к нескольким сайтам. Следует помнить, что каждый последующий прыжок находится все дальше от вас. Чем дальше от вас находится проблема, тем сложнее будет ее определить, поскольку тестирование других сайтов может включать другие маршруты. Когда вы выполняете TRACERT для различных сайтов, вам нужно обращать внимание на маршруты, по которым проходит запрос, чтобы определить, имеет ли место сбой в соединении.
Такое поведение не является проблематичным, поскольку так и должно быть. Причина, по которой я показал вам это, заключается в том, что если вы выполняете команду TRACERT к сайту, вы не должны думать, что процесс был неудачным только потому, что узел назначения не был определен по названию.
Заключение
В этой части я показал вам, как расшифровывать результаты использования команды TRACERT. В следующей части я покажу вам, как использовать команду Route для просмотра таблиц маршрутизации машины.
Автор: Брайн Позей (Brien Posey)
Постовой
Скоро для IT-специалистов Воронежа откроется отличный ресурс для поиска работы. В Воронеже работа на дому найдется теперь легко и просто.
Создание и продвижение сайтов в Челябинске. Теперь это просто и доступно всем. Отлтчные специалисты займутся вашим сайтом
Перед тем, как обращаться к провайдеру, необходимо разобраться - а всё ли хорошо в доме. Без этой проверки есть риск превратиться в мальчика, который постоянно кричал "у меня потери пакетов" "волки".
Моральное устаревание диагностических инструментов
В современном мире диагностика, увы не очень показательна. Во-первых, потому, что она базируется на протоколах 40-летней давности (RFC 792 - от 1981-го года) и превращается в лупу в эпоху электронных микроскопов. А во-вторых, у этих протоколов есть большие проблемы в части безопасности. Если какой-то маршрутизатор полностью отвечает RFC 792, то его можно элементарно атаковать с помощью DDoS атаки (чем хакеры в нулевых и баловались). Поэтому, даже эти протоколы работают плохо благодаря закрученным гайкам.
Прямым следствием этих ограничений является типичный сценарий решения сетевых проблем:
Пользователь обращается к провайдеру и говорит, что с сайтом А у него проблемы и плохая связь. Провайдер обычно всегда говорит: у нас всё хорошо, проблемы у сайта.
Когда пользователь обращается в поддержку сайта, то ему там говорят то же самое – у нас всё хорошо, обратитесь к провайдеру.
В итоге, проблема конечно же не решается.
Ниже мы всё-таки попробуем определиться, где именно проблема.
К сожалению для статьи, и к счастью для автора, у автора всё в порядке с интернетом. Потому, примеров «смотрите – слева всё плохо, а справа всё хорошо» практически не будет. Но, где возможно – я всё-таки попробую что-нибудь сломать для наглядности.
Маршруты интернета
В первой части статьи я рассказывал, что трафик ходит по маршрутам. Их два : BGP и IP. Один поверх другого. BGP - определяет маршрут через физические маршрутизаторы, а IP - уже логическая составляющая пути. На этом этапе диагностика затруднена тем, что :
Вводная по BGP это TTTLDR.
Благодаря таким технологиям, как AnyCast, IP 11.22.33.44 на маршруте может физически находиться в любом месте, и в двух+ местах одновременно : AnyCast позволяет указать, что за этот IP отвечает сервер в Нью-Йорке и в Москве. При пинге этого IP вы не можете однозначно утверждать, что вы пингуете именно Московский сервер.
Так же есть MPLS и иное туннелирование. Разобрать маршруты тоннелей, простыми инструментами не получится.
Пакет "туда" и пакет "обратно" может пойти разными путями.
Пакет "туда" может пойти по нескольким путям в разное время. Инструментов для диагностики ECMP на домашних OS немного, они сложнее простого tracert, а иногда, стоят дорого.
Будем работать с тем что есть. А есть у нас команда traceroute.
На windows она выполняется из Пуск/cmd и ввести tracert. Так же есть графическая утилита WinMTR. Она дает больше полезной информации и, в некоторых случаях, будем пользоваться ей.
Можно не запускать cmd и там выполнять команды, а делать это windows-style:
Пуск/выполнить cmd /k tracert -d что-нибудь
Ключевые правила диагностики:
Если вы не можете продемонстрировать и повторить проблему, то никто не сможет.
Данные нужно собирать за несколько временных периодов – как минимум, за период, когда проблем нет, и за период, когда проблемы есть.
Как быстро определить, что всё приемлемо
Автор использует универсальную метрику «Пинг на 1000 километров». Он считается следующим образом:
Определяете, где находится сервер.
На Яндекс.картах измеряете расстояние от вас до сервера.
Выполняете команду ping до нужного вам хоста. Если получается не больше, чем 20 миллисекунд на 1000 километров, то у вас с инпут-лагом не должно быть никаких проблем.
Автор находится в
1000 км от Москвы. Его пинги выглядят следующим образом:
На расстояниях до 200 км данное правило, кстати, не будет выполняться, ввиду того, что скорость работы оборудования вносит бОльшую лепту. На таких расстояниях пинг должен быть в рамках 5-6 миллисекунд. Если больше – у вас проблема.
Как читать PING
Соединение до домашнего роутера
1 1 ms 1 ms <1 ms 192.168.88.1
Первый IP адрес в результатах tracert скорее всего и будет IP-адресом вашего роутера.
Так же можно сделать вывод, что автор любитель Mikrotik.
Пинг, обычно, отправляет пакеты размером 64 байта, что показывает скорее физические качества канала– нет ли плохого кабеля по пути.
Как уже говорилось ранее – диагностика работает только в сравнении. Ниже - два примера пинга.
С сервера, который подключен к роутеру кабелем.
А это с компьютера, который подключен к той же сети, но по wi-fi.
Какие выводы можно здесь сделать:
WIFI вносит свою лепту. Во-первых, у нас появился Джиттер (видим, что время пинга скачет). Во-вторых, пинг стал немного хуже.
И вот подтверждение моих слов - тест участка компьютер-домашний роутер.
Пакеты, даже не выходя в интернет, иногда проходят плохо. Без потерь, но задержки присутствуют.
Чтоб запустить "длинный ping" - необходимо ввести команду ping -t . В этом случае ping будет продолжаться пока вы не нажмете Control+C
Видим, что при приеме больших объемов информации скорость падает существенно меньше, чем при передаче.
Одна из причин – мощность антенны в точке доступа выше, чем у ноутбука. Ноутбук работает на аккумуляторе и не подключен к сети. Аккумулятор - почти севший и windows находится в режиме «Best battery life»
Вот тот же самый тест, но с подключенным блоком питания.
Видно, что прием стал гораздо лучше, и передача тоже улучшилась. 200мс пинг при передаче отсутствует.
Что в этой ситуации можно настроить:
Мощность передатчика на точке доступа.
Мощность передатчика на ноутбуке.
В первых тестах мощность передатчика ноутбука была выкручена на максимум. Ниже – выкручена на минимум:
Как видно, появились потери, и пинг стал гораздо хуже, даже при работе от блока питания.
Стоит помнить, что Wi-Fi это диалог. Если точка доступа «кричит», а компьютер «шепчет», то точка может плохо слышать компьютер, хотя палочки будут показывать, что всё хорошо.
Если вы везде выставите мощность на максимум, то могут начать страдать ваш Smart TV и телефон, подключенный к той же сети – компьютер будет их «перекрикивать». Ноутбук будет меньше работать от батарей. Мощность всегда нужно выбирать исходя из условий, и ставить минимальную мощность, которая дает вам приемлемый результат. Мощность с запасом ставить не рекомендуется.
Факторы, влияющие на Wi-Fi
Здесь опустим исключительно программные факторы вроде beacons, размеры пакетов, 80 мегагерц и прочее – про них можно написать еще десяток страниц. Приведу только ключевые физические факторы и факторы окружения.
Частоты : «2.4» в городах – всегда хуже 5 гигагерц. При возможности выбирайте 5.
При выборе канала – проведите анализ спектра, когда «соседи дома». Точки обычно позволяют сканировать эфир. Выберите канал, который не занят и у которого меньше всего соседей. При выборе канала старайтесь выбирать как можно меньший канал. 5-й канал бьет «дальше», чем 159-й.
Ищем частоту, вокруг которой либо самая слабая передача - Signal Quality самый плохой, либо вообще на этой частоте ничего нет.
У ноутбуков антенна встроена в экран. Антенна точки и устройства должны находиться в одной плоскости. Если у вас экран стоит вертикально, то и антенны на роутере должны стоять вертикально, а не так, как обычно показывается на рекламных материалах:
Плохая ориентация антенн :
Правильная ориентация антенн.
Вокруг и над антенной, в радиусе 40-50 сантиметров по горизонту НЕ ДОЛЖНО быть металла и стен. Т.е. – на столе/полке роутер ставить – неизбежное зло, с которым придется смириться. А вот возле стены – плохо. Популярные гипсокартонные стены содержат в себе металлические направляющие каждые 40 сантиметров.
Работающие микроволновки – злейшие враги Wi-Fi в тот момент, когда в них готовят.
Конспект
Найти IP-адрес домашнего роутера.
Запустить длинный пинг до роутера. Замерить потери и скорость.
Запустить спидтест и параллельно длинный пинг.
Сравнить результаты. Если ухудшения показателей пинга нет, то у вас соединение до роутера - быстрее чем канал в интернет, и в целом, дома всё хорошо.
Выбрать частоту и незанятый канал.
По возможности, убрать точку от стен.
Правильно ориентировать антенны. Кстати, запустив длинный "пинг", и покрутив антенны - можно найти оптимальный вариант, но не забывайте, что цифры достоверные только когда вы НЕ КАСАЕТЕСЬ антенн.
Выбрать минимальную мощность передатчика, дающую максимальную скорость в локальной сети.
Как выявить, на чьей стороне (вашей или провайдера) проблемы со связью:
-
Шаг 1. Проверка на вирус
Даже если у вас установлен хороший антивирусный пакет с самыми свежими базами — не обольщайтесь. Его наличие не является стопроцентной гарантией защиты от заражения. Подцепить хитрый троян, руткит или другой вредоносный код проще простого. Внедрившись в систему, опасное ПО может не только затормозить ее, но и загрузить из Интернета выводок других не менее пагубных программ. А когда антивирус подаст сигнал тревоги, среагировав на одну из них, в системе уже «поселится» целый зоопарк — и будет невозможно что-либо сделать.
Поэтому при любых признаках непривычного поведения ПК надо сразу произвести проверку, но не тем антивирусом, который у вас установлен, а бесплатной сторонней утилитой. Самый простой способ — воспользоваться Dr. Web CureIT!, загрузив ее с официального сайта. Инструкцию по применению, кстати, чрезвычайно простую, прочитайте [ТУТ - пункт Чистка компьютера от вирусов].
Впрочем, если после первой же антивирусной проверки ничего не выявлено и состояние не изменилось — переходим к следующему шагу.
Это одно из первых действий, которое вам порекомендуют в техподдержке интернет-провайдера. Действительно, отдельные компоненты ОС Windows (службы, драйверы) могут подвисать, никак об этом не сообщая пользователю. Кстати, и аппаратные компоненты точно так же могут сбойнуть, а для возврата в первоначальное (рабочее) состояние им потребуется аппаратный сброс, который и произойдет в процессе перезапуска компьютера. Если вы подсоединены к Интернету напрямую кабелем провайдера, то переподключитесь к сети с обновлением параметров. Самый чистый вариант — отключение ПК на время не дольше полуминуты. После включения все нестабильные состояния оборудования, как правило, устраняются.
Не помогло? Переходим к следующему шагу.
Если вы подключаете свой компьютер к Интернету через роутер, даже не проверяйте его состояние и не пытайтесь разобраться в состоянии индикаторов. Перезапустите его — ведь сетевые устройства могут зависнуть или сбойнуть точно так же, как и ПК. Кроме того, не все устройства корректно отрабатывают изменения в состоянии сетевого соединения: при обновлении сетевых настроек со стороны провайдера роутер мог не отреагировать автоматически. Перезагружаем его, выключив питание (на 10 секунд), затем снова включаем и проверяем состояние. После этого может понадобиться перезагрузить и компьютер.
Если не помогло — переходим к следующему шагу.
Предположим, что проблема все-таки в вашем компьютере. Единственный способ проверить это — подключиться с другого устройства: подойдет второй ПК, ноутбук, планшет с портом локальной сети. Если вам удается с него подключиться, значит, придется разбираться с вашим компьютером, если нет — переходим к следующему шагу и пускаем в ход «тяжелую артиллерию».
В данном случае тяжелой артиллерией я называю «админские» методы. Для того чтобы ими воспользоваться, не нужно иметь специальных знаний, но представление о происходящем они могут дать вполне точное. Не понадобится и специализированный софт — сгодятся встроенные в ОС утилиты.
Если вы не хотите связываться с консольными утилитами, используйте программу с наглядным графическим интерфейсом, более удобным в ряде случаев. Самая распространенная из них, успешно заменяющая и ping, и tracert, — WinMTR (нажимаем кнопку Download). У нее свои достоинства: маленькая, не требует инсталляции и при этом позволяет легко получить информацию о состоянии канала, а также сбросить отчет в файл нажатием всего одной кнопки. Данная информация важна не только вам — она может пригодиться службе техподдержки. Ведь при использовании консольных команд результаты их работы придется вручную переносить в текстовый файл, а это не самое простое и быстрое занятие.
Запустив WinMTR, достаточно ввести искомый адрес и нажать кнопку «Старт» — она сразу же начнет трассировать маршрут, а затем высветит его в нижнем окне, после чего будет циклически выполнять опрос всех узлов, накапливая статистику до нажатия кнопки «Стоп». В то время можно просмотреть информацию по каждому из серверов, два раза кликнув по его названию мышью.
Как расшифровать показатели пинга и трассировки маршрута
а ее выполнение продемонстрирует нечто подобное:
Ответ от 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
1 * * * Превышен интервал ожидания для запроса.
В этом случае, скорее всего, утрачена связь с вашим шлюзом. А значит, проблема на вашей стороне.
Следующая ситуация:
Как включить команду ping в Windows 7
«Ааа, помогите, все пропало!» – если ваш внутренний голос реагирует на обрыв соединения с сервером примерно так, этот материал точно для вас. :) Безусловно, со своей стороны мы каждый день делаем все возможное, чтобы ничто не мешало вашей работе в облаке, но случись форс-мажор – будем разбираться. А чтобы быстрее сориентироваться в ситуации и понять, на чьей стороне ошибка, вот вам задача-минимум – во время обрыва первым делом выполните трассировку маршрута и пинг промежуточных узлов. Как все это сделать, сейчас расскажем.
Трассировка маршрута
Во время трассировки происходит отправка пакетов данных между локальным компьютером и сервером. Это помогает проследить путь прохождения запроса к серверу и определить, на каком этапе происходит обрыв. Выполнить трассировку довольно легко.
1. Запустите команду cmd: Win+R > пропишите cmd > ОК.
2. В открывшейся командной строке введите tracert Х.Х.Х.Х (где Х.Х.Х.Х – это IP-адрес сервера или домен) и нажмите Enter.
Как видим, наши пакеты преодолели десять (их может быть как меньше, так и больше) узлов, и преодолели их успешно. В противном случае, если бы пакеты «споткнулись» на одном из узлов, на нем (и последующих за ним узлах) мы бы увидели:
* * * Превышен интервал ожидания для запроса.
Но даже в таком случае пока не время для выводов – эта запись может означать как потерю пакетов, так и то, что узел сети просто закрыт настройками безопасности. Иногда провайдеры специально настраивают узлы так, чтобы они не отвечали на трассировочные пакеты, дабы снизить нагрузку. Чтобы точно узнать, действительно ли происходит обрыв, и, если да, то где именно, нужно пропинговать каждый из узлов. При трассировке мы получили IP каждого из них, а значит, можем перейти к пингу.
Пинг промежуточных узлов
Пинг предназначен для проверки целостности и качества соединений. Выполнить его тоже несложно. При этом запустить пинг нужно ко всем промежуточным узлам в отдельных окнах. Так непосредственно в момент обрыва связи будет видно, на каком узле происходят потери пакетов и насколько продолжительны эти обрывы.
В ОС Windows по умолчанию передается только четыре пакета, чего недостаточно, если проблема проявляется кратковременно. Поэтому нужно снять это ограничение параметром -t (чтобы потом остановить обмен пакетами, нажать CTRL+C).
Теперь по порядку.
1. Запустите команду cmd: Win+R > пропишите cmd > ОК.
2. В открывшейся командной строке введите ping -t Х.Х.Х.Х (где Х.Х.Х.Х – это адрес одного из промежуточных узлов, которые мы узнали при трассировке) и нажмите Enter.
В нашем случае при трассировке мы выявили десять узлов, а значит, и пинг нужно выполнить десять раз в десяти отдельных окнах.
Полезно!
Если вам нужно постоянно отслеживать качество соединения, для Windows можно воспользоваться удобной программой PingPlotter.
Итак, пингуем – в десяти отдельных окнах командной строки вводим команды с IP-адресами узлов, которые мы выявили при трассировке. В нашем случае будут такие команды:
ping -t 10.1.1.1
ping -t 193.151.89.254
ping -t 85.195.75.129
ping -t 213.248.79.29
ping -t 62.115.139.50
ping -t 62.115.120.8
ping -t 62.115.153.215
ping -t 108.170.251.129
ping -t 66.249.94.135
ping -t 216.58.208.46
Если в каком-нибудь из окон вы с первых же секунд видите «Превышен интервал ожидания», не спешите кричать: «Попался!». Если следующие узлы пингуются нормально, значит, этот просто закрыт настройками. В нашем случае, например, предпоследний узел (66.249.94.135) сразу же говорит, что интервал превышен, но с пингом десятого узла никаких проблем нет.
Что дальше? Запустив пинг всех узлов, оставьте его включенным и занимайтесь своими делами до следующего обрыва. Как только он случится, вернитесь к окнам пинга, чтобы выявить, кто виноват и что делать.
На чьей стороне ошибка?
Итак, обрыв повторился. Но на этот раз запущенный пинг промежуточных узлов поможет «обличить» виновника. Тут все просто – с какого узла вам начало выдавать «Превышен интервал ожидания», тот и слабое звено.
Кто виноват – ясно, теперь нужно понять, что делать в конкретных ситуациях.
1. Последний узел. Если последний узел сначала пинговался нормально (некоторые Windows-машины вообще не отвечают на пинг, это задается в настройках брандмауэра)…
…а после обрыва начал показывать «Превышен интервал ожидания», обрыв происходит на вашем сервере.
В этом случае зайдите в панель управления, запустите консоль и войдите в операционную систему, чтобы разобраться, почему сервер не работает. Если окажется, что операционная система зависла, перезагрузите сервер.
2. Любые узлы, кроме последнего. В этом случае обращайтесь одновременно в техподдержку и облачного, и интернет-провайдера. При этом обязательно укажите, как изначально выглядела трассировка маршрута, и составьте перечень узлов с указанием, на каких из них пинг во время обрыва прервался, а на каких нет. Будьте внимательны, это важная информация, не ошибитесь.
3. Все узлы одновременно. Если все окна с пингом начали показывать «Превышен интервал ожидания», проблема в вашем компьютере или сети, к которой он подключен.
Бонус!
Ну, а чтобы вам было совсем уж комфортно, мы тут подобрали утилиты, с которыми можно делать трассировку и пинг промежуточных узлов одним простым движением без запуска пятнадцати различных окон.
Для ОС семейства Windows такую оптимизацию проводит утилита Winmtr. Она не нуждается в установке и готова к использованию сразу после распаковки из архива.
Распаковали, запустили, что дальше?
В поле Host укажите конечный сервер, с которым будет проверяться соединение, и нажмите Start:
В нашем примере видна трассировка маршрута и все промежуточные узлы. При этом к каждому из них направляются ICMP-пакеты, по которым можно определить качество связи.
Собственно, в этом и заключается главное преимущество утилиты – ее вывод постоянно обновляется, это позволяет собирать статистику, отслеживать средние показатели, тенденции и какие-либо изменения качества сети.
Раз мы проверяем соединение с сервером, нас интересуют столбцы Sent (отправлено пакетов) и Recv (получено пакетов). Если значения в этих столбцах не совпадают, значит, качество связи с узлом ухудшилось. Что делать? Обратиться в соответствующую техподдержку.
Столбец Loss поможет просмотреть динамику потерь в процентном соотношении.
Также утилита позволяет копировать текст в удобных форматах (.txt и .html) в буфер обмена (Copy to clipboard) или в отдельный файл (Export).
Двойной щелчок по промежуточному узлу позволит получить дополнительную информацию о нем.
Важно знать!
Для детализации проблемы специалисты техподдержки могут запросить дополнительные пинги с особыми настройками. Для этого достаточно внести их в окошке Options, которое позволит указать:
- Interval (sec) – время обновления данных в секундах.
- Max host in LRU list – максимальное количество хостов (или IP-адресов, если не активна опция Resolve names) до конечной точки.
- Ping size (bytes) – размер ICMP-пакета.
- Resolve names – возможность преобразовать IP-адрес в имя хоста.
А что же линуксоиды?
Для ОС семейства Linux утилита называется просто MTR. Если ее нет в вашей операционной системе, установить ее можно одним из следующих способов:
$ apt-get install mtr
$ yum install mtr
У MTR такой же функционал, как у Winmtr, а также схожий графический интерфейс. Запустить утилиту можно командой:
где X.X.X.X – это IP-адрес конечного сервера или имя хоста.
В данном случае интересуют следующие столбцы:
- Loss % – процент потерянных пакетов между компьютером-отправителем и промежуточными узлами.
- SNT – общее количество отправленных пакетов.
Как только где-то что-то потерялось, утилита сигнализирует нам об этом, окрашивая узел в красный цвет и подсчитывая процент потерь.
Отдельно отметим возможность запуска утилиты в текстовом (консольном) режиме. Для этого достаточно добавить опцию -t или --curses:
mtr --curses tucha.ua
Рассмотрим еще несколько важных опций MTR, которые могут быть крайне полезны в процессе диагностики сети.
Запускает режим отчета, в котором MTR обработает заданное количество циклов (определенных опцией -c), а затем отобразит статистику и автоматически завершит работу. Этот режим полезен для сбора статистики о качестве сети.
-c COUNT или --report-cycles COUNT
Позволяет задать количество циклов, после которых MTR завершит работу.
-p BYTES или --psize BYTES
Устанавливает размер пакетов в байтах.
-i SECONDS или --interval SECONDS
Задает интервал между отправляемыми пакетами.
Разрешает не использовать DNS, отображает IP-адреса узлов.
-a X.X.X.X или --address X.X.X.X
Позволяет указать адрес интерфейса компьютера, с которого будут отправляться ICMP-запросы.
Разумеется, команды в консоли дают более точный результат, поскольку фиксируют даже единичные потери пакетов (короткие обрывы), но Winmtr и MTR компактные и более удобны в использовании. А на чем остановить свой выбор, решать только вам. :)
Вот, собственно, и все, кто виноват – выяснили, что делать – тоже. :) Надеемся, материал был вам полезен, а если у вас остались дополнительные околооблачные вопросы, обращайтесь к нам за грамотной консультацией 24/7.
Читайте также: