Популярные статьи |
Категория “Администрирование” Использование MTR для диагностики сетиMTR – это динамическая альтернатива программе traceroute. Объединяя функции ping и traceroute, mtr позволяет постоянно опрашивать удаленный сервер и отслеживать изменения задержки и производительности с течением времени. В отличие от traceroute, в большинстве систем mtr не поставляется по умолчанию. Утилиту необходимо сперва установить. Самый простой запуск:
По умолчанию выполняется по 10 запросов. Сначала вывод может показаться похожим на traceroute; но mtr имеет существенное преимущество – ее вывод постоянно обновляется. Это позволяет собирать средние показатели, а также отслеживать тенденции и изменения производительности сети. При запуске traceroute есть вероятность, что пакеты, отправленные на каждый хоп, были переданы должным образом, даже если маршрут пострадал от потери пакетов. Утилита MTR позволяет отслеживать подобные ситуации путем сбора данных в широком диапазоне времени. Эта функция полезна при необходимости охватить более широкий спектр данных, предоставленных traceroute, не ограничиваясь реальным временем. Рекомендуется запускать утилиту на 1000 запросов. Пример: Опция -c 1000 говорит о том что посылается по 1000 пакетов.
Опция -n аналогична той что для traceroute. Да и в принципе для большинства утилит. -r (--report) режим отчета. Только в этом режиме можно задать кол-во пакетов используя опцию -c. Также этот режим позволяет записать вывод в файл:
Размер пакета задается опцией -s (--psize) в байтах. Есть возможность запуска для проверки TCP пакетами - опция -T (--tcp):
Tcp-порт задается опцией -P (--port). Таймаус задается опцией --timeout. Рассмотрим сделающий вывод:
Здесь мы видим потери пакетов между первым и вторым хопом. Это может происходить из-за лимита на частоту запросов у магистральных провайдеров. Это нормально. На конечном хопе, нашем хосте, потерь нет - 0%. Второй пример:
Здесь потери начинаются после второго хопа и держатся до последнего хопа. В этом выводе 40% потерь. На 3-5 хопах процент выше, но это может быть связано из-за ограничений частоты запросов у провайдеров. Стоит смотреть всегда следующий хоп. Некоторые потери также можно объяснить проблемами в обратном пути. Пакеты могут быть доставлены по назначению без ошибок, но с трудом выполняться обратное их прохождение. По этой причине часто лучше выполнять MTR в обоих направлениях, чтобы исключить ошибочные суждения. Третий пример:
Здесь стоит обратить внимание на летентность запросов. В силу физических ограничений, задержка всегда возрастает с увеличением числа прыжков в маршруте. Тем не менее, этот рост должен быть последовательным и линейным. К сожалению, задержка часто относительная и очень зависит от качества связи между хостами и их физическим расстоянием. К сожалению, высокая латентность не всегда означает проблемы с текущего маршрута. Отчет выше говорит о том, что, несмотря на какою-то задержку с 4-го прыжка, трафик по-прежнему достигает хост назначения и возвращения к исходному хосту. Задержка может быть вызвана проблемой с обратном путь также. В приведенном выше примере, в то время как существует большой скачок в латентности между хостами 3 и 4 латентность не увеличивается в последующих хопах. Отсюда логично предположить, что есть некоторая проблема на 4-м маршрутизаторе. Лимиты на частоту ICMP пакетов могут также проявлятся и в ланетности:
Здесь также стоит обратить внимание на 6-й хоп, где латентность в норме. MTR не всегда позволяет выяснить источник проблемы, но его вывод является помощником для сетевых администраторов при анализе проблемы. Thursday, 06 November 2014, 15:17Прочитано 43 раза Ссылка на страницу: comments powered by Disqus |
Чаще всего ищут Статистика блога |