Avec tout le respect que je vous dois, je ne veux pas dire que tracert échoue à chaque fois. Je veux dire que lorsque qu'un hôte dans le chemin ne répond pas à un tracert, cela ne signifie pas que cet hôte est le problème, et si vous utilisez souvent tracert, vous verrez qu'il y a toujours un hôte dans le chemin qui ne répond pas.
Le problème ici est la déconnexion intermittente. Si elle était complètement en panne, utiliser tracert et ping serait un bon choix. Ping et tracert sont de bons outils de niveau de triage mais ils ne vont pas aider à découvrir la cause des problèmes intermittents. Tracert (comme son nom l'indique) est un outil pour tracer le chemin vers un hôte distant, et par sa nature, il peut vous dire si un chemin existe ou non. Tracert n'est pas un outil de diagnostic qui peut vous dire pourquoi un hôte ne répond pas ou laisse passer des paquets. La seule façon d'obtenir ces informations est d'exécuter une capture réseau aux deux extrémités de la connexion, et idéalement, si possible, sur chaque lien dans le chemin.
Si je lance un ping constant et un tracert constant vers un hôte distant et que je reçois une réponse de ping échouée de l'hôte distant et qu'au même moment je vois un hôte intermédiaire dans le tracert cesser de répondre, est-ce que cela signifie que cet hôte intermédiaire est le problème? Non, cela ne le signifie pas et il ne serait pas possible de corréler les deux événements à moins que je n'exécute une capture réseau sur chaque lien dans le chemin et que je puisse analyser les données au niveau du paquet.
Je suggérais simplement de commencer le dépannage avec les composants connus et mesurables, qui sont les deux hôtes aux extrémités de la connexion.
Je sais que chacun a son opinion et mon intention n'est pas de commencer une guerre, donc je m'excuse si quelqu'un se sent offensé.
