18.11.2023

8151

Netzwerkproblem, teilweise völliger Stillstand für Sekunden

Guten Morgen Zusammen,

ich bin Admin eines kleineren Unternehmens, wir haben im Schnitt ca 110 aktive Nodes im Netzwerk.
Seit geraumer Zeit haben wir Probleme mit der Netzwerkperformance. Hauptsächlich bemerken das die Kolleginnen in der "Druckstube", diese arbeiten mit Win 10 Clients auf denen eine unter Access 2010 programmierte Umgebung via Codesoft Etikettvorlagen aus einer Datenbank befüllt. Das funktioniert grundsätzlich trotz des alters der Software sehr zuverlässig.
Allerdings bekommen die Damen regelmäßig über den Tag verteilt Fehlermeldungen (Laufzeitfehler, Server nicht gefunden, Datenbank nicht erreicht).
Interessanterweise ist es aber nicht darauf beschränkt. Ich habe zum Beispiel bei mir am Rechner schon öfter gesehen, dass in der Konsole vom Backup auf HD via Robocopy der Prozentzähler einfach mal für ca 1-6 Sekunden stehen bleibt.
Auf tritt gefühlt oft eine Verzögerung beim auflisten in Netzwerkfreigaben auf.
Als ob das Netz kurze Zeit völlig still steht.

Hier mal die technischen groben Details zur Ausstattung:
4 Server physisch, 10 insgesamt (6 auf virualisierungshost):
2 Fileserver, physisch
1 "Dienste" Server für Kleinkram wie Lizenzdienste und Zeiterfassung
1 Virtualisierungshost für Domaincontroller, Datenbankserver, Linux Server für interne Webanwendung

Dazu diverse NAS für Videoüberwachung und Backup.
Internetzugang über OPNSense Firewall
Netzwerkhardware komplett erneuert im Sommer, alles Gigabit bzw 10 GB zwischen den Switchen und Servern.
Clients ne bunte Mischung aus allem Möglichen.

Wie gesagt, ich kann nicht festmachen dass der Fehler nur zwischen bestimmten Clients und Severn auftritt, es scheint eben als ob das ganze Netz stillsteht.

Wäre für eure Ideen dazu sehr Dankbar.

Danke schon mal vorab und schönes Wochenende

Ralph

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 9156586000

Url: https://administrator.de/contentid/9156586000

Ausgedruckt am: 22.11.2024 um 19:11 Uhr

28 Kommentare

Neuester Kommentar

Moin,

Fangen wir erstmal an der Basis an:
Was für Switche (Hersteller und Modell)?
Kommen LAGs (zwischen den Switchen) zum Einsatz?
Habt ihr in VLANs segmentiert?
Wenn ja, wer routet?

Greifen die Kollegen über gemappe Laufwerke (also K:\Datenbank\theShit.mdb) auf die DB zu oder per UNC (\\HolyServer\Shares\Datenbank\theShit.mdb) zu? Wenn ersteres, Laufwerk per GPO erstellt?

Rstp arbeitet korrekt?

Moin

Zitat von @8585324113:

Rstp arbeitet korrekt?

+1 für (R)STP.

Kannst du in die Logs der Switches schauen? Finden sich dort „topology change“-Ereignisse? Könnte auf einen flappenden Port hindeuten.

Macht ihr Netzwerk-Monitoring bzw. würden eure Switches ein solches unterstützen? Mit beispielsweise LibreNMS kannst recht schnell erfassen, was in deinem Netzwerk losgeht, gerade die Portauslastung finde ich dort charmant gelöst. So könntest du auch eine Überlastung z.B. durch ungefilterten Multicast-Traffic erkennen. Vermutlich würde der aber bezogen auf dein konkretes Problem länger als ein paar Sekunden dauern.

Zu LibreNMS gab es erst vor kurzem eine Artikel in der IT-Administrator 9/23.

Grüße
TA

Zitat von @em-pie:

Moin,

Fangen wir erstmal an der Basis an:
Was für Switche (Hersteller und Modell)?
Kommen LAGs (zwischen den Switchen) zum Einsatz?
Habt ihr in VLANs segmentiert?
Wenn ja, wer routet?

Greifen die Kollegen über gemappe Laufwerke (also K:\Datenbank\theShit.mdb) auf die DB zu oder per UNC (\\HolyServer\Shares\Datenbank\theShit.mdb) zu? Wenn ersteres, Laufwerk per GPO erstellt?

