Como o mtr trabalha / interpreta pontos de dor usando mtr

Question

Eu tenho experimentado recentemente mtr para obter pontos problemáticos de congestionamento de rede. A seguir estão exemplos de solicitações mtr

Exemplo 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

Exemplo 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

Perguntas:

1. O pacote é descartado no HOST n = Soma de pacotes de pacotes enviados exclusivamente para o HOST n? Quão seguro é assumir que os pacotes enviados para dizer HOST 7 teriam os mesmos saltos anteriores?

2. No Exemplo 1, No HOST 3 e 4, a perda de pacotes é igual (10%). É seguro assumir que toda a perda de pacotes aconteceu no nó 3?

3. No exemplo 1. Quando há uma perda de pacotes no HOST 4 para 10%, os próximos saltos também não devem ser afetados em termos de desempenho? Se eu tiver uma perda de pacotes de 10% em um nó intermediário, os nós após ele também devem experimentar alguma perda de pacotes, certo?

4. No Exemplo 2, alguns nós possuem StDev mais alto. Estes devem ser interpretados como pontos de falta de confiabilidade?

Answer 1

1) Is Packet drops at HOST n = Sum of Packet drops for packets sent exclusively for HOST n?

Sim, eles são especificamente para esse host. O MTR depende do envio de um pacote de um TTL fixo e espera receber de volta uma resposta ICMP "excedida pelo tempo" para o eco ICMP originalmente enviado, que virá do roteador que o TTL excedeu.

How safe is it to assume, that packets sent to say HOST 7, would have had the same previous hops?

É bastante seguro, eu não posso falar por todas as redes, mas é incrivelmente incomum em uma rota inter-hop esperar que o tráfego seja roteado para vários caminhos - isso pode acontecer, mas é mais exceção do que a norma.

2) In Example1, At HOST 3 and 4, packet loss is same (10%). Is it safe to assume that all packet loss has thus happened at node 3?

Não, provavelmente não. Seria de se esperar uma perda derivada para todos os outros saltos posteriores (então, cerca de 10% de perda nos saltos 5, 6, 7, 8 e 9) se fosse o caso, o nó 3 realmente estava descartando pacotes encaminhados.

3) In Example1. When there is a packet loss at HOST 4 for 10%, shouldn't the next hops also be getting affected in terms of performance? If I have a 10% packet loss in one of the intermediate node, the nodes after it should also experience some packet loss, right?

Sim, se você estiver recebendo uma perda genuína de pacotes. As coisas são muito mais complicadas do que isso, infelizmente.

4) In Example2, some nodes have higher StDev. Should these be interpreted as points of unreliablity?

mtr pode realmente dar apenas uma estimativa. Muitos roteadores descartam pacotes ICMP como parte de um regime de qualidade de serviço (o icmp é menos importante do que o tráfego tcp / udp). Outros podem atrasar o tráfego ou fazer as duas coisas.

Tudo o que você pode realmente dizer é que enviar tráfego ICMP ao qual esse roteador deve responder pode resultar em desempenho não confiável, mas você não pode dizer que o mesmo vale para outros tipos de tráfego, como o TCP.

Para resumir, se você tiver uma perda real de pacotes para um destino específico causada por um roteador no meio do salto, você verá o < = loss% até o final dos saltos futuros.

Se o seu destino hop responder com perda de 0%, você não está descartando pacotes.

Alguns roteadores descartam deliberadamente o tráfego ICMP ao qual são responsáveis por responder, portanto, você pode obter uma 'perda adicional' confinada apenas a esse salto. Se esse salto for bom para alguma forma de modelagem de tráfego e realmente perder tráfego, as coisas ficam terrivelmente confusas porque você não pode dizer quanta perda realmente tem. Em vez disso, o melhor que você pode fazer é pegar a menor perda% de um salto futuro e declarar que provavelmente está em torno dessa% de perda que você está vendo.

    

Answer 2

Em resumo, os roteadores colocam uma prioridade mais alta no processamento de tráfego do que em responder a pacotes com 0 ttl. Ferramentas como mtr e traceroute são úteis para determinar o caminho que você está usando. Eles não são úteis para determinar o desempenho desse caminho. Fui a isso com mais detalhes na minha resposta a Quanto a latência de rede é" típica "para a costa leste-oeste dos EUA?