23.02.2017, aktualisiert um 16:40:53 Uhr

5938

LAG zwischen SG300-Switches macht Probleme. Wer weiß Rat?

Hallo.
Ich bin gerade dabei eine Teststrecke aufzubauen, bei der es darum gehen soll, mehrere Cisco-Switches per LAG zu verbinden (je 2 Leitungen).
Leider geht es an einer Stelle nicht richtig weiter, so dass ich die Frage nun hier stelle. Vielleicht weiß ja einer der Wizzards Rat?
(Um es gleich dazu zu sagen: ich bin kein IT-Profi, sondern mache das "nebenbei"...)

Hier eine Skizze vom derzeitigen Aufbau:

Es sind drei Cisco-SG300-Switche mit 10, 28 bzw 20 Ports. Der rechte Switch läuft im L3-Mode, alle anderen im L2-Mode.

Bei uns laufen alle Switches in VLAN.2 ("Switch-Netz"). Alle IP-Adressen sind in einem Subnetz 10.16.2.0/24 angesiedelt und natürlich von allen anderen Subnetzen getrennt.

Ich bin so vorgegangen, dass ich mich von links nach rechts vorgearbeitet habe. Zuerst stand das bond0 von einem Test-Rechner mit Knoppix und einer Dual-NIC zum kleinen Cisco-10-Switch. Das funktioniert (bis auf die Kleinigkeit, dass im Cisco-10 nur eine Leitung im LAG als aktiv angezeigt wird. Ein ping kommt aber an. Danach habe ich ein LAG weiter auf den großen Cisco-28 geführt. Hier sind alle VLANs drin und auch das funktioniert. Auch der Laptop (T410) gelangt problemlos auf beide Switches auf der linken Seite.

Das Problem trat auf, als ich den Cisco-28 heute mit dem L3-Switch verbunden habe. Obwohl auch hier das LAG als "aktiviert" angzeigt wird (und natürlich alle VLANs vertreten sind), kommt ein ping seltsamerweise nicht immer an. Manchmal werden die pings einfach "verschluckt" -- dann dauert es etliche Sekunden, in denen nichts ankommt. Danach geht es aber normal weiter als sei nichts gewesen. Die ping-Zeiten sind dann auch nicht ungewöhnlich hoch, sondern es läuft alles normal weiter. Die Linux-VM gelangt immer problemlos auf den L3-Cisco-20 aber es stockt ganz erheblich, wenn ich über das LAG auf einen der anderen Switchtes zugreifen will. Es muss also offenbar an der Konfiguration des LAGs oder aber an den L3-Settings liegen ... wer hat einer Idee, wonach ich suchen soll?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 330321

Url: https://administrator.de/forum/lag-zwischen-sg300-switches-macht-probleme-wer-weiss-rat-330321.html

Ausgedruckt am: 22.12.2024 um 13:12 Uhr

31 Kommentare

Neuester Kommentar

Ein sicheres Indiz das der LAG de facto NICHT funktioniert !!
Details dazu hier:
Netzwerk Management Server mit Raspberry Pi
Vermutlich am Knoppix kein LACP aktiviert mit einem 802.3ad Trunk ?!
Hast du irgendeine Art von Spanning Tree am laufen ?
Generell sind solche Kaskaden Designs tödlich im Ethernet Umfeld. Weiss man ja auch als Netzwerker und macht man deshalb nicht. Aber mit einer 3er Kaskade bist du grade noch so an der Toleranzgrenze.
Auf alle Fälle sollten die LAGs sauber und stabli laufen. Link Ausfälle passieren meistens dann wenn Spanning Tree rennt und es irgendwo zu einem Loop kommt.
Möglich das der Knoppix falsch konfiguriert ist und dort kein LAG aktiv ist und es deshalb zu einem STP Event kommt (Blocking)
Da du hier auch von einer VM sprichst ist es vermutlich gar nicht Knoppix selber sondern ein Hypervisor OS was hier mit einem LACP LAG per 802.3ad angebunden ist...oder vemutlich nicht weil kein LACP und erst gar kein Trunk zustande kommt.
Der fehlende 2te aktive Link spricht ja deutlich dafür das hier was nicht stimmt.
Ohne Config Screenshots und Logs kann man das aber nur im freien Fall raten

Ok, ich könnte den Knoppix-Rechner problemlos wieder ziehen. Das war nur ein Test. Die config der "interfaces"-Datei kam übrigens genau von dem Link, den du angegeben hast. Da ist "bond-mode 802.3ad" mit drin. Spanning Tree ist aber imho nicht aktiv.

Warum meinst du, dass solche Kaskaden tödlich sind? Wir sind baulich darauf angewiesen, dass mehrere Switches hintereinander geschaltet sind. Die abgebildete "Hauptstrecke" wollten wir mit den LAGs schneller machen (immer 2x 1GBit).

Die LAGs scheinen auch zu laufen -- zumindest zeigen alle Cisco-Switches "aktiv" inkl. der richtigen Ports an, die ich oben immer dazu geschrieben habe.
Ich gelange im Moment nur an die Configs vom L3-Switch, da ich das LAG zum nächsten Switch wieder getrennt habe. Dessen Konfig könnte ich als Screenshot posten. Ich könnte mir vorstellen, dass das Problem mit der PVID 1 bzw dem default-VLAN zu tun hat? Ich habe da mal was gehört, dass Cisco immer 1 haben will. Ist da was dran? Bei uns müsste es ja PVID.2 sein, wenn mich nicht alles täuscht?

Noch eine Ergänzung: Der Knoppix-Rechner ganz links ist bare-metal. Das war -wie gesagt- nur eine Testumgebung und kann wieder weg.
Die VM ganz rechts läuft unter Proxmox. Der L3-Switch ist mit einem Proxmox-Host verbunden. Von dort klappt der Zugriff (nicht abgebildet, aber auch über ein LAG)

Twisted Pair bzw. Glasfaserinfrastrukturen sind immer Sternstrukturen im Ethernet. Das sollte man auch so belassen. In redundanten Designs bedeuten solche Kaskaden immer große Latency und Performanceverluste da mancher Traffic über die ganze Kaskade hin und zurück muss.
Bei dir ist das ebenfalls der Fall im VLAN Routing. Traffic wandert durch die gesamte Kaskade bis zum L3 Switch und wieder zurück. Nicht sehr gerade produktiv.
Viel schlimmer sind aber Recovery Zeiten im Redundanz Fall bei solchen Kaskaden. Das kann bis zu 10Minuten betragen deshalb vermeiden verantwortungsvolle Netzwerker solche Strukturen wo immer sie können.
Bzw. verwenden spezielle Ring Protokolle wie REP (Cisco) oder MRP (Brocade) usw. welche optimiert sind auf solche Strukturen. Mehr als eine 3er Kaskade sollte man niemals machen aus diesen Gründen auch wenn technisch mehr möglich sind.
Gut, wenn die Knoppix Kiste wirklich "bond-mode 802.3ad" macht ist das ja richtig. Verwunderlich nur das ein Link dann nicht hochkommt. Das zeigt das hier was nicht stimmt.
Entweder auf Switchseite oder auf Hostseite.
Hast du da mal mit tcpdump oder Wireshark nachgesehen ob an beiden Links LACP Frames vom Cisco kommen ??
Da ist in jedem Falle was faul.
Spannend wäre mal zu wissne ob die Ausfälle weg sind wenn der Knoppix nur noch einbeinig dran ist oder ganz ab ist ?

default-VLAN zu tun hat? Ich habe da mal was gehört, dass Cisco immer 1

Das stimmt, ist aber nicht nur bei Cisco so sondern bei den meisten anderen Herstellern auch. Auf einem tagged Uplink liegt das Default VLAN immer untagged an. Der 802.1q Standard definiert das so und die meistens Hersteller haben das so umgesetzt.
Will man das nicht muss man das dediziert deaktivieren.
Bei Knoppix oder Linux ist es übrigens auch so !! Damit das dann voll kompatibel.

Du kannst dir im Switch GUI (oder CLI) immer den LACP Status ansehen ob der LAG gebildet ist und beide Links UP sind was dafür zwingend ist.
Schneller wird so ein Link übrigens nicht, denn du veränderst die physische Geschw. ja nicht. Er hat nur mehr Kapazität. 802.3ad nutzt ein Hashing Verfahren um die Sessions Mac oder IP Adress basiert zu verteilen.
Infos dazu hat auch dieser Thread:
Cisco LAG-LACP an Synology RS3614xs+ Bonding Bandbreite zu niedrig

Du solltest mal strategisch vorgehen und erstmal nur die Switch Kaskade mit den LACP LAGs aufsetzen.
Sehr wichtig ist dabei das die Links die einen LAG bilden immer identische VLANs tagged übertragen sollten. Hier sollte es niemals zu einem Mismatch kommen. Das gilt sowohl für die LAG Links der einen Seite als auch für die der anderen Seite !
Wenn die stabil stehen, dann schliesst du an beiden Enden einen Rechner erstmal einbeinig und machst einen 5 minütigen Dauerping.
Wenn der fehlerfrei rennt dann mal wieder die Knoppix Kiste ran. Dort müssen dann aber BEIDE Links des LAGs auf UP gehen !!
Hilfreich natürlich auch die SG-300 alle auf die aktuellste Firmware Version zu flashen !

Ok, ich werde das mal weiter testen und zunächst den Knoppix-Rechner ziehen.

Als kleiner Nachtrag: Selbst wenn der Knoppix-Rechner gar nicht angeschaltet war, lieferte die eine Leitung Dauerfeuer (LEDs) -- die andere war hingegen aus. Vielleicht ist das also wirklich aus irgendwelchen Gründen ein Loop?

Wäre es in meinem Fall denn ratsam, das default-VLAN überall auf 2 zu setzen?

Wir haben hier diverse Gebäudeteile mit 2er und manchmal auch 4er Leitungen verbunden. Die laufen allerdings nicht alle in einem Raum zusammen sondern treffen sich kreuz und quer verteilt in diversen kleinen Serverschränken, wo dann die Patchfelder + Switche hängen. Also ein ziemlich "normaler", klassischer Aufbau, würde ich meinen?
Weitere zusätzliche Leitungen sind nicht so einfach möglich (auch aufgrund unfassbarer Brandschutzbedinungen...). Daher sind wir auch weiterhin auf so eine Switch-Kaskade angewiesen, wenn ich das richtig sehe, oder?

(Gerade auch noch diesen Beitrag bzw deine Antwort gefunden: Grundsatzfrage Verbindung von Switches untereinander )

Hallo,

darf ich mal blöd fragen bitte:

Inwiefern dürfen wir uns vorstellen wenn du sagst die baulichen Gegebenheiten zwingen euch so ein Netzwerk Design auf?

Sind die Strecken zwischen den einzelnen Switches wirklich ~50m?

Denn falls nicht, wird dir nix aufgezwungen

Gruß

Es geht über max. 5 Etagen kreuz und quer zwischen mehreren Gebäuden hin und her. Da kommen locker 50 Meter zusammen -- eher mehr.
Außerdem sind das natürlich gewachsene Strukturen, die mit der Zeit immer größer wurden...

Zitat von @White-Rabbit2:

zwischen mehreren Gebäuden hin und her.

Ouch... Potentialausgleich schon mal gehört? Sollte man niemals mit Kupfer machen sowas.

Tut jetzt nichts direkt zur Sache (aber ev indirekt), ist als gut gemeinter Rat zu verstehen.

Da kannst du dir im worst case die Bude abfackeln

Gruß

Ok -- nicht "hin und her" -- sondern nur "hin". Es bleibt ja eine Sternstruktur aber leider mit ein paar Zwischenstationen.

Hallo,

(Um es gleich dazu zu sagen: ich bin kein IT-Profi, sondern mache das "nebenbei"...)

ich würde einmal sagen wollen wenn wir hier schon von Netzwerken reden und zwar von strukturierten Netzwerken
dann sind sicherlich einige Möglichkeiten vorhanden so etwas umzusetzen und/oder zu realisieren, nur wie viel Sinn
die eine oder andere Struktur macht ist damit noch lange nicht geklärt, ebenso wenig ob es vernünftig ist die eine oder
andere Struktur zu bevorzugen oder sie gar abzulehnen. Und sicherlich sind gewachsene Netzwerke keine Seltenheit bzw.
geben auch mitunter Gebäudestrukturen vor wie man etwas realisiert, aber es sollte dann auch funktionieren und man sollte
sich dann auch nicht wundern, wenn es einmal knallt und man richtig draufzahlt für all die gesparte zeit und das gesparte Geld.

Bei Eurer höchstwahrscheinlich dezentralen Netzwerkstruktur die Stück für Stück gewachsen ist und von Leuten betreut wird
die nicht all zu viel Ahnung von der Materie etwas haben, kann so ein Problem wie oben beschrieben meist aber auch nicht mehr
nur auf die eine oder andere Sache geschoben werden sondern die Probleme können auch ganz wo anders auftauchen bzw. von
ganz woanders herrühren!

Ich bin gerade dabei eine Teststrecke aufzubauen, bei der es darum gehen soll, mehrere Cisco-Switches per LAG zu verbinden
(je 2 Leitungen).

Sollte kein Problem sein, denn die sind kompatibel zu- und untereinander, das sollte schnell erledigt sein.

Leider geht es an einer Stelle nicht richtig weiter, so dass ich die Frage nun hier stelle. Vielleicht weiß ja einer der Wizzards Rat?

Ein Switch in der Mitte und zwei Switche an diesen heran also als Stern (zentral) wäre aber trotz alledem besser denn dann kann
man ausschließen dass dort an den anderen Punkten der Fehler zusuchen ist, ok das ist jetzt zwar ""nur"" der Testaufbau, aber bei
Eurer wild gewachsenen Netzwerkstruktur kann der Fehler eventuell auch von ganz wo anders herrühren!

Es sind drei Cisco-SG300-Switche mit 10, 28 bzw 20 Ports. Der rechte Switch läuft im L3-Mode, alle anderen im L2-Mode.

Egal ob es nun dezentral oder zentral, vermascht oder voll vermascht aufgesetzt worden ist, wenn man schon alles untereinander
verbinden möchte (Uplink oder Stapel) sollte man dafür auch die richtigen Switche benutzen. Denn alle Cisco SG Switche haben in
der Regel zwei SFP Slots und diese lassen sich optimal an Switche mit ausschließlich nur SFP/SFP+ Ports anschließen bzw. bündeln.
Cisco SG300-28SFP 28-port Gigabit SFP Managed Switch
Cisco SG350XG-24F 24-Port 10G SFP+ Stackable Managed Switch

An beide Switche ob nun als Core Switch im Core LAyer3 oder Distributed Switch im Distributed Layer lassen sich alle Deine (Eure)
anderen Switche mittels SFP anbinden und das auch via LAG (LACP), warum also das über Kupferports (RJ45) abwickeln.

Bei uns laufen alle Switches in VLAN.2 ("Switch-Netz"). Alle IP-Adressen sind in einem Subnetz 10.16.2.0/24 angesiedelt und
natürlich von allen anderen Subnetzen getrennt.

Ist ja auch ok so.

Ich bin so vorgegangen, dass ich mich von links nach rechts vorgearbeitet habe. Zuerst stand das bond0 von einem Test-Rechner mit
Knoppix und einer Dual-NIC zum kleinen Cisco-10-Switch. Das funktioniert (bis auf die Kleinigkeit, dass im Cisco-10 nur eine Leitung
im LAG als aktiv angezeigt wird.

Und was ist dort denn nun konfiguriert!? active/passive oder was genau?

Was passiert denn wenn man beide L2 Switche an den L3 Switch direkt dran anschließt?
Hast Du dort eine Art von STP (RSTP, MSTP) konfiguriert?

Wir haben hier diverse Gebäudeteile mit 2er und manchmal auch 4er Leitungen verbunden.

Hoffentlich mittels SFP und nicht mittels Kupferkabel!!

Die laufen allerdings nicht alle in einem Raum zusammen sondern treffen sich kreuz und quer verteilt in diversen kleinen Serverschränken
, wo dann die Patchfelder + Switche hängen.

Hm, was sollen oder dürfen wir uns denn darunter vorstellen!?

Also ein ziemlich "normaler", klassischer Aufbau, würde ich meinen?

Eher nicht oder?

Weitere zusätzliche Leitungen sind nicht so einfach möglich (auch aufgrund unfassbarer Brandschutzbedinungen...).

Sind denn dort keine Kabelkanäle vorhanden in die man neue Kabel einziehen kann?

Daher sind wir auch weiterhin auf so eine Switch-Kaskade angewiesen, wenn ich das richtig sehe, oder?

Ich würde davon eher abraten wollen, aber das macht auch immer jeder wie er meint.

Gruß
Dobby

Gruß
Dobby

lieferte die eine Leitung Dauerfeuer (LEDs)

Böses Faul !! Das sieht nach einem Loop aus !
Du solltest deshalb in jedem Fall RSTP aktivieren wie es in soclhen Kaskaden Netzen zwingend anzuraten ist !!!

Wäre es in meinem Fall denn ratsam, das default-VLAN überall auf 2 zu setzen?

Nein, was sollte der tiefere Sinn davon sein ? Ob 1 oder 2 ist doch Latte.
Wichtig sist das alle deine LAG Uplinks immer die gleiche VLANs tagged übertragen und das es da keinen Mismatch gibt !!

Gebäudeteile mit 2er und manchmal auch 4er Leitungen verbunden.

Was meinst du damit ?? Duplex Fasern ? Was du als "Leitung" bezeichnest ist das eine Duplex Faser oder eine singuläre Faser ?

klassischer Aufbau, würde ich meinen?

Nein, leider nicht !
Fehlerhafter Aufbau denn der Verkabler hat sein Handwerk nicht verstanden oder hat vollkommen falsche Vorgaben von jemanden bekommen der nicht weiss was Netzwerke sind.
Hier berücksichtigt man eigentlich immer Stern Strukturen und passt die Verkabelung entsprechend an die Bedürfnisse an.
Aber egal, wenn du sowas Übles hast und nicht ändern kannst musst du ja damit erstmal leben. Toll ist das nicht auch für die Gesamtperformance des Netzes, aber was willst du anderes machen als damit zu leben wenn du keinen neuen Fasern ziehen kannst ?
Eine 3er Kaskade ist ja auch noch tolerierbar...grade

Viel sinnvoller wäre es aber gewesen du hättest hier SG-500er oder Switches genommen die sich in einen Full Stack verwandeln lassen über ihre Uplinks. Damit hätte man dann keine Kaskade mehr sondern einen gesamten Switch, quasi als Backbone.
In einem soclhen Stack verhalten sich alle Member quasi wie Einschübe eines Chassis Switches und der komplette Stack lässt sich wie ein zentraler Switch verwalten und managen.
Falsche HW zu falscher Verkabelung gekauft, denn das wäre die ideale Lösung gewesen mit Stack Switches...egal.

Aber trotzdem bekommt man es mit der 3er Kaskade und LAGs natürlich auch hingefrickelt.
Habs hier mal aus 2 mal SG-200 und einem Catalysten nachgestellt und rennt jetzt seit 24 Stunden mit einem iPerf Dauertest über die LACP Links fehlerlos und ohne jeglichen Ausfall !
iPerf deswegen weil man da mehrere Sessions generieren kann um eine Verteilung über die LACP Links zu erzwingen.
Natürlich mit RSTP aktiviert.

SG-200 LAG channel 1:

SG-200 channel 1 Parameter und Status UP:

Catalyst Gegenpart:

Channel group 3 neighbors

Partner's information:

          Partner               Partner                     Partner
Port      System ID             Port Number     Age         Flags
Fa0/1     00128,203a.07f4.f37e  0x8              14s        SA     <---SG200 Mac Adresse

          LACP Partner         Partner         Partner
          Port Priority        Oper Key        Port State
          128                  0xA             0x3D

          Port State Flags Decode:
          Activity:   Timeout:   Aggregation:   Synchronization:
          Active      Long       Yes            Yes

          Partner               Partner                     Partner
Port      System ID             Port Number     Age         Flags
Fa0/2     00128,203a.07f4.f37e  0x7              14s        SA     <---SG200 Mac Adresse

          LACP Partner         Partner         Partner
          Port Priority        Oper Key        Port State
          128                  0xA             0x3D

          Port State Flags Decode:
          Activity:   Timeout:   Aggregation:   Synchronization:
          Active      Long       Yes            Yes
Catalyst# 

Hier als Quercheck das die LACP Neigbor Mac Adresse auf der SG-200 ist:

Du kannst sehen das beide LACP Links in den State Active gegangen sind was ein sicheres Indiz dafür ist das beide Links als LAG arbeiten.
Wenn du SNMP aktivierst auf deinen Switches kannst du mit einem kleinen Tool wie STG auch grafisch sofort sehen wie die Traffic Auslastung der einzelnen Links des LAGs ist:
http://leonidvm.chat.ru

Eigentlich alles ganz easy

Ok, ich sehe schon: Es gibt noch viel zu lernen

An der Verkabelung kann ich leider nicht viel ändern. Jedenfalls nicht von heute auf morgen und schon gar nicht in Eigenregie, da das viel zu aufwendig und teuer wäre (Gibt es eine Faustformel: "100 m Glasfaser kosten.... ?").
Ich muss die Situation also vorerst so hinnehmen, wie sie ist.

Mit "Leitung" meinte ich stinknormale CAT.6-Kabel. Da sind fast überall Doppelkabel verlegt, von denen dann aber nur eine Leitung vom Patchfeld auf den Switch geht. Da die Doppelkabel aber nunmal vorhanden sind, lag der Gedanke nicht ganz fern, diese für ein LAG zu nutzen.

Also heute habe ich die Knoppix-VM (also ganz links in der Skizze) sowie die Verbindung zum L3-Switch (also ganz rechts) gezogen und mir nochmal NUR das LAG zwischen den Cisco-10 und dem Cisco-28 mit dem T410 angesehen. Das läuft stabil und beide Leitungen sind aktiv. Es ist aber tatsächlich so, dass das nur klappt, wenn VLAN.1 untagged übertragen wird. Da unser Switch-Subnetz aber komplett in VLAN.2 steckt, kann ich auf diesem Weg VLAN.2 nur tagged mit übertragen. Die IPs 10.16.2.x der Switche kann ich auf diesem Weg aber dann nicht von einem Rechner aus erreichen, der irgendwo hinter dem L3-Switch steht, meine ich?
Daher die Frage, ob es etwas bringen würde, wenn ich das default-VLAN auf den beiden L2-Switches auf "Default VLAN.2" umstellle, da ich dann vermutlich 2 untagged übertragen und auch vom L3-Switch (bzw jenseits davon) wieder auf alle Switche zugreifen kann? Oder sehe ich das falsch?

Hallo,

(Gibt es eine Faustformel: "100 m Glasfaser kosten.... ?").

100 €

Nachdem wir hier im Forum vor ein paar Tagen erst eine Diskussion um das ungeliebte VLAN 1 hatten...
Ändere deine Konfiguration mal komplett auf eine andere VLAN ID

brammer

Es gibt noch viel zu lernen

Eine weise Erkenntnis

An der Verkabelung kann ich leider nicht viel ändern

Musst du auch nicht, sondern mit ihr leben. Siehe oben. Schnell kann man die Fehler eh nicht ausräumen die damals bei der Verkabelung gemacht wurden

(Gibt es eine Faustformel: "100 m Glasfaser kosten.... ?").

Ja, am besten euren Hausverkabler fragen. Aber nicht den der es schon so verbockt hat

lag der Gedanke nicht ganz fern, diese für ein LAG zu nutzen.

Macht auch Sinn.

Also heute habe ich die Knoppix-VM (also ganz links in der Skizze)

Ahem...nun also doch VM ?? Gestern hast du noch gesagt das ist bare metal ??! Was denn nun.
Wenn es wirklich eine VM ist dann macht der Hypervisor bzw. dessen internen vSwitch den physischen LAG auf den Switch und NICHT die VM !! Das solltest du beachten !

mit dem T410 angesehen

Bahnhof ?? T410 ?? Ist das ein russischer Panzer ?

Es ist aber tatsächlich so, dass das nur klappt, wenn VLAN.1 untagged übertragen wird.

Klar, ist Standard, denn das VLAN 1 ist das native VLAN an den Uplink und LACP nutzt das vermutlich für die LAG Negotiation.

komplett in VLAN.2 steckt, kann ich auf diesem Weg VLAN.2 nur tagged mit übertragen.

Auch das ist vollkommen normal. Im Test oben sind 3 VLANs 10, 20 und 100 auf dem LAG Uplink übertragen. Simpler Standard also und kein Hinderungsgrund.
Das muss ja auch so sein, denn sonst ohne VLAN 2 Tags würden die Switches nicht mehr wissen welchem VLAN sie den Traffic zuordnen sollen... Works as designed. Das VLAN brauchst du de facto NICHT ändern !
Die gleiche Konfig rennt hier im Setup fehlerfrei.

Die IPs 10.16.2.x der Switche kann ich auf diesem Weg aber dann nicht von einem Rechner aus erreichen, der irgendwo hinter dem L3-Switch steht, meine ich?

Das ist ja, sorry, völliger Quatsch, denn der L3 Switch routet ja zwischen den VLANs ! Deswegen hast du da ja einen L3 Switch !
Also routet er zwischen VLAN 1 und 2 und so kann jedes Endgerät im VLAN 2 auch die Switch Management IPs im VLAN 1 erreichen und vice versa.
Das ist also Unsinn was du da sagst.

Wichtig ist das ALLE verwendeten LAG Links zwischen deinen Switches 10, 28 und 20 immer den selben Mode und Tagging eingestellt haben:
Trunk Mode, Untagged = VLAN 1 und Tagged = VLAN 2

U = Untagged, T = Tagged

Gig 8 ist hier einer der LACP Links aus dem Test oben.

Der L3 Switch hat dann eine IP im VLAN 2. Bei dir hoffentlich 10.16.2.254 /24 oder 10.16.2.1 /24 und die Endgeräte im VLAN 2 haben DIESE Switch IP im VLAN 2 immer als Default Gateway !!!
Wenn dem so ist kannst du auch die Management IP der Switches im VLAN 1 problemlos erreichen. Klar, denn der Cisco L3 kann zwischen beiden Netzen routen.
Alternativ kannst du das Management der Switches natürlich auch in das VLAN 2 legen um sie aus dem VLAN 2 direkt zu erreichen:

Auch das ist natürlich möglich.
Besser aber man hält als verantwortungsvoller Netzwerker das Infrastruktur Management immer getrennt vom Produktivnetz, damit da keiner auf dumme Gedanken kommt.
Wie bereits gesagt...."Es gibt noch viel zu lernen !"

Also heute habe ich die Knoppix-VM (also ganz links in der Skizze)

Ahem...nun also doch VM ?? Gestern hast du noch gesagt das ist bare metal ??! Was denn nun.

Sorry, war mein Fehler. Die VM ist ganz rechts abgebildet. Ich meinte den "echten" Rechner ganz links. Der läuft auf bare-metal und ist nicht mehr mit dem Rest verbunden.

mit dem T410 angesehen

Bahnhof ?? T410 ?? Ist das ein russischer Panzer ?

Der T410 ist einfach ein Laptop von Lenovo ... (Typenbezeichnung)

Ok. Dann habe ich das falsch verstanden. Mir war schon klar, dass der L3-Switch das Routing zwischen den VLANs macht. Andererseits ist es ja so, dass ein Endgerät immer untagged an einem Port hängen muss, wenn man das Gerät direkt/normal erreichen will. Nun ist ein Switch kein Endgerät aber ich dachte bisher, dass das VLAN, in dem der Swtich selbst steckt, ebenfalls untagged ankommen muss, wenn man direkt auf den Switch will?!

Der L3 Switch hat dann eine IP im VLAN 2. Bei dir hoffentlich 10.16.2.254 /24 oder 10.16.2.1 /24 und die Endgeräte im VLAN 2 haben DIESE Switch > IP im VLAN 2 immer als Default Gateway !!!

Ja, das haben alle Geräte in VLAN.2 so eingestellt. Bei allen anderen Switches klappt das ja auch bereits wunderbar. Das Gateway ist .254

Alternativ kannst du das Management der Switches natürlich auch in das VLAN 2 legen um sie aus dem VLAN 2 direkt zu erreichen:
Besser aber man hält als verantwortungsvoller Netzwerker das Infrastruktur Management immer getrennt vom Produktivnetz, damit da keiner auf dumme Gedanken kommt.

Ja, das war der Hintergedanke dabei. Das hatte ich schon gelernt

Zudem liegen alle nicht verwendeten Ports auf Black-Holes ... auch das war ein guter Tipp, den ich irgendwo aufgeschnappt habe.

Nochmal zurück zum "default VLAN": Wenn ich das tatsächlich auf 2 umstellen möchte (ob sinnvoll oder nicht), erscheint hier eine dicke Warnung, die danach klingt, als würden alle VLAN-Einstellungen reseted. Ich habe daher bisher darauf verzichtet. Aber du meinst, dass es auch so gehen muss, würde ich das auf VLAN.1 (untagged) + VLAN.2 (tagged) + alle anderen VLANs (tagged) lassen. Die Einstellungen sind übrigens überall identisch -- darauf habe ich heute nochmal explizit geachtet.

dass ein Endgerät immer untagged an einem Port hängen muss, wenn man das Gerät direkt/normal erreichen will.

Das ist absolut richtig, denn Tags verstehen Endgeräte logischerweise in der regel nicht im Paket !

Nun ist ein Switch kein Endgerät aber ich dachte bisher, dass das VLAN, in dem der Swtich selbst steckt, ebenfalls untagged ankommen muss, wenn man direkt auf den Switch will?!

Die Frage ist hier was du mit "ankommen" meinst ??
Wenn du z.B. dein Management VLAN ins dein VLAN 2 hängst per Konfig und mit deinem Management Laptop irgendwo dran bis kommen die Pakete ja Tagged rein am Switch, da VLAN 2 ja logischerweise immer Tagged ist an den Uplinks zw. den Switches.
Folglich muss also ankommender Traffic nicht immer Untagged sein. Tagged geht auch.
Wichtig ist hier einzig nur das das Pakte überhaupt ankommt !!

Klar wenn du das VLAN 2 als native VLAN umkonfigurierst dann geht natürlich alles was an tagged Uplinks usw. da ist verloren. Das ist ja klar.
Das Vorhaben ist aber Unsinn, denn was hättest du damit gewonnen oder wo läge der Vorteil. Gar nix !
Deshalb also Bleiben lassen, das wäre in der Tat überflüssiger Unsinn.
Hast du denn diese Instabilitäten immer noch ?
Bzw. Ist Spanning Tree RSTP bei dir durchgängig aktiviert auch allen Switches. Das sollte es nämlich ?!
Ganz wichtig hier: Der L3 Switch MUSS zwingen der Root Swith im Spanning Tree sein !!!
Dem also IMMER eine entsprechende Priority (4096) verpassen !!!

Die anderen Switches bleiben alle auf Default !!

Hast du denn diese Instabilitäten immer noch ?

Ich kann im Moment nichts testen geschweige denn weitermachen. Per Fernadministration käme ich zur Zeit nur auf den L3-Switch -- der Rest ist ja im Moment nicht miteinander verbunden. Der Dauer-PING auf der linken Seite (ohne L3) sah heute schon mal vielversprechend aus. Weitere Tests mit dem (entscheidenden) L3-Switch folgen...

Was ich heute noch gemacht habe: Die LAGs vom Cisco-10 <-> Cisco-28 und Cisco-28 <-> Cisco-20 nochmals miteinander verglichen. Es ist überall so, dass dort PVID 1 und VLAN.1 (untagged) eingestellt ist. Alles andere wird tagged mit durchgereicht (insbesondere auch VLAN.2). Ein "mismatch" kann also nicht auftreten. Mehr kann ich im Moment nicht testen. Evtl geht es Montag weiter ...

Wenn es wirklich so ist, dass man 100m Glasfaserleitung für ~100€ bekommen kann (und natürlich nochmal die SFP+ Module für ?€. Welche nimmt man da?), dann ist es ja gar nicht soooooo teuer?! Sinnvoll investiertes Geld, will ich meinen...

Spanning Tree RSTP bei dir durchgängig aktiviert auch allen Switches. Das sollte es nämlich ?!

Noch nicht. Ist wie gesagt "Nebentätigkeit"/"Ehrenamt" ... aber steht auf der to-do-Liste

Per Fernadministration käme ich zur Zeit nur auf den L3-

Weil du natürlich vergessen hast auf den anderen beiden Switches als Default Gateway die VLAN 1 IP Adresse des L3 Switches einzutragen...dzzzz

sah heute schon mal vielversprechend aus.

Hört sich gut an. So sollte es auch sein.

Ein "mismatch" kann also nicht auftreten.

Sehr gut !!

Evtl geht es Montag weiter ...

Dann sind wir gespannt

und natürlich nochmal die SFP+ Module für ?€. Welche nimmt man da?

Für 20 Euro !
https://www.reichelt.de/Medienkonverter-GBICs/DELOCK-86186/3/index.html? ...
Bei eBay bekommst du sie auch für 3 Euro gebraucht:
http://www.ebay.de/itm/HP-A7446B-SFP-1000Base-SX-4GB-SW-850nm-miniGBIC- ...
Wieso übrigens SFP+ ?? Du hast doch bloß SG-300 und die haben nur SFP Ports !
SFP+ ist 10Gig das haben die gar nicht.

... aber steht auf der to-do-Liste

Solltest du dringenst machen. Schützt das Netz auch vor Loops !

Weil du natürlich vergessen hast auf den anderen beiden Switches als Default Gateway die VLAN 1 IP Adresse des L3 Switches einzutragen...

Nein -- ich vermute, dass ich vergessen habe, das Management VLAN auf 2 umszustellen. Wenn das natürlich noch auf 1 steht, würde das erklären, warum ich die Switche von der rechten Seite (also Linux-VM hinter dem L3-Switch) nicht sehen konnte ...

Dein Screenshot oben hat mich drauf gebracht ... aber ich kann es nicht nachsehen ... die Kabel sind gezogen. Ich wollte kein LAG aktiv lassen, das nicht richtig (oder gar nicht?) funktioniert.

ich vermute, dass ich vergessen habe, das Management VLAN auf 2 umszustellen.

Das musst du aber gar nicht, da das management ja auch immer über den L3 Switch erreichbar ist.
Voraussetzung natürlich das...

entweder ALLE Switches im VLAN 1 sind mit entsprechender VLAN 1 IP und die L2 only Switche ihr Default Gateway auf die VLAN 1 IP des L3 Switches haben oder...
Das alle Switches mit ihrem Management Interface und IP im VLAN 2 hängen.

Sonst geht es zwar auch aber du musst dann immer die unterschiedliche IP angeben pro Switch was ja nervig ist.
Besser ist immer Management getrennt zu haben. Insofern ist es nicht falsch wenn man es im VLAN 1 belässt.
Ist aber deine eigene Entscheidung-

warum ich die Switche von der rechten Seite (also Linux-VM hinter dem L3-Switch) nicht sehen konnte ...

Nein, das würde es nicht erklären, denn normal wäre er auch von da erreicbar sofern die VM ihr Gateway auf die VLAN 2 Switch IP gesetzt hat.
Bei einem Zugriff auf dem Switch in VLAN 1 würde der L3 Switch das paket ins VLAN 1 routen und dann zum Zielswitch senden.
Der antwortet dann und L3 routet es wieder zur VM.
Er kann aber nur antworten wenn er auch ein VLAN 1 Default gateway auf die VLAN 1 IP des L3 Switches gesetzt hat sonst geht das Antwortpaket (da IP aus dem VLAN 2 IP Netz) natürlich ins Nirwana, klar !
Das setzt natürlich auch voraus das du logischerweise in VLAN 1 und VLAN 2 unterschiedliche IP Netze definiert hast wie es sich gehört ?!

Also die IP(s) in VLAN.1 benutze ich eigentlich überhaupt nicht. Da ist NUR der L3-Switch ganz alleine mit seiner Default-Cisco-IP (192.168.1.254 glaube ich). Anonsten ist *alles*, was für die Switche zuständig ist, ins VLAN.2 verlagert. Alle Switches haben als Gateway 10.16.2.254 (die IP des L3-Switches) eingetragen. Daher kommt für mich nur Punkt 2 in Frage:

alle Switches mit ihrem Management Interface und IP im VLAN 2 hängen.

Die IPs sind alle ganz sicher in VLAN.2 (da ich sie ja zwischendurch schon gesehen habe) aber Management-Interface muss ich checken.

das würde es nicht erklären, denn normal wäre er auch von da erreicbar sofern die VM ihr Gateway auf die VLAN 2 Switch IP gesetzt hat.

... es sei denn, dass das ACLs/ACEs gesetzt sind, die das routing verhindern. Ist aber von VLAN2 <--> VLAN1 nicht der Fall.

Das setzt natürlich auch voraus das du logischerweise in VLAN 1 und VLAN 2 unterschiedliche IP Netze definiert hast wie es sich gehört ?!

Klar -- VLAN.1 wie gesagt "default" gelassen aber nicht weiter benutzt und VLAN.2 ist 10.16.2.254 auf L3-Seite.

Ich weiß es genauer, sobald ich das LAG zum L3-Switch mit der jetzigen Konfiguration wieder gesteckt habe. Vorher bleibt es Stochern im Nebel.
Nichts desto trotz habe ich in diesem Thread wieder 'ne Menge mitgenommen. Besten Dank dafür!

Da ist NUR der L3-Switch ganz alleine mit seiner Default-Cisco-IP (192.168.1.254 glaube ich).

Glauben heisst nicht wissen

OK, wenn dem so ist dann kann der Zugriff über die VLAN 1 IP der anderen Switches natürlich nicht klappen. Wo nix iss kann man nix connecten

Daher kommt für mich nur Punkt 2 in Frage:

Das ist dann richtig. Dennoch solltest du über eine Trennung zur Sicherheit wenigstens mal nachdenken...

aber Management-Interface muss ich checken.

Das ist der Schlüssel zum Erfolg !

wieder 'ne Menge mitgenommen. Besten Dank dafür!

Immer gerne wieder !

Glauben heisst nicht wissen

Ich habe es nochmal nachgesehen: Es IST so wie vermutet: Der SG300 hat als default-IP die 192.168.1.254. Die habe ich in VLAN.1 genau so gelassen....

Das ist dann richtig. Dennoch solltest du über eine Trennung zur Sicherheit wenigstens mal nachdenken...

Hm -- verstehe ich jetzt nicht: Ich habe in VLAN.2 bei mir ja NUR die IPs der Switche und eine VM, die ebenfalls in VLAN.2 angesiedelt ist, um auf alle Switches gelangen zu können. Alles andere liegt völlig getrennt davon in anderen Subnetzen/VLANs, so dass auch niemand ohne weiteres an die IPs in 10.16.2.0/24 kommen kann. Zusätzlich ist eine ACL/ACE eingerichtet, die als Quell-IP nur IPs aus dem gleichen Subnetz zuläßt. Natürlich geht VLAN.2 "notgedrungen" immer mit über die Leitung zu allen Switches, doch ich habe das immer nur auf 2 Ports untagged liegen. Alle anderen Ports sind immer in anderen VLANs untergebracht. Daher dachte ich, dass das an Sicherheit ausreichen sollte. An die Switche kommt jedenfalls von außen auch niemand heran, da die alle eingeschlossen sind... ich denke mal, dass du das so meintest und wir irgendwie aneinander vorbei geredet haben?

Der SG300 hat als default-IP die 192.168.1.254. Die habe ich in VLAN.1 genau so gelassen....

OK, das musst du dann natürlich ändern wie du schon sagst auf eine VLAN 2 IP und das Management dann in das VLAN hieven.
Wenn VLAN 2 nicht dein Produktivnetz ist dann ist das auch absolut richtig.
Nicht das du das missverstehst. Der Hinweis mit der Trennung bezog sich nur darauf Management Traffic nicht in Produktivnetze zu hängen.
Alles gut also

OK, das musst du dann natürlich ändern wie du schon sagst auf eine VLAN 2 IP und das Management dann in das VLAN hieven.

Nochmal die Rückfrage, um alle Missverständnisse zu vermeiden:
Der L3 Switch besitzt in VLAN.1 die IP 192.168.1.254 und in VLAN.2 die IP 10.16.2.254. Die Einstellungen im L3 müssten damit richtig sein.
Einstellungen zum " Management VLAN" finde ich auf dem L3 nicht -- zumindest nicht unter "IPv4 Interface" so wie das der Fall ist, wenn der im L2-Mode läuft. Macht auch wenig Sinn, da der L3-Switch ja in jedem VLAN über seine Subnetz-IP aufrufbar ist (solange man das nicht mit ACE/ACL blockiert)?

Die L2-Switches sind ebenfalls in 10.16.2.x/24 aber haben als "Management VLAN" vermutlich noch VLAN.1 anstelle von 2 eingestellt (moment nicht prüfbar). DORT kann man das Management-VLAN auch in den Einstellungen zu "IPv4 Interface" umstellen. Daher nehme ich mal stark an, dass sich deine Aussage oben nun auf die L2-Switches bezog...

Wenn VLAN 2 nicht dein Produktivnetz ist dann ist das auch absolut richtig.

Ok - da sind wir uns einig. Da läuft nichts aus dem Produktivnetz.

Die Einstellungen im L3 müssten damit richtig sein.

Ja, sind sie. Wenn du VLAN 1 gar nicht nutzt kannst du die IP dort auch löschen.

da der L3-Switch ja in jedem VLAN über seine Subnetz-IP aufrufbar ist

Stimmt ! Beim L3 Switch ist das obsolet.

vermutlich noch VLAN.1 anstelle von 2 eingestellt (moment nicht prüfbar).

Genau das wird das Problem sein. Änder das, dann passt das auch.

Ich markiere das Thema schon mal als gelöst und hoffe, dass das 2. LAG ebenfalls problemlos laufen wird.

In diesem Zusammenhang wäre nun aber eine andere Frage interessant (könnte einen neuen Thread dazu öffnen ... aber thematisch passt es auch hier):

Der SG300 ist im L3-Modus "per default" von jedem Subnetz aus erreichbar (als Gateway). Allerdings betrifft das auch den Zugang zur Weboberfläche sowie via SSH. Das würde ich gerne weiter einschränken, damit auf den Switch nur noch aus VLAN.2 via Port 22 bzw 443 zugegriffen werden kann und alle anderen VLANs nicht zugreifen können.
Bei den tcp/udp-Services kann man das nicht direkt einstellen, wenn ich's richtig gesehen habe. Daher vermute ich, dass man die ACEs/ACLs entsprechend anpassen muss, um diesen Zugriff zu blockieren? In den vorgefertigten Listen der tcp-Services ist aber weder SSH noch httpS dabei ... daher die Frage, ob das so überhaupt die richtige Vorgehensweise wäre oder ob das noch anders läuft?

Daher vermute ich, dass man die ACEs/ACLs entsprechend anpassen muss

So ist es auch.... Ist richtig
Einfacher ist es ein Access profile zu erstellen unter "Security" -> "Mgmt access methods" -> "Access profiles".

Hier kannst du Regeln auf Port Basis oder was noch erheblich besser ist per Absender IP Basis erstellen
(Siehe "User Defined" und "Applies to Source IP Address").
Das bedeutet damit kannst du den Zugraif nur auf das management von einer bestimmte Absedner IP z.B. VLAN Segment, einzelnen Rechner usw. auf das Mgmt Interface limitieren.
Setzter regelsatz sollte dann natürlich ein "deny all" sein

Nochmal ein Nachtrag ... irgendwo hatte ich davon gelesen, wie du beschrieben hast, wie man unter Linux ein LAG derart testen kann, dass man sehen kann, welcher Traffic gerade über welche Leitung geht. Wenn ich mich richtig erinnere, hing das damit zusammen, dass der Traffic bei nur einer Mac-Adresse immer über die gleiche Leitung geht und man "tricksen" muss, damit beide Leitungen des LAGs benutzt werden? Das Windows-Tool
stg von http://leonidvm.chat.ru/ habe ich gefunden -- aber das meinte ich nicht. Ich meine, dass du irgendwo von einer Linux-Lösung geschrieben hast ... nur wo? Danke nochmal.

Linux macht das mit Cacti oder MRTG:
Netzwerk Management Server mit Raspberry Pi

hm .. aber damit sehe ich nicht, welche Daten durch welche Leitung eines LAGs (direkt vom Rechner zum Switch!) gegangen sind, oder??
Ich meine, dass du noch etwas anderes beschrieben hast, was in diese Richtung ging:

--> Cisco LAG-LACP an Synology RS3614xs+ Bonding Bandbreite zu niedrig

Zitat : " Wenn dann wie bei dir jeweils nur ein einzelnes Gerät, das ja immer eine identische und feste Mac oder IP hat in Source und Destination und einen festen Application Port kommunizieren ist der Hash der dann auf den physischen Link zeigt ja immer derselbe.
Folglich wird also diese Kommunikation immer auf einem und demselben Link abgewickelt.
Das ist systembedingt durch den unterliegenden 802.3ad Standard."

Über die Layer 2 Forwarding Tabelle im Switch kannst du sehen welche Mac er physisch über welchen Port schickt.
Die kann man über das CLI oder per SNMP auslesen.
Das STG Tool zeigt nur den quantitativen Traffic an wieviel über welchen Link geht aber nicht von wem (Mac Adresse)
Das Zitat ist eine logische Konsequenz auf dem 802.3ad Hashing. Bei bestimten Mac Adress Pärchen zeigt der errechnete Hashwert des LAGs im Switch ja immer auf den gleichen Link. Da du die Mac Adressen (oder IPs je nachdem wie die Hashberechnung konfiguriert ist) ja nicht ändern kannst bleibt das immer so.
Bessere Switches nehmen für die Hash Berechnung oft noch den UDP oder TCP Port mit dazu um etwas mehr Entropie reinzubekommen...aber eben nur bessere Switches.

gelöst Frage Hardware Switche, Hubs

Mehr von White-Rabbit2

Verbindung über VLAN bricht alle paar Sekunden zusammen - mögliche Ursache?White-Rabbit2 - 3 Kommentare

Samba: task(ldap) pre-forked worker - 100 Prozent CPU LastWhite-Rabbit2 - 1 Kommentar

Frage zu IGMP-Snooping - wie implementiert man das?White-Rabbit2 - 9 Kommentare

Frage zu Jumbo FramesWhite-Rabbit2 - 40 Kommentare

Heiß diskutiert