hansdampf06
Goto Top

OPNsense - VLAN will mit nachgeschaltetem Switch nicht funktionieren

Hallochen Gemeinde,

folgende vorhandene Konstellation:
Lokales AD-Netzwerk an zwei Standorten mit OPNsense als jeweiligem Router. Die OPNsense erledigt das netzwerkweite Routing einschließlich VLAN. Für zwei Fremdrechner von Kunden ist (nunmehr) ein eigenes VLAN eingerichtet worden. Die Konfiguration der beiden OPNsensen ist insoweit identisch.

An dem einen Standort funktioniert die VLAN-Separierung von der OPNsense über einen 24er Switch und danach einem Zyxel GS1200-8 auf Anhieb und problemfrei.

An dem zweiten Standort ist der OPNsense nur ein Zyxel GS1200-8HP nachgeschaltet. Stelle ich dort die VLAN-Konfiguration auf irgendeine VLAN-ID scharf, sehe ich im Live-Kino der OPNsense zwar den vom Fremdrechner kommenden Verkehr. Aber es gibt ganz offensichtlich keinen Rückverkehr.
Realisiere ich hingegen die logische Netzwerktrennung nicht über das VLAN, sondern füge stattdessen der LAN-Schnittstelle der OPNsense den betreffenden VLAN-IP-Bereich als weiteren Netzwerkbereich hinzu (mittels virtueller IP-Adresse) und belasse auf dem Switch alles auf der VLAN-ID 1, so klappt alles hervorragend.

Es spielt übrigens keinerlei Rolle, mit welcher VLAN-ID und welchem an dem Switch angeschlossenem Gerät das Ganze versucht wird, weil sich übergreifend das Problem jederzeit identisch rekonstruieren und "beseitigen" lässt.

Woran kann diese Kuriosität am zweiten Standort liegen?
Meine Vermutung / Erklärung ist, dass der GS1200-8HP (noch die Version 1) zwar grundsätzlich ordnungsgemäß läuft, aber bei der VLAN-Konfiguration aus irgendeinem Grund nicht mitspielt. Denn ich habe verschiedene Ansätze durchgespielt und kann im Ergebnis dessen - gerade auch mit Blick auf den anderen funktionierenden Standort - sagen, dass nur der Switch als Ursache in Betracht kommen kann.

Hat jemand schon ähnliche Erfahrungen mit einem Switch gemacht? Gibt es einen Lösungsansatz, ohne den Switch physisch auszutauschen zu müssen?
Gibt es eine passende Custom Firmware für diesen Switch (ähnlich OpenWRT für Router)? Auf den ersten Blick habe ich (noch) nichts finden können.

Vielen Dank im Voraus für Euren Input und viele Grüße
HansDampf06

Content-ID: 668514

Url: https://administrator.de/forum/opnsense-vlan-will-mit-nachgeschaltetem-switch-nicht-funktionieren-668514.html

Ausgedruckt am: 22.12.2024 um 03:12 Uhr

aqui
aqui 01.10.2024 aktualisiert um 13:25:08 Uhr
Goto Top
Das Setup des GS-1200 Switches ist eigentlich immer identisch! HIER ist das genaue Prozedere beschrieben an der OPNsense.
Wichtig ist immer das man dort nicht benutzte Memberports ausgraut. Aktuelle Switch Firmware sollte auch drauf sein.
Der Fehler liegt ja da ganz klar im VLAN Setup. Screenshot wäre hier hilfreich gewesen! face-sad
Im Zweifel einen Werksreset mit aktueller Firmware und nochmal in Ruhe von vorne anfangen. Solche groben Fehlfunktionen liegen in der Regel nicht am Switch selber sondern am Setup. face-wink
HansDampf06
HansDampf06 01.10.2024 aktualisiert um 13:47:30 Uhr
Goto Top
@aqui:
Danke für Deinen Hinweis. Aber die VLAN-Konfiguration auf dem Switch ist kein Hexenwerk, wie in dem von Dir verlinkten Tutorial zu ersehen ist. Alle VLAN's auf dem Switch nochmals zu löschen und dann zunächst nur eine VLAN-ID hinzuzufügen, bleibt trotz mehrmaliger Wiederholung mit unterschiedlichen VLAN-ID's ohne jede Veränderung des Problems. Es ist selbstredend, genau das als Fehleruntersuchung zunächst zu machen. Immerhin ist die Konfiguration des funktionierenden GS1200-8 in dieser Hinsicht absolut identisch vorzunehmen wie bei dem problematischen GS1200-8HP - es ist ja dieselbe Modellfamilie mit derselben Weboberfläche!

Gleichfalls wurde der Switch bei diesen Gelegenheiten auch aus- und nach einer Weile wieder eingeschaltet, um einen sauberen Systemstart zu haben. Vergeblich!

Und genau deswegen bin ich über die Problemsituation so verwundert.

Lediglich einen Werksreset könnte ich noch durchführen. Aber würde das wirklich etwas bringen? Ist es denn denkbar, dass sich der GS1200-8HP irgendwie "verschluckt" haben könnte?

Viele Grüße
HansDampf06

PS: Ich habe leider keinen unbenutzten VLAN-Switch herumliegen. Sonst hätte ich darüber schon längst verifiziert, ob der GS1200-8HP die (alleinige) Ursache des Übels ist.
em-pie
em-pie 01.10.2024 um 13:48:40 Uhr
Goto Top
Moin,

Aber es gibt ganz offensichtlich keinen Rückverkehr.
Und das machst du woran fest?
Ich nehme an, dass du in der Sense auch die Firewall-Regeln korrekt gesetzt hast und die Sense auch NAT für die neuen VLANs mit macht!?
HansDampf06
HansDampf06 01.10.2024 aktualisiert um 16:11:33 Uhr
Goto Top
Zitat von @em-pie:
Aber es gibt ganz offensichtlich keinen Rückverkehr.
Und das machst du woran fest?
Ich nehme an, dass du in der Sense auch die Firewall-Regeln korrekt gesetzt hast und die Sense auch NAT für die neuen VLANs mit macht!?
Die Schnittstellen LAN und VL0301 (= eine der VLAN-Schnittstellen, gebunden an LAN) sind in einer Firewall-Gruppe registriert. Zu/in dieser Gruppe sind derzeit die relevanten Regeln eingetragen, so dass es keine Rolle spielt, ob der separate IP-Bereich entweder VL0301 oder - bei (vorheriger) Deaktivierung von VL0301 - dem LAN über eine virtuelle IP-Adresse (= dieselbe IP-Adresse die ansonsten VL0301 auf der OPNsense als Gateway für den IP-Bereich hätte) zugeordnet wird.

Kommt also beispielsweise eine DHCP-Anfrage von einem frisch angeschlossenem Gerät im Falle der Anbindung am LAN, so ist sehr schön im Live-Kino zusehen:
1. per UDP von 0.0.0.0:68 an 255.255.255.255:67 (auf LAN eingehend)
2. per UDP von Gateway-IP:67 an DHCP-Server-IP:67 (über DHCP-Relay)
3. ff. Gerät ackert mit der zutreffend zugewiesenen IP-Adresse
Bei nachfolgenden DNS-Anfragen folgt auf diese Anfragen entsprechender Verkehr zu externen IP-Adressen oder was auch immer. Auch wieder alles so, wie es sein soll. Im Browser des Geräts ist der Erfolg dieses Verkehrs sehr schön zu sehen, weil nämlich die angesteuerten Webseiten erwartungsgemäß geöffnet und dargestellt werden.

Jetzt das Ganze für DHCP-Anfragen bei Aktivierung von VL0301 auf der OPNsense und Zyxel-typischen Konfiguration (s.o. ergänzend @aqui) der VLAN-ID auf dem GS1200-8HP:
1. per UDP von 0.0.0.0:68 an 255.255.255.255:67 (auf VL0301 eingehend)
2. per UDP von Gateway-IP:67 an DHCP-Server-IP:67 (über DHCP-Relay)
Mehr passiert dann nicht mehr. Das Gerät bekommt keine IP-Adresse, obschon im Syslog-Live-Stream des DHCP-Servers zu sehen ist, dass er das zutreffende IP-Lease-Angebot via die Gateway-IP zum Gerät absendet.
Hat das Gerät eine feste IP-Adresse, dann gibt es zwar lauter DNS-Anfragen, aber nichts weiter an Verkehr. Im Browser wird nach einer Weile der vergeblichen Versuche mitgeteilt, dass die aufgerufene Seite nicht zu erreichen sei. Wie auch, wenn die Antworten der DNS-Server nicht ankommen? Und die DNS-Server antworten laut Syslog-Live-Stream prompt, wenngleich die Antwort eben nicht am Gerät ankommt. Würde die Antwort auf der OPNsense verworfen werden, müsste das im Live-Kino zu sehen sein. Fehlanzeige.

In beiden Varianten (VL0301 oder LAN) sind alle involvierten IP-Bereiche identisch - es wird nichts geändert! Alle Regeln sind dieselben und in ihrer Abfolge etc. sind sie ebenso absolut identisch. Der einzige Unterschied ist, dass es bei VL0301 über die zugehörige VLAN-ID und bei LAN über die VLAN-ID 1 läuft sowie der Switch entsprechend konfiguriert ist.

Und bitte noch einmal zur Kenntnis nehmen:
AM ANDEREN STANDORT ist die KONFIGURATION der OPNsense IDENTISCH und läuft auf Anhieb und seither störungsfrei. Der RELEVANTE UNTERSCHIED sind die nachgeschalteten Switche (funktionierend: 24er Switch + GS1200-8 <=> problematisch: GS1200-8HP (v1) solo).

Damit wage ich zu behaupten, dass Konfigurationsfehler auf der OPNsense guten Gewissens ausschließbar sein dürften. Wenn zudem sowohl auf dem funktionierenden GS1200-8 als auch auf problematischen GS1200-8HP die Konfiguration für VL0301 abermals identisch ist und es bei dem erstgenannten Switch klappt, aber beim zweiten nicht, obschon bei diesen Zyxel-Modellen nichts anderes konfigurierbar ist (s.o. Link von @aqui), dann dürfte auch hier ein Konfigurationsfehler eher fernliegend sein.

Viele Grüße
HansDampf06
NordicMike
NordicMike 01.10.2024 um 18:00:05 Uhr
Goto Top
Je mehr ich lese, desto mehr verwirrt es, Ich denke du solltest alles schematisch aufzeichnen und alle IP Adressen, Subnetz Masken, Gateways und Routen dazu schreiben, dann kommt man der Sache eher auf die Spur.
aqui
Lösung aqui 02.10.2024 aktualisiert um 10:58:07 Uhr
Goto Top
Ich habe leider keinen unbenutzten VLAN-Switch herumliegen.
Was du ohne Vergleichsswitch immer machen kannst zur sicheren Kontrolle ist einen Wireshark....
  • einmal direkt an das OPNsense Interface klemmen wo der der Zyxel dranhängt
  • und einmal direkt am Zyxel Uplink Port anschliessen der zur OPNsense geht.
Du generierst dann einmal an der OPNsense Traffic im Parent Interface (UNtagged) sofern genutzt und einmal im VLAN und siehst dir diesen Traffic im Wireshark an.
Analog machst du das am Zyxel Switch Uplink Port.
So kannst du wenigstens im Wireshark sehen ob beide Seiten den betreffenden Traffic entsprechend richtig mit einem .1q VLAN Tag taggen.
Hier am Beispiel mit einem VLAN ID 14 Tag:
vlansniff14
Das bei so einer grundlegenden Funktion wie VLANs ein managed Switch einen Fehler hat ist eher ungewöhnlich.
Als letzte Option solltest du immer einen Werksreset am Switch machen und erstmal einfach mit dem PVID und nur einem tagged VLAN anfangen. Switch VLAN Konfig Screenshot würde auch helfen.
HansDampf06
HansDampf06 07.10.2024 um 15:56:18 Uhr
Goto Top
Die Anregungen von @aqui habe ich im Laufe der letzten Woche mit folgenden Ergebnissen umgesetzt:

1.
Werksreset des GS1200-8HP: erwartungsgemäß wirkungslos

2.
Frei nach dem Motto "aus den Augen, aus dem Sinn" konnte ich doch noch einen derzeit unbenutzten GS1200-8 herauskramen. Jedenfalls diesen Switch für das fragliche VLAN konfiguriert - abermals wirkungslos. Damit sprach aber bereits alles dafür, dass gemäß der Anmerkung von @aqui der GS1200-8HP nicht die Ursache für das Problem sein konnte.

3.
Wireshark - und jetzt wurde es interessant.
Der GS1200-8HP (v1) unterstützt leider keinen Spiegelport, weshalb es etwas schwierig ist, dort mit Wireshark anzusetzen. Nicht so aber in Bezug auf OPNsense. Denn OPNsense läuft als VM und ist auf dem Host per Open VSwitch (= OVS) an die LAN-Schnittstellen angebunden. Mit Wireshark auf dem Host kann natürlich OVS an allen (virtuellen) Schnittstellen beobachtet werden.
Jedenfalls offenbarte ein permanent von einem anderen PC gesendeter Ping, dass der Ping als Request von der OPNsense über OVS und den GS1200-8HP bis zum Ziel lief und von dort als promptes Reply bis zur OPNsense zurückkam. Auch der Tag für das VLAN war jedes Mal ordnungsgemäß gesetzt. Das war die endgültige Bestätigung, dass der GS1200-8HP "unschuldig" ist.
Dennoch tat sich auf der OPNsense weiterhin nichts. Nach nährerer Inspektion der Pakete fiel mir irgendwann auf, dass die Reply-Pakete immer an die LAN-MAC der OPNsense gerichtet waren und bei allen OVS-Switch-Ports aufschlugen. Letzteres interpretierte ich dahin, dass OVS noch keine MAC-Port-Zuordnung getroffen hatte und deswegen automatisch an alle Ports ausliefert bzw. dass OVS für die getaggten VLAN-Pakete keine Weiterleitung weiß.
Eine dadurch animierte ergänzende Recherche im Internet zu OVS zeigte, dass bei der physischen LAN-Schnittstelle noch der Parameter trunks mit der VLAN-ID ergänzt werden musste. Hier hatte ich im Vorfeld der VLAN-Konfiguration bei zwei Fundstellen im Internet die Aussage gefunden, dass in einer solchen Konstellation mit OVS keine ergänzenden Angaben zum VLAN zu machen seien, weil OVS alles durchleiten würde - deshalb unterließ ich das. Das erweist sich aber als falsch, wenngleich natürlich OVS alles durchleitet. Das Durchleiten allein genügt halt nicht. Nach dem Setzen der VLAN-ID bei trunks funktionierte es endlich.

Erstaunlich ist, dass diesbezüglich am anderen Standort bei identischer Konfiguration das Problem nicht zu beobachten war. Das könnte darauf hindeuten, dass der GS1200-8HP (v1) in Bezug auf VLAN's nicht mehr auf der Höhe der Zeit ist oder dass der dortige 24er Switch eine fehlende trunks-Angabe bei OVS überspielen kann.

Beim Austesten der OVS-Konfiguration zeigte sich überdies, dass neben trunks der Parameter tag nicht gesetzt werden darf, sondern undefiniert bleiben muss. Andernfalls wird der Verkehr vom/zum LAN über OVS unterbunden. Insoweit genügt der Parameter "vlan-modus=native-untagged" vollauf und führt ja automatisch zur VLAN-ID-/Tag-Zuordnung (= 1).

Viele Grüße
HansDampf06
aqui
aqui 07.10.2024 um 16:31:56 Uhr
Goto Top
Glückwunsch zum bilderbuchmäßigen Troubleshooting und interessantem Feedback! 👏 👍

Bleibt zum Schluß nur noch die Frage auf welchen vSwitch bzw. Hypervisor sich das bezieht?!
Bei Proxmox oder VmWare ist dem glücklicherweise nicht so. Dort entscheidet der vSwitch welcher Tag einer VM mitgegeben wird. Bei VmWare könnte man über die VLAN ID 4095 auch alles Getaggte transparent "durchreichen".
Aus Sicherheitsgründen und der Gefahr nicht abschätzen zu können wie ein vSwitch mit Promiscous Traffic umgeht ist davon aber dringenst abzuraten. Das macht niemand so.

Zu den VLAN spezifischen Setups für Proxmox und VmWare gibt es ein paar Forenthreads.
Proxmox. Desweiteren hier.
VmWare
HansDampf06
HansDampf06 07.10.2024 um 17:17:37 Uhr
Goto Top
Zitat von @aqui:
Glückwunsch zum bilderbuchmäßigen Troubleshooting und interessantem Feedback! 👏 👍
Danke für das Lob!

Bleibt zum Schluß nur noch die Frage auf welchen vSwitch bzw. Hypervisor sich das bezieht?!
Debian 11 (Bullseye) mit KVM/QEMU und Open VSwitch aus dem offiziellen Repository. Bekanntlich bin ich kein Freund der Proxmox-Webshell. Wer Hyper-V mit Hyper-V-Manager kann, der kann auch KVM/QEMU mit dem Virtual Machine Manager und braucht keine bunte Shell oben drauf. Immerhin fußt Proxmox auf KVM/QEMU und unter anderem Open VSwitch. Dann kann ich das auch direkt administrieren, brauche keine drittabhängige Distribution (= Proxmox) und bleibe beim unverfälschten Debian - keep simple ...
(M)Ein weiterer Gedanke ist: Solche Konfigurationen macht man im Prinzip nur einmal und dann läuft das nahezu bis in alle Ewigkeit (= never touching ...). Administriere ich es selbst, dann muss ich mich damit beschäftigen und kenne das System auch wesentlich besser. Jedenfalls ergeben sich für mich Ansatzpunkte, auf die ich ansonsten nicht kommen würde. So auch durch das Wireshark ausgelöst: nach der Paket-Inspektion wusste ich, was ich mir genauer ansehen muss und konnte gezielt recherchieren.

Bei Proxmox oder VmWare ist dem glücklicherweise nicht so. Dort entscheidet der vSwitch welcher Tag einer VM mitgegeben wird. Bei VmWare könnte man über die VLAN ID 4095 auch alles Getaggte transparent "durchreichen".
Vielleicht war das auch bei den beiden Fundstellen (diese erinnere ich leider nicht mehr) so gemeint gewesen und ich hatte es nur missverstanden.

Aus Sicherheitsgründen und der Gefahr nicht abschätzen zu können wie ein vSwitch mit Promiscous Traffic umgeht ist davon aber dringenst abzuraten. Das macht niemand so.
In OPNsense ist die Option "Promiscous Mode" für eine VLAN-Schnittstelle vorhanden, aber im Erläuterungstext wird von einer Aktivierung abgeraten.

Zu den VLAN spezifischen Setups für Proxmox und VmWare gibt es ein paar Forenthreads.
Proxmox. Desweiteren hier.
VmWare

Was mir aufgrund des hiesigen Problems und der gefundenen Lösung durch den Kopf geht, ist die Frage, ob auch die vnet-Schnittstelle der OPNsense bei OVS nicht mit dem Parameter trunks ergänzt werden sollte, um die OVS-Konfiguration zu optimieren. Konsequent erschiene es.
Ein praktisches Problem ist aber, dass die Nummer des vnet-Namens mit jedem Herunterfahren und anschließendem Kaltstart der VM (=/= Neustarten) hochzählt. Dadurch lässt sich das wohl nicht persistent in die OVS-Konfiguration auf dem Host schreiben. Wahrscheinlich muss das in der Konfiguration der VM erfolgen. Hier weiß ich derzeit noch nicht, ob ich auf der Seite der VM-Konfiguration die LAN-Schnittstelle entsprechend mit Trunk-Angaben ergänzen kann. Das muss ich noch recherchieren. Wenn alle Stränge reißen, dann hilft im Zweifel auch ein Cronjob-Script auf dem Host.

Das ist aber nicht vordringlich, weil die VM's auf dem Host zusammen mit ihm starten und dann mit ihm die ganze Zeit durchlaufen. Etwaige Neustarts durch Updates sind kein Herunterfahren der VM, so dass die vnetX-Schnittstelle beibehalten wird. Vor einer persistenten Konfiguration kann man das ja bei OVS sehr schön mit Consolenbefehlen austesten und wieder entfernen.

Viele Grüße
HansDampf06
HansDampf06
Lösung HansDampf06 11.10.2024 aktualisiert um 13:34:26 Uhr
Goto Top
Auch wenn heute Freitag ist, aber ich komme nicht umhin, meinen Kommentar ein Stück weit zu revidieren.

Die dort beschriebene Lösung mit dem trunks-Parameter war nämlich eine trügerische Problembehebung, wie ich am Montagabend feststellen musste. Denn nun konnte sich plötzlich ein Gerät, dass keinem VLAN-Bereich zugeordnet ist, seine IP-Adresse nicht mehr per DHCP zuweisen lassen, wie das zuvor bei den VLAN-zugewiesenen Geräten scheiterte. Also habe ich das Problem am Dienstagvormittag intensiv untersucht, bis letztlich der einzig verbleibende Ansatz übrig war, den trunks-Parameter wieder zu löschen. Und siehe da, jetzt konnte sich das Geräte ohne VLAN-Zuweisung prompt seine IP-Adresse holen.

Somit stand ich vor einer Art Ping-Pong-Situation, die selbstredend unhaltbar und letztlich nicht auflösbar ist. Zugleich stand damit fest, dass der GS1200-8HP und OVS nicht miteinander wollen. Denn der 24er Switch (ein GS2210-24HP) am anderen Standort war jederzeit unauffällig, und zwar egal, ob der trunks-Parameter gesetzt wurde. Dort lief alles auf Anhieb.

Für das vollständige Verständnis der Problemlage ist wichtig zu wissen, wie OVS und KVM/QEMU (per libvirt) zusammenarbeiten. Die allgemeine Beschreibung von OVS und VM's mittels VLAN greift hier nicht, weil es für die libvirt-VM's keine festen Interfaces gibt - diese werden gelöscht beim Herunterfahren der VM (wie schon erwähnt)! Wichtig ist aber - jetzt weiß ich wieder, woher ich es habe: aus berufenem Munde - die dortige Anmerkung:
By default, all OVS ports are VLAN trunks, so eth0 will pass all VLANs
Und genau deshalb ist der trunks-Parameter auf dem Ethernet-Interface eigentlich überflüssig. Meine intensiven Untersuchungen haben gezeigt, dass das Problem auch dann nicht positiv behoben werden kann, wenn der trunks-Parameter mit einem tag=1 ergänzt wird. Dann ist sogar die gesamte Kommunikation gestört.

Das zwang mich in der Quintessenz, nach einem passenden Ersatz zu suchen - geizhals.de als erste Anlaufstelle lässt grüßen. face-smile Obschon ich diesbezüglich offen war, was der neue Switch sein könnte, ergab die Filterung der Aspiranten den Zyxel GS1920-8HPv2. Der erste Vorteil ist, dass er neben den acht Access-Ports zwei zusätzliche RJ-45-Ports, die mit SPF-Steckplätzen geteilt sind, hat und dass er dadurch den Uplink separiert, wodurch die beiden freiwerdenden Access-Ports für weitere Geräteanbindungen zur Verfügung stehen. Der wesentliche Vorteil für die Problemlösung besteht aber darin, dass er eine mit dem GS2210 quasi identische Firmware teilt. Dadurch muss ich mich nicht in ein neues Switch-OS einarbeiten und kann die am anderen Standort funktionierende Konfiguration im Wesentlichen 1:1 übertragen. Noch am Dienstag bestellt war der GS1920 dann gestern mittags eingetroffen. Und sofort nach der Konfiguration lief auch der zweite Standort ohne das bisherige Problem. Über die weiteren Vorteile, die sich aus den umfangreicheren und feingranulareren Konfigurationsmöglichkeiten ergeben, will ich gar nich erst sprechen.
(Am Mittwoch eskalierte sogar das Problem, weil allem Anschein nach zwischenzeitlich alle zuvor verteilten DHCP-Leases abgelaufen waren und nicht erneuert wurden und nun die Disharmonie von GS1200-8HP und OVS für jedwede DHCP-Anfrage erst richtig zum Vorschein trat. Bloß gut, dass ich am Vortag den neuen Switch bestellt hatte!)

Ganz im Gegenteil wurde ich noch positiv überrascht. Beim GS1200-8HP zeigte der eine AP nur eine gelbe LED, was eine limitierten Power-Modus signalisiert. Mit dem neuen Switch ist die LED grün - also "volles Kanonenrohr". Herz, was willst du mehr! Das ist vor allem deshalb überraschend, weil beide Switche 802.3at pro Port unterstützen (sollen). Scheinbar kann hier der GS1200-8HP das realiter nicht vollständig umsetzen. Immerhin wurde das LAN-Kabel nur von dem einen zum anderen Switch umgesteckt.

Schon im Vorfeld der Bestellung bei der Informationsauswertung war ich bei der Bedienungsanleitung für den neuen Switch auf eine Funktionalität aufmerksam geworden, die dort auf Seite 297 bezüglich des VLAN-Trunkings beschrieben wird. Ich war sofort an die obige OVS-Anmerkung erinnert und so wurde mir klar, dass die GS1200er Switchserie zwar eine gewisse 802.1Q-Konformität besitzt, aber eben nur mit einer sehr eingeschränkten Funktionalität. Demnach mögen die GS1200er Switch für einfache Anwendungsfälle und als pure Access-Switche geeignet sein. Aber bei anspruchsvolleren Szenarien, unter anderem ein Zusammenspiel mit einem VM-Host, auf dem OVS läuft und VLAN's zum Einsatz kommen, sind sie doch eher nur ein überfordertes "Consumer-Produkt".

ERGEBNIS: Der GS1200-8HP ist aufgrund seiner sehr eingeschränkten VLAN-Funktionalität doch der "Schuldige", weil er ein Zusammenspiel mit OVS nicht reißen kann. Die Problemlösung liegt einzig und allein darin, ihn wie geschehen gegen einen tauglichen Switch auszutauschen. Jetzt ist wirklich alles chic!

Anzumerken ist, dass ich ohne den zweiten Standort und die dortige auf Anhieb funktionierende Installation keine Vergleichssituation gehabt hätte und so wohl nicht so schnell auf den notwendigen Austausch des Switches gekommen wäre.

Viele Grüße
HansDampf06

PS1:
Bei der Gelegenheit der Problemuntersuchung hatte ich auch einmal den trunks-Parameter für das vnet-Interface der OPNsense gesetzt und auch wieder ganz schnell gelöscht - es funktioniert nicht.

PS2:
In Ergänzung zu dem oben erwähnten VLAN-HowTo: Persistente VLAN-Zuweisungen für libvirt-VM's werden entweder über eine Fake-Bridge oder über eine spezielle Netzwerkkonfiguration von libvirt realisiert. Letzteres wird dann interessant, wenn man eine VM-Schnittstelle gezielt mehreren VLAN's zuweisen möchte, wenn diese Zuweisung nicht wie bei der VLAN-Konfiguration der OPNsense auf der VM selbst erfolgt. Ich tendiere in meinem Szenario zu Ersterem und muss nur eruieren, wie ich das für den Systemstart des Hosts in die switch.conf einbauen kann, ohne ovs-vsctl benutzen zu müssen.
aqui
aqui 11.10.2024 um 17:35:21 Uhr
Goto Top
Denn nun konnte sich plötzlich ein Gerät, dass keinem VLAN-Bereich zugeordnet ist, seine IP-Adresse nicht mehr per DHCP zuweisen lassen
Bedeutet ja dann das das PVID VLAN entweder vom vSwitch oder vom Zyxel nicht übertragen wird. Den Zyxel wird man hier sicher ausschliessen können, denn das funktioniert mit dem fehlerfrei. Natürlich sofern man das richtig konfiguriert. Ist also zu vermuten das der vSwitch entweder kein PVID VLAN supportet oder sonstwas falsch macht.
Solche mehr als banale Funktionen einen 802.1q Tag an einem Ethernet Frame zu erkennen (oder eben auch keinen) kann jede billige Baumarkt VLAN Switch.
Proxmox basiert ja auch auf diesem Hypervisor und das rennt nachweislich fehlerlos hier mit einem GS1200. Wäre dann etwas unverständlich was das geheime Zusammenspiel mit OVS dann technisch bedeutet. Übrigens werkelt der GS1200 auch völlig problemlos mit einer auf Proxmox virtualisierten OPNsense und das auf einem NUC mit nur einem einzigen Ethernetport!
Geht ja letztlich nur um Tag erkennen oder nicht. Warum es mit der anderen Kiste dann klappt ist aber genauso mysteriös und wirft eher ein Schatten auf den vSwitch.
HansDampf06
HansDampf06 11.10.2024 aktualisiert um 23:08:07 Uhr
Goto Top
@aqui:
Dann müsste man einmal anschauen, wie Proxmox den OVS jungfräulich konfiguriert. Also konkret ohne jede VM und dann einmal OPNsense mit einem VLAN. Denn weil das Proxmox wohl im Hintergrund ohne Zutun des Admin/Nutzers machen dürfte, wird sich das eher niemand im Detail ansehen und dazu aus dem Stehgreif etwas sagen können.

Ich kann für meinen Teil ruhigen Gewissens behaupten, dass meine OVS-Konfiguration lege artis ist. In der switch.conf werden eine bond-Schnittstelle, die die beiden physischen LAN-Schnittstellen zusammenfasst, und eine host-Schnittstelle für den Host erstellt. Sodann wird die OVS-Bridge generiert und die beiden Schnittstellen hinzugefügt. Selbstredend wird wegen der bond-Schnittstelle keine Konfiguration der beiden LAN-Schnittstellen vorgenommen. Bezüglich VLAN wird bei der bond-Schnittstelle der Parameter "vlan-mode=native-untagged" gesetzt.

Mehr als all das dürfte nicht nötig sein. Denn vom GS1200-8HP kommt der PVID=1 untagged. Deshalb müsste es auf der OVS-Seite bei der bond-Schnittstelle eigentlich belanglos sein, ob dort ebenfalls der Parameter "tag=1" gesetzt ist oder nicht, weil die betreffenden Pakete untagged sind und deswegen keine VID-Kennung aufweisen.
Überdies hatte ich, wie beschrieben den tag-Parameter bei meinen Untersuchungen ausprobiert, was auch naheliegend war. Nur war dann die Kommunikation zwischen OVS und GS1200-8HP gestört. Das verstehe, wer will, weil ich auf OVS-Seite nichts anderes einstellen kann, als das was ich bereits beschrieben habe. Auch die OVS-Dokumentation gibt dazu nichts weiter her. Beim GS1200-8HP war am entsprechenden Port PVID=1 ein grünes und bei den zu trunkenden VLAN's jeweils ein orangenes Kästenchen gesetzt. Abermals ist nicht mehr als das möglich und es müsste eigentlich so funktionieren. Hat es aber nicht.

Die Konfiguration des GS2210-24HP und des neuen GS1920-8HPv2 entsprechen genauso an den Trunk-Ports den bunten Kästenchen des GS1200-8HP. Und es funktioniert. Das verstehe, wer will. Es bleibt für mich bei solch einfachen Konfigurationen nach so viel Probiererei aller Varianten nur ein Schluss: Derjenige, mit dem es nicht klappt, ist der "Übeltäter".

Letztlich kannst Du auch nur mutmaßen, wo ein (Konfigurations-)Fehler liegen könnte. Wenn aber alle Varianten durchgespielt sind und der Fehler fortbesteht oder noch schlimmer wird, dann wird es gewiss äußerst eng. Es bliebe also nur noch ein Vergleich mit dem, was Proxmox unter der Haube veranstaltet, um zu erkennen, wo der Hund begraben liegt. Vielleicht schaust Du mal unter die Haube und teilst es.

Viele Grüße
HansDampf06

PS: Was mir gestern noch durch den Kopf gegangen war: Bei der OPNsense mit dem GS2210-24HP ist der Switch mit vier gebondeten Leitungen über eine Intel-T4-LAN-Erweiterungskarte mit dem Host verbunden. Bei der anderen OPNsense mit dem bisherigen GS1200-8HP sind es zwei LAN-Ports des Mainboards. Vielleicht wirkt sich dieser Hardware-Unterschied aus, wenngleich der GS1920-8HPv2 daran keinen Anstoß nimmt.
aqui
aqui 12.10.2024, aktualisiert am 13.10.2024 um 14:59:35 Uhr
Goto Top
wie Proxmox den OVS jungfräulich konfiguriert.
Ich habe das bis dato nur im KlickiBunti GUI gesehen und da ist es ein einfacher Switch ohne VLAN Support. Getaggte Frames werden also geblockt.
In der Grundversion hängen damit dann Management und alle VMs in einer Layer 2 Domain.
Erst wenn man dem vSwitch aktiv im Setup sagt er soll VLANs verstehen behandelt er auch Tags korrekt. Dazu muss man den Haken "VLAN aware" setzen!
Dieser Thread zeigt das am vSwitch Setup.
Man müsste also mal ergründen wie das in einer CLI Konfig aussieht.

Bei deiner Bonding Schnittstelle ist die Frage wie die agiert?? Bonding ist ja recht vielfältig und der Netzwerker versteht da primär immer einen LACP LAG mit 802.3ad. Der GS1200 ist gar nicht LAG fähig weil er das Feature gar nicht supportet!
Das muss es bei Hypervisoren aber nicht immer sein, da es hier auch andere proprietäre, non lege artis Bonding Verfahren gibt. Besonders solche die auch bei ungemanagten Switches funktionieren.
Da wird es dann wieder spannend ob ein Switch mit sowas umgehen kann. Der GS1200 kann außer LAG (korrigiert, siehe unten!) kein Spanning Tree, ist also ungeschützt im Falle eines Loops zwischen zweien seiner Interfaces. Dann ist immer die Frage WIE verhalten die Server Bonding Interfaces sich? Forwarden die L2 Broad- und Multicasts oder tun sie das nicht? Kann es einen Loop geben oder nicht?
Ganz spannend wäre dann noch die Frage: Wie sieht es mit einem singulären Port aus ohne Bonding?? Da wären Loop Fehler die aus solchen Bonding Setups resultieren könnten per se ausgeschlossen.
Es könnte also primär etwas mit dem Bonding Verfahren zu tun haben und wie das mit einem so einfachen VLAN Switch interagiert.

bei der bond-Schnittstelle eigentlich belanglos sein, ob dort ebenfalls der Parameter "tag=1" gesetzt ist oder nicht
Richtig!
Das wäre sogar grundfalsch so einen Tag zu setzen wenn das gleiche VLAN auch PVID VLAN ist. Denn ein VLAN 1 oder generell ein VLAN kann bekanntlich niemals gleichzeitg Tagged und UNtagged sein an einem Port. Keinesfalls darf man ein PVID VLAN gleichzeitig taggen. Auf Switches verbieten das in der Regel schon die Kommando Parser.

Im Vergleich hierzu einmal ein ESXi Setup auch ohne Bonding. Hier ist der vSwitch immer Tagging fähig und man löst das da über Port Groups.
HansDampf06
HansDampf06 12.10.2024 um 16:21:15 Uhr
Goto Top
Klasse die ausführliche Antwort!

Bei der GS1200er Serie muss man aus meiner Sicht zwischen den Versionen 1 und 2 unterscheiden. Mein GS1200-8HP ist eine Version 1. Diese kann weder LAG noch Portspiegelung. Das kann laut Handbuch in jedem Fall die Version 2, also der GS1200-8HPv2. Meine beiden GS1200-8 haben zudem die Firmware, die der Version 2 entspricht, und die können das laut Webinterface; sie haben auch die aktuellste Firmwareversion. Die GS1200-8 können außerdem Loop-Prevention/-Detection, so dass ein GS1200-8HPv2 das wohl auch können dürfte.
Insoweit lässt sich konstatieren, dass es wahrscheinlich aufgrund des Firmwareunterschiedes auch Funktionsunterschiede gibt. Dann ist nicht ausschließbar, dass sich das im praktischen Einsatz bemerkbar machen kann. Aber dürfte das nicht bedeutsam sein (s.u.).

Dann habe ich noch einmal in meine Aufzeichnungen geschaut, als ich mir das erste Mal den Einsatz von Open VSwitch und später ergänzend die Konfiguration der OPNsense-Hosts erarbeitet habe. Ich notiere mir zu solchen Aufzeichnungen immer die Quellen, auf die ich mich für meine Konfiguration konkret gestützt habe. Später werden nötige Abwandlungen (z.B. Unterschiede bei Linux-Distributionen/-Versionen) oder Konfigurationsvarianten bei differierenden Einsatzfällen hinzugefügt. Auf diese Weise habe ich eine jederzeit rekapitulierbare Wissensbasis.
Eine der dabei notierten Webseiten ist von Proxmox selbst. Nach den Erläuterungen folgen Einsatzbeispiele. Das Example 3, welches dort ausdrücklich als Standardkonfiguration bezeichnet wird, wenn zwei LAN-Schnittstellen gebondet werden, ist hinsichtlich der Bridge und der bond-Schnittstelle genau meine Konfiguration auf der Host-CLI-Ebene. Demnach würde ich behaupten, dass ich mich hinsichtlich meiner Konfiguration genauso verhalte, wie die Proxmox-Macher das für geboten halten.

Und nehme ich dann noch die oben zitierte Anmerkung von Open VSwitch hinsichtlich der generellen Trunkfunktionalität zur der Sichtweise von Proxmox hinzu, so bestätigt das meine Konfiguration zusätzlich.

Das Einzige, was noch überlegenswert ist, sind bei Proxmox die generellen Bond-Erläuterungen sowie das Example 3 hinsichtlich der bond-options. Dort sind ein anderer bond_mode sowie die Angaben für die Verwendung von LACP gesetzt. Wenn die GS1200er Serie aber kein LACP kann, würde das wohl nicht funktionieren. Aber der GS2210 und der GS1920 können LACP, so dass ich einen Wechsel darauf durchaus einmal ausprobieren kann, weil ich dann auf beiden Seiten (Switch und OVS) das LACP aktivieren könnte.

Wie man sehen kann, gibt es laut Example 3 noch den vlan_mode=access. Aber diese Variante betrifft offenkundig eine OVS-Schnittstelle im Sinne eines Accessports. Eine bond-Schnittstelle ist aber kein solcher Accessport, so das ich diese Variante ebenfalls sachlich ausschließen würde und daher nicht ausprobiert habe.

Es könnte also primär etwas mit dem Bonding Verfahren zu tun haben und wie das mit einem so einfachen VLAN Switch interagiert.
Das wäre nach allem wohl das Einzige, was noch denkbar wäre. Fakt ist aber, dass der (aktuelle) GS1200-8 dieselben Probleme in meinem Setup hat wie der GS1200-8HP (v1). Denn egal, ob ich die beiden LAN-Kabel bei ihm an 3+4 oder 7+8 (die LAG-Ports; mit und ohne LAG aktiviert) anschließe oder zwei der anderen Ports verwende, verhält er sich wie der GS1200-8HP. Damit sind dann die physischen Testvarianten erschöpft. Zumal, wenn es mit dem GS1200-8 geklappt hätte, hätte ich ihn den GS1200-8 wahrscheinlich schlicht nur zwischen OVS und GS1200-8HP geschaltet.

Am Ende bliebe in der Tat für einen Vergleich mit Proxmox nur noch, im Falle eines Bonding von zwei LAN-Schnittstellen und der Verwendung von VLAN's auf die Host-CLI-Ebene zu gehen und dort zu schauen, was sich im Verzeichnis /etc/network/interfaces.d o.ä. befindet. Zudem müsste mittels ovs-vsctl die Konfiguration der Bridge und der Ports aufgelistet werden. Gegebenenfalls, wenn Proxmox auch libvirt verwendet, müsste die generelle Netzwerk-XML-Konfiguration inspiziert werden. Andere Stellzentren gibt es für OVS eigentlich nicht mehr, und zwar auch dann nicht, wenn Proxmox die OVS-Konfiguration zur Laufzeit per Script manipulieren sollte, weil mit ovs-vsclt die Laufzeitkonfiguration sichtbar gemacht wird.

Viele Grüße
HansDampf06

PS: Was die GS1200er Serie definitiv nicht kann, eine MAC-basierte VLAN-Zuordnung. Das könnte demnächst an diesem Standort noch relevant werden, so dass ohnehin ein Austausch unausweichlich werden würde. Der GS1920-8HP kann das natürlich. Aber der spielt eben in einer anderen Liga als die GS1200er Serie ...
aqui
aqui 13.10.2024 aktualisiert um 15:03:59 Uhr
Goto Top
Was die GS1200er Serie definitiv nicht kann, eine MAC-basierte VLAN-Zuordnung.
Das ist richtig und wäre bei der Preisrange in dem sich diese Hardware bewegt wohl sicher auch etwas zuviel verlangt. Obwohl ein einfacher 20€ Mikrotik Switch es dennoch dafür leistet. face-wink

Die hiesigen Tests verrichtete ein GS1200-5 der keinerlei Versionen kennt. Auf dem Typenschild ist diesbezüglich nichts aufgedruckt.
Der Switch arbeitet mit deaktivierter Port Isolation, deaktivierer Strom Control aber aktivierter Loop Protection. Letzteres ist sowas wie das "Spanning Tree des kleinen Mannes" bei dem der Switch auf selbst gesendete Loop Protection Frames achtet an seinen Ports. Empfängt er die blockt er den Port. IGMP Snooping ist aktiv.
gs1200

Auf OPNsense und Proxmox sind 3 VLANs aktiv wobei UNtagged Frames am Trunkport 5 im VLAN 1 landen.
gs1200vlan
Mit den Settings arbeitet zu mindestens dieser Switch der o.a Hardware in allen Testumgebungen absolut unauffällig.

Die Aussage von oben muss ich korrigieren: Natürlich supportet der GS1200 auch LACP LAGs. Der 5er Switch aber nur limitiert einen 2er LAG und nur auf den Ports 3 und 4. Ob der 8er da flexibler ist kann ich nicht sagen. Der LAG rennt getestet zu einer OPNsense, Cisco Catalyst 2960 und Ruckus ICX7150 völlig unauffällig. Proxmox kann ich in Ermangelung einer weiteren Ethernet Schnittstelle (NUC Server) nicht testen.
Die Kardinalsfrage ist also dann welches Bonding Verfahren? LACP LAG kein Problem aber alles andere was nicht Standard konform ist birgt ohne Loop Detection ein Risiko. Bzw. mit aktiver Loop Detection auch sollten die vom Bonding Device auf der anderen Seite (vSwitch) geforwardet werden und damit dann ein Port Blocking auslösen. Ggf. müsste an dann testweise mal die Loop Detection deaktivieren. LACP LAG bringt ein eigenes Verfahren mit.
gs1200lag
Zusätzlich supportet der GS1200 auch ein Port Mirroring.
HansDampf06
HansDampf06 13.10.2024 um 17:41:10 Uhr
Goto Top
Zitat von @aqui:
Die hiesigen Tests verrichtete ein GS1200-5 der keinerlei Versionen kennt. Auf dem Typenschild ist diesbezüglich nichts aufgedruckt.
So auch die beiden GS1200-8 (=/= 8HP) hier. Lediglich anhand der Web-GUI im Vergleich mit der Bedienungsanleitung des 8HPv2 sieht es nach demselben Firmwarestand aus. Das Web-GUI der hiesigen GS1200-8 sieht identisch mit der Abbildunmg von Deinem GS1200-5 aus.

Der Switch arbeitet mit deaktivierter Port Isolation, deaktivierer Strom Control aber aktivierter Loop Protection.
Dito.

Mit den Settings arbeitet zu mindestens dieser Switch der o.a Hardware in allen Testumgebungen absolut unauffällig.
Dito. Allerdings hätte ich das hier auch erwartet - war aber leider nicht.

Die Aussage von oben muss ich korrigieren: Natürlich supportet der GS1200 auch LACP LAGs. Der 5er Switch aber nur limitiert einen 2er LAG und nur auf den Ports 3 und 4.
Beim GS1200-8 kommen lediglich als zweite LAG-Variante die Ports 7 und 8 hinzu, so dass zwei LAG's zur gleichen Zeit möglich sind. Das funktioniert auch, weil ich das eine Zeit lang in einer früheren Netzwerkgestaltung so genutzt habe.

Ob der 8er da flexibler ist kann ich nicht sagen. Der LAG rennt getestet zu einer OPNsense, Cisco Catalyst 2960 und Ruckus ICX7150 völlig unauffällig. Proxmox kann ich in Ermangelung einer weiteren Ethernet Schnittstelle (NUC Server) nicht testen.
Ich bin mir sicher, dass bis auf die unterschiedliche Portanzahl kein wirklicher Unterschied zwischen dem 8er und 5er besteht.

Die Kardinalsfrage ist also dann welches Bonding Verfahren? ...
Mal sehen, ob ich kurzfristig dazu komme, das noch einmal auszuprobieren. Interessant wäre es in jedem Fall, weil es ja noch die von Proxmox benannte Beispielsvariante mit LACP bei einem Bond gibt. Auf diese Variante würde ich wohl wechseln müssen, wenn ich auch auf dem GS2210/GS1920 das LACP aktivieren möchte. Bisher ist auf den Switchen nur ein statisches LAG eingerichtet. Es bleibt also spannend.

Viele Grüße
HansDampf06
aqui
aqui 14.10.2024 um 15:16:11 Uhr
Goto Top
Bisher ist auf den Switchen nur ein statisches LAG eingerichtet.
Aber dann auch auf Basis von 802.3ad bei dem dann nur der LACP Teil fehlt, oder?
So gut wie alle Hersteller supporten keine weitere Option beim Bondig. Ausnahme vielleicht noch Cisco mit seinem älteren PaGP Protokoll was aber wie ggf. andere Verfahren immer proprietär sind und niemals mit anderen Geräten zusammenarbeit.
Es ist generell niemals eine gute Idee Link Aggregation mit statischen LAGs laufen zu lassen weil dann immer die Funktionskontrolle fehlt. Auch wenn der Switch so ein statisches Feature supportet. LACP ist da immer die bessere Wahl allein auch schon wegen der protokollinternen Loop Detection.
HansDampf06
HansDampf06 14.10.2024 aktualisiert um 17:01:08 Uhr
Goto Top
Zitat von @aqui:
Bisher ist auf den Switchen nur ein statisches LAG eingerichtet.
Aber dann auch auf Basis von 802.3ad bei dem dann nur der LACP Teil fehlt, oder?
Davon gehe ich aus, weil lediglich LACP nicht aktiviert war und im GS2210/GS1920 der Modus mit "static" angezeigt wurde.
Das ist aber seit gestern Abend Geschichte, weil angeregt durch unsere Diskussion und Deinen Input nunmehr die Bonds aller meiner Host-OVS auf LACP (siehe Example 2 bei Proxmox) umgestellt und spiegelbildlich auf den Switchen das LACP aktiviert wurden. Freilich hätte ich das beim GS2210 schon längst machen können - aber besser spät als nie! face-smile Der Modus wird jetzt mit "dynamic" angezeigt und in der MAC-Tabelle sind nicht mehr die Portnummern der LACP-/Bond-Mitglieder, sondern nur noch die Kurzbezeichnung des jeweiligen Verbunds zu sehen.

Ist übrigens interessant, in der Schnittstellenübersicht von Wireshark die Aktivitätsgrafen der Bond-Schnittstellen zu beobachten, wie sie sich durch die LACP-Aktivierung verändern.

So gut wie alle Hersteller supporten keine weitere Option beim Bondig. Ausnahme vielleicht noch Cisco mit seinem älteren PaGP Protokoll was aber wie ggf. andere Verfahren immer proprietär sind und niemals mit anderen Geräten zusammenarbeit.
Vor dem GS2210 waren nur die GS1200er im Einsatz, wenn auch beim GS1200-8 die beiden LAG's genutzt wurden. Jedoch vertrug sich das der Erinnerung nach nicht mit der LACP-Aktivierung beim OVS-Bond. Daher blieb es, wie im Example 3 bei Proxmox beschrieben, beim (statischen) bond_mode=balance-slb. Trotz der damit verbundenen Nachteile / Einschränkungen liefert ein solcher Bond eine Erhöhung der Verbindungleistung. An der MAC-Tabelle auf dem GS2210/GS1920 war nämlich eine Lastverteilung auf die Bond-Mitglieder gut sichtbar. Zudem war anhand der MAC-Adressen für mich ersichtlich, dass diese Verteilung ganz gut einer gleichmäßigen Auslastung des Bonds entsprach.

Es ist generell niemals eine gute Idee Link Aggregation mit statischen LAGs laufen zu lassen weil dann immer die Funktionskontrolle fehlt. Auch wenn der Switch so ein statisches Feature supportet. LACP ist da immer die bessere Wahl allein auch schon wegen der protokollinternen Loop Detection.
Die Loop-Detection/-Prevention war auf dem GS1200-8 natürlich aktiviert. Das erst recht, nachdem ich zu Hyper-V-Zeiten als Host bei der Netzwerkverkabelung einen Gedankenfehler gemacht hatte, mich über ein geleglich komisches Netzwerkverhalten wunderte und erst später diesen Gedankenfehler wirklich erkannt habe. Nach dessen Beseitigung war das komische Verhalten weg, wenngleich ich nicht mehr weiß, ob dieses Loop-Feature schon vor der Fehlererkennung aktiviert war oder nicht. In jedem Fall achte ich seitdem verstärkt auf die genaue Konfiguration und habe auch ein besseres Verständnis für die LAG- und Loop-Problematik entwickelt.

Denn - ich habe es zwar nicht mit Wireshark oder so geprüft - das komische Verhalten machte auf mich den Eindruck eines Broadcast-Sturms oder vergleichbarer Effekte der redundanten oder gar vervielfältigten Weiterleitung von Paketen. Damit im Hinterkopf ist mir dann irgendwann der Gedankenfehler bewusst und sichtbar geworden.

Im aktuellen Design mit dem GS2210/GS1920 ist dieser Fehler ohnehin nicht mehr möglich. Das war vor allem dem Umstand geschuldet, dass der GS1200-8HP später wegen der PoE-Nutzung hinzukam und dass sich die relevanten Leitungen aus objektiven Gründen über die beiden Switche und die LAN-Port-Gruppe der FortiGate verteilen mussten. Hier sollte dennoch der Hyper-V-Host mit seinen vier VM-Leitungen (Trunking auf dem virtuellen Switch des Hyper-V) bestmöglich angebunden werden, was dann zu dem Gedankenfehler führte.

Viele Grüße
HansDampf06
HansDampf06
HansDampf06 15.10.2024 um 00:09:08 Uhr
Goto Top
So, lieber @aqui, jetzt nähern wir uns des Rätzels Auflösung.

Die Konfiguration des OVS-Bonds gemäß Example 3 von Proxmox (bond_mode=balance-slb) in Verbindung mit den GS1200 war ja disfunktional, weil mit und auch ohne LAG-Konfiguration auf dem GS1200-8 die Datenverbindung zum Host nur bedingt noch eine DHCP-Lease-Vergabe zuließ.

Entsprechend Deiner Aussage spricht mit dem LAG-Menü der Web-GUI des GS1200-8 in der Tat etwas dafür, dass er echtes LACP und das gestützt auf MAC-src-dst können würde. Also habe ich den freien GS1200-8 noch einmal für das LAG 1 (Port 3 + 4) / 2 (Port 7 + 8) und zugleich für die VLAN's (orangene Kästen für getaggt) konfiguriert.

Weil jetzt ja das LACP auf dem OVS-Bond aktiviert ist, müsste also eine Kopplung erwartungsgemäß funktionieren. Zuerst hatte ich deshalb ein dauerhaftes Ping auf die OPNsense gestartet, um auf diese Weise das Fortbestehen der Verbindung zum Host unkompliziert mitverfolgen zu können.
Sodann wurde zunächst eine Leitung des Bonds vom Port 10 des GS1920 auf den Port 3 des GS1200-8 umgesteckt. Dem folgend wurde ein Kabel in Port 8 des GS1200-8 und in Port 10 des GS1920 eingesteckt. Noch laufen die Pings durch.
Dann die zweite Leitung von Port 9 des GS1920 auf Port 4 des GS1200-8 ungesteckt. Nun stand die LACP-Verbindung vollständig zwischen GS1200-8 und OVS-Host. Aber es ging kein Ping mehr durch. Daher das Kabel von Port 9 auf einen normalen Accessport des GS1920 umgesteckt. Weiterhin kein erfolgreiches Ping. Deswegen das Kabel von Port 8 auf Port 1 (= zuvor getaggt für die VLAN's konfiguriert) des GS1200-8 verlegt, damit GS1920 und GS1200-8 über eine einfache Anbindung mit einander reden können. Immer noch kein erfolgreiches Ping. Schließlich noch die beiden OVS-Bond-Leitungen nach Port 5 + 6 umgesteckt (also ohne LAG), was gleichfalls erfolglos blieb.
Das Zurückstecken der einen Bond-Leitung auf Port 9 des GS1920 zeigte sofort wieder erfolgreiche Pings.

Quintessenz dieser Verifikation:
Als auf dem ehemaligen Hyper-V-Host die Ports der dortigen Intel-T4-LAN-Karte als Team zusammengefasst waren, funktionierte die Kommunikation mit und ohne LAG-Einrichtung zu den GS1200er Switchen. Noch bevor der Wechsel von Hyper-V auf KVM/QEMU erfolgte, wurden die GS1200er vom GS2210 ersetzt, so dass hier nie das beschriebene Problem auftreten / beobachtet werden konnte. Die nachfolgende Einrichtung der VLAN's in der OPNsense und auf dem GS2210 lief von Anfang an problemfrei.
Die Hosthardware der OPNsensen für die beiden Standorte ist identisch. Lediglich am Standort mit dem ehemaligen Hyper-V-Host ist noch eine zusätzliche Intel-T4-LAN-Karte eingebaut worden, so dass dieser OPNsense-Host ebenso über vier Ports einer LAN-Karte per LAG, jetzt LACP, an den GS2210 angeschlossen ist.
Beim anderen, dem problematischen Standort reichen zwei der eingebauten Mainboard-LAN-Schnittstellen als Bond (bisher gemäß Example 3 von Proxmox) aus. Der GS1200-8HP, der selbst kein LAG kann, übernahm am zweiten Standort spiegelbildlich die äquivalente Aufgabe des GS2210. Solange es keine VLAN-Konfiguration gab, traten keine Probleme auf. Diese kamen mit den VLAN's, insbesondere seit diese VLAN's getaggt an die Access Points weitergereicht werden sollten. Beim probeweise angeschlossenen GS1200-8 sah das Problem gleich wie beim GS1200-8HP aus.

Meine Mutmaßung war ja, dass die GS1200er Switche nicht mit einem OVS-Bond wollen oder nicht können. Der heutige Test, bei dem der OVS-Bond bereits gemäß Example 2 von Proxmox auf LACP umgestellt war (seit gestern Abend), ließ wegen der LAG- und möglichen LACP-Fähigkeit die Hoffnung aufkeimen, der GS1200-8 würde dann brillieren. Dem war aber nicht so. Im Gegensatz dazu hat die LACP-Konfiguration auf dem GS1920 mehr als 24 Stunden mit dem OVS-Bond auf Anhieb harmoniert und kann auch anhand der Statusanzeige im Web-GUI des GS1920 nicht anders beurteilt werden.

Weil bereits beim bloßen Umstecken der Leitungen kein Ping mehr durchging, hatte ich davon abgesehen, auch noch den trunk-Parameter auszuprobieren. Denn mein Rechner war im Nicht-VLAN-Bereich bzw. untagged ans Netzwerk angeschlossen, so dass es für die Pings gar nicht auf die VLAN's ankam.

Hierdurch lässt sich konstatieren, dass die GS1200er Switche mit einem OVS-Bond - jedenfalls in meiner konkreten Situation - nicht wollen oder nicht können, zumindest dann nicht, wenn VLAN's mit ins Spiel kommen. Mehr als den GS1200-8 so einzurichten, wie auch Du ja das beschrieben hast, und die Kabel in die zutreffenden Ports zu stecken, ist nun einmal nicht möglich. Der GS2210 wie der GS1920 kommen hingegen sehr gut mit meiner Gestellung klar. Also sind die GS1200er Switche in einer Konstellation wie der meinigen nicht tauglich, um direkt an einen OVS-Bond des KVM/QEMU-Hosts der virtualisierten OPNsense angeschlossen zu werden.

Hierdurch war, ist und bleibt der bereits vollzogene Switchwechsel auf den GS1920 alternativlos.

Wenn ein GS1200-8 bei Anbindung an Proxmox und VLAN-Einrichtung in anderen Gestellungen unauffällig funktioniert, käme es letztlich auf einen Vergleich der Hardware-Konfiguration (z.B. ob mit oder ohne LAG / OVS-Bond) und der konkreten (Laufzeit-)OVS-Konfiguration an. Was macht Proxmox an dieser Stelle nun wirklich? Weicht das von meiner Gestellung ab? Nur hier, insbesondere bei einem Blick unter die Haube von Proxmox in den OVS-Niederungen, könnte noch ein Erkenntnisschlüssel liegen, wenngleich ich das mit Blick auf die Example 2 + 3 von Proxmox eher nicht erwarten würde.

Eine gute Nacht
HansDampf06
aqui
aqui 15.10.2024 aktualisiert um 11:48:16 Uhr
Goto Top
https://www.duden.de/rechtschreibung/Raetsel
Du hast vermutlich gerade an eine Butterbrezel gedacht beim Schreiben...?! 😉
Zurück zum Thema....
(bond_mode=balance-slb) in Verbindung mit den GS1200 war ja disfunktional
Normal ist das ein Mode der keinen spezifischen Bond auf der anderen Seite erfordert und auch mit ungemanagten Switches rennt. Sowas ist wegen der unklaren Forwarding Situation von Broad- und Multicast Frames immer etwas ein Vabanque Spiel. Die meisten Hypervisor Hersteller raten deshalb davon ab wie oben schon gesagt. Z.B.:
https://portal.nutanix.com/page/documents/solutions/details?targetId=BP- ...

Nun stand die LACP-Verbindung vollständig zwischen GS1200-8 und OVS-Host.
Woran hast du das genau gesehen?? Leider fehlt dem GS1200 eine Anzeige des LACP Status an dem man das im Gegensatz zu anderen Switches eindeutig sieht. Hier z.B. ein Ruckus ICX an den LAG Port 1 und 2
Port       [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
1/1/1           1        1   20001   Yes   L   Agg  Syn  Col  Dis  No   No   Ope
1/1/2           1        1   20001   Yes   L   Agg  Syn  Col  Dis  No   No   Ope
 Partner Info and PDU Statistics
Port          Partner         Partner     LACP      LACP
             System ID         Key     Rx Count  Tx Count
1/1/1    32768-000d.b95a.49ea      299        4         6
1/1/2    32768-000d.b95a.49ea      299        4         6 
"Ope" steht für "Operational" also aktiv und anhand der Partner System ID unten kannst du die Mac Adresse des Gegenüber sehen der erfolgreich beim LACP Aufbau negotiated wurde und damit dann das virtuelle Bond Interface aktiv ist. Die hochzählenden RX und TX Counter sind ein weiteres Indiz der korrekten Funktion.
Ob zumindestens die OPNsense ein LACP Status Output hat müsste ich mal checken.

Das Scheitern des Pings ist also sehr wahrscheinlich eher ein Indiz das der LACP LAG nicht oder nicht richtig zustande kommt.
Viele Switches sind so eingestellt das sie den LACP LAG bei Ausfall eines Memberlinks komplett deaktivieren und NICHT in einem sog. Degraded Mode laufen lassen, also nur mit einem Tel der Memberlinks. Das die primär der Signalisierung weil sonst ein Gros der Admins gar nicht merken würden ob der LAG sauber rennt oder nicht.
Hier ist also die Frage WIE sich der GS1200 bei einem Teilausfall der LAG Memberlinks verhält. Ich teste das nochmal an einem Catalysten und ICX genau.

Ein weiterer Knackpunkt ist hier die Konfiguration der Memberlinks. Bei besseren Switches wird, wie oben schon gesagt, ein virtuelles LAG Interface erzeugt in der Konfig wenn der LAG sauber konfiguriert wurde. Ein Tagging lässt sich dann sinnvollerweise ausschliesslich nur über das LAG Interface konfigurieren und niemals mehr einzeln über die Memberlinks.
Das macht auch absolut Sinn, denn ein einziger Konfig Mismatch der Memberlinks resultiert dann in einem Scheitern des LAGs. Verständlich, denn ein LAG erzwingt das deren Memberlinks absolut identisch konfiguriert sein müssen. VLAN 10 taggen auf einem und nicht auf dem anderen wäre fatal.
Genau das erreichen Hersteller über das virtuelle LAG Interface was man nach Erstellung nur noch konfigurieren kann und was dann wasserdicht dafür sorgt das die Konfig Einstellungen parallel auf alle Memberlinks übertragen werden.
Bei Switches die diese Option nicht haben wie der 1200 besteht also eine ganz besondere Sorgfalt beim Einrichten der Memberlinks in Bezug auf Tagging und PVID sonst droht immer ein Scheitern des LAG.

Ich kann es zwar nicht mit KVM/QEMU testen aber ich werde nochmal den Cisco Catalysten und ICX anschmeissen sowie eine OPNsense mit LAG Konfig und das mal im Wechselspiel mit dem hiesigen 1200-5 testen und einmal Teilausfälle simulieren.
Ist zwar nur ein rudimentärer Test aber mal sehen wie sich das auf einem LACP Bonding mit einem Debian (Raspberry) verhält.

Damoklesschwert ist wie gesagt das IGMP Snooping Verhalten und damit das Forwarding Verhalten der 1200er mit Broad- und Multicasts. Im nicht optimalen SLB Balancing ist das Snooping Verhalten essentiell. In dem Mode darf dann keinesfalls Snooping aktiviert sein und unknown Multicasts müsste auf Drop gesetzt sein.
Generell ist das bei solchen absoluten Billo Switches immer Rätselraten (ohne Bretzel!! face-wink ) weil schlicht und ergreifend sinnvolle Debugging Opotionen dort fehlen. Falsch war es also nicht diese letztlich zu ersetzen. face-wink
HansDampf06
HansDampf06 15.10.2024 aktualisiert um 13:44:17 Uhr
Goto Top
Zitat von @aqui:
https://www.duden.de/rechtschreibung/Raetsel
Du hast vermutlich gerade an eine Butterbrezel gedacht beim Schreiben...?! 😉
In der Tat hatte ich zu der Zeit Hunger und es war ja auch schon wieder ziemlich spät ... face-smile

(bond_mode=balance-slb) in Verbindung mit den GS1200 war ja disfunktional
Normal ist das ein Mode der keinen spezifischen Bond auf der anderen Seite erfordert und auch mit ungemanagten Switches rennt. Sowas ist wegen der unklaren Forwarding Situation von Broad- und Multicast Frames immer etwas ein Vabanque Spiel. Die meisten Hypervisor Hersteller raten deshalb davon ab wie oben schon gesagt. Z.B.:
https://portal.nutanix.com/page/documents/solutions/details?targetId=BP- ...
Dessen bin ich mir bewusst, weil das für diesen Modus ausdrücklich so beschrieben ist (siehe Bonding). Der bisher angeschlossene GS1200-8HP (v1) kann ja kein LAG und so bleibt nur dieser Modus, sollen zwei Leitungen gebündelt werden. Freilich mit allen damit verbundenen Nachteilen und Einschränkungen, wie ich ja bereits schrieb.
(Der Modus zielt unter anderem auch auf solche Fälle ab, bei denen die Bondleitungen nicht zum selben Ziel führen, z.B. unterschiedliche Switche. Aber das ist nicht der hiesige Anwendungsfall.)

Nun stand die LACP-Verbindung vollständig zwischen GS1200-8 und OVS-Host.
Woran hast du das genau gesehen?? Leider fehlt dem GS1200 eine Anzeige des LACP Status an dem man das im Gegensatz zu anderen Switches eindeutig sieht.
Gemeint war meinerseits, dass beide Leitungen des Bonds physisch in den Ports 3 und 4 des GS1200-8 steckten und die Port-LED's auf übliche Weise grün leuchteten und dadurch eine bereite Verbindung anzeigten. Hierdurch war die Verbindung zwischen dem GS1200-8 und OVS dem Grunde nach hergestellt = "die Verbindung stand". Das war also im weiteren Sinne gemeint (siehe sogleich) und nicht auf das LACP als solchem (= im engeren Sinne) bezogen.

Ob zumindestens die OPNsense ein LACP Status Output hat müsste ich mal checken.
Das müsste man eigentlich dann beim OVS checken, weil OVS ja ein virtueller Switch ist und die LACP-Verbindung mit dem einen Ende dort terminiert.

Das Scheitern des Pings ist also sehr wahrscheinlich eher ein Indiz das der LACP LAG nicht oder nicht richtig zustande kommt.
Genau! Nichts anderes wollte ich zum Ausdruck bringen. Die LACP-Verbindung "stand" zwar in physischer Hinsicht und war in dieser Hinsicht operabel. Aber eine Verbindung in dem Sinne, dass auch Pakete von dem einen Ende zum anderen Ende geschickt werden können und dort erfolgreich ankommen, scheiterte. Die logische Konsequenz ist die Erfolglosigkeit der Pings - in der Tat ist diese Erfolglosigkeit ein mehr als deutliches Indiz für das Scheitern der gewollten LACP-Verbindung im engeren Sinne.
Mangels weiterer Einstellmöglichkeiten, genügt aber schon diese Wahrnehmung / Feststellung, dass trotz physischer Verbindung die eigentliche LACP-/LAG-Verbindung nicht aufgebaut wird, weil hierdurch ein gemeinsamer Betrieb von OVS und GS1200-8 über ein LAG / LACP letztlich verneint werden muss.


Viele Switches sind so eingestellt das sie den LACP LAG bei Ausfall eines Memberlinks komplett deaktivieren und NICHT in einem sog. Degraded Mode laufen lassen, also nur mit einem Tel der Memberlinks. Das die primär der Signalisierung weil sonst ein Gros der Admins gar nicht merken würden ob der LAG sauber rennt oder nicht.
Da verhalten sich OVS und GS1920 ersichtlich anders. Denn während des Umsteckens der ersten Leitung vom GS1920 zum GS1200-8 lief der Dauerping unbeeindruckt weiter. Erst beim Umstecken der zweiten Leitung scheiterten die Pings. Das würde ich ja auch erwarten (wollen), weil ich in einem LAG - ob nun mit oder ohne LACP - eben auch eine Redundanz für den Fehlerfall einer Leitung erblicke.

Hier ist also die Frage WIE sich der GS1200 bei einem Teilausfall der LAG Memberlinks verhält. Ich teste das nochmal an einem Catalysten und ICX genau.
Meine Erfahrung zu Hyper-V-Zeiten war, dass der GS1200-8 bei einem LAG auch nur mit einer Leitung weiterläuft. Freilich war das damals kein LACP, sofern das MS-eigene Teaming von LAN-Schnittstellen nicht eine Art LACP sein sollte.

Ein weiterer Knackpunkt ist hier die Konfiguration der Memberlinks. Bei besseren Switches wird, wie oben schon gesagt, ein virtuelles LAG Interface erzeugt in der Konfig wenn der LAG sauber konfiguriert wurde. Ein Tagging lässt sich dann sinnvollerweise ausschliesslich nur über das LAG Interface konfigurieren und niemals mehr einzeln über die Memberlinks.
Das scheint bei dem GS1200-8 vereinfacht der Fall zu sein, weil nach der Aktivierung des LAG nur noch bei diesem LAG und nicht mehr bei seinen Ports (z.B. 3+4) die VLAN-Zugehörigkeit angezeigt und eingestellt werden kann. War wie bei mir zuvor die VLAN-Zugehörigkeit an den Ports konfiguriert, so übernimmt der GS1200-8 dies zum LAG. Möglicherweise ist das aber nur eine summierte Anzeige (z.B. OR-Verknüpfung).

Bei dem GS2210 / GS1920 ist das aber nicht der Fall. Die Portzugehörigkeit eines VLAN's und die eines LAG / LACP werden unabhängig voneinander konfiguriert. Das jeweilige LAG hat lediglich einen Gruppennamen. Also werde ich wohl damit leben müssen, dass ich die "nicht besseren" Switche habe. face-smile

Ich kann es zwar nicht mit KVM/QEMU testen aber ich werde nochmal den Cisco Catalysten und ICX anschmeissen sowie eine OPNsense mit LAG Konfig und das mal im Wechselspiel mit dem hiesigen 1200-5 testen und einmal Teilausfälle simulieren.
Ist zwar nur ein rudimentärer Test aber mal sehen wie sich das auf einem LACP Bonding mit einem Debian (Raspberry) verhält.
Mit einer OPNsense auf dem Blech kann das möglicherweise alles funktionieren, weil die OPNsense dann direkt an den Ports anliegt und wol kein OVS dazwischen ist. Entscheidender wäre daher ein Test mit OVS, dass ja im offiziellen Repository von Debian enthalten ist. Also auf dem Debian eine OVS-Bridge installieren, bei der wie bei mir das Linux seine Schnittstelle an der Bridge bekommt und die beiden LAN-Schnittstellen gebondet sind. Die verlinkte Anleitung von Proxmox könnte hier hilfreich für die Erstkonfiguration sein. Ergänzbar ist bestimmt auch eine Analyseanzeige für OVS - OVS kann hier sehr viel, wenngleich ich das bisher noch nicht genutzt habe und deswegen keine näheren Tipps geben kann.

Um es vereinfacht auszudrücken: OVS ist das virtuelle Pendant zu einem Hardware-Switch wie GS2210/GS1920 (oder besser). All das, was die können, kann OVS auch und wohl noch viel mehr.

Damoklesschwert ist wie gesagt das IGMP Snooping Verhalten und damit das Forwarding Verhalten der 1200er mit Broad- und Multicasts. Im nicht optimalen SLB Balancing ist das Snooping Verhalten essentiell. In dem Mode darf dann keinesfalls Snooping aktiviert sein und unknown Multicasts müsste auf Drop gesetzt sein.
Dieses Snooping war bei mir aktiviert, einschließlich dem Drop. Nicht, dass ...

In jedem Fall hat OVS diese IGMP-Fähigkeiten. Diese habe ich aber noch nicht aktiviert gehabt, weil die IGMP-Implementierung im Netzwerk eines der nächsten Projekte sein wird.

Generell ist das bei solchen absoluten Billo Switches immer Rätselraten (ohne Bretzel!! face-wink ) weil schlicht und ergreifend sinnvolle Debugging Opotionen dort fehlen. Falsch war es also nicht diese letztlich zu ersetzen. face-wink
Für die Aufgabe als kleine Access Switche, um mehrere Geräte unkompliziert ans Netzwerk anzuschließen, haben die GS1200-8 ganz gewiss ihre Daseinsberechtigung und können das sehr gut erfüllen (ein GS1200-8 ist ja dem GS2210 nachgeschaltet und funktioniert dabei tadellos). Aber in meinem Fall, wo es eher um eine Art Core Switch und um speziellere Anforderungen geht, sind sie schnell überfordert oder gar unzureichend.
Sicherlich sind der GS2210 und der GS1920 noch lange nicht das Ende der Fahnenstange nach oben hin. Aber meine derzeitigen Anforderungen können sie nach meinem Dafürhalten abbilden und erfüllen.

Viele Grüße
HansDampf06
HansDampf06
HansDampf06 15.10.2024 um 17:28:09 Uhr
Goto Top
@aqui:
In Deinem Link zum LACP-Bonding auf dem Raspberry Pi verwendest Du ja die Linux-interne Bridgelösung und nicht OVS. Es könnte durchaus bei dem von Dir avisierten Test sinnvoll sein, die Bridgekonfiguration einmal mit dieser internen Lösung und einmal mit OVS durchzuspielen. Dann könnten diese beiden Varianten miteinander verglichen werden.

Ich habe aktuell leider keinen freien RaspPi und keinen USB-LAN-Adapter, um es selbst einmal ausprobieren zu können.

Und dann noch eine Verständnisfrage:
LACP beinhaltet nach meinem Verständnis alle nötigen Mechanismen, um die aus dem Bonding resultierenden Loop-Probleme zu vermeiden / lösen. In meinem Fall beruht das Netzwerk auf einer Sternstruktur. Es gibt - abgesehen vom LAG / LACP - keine parallelen oder Querverbindungen in der Netzwerkstruktur.

Das Aktivieren von RSTP und / oder Loop Guard dürfte dann doch eigentlich entbehrlich sein, oder? Was würde für eine Aktivierung sprechen und was dagegen? Was wäre hier Best Practice?

Viele Grüße
HansDampf06
aqui
Lösung aqui 15.10.2024 aktualisiert um 18:25:45 Uhr
Goto Top
Tests beendet und die offenbaren leider nichts Gutes was die angebliche LAG Funktion der 1200er anbetrifft. face-sad
Um es gleich vorweg zu nehmen: Das scheint alles andere zu sein aber kein Standard konformes LACP LAg Verfahren auf Basis 802.3ad. Das muss irgendein proprietärer Mist sein der nur mit diesen Zyxel Modellen klappt.
Man konnte es schon gleich sehen wenn man die Ports 3 und 4 mit aktiver LAG Funktion auf die Testswitches gibt kommt schon gar kein LAG zustande.
=== LAG "LAG-2" ID 2 (dynamic Deployed) ===
LAG Configuration:
   Ports:         e 1/1/43 to 1/1/44
   Port Count:    2
   Primary Port:  1/1/43
   Trunk Type:    hash-based
   LACP Key:      20002
Deployment: HW Trunk ID 2
Port       Link    State   Dupl Speed Trunk Tag Pvid Pri MAC             Name
1/1/43     Up      Blocked Full 1G    2     No  1    0   748e.f8d7.f56a  LAG-Uplink
1/1/44     Up      Blocked Full 1G    2     No  1    0   748e.f8d7.f56a  LAG-Uplink

Port       [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
1/1/43          1        1   20002   Yes   L   Agg  Syn  No   No   No   No   Ina
1/1/44          1        1   20002   Yes   L   Agg  Syn  No   No   No   No   Ina 
"Ina" steht hier für Inaktive.
Beim Cisco zeigt ein show port-channel das der Port Channel Port ebenfalls gar nicht erst in den Status "UP" wechselt.
Der Cisco hat eine recht gute Debugging Option und sieht man sich das LACP Handshaking einmal an offenbart das nichts Gutes. face-sad
Oct 15 16:54:59.175: LACP :lacp_bugpak: Send LACP-PDU packet via Fa0/24
Oct 15 16:54:59.175: LACP : packet size: 124
Oct 15 16:54:59.175: LACP: pdu: subtype: 1, version: 1
Oct 15 16:54:59.175: LACP: Act: tlv:1, tlv-len:20, key:0x1, p-pri:0x8000, p:0x11B, p-state:0xD,
s-pri:0x8000, s-mac:0018.73b3.8880
Oct 15 16:54:59.175: LACP: Part: tlv:2, tlv-len:20, key:0x0, p-pri:0x8000, p:0x4, p-state:0x5,
s-pri:0x8000, s-mac:c854.4bfc.9822
Oct 15 16:54:59.175: LACP: col-tlv:3, col-tlv-len:16, col-max-d:0x8000
Oct 15 16:54:59.175: LACP: term-tlv:0 termr-tlv-len:0
Oct 15 16:54:59.175: LACP: lacp_write: LACP 124 bytes out Fa0/24
Oct 15 16:54:59.175:     lacp_ptx Fa0/24 - ptx: during state PERIODIC_TX, got event 2(long_timeout)
Oct 15 16:54:59.175: @@@ lacp_ptx Fa0/24 - ptx: PERIODIC_TX -> SLOW_PERIODIC
Oct 15 16:54:59.175: LACP: Fa0/24 lacp_action_ptx_slow_periodic entered
Oct 15 16:54:59.175: LACP: timer lacp_p_s(Fa0/24) started with interval 30000.
Oct 15 16:55:00.123: LACP: lacp_t(Fa0/24) timer stopped
Oct 15 16:55:00.123: LACP: lacp_t(Fa0/24) expired 
Der LACP Prozess timed aus und kommt nicht zum Ende. Das passiert auf beiden Memberports.
Zumindestens sendet er noch mit "s-mac:c854.4bfc.9822" seine Hardware Adresse aber das wars dann auch... Der Key ID Exchange für den Gruppenkey scheitert komplett. Was vermuten lässt das kein Standard Komnformes LACP hier verwendet wird.
Dies Fehlverhalten protokollieren Cisco und Ruckus auch noch mit:
Partner Info and PDU Statistics
Port          Partner         Partner     LACP      LACP
             System ID         Key     Rx Count  Tx Count
1/1/43   32768-c854.4bfc.9822        0       11        40
1/1/44   32768-c854.4bfc.9822        0        9        43
Diese erscheint auch in den sehr rudimentären Loop Prevention oder Detection Frames:
zyxeloop
die als simple all Net Broadcasts versendet werden sofern diese Funktion aktiv ist. "Realtek" ist dann auch schon ein deutlicher Hinweis was dort an internem Silizium werkelt.
Das das automatisch deaktiviert wird beim Setup der LAG Funktion lässt ebenso Böses erahnen das nämlich der LAG nicht Standard konform ist. face-sad
Die GS1200 Doku erwähnt das auch mit keinem Wort was das o.a. Verhalten indirekt bestätigt.
Beantwortet dann auch gleiche deine Frage zur embeddeten Loop Detection bei LACP LAGs mit einem klaren Ja. Das bringt der Standard von sich aus mit.

Damit erübrigte sich dann jeder weitere Testversuch mit LAGs auf der Maschine.
Ein Mikrotik der im Bonding noch etwas exotische Varianten supportet schafft es auch nicht mit diesen einen LAG zum Zyxel aufzubauen.
Zumindestens mit fremden Herstellern ist so ein Zyxel LAG also ein vollständiges NoGo!

Test mit der LAG Funktion auf der OPNsense selber liefen absolut fehlerlos.
opnlaginfo
Hier wieder das Switch Pendant:
=== LAG "LAG-1" ID 1 (dynamic Deployed) ===
LAG Configuration:
   Ports:         e 1/1/45 to 1/1/46
   Port Count:    2
   Primary Port:  1/1/45
   Trunk Type:    hash-based
   LACP Key:      20001
Deployment: HW Trunk ID 1
Port       Link    State   Dupl Speed Trunk Tag Pvid Pri MAC             Name
1/1/45     Up      Forward Full 1G    1     Yes 1    0   748e.f8d7.f56c  LAG-Uplink
1/1/46     Up      Forward Full 1G    1     Yes 1    0   748e.f8d7.f56c  LAG-Uplink

Port       [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
1/1/45          1        1   20001   Yes   L   Agg  Syn  Col  Dis  No   No   Ope
1/1/46          1        1   20001   Yes   L   Agg  Syn  Col  Dis  No   No   Ope


 Partner Info and PDU Statistics
Port          Partner         Partner     LACP      LACP
             System ID         Key     Rx Count  Tx Count
1/1/45   32768-000d.b95a.49ea      299       49        49
1/1/46   32768-000d.b95a.49ea      299       50        49 
Zieht man einen der Memberlinks wo die aktive Session drauf rennt dauert es ca. 2 Sekunden bis auf den anderen Member umgeleitet wird. Der LAG bricht also NICHT ab wenn einer der Member außer Betrieb ist.

Ein böses Detail kam aber bei der OPNsense noch zutage mit diesem LAG Test. Der neue Kea DHCP Server ist nicht in der Lage mit dem LAG als PVID und seinen VLANs darauf korrekt umzugehen. face-sad
Auf dem LAG Interface selber war kein DHCP möglich und von 3 tagged VLANs funktionierte nur eines.
Ein Umkonfigurieren auf den bewährten ISC DHCP versorge alle 4 VLANs über den Trunk sofort völlig problemlos mit IPs.
Der Kea macht wie am LAG, auch bei einigen Options derzeit (noch) keine gute Figur so das man Usern mit etwas anspruchsvolleren Netzwerk Settings derzeit vom Kea auf der OPNsense abraten kann. Ob der sich auf der pfSense auch so zickig an einem LAG verhält ist Thema eines weiteren Checks.

Zumindestens als Fazit kann man für die GS1200 mitnehmen das deren LAG Funktion nicht Standard konform und damit so gut wie unbrauchbar ist und eher massive Probleme beschert sollte man die aktivieren. Bestätigt mehr oder minder dann auch deine negativen Erfahrungen. Das sind Heimnetz Switches die definitiv nicht in eine komplexere Produktivumgebung gehören.
Das können andere Hersteller deutlich besser. Obwohl man aber auch fair sein muss das für einen knapp 20€ Switch so eine Funktion auch nicht erwartbar ist.
Auf der anderen Seite zeigt Mikrotik aber auch klar das man es mit 20€ auch fehlerfrei zum Laufen bekommt. Und noch vieles andere on Top mehr... face-wink
HansDampf06
HansDampf06 15.10.2024 um 20:01:10 Uhr
Goto Top
Wau und Danke für Deinen Test!

Dann hat sich im Ergebnis unserer umfangreichen Erörterungen und Deines Tests letztlich doch zur Gewissheit bestätigt, was der Auslöser für diese Fragerunde war: Ein GS1200er Switch ist nicht geeignet, wenn es um verlässliches LAG / LACP und das auch noch gepaart mit VLAN's geht.

Interessant ist Deine weitere Feststellung bei dieser Gelegenheit: Der Kea DHCP-Server ist - salopp ausgedrückt - noch nicht reif dafür, einen eingerichteten und unauffällig funktionierenden ISC DHCP-Server zu ersetzen, weil vorerst zumindest mit Problemen bei der Verwendung von VLAN's gerechnet werden muss. Mithin werde ich die Überlegung, die hier werkelnden ISC DHCP-Server durch den Kea DHCP-Server zu ersetzen vorerst in der Priorität weiter nach hinten stellen.

Also nochmals besten Dank für Deine aktive Mitwirkung!!! Deinen umfangreichen Test habe ich selbstverständlich ebenfalls als Lösungsbeitrag gekennzeichnet.

Viele Grüße
HansDampf06