"Ce n'est pas le réseau !" Si vous êtes comme moi, c'est ce que vous proclamez lors du dépannage d'un problème d'application. Seul problème : après un diagnostic minutieux du réseau, il arrive parfois que ce soit vraiment le réseau.
Une plaisanterie parmi les ingénieurs réseau est que lorsque quelque chose ne va pas avec tout ce qui concerne un ordinateur, tout le monde blâme le pare-feu. Oui, cela peut être drôle, mais c'est aussi l'une des choses les plus frustrantes pour un ingénieur réseau de faire un diagnostic réseau. Nous sommes doués pour faire fonctionner les pings sur un réseau, mais le dépannage d'une application peut donner l'impression de prendre des photos dans le noir.
Il y a quelques mois à peine, j'ai été tagué sur une chaîne de messagerie lancée par l'un de nos développeurs pour aider à dépanner une application héritée utilisée pour surveiller les instruments scientifiques. L'application fonctionnait très bien sur le site principal, mais il s'agissait d'un nouveau site et quelque chose n'allait pas.
J'ai été surpris d'apprendre qu'ils avaient déjà passé du temps à dépanner l'application avant de me faire venir. C'était bien, mais cela suggérait également que le problème pouvait vraiment être le réseau.
J'ai vérifié les bases comme les listes d'accès et les paramètres MTU, mais comme les symptômes rencontrés ne se produisaient pas sur le site principal, je ne savais pas quoi chercher. Les deux sites étaient configurés de manière identique, donc à mon avis, cela aurait dû fonctionner. Les journaux de l'application elle-même n'ont rien révélé d'utile, je ne pouvais donc faire que très peu de diagnostic réseau, à part attendre que cela se reproduise et me connecter aux appareils en temps réel.
La capture d'informations pertinentes au moment d'un incident peut être extrêmement difficile, en particulier avec un réseau de centaines de commutateurs et de dizaines de routeurs et de pare-feu. Par exemple, tracer le chemin de couche 2 emprunté par une application est presque impossible car le traceroute ne regarde que la couche 3. Et même lorsque nous regardons les informations de couche 3 pour un flux, c'est dans une seule direction à la fois.
Il est également important de dépanner en temps réel les informations sur les périphériques réseau tout au long du chemin, telles que les erreurs d'interface, les incompatibilités duplex et les erreurs CRC. Nous pouvons obtenir une partie de cela en passant manuellement appareil par appareil, mais cela signifie que nous devrons être sur le CLI prêt au moment où un utilisateur signale un problème.
En utilisant uniquement les méthodes de diagnostic réseau ad hoc dont nous disposions, nous avons poursuivi le dépannage en mettant les appareils hors production afin d'exécuter des tests alors qu'ils étaient directement connectés. L'application a parfaitement fonctionné. Après avoir tout remis en production, cela a échoué. Dire que j’étais frustré serait un euphémisme.
Mais cette fois, j’étais au top et juste au moment où les scientifiques recommençaient à utiliser l’application, une capture de paquet a immédiatement révélé le problème. Le problème était si simple, mais ce n’était pas quelque chose que je pensais vérifier lors du diagnostic du réseau.
Je ne savais pas comment l'application était censée fonctionner, et à travers toutes nos conférences téléphoniques, j'ai appris que les développeurs faisaient de leur mieux pour maintenir un ancien programme qu'ils n'avaient pas écrit.
Il utilisait la multidiffusion, et personne ne le savait.
C’est là que le diagnostic réseau automatisé et basé sur l’intention peut être une bouée de sauvetage pour les ingénieurs réseau qui résolvent des problèmes réels. J'avais des moniteurs de réseau, mais j'avais besoin d'un mécanisme capable de surveiller en permanence les caractéristiques du réseau, de les comparer aux configurations de base et d'être déclenché par l'ITSM et les outils de surveillance pour capturer automatiquement les informations critiques au moment de l'incident dans le ticket, y compris le diagnostic du réseau. . Heureusement, je peux utiliser une intention, une unité d'automatisation exécutable sans code, contenant des étapes pour fournir automatiquement des données sur les tables de routage, les statistiques d'interfaces, les informations réseau éphémères et même le chemin emprunté par une application au moment où un incident se produit. Je peux même le faire de manière interactive seul ou via un robot en libre-service !
Le site principal était le seul endroit où l'application était utilisée, donc ce n'était jamais une pensée. Mais maintenant qu'il était utilisé à travers les limites de la couche 3 vers un autre emplacement, le réseau et l'application devaient avoir une multidiffusion correctement configurée pour que la communication fonctionne.
La remédiation a été relativement simple par rapport au diagnostic du réseau, et la direction était heureuse que nous ayons pu faire fonctionner cette ancienne application sur le nouveau site. Personne ne s'est demandé pourquoi cela avait pris autant de temps, mais je pense que c'est uniquement parce que l'on comprenait déjà qu'il s'agissait d'une ancienne application.
Bien que j'ai ignoré le temps de résolution excessivement long, j'aurais également souhaité qu'il y ait un moyen plus simple de capturer les données dont j'avais besoin au moment où le problème est survenu. En fait, un outil comme celui-ci serait inestimable pour résoudre les problèmes quotidiens d'exploitation du réseau.
NetBrainLa plateforme de permet aux ingénieurs réseau de visualiser facilement les chemins empruntés par les applications à travers nos réseaux. De plus, il peut automatiquement fournir les bonnes intentions pour recueillir le diagnostic de réseau incroyablement précieux dont nous avons besoin pour traiter les vagues tickets d'incident qui arrivent dans nos files d'attente et qui contiennent peu ou pas d'informations directement sur une carte à l'aide de l'intention automatique.
En fin de compte, résoudre mon problème d'application n'était pas sorcier. J'ai appris que de nombreux problèmes auxquels nous sommes confrontés sont souvent le résultat de problèmes très communs. Cependant, trouver le problème, même s'il est simple, peut être très difficile sans les bons outils.
Intent-Based Network Automation nous donner, en tant qu'ingénieurs réseau, la possibilité de créer cartographie dynamique du réseau et des intentions de superposition pour le diagnostic et le dépannage en temps réel du réseau, de la connectivité et des performances des applications qui nous aident finalement à prouver, une fois pour toutes, que ce n'est pas le réseau, sauf, bien sûr, quand il l'est.