VXLAN in der OPNsense verstehen

[Layer8]

Hallo zusammen,

ich versuche gerade VXLAN in der OPNsense zu verstehen. Die Doku hilft da aktuell leider nicht weiter, das Forum ist da auch noch nicht sonderlich hilfreich.

Punkt 1 (Tunneling von VLANs / QinQ)

VXLAN heißt, Layer2 über ein Layer 3 Netz tunneln zu können.  Die Tunnelendpunkte (TEPs) können Point to Point- (Unicast) oder Point to Multipoint-Verbindungen (Multicast) aufbauen.

Eine Tunnelendpunkt kann 16.777.215 VNIs (VXLAN Network Identifiers) unterscheiden. Jedes VNI bildet dabei ein eigenes Layer2-Netz. Und in jedes VNI können vollwertige Layer2 Frames gekapselt und an einen anderen TEP geschickt geschickt werden.

Daraus folgt:

Jedes VNI kann untagged Frames transportieren, aber auch genauso gut VLAN-getaggte Frames und auch QinQ-getaggte Frames. Theoretisch wären so 16.777.215 (VNI) * 4094 (Outer Q) * 4094 (Inner Q) unabhängige Layer 2-Netze mit nur einem VXLAN-Netzwerk tunnelbar.

Nun lassen aber viele Netzwerkgeräte nur zu, durch ein VNI ungetaggte Layer 2 Frames zu schicken. Bei solchen Geräten kann man dann immer nur ein VLAN je VNI übertragen. Es wird also bspw. auf Switch A VLAN 100 ungetagged in den TEP mit der VNI 100 geschickt. Auf Switch B kommt dann VNI 100 an und wird dort in ein VLAN ausgekapselt. Auf Switch B muss VNI 100 aber nicht zwingend auf VLAN 100 ausgekapselt werden, man kann es auch z.B. auf VLAN 111 auskapseln.

Der Nachteil dieses Vorgehens ist, dass man für jedes VLAN ein eigenes VNI konfigurieren muss. Der Aufwand dafür ist ggf. recht groß.

Manche Netzwerkgeräte lassen es aber auch zu, dass man VLAN oder QinQ getaggte Frames durch den VNI schicken kann. Somit braucht man nur noch ein VNI konfigurieren, über das man dann 4094 VLANs schicken kann oder eben bei Einsatz von QinQ 4094x4094 VLANs.

Ich hab noch nicht so richtig raus, was die OPNsense kann. Ist beides möglich? Wenn ja, wie? Wenn nein, was ist möglich?

Punkt 2 (untagged, VLAN oder QinQ-Interface an VXLAN binden)

Ein VXLAN-Interface mit einem VNI anzulegen scheint mir jetzt nicht so die Hürde zu sein. Das ist unter Interfaces - Other Types - VXLAN schnell gemacht. Das VXLAN-Interface ist nach der Erstellung verüfgbar um assigned zu werden.

Ich bin mir aber noch nicht sicher, wie ich nun ein Layer2-Netz an ein VNI binde. Verbinde ich ein untagged- / VLAN- / QinQ-Device per Bridging auf das VXLAN device oder wie geht man vor? Und muss man das VLAN/QinQ Device speziell konfigurieren, dass es Layer2-Taffic aufnimmt und an den Tunnel weiter reicht?

Punkt 3 (Standard?)

Hält sich das VXLAN in der OPNsense an RFC7348? Kann ich die OPNsense mit jedem VXLAN-fähigen Netzwerkgerät (Switch, Router, Hypervisor, Server) verbinden welches RFC7348-konform ist? Oder gibts hier irgendwelche Einschränkungen?


Vielen Dank für die Aufklärung.

[seed]

VXLAN ist Layer 2. Also der Traffic wird nicht geroutet sondern geswitched.
Um Traffic zu switchen brauchst du eine Bridge.

z.B.:
Bridge-VTEP1000

Interfaces in der Bridge: VTEP1000 interface, LAN Interface

Dann würde Traffic auf dem "LAN" Interface mit dem VTEP1000 gebridged werden. Als praktisch wie bei einem EoIP Tunnel getunnelt werden.


Wenn du QinQ machst, dann überträgst du das outer VLAN. Auf den Switches hinter den VXLAn Routern wird das dann wieder auseinander gefummelt.
outer VLAN: 100
innter VLAN: 200


Dann sollte es z.B. so aussehen:

Bridge-VTEP1001

Interfaces in der Bridge: VTEP1001 interface, VLAN100

[Layer8]

