26
LACP flapping: Ständig wird ein Port entfernt und wieder hinzugefügt
Hallo.
Wir setzen bei uns Cisco SG350X-Switche ein, die z.T. über LAGs miteinander verbunden sind. Einige Doppelleitungen führen auch zu einem Unifi-16XG-Switch, der ebenfalls LACP-LAGs kann. Nun sehe ich im Log unseres Layer3-Routers (ebenfalls ein SG350X-24) ständig Meldungen dieser Art:
Das geht also quasi im Minutentakt so.
Ich habe natürlich schon danach gesucht aber bisher keine gute Lösung für das Problem gefunden. Es tritt übrigens erst auf, seitdem wir auf 10GBit SFP+ gewechselt sind. Vorher liefen diverse LAGs auf Kupfer (nur 1 GBit) -- da gab es dieses Problem imho nie?!?
Hat jemand eine gute Idee, wonach ich schauen kann?
Es ist doch nicht so, dass bei einem LAG ein Port heruntergefahren wird, wenn dort nichts los ist, oder?
Danke.
Wir setzen bei uns Cisco SG350X-Switche ein, die z.T. über LAGs miteinander verbunden sind. Einige Doppelleitungen führen auch zu einem Unifi-16XG-Switch, der ebenfalls LACP-LAGs kann. Nun sehe ich im Log unseres Layer3-Routers (ebenfalls ein SG350X-24) ständig Meldungen dieser Art:
...
2147427869 2020-May-10 16:56:28 Warning %TRUNK-W-PORTREMOVED: Port te1/0/2 removed from Po6
2147427871 2020-May-10 16:55:46 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/9 removed from Po1
2147427874 2020-May-10 16:54:14 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/9 removed from Po1
2147427876 2020-May-10 16:53:28 Warning %TRUNK-W-PORTREMOVED: Port te1/0/2 removed from Po6
2147427879 2020-May-10 16:51:00 Warning %TRUNK-W-PORTREMOVED: Port te1/0/2 removed from Po6
2147427880 2020-May-10 16:50:49 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/9 removed from Po1
2147427882 2020-May-10 16:49:30 Warning %TRUNK-W-PORTREMOVED: Port te1/0/2 removed from Po6
2147427884 2020-May-10 16:48:44 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/9 removed from Po1
2147427886 2020-May-10 16:47:58 Warning %TRUNK-W-PORTREMOVED: Port te1/0/2 removed from Po6
2147427888 2020-May-10 16:45:28 Warning %TRUNK-W-PORTREMOVED: Port te1/0/2 removed from Po6
2147427890 2020-May-10 16:44:46 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/9 removed from Po1
2147427894 2020-May-10 16:43:45 Warning %TRUNK-W-PORTREMOVED: Port te1/0/1 removed from Po6
2147427895 2020-May-10 16:43:45 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/24 removed from Po4
...Ich habe natürlich schon danach gesucht aber bisher keine gute Lösung für das Problem gefunden. Es tritt übrigens erst auf, seitdem wir auf 10GBit SFP+ gewechselt sind. Vorher liefen diverse LAGs auf Kupfer (nur 1 GBit) -- da gab es dieses Problem imho nie?!?
Hat jemand eine gute Idee, wonach ich schauen kann?
Es ist doch nicht so, dass bei einem LAG ein Port heruntergefahren wird, wenn dort nichts los ist, oder?
Danke.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666605
Url: https://administrator.de/contentid/666605
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
26 Kommentare
Neuester Kommentar
Ich sehe, dass du scheinbar einen Mischbetrieb hast, also 10GbE und 1GbE-Trunks. Sind die auch vermischt? Also 10GbE-Verbindungen mit 1GbE-Verbindungen in einem LACP-Trunk?
Nein, bei Trunks bleiben alle aktiven und funktionierenden Verbindungen dauerhaft aktiv.
Es tritt übrigens erst auf, seitdem wir auf 10GBit SFP+ gewechselt sind. Vorher liefen diverse LAGs auf Kupfer (nur 1 GBit) -- da gab es dieses Problem imho nie?!?
Kann ich so irgendwie nicht glauben, weil die meisten Ausfälle betreffen ja 1GbE-Verbindungen, die haben mit SFP+ ja nichts zu tun.Nein, bei Trunks bleiben alle aktiven und funktionierenden Verbindungen dauerhaft aktiv.
Nein, gemischt ist da nichts. Hier nochmal die Übersicht der derzeitigen Trunks:
Das ist also getrennt -- so wie's sein sollte ... trotzdem sind Port 7 und 9 im Moment heiße Kandidaten für das flapping; aber die 10G-Ports ja auch ...
Übrigens hängt auf der anderen Seite von LAG1 ein SG300 (nur 1 Gbit) aber auf der anderen Seite von LAG5 der Unifi-Switch mit 10GBit. Es scheint keine Rolle zu spielen, da die Meldungen für alle LAGs erscheinen...!??
LAG Name LACP Link State Active Member Standby Member
LAG 1 LAG1 Enabled Link Up GE1/6, GE1/7, GE1/8, GE1/9
LAG 2 LAG2 Enabled Link Up GE1/19, GE1/20
LAG 3 LAG3 Link Not Present
LAG 4 LAG4 Enabled Link Up GE1/23, GE1/24
LAG 5 LAG5 Enabled Link Down XG1/3, XG1/4
LAG 6 LAG6 Enabled Link Up XG1/1, XG1/2 Das ist also getrennt -- so wie's sein sollte ... trotzdem sind Port 7 und 9 im Moment heiße Kandidaten für das flapping; aber die 10G-Ports ja auch ...
Übrigens hängt auf der anderen Seite von LAG1 ein SG300 (nur 1 Gbit) aber auf der anderen Seite von LAG5 der Unifi-Switch mit 10GBit. Es scheint keine Rolle zu spielen, da die Meldungen für alle LAGs erscheinen...!??
Moin,
Sprich sind die Messprotokolle der Leitungen 1a?
Gruß,
Dani
Es ist doch nicht so, dass bei einem LAG ein Port heruntergefahren wird, wenn dort nichts los ist, oder?
Nein, dem ist nicht so. Hat jemand eine gute Idee, wonach ich schauen kann?
Tritt das Problem auch auf, wenn du auf den betroffenen Ports Speed und Duplex temporär fest einstellst?Es tritt übrigens erst auf, seitdem wir auf 10GBit SFP+ gewechselt sind.
Handelt es sich um GBICs für LWL oder wird die bisherige Kupferleitung weitergenutzt?Sprich sind die Messprotokolle der Leitungen 1a?
Gruß,
Dani
Habe ich noch nicht versucht -- das muss ich erstmal suchen, wo ich im Cisco-Switch beides fest einstellen kann.
Ah - gefunden unter Port Management --> Port Settings:
Die 10GBit-LAGs laufen jetzt über LWL -- die 1GBit-LAGs aber weiterhin über die gleichen Kupferleitungen wie bisher. Da sich z.B. der eine SG300 im selben Rack befindet wie der SG350X, ist die Verbindung über das 4-fach-LAG keinen Meter lang!
Das 10GBit-LAG zum Unifi-Switch ist höchsten 3m lang .... aber ob es da Messprotokolle gibt, kann ich nicht sagen. Könnte man die Qualtität einer LWL-Verbindung auch selbst testen oder ist dazu irgendein teures Gerät von $Fluke notwendig?
Übrigens kommen auch solche Meldungen vor:
Ich würde sagen: Da ist schwer was faul ... aber wie kann man das einkreisen?
Ah - gefunden unter Port Management --> Port Settings:
Die 10GBit-LAGs laufen jetzt über LWL -- die 1GBit-LAGs aber weiterhin über die gleichen Kupferleitungen wie bisher. Da sich z.B. der eine SG300 im selben Rack befindet wie der SG350X, ist die Verbindung über das 4-fach-LAG keinen Meter lang!
Das 10GBit-LAG zum Unifi-Switch ist höchsten 3m lang .... aber ob es da Messprotokolle gibt, kann ich nicht sagen. Könnte man die Qualtität einer LWL-Verbindung auch selbst testen oder ist dazu irgendein teures Gerät von $Fluke notwendig?
Übrigens kommen auch solche Meldungen vor:
2147427655 2020-May-10 18:40:16 Warning %TRUNK-W-PORTREMOVED: Port te1/0/1 removed from Po6
2147427659 2020-May-10 18:38:47 Warning %LINK-W-Down: Po4
2147427660 2020-May-10 18:38:47 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/23 removed from Po4
2147427661 2020-May-10 18:38:47 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/24 removed from Po4
2147427665 2020-May-10 18:36:18 Warning %LINK-W-Down: Po4
2147427666 2020-May-10 18:36:16 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/24 removed from Po4
2147427667 2020-May-10 18:36:16 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/23 removed from Po4 
Moin,
Was ich mir auch vorstellen könnte hatte ich ähnlich schonmal das eine Fehlerhafte Konfiguration von Loop Protection mit disable Timer vorliegt oder ein nahe liegendes Spanning Tree Problem weshalb die Ports auf Forward oder Blocking gehen. Erzeugt im Log meist die selbe Meldung.
Daher würde ich prüfen ob alle Links an alle Stellen sauber in den LAGs Konfiguriert sind. Statisches dynamisches LACP. Dann ob der Spanning Tree Prio sauber auf dem Coreswitch liegt und die restlichen Switche eine geringeren Wert (ID) als der Core haben. Keine Loops im Netzwerk vorhanden sind
Grüße
Niklas
Was ich mir auch vorstellen könnte hatte ich ähnlich schonmal das eine Fehlerhafte Konfiguration von Loop Protection mit disable Timer vorliegt oder ein nahe liegendes Spanning Tree Problem weshalb die Ports auf Forward oder Blocking gehen. Erzeugt im Log meist die selbe Meldung.
Daher würde ich prüfen ob alle Links an alle Stellen sauber in den LAGs Konfiguriert sind. Statisches dynamisches LACP. Dann ob der Spanning Tree Prio sauber auf dem Coreswitch liegt und die restlichen Switche eine geringeren Wert (ID) als der Core haben. Keine Loops im Netzwerk vorhanden sind
Grüße
Niklas
Hm, viele neue ideen ... hier ein paar Screenshots:
Der Spanning Tree ist aus -- ich weiß, dass er aktiviert sein sollte, doch damit funktioniert ein Feature nicht, das wir hier unbedingt benötigen. Das lief die letzten Jahre aber immer so.
Einen Loop kann es da eigentlich nicht geben, da wir die LAGs von einem alten Netz (das parallel lief) auf das neue Netz umgesteckt haben. Dabei haben wir immer nur die Leitungen des LAGs angefasst und auf den Core-Switch gesteckt....
Einen Loop kann es da eigentlich nicht geben, da wir die LAGs von einem alten Netz (das parallel lief) auf das neue Netz umgesteckt haben. Dabei haben wir immer nur die Leitungen des LAGs angefasst und auf den Core-Switch gesteckt....
MSTP ist auch deaktiviert? Ansonsten würde ich es mal so probieren jeweils nur 1 Port zu jedem Switch zu haben, ein administratives herunterfahren der Ports reicht und dann prüfen ob du immernoch Portflapping hast.
Ich würde parallel auch die physischen Verbindungen prüfen ob sich nicht wirklich ein Loop eingeschlichen hat kann im Eifer des Gefechtes passieren. Das kannst du imho mit einem simplen Ping auf die Management IP von jedem Switch prüfen, natürlich dann den letzten wissentlichen Port im LAG administrativ herunterfahren.
Übringens ist auf Unifi Switchen per Default Spanning Tree an das muss explizit deaktiviert werden, habe gerade nochmal auf meine im Einsatz befindlichen Unifi Controller geschaut.
Ich würde parallel auch die physischen Verbindungen prüfen ob sich nicht wirklich ein Loop eingeschlichen hat kann im Eifer des Gefechtes passieren. Das kannst du imho mit einem simplen Ping auf die Management IP von jedem Switch prüfen, natürlich dann den letzten wissentlichen Port im LAG administrativ herunterfahren.
Übringens ist auf Unifi Switchen per Default Spanning Tree an das muss explizit deaktiviert werden, habe gerade nochmal auf meine im Einsatz befindlichen Unifi Controller geschaut.
MSTP: Wo sehe ich das, ob es deaktiviert ist? Bei "MSTP Interface Settings" steht hier jedenfalls: Mode: RSTP. Ist das richtig so?
Ok, also kann es auch zu irgendeinem unerwünschten Verhalten kommen, wenn die eine Seite den Spanning Tree aktiviert hat -- die andere aber nicht? Ich suche gleich mal im Unifi-Controller und hoffe, dass ich es finde. Die Port-Einstellungen sind da zwar relativ überischtlich aber dafür findet man auch nicht alles sofort.
Ok, also kann es auch zu irgendeinem unerwünschten Verhalten kommen, wenn die eine Seite den Spanning Tree aktiviert hat -- die andere aber nicht? Ich suche gleich mal im Unifi-Controller und hoffe, dass ich es finde. Die Port-Einstellungen sind da zwar relativ überischtlich aber dafür findet man auch nicht alles sofort.
Ja das kommt definitiv zu unerwünschtem Verhalten. Das könnte schon dein Problem sein :/. Was Enterprise Features angeht da bin von Unifi nicht so überzeugt, da sind die Anbieter Cisco, Ruckus, Aruba, HPE wesentlich besser und da lässt sich das auch gut konfigurieren. Selbst bei LACP dreht man sich bei Unifi schon einen wolf.
Ja, Unifi hat da so seine Schwächen ... you get what you pay for.
Ich habe den Spanning Tree auf dem Unifi-16XG gerade deaktiviert. Seit 2 Minuten ist nun schon Ruhe
Ich habe den Spanning Tree auf dem Unifi-16XG gerade deaktiviert. Seit 2 Minuten ist nun schon Ruhe
1
Top, sehr schön das freut mich da Licht ins dunkele bringen konnte und es das hoffentlich war. Dann würde ich mich auch über den Lösungsknopf bei mir freuen 😉.
Hm -- ich habe den (subjektiven) Eindruck, dass es weniger geworden ist --- aber weg ist es leider noch nicht.
Gerade nochmal nachgesehen ...
Ich habe es nochmal 15 Minuten beobachtet -- keine einzige Meldung mehr!
Die Logs vom 21:04 Uhr könnten auch vom Reboot des Unifi-Switches stammen ...
Ich hoffe mal, dass es da war und markiere es vorerst als gelöst.
Sonst melde ich mich gleich wieder.
Danke jedenfalls schon mal für die Hilfe und die ganzen Tipps ... hätte ich alleine vermutlich nie erraten.
Gerade nochmal nachgesehen ...
2147483614 2020-May-10 21:04:50 Informational %TRUNK-I-PORTADDED: Port gi1/0/19 added to Po2
2147483615 2020-May-10 21:04:49 Informational %LINK-I-Up: Po2
2147483616 2020-May-10 21:04:49 Informational %TRUNK-I-PORTADDED: Port gi1/0/20 added to Po2
2147483617 2020-May-10 21:04:49 Warning %LINK-W-Down: Po2
2147483618 2020-May-10 21:04:49 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/20 removed from Po2
2147483619 2020-May-10 21:04:49 Informational %TRUNK-I-PORTADDED: Port gi1/0/8 added to Po1
2147483620 2020-May-10 21:04:49 Informational %TRUNK-I-PORTADDED: Port gi1/0/6 added to Po1
2147483621 2020-May-10 21:04:49 Informational %TRUNK-I-PORTADDED: Port gi1/0/23 added to Po4
2147483622 2020-May-10 21:04:49 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/23 removed from Po4
2147483623 2020-May-10 21:04:48 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/19 removed from Po2
2147483624 2020-May-10 21:04:48 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/8 removed from Po1
2147483625 2020-May-10 21:04:48 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/6 removed from Po1
2147483626 2020-May-10 21:03:38 Informational %Environment-I-FANS-SPEED-CHNG: FAN'S speed level - 4 changed to level - 5.
2147483627 2020-May-10 21:03:13 Informational %Environment-I-FANS-SPEED-CHNG: FAN'S speed level - 3 changed to level - 4.
2147483628 2020-May-10 21:02:58 Informational %Environment-I-FANS-SPEED-CHNG: FAN'S speed level - 2 changed to level - 3.
2147483629 2020-May-10 21:02:38 Informational %Environment-I-FANS-SPEED-CHNG: FAN'S speed level - 1 changed to level - 2. Ich habe es nochmal 15 Minuten beobachtet -- keine einzige Meldung mehr!
Die Logs vom 21:04 Uhr könnten auch vom Reboot des Unifi-Switches stammen ...
Ich hoffe mal, dass es da war und markiere es vorerst als gelöst.
Sonst melde ich mich gleich wieder.
Danke jedenfalls schon mal für die Hilfe und die ganzen Tipps ... hätte ich alleine vermutlich nie erraten.
Das hört sich dich schonmal jut an. Wenn was ist melde dich einfach auch per PN möglich.
Grüße und schônen Abend
Grüße und schônen Abend
Wie sind denn deine LAG Settings am Cisco? IP/MAC Hash als Load Balance Algorithmus? Oder nur Mac?
Ebenfalls am Unify mal schauen ob es dort gleich eingestellt ist.
Ebenfalls am Unify mal schauen ob es dort gleich eingestellt ist.
Leider sind die Meldungen doch noch nicht verschwunden -- wenngleich sie aber jetzt seltener sind. Ich habe gerade nochmal im Log des L3-Routers gesehen, dass...
Leider ist das Problem also doch noch nicht gelöst. Ich überlege schon, ob ich die LAGs wieder zurück baue und Einzelleitungen verwende
Ich habe es gerade gefunden:
LAG Management
Load Balance Algorithm: [x] MAC Address
Diese Einstellung ist auf den Cisco-Switches überall gleich, also insbesondere auch für die LAGs vom SG350X zum SG300. Sollte man das auf IP & MAC umstellen?
Aber Wie sehe ich das auf der Unifi-Seite? Ich meine, dass auf dem Unifi-Switch fast keine Einstellungen in Sachen LAG möglich sind.
2147482973 2020-May-12 20:34:22 Informational %TRUNK-I-PORTADDED: Port gi1/0/8 added to Po1
2147482974 2020-May-12 20:34:22 Informational %TRUNK-I-PORTADDED: Port gi1/0/6 added to Po1
2147482975 2020-May-12 20:34:20 Informational %TRUNK-I-PORTADDED: Port gi1/0/7 added to Po1
2147482976 2020-May-12 20:34:20 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/7 removed from Po1
2147482977 2020-May-12 20:34:17 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/6 removed from Po1
2147482978 2020-May-12 20:34:17 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/8 removed from Po1
2147482979 2020-May-12 20:33:21 Informational %TRUNK-I-PORTADDED: Port gi1/0/23 added to Po4
2147482980 2020-May-12 20:33:20 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/23 removed from Po4
2147482981 2020-May-12 20:31:50 Informational %TRUNK-I-PORTADDED: Port gi1/0/23 added to Po4
2147482982 2020-May-12 20:31:49 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/23 removed from Po4 Leider ist das Problem also doch noch nicht gelöst. Ich überlege schon, ob ich die LAGs wieder zurück baue und Einzelleitungen verwende
Wie sind denn deine LAG Settings am Cisco? IP/MAC Hash als Load Balance Algorithmus? Oder nur Mac?
Ich habe es gerade gefunden:
LAG Management
Load Balance Algorithm: [x] MAC Address
Diese Einstellung ist auf den Cisco-Switches überall gleich, also insbesondere auch für die LAGs vom SG350X zum SG300. Sollte man das auf IP & MAC umstellen?
Aber Wie sehe ich das auf der Unifi-Seite? Ich meine, dass auf dem Unifi-Switch fast keine Einstellungen in Sachen LAG möglich sind.
Mache IP & Mac. Das ist das was die Ubiquity auch supporten.
Ich habe das auf einem der Cisco SG350X Switches gerade aktiviert und hoffe, dass es was bringt....
In dessen LOG-Datei habe ich auch diese Meldung gesehen ... ist mir jetzt zwar zum ersten Mal aufgefallen, aber vielleicht gibt es ja einen Zusammenhang??
In dessen LOG-Datei habe ich auch diese Meldung gesehen ... ist mir jetzt zwar zum ersten Mal aufgefallen, aber vielleicht gibt es ja einen Zusammenhang??
2147482435 2021-May-10 21:48:00 Informational %LINK-I-Up: te1/0/4
2147482436 2021-May-10 21:48:00 Informational %LINK-I-Up: te1/0/3
2147482437 2021-May-10 21:46:49 Informational %2SWTRUNK-I-TRNKPORTPARAM: auto-negotiation/adv. capabilities of port te1/0/4 differ from auto-negotiation/adv. capabilities of Po1
2147482438 2021-May-10 21:46:49 Informational %2SWTRUNK-I-TRNKPORTPARAM: auto-negotiation/adv. capabilities of port te1/0/3 differ from auto-negotiation/adv. capabilities of Po1
Stell die Ports mal direkt auf 10G. Sind das Kupfer oder Glas Ports?
Ich habe nun zunächst für alle LAGs die Einstellung "IP & MAC" gewählt ... die Meldungen sind seltener geworden. Ich hoffe im Moment, dass es einfach an so einer falschen bzw schlechten Einstellung lag...?!?
Nach ein paar weiteren Tagen des Beobachtens sehe im Log des SG350X weiterhin die gleichen Meldungen. Sie sind etwas seltener geworden aber tauchen weiterhin auf; ich würde sagen grob im 10 Minuten bis 1/4-Stunden-Takt!?
Das "erstaunliche" dabei: Es sind jetzt nur noch die Ports betroffen, die über LAGs mit SG300-Switches verbunden sind.
Daher die Frage: Kann es sein, dass sich der SG350X mit dem SG300 nicht so gut verträgt? Hat sich bei cisco vielleicht in der Verwaltung der LAGs "unter der Haube" noch etwas geändert? Oder ist das alles Standardzeug und müsste ootb laufen?
In der Zwischenzeit habe ich auch mal checkMK bemüht und mir die Diagramme zum Packet Loss angesehen: Die Uhrzeiten, wo es einen Packet Lossgibt, stimmen nicht mit den Uhrzeiten überein, wo die Switche die Ports der LAGs rauswerfen und wieder neu hinzufügen...
aber die entsprechenden Uhrzeiten im Log dagegen bei:
... ob das also die Ursache für den Paketverlust ist?
Das "erstaunliche" dabei: Es sind jetzt nur noch die Ports betroffen, die über LAGs mit SG300-Switches verbunden sind.
Daher die Frage: Kann es sein, dass sich der SG350X mit dem SG300 nicht so gut verträgt? Hat sich bei cisco vielleicht in der Verwaltung der LAGs "unter der Haube" noch etwas geändert? Oder ist das alles Standardzeug und müsste ootb laufen?
In der Zwischenzeit habe ich auch mal checkMK bemüht und mir die Diagramme zum Packet Loss angesehen: Die Uhrzeiten, wo es einen Packet Lossgibt, stimmen nicht mit den Uhrzeiten überein, wo die Switche die Ports der LAGs rauswerfen und wieder neu hinzufügen...
2147483390 2020-May-16 09:42:01 Informational %TRUNK-I-PORTADDED: Port gi1/0/23 added to Po4
2147483391 2020-May-16 09:42:01 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/23 removed from Po4
2147483392 2020-May-16 09:09:05 Informational %TRUNK-I-PORTADDED: Port gi1/0/19 added to Po2
2147483393 2020-May-16 09:09:05 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/19 removed from Po2
2147483394 2020-May-16 09:09:05 Informational %TRUNK-I-PORTADDED: Port gi1/0/9 added to Po1
2147483395 2020-May-16 09:09:05 Warning %TRUNK-W-PORTREMOVED: Port gi1/0/9 removed from Po1
Bin jetzt nicht der Cisco Spezl, aber die Konfig ist beim neuen Cisco und dem sg300 in sachen Lacp die gleichen? Ist auf dem SG300 evt noch spanning tree aktiv, dann wäre aber der Zeitraum des auftreten kleiner.
Beide Seitches auf dem aktuellsten Software- Release? Ist das 10Gbit-T oder 10gbit-SR?
Beide Seitches auf dem aktuellsten Software- Release? Ist das 10Gbit-T oder 10gbit-SR?
Der Spanning Tree ist überall deaktiviert. Der "Load Balance Algorithm" ist jetzt überall auf MAC & IP eingestellt.
Software ist die aktuellste, die es gibt und die LAGs sind in diesem Fall nicht 10 GBit sondern zusammengefasste 1Gibt Leitungen (alles Kupfer)
Software ist die aktuellste, die es gibt und die LAGs sind in diesem Fall nicht 10 GBit sondern zusammengefasste 1Gibt Leitungen (alles Kupfer)
Schalte doch mal beidseitig LACP ab und konfiguriere es als statischen Trunk. LACP ist ja nur für die dynamische Aushandlung da.
Ok, wenn ich das richtig sehe, kann ich aber LACP nicht nachträglich deaktivieren ... dazu müsste ich das LAG komplett neu erstellen, oder?
Ja bisheriges Lag löschen und dann muss dieser neu erstellt werden
Leider reißen die Meldungen im Log nicht ab ... da wir noch Ersatz-Switche haben, werde ich die SG300 vermutlich komplett ersetzen können. Aber eine Sache habe ich dann doch noch gefunden, von der ich gerne wüsste, wozu sie dient:
Diese Option war meines Wissens per default aktiv -- und die gibt es auf der SG300-Seite (noch) nicht, wenn ich das richtig sehe?!
Können die Probleme mit den LAGs auch daher kommen?
Mittlerweile habe ich auch unter SmokePing gesehen, dass die SG300-Switche ordentlich "rauschen", während die SG350X relativ ruhig sind ...
Nachtrag: Hier steht etwas dazu: https://www.cisco.com/c/de_de/support/docs/smb/switches/cisco-350-series ...
Diese Option war meines Wissens per default aktiv -- und die gibt es auf der SG300-Seite (noch) nicht, wenn ich das richtig sehe?!
Können die Probleme mit den LAGs auch daher kommen?
Mittlerweile habe ich auch unter SmokePing gesehen, dass die SG300-Switche ordentlich "rauschen", während die SG350X relativ ruhig sind ...
Nachtrag: Hier steht etwas dazu: https://www.cisco.com/c/de_de/support/docs/smb/switches/cisco-350-series ...
