OPNsense Forum
International Forums => German - Deutsch => Topic started by: Layer8 on March 02, 2022, 08:45:53 pm
-
Moin,
die pfsense scheint QinQ zu beherrschen: https://docs.netgate.com/pfsense/en/latest/interfaces/qinq.html
Die OPNsense scheinbar leider nicht. Zumindest kann ich, wenn ich ein neues VLAN-Interface anlegen will, kein VLAN-Interface als Parent-Interface auswählen.
Ist das eine Frage der OS-Basis oder eine Frage des OPNsense codes?
Und, falls das jemand weiß:
Einige Switche können QinQ nativ. Das heißt, sie supporten 802.1ad und können den äußeren VLAN-Tag entfernen und dann den inneren VLAN-Tag nutzen um den Frame tagged oder untagged auf einen Port zu legen.
Wenn ich mir so den Aufbau von 802.1ad bei Wikipedia (https://en.wikipedia.org/wiki/IEEE_802.1ad) angucke, dann würde ich vermuten, dass möglicherweise der ein oder andere "dumme unmanaged Switch" in der Lage sein sollte, QinQ weiterzuleiten, schließlich brauchen diese Switche nur Ziel und Quell-Mac und kümmern sich nicht drum, was zwischen Source-Mac und CRC steht. Oder prüfen solche Switche den Ethertype ? Hat da jemand Erfahrung? Oder Erfahrung damit, was einfach getaggte 802.1Q-Frames über "dumme" Switche schicken angeht? Sollte ja dann übertragbar sein auf QinQ-Frames. Dass die MTU dann beim Absender ggf. um entsprechende Bytes kleiner sein muss, ist klar.
Wie siehts miit managed switches aus, die kein QinQ können? Können die es durchreichen? Vermute mal nicht, weil die sich wahrscheinlich für den Ethertype interessieren, aber sicher bin ich mir da nicht. Hat da jemand Erfahrung?
-
Seit heute in der Entwicklungsversion:
https://github.com/opnsense/core/commit/99aacf7326
Man muss dazu sagen dass wir auch mal QinQ hatten so wie es pfSense hat, aber diese Implementation basierte auf Netgraph und war zu komplex und fehleranfällig respektive kaputt nach einem OS Update.
https://github.com/opnsense/core/commit/92a8e402b106
Die neue Variante in FreeBSD 13 beschränkt sich auf die Verwendung von bestehenden VLAN-Mechanismen. Im Patch sieht man wie viel "Aufwand" QinQ dann noch ist im Vergleich zu vorher.
Aktuell soll das so in 22.1.4 kommen wenn die Tests gut laufen.
Grüsse
Franco
-
Was für ein Zufall!
Danke für das Feedback und die Erklärung zur Historie. Ja, sieht nach weniger Code aus.
Falls jemand zu den restlichen Fragen noch Informationen hat, wäre ich dankbar.
Edit: Und danke auch für die unermüdliche Arbeit an OPNsense. :-)
-
Ich kann dir auf die Frage was ein „dummer unmanaged Switch“ macht zwar eine Antwort geben, diese wird dich aber nicht weiter bringen:
Es kommt darauf an/ alles ist möglich.
Bei meiner Arbeit habe ich schon alles erlebt:
- Dem Switch war das VLAN-TAG egal und er hat das Paket einfach weiter geleitet
- Der Switch hat Pakete mit VLAN-TAG einfach verworfen
- Der Switch hat das VLA-TAG entfernt
Mit freundlichen Grüßen
Roland
-
Ich hab zum Thema QinQ noch eine Frage.
Der übliche VLAN-Tag (802.1Q) bzw. der innere Tag vom QinQ wird ja mit EtherType/Tag Protocol Identifier(TPID) 0x8100 markiert . Der äußere Tag von 802.1AD wird gemäß Standard mit EtherType 0x88A8 markiert.
Ist es möglich, den äußeren Ethertype von einem QinQ-Device zu modifizieren? Sagen wir, auch auf EtherType 0x8100?
Grund:
Es gibt Switche, die können zwar QinQ, aber machen das nicht unbedingt sauber. Die nutzen sowohl für den äußeren als auch den inneren Ethertype immer die 0x8100.
Und es gibt Switche, die können mit Ethertype 0x88A8 nix anfangen, weil sie nur 0x8100 (802.1Q) können. Solche Switche könnte man trotzdem unter bestimmten Umständen für QinQ missbrauchen. Würde die Sense ebenfalls "unsauberes" QinQ beherrschen und outer und inner Tag mit Ethertype 0x8100 versehen, dann würde so ein Switch den äußeren Tag als VLAN-Tag und den inneren Tag als Payload betrachten. Der Payload würde dann aus am letzten Switch vor dem Accessswitch aus einem ungetaggten Port ausgeleitet werden. Der Accesswitch würde dann einfach auf Tagging eingestellt sein den Payload dem entsprechenden VLAN zuweisen. Ist zwar dirty, aber müsste gehen.
Und dann gibts Switche da kann man den TPID sogar ändern oder zusätzliche TPIDs hinzufügen/definieren.
-
Ich muss den vorherigen Post nochmal etwas ergänzen / klarstellen, was Switche mit "unsauberer QinQ-Implementierung" angeht:
Bevor es 802.1AD gab, welches den Ethertype auf 0x88A8 festgelegt hat, gab es einen inoffiziellen Vorläufer, der auch 801.1QinQ genannt wurde. Dieser Vorläufer nutzte meist 0x9100 als EtherType.
Wenn also in Switchdokus von 802.1QinQ die Rede ist, dann ist möglicherweise gemeint, dass der Switch QinQ mit Ethertype 0x9100 beherrscht.
Es gibt nach wie vor aktuelle Switche, die diese Altlast mit sich rumtragen und nicht jedes Switch-OS lässt zu, den Ethertype von 0x9100 auf z.B. 0x88A8 zu ändern.
Welchen Ethertype nutzt OPNsense standardmäßig für QinQ (würde mal 0x8848 vermuten)?
Wenn ich das richtig sehe, sollte FreeBSD nicht nur 0x88A8 sondern auch 0x9100, 0x9200 und 0x9300 unterstützen.
https://reviews.freebsd.org/D21846
-
Soweit ich sehen kann nutzt FreeBSD nur 0x88A8 und die anderen Werte für QinQ werden schlicht ignoriert.
Grüsse
Franco
-
Ja, danke. Das wurde mir jetzt auch schon im FreeBSD-Forum bestätigt.
Wo kann man bei den FreeBSD-Entwicklern Feature-Requests einkippen?
Es wäre cool, wenn FreeBSD den EtherType 0x88A8, 0x9100, 0x9200, 0x9300 für QinQ nutzen würde. Oder wenn man den EtherType je Interface einstellbar machen könnte.
-
https://bugs.freebsd.org/bugzilla/ aber eher wenig Hoffnung, dass dies auch aufgegriffen wird.
Grüsse
Franco
-
Habs mal reported.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264014
-
Bin im CC, danke :)
Grüsse
Franco