„Es liegt nicht am Netzwerk!“ Das ist es, was Sie wie ich ausrufen, wenn Sie ein Anwendungsproblem beheben. Das einzige Problem: Nach sorgfältiger Netzwerkdiagnose liegt es manchmal wirklich am Netzwerk.
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 habe die grundlegenden Dinge wie Zugriffslisten und MTU-Einstellungen überprüft, aber da die Symptome, die sie zeigten, auf der Hauptseite nicht auftraten, wusste ich nicht, wonach ich suchen sollte. Beide Seiten waren identisch konfiguriert, also hätte das meiner Meinung nach funktionieren müssen. Die Protokolle für die Anwendung selbst haben nichts Hilfreiches ergeben, also konnte ich nur sehr wenig Netzwerkdiagnosen durchführen, außer zu warten, bis es wieder passiert, und mich in Echtzeit bei den 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 Echtzeit-Fehlerbehebung sind auch Netzwerkgeräteinformationen entlang des Pfads, wie Schnittstellenfehler, Duplex-Fehlanpassungen und CRC-Fehler. Einige dieser Informationen können wir erhalten, indem wir Gerät für Gerät manuell durchgehen, aber das bedeutet, dass wir auf dem CLI immer zur Hand, sobald ein Benutzer ein Problem meldet.
Wir setzten die Fehlersuche fort, indem wir nur die Ad-hoc-Netzwerkdiagnosemethoden verwendeten, die uns zur Verfügung standen. Wir nahmen die Geräte aus der Produktion, um Tests durchzuführen, während sie direkt angeschlossen waren. Die Anwendung funktionierte einwandfrei. Nachdem wir alles wieder in die Produktion gebracht hatten, funktionierte sie nicht mehr. Zu sagen, dass ich frustriert war, wäre eine grobe Untertreibung.
Dieses Mal hatte ich es jedoch im Griff, und als die Wissenschaftler die Anwendung wieder zu verwenden begannen, offenbarte eine Paketerfassung das Problem sofort. Das Problem war so einfach, aber es fiel mir bei der Netzwerkdiagnose nicht ein, 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 eine automatisierte, absichtsbasierte Netzwerkdiagnose für Netzwerktechniker bei der Behebung realer Probleme lebensrettend sein. Ich hatte Netzwerkmonitore, brauchte aber einen Mechanismus, der die Netzwerkeigenschaften kontinuierlich überwachen und mit Basiskonfigurationen vergleichen konnte und der von ITSM und Überwachungstools ausgelöst werden konnte, um zum Zeitpunkt des Vorfalls automatisch wichtige Informationen im Ticket zu erfassen, einschließlich der Netzwerkdiagnose. Glücklicherweise kann ich eine Absicht verwenden, eine ohne Code ausführbare Automatisierungseinheit, die Schritte enthält, um automatisch Daten über Routingtabellen, Schnittstellenstatistiken, flüchtige Netzwerkinformationen und sogar den Pfad bereitzustellen, den eine Anwendung nimmt, wenn ein Vorfall auftritt. 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 im Vergleich zur Netzwerkdiagnose relativ einfach und das Management war froh, dass wir diese alte Anwendung am neuen Standort zum Laufen bringen konnten. Niemand fragte, warum es so lange dauerte, aber ich denke, das lag nur daran, dass bereits klar war, dass es sich um eine alte Anwendung handelte.
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.
NetBrainMithilfe der Plattform von können Netzwerkingenieure die Pfade, die Anwendungen durch unsere Netzwerke nehmen, einfach visualisieren. Darüber hinaus kann sie automatisch die richtigen Intents bereitstellen, um die unglaublich wertvolle Netzwerkdiagnose zu erstellen, die wir benötigen, um die vagen Problemtickets in unseren Warteschlangen zu bearbeiten, die nur wenige oder gar keine Informationen enthalten – und zwar direkt auf einer Karte mit Auto Intent.
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.