Provavelmente, eles estão viajando pela rede de quem quer que seja seu provedor de serviços, não pela sua rede real, e você está por trás do que é chamado de NAT de Carrier Grade.
Quando executo mtr --report tokyo1.linode.com , vejo o seguinte relatório. Parece que meu tráfego está pulando dentro da minha rede local 12 vezes antes mesmo de atingir a "internet". Alguma ideia do que poderia estar causando isso e como eu poderia solucioná-lo?
Meu computador está conectado via wi-fi a um roteador, o roteador é ligado a uma conexão dsl por um soquete na parede. Não há modem entre meu roteador e a conexão na parede. Esta é a primeira vez que uso um provedor de banda larga que não precisa usar um modem, mas de alguma forma funciona.
Por favor, note que eu substituí alguns números com R e Q no relatório abaixo apenas para estar seguro.
HOST: MacBook-Pro.local Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.0.0.1 0.0% 10 0.7 0.9 0.7 1.3 0.2
2.|-- 10.84.0.1 80.0% 10 2.9 3.3 2.9 3.7 0.5
3.|-- 192.168.R.73 80.0% 10 2.1 2.7 2.1 3.2 0.8
4.|-- 192.168.R.10 80.0% 10 2.0 2.2 2.0 2.4 0.3
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- 192.168.R.209 80.0% 10 24.7 14.5 4.3 24.7 14.4
7.|-- 192.168.R.205 80.0% 10 2.3 4.3 2.3 6.2 2.7
8.|-- 192.168.R.21 80.0% 10 4.5 6.3 4.5 8.2 2.6
9.|-- 192.168.Q.158 80.0% 10 10.4 6.2 2.1 10.4 5.9
10.|-- bogon 80.0% 10 2.8 2.4 2.0 2.8 0.5
11.|-- 192.168.R.37 80.0% 10 3.8 4.4 3.8 5.0 0.8
| '|-- 192.168.R.49
12.|-- 192.168.R.37 80.0% 10 12.5 7.7 2.9 12.5 6.8
13.|-- 124.68.6.189 80.0% 10 4.3 4.7 4.3 5.1 0.5
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- 221.122.35.65 80.0% 10 2.7 8.5 2.7 14.2 8.1
... (etc)
Provavelmente, eles estão viajando pela rede de quem quer que seja seu provedor de serviços, não pela sua rede real, e você está por trás do que é chamado de NAT de Carrier Grade.
O Tracert não é uma ferramenta para testar a qualidade da conexão, é uma ferramenta para determinar o caminho entre dois pontos de extremidade. Tracert funciona enviando solicitações de eco ICMP, incrementando o TTL por um em cada salto sucessivo para determinar o caminho entre os dois pontos de extremidade. Os resultados mostram a resposta de cada salto para o pedido de eco ICMP enviado para ele, o que não é uma indicação de como esse salto está lidando com o tráfego "real" enviado através dele.
Se seus resultados estivessem realmente mostrando perda de pacotes ATRAVÉS dos saltos, cada salto sucessivo mostraria a mesma perda de pacotes ou aumentaria a perda de pacotes.
O que você vê nos saltos que mostram a perda de pacotes é como esse salto está respondendo à solicitação de eco ICMP enviada para ele, que em muitos casos é ignorada, descartada ou recebe baixa prioridade. Os roteadores estão preocupados com o tráfego real de roteamento, não respondendo ao seu tracert.
Como tal, não vejo um "problema" que deva ser corrigido.
EDITAR
Em resposta ao seu comentário:
Eu deveria ter olhado seu traço com mais cuidado. Seu rastreio mostra a perda de pacotes no segundo salto e a mesma perda de pacotes em cada salto sucessivo (os saltos que mostram 100% de perda de pacotes provavelmente estão ignorando completamente os pacotes ICMP). Isso pode ser uma indicação de um problema. Não explica porque remover o roteador parece "consertar" a perda de pacotes.
Tags networking routing linode