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/contentid/668514

Printed on: October 15, 2024 at 07:10 o'clock

aqui
aqui Oct 01, 2024 updated at 11:25:08 (UTC)
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 Oct 01, 2024 updated at 11:47:30 (UTC)
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 Oct 01, 2024 at 11:48:40 (UTC)
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 Oct 01, 2024 updated at 14:11:33 (UTC)
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 Oct 01, 2024 at 16:00:05 (UTC)
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
Solution aqui Oct 02, 2024 updated at 08:58:07 (UTC)
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 Oct 07, 2024 at 13:56:18 (UTC)
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 Oct 07, 2024 at 14:31:56 (UTC)
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 Oct 07, 2024 at 15:17:37 (UTC)
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
Solution HansDampf06 Oct 11, 2024 updated at 11:34:26 (UTC)
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 Oct 11, 2024 at 15:35:21 (UTC)
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 Oct 11, 2024 updated at 21:08:07 (UTC)
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 Oct 12, 2024, updated at Oct 13, 2024 at 12:59:35 (UTC)
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 Oct 12, 2024 at 14:21:15 (UTC)
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 Oct 13, 2024 updated at 13:03:59 (UTC)
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 Oct 13, 2024 at 15:41:10 (UTC)
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 Oct 14, 2024 at 13:16:11 (UTC)
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 Oct 14, 2024 updated at 15:01:08 (UTC)
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 Oct 14, 2024 at 22:09:08 (UTC)
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