Par défaut, MTR utilise des paquets ICMP Echo Request. Bien qu'efficace pour des diagnostics de base, cette approche se heurte rapidement aux politiques de sécurité qui filtrent ICMP. Pour un diagnostic de précision, la sélection du protocole de transport est non négociable. L'utilisation stratégique des options -u (UDP) et -t (TCP) permet de simuler un trafic applicatif légitime et de contourner les filtrages de couche 4.

Le choix du protocole dépend de la nature du service à atteindre. Le mode TCP est idéal pour les services basés sur TCP (web, SSH, etc.), car il teste le chemin exact que prendrait le trafic applicatif. Le mode UDP est pertinent pour les services comme le DNS ou le streaming en temps réel. Adapter le protocole de sondage transforme MTR d'un simple outil de détection de panne en un instrument d'analyse de la performance applicative de bout en bout.

Les paramètres par défaut de MTR, avec un intervalle d'une seconde entre les sondes (-i 1), sont souvent trop agressifs pour les infrastructures réseau modernes. Les routeurs et les commutateurs peuvent interpréter ce flux constant de paquets de sondage comme une attaque de bas niveau ou du trafic indésirable, activant des mécanismes de limitation de débit (rate-limiting) sur leur plan de contrôle. Le résultat est une perte de paquets artificielle dans le rapport MTR, masquant la véritable performance du chemin de données.

Pour obtenir des mesures fiables, il est crucial d'ajuster l'intervalle. Une approche prudente consiste à commencer avec un intervalle plus long, par exemple 5 secondes (-i 5), et à l'ajuster en fonction de la stabilité observée. Sur des liaisons très stables (fibre optique, liaisons WAN d'entreprise), des intervalles plus courts peuvent être tolérés. Sur des réseaux instables ou partagés, des intervalles plus longs minimisent l'impact de l'outil de mesure sur les résultats.

Dans les réseaux d'opérateurs complexes, connaître l'adresse IP d'un saut est insuffisant. Pour comprendre les décisions de routage et identifier les points de défaillance, il est essentiel d'analyser les numéros de système autonome (AS) et les étiquettes MPLS.

L'option -z (ou --as-lookup) enrichit chaque saut avec son numéro d'AS. Cela permet d'identifier instantanément les changements de fournisseur de transit ou de peering, qui sont des points fréquents de congestion ou de mauvaise configuration. Si la latence augmente brusquement au moment de passer d'un AS à un autre, le problème se situe probablement au niveau de l'interconnexion entre ces deux réseaux.

Pour les réseaux d'opérateurs utilisant MPLS, l'option -e (ou --mpls) est indispensable. Elle affiche les informations d'étiquette MPLS, de classe de trafic (TC) et de Time-to-Live (TTL) pour chaque saut. L'analyse des étiquettes permet de suivre le chemin de commutation par étiquettes (LSP) qu'empruntent les paquets, offrant une visibilité à l'intérieur du cloud MPLS qui serait autrement opaque. Des changements inattendus d'étiquette ou des valeurs de classe de trafic incohérentes peuvent indiquer une mauvaise configuration de l'ingénierie de trafic.

Enfin, pour l'automatisation et l'analyse post-mortem, les options -w (--report-wide) et -x (--xml) sont cruciales. L'option -w garantit que les noms d'hôtes ne sont pas tronqués, tandis que -x fournit une sortie structurée et facilement analysable par des scripts ou des outils de monitoring. La combinaison de ces options permet d'intégrer MTR dans des pipelines de diagnostic automatisés pour une surveillance proactive des performances réseau.