OPNsense - VLAN will mit nachgeschaltetem Switch nicht funktionieren

@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.

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

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

Danke für das Lob!

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.

Vielleicht war das auch bei den beiden Fundstellen (diese erinnere ich leider nicht mehr) so gemeint gewesen und ich hatte es nur missverstanden.

In OPNsense ist die Option "Promiscous Mode" für eine VLAN-Schnittstelle vorhanden, aber im Erläuterungstext wird von einer Aktivierung abgeraten.


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

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:
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. 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:
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.

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.

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 ...

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.

Dito.

Dito. Allerdings hätte ich das hier auch erwartet - war aber leider nicht.

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.

Ich bin mir sicher, dass bis auf die unterschiedliche Portanzahl kein wirklicher Unterschied zwischen dem 8er und 5er besteht.

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

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! 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.

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.

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

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

In der Tat hatte ich zu der Zeit Hunger und es war ja auch schon wieder ziemlich spät ...

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.)

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.

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.

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.


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.

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.

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.

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.

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.

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

@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