"¡No es la red!" Si eres como yo, eso es lo que proclamas cuando solucionas un problema de aplicación. El único problema: después de un cuidadoso diagnóstico de la red, a veces realmente es la red.
Una broma entre los ingenieros de redes es que cuando algo anda mal con algo relacionado con una computadora, todos culpan al firewall. Sí, esto puede ser divertido, pero también es una de las cosas más frustrantes para un ingeniero de redes hacer un diagnóstico de red. Somos buenos para hacer que los pings funcionen en una red, pero solucionar problemas de una aplicación puede parecer como tomar fotografías en la oscuridad.
Hace solo unos meses, fui etiquetado en una cadena de correo electrónico iniciada por uno de nuestros desarrolladores para ayudar a solucionar problemas de una aplicación heredada utilizada para monitorear instrumentos científicos. La aplicación funcionó bien en la ubicación principal, pero este era un sitio nuevo y algo andaba mal.
Me sorprendió saber que ya dedicaron tiempo a solucionar los problemas de la aplicación antes de traerme. Eso estuvo bien, pero también sugirió que el problema realmente podría ser la red.
Verifiqué los conceptos básicos como listas de acceso y configuraciones de MTU, pero como los síntomas que experimentaron no ocurrieron en el sitio principal, no sabía qué buscar. Ambos sitios estaban configurados de manera idéntica, por lo que, en mi opinión, esto debería haber funcionado. Los registros de la aplicación en sí no revelaron nada útil, por lo que pude hacer muy poco diagnóstico de red excepto esperar a que volviera a suceder e iniciar sesión en los dispositivos en tiempo real.
Capturar información relevante en el momento de un incidente puede ser extremadamente difícil, especialmente con una red de cientos de conmutadores y docenas de enrutadores y cortafuegos. Por ejemplo, rastrear la ruta de la capa 2 que toma una aplicación es casi imposible porque traceroute solo mira la capa 3. E incluso cuando miramos la información de la capa 3 para un flujo, está en una sola dirección a la vez.
Además, es importante solucionar problemas en tiempo real la información del dispositivo de red a lo largo de la ruta, como errores de interfaz, discrepancias dúplex y errores CRC. Podemos obtener algo de esto yendo dispositivo por dispositivo manualmente, pero eso significa que necesitaríamos estar en el CLI listo justo cuando un usuario informa un problema.
Utilizando únicamente los métodos de diagnóstico de red ad hoc que teníamos, continuamos solucionando problemas sacando los dispositivos de producción para ejecutar pruebas mientras estaban conectados directamente. La aplicación funcionó perfectamente. Después de volver a poner todo en producción, falló. Decir que estaba frustrado sería quedarse muy corto.
Esta vez, sin embargo, estaba al tanto y justo cuando los científicos comenzaron a usar la aplicación nuevamente, una captura de paquetes reveló el problema de inmediato. El problema era muy simple, pero no se me ocurrió verificarlo durante el diagnóstico de la red.
No sabía cómo se suponía que funcionaba la aplicación y, a través de todas nuestras conferencias telefónicas, supe que los desarrolladores estaban haciendo todo lo posible para mantener un programa antiguo que no escribieron.
Usaba multidifusión, y nadie lo sabía.
Aquí es donde el diagnóstico de red automatizado y basado en la intención puede ser una salvación para los ingenieros de redes que solucionan problemas del mundo real. Tenía monitores de red, pero necesitaba un mecanismo que pudiera monitorear continuamente las características de la red y compararlas con las configuraciones de referencia y ser activado por ITSM y herramientas de monitoreo para capturar automáticamente información crítica en el momento del incidente en el ticket, incluido el diagnóstico de la red. . Afortunadamente, puedo usar un intent, una unidad de automatización ejecutable sin código, que contiene pasos para entregar automáticamente datos sobre tablas de enrutamiento, estadísticas de interfaces, información efímera de la red e incluso la ruta que está tomando una aplicación justo cuando ocurre un incidente. ¡Incluso puedo hacer esto de forma interactiva por mi cuenta o mediante un robot de autoservicio!
El sitio principal era el único lugar donde se usaba la aplicación, por lo que esto nunca fue un pensamiento. Pero ahora que se estaba utilizando a través de los límites de la capa 3 a otra ubicación, la red y la aplicación necesitaban tener la multidifusión configurada correctamente para que la comunicación funcionara.
La reparación fue relativamente simple en comparación con el diagnóstico de la red, y la administración estaba contenta de que pudiéramos hacer que esta antigua aplicación funcionara en el nuevo sitio. Nadie cuestionó por qué tomó tanto tiempo, pero creo que eso se debe únicamente a que ya se entendía que se trataba de una aplicación antigua.
Aunque me encogí de hombros por el tiempo excesivamente largo para la resolución, también deseaba que hubiera una manera más fácil de capturar los datos que necesitaba en el momento en que ocurrió el problema. De hecho, una herramienta como esa no tendría precio para solucionar problemas de operaciones diarias de la red.
NetBrainLa plataforma de permite a los ingenieros de redes visualizar fácilmente las rutas que toman las aplicaciones a través de nuestras redes. Además, puede proporcionar automáticamente las intenciones correctas para recopilar el diagnóstico de red increíblemente valioso que necesitamos para abordar los vagos tickets de problemas que llegan a nuestras colas y que vienen con poca o ninguna información directamente en un mapa usando Auto Intent.
Al final, solucionar el problema de mi aplicación no fue una ciencia espacial. He aprendido que muchos de los problemas que enfrentamos a menudo son el resultado de problemas muy comunes. Sin embargo, encontrar el problema, aunque sea simple, puede ser muy difícil sin las herramientas adecuadas.
Intent-Based Network Automation darnos, como ingenieros de redes, la capacidad de crear mapeo dinámico de redes e intentos de superposición para el diagnóstico en tiempo real y la resolución de problemas de la red, la conectividad y el rendimiento de la aplicación que, en última instancia, nos ayudan a demostrar, de una vez por todas, que no es la red, excepto, por supuesto, cuando lo es.