ex0r2k16
Goto Top

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.

Content-Key: 1712484819

Url: https://administrator.de/contentid/1712484819

Printed on: May 21, 2024 at 11:05 o'clock

Member: aqui
Solution aqui Jan 11, 2022 updated at 15:55:51 (UTC)
Goto Top
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.
Member: Ex0r2k16
Ex0r2k16 Jan 12, 2022 at 07:18:01 (UTC)
Goto Top
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.

Moin!

top danke. Der SG500 eine relativ alte Firmware. Der SG350 ist aktuell. Wird wohl daran liegen.