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