PingPlotter et les serveurs DNS squameux d’AT & T
L’un de mes outils préférés pour traquer les problèmes de réseau est un outil appelé PingPlotter publié par Nessoft. J’ai écrit plusieurs fois sur PingPlotter (la dernière fois en 2011, bien qu’il ait également joué un rôle de premier plan dans le tri de mes problèmes avec AT& T en 2012). En fait, cet utilitaire m’a tellement aidé que c’est ridicule. Voici mon résumé de PingPlotter de mon dernier tour d’horizon de mes outils préférés:
Le PingPlotter de Nessoft tests teste la connectivité à un ou plusieurs hôtes cibles sur votre réseau local ou sur Internet et trace les résultats. En fait, PingPlotter exécute à plusieurs reprises une traceroute pour identifier tous les routeurs intermédiaires entre votre machine et les cibles et tester chacun pendant le temps nécessaire pour répondre. L’outil mesure également la « gigue de paquet » (la variation de la rapidité avec laquelle les paquets sont traités), le score d’opinion moyen VoIP ou MOS (une estimation de la qualité vocale perçue) et l’écart-type du temps de transit des paquets. Pingplotter est disponible en versions freeware, Standard (24,95$) et Pro (199,95$). Pingplotter gets obtient une note de 5 sur 5.
J’ai récemment eu l’occasion d’utiliser à nouveau le PingPlotter lorsque les périphériques de mon réseau qui configurent leurs connexions réseau via DHCP desservies par ma passerelle ADSL + AT& T U-verse NVG-510 ont commencé à ralentir.
Dans le journal du NVG-510 (qui est un journal circulaire beaucoup trop court), j’ai vu plusieurs occurrences de défaillances DNS ; par exemple, plus tôt aujourd’hui:
2014-07-10T22:21:28-07:00 L3 dnsmasq: no responses from nameserver '99.99.99.53'2014-07-10T22:21:28-07:00 L3 dnsmasq: nameserver '99.99.99.53' is now responding
Assez souvent, ces erreurs se produisent dans les clusters et les clusters peuvent continuer pendant des minutes à la fois, il n’est donc pas surprenant que les périphériques de mon réseau utilisant des configurations DHCP présentent une mauvaise connectivité.
J’ai déjà théorisé que l’implémentation par le NVG-510 du transitaire DNS de la passerelle (qui est basée sur le code dnsmasq open source) a un délai d’attente trop court sur les requêtes ayant échoué. Mais pourquoi une requête échouerait-elle ?
J’ai démarré PingPlotter et j’ai constaté que les deux serveurs DNS qui sont définis et immuables dans le serveur DHCP de la passerelle (à savoir, les serveurs DNS primaires et secondaires à 99.99.99.53 et 99.99.99.153 respectivement qui, selon whatsmydns.net , n’existent pas) sont encore, comme je l’ai observé en 2012, flakey. Le problème semble maintenant être qu’ils sont devenus encore plus floconneux.
Voici un exemple de la sortie de PingPlotter d’hier pour les serveurs DNS par défaut d’AT &T:
Le temps entre les pings est de 10 secondes et les blocs rouges les plus étroits indiquent 1 paquet perdu. Comme vous pouvez le voir, il y a des pertes fréquentes de paquets pendant 20 ou 30 secondes (les blocs de longueur double et triple) ou plus. Ces clusters de paquets perdus sont eux-mêmes dans des clusters réguliers comme on peut le voir sur cette trace pendant environ trois jours et demi:
Pourquoi les réponses du serveur devraient s’améliorer systématiquement une fois par jour est à peu près un mystère pour l’instant.
Curieusement, ce ne sont pas les seuls serveurs DNS À & T a d’autres serveurs DNS primaires et secondaires aux 68.94.156.1 et 68.94.157.1 respectivement. Le suivi de leur comportement (les deux traces du bas) ainsi que des serveurs DNS de Google aux versions 8.8.8.8 et 8.8.4.4 (les deux traces du haut) aux côtés des serveurs DNS par défaut (les deux traces du milieu) montre que les serveurs DNS peuvent être atteints de manière fiable sur le réseau AT & T :