Назад | Перейти на главную страницу

Как работает mtr / интерпретация болевых точек с помощью mtr

Я недавно пробовал mtr чтобы узнать о проблемах с перегрузкой сети. Ниже приведены образцы mtr Запросы

Пример 1

$ mtr --report -c 10 my.example.com 

HOST: ansh0l-Lenovo               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1                0.0%    10    1.3   5.2   1.3  22.4   8.0
  2.|-- 10.10.20.1                 0.0%    10    3.9   2.5   1.6   4.6   1.2
  3.|-- NSG-Static-*.*.*.*        10.0%    10    7.7   6.7   5.1  10.1   1.5
  4.|-- AES-Static-*.*.*.*        10.0%    10   46.3  48.5  46.2  53.8   2.6
  5.|-- s38895.sgw.equinix.com     0.0%    10   50.3  47.9  46.1  50.3   1.5
  6.|-- 203.83.223.2               0.0%    10   49.0  48.7  47.0  51.1   1.2
  7.|-- 203.83.223.23              0.0%    10   47.8  48.1  46.9  50.0   1.0
  8.|-- ec2-175-*-*-*.ap-sou       0.0%    10   47.7  49.0  47.6  55.8   2.5
  9.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

Пример 2

$ mtr --report -c 100 my.example.com 
HOST: ansh0l-Lenovo               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1                2.0%   100    5.5   3.2   1.2  94.6   9.8
  2.|-- 10.10.20.1                 3.0%   100    4.3   3.9   1.5 160.5  16.3
  3.|-- NSG-Static-*.*.*.*         3.0%   100    9.9   8.1   4.3  99.0   9.8
  4.|-- AES-Static-*.*.*.*         3.0%   100   48.6  48.9  45.9 137.0   9.4
  5.|-- s38895.sgw.equinix.com     5.0%   100   46.7  49.6  45.5 155.6  11.5
  6.|-- 203.83.223.2               2.0%   100   52.4  53.0  46.5 213.3  20.8
  7.|-- 203.83.223.23              4.0%   100   49.1  50.0  46.2 145.6  11.5
  8.|-- ec2-175-*-*-*.ap-sou       5.0%   100   49.3  50.8  46.4 169.6  12.8
  9.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

Вопросы:

  1. Отбрасывается ли пакет на HOST n = Сумма отбрасывания пакетов для пакетов, отправленных исключительно для HOST n? Насколько безопасно предположить, что пакеты, отправленные для HOST 7, будут иметь те же предыдущие переходы?

  2. В примере 1 на HOST 3 и 4 потеря пакетов одинакова (10%). Можно ли предположить, что вся потеря пакетов произошла на узле 3?

  3. В примере 1. При потере пакетов на ХОСТЕ 4 на 10%, не должны ли следующие прыжки также пострадать с точки зрения производительности? Если у меня есть 10% потери пакетов в одном из промежуточных узлов, узлы после него также должны испытывать некоторую потерю пакетов, верно?

  4. В примере 2 у некоторых узлов выше StDev. Следует ли их интерпретировать как точки ненадежности?

1) Отбрасывается ли пакет на HOST n = Сумма отброшенных пакетов для пакетов, отправленных исключительно для HOST n?

Да, они созданы специально для этого хоста. MTR полагается на отправку пакета с фиксированным TTL и ожидает получить ответ ICMP «время истекло» на первоначально отправленное эхо ICMP, которое будет исходить от маршрутизатора, время жизни которого превышено.

Насколько безопасно предположить, что пакеты, отправленные для HOST 7, будут иметь те же предыдущие переходы?

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

2) В Примере 1, на ХОСТЕ 3 и 4 потеря пакетов одинакова (10%). Можно ли предположить, что вся потеря пакетов произошла на узле 3?

Нет, наверное, нет. Можно было бы ожидать, что после этого будет производная потеря для всех других переходов (так что потеря около 10% на переходах 5, 6, 7, 8 и 9), если это был случай, когда узел 3 действительно отбрасывал пересылаемые пакеты.

3) В примере 1. Когда происходит потеря пакетов на HOST 4 на 10%, не должны ли следующие прыжки также влиять на производительность? Если у меня есть 10% потери пакетов в одном из промежуточных узлов, узлы после него также должны испытывать некоторую потерю пакетов, верно?

Да, если вы получаете реальную потерю пакетов. К сожалению, все гораздо сложнее.

4) В примере 2 некоторые узлы имеют более высокое значение StDev. Следует ли их интерпретировать как точки ненадежности?

mtr может дать вам только приблизительную цифру. Многие маршрутизаторы будут отбрасывать ICMP-пакеты в рамках режима качества обслуживания (icmp менее важен для него, чем трафик TCP / UDP). Другие могут задерживать трафик или делать то и другое.

Все, что вы действительно можете сказать, это то, что отправка ICMP-трафика, на который должен отвечать этот маршрутизатор, может привести к ненадежной производительности, но вы не можете сказать, что то же самое верно и для других типов трафика, таких как TCP.

Подводя итог, если у вас есть реальная потеря пакетов в конкретный пункт назначения, вызванная промежуточным переходом маршрутизатора, вы увидите <= loss% на всех последующих этапах.

Если ваш целевой переход отвечает с потерей 0%, вы не отбрасываете пакеты.

Некоторые маршрутизаторы намеренно отбрасывают ICMP-трафик, за ответ на который они отвечают, поэтому вы можете получить «дополнительную потерю», ограниченную только этим переходом. Если этот переход - ОБА выполняет некоторую форму формирования трафика И действительно теряет трафик, все становится ужасно запутанным, потому что вы не можете сказать, сколько у вас действительно потерь. Вместо этого лучшее, что вы можете сделать, - это взять наименьший процент потерь от будущего хмеля и заявить, что он, вероятно, составляет примерно тот процент потерь, который вы видите.

Короче говоря, маршрутизаторы уделяют обработке трафика более высокий приоритет, чем ответ на пакеты с 0 ttl. Такие инструменты, как mtr и traceroute, полезны для определения пути, который вы используете. Они бесполезны для определения производительности этого пути. Я подробно остановился на этом в своем ответе на Какая задержка в сети «типична» для восточно-западного побережья США?