Para usar o traceroute de maneira afetiva, é necessário ter uma compreensão do que ele realmente faz. O Tracert é uma ferramenta de determinação de caminho. Não é uma ferramenta de análise de perda de pacotes.
O traceroute envia um pacote / datagrama (na verdade vários) para cada roteador no caminho da origem para o destino. Qualquer um ou todos esses roteadores podem ser configurados para descartar ou dar baixa prioridade a esses pacotes / datagramas direcionados a si mesmos porque um trabalho de roteador é encaminhar o tráfego real , não responder ao ping e traceroute. O que você está vendo em seus rastreamentos é que esses roteadores, mais do que provavelmente, estão fazendo exatamente isso. É possível que esses roteadores estejam descartando tráfego real , mas os roteadores subsequentes não confirmam isso porque não mostram a mesma perda de pacotes, ou maior. Se houvesse perda real de pacotes nesses roteadores, você veria algum grau de perda de pacotes em todos os roteadores subsequentes também. Caso contrário, como seria possível que um roteador descartasse 40% do tráfego fluindo sem roteadores subseqüentes, mostrando algum grau de perda de pacotes? Não é.
O único problema real que vejo em seu traceroute é seu traceroute para bing.com e isso não é um problema com seu ISP, é um problema com quem gerencia a rede msedge.net (presumivelmente a Microsoft). Agora, pode ser que eles estejam simplesmente descartando / bloqueando todo o tráfego de traceroute, ping, etc. da rede, mas eu consegui traceroute com sucesso para o bing.com, então não acho que seja o caso. De qualquer forma, eu não vejo nada em qualquer um dos seus vestígios que aponta para um problema com o seu ISP.
Para finalizar: traceroute é uma ferramenta de determinação de caminho, não uma ferramenta de análise de perda de pacotes. Se você quiser testar a perda de pacotes do caminho, você precisará usar uma ferramenta que possa testar isso, como pathping, MTR ou iperf. Veja esta nota na página da web do MTR sobre perda de pacotes:
