24
100MBit und Gigabit Mischbetrieb ergibt sporadische Netzausfälle
Ich habe seit einigen Tagen zwei Gigabit Switches in mein Netzwerk integriert, sowie ein neues Notebook mit W-LAN N. Seit dem habe ich sporadisch Netzausfälle die ich mir noch nicht erklären kann. Ich vermute, der Mischbetrieb und Ethernet flow control könnten daran schuld sein.
Hallo,
zuerst mal mein Netzaufbau (Geräte die zum fraglichen Zeitpunkt offline waren, sind nicht erwähnt):
1. Switch, Netgear ProSafe GS108 (8x1GBit/s)
- FritzBox 7270, nur Internet Gateway (kein W-LAN), integrierter Switch, 100MBit/s
- FritzBox 7170, W-LAN AccessPoint (g-Betrieb), integrierter Switch, 100MBit/s
- Windows Server 2008 PC, Fileserver, Webserver, DHCP usw..., 1GBit/s
- QNAP 419P, NAS, 1GBit/s
- Switch 2, 1GBit/s
2. Switch, Netgear ProSafe GS108 (8x1GBit/s)
- Desktop PC, 1GBit/s
- Desktop PC, 1GBit/s
- Desktop PC, 100MBit/s
- Switch 1, 1GBit/s
- Switch 3, 100MBit/s
3. Switch, keine Herstellerangabe (16x100MBit/s)
- DLink DIR-615, W-LAN AccesPoint (g/n-Betrieb), integrierter Switch, 100MBit/s
- LogiLink Wirleless N Router (g/n-Betrieb), integrierter Switch, 100MBit/s
- Desktop PC, 100MBit/s
- Switch 2, 100MBit/s
- Switch 4, 100MBit/s
4. Switch, keine Herstellerangabe (5x100MBit/s)
- FritzBox 3030, W-LAN AccessPoint (g-Betrieb), 100MBit/s
- Switch 3, 100MBit/s
Dazu zwei Notebooks, zum Problemzeitpunkt vermutlich verbunden mit dem DLink DIR-615. Eines davon kann n und war vermutlich auch im n-Betrieb (ist im selben Raum wie der AP). Das Zweite kann nur g.
Mein Problem ist jetzt, dass es vor ein paar Tagen einen Netzausfall gab.
Das heisst konkret, kein Gerät konnte mehr ein anderes Gerät erreichen. Ich habe Pings von PCs an Switch 2 zu Switch 2, 1 und 3 getestet. Auch brach mein Webserver zusammen, Switch 1 hat also ebenfalls nicht mehr zwischen Server und FritzBox vermittelt. Ich hab an einem PC an Switch 2 Wireshark gestartet und konnte keine eingehenden Pakete sehen. Nur ausgehende Broadcasts. Kein Switch hing. Die LEDs blinkten normal (es gingen also Daten ein, aber nicht übermäßig viele). Ich vermute, die Switches haben die Pakete nicht weitergeleitet?!
Das ging so gute 15 Minuten lang, zumal ich erstmal garnicht wusste, wie das Problem zu beheben ist, da ich via Ethernet keines der Geräte erreichen konnte.
Letztendlich löste sich das Problem in Luft auf, als ich die Verbindung zwischen Switch 2 und 3 getrennt habe. Wieder verbunden, kam das Problem etwa 10min später wieder. Dann habe ich alle Ports an Switch 3 getrennt und der Reihe nach erst Switch 2 und dann die anderen Ports verbunden... das Problem kam aber dann 24h lang nicht mehr.
Am Tag drauf war das Problem erneut da. Diesmal hatte ich zur Diagnose den Laptop mit Wireshark an den DIR-615 via LAN angeschlossen und dessen W-LAN Verbindung (n-Betrieb) mit dem DIR-615 getrennt. Ich empfing ununterbrochen Ethernet flow control PAUSE Frames, gleichzeitig reagierte der DIR-615 nicht auf Pings. Ich trennte den DIR-615 vom 3. Switch und erhielt weiterhin die PAUSE Frames, das übrige Netzwerk funktionierte wieder. Zu dem Zeitpunkt war höchstens noch ein Notebook (nicht n fähig) via W-LAN mit dem DIR-615 verbunden. Letztendlich habe ich den DIR-615 vom Strom getrennt um den Spuk ein Ende zu bereiten.
Zusätzlich ist mir aufgefallen, dass das Notebook im n-Betrieb wenn es mit dem DIR-615 verbunden ist, manchmal (aber nicht immer) undglaublich schlechte Pings hat. Jeweils immer eine Zeitüberschreitung und dann einmal 300-800ms.
Das Ganze ist für mich relativ verwirrend, ich kann das Problem auch nicht reproduzieren.
Ich vermute eben, dass ein Gerät im LAN die PAUSE-Frames aussendet (der DIR-615?) und die anderen Switches darauf hin ihren Betrieb einstellen?! Wobei ich nicht verstehe, wieso alle Switches betroffen sind...
Lange Rede kurzer Sinn, wie gehe ich das Problem am schlauesten an? Wie finde ich heraus, welche Geräte PAUSE Frames selbst versenden, darauf reagieren (und wie) oder weiterleiten? Wie kann ich das Aussenden der Frames provozieren? Kann es sein, dass Wireshark die PAUSE Frames bei Netzwerkkarten welche Flow Control unterstützen nicht anzeigen kann, weil sie schon hardwaremäßig gefiltert werden?
Sollte ich Flow Control bei allen Endgeräten die es mir anbieten deaktivieren?
An meinem Server war Flow Control deaktiviert.
An meinem PC, auf dem beim ersten mal Wireshark lief, war Flow Control aktiv.
Die PAUSE Frames hatten die Sender-MAC 00:03:64:00:00:00 (Scenix Semiconductor Inc), kann ich so spontan leider keinem der Geräte zuordnen.
Wäre für Tipps dankbar. Dachte nicht, dass das so kompliziert sein kann
Edit: geforderte Skizze zum Netzaufbau:
http://img171.imageshack.us/img171/3240/netm.png
Hallo,
zuerst mal mein Netzaufbau (Geräte die zum fraglichen Zeitpunkt offline waren, sind nicht erwähnt):
1. Switch, Netgear ProSafe GS108 (8x1GBit/s)
- FritzBox 7270, nur Internet Gateway (kein W-LAN), integrierter Switch, 100MBit/s
- FritzBox 7170, W-LAN AccessPoint (g-Betrieb), integrierter Switch, 100MBit/s
- Windows Server 2008 PC, Fileserver, Webserver, DHCP usw..., 1GBit/s
- QNAP 419P, NAS, 1GBit/s
- Switch 2, 1GBit/s
2. Switch, Netgear ProSafe GS108 (8x1GBit/s)
- Desktop PC, 1GBit/s
- Desktop PC, 1GBit/s
- Desktop PC, 100MBit/s
- Switch 1, 1GBit/s
- Switch 3, 100MBit/s
3. Switch, keine Herstellerangabe (16x100MBit/s)
- DLink DIR-615, W-LAN AccesPoint (g/n-Betrieb), integrierter Switch, 100MBit/s
- LogiLink Wirleless N Router (g/n-Betrieb), integrierter Switch, 100MBit/s
- Desktop PC, 100MBit/s
- Switch 2, 100MBit/s
- Switch 4, 100MBit/s
4. Switch, keine Herstellerangabe (5x100MBit/s)
- FritzBox 3030, W-LAN AccessPoint (g-Betrieb), 100MBit/s
- Switch 3, 100MBit/s
Dazu zwei Notebooks, zum Problemzeitpunkt vermutlich verbunden mit dem DLink DIR-615. Eines davon kann n und war vermutlich auch im n-Betrieb (ist im selben Raum wie der AP). Das Zweite kann nur g.
Mein Problem ist jetzt, dass es vor ein paar Tagen einen Netzausfall gab.
Das heisst konkret, kein Gerät konnte mehr ein anderes Gerät erreichen. Ich habe Pings von PCs an Switch 2 zu Switch 2, 1 und 3 getestet. Auch brach mein Webserver zusammen, Switch 1 hat also ebenfalls nicht mehr zwischen Server und FritzBox vermittelt. Ich hab an einem PC an Switch 2 Wireshark gestartet und konnte keine eingehenden Pakete sehen. Nur ausgehende Broadcasts. Kein Switch hing. Die LEDs blinkten normal (es gingen also Daten ein, aber nicht übermäßig viele). Ich vermute, die Switches haben die Pakete nicht weitergeleitet?!
Das ging so gute 15 Minuten lang, zumal ich erstmal garnicht wusste, wie das Problem zu beheben ist, da ich via Ethernet keines der Geräte erreichen konnte.
Letztendlich löste sich das Problem in Luft auf, als ich die Verbindung zwischen Switch 2 und 3 getrennt habe. Wieder verbunden, kam das Problem etwa 10min später wieder. Dann habe ich alle Ports an Switch 3 getrennt und der Reihe nach erst Switch 2 und dann die anderen Ports verbunden... das Problem kam aber dann 24h lang nicht mehr.
Am Tag drauf war das Problem erneut da. Diesmal hatte ich zur Diagnose den Laptop mit Wireshark an den DIR-615 via LAN angeschlossen und dessen W-LAN Verbindung (n-Betrieb) mit dem DIR-615 getrennt. Ich empfing ununterbrochen Ethernet flow control PAUSE Frames, gleichzeitig reagierte der DIR-615 nicht auf Pings. Ich trennte den DIR-615 vom 3. Switch und erhielt weiterhin die PAUSE Frames, das übrige Netzwerk funktionierte wieder. Zu dem Zeitpunkt war höchstens noch ein Notebook (nicht n fähig) via W-LAN mit dem DIR-615 verbunden. Letztendlich habe ich den DIR-615 vom Strom getrennt um den Spuk ein Ende zu bereiten.
Zusätzlich ist mir aufgefallen, dass das Notebook im n-Betrieb wenn es mit dem DIR-615 verbunden ist, manchmal (aber nicht immer) undglaublich schlechte Pings hat. Jeweils immer eine Zeitüberschreitung und dann einmal 300-800ms.
Das Ganze ist für mich relativ verwirrend, ich kann das Problem auch nicht reproduzieren.
Ich vermute eben, dass ein Gerät im LAN die PAUSE-Frames aussendet (der DIR-615?) und die anderen Switches darauf hin ihren Betrieb einstellen?! Wobei ich nicht verstehe, wieso alle Switches betroffen sind...
Lange Rede kurzer Sinn, wie gehe ich das Problem am schlauesten an? Wie finde ich heraus, welche Geräte PAUSE Frames selbst versenden, darauf reagieren (und wie) oder weiterleiten? Wie kann ich das Aussenden der Frames provozieren? Kann es sein, dass Wireshark die PAUSE Frames bei Netzwerkkarten welche Flow Control unterstützen nicht anzeigen kann, weil sie schon hardwaremäßig gefiltert werden?
Sollte ich Flow Control bei allen Endgeräten die es mir anbieten deaktivieren?
An meinem Server war Flow Control deaktiviert.
An meinem PC, auf dem beim ersten mal Wireshark lief, war Flow Control aktiv.
Die PAUSE Frames hatten die Sender-MAC 00:03:64:00:00:00 (Scenix Semiconductor Inc), kann ich so spontan leider keinem der Geräte zuordnen.
Wäre für Tipps dankbar. Dachte nicht, dass das so kompliziert sein kann
Edit: geforderte Skizze zum Netzaufbau:
http://img171.imageshack.us/img171/3240/netm.png
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 159163
Url: https://administrator.de/contentid/159163
Ausgedruckt am: 24.11.2024 um 22:11 Uhr
24 Kommentare
Neuester Kommentar
Hallo,
wenn ich deine Fehlerbeschreibung richtig interpretiere ist der noname Switch 3 zumindest derjenige der einen Teil dienes Problems verursacht.
Daher würde ich den als erstes mal gegen einen anderen Testweise tauschen.
Weiterhin würde ich an deiner Stell mal eine komplette Netzwerkskizze anfertigen um das ganze mal als ganzes Bild zu sehen, darin sollten die Ports und die angeschlossenen Geräte gekennzeichnet sein.
Sorgen machen mir auch die Switche ohne Hersteller Angaben. Sind das Switche oder alte Hubs?
Generell gilt aber immer das der langsamste Teilnehmer in einem Netzwerk die Geschwindigkeit vorgibt. (wAs nützen dir 1000 MBit wenn das WLAN nur 54 MBit schafft... )
brammer
wenn ich deine Fehlerbeschreibung richtig interpretiere ist der noname Switch 3 zumindest derjenige der einen Teil dienes Problems verursacht.
Daher würde ich den als erstes mal gegen einen anderen Testweise tauschen.
Weiterhin würde ich an deiner Stell mal eine komplette Netzwerkskizze anfertigen um das ganze mal als ganzes Bild zu sehen, darin sollten die Ports und die angeschlossenen Geräte gekennzeichnet sein.
Sorgen machen mir auch die Switche ohne Hersteller Angaben. Sind das Switche oder alte Hubs?
Generell gilt aber immer das der langsamste Teilnehmer in einem Netzwerk die Geschwindigkeit vorgibt. (wAs nützen dir 1000 MBit wenn das WLAN nur 54 MBit schafft... )
brammer
Kannst du mir ein kostenloses Tool für eine Skizze empfehlen? Ich hab das bisher nie gemacht und mit den Mitteln die mir bekannt sind sitze ich da sicher endlos dran ;) Da habe ich eigentlich keine Lust zu...
So kompliziert ists ja auch nicht... vier Switche in Reihe (so von oben nach unten wie ich beschrieben habe) und der einzige relevante AP sollte der DIR-615 an Switch 3 sein.
Bringen tut mir das Gigabit sehr viel, weil ich von meinen Desktop PCs die Gigabit können auf das NAS und den Server performant zugreiffen können muss. Für die Laptops ist das weniger relevant.
Wieso denkst du, der 3. Switch ist schuld? Ich denke eher der DIR-615 ist es...
Der 3. Switch hat zwar keinen Namen (billig bei Reichelt bestellt), war aber schon bevor ich die Gigabit Switches hatte 2 Jahre problemlos im Einsatz. Und ja, es sind Switches.
Ich habe eben versucht den Fehler zu provozieren... Mit netio zwischen dem Desktop-PC und dem Notebook mit W-LAN N getestet (UDP).
Die Verbindung war wie folgt:
PC mit 1GBit/s am Switch 2, Switch 2 mit 100MBit/s am Switch 3, Switch 3 mit 100MBit/s am DIR-615 und das Notebook mit 130MBit/s am DIR-615.
netio hat am PC mit ~990 MBit/s gesendet und am Notebook mit ~105 MBit/s... also jeweils über den 100MBit/s Flaschenhals (wenn auch knapp). Selbstverständlich gingen viele Pakete verloren, aber einen Netzausfall gab es nicht. Ich versuche das Notebook noch auf mehr als 130MBit/s zu bekommen und teste nochmal...
So kompliziert ists ja auch nicht... vier Switche in Reihe (so von oben nach unten wie ich beschrieben habe) und der einzige relevante AP sollte der DIR-615 an Switch 3 sein.
Bringen tut mir das Gigabit sehr viel, weil ich von meinen Desktop PCs die Gigabit können auf das NAS und den Server performant zugreiffen können muss. Für die Laptops ist das weniger relevant.
Wieso denkst du, der 3. Switch ist schuld? Ich denke eher der DIR-615 ist es...
Der 3. Switch hat zwar keinen Namen (billig bei Reichelt bestellt), war aber schon bevor ich die Gigabit Switches hatte 2 Jahre problemlos im Einsatz. Und ja, es sind Switches.
Ich habe eben versucht den Fehler zu provozieren... Mit netio zwischen dem Desktop-PC und dem Notebook mit W-LAN N getestet (UDP).
Die Verbindung war wie folgt:
PC mit 1GBit/s am Switch 2, Switch 2 mit 100MBit/s am Switch 3, Switch 3 mit 100MBit/s am DIR-615 und das Notebook mit 130MBit/s am DIR-615.
netio hat am PC mit ~990 MBit/s gesendet und am Notebook mit ~105 MBit/s... also jeweils über den 100MBit/s Flaschenhals (wenn auch knapp). Selbstverständlich gingen viele Pakete verloren, aber einen Netzausfall gab es nicht. Ich versuche das Notebook noch auf mehr als 130MBit/s zu bekommen und teste nochmal...
Hallo, für Skizzen benutze ich Networknotepad:
http://www.networknotepad.com/
Am Anfang etwas holprig, aber es ist soweit sehr brauchbar.
Lade Dir auf jeden Fall die zusätzlichen Objekt Bibliotheken mit herunter.
Gruß Daniel
http://www.networknotepad.com/
Am Anfang etwas holprig, aber es ist soweit sehr brauchbar.
Lade Dir auf jeden Fall die zusätzlichen Objekt Bibliotheken mit herunter.
Gruß Daniel
moin,
also ein Bild würde die Sache doch enorm vereinfachen. Hast du schon kontrolliert, ob du keine Redundanz zwischen x-Switchen hast? Dadurch könntest du dir dein gesamtes LAN lahmlegen.
Gruß
Cometcola
also ein Bild würde die Sache doch enorm vereinfachen. Hast du schon kontrolliert, ob du keine Redundanz zwischen x-Switchen hast? Dadurch könntest du dir dein gesamtes LAN lahmlegen.
Gruß
Cometcola
Bild ist da.
Du meinst eine Schleife? nein, habe ich nicht. Einen Broadcast Storm hätte ich ja schnell erkannt.
Du meinst eine Schleife? nein, habe ich nicht. Einen Broadcast Storm hätte ich ja schnell erkannt.
Na ja wenn Spanning Tree aktiv ist dann kann man es nicht lahmlegen !
Dein Problem ist mit Sicherheit das aktivierte 802.3x Flow Control. Hauptproblem bei Billigen Consumer Switches, wie deine es sind, ist geringer oder kein Pufferplatz pro Port (deshalb sind die Switches so billig) und einer Billig Implementierung des Flow Control Protokolls. Datenströme an NICs unterschiedlicher Geschwindigkeit von einer GiG NIC reissen meist alle GiG Ports mit auf die langsame Geschwindigkeit. Das ist bei 99% aller Billigswitches so und auch nicht managebaren GiG Switches mit permament aktivier Flow Control.
Berichte über lahme Performance in GiG Netzen mit Billigswitches liest man deshalb täglich hier im Forum !
Vergiss auch bitte nicht das für eine sauber funktionierende 802.3x Flow Control Umgebung immer Switchport UND auch korrespondierender NIC Port aktiv Flow Control aktiviert haben müssen, was niemand im realen Leben verifiziert, denn dafür müsstest du alle Endgeräte kontrollieren. Probleme gibts dann sofort bei HW die das gar nicht supportet wie Drucker usw.
Dummerweise gibt es zudem zig Billig NICs Chipsätze in deren Treiber Settings keinerlei Flow Control Schalter verfügbar sind und das hard gecodet ist, so das du nie weisst wie der Flow Control Status der NIC überhaupt ist.
Ein Mismatch kann aber fatale Folgen haben. Niemand kontrolliert das und das führt dann zu soclhen Verhalten wie auch du es siehst.
Deshalb gilt die goldene Regel bei kleinen Netzen mit Billigswitches wie deines: Immer Flow Control fest im Switch deaktivieren !
Die Default Flow Control im TCP gann das eh handhaben so das 802.3x in der Regel vollkommen überflüssig ist.
Schalte das also in allen Switches fest ab und gut ist.
Gekniffen bist du bei nicht managebare Billigteilen...da hilft dann nur der komplette Austausch.
Das deine managebaren Switches die aktuellste Firmware geflasht haben sollte sollte dir auch klar sein.
Dein Problem ist mit Sicherheit das aktivierte 802.3x Flow Control. Hauptproblem bei Billigen Consumer Switches, wie deine es sind, ist geringer oder kein Pufferplatz pro Port (deshalb sind die Switches so billig) und einer Billig Implementierung des Flow Control Protokolls. Datenströme an NICs unterschiedlicher Geschwindigkeit von einer GiG NIC reissen meist alle GiG Ports mit auf die langsame Geschwindigkeit. Das ist bei 99% aller Billigswitches so und auch nicht managebaren GiG Switches mit permament aktivier Flow Control.
Berichte über lahme Performance in GiG Netzen mit Billigswitches liest man deshalb täglich hier im Forum !
Vergiss auch bitte nicht das für eine sauber funktionierende 802.3x Flow Control Umgebung immer Switchport UND auch korrespondierender NIC Port aktiv Flow Control aktiviert haben müssen, was niemand im realen Leben verifiziert, denn dafür müsstest du alle Endgeräte kontrollieren. Probleme gibts dann sofort bei HW die das gar nicht supportet wie Drucker usw.
Dummerweise gibt es zudem zig Billig NICs Chipsätze in deren Treiber Settings keinerlei Flow Control Schalter verfügbar sind und das hard gecodet ist, so das du nie weisst wie der Flow Control Status der NIC überhaupt ist.
Ein Mismatch kann aber fatale Folgen haben. Niemand kontrolliert das und das führt dann zu soclhen Verhalten wie auch du es siehst.
Deshalb gilt die goldene Regel bei kleinen Netzen mit Billigswitches wie deines: Immer Flow Control fest im Switch deaktivieren !
Die Default Flow Control im TCP gann das eh handhaben so das 802.3x in der Regel vollkommen überflüssig ist.
Schalte das also in allen Switches fest ab und gut ist.
Gekniffen bist du bei nicht managebare Billigteilen...da hilft dann nur der komplette Austausch.
Das deine managebaren Switches die aktuellste Firmware geflasht haben sollte sollte dir auch klar sein.
Alles schön und gut, aber ich habe keine Performance Probleme gehabt, sondern es sind alle Switches komplett ausgefallen.
Und meine Tests mit netio haben gezeigt, dass ich zwischen zwei Gigabit Hosts auch das Gigabit schaffe und von Gigabit zu 100 MBits gab es ja im Test auch kein Problem.
Obwohl ich mit netio mit 1GBit/s auf einen via 100MBit/s angebundenen Laptop gesendet habe, hat der Gigabit Switch nicht gestreikt.
Was müsste ich denn deiner Meinung nach konkret tun, um einen weiteren Netzausfall zu provozieren?
Und meine Tests mit netio haben gezeigt, dass ich zwischen zwei Gigabit Hosts auch das Gigabit schaffe und von Gigabit zu 100 MBits gab es ja im Test auch kein Problem.
Obwohl ich mit netio mit 1GBit/s auf einen via 100MBit/s angebundenen Laptop gesendet habe, hat der Gigabit Switch nicht gestreikt.
Was müsste ich denn deiner Meinung nach konkret tun, um einen weiteren Netzausfall zu provozieren?
Moin,
also ich hätte noch eine Idee. Wie groß sind den die Entfernungen zwischen den einzelnen Switches? Kann irgendetwas deine Kupferleitungen sporadisch lahmegen ? Irgendwelche spannungsführenden Leitungen? Hast du die Leitungen mal mit einem Netzwerkanalysegerät untersucht? Beispielsweise mit einem Fluke?
Gruß
Cometcola
also ich hätte noch eine Idee. Wie groß sind den die Entfernungen zwischen den einzelnen Switches? Kann irgendetwas deine Kupferleitungen sporadisch lahmegen ? Irgendwelche spannungsführenden Leitungen? Hast du die Leitungen mal mit einem Netzwerkanalysegerät untersucht? Beispielsweise mit einem Fluke?
Gruß
Cometcola
Moin,
mit Ausnahme des Kabels zu Switch 4 sowie der Kabel zu dem PC und dem LogiLink an Switch 3 sind alle Kabel <10m. Insbesondere die Gigabit-Verbindungen nur etwa 5m und kleiner.
Physikalisch ist das Netz in Ordnung, denke ich. Ein physikalischer Ausfall eines Links würde sich ja anders bemerkbar machen. Ausserdem nicht alle Switches lahm legen sondern nur den betreffenden Link. In meinem Haus wird ja nicht täglich ein EMP gezündet
Gibt's denn Gründe überhaupt anzunehmen, dass die PAUSE Frames nicht die Ursache sind??
mit Ausnahme des Kabels zu Switch 4 sowie der Kabel zu dem PC und dem LogiLink an Switch 3 sind alle Kabel <10m. Insbesondere die Gigabit-Verbindungen nur etwa 5m und kleiner.
Physikalisch ist das Netz in Ordnung, denke ich. Ein physikalischer Ausfall eines Links würde sich ja anders bemerkbar machen. Ausserdem nicht alle Switches lahm legen sondern nur den betreffenden Link. In meinem Haus wird ja nicht täglich ein EMP gezündet
Gibt's denn Gründe überhaupt anzunehmen, dass die PAUSE Frames nicht die Ursache sind??
Kennt irgendjemand ein Tool mit dem ich selbst PAUSE Frames senden kann? Dann würde ich einfach mal schaun wie meine Geräte darauf reagieren...
Ich finde nur http://www.tux.org/pub/sites/www.zip.com.au/%257Eakpm/linux/#flow-ctrl aber das kompiliert nur mit dutzenden Fehlern und ich bin weder C noch Linux Freak :/
Ich finde nur http://www.tux.org/pub/sites/www.zip.com.au/%257Eakpm/linux/#flow-ctrl aber das kompiliert nur mit dutzenden Fehlern und ich bin weder C noch Linux Freak :/
Okay, ich habe jetzt mit PackETH die PAUSE Frames die ich beim letzten Ausfall empfangen habe über einen 100MBit/s Link an einen der GS108er Switche gesendet.
Ausserdem habe ich noch zwei 1GBit/s PCs an diesem Switch. Ich pinge vom 100er beide GBit PCs und die GBit PCs untereinander.
Die LED am 100er Port blinkt schnell (ich sende die PAUSE Frames mit 4MBit/s), die anderen nur langsam. Der Switch leitet die PAUSE Frames also nicht weiter (Wireshark bestätigt das). Ausserdem funktionieren alle Pings problemlos - der Switch hört also auch nicht auf, Pakete an den 100er Port durchzustellen?!
Ich versteh es nicht... Das Testergebnis hilft mir jetzt kein bisschen weiter
Vorschläge?
Nachtrag:
Auch wenn ich die PAUSE Frames sende, erreiche ich zwischen einem GBit/s PC und dem 100er laut netio gute 80MBit/s. Zwischen den Gigabit PCs gut 950MBit/s. Die Pings funktionieren auch alle.
Am Gigabit PC (flow control ausgeschaltet - ich hoffe dass so die Wahrscheinlichkeit geringer ist, dass die Hardware die PAUSE Frames rausfiltert und so in Wireshark auftauchen) gehen auch (laut Wireshark) keine PAUSE Frames ein, wenn dieser den Switch mit 1GBit/s zuballert obwohl die Daten an den 100er gehen. Egal ob ich die Frames am 100er sende oder nicht.
Ausserdem habe ich noch zwei 1GBit/s PCs an diesem Switch. Ich pinge vom 100er beide GBit PCs und die GBit PCs untereinander.
Die LED am 100er Port blinkt schnell (ich sende die PAUSE Frames mit 4MBit/s), die anderen nur langsam. Der Switch leitet die PAUSE Frames also nicht weiter (Wireshark bestätigt das). Ausserdem funktionieren alle Pings problemlos - der Switch hört also auch nicht auf, Pakete an den 100er Port durchzustellen?!
Ich versteh es nicht... Das Testergebnis hilft mir jetzt kein bisschen weiter
Vorschläge?
Nachtrag:
Auch wenn ich die PAUSE Frames sende, erreiche ich zwischen einem GBit/s PC und dem 100er laut netio gute 80MBit/s. Zwischen den Gigabit PCs gut 950MBit/s. Die Pings funktionieren auch alle.
Am Gigabit PC (flow control ausgeschaltet - ich hoffe dass so die Wahrscheinlichkeit geringer ist, dass die Hardware die PAUSE Frames rausfiltert und so in Wireshark auftauchen) gehen auch (laut Wireshark) keine PAUSE Frames ein, wenn dieser den Switch mit 1GBit/s zuballert obwohl die Daten an den 100er gehen. Egal ob ich die Frames am 100er sende oder nicht.
Was meinst du mit fehlerhaft? Fehlerhaft im Sinne von keiner Spezifikation entsprechend, oder dass PAUSE Frames gesendet werden, obwohl dies nicht notwendig wäre?
Letzteres habe ich ja vermutet, am DIR-615. Aber ich kann mir dann nicht erklären, dass das Aussenden der Frames an den Switch in meinem Test keinen Ausfall mehr provoziert hat.
Könntest du mir erklären, wie der Ausfall deiner Meinung nach konkret zustande kommen könnte?
Letzteres habe ich ja vermutet, am DIR-615. Aber ich kann mir dann nicht erklären, dass das Aussenden der Frames an den Switch in meinem Test keinen Ausfall mehr provoziert hat.
Könntest du mir erklären, wie der Ausfall deiner Meinung nach konkret zustande kommen könnte?
Also, es ist gerade wieder passiert....
Gegenüber der Konfiguration oben hat sich geändert, dass der DIR-615 jetzt an Switch 2 angeschlossen ist.
Während dem Ausfall waren mit dem DIR-615 ein MacBook (das ist gerade Gast im Haus und war bei den letzten Ausfällen nicht beteiligt!) und möglicherweise ein iPod via W-LAN verbunden.
Die LAN LEDs am DIR-615 sowie am Switch 2 haben schnell geblinkt. Die W-LAN LED am DIR-615 dagegen nicht, ebenso nicht die LAN LEDs der anderen Ports des Switch.
Ich vermute, am Link zwischen DIR-615 und Switch 2 wurden wieder einmal PAUSE Frames gesendet. Diesmal konnte ich leider kein Wireshark an den DIR-615 via LAN anklemmen.
Während des Ausfalls war keine Kommunikation zwischen den PCs an Switch 2 möglich, ebenso zwischen PCs an Switch 2 und dem Server an Switch 1, noch konnte der Server an Switch 1 mit dem Router an Switch 1 kommunizieren. Es war also wieder einmal das gesamte Netzwerk platt.
Ich hatte Wireshark an zwei PCs an Switch 2 laufen. Viele Daten gingen nicht ein, allerdings kamen Broadcasts von anderen PCs durch! (ARP Requests, einige UDP Broadcasts)
Nach 5min Ausfall habe ich den DIR-615 vom Switch 2 getrennt, das Netz ging sofort wieder.
Nachdem im gesamten Netz keine Kommunikation mehr möglich war, Broadcasts aber noch durch gingen, liegt nahe, dass die MAC Tabelle der Switches zugemüllt wurde. (korrekt?)
Jetzt stellt sich aber die Frage, wie kann das passieren?
Angenommen der DIR-615 dreht durch und sendet zufällig generierte Pakete (was meiner Beobachtung beim letzten mal widerspricht, da war es immer der selbe Ethernet PAUSE Frame, aber egal) die logischerweise auch zufällige MAC Adressen als Absender haben und keine gültigen Zieladressen, daher also gebroadcastet werden. Dadurch dürfte die gesamte MAC Tabelle von Switch 2 auf den Port zum DIR-615 hin auflösen, die des Switch 1 komplett auf den Port der zum Switch 2 geht. Beide Switche sind lahmgelegt. Soweit so gut und theoretisch im ersten Moment des Ausfalls denkbar.
Aber: Sobald ich den Ausfall bemerkt habe, habe ich ja Wireshark gestartet und die LEDs begutachtet. Zu diesem Zeitpunkt wurden an Switch 2 nur noch echte Broadcasts ausgesendet, keine Pakete mit ungültiger MAC Adresse. Switch 2 hätte also aus irgendeinem Grund aufgehört, die Pakete vom DIR-615 zu broadcasten. Switch 1 wäre also ebenfalls nicht mehr zugeballert worden und hätte sich wieder fangen müssen. Das tat er aber nicht! Obwohl von Switch 2 nahezu keine Pakete mehr ausgesendet wurden, war Switch 1 weiterhin tot.
Der DIR-615 ist ziemlich sicher die Ursache des Problems. Aber ich verstehe immernoch nicht, wie es entsteht :/
Gegenüber der Konfiguration oben hat sich geändert, dass der DIR-615 jetzt an Switch 2 angeschlossen ist.
Während dem Ausfall waren mit dem DIR-615 ein MacBook (das ist gerade Gast im Haus und war bei den letzten Ausfällen nicht beteiligt!) und möglicherweise ein iPod via W-LAN verbunden.
Die LAN LEDs am DIR-615 sowie am Switch 2 haben schnell geblinkt. Die W-LAN LED am DIR-615 dagegen nicht, ebenso nicht die LAN LEDs der anderen Ports des Switch.
Ich vermute, am Link zwischen DIR-615 und Switch 2 wurden wieder einmal PAUSE Frames gesendet. Diesmal konnte ich leider kein Wireshark an den DIR-615 via LAN anklemmen.
Während des Ausfalls war keine Kommunikation zwischen den PCs an Switch 2 möglich, ebenso zwischen PCs an Switch 2 und dem Server an Switch 1, noch konnte der Server an Switch 1 mit dem Router an Switch 1 kommunizieren. Es war also wieder einmal das gesamte Netzwerk platt.
Ich hatte Wireshark an zwei PCs an Switch 2 laufen. Viele Daten gingen nicht ein, allerdings kamen Broadcasts von anderen PCs durch! (ARP Requests, einige UDP Broadcasts)
Nach 5min Ausfall habe ich den DIR-615 vom Switch 2 getrennt, das Netz ging sofort wieder.
Nachdem im gesamten Netz keine Kommunikation mehr möglich war, Broadcasts aber noch durch gingen, liegt nahe, dass die MAC Tabelle der Switches zugemüllt wurde. (korrekt?)
Jetzt stellt sich aber die Frage, wie kann das passieren?
Angenommen der DIR-615 dreht durch und sendet zufällig generierte Pakete (was meiner Beobachtung beim letzten mal widerspricht, da war es immer der selbe Ethernet PAUSE Frame, aber egal) die logischerweise auch zufällige MAC Adressen als Absender haben und keine gültigen Zieladressen, daher also gebroadcastet werden. Dadurch dürfte die gesamte MAC Tabelle von Switch 2 auf den Port zum DIR-615 hin auflösen, die des Switch 1 komplett auf den Port der zum Switch 2 geht. Beide Switche sind lahmgelegt. Soweit so gut und theoretisch im ersten Moment des Ausfalls denkbar.
Aber: Sobald ich den Ausfall bemerkt habe, habe ich ja Wireshark gestartet und die LEDs begutachtet. Zu diesem Zeitpunkt wurden an Switch 2 nur noch echte Broadcasts ausgesendet, keine Pakete mit ungültiger MAC Adresse. Switch 2 hätte also aus irgendeinem Grund aufgehört, die Pakete vom DIR-615 zu broadcasten. Switch 1 wäre also ebenfalls nicht mehr zugeballert worden und hätte sich wieder fangen müssen. Das tat er aber nicht! Obwohl von Switch 2 nahezu keine Pakete mehr ausgesendet wurden, war Switch 1 weiterhin tot.
Der DIR-615 ist ziemlich sicher die Ursache des Problems. Aber ich verstehe immernoch nicht, wie es entsteht :/
Servus Admin,
ein paar Fragen.
1.) besteht das Problem noch ?
2.) Wie weit sind die Switche voneinander entfernt ?
3.) Ist das eine Privat- oder eine Firmenumgebung ?
4.) Warum verwendest Du einen solchen Namen ?
Ich fände es sympathischer, Dich mit einem richtigen Namen anzusprechen.
Gruß
Anton
ein paar Fragen.
1.) besteht das Problem noch ?
2.) Wie weit sind die Switche voneinander entfernt ?
3.) Ist das eine Privat- oder eine Firmenumgebung ?
4.) Warum verwendest Du einen solchen Namen ?
Ich fände es sympathischer, Dich mit einem richtigen Namen anzusprechen.
Gruß
Anton
Hi,
um das Thema nochmal auszugraben: Ja, es besteht immernoch.
Ich habe mittlerweile Switch 2 auch durch einen ProSafe GS108 ersetzt. Habe also nur noch drei ProSafe GS108 und einen alten 100MBit/s Switch im Netz. An letzterem ist nur ein W-LAN AccessPoint der bei uns im Keller steht und so gut wie nie genutzt wird. Man darf also davon ausgehen, dass über diesen Switch eigentlich keine Daten fließen.
Ich habe heute noch einmal den DIR-615 in Betrieb genommen (an Switch 3). Ein Notebook war über diesen mit dem Netzwerk verbunden. An diesem Notebook habe ich eine Videodatei, welche auf dem Server (Switch 1) liegt, encodet. Es gab also eine relativ konstante Datenübertragung von etwa 2MBit/s in beide Richtungen.
Selbiges habe ich auf meinem Arbeitsplatzrechner (Switch 2) gemacht, also ebenfalls ein Video encodet.
Nach etwa 30 Minuten brach das Netzwerk wieder komplett zusammen. Das Encoding an beiden Rechnern brach ab, weil die Datei vom Server nicht mehr gelesen werden konnte. Ebenso brach die Verbindung vom Server zum Internet ab.
Ich habe wieder mit Wireshark an Switch 2 und an Switch 3 sowie am integrierten Switch des DIR-615 gelauscht, konnte aber keine ungewöhnlichen Frames sehen.
Nachdem ich den DIR-615 vom Netz getrennt hatte, fing sich dieses sofort wieder.
Ich bin echt ratlos...
Um noch auf die anderen Fragen einzugehen:
2) 1-2: 5m; 2-3: 30cm (am 8er gingen die Ports aus, 16er war zu teuer); 3-4: 10m
3) privat
4) hab ich seit über 10 Jahren und bins gewohnt ;) darfst mich gern Andi nennen
Gruß,
Andi
um das Thema nochmal auszugraben: Ja, es besteht immernoch.
Ich habe mittlerweile Switch 2 auch durch einen ProSafe GS108 ersetzt. Habe also nur noch drei ProSafe GS108 und einen alten 100MBit/s Switch im Netz. An letzterem ist nur ein W-LAN AccessPoint der bei uns im Keller steht und so gut wie nie genutzt wird. Man darf also davon ausgehen, dass über diesen Switch eigentlich keine Daten fließen.
Ich habe heute noch einmal den DIR-615 in Betrieb genommen (an Switch 3). Ein Notebook war über diesen mit dem Netzwerk verbunden. An diesem Notebook habe ich eine Videodatei, welche auf dem Server (Switch 1) liegt, encodet. Es gab also eine relativ konstante Datenübertragung von etwa 2MBit/s in beide Richtungen.
Selbiges habe ich auf meinem Arbeitsplatzrechner (Switch 2) gemacht, also ebenfalls ein Video encodet.
Nach etwa 30 Minuten brach das Netzwerk wieder komplett zusammen. Das Encoding an beiden Rechnern brach ab, weil die Datei vom Server nicht mehr gelesen werden konnte. Ebenso brach die Verbindung vom Server zum Internet ab.
Ich habe wieder mit Wireshark an Switch 2 und an Switch 3 sowie am integrierten Switch des DIR-615 gelauscht, konnte aber keine ungewöhnlichen Frames sehen.
Nachdem ich den DIR-615 vom Netz getrennt hatte, fing sich dieses sofort wieder.
Ich bin echt ratlos...
Um noch auf die anderen Fragen einzugehen:
2) 1-2: 5m; 2-3: 30cm (am 8er gingen die Ports aus, 16er war zu teuer); 3-4: 10m
3) privat
4) hab ich seit über 10 Jahren und bins gewohnt ;) darfst mich gern Andi nennen
Gruß,
Andi
Servus Andi,
ich würde mal vermuten, Dein DIR615 hat eine Macke, oder ?
So wie Du das beschreibst. Nachdem Du den DIR615 aus dem Aufbau genommen hast, waren Deine Probleme verschwunden.
Wie alt ist das Teilchen ?
Ist der DIR-615 mit einem oder mehreren Netzwerkkabeln mit dem Switch verbunden ?
Das mit den 10m zwischen den Switchen ist sehr grenzwertig. Normalerweise verbinden man 2 100MBit/s Ports mit max. 5 metern, alles andere kann gehen muss aber nicht.
(Bevor jetzt wieder vielen heulen und diskutieren, ich hab die schmerzlichen Erfahrungen zu diesem Thema mit mehr als 600 Loaktionen gemacht.)
Gruß
Anton
ich würde mal vermuten, Dein DIR615 hat eine Macke, oder ?
So wie Du das beschreibst. Nachdem Du den DIR615 aus dem Aufbau genommen hast, waren Deine Probleme verschwunden.
Wie alt ist das Teilchen ?
Ist der DIR-615 mit einem oder mehreren Netzwerkkabeln mit dem Switch verbunden ?
Das mit den 10m zwischen den Switchen ist sehr grenzwertig. Normalerweise verbinden man 2 100MBit/s Ports mit max. 5 metern, alles andere kann gehen muss aber nicht.
(Bevor jetzt wieder vielen heulen und diskutieren, ich hab die schmerzlichen Erfahrungen zu diesem Thema mit mehr als 600 Loaktionen gemacht.)
Gruß
Anton
Die Frage ist doch, welche Macke hat der DIR615?! Und ich kann nicht glauben dass es Zufall ist dass die Probleme mit dem 100MBit/s Netz vorher nicht da waren. Dass der DIR 615 zufällig zur selben Zeit kaputt gegangen ist halte ich für unwahrscheinlich.
Und vor allem: Welchen Defekt soll er denn bitte haben, dass er auch noch den über- und überübernächsten in Reihe angeschlossenen Switch lahmlegen kann?! Und das ohne auffällige Frames in Wireshark?
Der DIR-615 ist natürlich nur mit einem Kabel verbunden, sonst gäbs nen Loop.
Und die 10m sind nun wirklich nicht grenzwertig. Hast du vielleicht Telefonkabel statt Netzwerkkabel verlegt?
Und vor allem: Welchen Defekt soll er denn bitte haben, dass er auch noch den über- und überübernächsten in Reihe angeschlossenen Switch lahmlegen kann?! Und das ohne auffällige Frames in Wireshark?
Der DIR-615 ist natürlich nur mit einem Kabel verbunden, sonst gäbs nen Loop.
Und die 10m sind nun wirklich nicht grenzwertig. Hast du vielleicht Telefonkabel statt Netzwerkkabel verlegt?
Servus Andi,
aber nun mal ehrlich, wenn Du den DIR-615 vom Netz trennst und alle Deine Probleme sind wie weggeblasen, was ist es dann ?
Zu Deiner Frage:
Nein, ich habe keine Telefonkabel verlegt, sondern Cat.5 Cat.6, Cat6a, Cat7, geschirmt mit allem schnickschnack.
Also glaube mir, wenn ich sage, 10 m Cu Kabel zwischen 2 Switchen mit 100 Mbit/s oder mehr sind grenzwertig.
Mit dieser Aussage treffe ich keine Annahmen Richtung Clients.
d.h., Kabel vom Patchfeld zur Dose 90m und je Seite 5 m zum PC, Drucker oder was sonst noch am Netz ist.
also insgesamt max. 100m.
Noch ein Gedanke:
Was wurde am Netz geändert, bevor diese Probleme auftraten ?
Was wurde an der Umgebung geändert, bevor diese Probleme auftraten ?
Nichts kann nicht sein, sonst hättest Du keine Probleme
Gruß
Anton
aber nun mal ehrlich, wenn Du den DIR-615 vom Netz trennst und alle Deine Probleme sind wie weggeblasen, was ist es dann ?
Zu Deiner Frage:
Nein, ich habe keine Telefonkabel verlegt, sondern Cat.5 Cat.6, Cat6a, Cat7, geschirmt mit allem schnickschnack.
Also glaube mir, wenn ich sage, 10 m Cu Kabel zwischen 2 Switchen mit 100 Mbit/s oder mehr sind grenzwertig.
Mit dieser Aussage treffe ich keine Annahmen Richtung Clients.
d.h., Kabel vom Patchfeld zur Dose 90m und je Seite 5 m zum PC, Drucker oder was sonst noch am Netz ist.
also insgesamt max. 100m.
Noch ein Gedanke:
Was wurde am Netz geändert, bevor diese Probleme auftraten ?
Was wurde an der Umgebung geändert, bevor diese Probleme auftraten ?
Nichts kann nicht sein, sonst hättest Du keine Probleme
Gruß
Anton
Wenn dein Auto 3 Tage lang problemlos läuft aber am 4. Tag einfach nicht starten will, kaufst du dir dann sofort ein neues? Nein.
Ich will das Problem verstehen können. Der DIR-615 ist sicher nicht einfach nur "Defekt", manchmal geht er ja Tagelang problemlos im Netz. Ich vermute mehr ein Systematisches Problem.
Was geändert wurde habe ich schon breit getreten. Erst habe ich das Netz um zwei GBit/s Switche erweitert, dann den 16er durch einen 8er GBit/s ersetzt. Ausserdem kam ein n-fähiges Notebook dazu.
Ich will das Problem verstehen können. Der DIR-615 ist sicher nicht einfach nur "Defekt", manchmal geht er ja Tagelang problemlos im Netz. Ich vermute mehr ein Systematisches Problem.
Was geändert wurde habe ich schon breit getreten. Erst habe ich das Netz um zwei GBit/s Switche erweitert, dann den 16er durch einen 8er GBit/s ersetzt. Ausserdem kam ein n-fähiges Notebook dazu.
Hallo,
Ich habe mal in grauer Vorzeit gelernt Cat5 Kabel ginge bis 100m.
Wieso sollte es also bei 10m grenzwertig sein?
brammer
Also glaube mir, wenn ich sage, 10 m Cu Kabel zwischen 2 Switchen mit 100 Mbit/s oder mehr sind grenzwertig.
Ich habe mal in grauer Vorzeit gelernt Cat5 Kabel ginge bis 100m.
Wieso sollte es also bei 10m grenzwertig sein?
brammer
Hallo brammer,
Cat.5 Verkabelungen gehen vom Patchfeld bis zur Dose 90m plus jeweils 5 m für Parchkabel je Ende. (soweit so gut )
Wenn man dann noch mit einrechnet, dass 2 Stationen max. ca. 200 m voneinander entfernt sein dürfen,
und wenn Du dann sagst man kann Switche mit 100 m Kupferkabel verbinden, dann sind wir bei 300 m und nichts geht mehr.
Gruß
Anton
Cat.5 Verkabelungen gehen vom Patchfeld bis zur Dose 90m plus jeweils 5 m für Parchkabel je Ende. (soweit so gut )
Wenn man dann noch mit einrechnet, dass 2 Stationen max. ca. 200 m voneinander entfernt sein dürfen,
und wenn Du dann sagst man kann Switche mit 100 m Kupferkabel verbinden, dann sind wir bei 300 m und nichts geht mehr.
Gruß
Anton
Servus Andi,
dann auf ein neues.
Kannst Du mal bitte Deine Skizze soweit ergänzen, dass Du bitte mit einträgst, welches Gerät welche IP-Adresse hat,
und was für eine Default-GW an jedem der Geräte, Server, PCs Notebooks, Switche, DIR-615 etc eingetragen ist ?
Wenn es keine Layer-2 Problme ist, wie Du vermutest, kann es neu ein Layer-3 Problem (also IP-Ebene) sein.
Danke
Gruß
Anton
dann auf ein neues.
Kannst Du mal bitte Deine Skizze soweit ergänzen, dass Du bitte mit einträgst, welches Gerät welche IP-Adresse hat,
und was für eine Default-GW an jedem der Geräte, Server, PCs Notebooks, Switche, DIR-615 etc eingetragen ist ?
Wenn es keine Layer-2 Problme ist, wie Du vermutest, kann es neu ein Layer-3 Problem (also IP-Ebene) sein.
Danke
Gruß
Anton
Hallo,
Cat5e Kabel ist bis 100 m zugelassen.
Entweder hast du alle 100m einen Signal Verstärkendes (aufbereitendes) Gerät oder du gehst das Risiko ein das deine Kommunikation unzuverlässig wird und du nicht reproduzierbare Fehler hast.
Wie du die 300 m rechnest ist mir unklar.
Außerdem bezieht sich meine Aussage auf deine >10m<
Wo das Grenzwärtig ist ist mir unklar!
brammer
Cat5e Kabel ist bis 100 m zugelassen.
Entweder hast du alle 100m einen Signal Verstärkendes (aufbereitendes) Gerät oder du gehst das Risiko ein das deine Kommunikation unzuverlässig wird und du nicht reproduzierbare Fehler hast.
Wie du die 300 m rechnest ist mir unklar.
Außerdem bezieht sich meine Aussage auf deine >10m<
Wo das Grenzwärtig ist ist mir unklar!
brammer
Hallo brammer,
ich sagte:
PC - 5m Dose - Patchfeld 90m Pachfeld - Switch 5m = 100m
Swich 5m Patchfeld 90m Dose 5m Switch = 100m
Switch 5m Patchfeld 90m Dose 5m Cient = 100m
macht summasumarum 300 m
Außerdem kannst Du max 5 aktive Geräte (Switchte, Bridges) hintereinander schlaten.
Gruß
Anton
Aber wir weichen vom Thema ab.
ich sagte:
PC - 5m Dose - Patchfeld 90m Pachfeld - Switch 5m = 100m
Swich 5m Patchfeld 90m Dose 5m Switch = 100m
Switch 5m Patchfeld 90m Dose 5m Cient = 100m
macht summasumarum 300 m
Außerdem kannst Du max 5 aktive Geräte (Switchte, Bridges) hintereinander schlaten.
Gruß
Anton
Aber wir weichen vom Thema ab.