Switche sind von TP-Link, Modell wie folgt:
Serverschrank und neue Hall sind TL-SG3428X v1.0
Patchfeld Oben und Unten sind TL-SG3452X v1.0
Verbindung siehe Bild anbei, die Switche sind jeweils über 10Gb Glasfaser verbunden.
Vom Serverschrank zum Patchfeld oben, von dort jeweils per Glasfaser an Patchfeld unten und zur neuen Halle.

LAG nein
VLAN auvh nein

Laufwerke sind gemappt über X:, die Datenbanken sind in Access und Codesoft jeweils per UNC angebunden.

Es sei dazugesagt, die Probleme merkt man oft auch beim laden von Webseiten, deutlich bei Zugriffen auf unser neues ERP System (Web-basiert).
Nur die armen Kolleginnen beim drucken bekommen immer Fehlermeldung, für alle anderen entsteht halt ne kurze Netzwerkgedenksekunde.

Zitat von @8585324113:

Rstp arbeitet korrekt?

Ich hoffe doch, seit gestern habe ich den Omada Controller von TP-Link am laufen und damit zumindest eine zentrale Verwaltung für die Switche. Aktiviert ist Rstp jedenfalls.

Zitat von @TwistedAir:

Moin

Zitat von @8585324113:

Rstp arbeitet korrekt?

Grüße
TA

Werde ich mir am Montag mal näher anschauen.
Netzwerkmonitoring seit gestern über die Funktionen des Omada Controllers von TP-Link

Ich möchte noch anmerken dass die Probleme auch schon da waren vor Austausch der gesamten Switche.
Ich denke also mal nicht an Hardwareprobleme.

Was mir auffällt, wenn ich die Switche neu starte, dann ist relativ normaler "Verkehr" an den LED zu sehen, nach kurzer Zeit fangen dann alle gleichmäßig an zu blinken, als ob da dauernd Brodcasts laufen.
Laut Aktivitätsmonitor haben die Switche aber nicht viel zu tun. Auch kann icg hier keine Peaks entdecken, die sich mit den Aussetzern in Verbindung bringen lassen würden.

Die Performance im Netz ist auch so weit gut, kopieren z.B. großer Dateien läuft entsprechend Gigabit Verbindung flott, nur eben mit zeitweisen aussetzern ..

Gucke in Log und höre auf zu spielen.

Switches werden nicht neu gestartet.

Zitat von @8585324113:

Gucke in Log und höre auf zu spielen.

Switches werden nicht neu gestartet.

Doch, zum Beispiel bei Updates oder wenn der Switch meint am Controller festzuhängen, wenn die Verkabelung im Schrank mal neu gemacht wird ..
Zum Spaß sicher nicht

Zitat von @Kamillenbluetenjunkie:

Switche sind von TP-Link, Modell wie folgt:
Serverschrank und neue Hall sind TL-SG3428X v1.0
Patchfeld Oben und Unten sind TL-SG3452X v1.0
Verbindung siehe Bild anbei, die Switche sind jeweils über 10Gb Glasfaser verbunden.
Vom Serverschrank zum Patchfeld oben, von dort jeweils per Glasfaser an Patchfeld unten und zur neuen Halle.

LAG nein
VLAN auvh nein

Netzwerkmonitoring seit gestern über die Funktionen des Omada Controllers von TP-Link

Gut, die Switches können wenigstens SNMP - wenn der Omada Controller nicht genügend Informationen rausrückt (kenne das Teil nicht), hättest du darüber noch einen Ansatz.
Achte bei der Log-Auswertung auch auf Port-down/ups, die ggf. ein topology change verursachen.

Eingangs hattest du Videoüberwachung erwähnt - senden die einen permanenten Stream, wieviele Kameras gibt es und wie hoch ist dann die Bandbreite in Summe für diesen Anwendungsfall?

Als Anregung für dein Netzwerkdesign:

Du könntest je nach den baulichen Voraussetzungen die Switches untereinander mit zwei Glasfasern verbinden und ein LAG drüber bilden. Dann fliegt dir nicht das Netzwerk auseinander, wenn eine Verbindung Schwierigkeiten macht.
Das Netzwerk mit VLANs segmentieren, bspw. ein VLAN für Server und Speicher, Clients und die Videoüberwachung. Vorteil ist, dass Probleme entweder nur in dem jeweiligen Segment auftauchen oder über das gesamte Netzwerk wirken - was dann auch wieder eine Aussage ist.

