2
LACP sorgt für defekte LAG
Mahlzeit,
folgende Ausgangslage:
LAG zwischen Cisco SG500 und SG350 über 2*1GBit Multimode Gbics. Lief ca. ein Jahr problemlos. Eines Samstags plötzlich: Verbindung zwischen beiden Switchen weg.
Sobald ich einen Trunk gezogen habe: Link wieder da, Daraufhin die nicht originalen Gbics gegen originale getauscht. Fehler blieb gleich.
Sobald ich beide Trunks vor Ort am SG350 in die LAG geschoben habe, flog die komplette LAG davon. Da ich nicht auf LACP angewiesen bin, habe ich dies auf beiden Seiten deaktiviert. Siehe da...LAG wieder funktional. Absolut merkwürdig. Ein Firmware Update oder Ähnliches kann ausgeschlossen werden. Es passierte einfach so. Auch vorher mit den billig Gbics kein Problem gehabt.
Jemand eine Idee? Liegt es vielleicht an den LACP Timeout Settings? Wobei beide Seiten auf "Long" standen.
folgende Ausgangslage:
LAG zwischen Cisco SG500 und SG350 über 2*1GBit Multimode Gbics. Lief ca. ein Jahr problemlos. Eines Samstags plötzlich: Verbindung zwischen beiden Switchen weg.
Sobald ich einen Trunk gezogen habe: Link wieder da, Daraufhin die nicht originalen Gbics gegen originale getauscht. Fehler blieb gleich.
Sobald ich beide Trunks vor Ort am SG350 in die LAG geschoben habe, flog die komplette LAG davon. Da ich nicht auf LACP angewiesen bin, habe ich dies auf beiden Seiten deaktiviert. Siehe da...LAG wieder funktional. Absolut merkwürdig. Ein Firmware Update oder Ähnliches kann ausgeschlossen werden. Es passierte einfach so. Auch vorher mit den billig Gbics kein Problem gehabt.
Jemand eine Idee? Liegt es vielleicht an den LACP Timeout Settings? Wobei beide Seiten auf "Long" standen.
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: 1712484819
Url: https://administrator.de/contentid/1712484819
Printed on: April 26, 2024 at 10:04 o'clock
2 Comments
Latest comment
Es gab mal einen älteren Cisco Bug. (Siehe SG Release Notes). Cisco übergibt beim Aufbau des LAGs eine Hardware Mac, errechnet beim LACP Handshake aber eine virtuelle, was im Standard so nicht definiert ist. Das Gegenüber interpretiert das dann oft als Link Verlust und bricht den LAG ab. Etwas schlampig programmierte 802.3ad Implementationen tolerierten es auch manchmal. Ist ein Lotteriespiel.
Das sollte mit einigermaßen aktuellen Firmwares aber jetzt gefixt sein.
Du solltest deshalb in jedem Falle darauf achten das die Firmware auf dem aktuellsten Stand ist und das auf beiden Seiten !
Andere Dinge warum LACP LAGs scheitern ist wenn die Member Ports vorher unterschiedliche Konfigs haben. Damit kommt ein LAG nicht zustande. Deshalb ist es immer ratsam zuerst die jungfräulichen Ports zu bündeln und dann nur mit dem virtuellen LAG Interface zu arbeiten.
In den letzten aktuellen Images hat Cisco das automatisiert so das diese Gefahr zumindestens bei Cisco gebannt ist. Bei anderen Herstellern ist das aber oft anders.
LACP Timeout Long bestimmt die Umschaltzeit der Memberlinks im Fehlerfalle und ist richtig. Hersteller übergreifend ist das auch immer der Default. Dieser Parameter muss an beiden Enden immer identisch sein !
Wenn du die Firmware (siehe oben) ausschliessen kannst ist es vermutlich Hardware in Form von defekten Kabeln, Patchkabeln oder Optiken.
Alle weiteren Details zu LACP LAGs auch hier.
Das sollte mit einigermaßen aktuellen Firmwares aber jetzt gefixt sein.
Du solltest deshalb in jedem Falle darauf achten das die Firmware auf dem aktuellsten Stand ist und das auf beiden Seiten !
Andere Dinge warum LACP LAGs scheitern ist wenn die Member Ports vorher unterschiedliche Konfigs haben. Damit kommt ein LAG nicht zustande. Deshalb ist es immer ratsam zuerst die jungfräulichen Ports zu bündeln und dann nur mit dem virtuellen LAG Interface zu arbeiten.
In den letzten aktuellen Images hat Cisco das automatisiert so das diese Gefahr zumindestens bei Cisco gebannt ist. Bei anderen Herstellern ist das aber oft anders.
LACP Timeout Long bestimmt die Umschaltzeit der Memberlinks im Fehlerfalle und ist richtig. Hersteller übergreifend ist das auch immer der Default. Dieser Parameter muss an beiden Enden immer identisch sein !
Wenn du die Firmware (siehe oben) ausschliessen kannst ist es vermutlich Hardware in Form von defekten Kabeln, Patchkabeln oder Optiken.
Alle weiteren Details zu LACP LAGs auch hier.
2
Zitat von @aqui:
Es gab mal einen älteren Cisco Bug. (Siehe SG Release Notes). Cisco übergibt beim Aufbau des LAGs eine Hardware Mac, errechnet beim LACP Handshake aber eine virtuelle, was im Standard so nicht definiert ist. Das Gegenüber interpretiert das dann oft als Link Verlust und bricht den LAG ab. Etwas schlampig programmierte 802.3ad Implementationen tolerierten es auch manchmal. Ist ein Lotteriespiel.
Das sollte mit einigermaßen aktuellen Firmwares aber jetzt gefixt sein.
Du solltest deshalb in jedem Falle darauf achten das die Firmware auf dem aktuellsten Stand ist und das auf beiden Seiten !
Andere Dinge warum LACP LAGs scheitern ist wenn die Member Ports vorher unterschiedliche Konfigs haben. Damit kommt ein LAG nicht zustande. Deshalb ist es immer ratsam zuerst die jungfräulichen Ports zu bündeln und dann nur mit dem virtuellen LAG Interface zu arbeiten.
In den letzten aktuellen Images hat Cisco das automatisiert so das diese Gefahr zumindestens bei Cisco gebannt ist. Bei anderen Herstellern ist das aber oft anders.
LACP Timeout Long bestimmt die Umschaltzeit der Memberlinks im Fehlerfalle und ist richtig. Hersteller übergreifend ist das auch immer der Default. Dieser Parameter muss an beiden Enden immer identisch sein !
Wenn du die Firmware (siehe oben) ausschliessen kannst ist es vermutlich Hardware in Form von defekten Kabeln, Patchkabeln oder Optiken.
Alle weiteren Details zu LACP LAGs auch hier.
Es gab mal einen älteren Cisco Bug. (Siehe SG Release Notes). Cisco übergibt beim Aufbau des LAGs eine Hardware Mac, errechnet beim LACP Handshake aber eine virtuelle, was im Standard so nicht definiert ist. Das Gegenüber interpretiert das dann oft als Link Verlust und bricht den LAG ab. Etwas schlampig programmierte 802.3ad Implementationen tolerierten es auch manchmal. Ist ein Lotteriespiel.
Das sollte mit einigermaßen aktuellen Firmwares aber jetzt gefixt sein.
Du solltest deshalb in jedem Falle darauf achten das die Firmware auf dem aktuellsten Stand ist und das auf beiden Seiten !
Andere Dinge warum LACP LAGs scheitern ist wenn die Member Ports vorher unterschiedliche Konfigs haben. Damit kommt ein LAG nicht zustande. Deshalb ist es immer ratsam zuerst die jungfräulichen Ports zu bündeln und dann nur mit dem virtuellen LAG Interface zu arbeiten.
In den letzten aktuellen Images hat Cisco das automatisiert so das diese Gefahr zumindestens bei Cisco gebannt ist. Bei anderen Herstellern ist das aber oft anders.
LACP Timeout Long bestimmt die Umschaltzeit der Memberlinks im Fehlerfalle und ist richtig. Hersteller übergreifend ist das auch immer der Default. Dieser Parameter muss an beiden Enden immer identisch sein !
Wenn du die Firmware (siehe oben) ausschliessen kannst ist es vermutlich Hardware in Form von defekten Kabeln, Patchkabeln oder Optiken.
Alle weiteren Details zu LACP LAGs auch hier.
Moin!
top danke. Der SG500 eine relativ alte Firmware. Der SG350 ist aktuell. Wird wohl daran liegen.