Danke für deine Erläuterung. Das Vorgehen leuchtet ein. Werde ich so erstmal zwischen zwei sensen ausprobieren und dann versuchen es an unsere Switche zu connecten.

Schlussfolgern lässt sich aus dem Vorgehen jedenfalls, dass man weder VLAN-TAGS noch QinQ-Tags in einen VTEP schicken kann, da die Bridge nicht in der Lage ist Tags zwischen den hinzugefügten Interfaces übertragen.

[seed]

Auch wenn du keine Arista Switche betreibst kann es dir Ggf helfen die Konfiguration mal anzusehen.
https://www.arista.com/en/um-eos/eos-vxlan-configuration

Dann kannst du das analog auf deine Situation übertragen. Die OPNsense kann ja "nur" VXLAN mit Multicast oder Unicast. EVPN über BGP kommt da nicht zum Einsatz.

In dem Konfigurationsbeispiel von Arista oben wird auch EVPN konfiguriert. Das kannste aber ignorieren.

Interessant ist der Teil:

switch(config)#interface vxlan 1
switch(config-if-Vx1)#vxlan vlan 100 vni 100

Also da wird das vxlan 100 mit dem vlan 100 gebridged.

Solange die VNI identisch ist kann auf den beiden VXLAN Tunnel Endpoints auch das VLAN unterschiedlich sein.
Der VLAN Tag wird ja nicht übertragen.
Auf der einen Seite kanns ja VLAN 100 und auf der anderen Seite VLAN 200 sein. Solange die VNI identisch ist ists für VXLAN eine Broadcast-Domäne.

Wenn du Q-in-Q überträgst, dann ist es für den VXLAN Tunnel ja irrelevant welche inner VLANs du überträgst.
Das wird auf der anderen Seite ja einfach wieder rausgeworfen (also von dem VLAN Interface der OPNsense zu dem Switch).

Du kannst durch ein VXLAN ja auch Wireguard übertragen und in dem Wireguard EoIP. Das ist für VXLAN nicht interessant.

[Layer8]

Wir haben aktuell Dell Switche die mit Dell OS10 (wären auch Open-Network-fähig). Dafür gibt es auch brauchbare Konfigbeispiele in der Doku. EVPN / BGP nutzen wir aktuell aber auch nicht, da das Netz zu klein ist und der Aufwand sich auf absehbare Zeit nicht lohnt. Das Underlay-Network ist erstmal ohne dynamisches Routing und Layer 2.

Der ursprüngliche Gedanke war, dass wir zwischen unserem Edge-Router vom Datacenter und den Access-Switches einfach nur ein Transfernetz bauen, in das wir die VXLAN-Tunnel zu den Switches anlegen und dann nur auf den Access-Switches dort wo benötigt die einzelnen VNIs auf die VLANs auskapseln. Das hätte dieses lästige VLAN-Management durchs Netzwerk weitgehend eingedampft.


Was ich nicht ganz nachvollziehen kann ist, dass die meisten Implementierungen von VXLAN es nicht zulassen, Frames mit EtherTyper 802.1Q oder 802.1AD zu übertragen, obwohl VXLAN das ja hergeben würde. Das würde den Aufwand der Konfiguration deutlich verringern. Man könnte dann viele VLANs in ein VNI packen. So muss man für jedes VLAN ein eigenes VNI erstellen.

[seed]

Wenn du Q-in-Q über VXLAN betreibst dann wäres interessant zu sehen ob es da reicht einfach nur den outer VLAN Tag zu übertragen. So das die inner VLANs "Payload" sind.

Der Port der dann auf der OPNsense in der VXLAN Bridge ist müsste dann ja das outer VLAN tagged zu dem Switch hinter der opnsene übertragen. Also gehen die inner VLANs durch den VXLAN Tunnel. Der Switch hinter der OPNsense sieht dann nur das tagged outer VLAN (vom VLAN Port der OPNsense) und die inner VLANs

Du kannst das ja mal testen und berichten.

[Layer8]

Ich hab ein Testsetup zwischen zwei sensen aufgebaut um VXLAN testen zu können, bekomme aber die Bridge nicht ans laufen. Kann mir bitte jemand auf die Sprünge helfen?

Der VXLAN-Tunnel (Eigenes Transfernetz über VLAN 911 mit MTU 9000) scheint zu stehen. Wenn ich jedem VXLAN-Interface auf den beiden sensen ne eigene IP gebe können sie sich gegenseitig pingen. Sogar DHCP funktioniert über VXLAN.

