11
Cisco SG500 Series LAG hat sich von selbst umgestellt
Hallo zusammen,
ich habe eine LWL LAG aus 2 Trunks welche sich über Nacht vom aktiv/aktiv Betrieb in den aktiv/standby Betrieb geschaltet hat. Ersichtlich wurde dies primär durchs Monitoring und auch optisch am gbic Port selbst. Der Link ist voll da aber es geht halt nichts mehr drüber.
Kennt jemand vielleicht die Ursache? Im Switch Log kann ich auf beiden Seiten keinen Eintrag zu den Ports finden.
Vielen Dank
ich habe eine LWL LAG aus 2 Trunks welche sich über Nacht vom aktiv/aktiv Betrieb in den aktiv/standby Betrieb geschaltet hat. Ersichtlich wurde dies primär durchs Monitoring und auch optisch am gbic Port selbst. Der Link ist voll da aber es geht halt nichts mehr drüber.
Kennt jemand vielleicht die Ursache? Im Switch Log kann ich auf beiden Seiten keinen Eintrag zu den Ports finden.
Vielen Dank
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: 327228
Url: https://administrator.de/contentid/327228
Printed on: April 24, 2024 at 16:04 o'clock
11 Comments
Latest comment
Das ist recht verwirrend was du da schilderst. 
Generell gibt es im Bereich von 802.3ad / LACP LAGs sowas wie active/active oder aktiv/standby Betrieb überhaupt nicht. In so fern ist es vollkommen unverständlich was du hier eigentlich schildern willst.
Was es lediglich gibt ist der LACP Active oder Passive Mode aber ob das was damit zu tun hast was du uns hier schildern willst weiss nur der Wind...?
Vielleicht solltest du mal etwas präziser werden damit wir hier alle wissen worum es eigentlich geht...
Generell gibt es im Bereich von 802.3ad / LACP LAGs sowas wie active/active oder aktiv/standby Betrieb überhaupt nicht. In so fern ist es vollkommen unverständlich was du hier eigentlich schildern willst.
Was es lediglich gibt ist der LACP Active oder Passive Mode aber ob das was damit zu tun hast was du uns hier schildern willst weiss nur der Wind...?
Vielleicht solltest du mal etwas präziser werden damit wir hier alle wissen worum es eigentlich geht...
Moin,
zum einen, siehe aquis Kommentar
zum Anderen:
was sagen die ErrorCounter auf den LWL-Ports?
Wenn die zu hoch sind bzw. in kürzester Zeit weiter steigen, müsstest du mal schauen, ob dieses LWL-Kabel noch i.O. ist...
Gruß
em-pie
zum einen, siehe aquis Kommentar
zum Anderen:
was sagen die ErrorCounter auf den LWL-Ports?
Wenn die zu hoch sind bzw. in kürzester Zeit weiter steigen, müsstest du mal schauen, ob dieses LWL-Kabel noch i.O. ist...
Gruß
em-pie
achso! Ich dachte aktiv/passiv Betrieb gibt es auch bei LACP LAGs . Ich habe 2 Strecken von Switch zu Switch. Pro Switch waren beide Ports in einer LAG. Im Monitoring konnte ich auch prima sehen, dass sich der Traffic auf beide Leitungen verteilt hat. Laut den beiden Switches war auch alles okay.
Jetzt steht bei beiden Geräten in der LAG Gruppe jeweils ein "Active Member" und "Standby Member". Der Standby Member macht dementsprechend auch genau nichts. Daher ging davon aus LAG Gruppen untestützen eben jenen aktiv/passiv Betrieb. Jetzt bin ich verwirrt.
Jetzt steht bei beiden Geräten in der LAG Gruppe jeweils ein "Active Member" und "Standby Member". Der Standby Member macht dementsprechend auch genau nichts. Daher ging davon aus LAG Gruppen untestützen eben jenen aktiv/passiv Betrieb. Jetzt bin ich verwirrt.
Update: Packet Errors habe ich keine.
achso! Ich dachte aktiv/passiv Betrieb gibt es auch bei LACP LAGs .
Ja, genau DAS steht ja auch oben !!! Wenn man denn mal liest...Du aber redest ja von active/stanby und sowas gibt es in dem Umfeld nicht !!
Normal sind bei LAGs die mit LACP laufen beide Partner im Active Mode !
Sie handeln dann dynamisch aus wer beim Link Aggregation den aktiven und den passiven Part übernimmt.
Na klar kann man das auch vorgeben indem man das explizit setzt. Der gravierende Nachteil ist dann aber das wenn man mal 2 Partner zusammenbringt die im Passive Mode laufen kommen die niemals zueinander.
Deshalb sollte man IMMER wenn irgend möglich beide Seiten im Active Mode laufen lassen.
In sehr seltenen Fällen scheitert zw. solchen beidseitig im Active Mode arbeitenden Partnern mal die Negotiation und dann hilft in der Regel eine Seite auf Passive zu setzen. Welche muss man ausprobieren.
Beim LAG gibt es de facto KEIN Standby !
Standy und solche Bezeihnungen kommen nur vor wenn man mit Link Redundanz arbeitet. Sowas gibt es z.B. bei Microsoft.
Dort kann man einen Rechner mit 2 NICs redundant an einen Switch anbinden auf Bais der Link Redundanz. Es gibt da einen Promary Link und einen Secondary. Relevant ist der physische Status des Primary Links.
Geht dort der physische Link weg wird der Secondary Link aktiviert. Kommt der Link des Promary wieder, geht der Secondary wieder down (Standby)
Das war in netzwerk Steinzeiten mal eine machbare Redundanz. Großer Nachteil ist das ein Link nie aktiv genutzt wird und nur nutzlos rumdümpelt und wartet das der andere ausfällt was (fast) nie passiert.
802.3ad LAGs mit LACP sind da erheblich sinnvoller.
Sie haben nicht nur die Link Redundanz sondern nutzen über ein Hashing auch aktiv beide Links zur Datenübertragung.
Deshalb nutzt mal heutzutage immer 802.3ad/LACP LAGs und nicht diesen Blödsinn mit active und standby Links.
Solche simplen Binsenweisheiten sollte man aber kennen als Netzwerk Admin ?!
Ruhig Blut aqui !
Wenn ich in meine LAG Gruppe gehe steht da nun mal knallhart Standby Member. Sorry dass ich das einfach so übernommen habe. Okay dann läuft meine LAG im aktiv/passiv Mode.
Du hast ja Recht, dass Standby Links nicht gerade effektiv sind aber es gibt nunmal auch Gerätschaften die nichts anderes können UND aktiv/aktiv nicht gewünscht ist (z.B. im WAN).
Cheers.
Wenn ich in meine LAG Gruppe gehe steht da nun mal knallhart Standby Member. Sorry dass ich das einfach so übernommen habe. Okay dann läuft meine LAG im aktiv/passiv Mode.
Du hast ja Recht, dass Standby Links nicht gerade effektiv sind aber es gibt nunmal auch Gerätschaften die nichts anderes können UND aktiv/aktiv nicht gewünscht ist (z.B. im WAN).
Cheers.
Bin immer tiefentspannt. War nur die Grundlagenerklärung für dich 
Welches Endgerät kann denn heutzutage KEINE LACP LAGs oder wenigstens statische LAGs ? Sowas gibts doch gar nicht mehr !
Im WAN greifen so oder so wieder völlig andere Mechanismen, sprich VRRP usw.
Welches Endgerät kann denn heutzutage KEINE LACP LAGs oder wenigstens statische LAGs ? Sowas gibts doch gar nicht mehr !
Im WAN greifen so oder so wieder völlig andere Mechanismen, sprich VRRP usw.
Sophos UTM :P
Vielleicht hat sich auch ein GBIc verabschiedet.
Hast du die Möglichkeit, mal einen/ beide GBICs zu ersetzen?
Oder hast du die Möglichkeit, ein anderes LWL-Phasernpaar zu verwenden?
Oder hast du schonmal versucht, den Problem-Port aus der LAG (auf beiden Seiten) zu entfernen und wieder einzubinden?
Wenn du das versuchst, pass aber auf, denn wenn du keine Vorkehrungen (STP aktiv oder eine Seite vom Switch trennen) triffst, baust du hier einen Loop!
Hast du die Möglichkeit, mal einen/ beide GBICs zu ersetzen?
Oder hast du die Möglichkeit, ein anderes LWL-Phasernpaar zu verwenden?
Oder hast du schonmal versucht, den Problem-Port aus der LAG (auf beiden Seiten) zu entfernen und wieder einzubinden?
Wenn du das versuchst, pass aber auf, denn wenn du keine Vorkehrungen (STP aktiv oder eine Seite vom Switch trennen) triffst, baust du hier einen Loop!
Kommando zurück: die UTM kann natürlich aktiv/aktiv. Aber in meiner Konfig sorgt das nur für Probleme. Aber ist ja wurscht jetzt :D
Ich habe gerade gesehen, dass es einen "reactivate suspende lag" flag im Webinterface gibt. Das werde ich mal testen. Gbics habe ich zur Not auch da.
Ich kann und will da aber im live betrieb nichts umstellen. Danke schon mal für die hilfe. Ich denke es liegt entweder an den gbics oder am Switch, da die Firmware älter ist.
Ich habe gerade gesehen, dass es einen "reactivate suspende lag" flag im Webinterface gibt. Das werde ich mal testen. Gbics habe ich zur Not auch da.
Ich kann und will da aber im live betrieb nichts umstellen. Danke schon mal für die hilfe. Ich denke es liegt entweder an den gbics oder am Switch, da die Firmware älter ist.
Switch Stack neugestartet, Leitung wieder da.
