„Es ist nicht das Netzwerk!“ Wenn Sie wie ich sind, sagen Sie das, wenn Sie ein Anwendungsproblem beheben. Das einzige Problem ist jedoch, dass es manchmal wirklich das Netzwerk ist.
Ein Witz unter Netzwerkingenieuren ist, dass jeder der Firewall die Schuld gibt, wenn etwas mit einem Computer nicht stimmt. Ja, das mag lustig sein, aber es ist auch eines der frustrierendsten Dinge für einen Netzwerktechniker, eine Netzwerkdiagnose durchzuführen. Wir sind gut darin, Pings in einem Netzwerk zum Laufen zu bringen, aber die Fehlerbehebung bei einer Anwendung kann sich anfühlen, als würde man im Dunkeln tappen.
Erst vor ein paar Monaten wurde ich in einer E-Mail-Kette markiert, die von einem unserer Entwickler gestartet wurde, um bei der Fehlersuche in einer Legacy-Anwendung zu helfen, die zur Überwachung wissenschaftlicher Instrumente verwendet wird. Die Anwendung funktionierte am Hauptstandort einwandfrei, aber dies war eine neue Website, und etwas stimmte nicht.
Ich war überrascht zu hören, dass sie bereits Zeit damit verbracht hatten, die Anwendung zu beheben, bevor sie mich hereinbrachten. Das war nett, aber es deutete auch darauf hin, dass das Problem wirklich das Netzwerk sein könnte.
Ich überprüfte die Grundlagen wie Zugriffslisten und MTU-Einstellungen, aber da die aufgetretenen Symptome nicht auf der Hauptseite auftraten, wusste ich nicht, wonach ich suchen sollte. Beide Sites wurden identisch konfiguriert, also sollte dies meiner Meinung nach funktionieren. Die Protokolle für die Anwendung selbst zeigten nichts Hilfreiches, daher konnte ich nur sehr wenig tun, außer darauf zu warten, dass es wieder passiert, und mich in Echtzeit bei Geräten anzumelden.
Die Erfassung relevanter Informationen zum Zeitpunkt eines Vorfalls kann äußerst schwierig sein – insbesondere bei einem Netzwerk aus Hunderten von Switches und Dutzenden von Routern und Firewalls. Beispielsweise ist es so gut wie unmöglich, den Layer-2-Pfad zu verfolgen, den eine Anwendung nimmt, da die Traceroute nur Layer 3 betrachtet. Und selbst wenn wir die Layer-3-Informationen für einen Datenfluss betrachten, erfolgt dies jeweils nur in eine Richtung.
Wichtig für die Fehlersuche in Echtzeit sind auch Netzwerkgeräteinformationen entlang des Pfads, wie Schnittstellenfehler, Duplex-Nichtübereinstimmungen und CRC-Fehler. Wir können einige davon abrufen, indem wir Gerät für Gerät manuell durchgehen, aber das bedeutet, dass wir auf der CLI bereit sein müssten, sobald ein Benutzer ein Problem meldet.
Wir nutzten nur die uns zur Verfügung stehenden Ad-hoc-Methoden und setzten die Fehlerbehebung fort, indem wir die Geräte aus der Produktion nahmen, um Tests durchzuführen, während sie direkt verbunden waren. Die Anwendung hat einwandfrei funktioniert. Nachdem alles wieder in Produktion gegangen war, schlug es fehl. Zu sagen, dass ich frustriert war, wäre eine grobe Untertreibung.
Diesmal war ich jedoch oben drauf, und gerade als die Wissenschaftler wieder mit der Anwendung begannen, enthüllte eine Paketerfassung das Problem sofort. Das Problem war so einfach, aber mir fiel nichts ein, um es zu überprüfen.
Ich wusste nicht, wie die Anwendung funktionieren sollte, und durch all unsere Telefonkonferenzen erfuhr ich, dass die Entwickler nur ihr Bestes gaben, um ein altes Programm zu pflegen, das sie nicht geschrieben hatten.
Es verwendete Multicast, und niemand wusste es.
Hier kann ein absichtsbasiertes automatisiertes System ein Lebensretter für Netzwerktechniker sein, die reale Probleme beheben. Ich hatte Netzwerkmonitore, aber ich brauchte einen Mechanismus, der die Netzwerkeigenschaften kontinuierlich überwachen und mit den Basiskonfigurationen vergleichen und von ITSM und Überwachungstools ausgelöst werden konnte, um kritische Informationen zum Zeitpunkt des Vorfalls automatisch im Ticket zu erfassen, einschließlich der Netzwerkdiagnose . Glücklicherweise kann ich einen Intent verwenden, eine ohne Code ausführbare Automatisierungseinheit, die Schritte enthält, um automatisch Daten über Routing-Tabellen, Schnittstellenstatistiken, flüchtige Netzwerkinformationen und sogar den Weg einer Anwendung zu liefern, sobald ein Vorfall eintritt. Ich kann dies sogar interaktiv alleine oder über einen Self-Service-Bot tun!
Die Hauptseite war der einzige Ort, an dem die Anwendung verwendet wurde, daher war dies nie ein Gedanke. Aber jetzt, da es über Layer-3-Grenzen hinweg zu einem anderen Standort verwendet wurde, mussten das Netzwerk und die Anwendung Multicast richtig konfiguriert haben, damit die Kommunikation funktionierte.
Die Behebung war relativ einfach, und das Management war froh, dass wir diese veraltete Anwendung am neuen Standort zum Laufen bringen konnten. Niemand hat hinterfragt, warum es so lange gedauert hat, aber ich denke, das liegt nur daran, dass man sich bereits darüber im Klaren war, dass es sich um eine alte Anwendung handelt.
Obwohl ich die unangemessen lange Zeit bis zur Lösung verdrängte, wünschte ich mir auch, dass es eine einfachere Möglichkeit gäbe, die Daten zu erfassen, die ich zum Zeitpunkt des Auftretens des Problems benötigte. Tatsächlich wäre ein solches Tool für die Behebung von Problemen im täglichen Netzwerkbetrieb von unschätzbarem Wert.
NetBrainDie Plattform von ermöglicht es Netzwerkingenieuren, die Pfade, die Anwendungen durch unsere Netzwerke nehmen, einfach zu visualisieren. Darüber hinaus kann es automatisch die richtigen Intents bereitstellen, um die unglaublich wertvollen Netzwerkdaten zu sammeln, die wir benötigen, um die vagen Trouble-Tickets zu adressieren, die unsere Warteschlangen treffen und mit wenig bis gar keinen Informationen direkt auf einer Karte mit Auto Intent kommen.
Am Ende war die Lösung meines Anwendungsproblems kein Hexenwerk. Ich habe gelernt, dass viele Probleme, mit denen wir konfrontiert sind, oft das Ergebnis sehr allgemeiner Probleme sind. Das Auffinden des Problems, selbst wenn es einfach ist, kann jedoch ohne die richtigen Tools sehr schwierig sein.
Intent-Based Network Automation Geben Sie uns als Netzwerktechniker die Möglichkeit zu schaffen dynamisches Netzwerk-Mapping und Overlay-Intents für die Echtzeitdiagnose und Fehlerbehebung des Netzwerks, der Konnektivität und der Anwendungsleistung, die uns letztendlich helfen, ein für alle Mal zu beweisen, dass es nicht das Netzwerk ist, außer natürlich, wenn es eines ist.