7
Cisco SG350X - Link bricht weg, wenn LAG aktiviert wird
Hallo zusammen,
habe hier 2x SG350XG-24F die als Stack konfiguriert im Serverraum laufen.
An 2 Etagenverteilern (2.OG, 3.OG) habe ich je 2 SG350X-24P als Stack konfiguriert.
Die Switche im 2.OG sind per LAG an den Core-Switch angebunden.
Die Switche im 3.OG verlieren den Link sobald ich die LAG am Core-Switch konfiguriere.
Die Einstellungen der Switche bzgl. LAG sind identisch und ich hab keine Ahnung, woran es noch liegen kann.
So viele Möglichkeiten bzgl. der LAGs gibt es jetzt ja nicht.
Alle Switche haben die selbe Firmware und haben einen 10G Link zum Core-Stack.
Mir fällt noch folgendes auf:
Auf dem Access-Stack konfiguriere ich die LAG und erhalten daraufhin folgendes:
Active-Member - XG1/3
Standby-Member - XG1/4
Zu diesem Zeitpunkt ist auf dem Core noch kein LAG für die Ports konfiguriert.
Konfiguriere ich hier die entsprechenden Ports in der LAG, verliere ich direkt die Verbindung zum Access-Switch.
Selbige ist sofort wieder da, wenn ich die LAG am Core-Deaktiviere.
Lt. Log am Access-Switch könnte es etwas mit der Auto-Negotiation zu tun zu haben.
Vielen Dank im voraus!
habe hier 2x SG350XG-24F die als Stack konfiguriert im Serverraum laufen.
An 2 Etagenverteilern (2.OG, 3.OG) habe ich je 2 SG350X-24P als Stack konfiguriert.
Die Switche im 2.OG sind per LAG an den Core-Switch angebunden.
Die Switche im 3.OG verlieren den Link sobald ich die LAG am Core-Switch konfiguriere.
Die Einstellungen der Switche bzgl. LAG sind identisch und ich hab keine Ahnung, woran es noch liegen kann.
So viele Möglichkeiten bzgl. der LAGs gibt es jetzt ja nicht.
Alle Switche haben die selbe Firmware und haben einen 10G Link zum Core-Stack.
Mir fällt noch folgendes auf:
Auf dem Access-Stack konfiguriere ich die LAG und erhalten daraufhin folgendes:
Active-Member - XG1/3
Standby-Member - XG1/4
Zu diesem Zeitpunkt ist auf dem Core noch kein LAG für die Ports konfiguriert.
Konfiguriere ich hier die entsprechenden Ports in der LAG, verliere ich direkt die Verbindung zum Access-Switch.
Selbige ist sofort wieder da, wenn ich die LAG am Core-Deaktiviere.
Lt. Log am Access-Switch könnte es etwas mit der Auto-Negotiation zu tun zu haben.
2147483145 2018-Nov-06 12:56:46 Warning %STP-W-PORTSTATUS: Po1: STP status Forwarding
2147483146 2018-Nov-06 12:56:45 Informational %LINK-I-Up: Vlan 30
2147483147 2018-Nov-06 12:56:45 Informational %LINK-I-Up: Vlan 11
2147483148 2018-Nov-06 12:56:45 Informational %LINK-I-Up: Vlan 10
2147483149 2018-Nov-06 12:56:45 Informational %LINK-I-Up: Vlan 2
2147483150 2018-Nov-06 12:56:45 Informational %LINK-I-Up: Vlan 1
2147483151 2018-Nov-06 12:56:45 Informational %LINK-I-Up: Po1
2147483152 2018-Nov-06 12:56:45 Informational %TRUNK-I-PORTADDED: Port te1/0/3 added to Po1
2147483153 2018-Nov-06 12:56:41 Informational %2SWTRUNK-I-TRNKPORTPARAM: auto-negotiation/adv. capabilities of port te1/0/4 differ from auto-negotiation/adv. capabilities of Po1
2147483154 2018-Nov-06 12:56:41 Informational %2SWTRUNK-I-TRNKPORTPARAM: auto-negotiation/adv. capabilities of port te1/0/3 differ from auto-negotiation/adv. capabilities of Po1
2147483155 2018-Nov-06 12:56:40 Informational %LINK-I-Up: te1/0/4
2147483156 2018-Nov-06 12:56:40 Informational %LINK-I-Up: te1/0/3
2147483157 2018-Nov-06 12:56:19 Informational %2SWTRUNK-I-TRNKPORTPARAM: auto-negotiation/adv. capabilities of port te1/0/4 differ from auto-negotiation/adv. capabilities of Po1
2147483158 2018-Nov-06 12:56:19 Informational %2SWTRUNK-I-TRNKPORTPARAM: auto-negotiation/adv. capabilities of port te1/0/3 differ from auto-negotiation/adv. capabilities of Po1
2147483159 2018-Nov-06 12:56:18 Warning %LINK-W-Down: te1/0/4
2147483160 2018-Nov-06 12:56:18 Warning %LINK-W-Down: Vlan 30
2147483161 2018-Nov-06 12:56:18 Warning %LINK-W-Down: Vlan 11
2147483162 2018-Nov-06 12:56:18 Warning %LINK-W-Down: Vlan 10
2147483163 2018-Nov-06 12:56:18 Warning %LINK-W-Down: Vlan 2
2147483164 2018-Nov-06 12:56:18 Warning %LINK-W-Down: Vlan 1
2147483165 2018-Nov-06 12:56:18 Warning %LINK-W-Down: Po1
2147483166 2018-Nov-06 12:56:18 Warning %LINK-W-Down: te1/0/3
2147483167 2018-Nov-06 12:56:18 Warning %TRUNK-W-PORTREMOVED: Port te1/0/3 removed from Po1 Vielen Dank im voraus!
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: 445908
Url: https://administrator.de/contentid/445908
Printed on: April 23, 2024 at 18:04 o'clock
7 Comments
Latest comment
Du solltest die LACP LAGs immer vorher direkt am Switch fertig konfigurieren bevor du sie in Betrieb nimmst.
Zudem solltest du bei LAGs immer Spanning Tree and dann natürlich RSTP aktiviert haben auf ALLEN Switches.
Wobei die Cores oder der Core dann die höchste RSTP Prio mit 4096 haben sollten.
Das grundlegend.
Das Fehlerlog besagt das es einen Port Mismatch an den von dir konfigurierten Trunk Member Ports gibt.
Bitte achte hier zwingend darauf das die rein im Default sind und keinerlei unterschiedliche Parameter haben ! Wenn das der Fall ist kommt der LAG logischerweise nicht zustande wenn die Port Konfigs nur in einem Punkt unterschiedlich sind ! Genau das ist bei dir der Fall.
Das ist auch sinnvoll, denn so ist immer und zu jeder Zeit sichergestellt das beide Ports immer identische Konfig Parameter haben was bei einem LACP LAG zwingend ist.
Das besten ist du resettest die Member Ports in den Default, formierst dann den LAG fertig in der Konfig und steckst ihn.
Das wäre der richtige Weg.
Zudem solltest du bei LAGs immer Spanning Tree and dann natürlich RSTP aktiviert haben auf ALLEN Switches.
Wobei die Cores oder der Core dann die höchste RSTP Prio mit 4096 haben sollten.
Das Fehlerlog besagt das es einen Port Mismatch an den von dir konfigurierten Trunk Member Ports gibt.
Bitte achte hier zwingend darauf das die rein im Default sind und keinerlei unterschiedliche Parameter haben ! Wenn das der Fall ist kommt der LAG logischerweise nicht zustande wenn die Port Konfigs nur in einem Punkt unterschiedlich sind ! Genau das ist bei dir der Fall.
- Port Speed und Duplex müssen gleich sein
- Ports dürfen NICHT Mitglied unterschiedlicher VLANs sein oder unterschiedlich getagged sein.
- Ports sollten BEIDE untagged im Default VLAN 1 sein
Das ist auch sinnvoll, denn so ist immer und zu jeder Zeit sichergestellt das beide Ports immer identische Konfig Parameter haben was bei einem LACP LAG zwingend ist.
Das besten ist du resettest die Member Ports in den Default, formierst dann den LAG fertig in der Konfig und steckst ihn.
Das wäre der richtige Weg.
Hallo aqui!
Vielen Dank für die Antwort!
Ich hatte die betreffenden Ports auf Trunk gestellt, unterschiedliche Vlans konfiguriert und danach erst die LAG konfiguriert.
Hatte die Switche vorher alle gestapelt in der Werkstatt und dann falsch vorkonfiguriert.
Nach zurücksetzen der Ports auf Access sowie nachfolgender LAG-Konfiguration hat es dann funktioniert!
Die RSTP Prio von 4096 stelle ich zusätzlich noch am Core ein.
Nochmal vielen Dank für Deine Unterstützung!
Vielen Dank für die Antwort!
Ich hatte die betreffenden Ports auf Trunk gestellt, unterschiedliche Vlans konfiguriert und danach erst die LAG konfiguriert.
Hatte die Switche vorher alle gestapelt in der Werkstatt und dann falsch vorkonfiguriert.
Nach zurücksetzen der Ports auf Access sowie nachfolgender LAG-Konfiguration hat es dann funktioniert!
Die RSTP Prio von 4096 stelle ich zusätzlich noch am Core ein.
Nochmal vielen Dank für Deine Unterstützung!
Alles wird gut ! 
Hallo Aqui,
ich habe hier leider weiterhin "Ungereimtheiten" im Log.
Ein Stack aus 2 24ern ist über eine LAG mit dem Core verbunden.
Für 5 Tage hatte ich aus Platzgründen am Patchfeld nur einen LWL-Port im Einsatz sodass die LAG nur auf einem Bein stand.
Mittags erreichte mich dann eine Mail, dass der Access-Switch nicht mehr erreichbar ist.. gefolgt von Anrufen der Mitarbeiter.
Der Port wurde aufgrund von "Link-Flapping" deaktiviert sodass der Switch dann nicht mehr erreichbar war.
Glücklicherweise war ein LevelOne Switch schon "leergeräumt" sodass ich das 2. Bein der LAG hinzufügen konnte.
Seitdem beobachte ich häufige Link-Flapping Meldungen im Log.
Ich werde in den nächsten Tagen auf einen anderen Glasfaserport wechseln um zu prüfen, ob es daran liegt.
Dies kann durchaus sein weil wir mit der OM2e Leitung über 100m liegen und 10Gbit daher etwas kritisch sein könnte.
Die Messwerte von dem Anschluss sind aber auch nur so lala....
Passend dazu erhalte ich aber Meldungen bzgl. der auto-negotiation um die es hier vorrangig geht.
Du hast ja geschrieben, dass die Einstellungen der Ports identisch sein müssen - Dies sind sie meiner Meinung nach aber.
Hast Du evtl. noch einen Tipp?
Vielen Dank!
ich habe hier leider weiterhin "Ungereimtheiten" im Log.
Ein Stack aus 2 24ern ist über eine LAG mit dem Core verbunden.
Für 5 Tage hatte ich aus Platzgründen am Patchfeld nur einen LWL-Port im Einsatz sodass die LAG nur auf einem Bein stand.
Mittags erreichte mich dann eine Mail, dass der Access-Switch nicht mehr erreichbar ist.. gefolgt von Anrufen der Mitarbeiter.
Der Port wurde aufgrund von "Link-Flapping" deaktiviert sodass der Switch dann nicht mehr erreichbar war.
Glücklicherweise war ein LevelOne Switch schon "leergeräumt" sodass ich das 2. Bein der LAG hinzufügen konnte.
Seitdem beobachte ich häufige Link-Flapping Meldungen im Log.
Ich werde in den nächsten Tagen auf einen anderen Glasfaserport wechseln um zu prüfen, ob es daran liegt.
Dies kann durchaus sein weil wir mit der OM2e Leitung über 100m liegen und 10Gbit daher etwas kritisch sein könnte.
Die Messwerte von dem Anschluss sind aber auch nur so lala....
%LINK-W-PORT_SUSPENDED: Port te2/0/3 suspended by link-flappingPassend dazu erhalte ich aber Meldungen bzgl. der auto-negotiation um die es hier vorrangig geht.
Core-Switch 2SWTRUNK - TRNKPORTPARAM - auto-negotiation/adv. capabilities of port te2/0/3 differ from auto-negotiation/adv. capabilities of Po6 Du hast ja geschrieben, dass die Einstellungen der Ports identisch sein müssen - Dies sind sie meiner Meinung nach aber.
Hast Du evtl. noch einen Tipp?
Vielen Dank!
Hi Knorkator !
Das OM2e Kabel über 100m ist garantiert der Verursacher. Das ist über dem supportetem Limit. Hier entscheidet dann einzig die Lichleistung der Optik ob der Link zustandekommt oder nicht. Eine wackelige Angelegenheit wie es ja auch dein Log leider bestätigt.
Ggf. erreichst du etwas mit einem Hin- und Hertausch der Optiken. Einige haben immer ein paar dB mehr was dann linkentscheident ist. Es bleibt aber dann ein Vabanque Spiel.
Altern die Optiken (Empfangsdioden) ist das dB was den Link stabil machte dann wieder dahin und du bist wieder am Anfang und musst tauschen.
Bei solch alten Kabeln und Längen über 66m sollte man dann immer besser LRM Optiken verwenden:
https://www.amazon.de/gp/offer-listing/B00AI2W5H6?linkCode=xm2&condi ...
oder kompatible:
https://shop.fiber24.net/index.php/de/10-3-Gbit-s-LRM-MM-1310nm-SFP-Tran ...
https://www.wowi-tec.de/SFP-10G-LRM-C-Compatible-10GBASE-LRM-SFP-Module? ...
Damit fährst du in jedem Falle sicherer was das Lichtbudget auf diesen Links mit OM1 oder OM2 anbetrifft.
Alternativ helfen auch LR Optiken:
https://www.flexoptix.net/de/blog/2011/06/damit-der-10g-ethernet-link-ho ...
Was die LAG Port Problematik angeht hast du einen Unterschied in der Speed und Duplex Mode einstellung auf den beteiligten Ports te2/0/3 die zum Port Channel (LAG) 6 gehören.
Es kann aber auch sein das du da beim Umstecken mal 1G drangehabt hast, dann meckert das Log natürlich gleich.
Wichtig ist nur das sie im Protduktiv Betrieb nacher immer gleich sind.
Das OM2e Kabel über 100m ist garantiert der Verursacher. Das ist über dem supportetem Limit. Hier entscheidet dann einzig die Lichleistung der Optik ob der Link zustandekommt oder nicht. Eine wackelige Angelegenheit wie es ja auch dein Log leider bestätigt.
Ggf. erreichst du etwas mit einem Hin- und Hertausch der Optiken. Einige haben immer ein paar dB mehr was dann linkentscheident ist. Es bleibt aber dann ein Vabanque Spiel.
Altern die Optiken (Empfangsdioden) ist das dB was den Link stabil machte dann wieder dahin und du bist wieder am Anfang und musst tauschen.
Bei solch alten Kabeln und Längen über 66m sollte man dann immer besser LRM Optiken verwenden:
https://www.amazon.de/gp/offer-listing/B00AI2W5H6?linkCode=xm2&condi ...
oder kompatible:
https://shop.fiber24.net/index.php/de/10-3-Gbit-s-LRM-MM-1310nm-SFP-Tran ...
https://www.wowi-tec.de/SFP-10G-LRM-C-Compatible-10GBASE-LRM-SFP-Module? ...
Damit fährst du in jedem Falle sicherer was das Lichtbudget auf diesen Links mit OM1 oder OM2 anbetrifft.
Alternativ helfen auch LR Optiken:
https://www.flexoptix.net/de/blog/2011/06/damit-der-10g-ethernet-link-ho ...
Was die LAG Port Problematik angeht hast du einen Unterschied in der Speed und Duplex Mode einstellung auf den beteiligten Ports te2/0/3 die zum Port Channel (LAG) 6 gehören.
Es kann aber auch sein das du da beim Umstecken mal 1G drangehabt hast, dann meckert das Log natürlich gleich.
Wichtig ist nur das sie im Protduktiv Betrieb nacher immer gleich sind.
Zitat von @aqui:
Hi Knorkator !
Das OM2e Kabel über 100m ist garantiert der Verursacher. Das ist über dem supportetem Limit. Hier entscheidet dann einzig die Lichleistung der Optik ob der Link zustandekommt oder nicht. Eine wackelige Angelegenheit wie es ja auch dein Log leider bestätigt.
Ggf. erreichst du etwas mit einem Hin- und Hertausch der Optiken. Einige haben immer ein paar dB mehr was dann linkentscheident ist. Es bleibt aber dann ein Vabanque Spiel.
Altern die Optiken (Empfangsdioden) ist das dB was den Link stabil machte dann wieder dahin und du bist wieder am Anfang und musst tauschen.
.
.
Alternativ helfen auch LR Optiken:
https://www.flexoptix.net/de/blog/2011/06/damit-der-10g-ethernet-link-ho ...
Ich hatte das mit den Leitungslängen ja schon auf dem Schirm und habe entsprechende LR-Optiken von Flexoptix bestellt.Hi Knorkator !
Das OM2e Kabel über 100m ist garantiert der Verursacher. Das ist über dem supportetem Limit. Hier entscheidet dann einzig die Lichleistung der Optik ob der Link zustandekommt oder nicht. Eine wackelige Angelegenheit wie es ja auch dein Log leider bestätigt.
Ggf. erreichst du etwas mit einem Hin- und Hertausch der Optiken. Einige haben immer ein paar dB mehr was dann linkentscheident ist. Es bleibt aber dann ein Vabanque Spiel.
Altern die Optiken (Empfangsdioden) ist das dB was den Link stabil machte dann wieder dahin und du bist wieder am Anfang und musst tauschen.
.
.
Alternativ helfen auch LR Optiken:
https://www.flexoptix.net/de/blog/2011/06/damit-der-10g-ethernet-link-ho ...
Modernisierung der Netzwerkswitche
Ich werde den Tausch der Optik testen. Im ersten Step werde ich aber mal einen anderen Port ausprobieren.
Was die LAG Port Problematik angeht hast du einen Unterschied in der Speed und Duplex Mode einstellung auf den beteiligten Ports te2/0/3 die zum Port Channel (LAG) 6 gehören.
Es kann aber auch sein das du da beim Umstecken mal 1G drangehabt hast, dann meckert das Log natürlich gleich.
Wichtig ist nur das sie im Protduktiv Betrieb nacher immer gleich sind.
Es könnte durchaus sein, dass im Port te2/0/3 mal ein 1G Modul steckte.. kommt der Switch dann später noch durcheinander damit?Es kann aber auch sein das du da beim Umstecken mal 1G drangehabt hast, dann meckert das Log natürlich gleich.
Wichtig ist nur das sie im Protduktiv Betrieb nacher immer gleich sind.
Kann man das irgendwie überprüfen?
Vielen Dank!
kommt der Switch dann später noch durcheinander damit?
Nein, er meckert das nur an wenn das Ereignis eintritt. Er also als LAG definiert ist und dann mal ein Speed bzw. Duplex Mismatch eintritt.Sofern das später wieder richtig gesteckt ist und Speed/Duplex beidseitig stimmen, ist alles wieder OK.
Verhindern kann man das nur indem man die Autonegotiation ausschaltet und die LAG Member Ports statisch konfiguriert.
