
Ich experimentiere mit Linux-Bridges und VLAN-Filterung, habe aber ein paar Probleme.
Ich habe eine VM mit einem Trunk (markierte Frames), der auf ens19 ankommt. Ich möchte diesen Port mit einer Linux-Brücke verbinden und auf dieser Brücke „virtuelle“ Schnittstellen haben, die auf dem von mir benötigten VLAN markiert sind, mit einem vollständigen TCP/IP-Stack dahinter (dem des Hosts).
Für meine Experimente beschränke ich mich auf VLAN 3 und 5, aber die Idee ist, dass es einfach zu erweitern sein sollte. Der Einsatz wird nicht groß erscheinen, da es durch Subschnittstellen von ens19 ersetzt werden könnte. Aber später werde ich den ens19-Port mit einer Gretap-Schnittstelle verbinden, um mehrere VLANs in einem Tunnel zirkulieren zu lassen.
Ich habe Tests mit Dummy- und Tap-Schnittstellen durchgeführt, aber es scheint mir, dass es aufgrund der Natur dieser Schnittstellen nicht funktioniert. Ich habe mit einer br0.3-Subschnittstelle getestet, aber hier erhält mein Client die ARP-Antwort, aber der PING erhält nie eine ICMP-Antwort ...
ip link add name br0 type bridge vlan_filtering 1
ip link set dev br0 up
ip link add link br0 name br0.3 type vlan id 3
ip link set dev ens19 master br0
ip link set ens19 up
ip link set dev br0 up
ip link set dev br0.3 up
ip addr add 10.3.0.106/22 dev br0.3
Antwort1
Dumme Brücke
Mit der aktuellen Konfiguration wird kein Datenverkehr weitergeleitet: Alles wird von der VLAN-fähigen Brücke gefiltert, da diese standardmäßig VLAN 1 auf allen Ports und auf ihrer Bridge-Schnittstelle selbst verwendet. Wenn ein Frame mit der VLAN-ID 3 eintrifft oder gesendet wird, wird er gelöscht, da er nicht mit dem Filter übereinstimmt.
Um das aktuelle Experiment zum Laufen zu bringen, setzen Sie die Brücke einfach als „dumme“ Brücke zurück:
ip link set dev br0 type bridge vlan_filtering 0
Jetzt wird getaggter Verkehr auf ens19
(getaggt) auf ankommen br0
(wenn er nicht anderswohin weitergeleitet wird), wird untagged weiterverarbeitet br0.3
und erreicht denRoutenplanungStack (z. B. als Typ IPv4, ARP oder IPv6). Nicht getaggter Verkehr erreicht auch denRoutenplanungStapel durch br0
. Jeder andere VLAN-getaggte Datenverkehr wird verworfen, da es nichts gibt, das ihn beansprucht: derRoutenplanungDer Stack selbst versteht VLANs nicht.
Die Bridge leitet VLAN-markierte Frames weiter, ohne die Bedeutung der VLAN-IDs zu berücksichtigen. Dies kann zu Problemen führen, wenn dieselbe MAC-Adresse in mehreren VLANs verwendet wird. Dies kann die Handhabung der Weiterleitungsdatenbank auf der Bridge durcheinanderbringen oder dazu führen, dass auf weiteren Geräten Duplikate oder Schleifen auftreten usw.
Daher ist tatsächlich eine VLAN-fähige Brücke vorzuziehen.
VLAN-fähige Brücke
Wenn die Bridge eine neutrale Rolle spielen soll und das Ziel darin besteht, einfach neue Pro-VLAN-Ports zu erstellen und noch mehr,ändernVLANs auf Ports, ohne eine Schnittstelle löschen und neu erstellen zu müssen (wie es bei VLAN-Subschnittstellen erforderlich ist), dann ist eine VLAN-fähige Brücke tatsächlich nützlich. In dieser Konfiguration ist es zwar immer noch möglich, VLAN-Subschnittstellen auf zu verwenden br0
, aber dies kann vermieden werden. Man kann stattdessen einevethPaar für jedes solche VLAN: eines als Bridge-Port, eines als Schnittstelle zur Kommunikation mit dem Routing-Stack (das ist ein Anwendungsfall vonvethohne dass Netzwerk-Namespaces überhaupt beteiligt sind).
br0
selbst muss nicht für das Routing verwendet werden, außer vielleicht, wenn es als Management verwendet wird, wenn keine andere physische Schnittstelle (als ens19
) verfügbar ist. Unten beginnt das Setup mit der vollständigen Sperrung aller hinzugefügten Ports, einschließlich br0
sich selbst, indem auch gesetzt wird vlan_default_pvid 0
(anstatt für alles die Standard-Port-VLAN-ID 1 zu erhalten). Dies ermöglicht es auch, Bridge-Ports sofort UP zu setzen, ohne Lecks während der Konfiguration zu riskieren, da standardmäßig nichts passieren kann.
Die Konfiguration von VLANs auf der VLAN-fähigen Bridge erfolgt überbridge vlan
Befehl mit dem neuerenrtnetlink(7)
Kernel-API. Der veraltete brctl
Befehl kann dies nicht tun, da dieältere Kernel-API(oder /sys
) bietet hierfür nicht die erforderlichen Funktionen.
Der Fall des OP wird in aufeinanderfolgenden Schritten:
Erstellung und Trunk-Link
Der Bridge sollte eine eigene (und eindeutige) MAC-Adresse zugewiesen werden, damit sie nichterbt standardmäßig die niedrigste verfügbare MAC-Adresse auf Bridge-Ports, die sich im Laufe der Zeit ändern könnte: dievethDie folgende Methode kann dazu führen, dass die Bridge ihre MAC-Adresse im Laufe der Zeit ändert, wenn neue VLANs hinzugefügt werden. Dies ist bei dieser Methode kein wirkliches Problem, kann aber die VLAN-Subschnittstellenmethode beeinträchtigen, wenn sie gemeinsam verwendet wird, oder die
br0
Verwendung von beeinträchtigen, wenn selbst eine IP-Adresse vorhanden ist. Auf neueren systemd-basierten Systemen ist diesbereits erledigt vonsystemdunabhängig vom beteiligten Netzwerkmanager, auch wenn dieses Verhalten unerwünscht ist, wenn er eine neue virtuelle Ethernet-ähnliche Schnittstelle erkennt, die ohne Angabe ihrer MAC-Adresse erstellt wurde.ip link add name br0 address 12:34:56:78:9a:bc up type bridge vlan_filtering 1 vlan_default_pvid 0 ip link set dev ens19 up master br0
optional:
br0
weiterhin VLAN 1 (untagged) durchgeleitetens19
(tagged) verwenden, zum Beispiel für das Management:bridge vlan add vid 1 dev ens19 bridge vlan del vid 1 dev br0 self pvid untagged
Die Bridge-Schnittstelle selbst erfordert
self
bei der Konfiguration das zusätzliche Schlüsselwort.VLANs hinzufügen
ens19
(hier VLAN-IDs 3 und 5):bridge vlan add vid 3 dev ens19 bridge vlan add vid 5 dev ens19
Oder wenn ens19 berücksichtigt werden sollDieUplink-Trunk-Port, fügen Sie einfach alle anderen VLANs darauf hinzu:
bridge vlan add vid 2-4094 dev ens19
Verwenden Sie
-compressvlans
diese Option, um den Inhalt wieder anzuzeigen. Andernfalls werden 4093 Zeilen mit einzelnen Einträgen angezeigt.bridge -compressvlans vlan show dev ens19
Das gleiche Gesamtergebnis kann nun erreicht werden mit:
entweder eine darüberliegende VLAN-Subschnittstelle
br0
(hier wird VLAN-ID 3 verwendet)Wenn der Bridge-Schnittstelle (hier) oder dem Bridge-Port (nächster Punkt) die VLAN-ID nicht hinzugefügt wurde, wird kein derartiger Datenverkehr weitergeleitet, wenn die Bridge als VLAN-fähige Bridge eingerichtet ist.
Die VLAN-ID muss, weiterhin markiert, hinzugefügt werden zu
br0
:bridge vlan add vid 3 dev br0 self
Wie oben könnte alles nur einmal im Voraus hinzugefügt werden:
bridge vlan add vid 2-4094 dev br0 self
Dann wird die übliche VLAN-Subschnittstelle darüber hinzugefügt:
ip link add link br0 name br0.3 up type vlan id 3 ip addr add 10.3.0.106/22 dev br0.3
Das Ändern der mit der Schnittstelle verknüpften VLAN-ID (und in gängigen Setups mit dem IP-LAN 10.3.0.0/22) erfordert das Löschen der Subschnittstelle und das erneute Erstellen einer neuen mit einer anderen VLAN-ID: Die
type vlan
Schnittstelle kann nicht neu konfiguriert werden.oder ein PaarvethSchnittstellen (hier wird VLAN-ID 5 verwendet)
pvid untagged
spielt dieselbe Rolle wie die Verwendung einer VLAN-Subschnittstelle: Untags von der Brücke zum Port, Tags vom Port zur Brücke. Nur eine VLAN-ID kann die PVID sein (und hier ist es die einzige verwendete VLAN-ID).ip link add name vlan5 up type veth peer name br0vlan5 ip link set br0vlan5 up master br0 bridge vlan add vid 5 dev br0vlan5 pvid untagged ip addr add 10.3.4.106/22 dev vlan5
Außer dass die in den Beispielen gewählten Namen die VLAN-ID widerspiegeln und dies zu menschlicher Verwirrung führen würde, kann die zugehörige VLAN-ID (fast) im laufenden Betrieb geändert werden (hier wird sie von 5 auf 6 geändert):
bridge vlan del vid 5 dev br0vlan5 bridge vlan add vid 6 dev br0vlan5 pvid untagged
Und wenn Sie nicht bereits alle VLANs auf konfiguriert haben
ens19
, ändern Sie dies auch dort:bridge vlan del vid 5 dev ens19 bridge vlan add vid 6 dev ens19