---
codigo: DOC-TEL-RED-DIA-004
tipo: conhecimento
dominio: Telecom
area: Redes
trilha: Diagnóstico de Redes
nivel_tecnico: Avançado
tempo_medio: 15-25 min
status: validado
---

# MTR

## Objetivo e funcionamento

MTR repete sondas com TTL crescente e atualiza estatísticas por salto. O modo interativo ajuda a observar mudanças; o modo relatório preserva evidência reproduzível. Pode usar ICMP, UDP ou TCP, conforme versão e privilégios.

```bash
mtr destino
mtr --no-dns destino
mtr --report --report-cycles 100 --no-dns destino
mtr --report-wide --report-cycles 200 destino
mtr --icmp destino
mtr --udp destino
mtr --tcp --port 443 destino
mtr -4 destino
mtr -6 destino
```

Confirme `mtr --help`: nomes de opções variam. No modo interativo, `d` alterna exibição e `q` sai em versões comuns. Para Windows, o WinMTR oferece coleta ICMP e exportação; registre versão, contagem e texto/HTML gerado, pois ele não equivale a todos os modos do MTR.

## Colunas

| Campo | Interpretação |
|---|---|
| Loss% | sondas sem resposta daquele salto; não é automaticamente perda encaminhada |
| Snt | número de sondas enviadas |
| Last | RTT da última resposta |
| Avg | média dos RTTs recebidos |
| Best | menor RTT observado |
| Wrst | maior RTT observado |
| StDev | dispersão dos RTTs recebidos |

Uma média baixa com `Wrst` alto pode refletir evento episódico; StDev alto sugere variabilidade, mas também pode ser ICMP de baixa prioridade. Perdas intermediárias que desaparecem nos saltos seguintes não provam descarte de tráfego encaminhado. Procure degradação persistente até o destino e compare com a aplicação.

## Procedimento operacional

1. Defina sintoma, destino real, origem/interface e família IP.
2. Use `--no-dns` para não misturar atrasos de resolução.
3. Escolha ICMP e, quando pertinente, TCP na porta do serviço.
4. Colete ciclos suficientes para cobrir o evento, sem adotar duração universal; documente início/fim e carga.
5. Exporte o relatório e repita de cliente, PoP e outra origem autorizada.
6. Compare rotas, BGP/OSPF, filas, interfaces e monitoramento no mesmo relógio.

Em rádio, móvel, fibra ou Internet distante, linhas de base diferem. Congestionamento, filas, destino, MPLS, CGNAT, túneis, VPN, ECMP e assimetria afetam a leitura.

## Cenários e critérios

- perda só em salto intermediário: provável rate limiting; não escale sem efeito fim a fim;
- perda começa e persiste: investigue enlace/filas a partir dali, considerando retorno assimétrico;
- rota muda no relatório: repita e consulte convergência/política;
- ICMP perde e TCP/443 não: política ou tratamento de ICMP é hipótese forte;
- apenas uma origem falha: delimite acesso, CPE, VLAN, BNG ou saída específica.

Avance para TCPDump/Wireshark quando precisar observar retransmissões, flags, DNS ou tráfego sem retorno. Registre comando, versão, origem, destino resolvido, ciclos, modo, relatório bruto, horário/timezone, rota e contexto de carga.

## Limitações e erros comuns

MTR não mostra a rota de retorno, pode alternar caminhos balanceados e não mede diretamente a experiência da aplicação. Não compare relatórios com destinos, períodos ou modos distintos como equivalentes; não use um limiar fixo de perda/latência para toda tecnologia; não atribua falha ao primeiro nó que limita respostas.

## Conclusão

MTR é forte para tendência e comparação entre origens. A conclusão continua dependendo de propagação fim a fim e correlação operacional.

## Documentos Relacionados

- [Teste de Ping](./01 - Teste de Ping.md)
- [Traceroute e Tracert](./02 - Traceroute e Tracert.md)
- [Pathping](./03 - Pathping.md)
- [TCPDump](./10 - TCPDump.md)
- [Captura de Pacotes](./12 - Captura de Pacotes.md)
- [Fluxo de Diagnóstico de Conectividade](./13 - Fluxo de Diagnóstico de Conectividade.md)
- [BGP](../Roteamento/04 - BGP.md)
- [OSPF](../Roteamento/03 - OSPF.md)