4
Unverständliche Meldung STP Loopback Detection
Kein Zugriff von Switch 2 auf Geräte/Server an Switch 1
Hallo,
habe beim Kunden zwei Switche (1.: AT-8000GS/48 und 2.: AT-8000S/24), die mit genau einem LWL-Kabel verbunden sind.
Jetzt ist es zwei mal passiert, dass nach 20:00 Uhr die Verbindung zwischen den beiden Switchen weg war.
Nach dem ersten mal hab ich auf den Switchen Syslog aktiviert, nach dem zweiten mal darin einige Einträge gefunden, die mir unverständlich sind:
Der Port g48 ist der LWL-Port an Switch 1, von dem die Leitung zum zweiten Switch geht. Im Falle des Ausfalls, können alle Geräte am zweiten Switch nicht mehr auf die Server am ersten Switch zugreifen.
Ich bin mir ganz sicher, dass es keine zweite Verbindung zwischen den Switchen gibt, die Grund für STP ist, den Port g48 zu blocken.
Kann irgend ein Endgerät den Switch zu solch einer Aktion 'verleiten'?
Ich hab das Problem erst einmal gelöst, in dem ich auf dem ersten Switch das STP deaktiviert habe. Seit dem gibt es die oben beschriebenen Probleme nicht mehr. Aber ich verstehe trotzdem nicht, wie das Problem entsteht, weil ich viele solche Konfigurationen kenne, wo ein solches Problem nicht existiert.
Hat jemand einen Hinweis für mich?
Schon mal vielen Dank und Grüße
LS
habe beim Kunden zwei Switche (1.: AT-8000GS/48 und 2.: AT-8000S/24), die mit genau einem LWL-Kabel verbunden sind.
Jetzt ist es zwei mal passiert, dass nach 20:00 Uhr die Verbindung zwischen den beiden Switchen weg war.
Nach dem ersten mal hab ich auf den Switchen Syslog aktiviert, nach dem zweiten mal darin einige Einträge gefunden, die mir unverständlich sind:
10.03.2011 20:17:38 %STP-W-PORTSTATUS: g48: STP status Blocking
10.03.2011 20:17:38 %STP-W-LOOPBACKDET: g48: STP Loopback Detection.
...
11.03.2011 00:25:07 %STP-W-LOOPBACKDETRSLV: g48: STP Loopback Detection resolved.
11.03.2011 00:25:22 %STP-W-PORTSTATUS: g48: STP status Forwarding
...Ich bin mir ganz sicher, dass es keine zweite Verbindung zwischen den Switchen gibt, die Grund für STP ist, den Port g48 zu blocken.
Kann irgend ein Endgerät den Switch zu solch einer Aktion 'verleiten'?
Ich hab das Problem erst einmal gelöst, in dem ich auf dem ersten Switch das STP deaktiviert habe. Seit dem gibt es die oben beschriebenen Probleme nicht mehr. Aber ich verstehe trotzdem nicht, wie das Problem entsteht, weil ich viele solche Konfigurationen kenne, wo ein solches Problem nicht existiert.
Hat jemand einen Hinweis für mich?
Schon mal vielen Dank und Grüße
LS
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 162582
Url: https://administrator.de/contentid/162582
Printed on: April 19, 2024 at 02:04 o'clock
4 Comments
Latest comment
Ja, aber nur wenn dieses Endgerät auch STP spricht. Der STP Status ist auf Blocking gegangen, was bedeutet das irgendjemand in dem Netz ein Loop gesteckt hat oder einen anderen STP Switch mit höherer Priority (default ist 32000) angeklemmt hat.
Dein Problem ist auch vermutlich das du den Switches keine STP Priority gegeben hast um einen dediziert als STP Root Switch zu selektieren. Damit besteht auch die Gefahr das jemand einen anderen Switch mit höherer Priority anklemmt und deinen STP durcheinenaderbringt was vermutlich auch passiert ist. Genausogut kann das eine fehlkonfigurierte Aggregation verbindung sein. Das lässt sich letztlich aus der STP meldung nicht mehr feststellen.
Unverständlich ist die Meldung jedenfalls nicht, sondern eine klassische Port STP Statusmeldung.
STP zu deaktivieren ist laienhaft und auch gefährlich. Damit setzt du dich der Gefahr aus das ein Dau oder andere einen Loop stecken und das ganze Netz dann kollabiert ohne das man das dann schnell finden kann.
Warum solche Meldungen auftauchen erklärt dir das STP Protokoll selber:
http://de.wikipedia.org/wiki/Spanning_Tree_Protocol
Dein Problem ist auch vermutlich das du den Switches keine STP Priority gegeben hast um einen dediziert als STP Root Switch zu selektieren. Damit besteht auch die Gefahr das jemand einen anderen Switch mit höherer Priority anklemmt und deinen STP durcheinenaderbringt was vermutlich auch passiert ist. Genausogut kann das eine fehlkonfigurierte Aggregation verbindung sein. Das lässt sich letztlich aus der STP meldung nicht mehr feststellen.
Unverständlich ist die Meldung jedenfalls nicht, sondern eine klassische Port STP Statusmeldung.
STP zu deaktivieren ist laienhaft und auch gefährlich. Damit setzt du dich der Gefahr aus das ein Dau oder andere einen Loop stecken und das ganze Netz dann kollabiert ohne das man das dann schnell finden kann.
Warum solche Meldungen auftauchen erklärt dir das STP Protokoll selber:
http://de.wikipedia.org/wiki/Spanning_Tree_Protocol
Hallo aqui,
vielen Dank für die Infos, das hilft mir erst einmal weiter (auf die Idee mit zusätzlichen Switch und höherer Prio bin ich nicht gekommen). Werde Deine Hinweise ernst nehmen
vG
LS
vielen Dank für die Infos, das hilft mir erst einmal weiter (auf die Idee mit zusätzlichen Switch und höherer Prio bin ich nicht gekommen). Werde Deine Hinweise ernst nehmen
vG
LS
Setz einen der AT-8000er auf die STP Prio 128 im Setup und den anderen auf 1024. Dann hast du einen dedizierten Root Switch und einen backup Root und dann passiert das auch nicht wieder.
Sofern die AT-8000er Gurken natürlich keinen STP Firmware Bug haben....?!
Sofern die AT-8000er Gurken natürlich keinen STP Firmware Bug haben....?!
Hallo aqui,
nochmals vielen Dank für die Infos!
(AT hat bei den Netzwerkprofis wohl keinen guten Ruf? Was sollte man denn stattdessen nehmen HP/3Com, Dell, Cisco, ...?)
vG
LS
nochmals vielen Dank für die Infos!
(AT hat bei den Netzwerkprofis wohl keinen guten Ruf? Was sollte man denn stattdessen nehmen HP/3Com, Dell, Cisco, ...?)
vG
LS