Schon die alten Römer wussten: „Teile und herrsche!“

Schöne WE
TA

Zitat von @TwistedAir:

Netzwerkmonitoring seit gestern über die Funktionen des Omada Controllers von TP-Link

Du könntest je nach den baulichen Voraussetzungen die Switches untereinander mit zwei Glasfasern verbinden und ein LAG drüber bilden. Dann fliegt dir nicht das Netzwerk auseinander, wenn eine Verbindung Schwierigkeiten macht.
Das Netzwerk mit VLANs segmentieren, bspw. ein VLAN für Server und Speicher, Clients und die Videoüberwachung. Vorteil ist, dass Probleme entweder nur in dem jeweiligen Segment auftauchen oder über das gesamte Netzwerk wirken - was dann auch wieder eine Aussage ist.

Schon die alten Römer wussten: „Teile und herrsche!“

Schöne WE
TA

Der Omada SDN Controller ist bei mir als Software installiert auf einer VM mit Linux. Es gibt den Controller auch als Hardware von TP-Link. Genutzt wird das Sytsem zur Verwaltung von TP-Link Produkten.
Nur Log Dateien habe ich da bisher nicht entdeckt. Werde am Montag mal einen Syslog Server einrichten, damit sollte Omada dann auch Logs wegschreiben wenn ich das richtig verstanden habe.
Sobald ich die Logs habe werde ich mal nach den genannten Einträgen suchen.

Die Videoüberwachung läuft in einem komplet eigenen Netz.

Auf jeden Fall werde ich das machen mit den Verbindungen und LAG, zumindest im Serverraum zwischen den 3 Switchen, die Verbindung neue Halle ist leider nur einfach ausgeführt derzeit.

VLAN Einrichtung steht ebenfalls auf der ToDo Liste

Deine Idee mit dem LAG macht in der Regel RSTP Probleme nicht besser.

Die Logs bekommst du aus dem Switch.

Deine Idee mit dem LAG macht in der Regel RSTP Probleme nicht besser.

Zumindestens nicht solange der TO keinen RSTP Root Switch mit entsprechender globaler STP Priority im Netz definiert hat und durchgehend RSTP auf ALLEN Switches aktiviert hat um sicher Loops ausschliessen zu können.

Ein ideales, redundantes Ethernet Allerwelts Standard Netzdesign, was man wenn auch nur genähert immer umsetzen sollte, sähe so z.B. aus:

Es hat mich sehr überrascht, aber da switch erzählt etwas über "show logging" über seinen Log.
https://static.tp-link.com/2020/202011/20201103/1910012903_T16_T26_UG.pd ...

Part 14 dreht sich um den Baum, den es möglichweise zu oft unbeabsichtigt schüttelt.
Mit ein paar BPDU-Sachen kann das Gert auch was anfangen. BPDU kann auch unschöne Folgen haben für Port und Bridges. di gehen aber in der Regel nicht in Sekunden weg.

Ich werfe einmal meine 5 Cents als Denkanstoß in den Ring:

