So fördern Sie Netzwerkfehler
May 30, 2023
Eine Nachricht hinterlassen
Wir wissen, dass Switches wichtige Netzwerkgeräte in lokalen Netzwerken sind, und ihr Betriebsstatus hängt eng mit dem Internetzugangsstatus von Client -Systemen zusammen.
In der praktischen Arbeit kann der Status von Schalter jedoch leicht von externen Faktoren beeinflusst werden, was zu verschiedenen Netzwerkfehlern im lokalen Netzwerk führt.
Um einen stabilen Netzwerkbetrieb zu gewährleisten, müssen wir ordnungsgemäß verwalten und wartenSchalterin unserer täglichen Arbeit, um Schalterfehler zu verhindern.
In diesem Artikel werden wir die Erfahrung eines hochrangigen Low-Voltage-Experten für Fehlerbehebungsfehler erzählen. Während der Wartung eines örtlichen Gebietsnetzes in einem Gebäude stieß er auf einen Fehler, bei dem der Bodenschalter aufgrund von unsachgemäßen physischen Verbindungen nicht pinged werden konnte. Der Fehlerbehebungsprozess für diesen Netzwerkfehler erwies sich als sehr herausfordernd.
Da dieser Fehler relativ typisch ist und der Ansatz zur Fehlerbehebung referenziert werden kann, wird er hier für den Vorteil aller geteilt.
1. Fehlerszene:
Das Bürogebäude, für das ich damals verantwortlich war, bestand aus mehreren Unternehmen. Um sicherzustellen, dass jedes Unternehmen einen unabhängigen Internetzugang haben und dass sein Internetstatus von anderen Unternehmen nicht beeinflusst wird, habe ich einen Router -Switch als Kernschalter für das Netzwerk des Gebäudes gewählt.
Gleichzeitig wurden für jede Einheit auf dem Schalter verschiedene virtuelle Arbeitssubnetze eingerichtet.
Da sich jede Einheit auf verschiedenen Böden befand und die Anzahl der Unternehmen auf jeder Etage unterschiedlich war, hatten einige Böden zwei oder drei Einheiten, während andere bis zu fünf oder sechs Einheiten hatten.
Die Arbeitsunternetze von Einheiten auf verschiedenen Böden wurden alle über den entsprechenden Bodenschalter mit dem örtlichen Gebäude -Netzwerk verbunden und über die Hardware -Firewall im Netzwerk des Gebäudes auf das Internet -Netzwerk zugegriffen.
Um die Effizienz des Netzwerkmanagements zu verbessern, verwalteten und pflegen Netzwerkadministratoren die Switches in der Regel über Remote -Verbindungen.
Eines Morgens, als ich mit der Arbeit begann und den Arbeitsstatus verschiedener Schaltanschlüsse im örtlichen Netzwerkkernschalter scannte und diagnostizierte, stellte ich fest, dass sich einer der Switch -Ports in einem Down -Status befand.
Deshalb habe ich die Netzwerkverwaltungsdatensätze überprüft und festgestellt, dass die Verbindung zu diesem Port aus einem Schalter im zweiten Stock im fünften Stock stammte.
Als ich versuchte, mich im Bodenschalter aus der Ferne anzumelden, stellte ich fest, dass ich mich nicht erfolgreich anmelden konnte. Als ich den Ping -Befehl benutzte, um die IP -Adresse des Switchs zu testen, wurde "Anforderungszeit“ zurückgegeben.
Gerade als ich mich fragte, warum niemand den Fehler gemeldet hatte, klingelte das Telefon wie erwartet und sicher genug, dass Benutzer aus dem fünften Stock nach dem anderen Netzwerkfehler melden.
Basierend auf den obigen Fehlersymptomen vermutete ich, dass es möglicherweise ein unerwartetes Problem mit dem Bodenschalter aufweist.
Also eilte ich zum Szene des fehlerhaften Schalters, trennte seine Stromversorgung, wartete eine Weile und verband dann das Stromversorgung, um ihn neu zu starten.
Nach Abschluss des Neustartvorgangs verwendete ich den Ping -Befehl, um die IP -Adresse des Switchs erneut zu testen.
Dieses Mal waren die zurückgegebenen Ergebnisse normal, und die Remote -Anmeldeingänge konnten reibungslos verlaufen.
Eine halbe Stunde später zeigte der fehlerhafte Schalter jedoch erneut die gleichen Fehlersymptome, und als ich ihn mit dem Ping -Befehl testete, kehrte er erneut abnormale Ergebnisse zurück.
Später wiederholte ich den Prozess des Neustarts und Tests, nur um festzustellen, dass der fehlerhafte Schalter immer noch nicht normal pinged werden konnte.
2. Eingehende Fehlerbehebung:
Da wiederholte Neustarts das Problem nicht gelöst haben, schätzte ich, dass die Ursache des Fehlers komplizierter war, wenn man bedenkt, dass diese Art von Fehler häufig in Netzwerkmanagementprozessen auftritt.
Deshalb habe ich nach dem folgenden Ansatz eine eingehende Fehlerbehebung durchgeführt:
In Anbetracht der Tatsache, dass nur ein Stockwerk im fünften Stock des gesamten Gebäudesetzwerks dieses Phänomen aufwies, beurteilte ich zunächst, dass es durch Probleme mit diesem Bodenschalter selbst verursacht werden könnte.
Um die Ursache des Fehlers genau zu identifizieren, wollte ich den fehlerhaften Schalter durch einen ordnungsgemäß funktionierenden ersetzen und beobachten, ob der Fehler immer noch bestand.
Gleichzeitig würde ich den vermuteten problematischen Schalter mit einer unabhängigen Netzwerkumgebung verbinden.
Nach einer halben Test- und Beobachtungsstunde sah ich, dass der fehlerhafte Schalter, der mit der isolierten Netzwerkumgebung verbunden war, normal funktionierte und seine IP -Adresse in dieser Netzwerkumgebung pingelt werden konnte.
Der neu ersetzte Switch konnte jedoch, wenn er mit dem Gebäudetuch verbunden war, nicht normal pinged.
Basierend auf diesen Beobachtungen kam ich zu dem Schluss, dass die Möglichkeit des Schalters im fünften Stock selbst fast vernachlässigbar war. Nachdem ich Faktoren ausgeschlossen hatte, die sich auf den Status des fehlerhaften Switchs beziehen, überprüfte ich die Netzwerkstruktur und den Status des gesamten Gebäudetodus.
Während Benutzer in anderen Böden des Gebäudes normalerweise auf das Internet zugreifen könnten, konnte ein Teil der Benutzer im fünften Stock nicht.
Als ich die Netzwerkinformationen für den fünften Stock überprüfte, stellte ich fest, dass es fünf Einheiten auf dieser Etage gab. Zu diesem Zeitpunkt hatte der Netzwerkadministrator zweistöckige Schalter im fünften Stock eingerichtet und in einer Kaskadenkonfiguration verbunden.
Darüber hinaus wurden auf diesen beiden Schalter fünf virtuelle funktionierende Subnetze erstellt, um sicherzustellen, dass jede Einheit unabhängig in ihren jeweiligen virtuellen Subnetzen arbeiten kann.
Da der entsprechende Anschluss auf dem Kernschalter bereits abgebaut war, sollten alle Einheiten im fünften Stock nicht auf das Internet zugreifen können. Warum meldeten nur einige Benutzer den Fehler?
Sobald es Zeit war, mit der Arbeit zu beginnen, kontaktierte ich sofort mehrere Unternehmen, die keine Netzwerkfehler gemeldet hatten. Ihre Antwort war, dass sie gerade den abnormalen Netzwerkzugang entdeckt hatten und im Begriff waren, Hilfe beim Gebäude -Netzwerkadministrator zu suchen.
Wenn dies der Fall ist, sollten alle Einheiten im fünften Stock nicht auf das Internet zugreifen können. Daher sollte die Ursache des Fehlers innerhalb der virtuellen Arbeitsunternetze dieser Einheiten liegen.
Nachdem ich den Umfang der Fehlerbehebung auf die fünf Einheiten im fünften Stock eingestellt hatte, war der Ansicht, dass das Neustart der Ausrüstung eines bestimmten Schalters im fünften Stock den Netzwerkfehler vorübergehend wiederherstellen könnte.
Nach einer halben Stunde würde der gleiche Netzwerkfehler jedoch wieder auftauchen.
In Anbetracht dieses spezifischen Phänomens vermutete ich, dass es sich um einen Netzwerk -Rundfunksturm handelt, der für einen bestimmten Zeitraum eine Überlastung im Schalter verursachte und letztendlich den entsprechenden Schalteranschluss am Kernschalter blockierte.
Um die Analyse des Fehlers zu erleichtern, habe ich Netzwerküberwachungstools verwendet, um die Netzwerkpaketübertragung an den Kaskadenanschlüssen des Schalters im fünften Stock zu analysieren.
Die Ergebnisse zeigten, dass sowohl der eingehende als auch der ausgehende Paketverkehr extrem hoch waren und fast das 100 -fache der Normalwerte fast übertrafen. Dies zeigte das Auftreten von Netzwerküberlastungen im Netzwerk im vierten Stock.
Ist die durch ein Netzwerkvirus verursachte Netzwerküberlastung?
Oder wird es durch eine Netzwerkschleife verursacht?
Ich habe vor, die Änderungen der Statusinformationen der Kaskadenanschlüsse des fehlerhaften Switchs zu beobachten, insbesondere die Änderungen in den Ausgabebraditionspaketen. Wenn die Ausgabepakete in jeder Sekunde steigen, ist es sehr wahrscheinlich, dass im Netzwerk im fünften Stock eine Netzwerkschleife vorhanden ist.
Basierend auf diesem Analyseansatz habe ich mithilfe eines Konsolensteuerkabels direkt an den fehlerhaften Schalter verbunden und als Systemadministrator in das System -Backend angemeldet.
Mit dem Befehl "Anzeige" habe ich die Änderungen in den Ausgabeträgerpaketen der Cascade -Ports des Schalters überprüft, die Ergebnisse jede Sekunde untersucht und verglichen.
Nach wiederholten Tests stellte ich fest, dass die Größe der Ausgangsübertragungspakete aus dem fehlerhaften Schalter tatsächlich ständig zunahm.
Dies weist darauf hin, dass es in den fünf Einheiten im fünften Stock definitiv eine Netzwerkschleife gibt.
Bei sorgfältiger Untersuchung der beiden Schalter im fünften Stock stellte ich fest, dass ihre physische Verbindung normal war.
Darüber hinaus wurden die verschiedenen Schaltanschlüsse dieser beiden Schalter direkt an die Wall -Netzwerk -Steckdosen in den Räumen im fünften Stock angeschlossen.
Theoretisch sollte es keine Netzwerkschleife geben, solange die Räume keine Schalter für nicht autorisierte Kaskadierung verwenden.
Nach dem Nachweis, dass es im Netzwerk im fünften Stock eine Netzwerkschleife gibt, bedeutet dies, dass jemand willkürlich Switches verwendet, um das Netzwerk zu erweitern. Indem wir den erweiterten Schalter finden und seine physischen Verbindungen inspizieren, können wir den spezifischen fehlerhaften Knoten schnell identifizieren.
Also habe ich die Netzwerkadministratoren der verschiedenen Einheiten im fünften Stock telefonisch kontaktiert und sie aufgefordert, jeden Büroraum zu inspizieren und die Zimmer mit untergeordneten Schalter zu melden.
Es dauerte nicht lange, bis die Inspektionsergebnisse mir gemeldet wurden, und überraschenderweise verwendeten rund 10 Räume untergeordnete Schalter für die Netzwerkausdehnung.
Zu diesem Zeitpunkt wusste ich, dass es in diesen 10 Räumen eine hohe Wahrscheinlichkeit einer Netzwerkschleife gab. Aber welcher Raum genau?
Muss ich jeden Raum besuchen und ihre Netzwerkverbindungen einzeln inspizieren?
Nach sorgfältiger Überlegung habe ich die Netzwerkdokumentation abgerufen und die von diesen 10 Räumen verwendeten Portnummern identifiziert.
Als nächstes habe ich mich direkt angeschlossenNetzwerkkabelZu diesen Ports und im Ansichtsmodus dieser Ports habe ich die IP -Adresse des fehlerhaften Switch nacheinander gepingt.
Als ich den sechsten Hafen erreichte, stellte ich fest, dass er nicht erfolgreich pinged werden konnte.
Um festzustellen, ob dieser Port tatsächlich problematisch war, habe ich den Befehl "Anzeige" im Ansichtsmodus des Ports verwendet, um seine Statusinformationen zu überprüfen.
Nach der Analyse der Ergebnisse stellte ich fest, dass die Eingangs- und Ausgangspaketgrößen dieses Ports signifikant abnormal waren. Daher schätzte ich, dass dieser Port definitiv die Ursache für den abnormalen Arbeitsstatus des fehlerhaften Schalters war.
Nachdem ich mich auf die Dateidatensätze bezogen hatte, habe ich den entsprechenden Raum basierend auf dieser Portnummer schnell identifiziert.
Bei der Ankunft am Tatort stellte ich fest, dass die beiden verfügbaren Netzwerkanschlüsse in diesem Raum mit kleinen Hubs verbunden waren und diese beiden Hubs mit mehreren Computern verbunden waren.
Um die Sache noch schlimmer zu machen, gab es ein Netzwerkkabel, das es direkt miteinander verband und eine Netzwerkschleife zwischen den beiden Hubs erstellt hat.
Diese Schleife verursachte einen Rundfunksturm, der letztendlich den Cascade -Port des fehlerhaften Switch blockierte und das gesamte Gebäudenetzwerk nicht ordnungsgemäß auf das Internet zugreifen kann.
3.. Fehlerbehebung:
Nachdem ich das zusätzliche Netzwerkkabel entfernt hatte, habe ich die Statusinformationen des Switch -Ports überprüft. Die Ergebnisse zeigten, dass die Eingangs- und Ausgangspaketgrößen wieder normal waren.
Als ich den Status des entsprechenden Ports im Kernschalter erneut überprüfte, stellte ich fest, dass sich der vorherige "Down" -Sstatus in den Status "Up" geändert hatte. Zu diesem Zeitpunkt konnte ich auch den fehlerhaften Schalter im vierten Stock erfolgreich durchführen.
Dies bestätigt, dass das Problem tatsächlich durch die nicht autorisierte Verwendung eines Schalters oder eines Hubs eines Benutzers in einem der Räume im fünften Stock verursacht wurde. Später erfuhr ich durch weitere Untersuchung mit Internetnutzern, dass ihre Zimmer in der Nacht zuvor und zu dieser Zeit alles gereinigt wurdenEthernet -Kabelwurden ausgesteckt.
Nachdem die Reinigungsarbeiten abgeschlossen waren, haben sie aufgrund der begrenzten Kenntnisse der Benutzer über Verbindungen die Kabel nach dem Zufallsprinzip wieder verbunden, was zu einer Netzwerkschleife führte. Als Netzwerkingenieure müssen wir uns daher auch bei der Durchführung von Wartungsprojekten bewusst sein.
Der nächste streifen:Rackschrank verstehen
