Ce n'est pas le réseau !

by Philippe Gervasi 26 mai 2017

"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. Le seul problème, cependant, est que parfois c'est 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 qu'ils ont rencontrés ne se sont pas produits sur le site principal, je ne savais pas quoi chercher. Les deux sites ont été configurés de manière identique, donc dans mon esprit, cela aurait dû fonctionner. Les journaux de l'application elle-même n'ont rien révélé d'utile, donc je ne pouvais pas faire grand-chose à 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 le 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 allant manuellement appareil par appareil, mais cela signifie que nous devons être prêts sur la CLI juste au moment où un utilisateur signale un problème.
En utilisant uniquement les méthodes ad hoc dont nous disposions, nous avons poursuivi le dépannage en retirant les appareils de la production afin d'effectuer 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 grossier.

Cette fois, j'étais au-dessus, cependant, et juste au moment où les scientifiques ont recommencé à utiliser l'application, une capture de paquet a immédiatement révélé le problème. Le problème était si simple, mais pas quelque chose qui m'est venu à l'esprit pour vérifier.

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à qu'un système automatisé 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 et de les vérifier par rapport 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 des 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 par moi-même ou via un bot 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 correction a été relativement simple 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 qu'il était déjà entendu 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 plate-forme de permet aux ingénieurs réseau de visualiser facilement les chemins empruntés par les applications sur nos réseaux. De plus, il peut fournir automatiquement les bonnes intentions pour collecter les données réseau incroyablement précieuses dont nous avons besoin pour traiter les vagues tickets d'incident qui frappent 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.