In den vergangenen zwei vielleicht drei Jahren konnte ich das vom TO beschriebene Phänomen hier ähnlich beobachten. Vor allem fiel es beim Surfen im Internet auf, wenn eine Seite neugeladen oder eine neue Seite aufgerufen wurde, dass es dann irgendwie einige Sekunden dauerte, bis sich nach dem Start des Neuladens/Aufrufens irgendetwas bewegte - und zwar egal, ob Windows oder Linux auf den Clients / Servern läuft. Alles schien darauf hinzudeuten, dass die DNS-Auflösung lange Zeit braucht. Jedoch war nicht wirklich etwas erkennbar, was die Ursache sein könnte. Die DNS-Server (alles DC's) waren ordnungsgemäß konfiguriert und zeigten keine wirklich erkennbaren Auffälligkeiten. Die Logs liefen unauffällig durch.

Aufgrund der Livebeobachtung der Logs des unter Linux laufenden named war ich in gewisserweise überrascht, wie intensiv die Clients und Server immer wieder in sehr kurzen Abständen dieselben DNS-Anfragen abrufen. Gegebenenfalls kann dabei erkannt werden, ob unauflösbare DNS-Anfragen aufschlagen, so dass dagegen Abhilfe geschaffen werden kann und was den Netzwerkverkehr reduzieren würde.
Ein weiterer Gedanke war, dass die (alte) FortiGate im Laufe der Zeit vielleicht etwas schmalbrüstig geworden ist, zumal die Filterlogik über die Jahre immer umfangreicher geworden ist. Aber auch dort ließen sich keine greifbaren Hinweise in den Logs entdecken.

Die Konstellation war ein Windows-AD mit zwei Samba-DC's (1x FSMO-Rollen und 1x "BDC") und einem Windows-DC (2008R2; "BDC"). Nunmehr gibt es diesen Windows-DC nicht mehr und es sind jetzt insgesamt vier Samba-DC's, wobei drei am Hauptstandort und einer am Nebenstandort (gab es zuvor auch nicht) werkeln. Die frühere Virtualisierung auf Hyper-V (2012R2) ist genauso restlos gegen QEMU/KVM auf Basis von Debian (12) eleminiert. Beide Standorte (einer Glasfaser und der andere VDSL) gehen mit virtualisierten OPNsense auf leistungsfähiger Hardware (u.a. Quad-Core-Xeon-CPU's) ins Internet.

In den letzten zwei bis drei Monaten, also seit die geänderte Struktur besteht, tritt dieses Stillhalteproblem so nicht mehr auf. Deswegen in der Rückschau ein mutmaßender Gedanke: Der Windows-DC und vielleicht auch der Hyper-V könnten aufgrund ihres betagten Daseins eine Störquelle gewesen sein.

Lange Rede kurzer Sinn: Es könnte wegen dieses Erfahrungsbildes interessant sein, einmal in diese Richtung zu schauen, ob es dort irgendwelche Hinweise geben könnte. Vor allem die DNS-Auflösung näher anschauen, weil der DNS-Anfrage-Verkehr wohl einen nicht unerheblichen Umfang haben kann, insbesondere wenn leerlaufende Anfragen immer wieder / permanent gestellt werden.

Viele Grüße
HansDampf06

Moin,
Bezieht sich das Problem auf den gesamten Netzwerktraffic?

Ich hatte mal ein ähnliches Problem, da wurden die Netzwerklaufwerke per gpo eingebunden und aufgrund des Modus in der gpo gab es regelmäßige Reconnects und eine Datenbankanwendung hat sich jedes Mal verabschiedet. Details erinnere ich mich nicht mehr wirklich dran.

Er und wir kennen das Problem der Ursache nach nicht.

Der To wäre gut beraten systematisch und den Layern folgenden zu suchen.

Moin.

Zitat von @Matzewo:

Moin,
Bezieht sich das Problem auf den gesamten Netzwerktraffic?

Ich hatte mal ein ähnliches Problem, da wurden die Netzwerklaufwerke per gpo eingebunden und aufgrund des Modus in der gpo gab es regelmäßige Reconnects und eine Datenbankanwendung hat sich jedes Mal verabschiedet. Details erinnere ich mich nicht mehr wirklich dran.

Ach, meinst du vielleicht die Problematik mit Laufwerk erstellen/ersetzen/aktualisieren? Auch ein sehr interessanter Punkt, den der TO verfolgen könnte.

Beispiele und deren Auswirkungen exemplarisch hier:
GPUPDATE trennt manuell eingebundenes Laufwerk
Netzlaufwerke via GPO
Netzlaufwerke verschwinden (teilweise)
GPO: Laufwerkszuordnung geht immer wieder kurz verloren

Grüße
TA

Das gleiche hatten wir auch nach Wechsel unserer Switche mit 10gbit zwischen den Switchen.

Am Ende war das Problem, dass neben dem 10 GBit glasfaser noch bei einer Verbindung das alte 1 GBit Kupfer Kabel mit angesteckt war.

Uns hat hier geholfen, die 10 GBit links zu trennen, um dann festzustellen, dass die Switche dann immer noch erreichbar waren.

Wie gesagt exakt gleiches Fehlerbild mit TP-Link Büchsen.

Zitat von @Razor10021990:

Das gleiche hatten wir auch nach Wechsel unserer Switche mit 10gbit zwischen den Switchen.

Am Ende war das Problem, dass neben dem 10 GBit glasfaser noch bei einer Verbindung das alte 1 GBit Kupfer Kabel mit angesteckt war.

Uns hat hier geholfen, die 10 GBit links zu trennen, um dann festzustellen, dass die Switche dann immer noch erreichbar waren.

Wie gesagt exakt gleiches Fehlerbild mit TP-Link Büchsen.

Nun, dann hat euch das STP getriggert abzupatchen. STP kann auch indirekt helfen.

Moin,
ich erinnere mich an ein ähliches Problem im Subnet mit Easyflex (was auch Access als Basis hat).

Es lag damals vermutlich am den DNS Abfragen für die internen Server.
Wir haben das eigentliche Problem nie genau lokalisieren können, aber die Hosts-Datei hat bei uns geholfen.

Weitere Anregungen:
Hast du mal ping -t laufen lassen und gesehen, das wirklich Pakete verloren gehen ?
Wie ist IPv6 konfiguriert?
Es gibt Dienste, die V6 bevorzugen, auch wenn es nicht richtig eingerichtet ist ...

Viel Erfolg bei der Suche.

dass neben dem 10 GBit glasfaser noch bei einer Verbindung das alte 1 GBit Kupfer Kabel mit angesteckt war.

Na und?? Mit einem vernünftig konfigurierten Spanning Tree ist das doch kein Problem, ganz im Gegenteil, hat sogar noch Vorteile!
Der STP setzt den 1Gig Link in den Blocking Mode (schlechtere Metrik) und gut ist.
Im Gegenteil das ist das sogar ein Vorteil in Bezug auf die Redundanz, denn wenn die 10G Leitung mal ausfällt ist sofort die 1Gig Leitung wieder aktiv.
Was meinst du wie sonst redundante Netzwerke funktionieren?!

Der Fehler war dann ein simpler PEBKAC Fehler das du den Spanning Tree entweder gar nicht oder fehlerhaft konfiguriert hast!!
Frage zur Konfiguration von Switchen zur Vermeidung eines Loops bei redundanter Anbindung

Zitat von @aqui:

Der Fehler war dann ein simpler PEBKAC Fehler das du den Spanning Tree entweder gar nicht oder fehlerhaft konfiguriert hast!!

Viel mehr war das Problem halt in den Logs nicht nachvollziehbar. Und das Problem-Verhalten nicht nachvollziehbar sporadisch ohne konkreten Auslöser auftrat. Und nach ein paar Minuten dann auch wieder normal weiter funktioniert hat.

Das Gravierendes wie ein Spanning Tree Event nicht in den Logs steht kann üblicherweise nicht sein! Die werden deshalb immer geloggt weil es ja essentielle Infrastruktur Events sind die das gesamte Netzwerk betreffen und für einen Admin wichtig sind. Kein Hersteller unterdrückt sowas nichtmal die Chinesen Billigteile aus dem Blödmarkt sofern sie STP können. Aber egal...

So, dann möchte ich mal ein Update geben, ich war ja nicht untätig die letzten Tage.

Die vollständigen Aussetzer sind jetzt behoben, Schuld war hier eine Mischung aus falschem/nicht konfiguriertem STP, Fehlern im DNS, Fehlern in der Konfiguration der Netzwerkschnittstellen am Hyper-V Server und einem "bösartigen" Switch.
Hintergrund war, wir hatten durch Neubau/Umbau dieses Jahr so viel zu tun, dass beim aufrüsten und erweitern des Netzwerks alles nur ausgepackt und zusammengesteckt wurde.
Und da gab es diesen einen Switch, der einsam und alleine im Haustechnikraum hängt und bisher nur eine Aufagbe hatte:
Verbindung der Glasfaser vom Neubau zum Serverraum
Das Miststück muss wohl schonn mal konfiguriert worden sein, denn ein Hinzufügen zum Omada Controller von TP-Link war nicht möglich. Oder Defekt, wer weiß. Weil der sich auch keine IP geholt hatte per DHCP, so wie die anderen Switche ab Werk. Erst nach Werkseinstellung an der Konsole verhält der sich normal.

Außerdem konnte ich der GL gleich noch in dem Zuge die Hardware ableiern für Aufrüstung der Server auf 10 Gb Verbindung.

Vielen Dank für Eure Hilfe!