Auf Sense 1 hab ich dann eine Bridge angelegt. Member sind das VXLAN Interface und ein VLAN-Interface in VLAN 2020.
Auf Sense 2 hab ich auch eine Bridge angelegt. Member sind wieder das VLAN Interface und ein VLAN-Interface in VLAN 2021.

Ich hab auf den VXLAN-Interfaces dann IPv4 deaktiviert. VLAN 2020 und 2021 sowie die Bridge haben auch keine IP.

In den Tunerables hab ich Filterung auf der Bridge und auf den Members deaktiviert. Trotzdem haben alle  beteiligten Interfaces allow all rules bekommen.

Anmerkung: In den meisten Tutorials steht, dass man Filterung für die Bridge aktivieren soll und auf Bridgemembers deaktivieren. Ich brauch in dem Fall aber weder auf der Bridge noch auf dem Bridgemember Filterung, weil keines davon ne IP bekommen soll.

Nun hab ich einen Win10 Testclient an VLAN 2020 (11.11.20.20/24) und einen anderen an VLAN 2021 (11.11.20.21/24) mit festen IPs angehängt. Die Clients können sich jedoch nicht pingen.

Jemand ne Idee?

Was ich bereits probiert habe:
- Wenn ich die Clients beide in VLAN 2020 oder 2021 hänge, können sie sich pingen (kein Client-FW Problem oder so)
- Wenn ich dem Interface 2020 oder 2021 auf den Sensen eine IP im 11.11.20.0/24er Netz gebe, kann ich diese IPs vom Client aus pingen (somit kein Problem vom VLAN-Interface)
- Wenn ich dann die IP auf die Bridge umziehe, kann ich die IP nicht mehr von den Clients aus pingen (somit ein Bridgingproblem?)
- Wenn ich dann die IP nochmals auf das VXLAN-Interface umziehe, kann ich die IP vom client aus pingen, weil ist ja auch direct attached
- Wenn ich von Sense 1 die IP vom VXLAN-Interface pinge, geht das (siehe auch oben)
- Wenn ich von Sense 1 die IP von der Bridge in Sense 2 pinge, geht das wiederum nicht (somit ein Bridgingproblem?)

Überlegung:

Müsste es nicht möglich sein, dasss wenn jeder Client, jedes VLAN-Interface, jedes VXLAN-Interface und jede Bridge ne statische IP bekommt, dass sich dann alle IPs gegenseitig pingen können müssten?


Edit: Grafisch sieht das dann etwa so aus:

Client 1 mit fixer IP 11.11.20.20 <->VLAN 2020

<-> if_vlan2020 <-> Bridge0 <-> if_vxlan <-> if_vlan911 <->  #Sense1

VLAN 911                                                                                #Transfernetz für VXLAN TEPs

<-> if_vlan911 <-> if_vxlan <-> Birdge0 <-> if_vlan2021 <->  #Sense 2

VLAN 2021 <-> Client 2 mit fixer IP 11.11.20.21

[stefan00]

@Layer8: Hast Du diese Konstellation hinbekommen? Ähnliches Vorhaben hier

Leider gibt es wohl noch immer recht wenige Quellen zu vxlan auf FreeBSD.

Was mir gestern z.B. nach ewigem Debuggen auffiel:

die MAC-Adressen auf Bridges / vxlan interfaces sind beim Einsatz von zwei Sensen per default gleich. Autsch. Händisch MACs eingetragen und die pings liefen in alle Richtungen durch.

Ein Dump hat's gezeigt - "Duplikate" mit der gleichen MAC Adresse im vxlan forwarding table jeweils auf der anderen Seite. Kann nix werden. Diagnose auf beiden Sensen:

Code: [Select]

root@DEC750:~ # sysctl net.link.vxlan.XXX.ftable.dump
Nach der Eintragung der MAC-Adressen ist auch der ARP-table auf beiden Seiten korrekt.

Übrigens: Hilfreiche Tipps zum Debuggen von vxlan gibt es im letzten Kapitel von https://blog.grem.de/ayvn.pdf

(wirst Du vermutlich aber schon gelesen haben - eine der sehr wenigen Quellen)

Viele Grüße,
Stefan

[Layer8]

Hey,

nein, sorry, habs dann aufgegegen und nicht weiter verfolgt.

Danke für den Link. Die PDF war mir neu.

Bin aber auch davon abgekommen, reines VXLAN zu nutzen. Sind auf EVPN-VXLAN (Overlaytechnologie) umgeschwenkt. Damit entfällt das manuelle konfigurieren der VXLAN-Tunnel. Wird zwar von FRR unterstützt, aber ist nicht in FRR mit FreeBSD implementiert und demnach auch nicht in OPNsense verfügbar. Leider.