Linux/Netzwerk/Virtuelle Schnittstelle: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
K Textersetzung - „Man-Pages“ durch „Man-Page“
 
(69 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Virtuelle Schnittstelle''' - Virtuelle Netzwerkschnittstelle
== Beschreibung ==
== Beschreibung ==
; Schnittstellen für virtuelle Netzwerke
Linux verfügt über umfangreiche virtuelle Netzwerkfunktionen
* Grundlage für das Hosting von VMs und Containern sowie für Cloud-Umgebungen
* häufig verwendeten virtuellen Netzwerkschnittstellentypen


; Tunnel
Für andere Schnittstellen wie Tunnel lesen Sie bitte
; An introduction to Linux virtual interfaces: Tunnels


= Linux-Schnittstellen für virtuelle Netzwerke =
; Übersicht
Linux verfügt über umfangreiche virtuelle Netzwerkfunktionen, die als Grundlage für das Hosting von VMs und Containern sowie für Cloud-Umgebungen verwendet werden. In diesem Beitrag gebe ich eine kurze Einführung in alle häufig verwendeten virtuellen Netzwerkschnittstellentypen. Es gibt keine Code-Analyse, nur eine kurze Einführung in die Schnittstellen und ihre Verwendung unter Linux. Für alle, die sich mit Netzwerken auskennen, könnte dieser Blog-Beitrag interessant sein. Eine Liste der Schnittstellen kann mit dem Befehl <code>ip link help</code> abgerufen werden.
{| class="wikitable sortable options big"
 
|-
Dieser Beitrag behandelt die folgenden häufig verwendeten Schnittstellen und einige Schnittstellen, die leicht miteinander verwechselt werden können:
! Option !! Beschreibung
 
|-
* Brücke
| [[#Brücke|Brücke]] ||
* Gebundene Schnittstelle
|-
* Team-Gerät
| [[#Gebundene Schnittstelle|Gebundene Schnittstelle]] ||
* VLAN (Virtuelles LAN)
|-
* VXLAN (Virtuelles eXtensible Local Area Network)
| [[#Team-Gerät|Team-Gerät]] ||
* MACVLAN
|-
* IPVLAN
| [[#VLAN|VLAN]] || Virtuelles LAN
* MACVTAP/IPVTAP
|-
* MACsec (Sicherheit der Medienzugriffskontrolle)
| [[#VXLAN|VXLAN]] || Virtuelles eXtensible Local Area Network
* VETH (Virtuelles Ethernet)
|-
* VCAN (Virtueller CAN)
| [[#MACVLAN|MACVLAN]] ||
* VXCAN (Virtueller CAN-Tunnel)
|-
* IPOIB (IP-über-InfiniBand)
| [[#IPVLAN|IPVLAN]] ||
* NLMON (NetLink MONitor)
|-
* Dummy-Schnittstelle
| [[#MACVTAP/IPVTAP|MACVTAP/IPVTAP]] ||
* IFB (Intermediate Functional Block)
|-
* netdevsim
| [[#MACsec|MACsec]] || Sicherheit der Medienzugriffskontrolle
 
|-
Nach der Lektüre dieses Artikels werden Sie wissen, was diese Schnittstellen sind, was der Unterschied zwischen ihnen ist, wann sie zu verwenden sind und wie man sie erstellt. Für andere Schnittstellen wie Tunnel lesen Sie bitte An introduction to Linux virtual interfaces: Tunnels
| [[#VETH|VETH]] || Virtuelles Ethernet
|-
| [[#VCAN|VCAN]] || Virtueller CAN
|-
| [[#VXCAN|VXCAN]] ||Virtueller CAN-Tunnel
|-
| [[#IPOIB|IPOIB]] || IP-über-InfiniBand
|-
| [[#NLMON|NLMON]] || NetLink MONitor
|-
| [[#Dummy|Dummy]] || Dummy-Schnittstelle
|-
| [[#IFB|IFB]] || Intermediate Functional Block
|-
| [[#netdevsim|netdevsim]]
|}


== Brücke ==
== Brücke ==
Eine Linux-Bridge verhält sich wie ein Netzwerk-Switch. Sie leitet Pakete zwischen Schnittstellen weiter, die mit ihr verbunden sind. Sie wird normalerweise für die Weiterleitung von Paketen auf Routern, Gateways oder zwischen VMs und Netzwerk-Namespaces auf einem Host verwendet. Sie unterstützt auch STP, VLAN-Filter und Multicast-Snooping.
Eine Linux-Bridge verhält sich wie ein Netzwerk-Switch
* Sie leitet Pakete zwischen Schnittstellen weiter, die mit ihr verbunden sind
* Sie wird normalerweise für die Weiterleitung von Paketen auf Routern, Gateways oder zwischen VMs und Netzwerk-Namespaces auf einem Host verwendet
* Sie unterstützt auch STP, VLAN-Filter und Multicast-Snooping


Verwenden Sie eine Bridge, wenn Sie Kommunikationskanäle zwischen VMs, Containern und Ihren Hosts einrichten möchten


Verwenden Sie eine Bridge, wenn Sie Kommunikationskanäle zwischen VMs, Containern und Ihren Hosts einrichten möchten.
So erstellen Sie eine Bridge
<syntaxhighlight lang="bash" line>
ip link add br0 type bridge
ip link set eth0 master br0
ip link set tap1 master br0
ip link set tap2 master br0
ip link set veth1 master br0
</syntaxhighlight>


So erstellen Sie eine Bridge:
Dadurch wird ein Bridge-Gerät mit dem Namen <code>br0</code> erstellt und zwei TAP-Geräte (<code>tap1</code>, <code>tap2</code>), ein VETH-Gerät (<code>veth1</code>) und ein physisches Gerät (<code>eth0</code>) als seine Slaves festgelegt, wie in der obigen Abbildung dargestellt
# ip link add br0 type bridge
 
# ip link set eth0 master br0
 
# ip link set tap1 master br0
 
# ip link set tap2 master br0
 
# ip link set veth1 master br0
Dadurch wird ein Bridge-Gerät mit dem Namen <code>br0</code> erstellt und zwei TAP-Geräte (<code>tap1</code>, <code>tap2</code>), ein VETH-Gerät (<code>veth1</code>) und ein physisches Gerät (<code>eth0</code>) als seine Slaves festgelegt, wie in der obigen Abbildung dargestellt.


== Gebundene Schnittstelle ==
== Gebundene Schnittstelle ==
Der Linux-Bonding-Treiber bietet eine Methode, um mehrere Netzwerkschnittstellen zu einer einzigen logischen "gebundenen" Schnittstelle zusammenzufassen. Das Verhalten der gebondeten Schnittstelle hängt vom Modus ab; im Allgemeinen bieten die Modi entweder Hot-Standby- oder Lastausgleichsdienste.
Der Linux-Bonding-Treiber bietet eine Methode, um mehrere Netzwerkschnittstellen zu einer einzigen logischen "gebundenen" Schnittstelle zusammenzufassen
* Das Verhalten der gebondeten Schnittstelle hängt vom Modus ab; im Allgemeinen bieten die Modi entweder Hot-Standby- oder Lastausgleichsdienste


Verwenden Sie eine gebondete Schnittstelle, wenn Sie die Verbindungsgeschwindigkeit erhöhen oder einen Failover auf Ihrem Server durchführen möchten


Verwenden Sie eine gebondete Schnittstelle, wenn Sie die Verbindungsgeschwindigkeit erhöhen oder einen Failover auf Ihrem Server durchführen möchten.
So erstellen Sie eine gebondete Schnittstelle
<syntaxhighlight lang="bash" line>
ip link add bond1 type bond miimon 100 mode active-backup
ip link set eth0 master bond1
ip link set eth1 master bond1
</syntaxhighlight>


So erstellen Sie eine gebondete Schnittstelle:
Damit wird eine bonded-Schnittstelle namens <code>bond1</code> mit dem Modus active-backup erstellt
ip link add bond1 type bond miimon 100 mode active-backup
* Für andere Modi lesen Sie bitte die Kernel-Dokumentation
 
ip link set eth0 master bond1
 
ip link set eth1 master bond1
Damit wird eine bonded-Schnittstelle namens <code>bond1</code> mit dem Modus active-backup erstellt. Für andere Modi lesen Sie bitte die Kernel-Dokumentation.


== Team-Gerät ==
== Team-Gerät ==
Ähnlich wie eine gebundene Schnittstelle dient ein Teamdevice dazu, mehrere NICs (Ports) auf der L2-Schicht zu einem logischen Gerät (Teamdev) zusammenzufassen.
Ähnlich wie eine gebundene Schnittstelle dient ein Teamdevice dazu, mehrere NICs (Ports) auf der L2-Schicht zu einem logischen Gerät (Teamdev) zusammenzufassen


Das Wichtigste ist, dass ein Teamdevice nicht versucht, eine gebondete Schnittstelle zu replizieren oder zu imitieren
* Vielmehr wird dasselbe Problem mit einem anderen Ansatz gelöst, z.&nbsp;B.&nbsp;mit einem schlosslosen (RCU) TX/RX-Pfad und einem modularen Design


Das Wichtigste ist, dass ein Teamdevice nicht versucht, eine gebondete Schnittstelle zu replizieren oder zu imitieren. Vielmehr wird dasselbe Problem mit einem anderen Ansatz gelöst, z. B. mit einem schlosslosen (RCU) TX/RX-Pfad und einem modularen Design.
Es gibt aber auch einige funktionale Unterschiede zwischen einer gebondeten Schnittstelle und einem Team
* So unterstützt ein Team beispielsweise LACP-Lastausgleich, NS/NA (IPV6)-Link-Überwachung, D-Bus-Schnittstelle usw., die bei Bonding nicht vorhanden sind
* Weitere Einzelheiten zu den Unterschieden zwischen Bonding und Team finden Sie unter Bonding vs.&nbsp;Team-Funktionen


Es gibt aber auch einige funktionale Unterschiede zwischen einer gebondeten Schnittstelle und einem Team. So unterstützt ein Team beispielsweise LACP-Lastausgleich, NS/NA (IPV6)-Link-Überwachung, D-Bus-Schnittstelle usw., die bei Bonding nicht vorhanden sind. Weitere Einzelheiten zu den Unterschieden zwischen Bonding und Team finden Sie unter Bonding vs. Team-Funktionen.
Verwenden Sie ein Team, wenn Sie einige Funktionen nutzen möchten, die Bonding nicht bietet


Verwenden Sie ein Team, wenn Sie einige Funktionen nutzen möchten, die Bonding nicht bietet.
So erstellen Sie ein Team
<syntaxhighlight lang="bash" line>
teamd -o -n -U -d -t team0 -c '{"runner": {"name": "activebackup"}, "link_watch": {"name": "ethtool"}}'
ip link set eth0 down
ip link set eth1 down
teamdctl team0 port add eth0
teamdctl team0 port add eth1
</syntaxhighlight>


So erstellen Sie ein Team:
Dadurch wird eine Team-Schnittstelle namens <code>team0</code> mit dem Modus <code>active-backup</code> erstellt, und <code>eth0</code> und <code>eth1</code> werden als Sub-Schnittstellen von <code>team0</code> hinzugefügt
<nowiki># teamd -o -n -U -d -t team0 -c '{"runner": {"name": "activebackup"}, "link_watch": {"name": "ethtool"}}'</nowiki>


# ip link set eth0 down
Ein neuer Treiber namens net_failover wurde kürzlich zu Linux hinzugefügt
 
* Er ist ein weiteres Failover-Master-Netzgerät für die Virtualisierung und verwaltet ein primäres (Passthru/VF [Virtual Function]-Gerät ) Slave-Netzgerät und ein Standby-Slave-Netzgerät (die ursprüngliche paravirtuelle Schnittstelle)
# ip link set eth1 down
 
# teamdctl team0 port add eth0
 
# teamdctl team0 port add eth1
Dadurch wird eine Team-Schnittstelle namens <code>team0</code> mit dem Modus <code>active-backup</code> erstellt, und <code>eth0</code> und <code>eth1</code> werden als Sub-Schnittstellen von <code>team0</code> hinzugefügt.
 
Ein neuer Treiber namens net_failover wurde kürzlich zu Linux hinzugefügt. Er ist ein weiteres Failover-Master-Netzgerät für die Virtualisierung und verwaltet ein primäres (Passthru/VF [Virtual Function]-Gerät ) Slave-Netzgerät und ein Standby-Slave-Netzgerät (die ursprüngliche paravirtuelle Schnittstelle).


== VLAN ==
== VLAN ==
Ein VLAN, auch bekannt als virtuelles LAN, trennt Broadcast-Domänen durch Hinzufügen von Tags zu Netzwerkpaketen. VLANs ermöglichen es Netzwerkadministratoren, Hosts unter demselben Switch oder zwischen verschiedenen Switches zu gruppieren.
Ein VLAN, auch bekannt als virtuelles LAN, trennt Broadcast-Domänen durch Hinzufügen von Tags zu Netzwerkpaketen
 
* VLANs ermöglichen es Netzwerkadministratoren, Hosts unter demselben Switch oder zwischen verschiedenen Switches zu gruppieren
Der VLAN-Header sieht wie folgt aus:
 


Verwenden Sie ein VLAN, wenn Sie Subnetze in VMs, Namespaces oder Hosts trennen möchten.
; Der VLAN-Header sieht wie folgt aus


So erstellen Sie ein VLAN:
Verwenden Sie ein VLAN, wenn Sie Subnetze in VMs, Namespaces oder Hosts trennen möchten
# ip link add link eth0 name eth0.2 type vlan id 2


# ip link add link eth0 name eth0.3 type vlan id 3
; So erstellen Sie ein VLAN
Dies fügt VLAN 2 mit dem Namen <code>eth0.2</code> und VLAN 3 mit dem Namen <code>eth0.3</code> hinzu. Die Topologie sieht wie folgt aus:
<syntaxhighlight lang="bash" line>
ip link add link eth0 name eth0.2 type vlan id 2
ip link add link eth0 name eth0.3 type vlan id 3
</syntaxhighlight>


Dies fügt VLAN 2 mit dem Namen <code>eth0.2</code> und VLAN 3 mit dem Namen <code>eth0.3</code> hinzu
* Die Topologie sieht wie folgt aus


''Hinweis'': Wenn Sie ein VLAN konfigurieren, müssen Sie sicherstellen, dass der mit dem Host verbundene Switch in der Lage ist, VLAN-Tags zu verarbeiten, z. B. indem Sie den Switch-Port auf den Trunk-Modus einstellen.
; Hinweis
: Wenn Sie ein VLAN konfigurieren, müssen Sie sicherstellen, dass der mit dem Host verbundene Switch in der Lage ist, VLAN-Tags zu verarbeiten, z.&nbsp;B.&nbsp;indem Sie den Switch-Port auf den Trunk-Modus einstellen


== VXLAN ==
== VXLAN ==
VXLAN (Virtual eXtensible Local Area Network) ist ein Tunneling-Protokoll, das entwickelt wurde, um das Problem der begrenzten VLAN-IDs (4.096) in IEEE 802.1q zu lösen. Es ist im IETF <nowiki>RFC 7348</nowiki> beschrieben.
VXLAN (Virtual eXtensible Local Area Network) ist ein Tunneling-Protokoll, das entwickelt wurde, um das Problem der begrenzten VLAN-IDs (4.096) in IEEE 802.1q zu lösen
 
* Es ist im IETF <nowiki>RFC 7348</nowiki> beschrieben
Mit einer 24-Bit-Segment-ID, auch bekannt als VXLAN Network Identifier (VNI), ermöglicht VXLAN bis zu 2^24 (16.777.216) virtuelle LANs, was dem 4.096-fachen der VLAN-Kapazität entspricht.


VXLAN kapselt Layer-2-Frames mit einem VXLAN-Header in ein UDP-IP-Paket ein, das wie folgt aussieht:
Mit einer 24-Bit-Segment-ID, auch bekannt als VXLAN Network Identifier (VNI), ermöglicht VXLAN bis zu 2^24 (16.777.216) virtuelle LANs, was dem 4.096-fachen der VLAN-Kapazität entspricht


VXLAN kapselt Layer-2-Frames mit einem VXLAN-Header in ein UDP-IP-Paket ein, das wie folgt aussieht


VXLAN wird normalerweise in Rechenzentren auf virtualisierten Hosts eingesetzt, die über mehrere Racks verteilt sein können.
VXLAN wird normalerweise in Rechenzentren auf virtualisierten Hosts eingesetzt, die über mehrere Racks verteilt sein können


So verwenden Sie VXLAN
<syntaxhighlight lang="bash">
ip link add vx0 type vxlan id 100 local 1.1.1.1 remote 2.2.2.2 dev eth0 dstport 4789
</syntaxhighlight>


So verwenden Sie VXLAN:
Als Referenz können Sie die VXLAN-Kernel-Dokumentation oder diese VXLAN-Einführung lesen
# ip link add vx0 type vxlan id 100 local 1.1.1.1 remote 2.2.2.2 dev eth0 dstport 4789
Als Referenz können Sie die VXLAN-Kernel-Dokumentation oder diese VXLAN-Einführung lesen.


== MACVLAN ==
== MACVLAN ==
Mit VLAN können Sie mehrere Schnittstellen zusätzlich zu einer einzigen erstellen und Pakete auf der Grundlage eines VLAN-Tags filtern. Mit MACVLAN können Sie mehrere Schnittstellen mit unterschiedlichen Layer-2-Adressen (d. h. Ethernet-MAC-Adressen) zusätzlich zu einer einzigen Schnittstelle erstellen.
Mit VLAN können Sie mehrere Schnittstellen zusätzlich zu einer einzigen erstellen und Pakete auf der Grundlage eines VLAN-Tags filtern
 
* Mit MACVLAN können Sie mehrere Schnittstellen mit unterschiedlichen Layer-2-Adressen (d.&nbsp;h.&nbsp;Ethernet-MAC-Adressen) zusätzlich zu einer einzigen Schnittstelle erstellen
Vor MACVLAN mussten Sie, wenn Sie von einer VM oder einem Namensraum aus eine Verbindung zu einem physischen Netzwerk herstellen wollten, TAP/VETH-Geräte erstellen und eine Seite an eine Bridge anschließen und gleichzeitig eine physische Schnittstelle an die Bridge auf dem Host anschließen, wie unten dargestellt.
 
 
Mit MACVLAN können Sie nun eine physische Schnittstelle, die mit einem MACVLAN verbunden ist, direkt an Namespaces binden, ohne dass eine Bridge erforderlich ist.
 
 
Es gibt fünf MACVLAN-Typen:
 
1. Private: Erlaubt keine Kommunikation zwischen MACVLAN-Instanzen auf derselben physischen Schnittstelle, selbst wenn der externe Switch den Hairpin-Modus unterstützt.
 
 
2. VEPA: Daten von einer MACVLAN-Instanz zu einer anderen auf derselben physischen Schnittstelle werden über die physische Schnittstelle übertragen. Entweder muss der angeschlossene Switch den Hairpin-Modus unterstützen oder es muss ein TCP/IP-Router vorhanden sein, der die Pakete weiterleitet, um die Kommunikation zu ermöglichen.


Vor MACVLAN mussten Sie, wenn Sie von einer VM oder einem Namensraum aus eine Verbindung zu einem physischen Netzwerk herstellen wollten, TAP/VETH-Geräte erstellen und eine Seite an eine Bridge anschließen und gleichzeitig eine physische Schnittstelle an die Bridge auf dem Host anschließen, wie unten dargestellt


3. Bridge: Alle Endpunkte sind mit einer einfachen Bridge über die physische Schnittstelle direkt miteinander verbunden.
Mit MACVLAN können Sie nun eine physische Schnittstelle, die mit einem MACVLAN verbunden ist, direkt an Namespaces binden, ohne dass eine Bridge erforderlich ist


; Es gibt fünf MACVLAN-Typen
# Private: Erlaubt keine Kommunikation zwischen MACVLAN-Instanzen auf derselben physischen Schnittstelle, selbst wenn der externe Switch den Hairpin-Modus unterstützt
# VEPA: Daten von einer MACVLAN-Instanz zu einer anderen auf derselben physischen Schnittstelle werden über die physische Schnittstelle übertragen
#* Entweder muss der angeschlossene Switch den Hairpin-Modus unterstützen oder es muss ein TCP/IP-Router vorhanden sein, der die Pakete weiterleitet, um die Kommunikation zu ermöglichen
# Bridge: Alle Endpunkte sind mit einer einfachen Bridge über die physische Schnittstelle direkt miteinander verbunden
# Passthru: Eine einzelne VM kann direkt mit der physischen Schnittstelle verbunden werden
# Quelle: Der Quellmodus wird zum Filtern des Datenverkehrs auf der Grundlage einer Liste zulässiger MAC-Quelladressen verwendet, um MAC-basierte VLAN-Zuordnungen zu erstellen
#* Bitte beachten Sie die Commit-Meldung


4. Passthru: Eine einzelne VM kann direkt mit der physischen Schnittstelle verbunden werden.
Der Typ wird je nach den verschiedenen Anforderungen gewählt
* Der Bridge-Modus ist der am häufigsten verwendete


Verwenden Sie ein MACVLAN, wenn Sie von Containern aus eine direkte Verbindung zu einem physischen Netzwerk herstellen möchten


5. Quelle: Der Quellmodus wird zum Filtern des Datenverkehrs auf der Grundlage einer Liste zulässiger MAC-Quelladressen verwendet, um MAC-basierte VLAN-Zuordnungen zu erstellen. Bitte beachten Sie die Commit-Meldung.
So richten Sie ein MACVLAN ein
<syntaxhighlight lang="bash" line>
ip link add macvlan1 link eth0 type macvlan mode bridge
ip link add macvlan2 link eth0 type macvlan mode bridge
ip netns add net1
ip netns add net2
ip link set macvlan1 netns net1
ip link set macvlan2 netns net2
</syntaxhighlight>


Der Typ wird je nach den verschiedenen Anforderungen gewählt. Der Bridge-Modus ist der am häufigsten verwendete.
Dadurch werden zwei neue MACVLAN-Geräte im Bridge-Modus erstellt und diese zwei Geräte zwei verschiedenen Namensräumen zugewiesen
 
Verwenden Sie ein MACVLAN, wenn Sie von Containern aus eine direkte Verbindung zu einem physischen Netzwerk herstellen möchten.
 
So richten Sie ein MACVLAN ein:
# ip link add macvlan1 link eth0 type macvlan mode bridge
 
# ip link add macvlan2 link eth0 type macvlan mode bridge
 
# ip netns add net1
 
# ip netns add net2
 
# ip link set macvlan1 netns net1
 
# ip link set macvlan2 netns net2
Dadurch werden zwei neue MACVLAN-Geräte im Bridge-Modus erstellt und diese zwei Geräte zwei verschiedenen Namensräumen zugewiesen.


== IPVLAN ==
== IPVLAN ==
IPVLAN ist ähnlich wie MACVLAN, mit dem Unterschied, dass die Endpunkte dieselbe MAC-Adresse haben.
IPVLAN ist ähnlich wie MACVLAN, mit dem Unterschied, dass die Endpunkte dieselbe MAC-Adresse haben


IPVLAN unterstützt die Modi L2 und L3
* Der L2-Modus von IPVLAN verhält sich wie ein MACVLAN im Bridge-Modus
* Die übergeordnete Schnittstelle sieht wie eine Brücke oder ein Switch aus


IPVLAN unterstützt die Modi L2 und L3. Der L2-Modus von IPVLAN verhält sich wie ein MACVLAN im Bridge-Modus. Die übergeordnete Schnittstelle sieht wie eine Brücke oder ein Switch aus.
Im IPVLAN L3-Modus verhält sich die übergeordnete Schnittstelle wie ein Router und die Pakete werden zwischen den Endpunkten weitergeleitet, was eine bessere Skalierbarkeit ermöglicht


In der IPVLAN-Kerneldokumentation heißt es, dass MACVLAN und IPVLAN "in vielerlei Hinsicht sehr ähnlich sind und der spezifische Anwendungsfall sehr wohl bestimmen kann, welches Gerät zu wählen ist


Im IPVLAN L3-Modus verhält sich die übergeordnete Schnittstelle wie ein Router und die Pakete werden zwischen den Endpunkten weitergeleitet, was eine bessere Skalierbarkeit ermöglicht.
(a) Der Linux-Host, der mit dem externen Switch/Router verbunden ist, hat eine Richtlinie konfiguriert, die nur einen Mac pro Port erlaubt


(b) Die Anzahl der auf einem Master erstellten virtuellen Geräte übersteigt die Mac-Kapazität und versetzt die Netzwerkkarte in den Promiscuous-Modus, so dass Leistungseinbußen zu befürchten sind


In der IPVLAN-Kerneldokumentation heißt es, dass MACVLAN und IPVLAN "in vielerlei Hinsicht sehr ähnlich sind und der spezifische Anwendungsfall sehr wohl bestimmen kann, welches Gerät zu wählen ist.
(c) Wenn das Slave-Gerät in den feindlichen / nicht vertrauenswürdigen Netzwerk-Namensraum gesetzt werden soll, wo L2 auf dem Slave geändert / missbraucht werden könnte


(a) Der Linux-Host, der mit dem externen Switch/Router verbunden ist, hat eine Richtlinie konfiguriert, die nur einen Mac pro Port erlaubt.
So richten Sie eine IPVLAN-Instanz ein
<syntaxhighlight lang="bash" line>
ip netns add ns0
ip link add name ipvl0 link eth0 type ipvlan mode l2
ip link set dev ipvl0 netns ns0
</syntaxhighlight>


(b) Die Anzahl der auf einem Master erstellten virtuellen Geräte übersteigt die Mac-Kapazität und versetzt die Netzwerkkarte in den Promiscuous-Modus, so dass Leistungseinbußen zu befürchten sind.
Dadurch wird ein IPVLAN-Gerät mit dem Namen <code>ipvl0
 
</code> und dem Modus L2 erstellt, das dem Namensraum <code>ns0</code> zugeordnet ist
(c) Wenn das Slave-Gerät in den feindlichen / nicht vertrauenswürdigen Netzwerk-Namensraum gesetzt werden soll, wo L2 auf dem Slave geändert / missbraucht werden könnte.
 
So richten Sie eine IPVLAN-Instanz ein:
# ip netns add ns0
 
# ip link add name ipvl0 link eth0 type ipvlan mode l2
 
# ip link set dev ipvl0 netns ns0
Dadurch wird ein IPVLAN-Gerät mit dem Namen <code>ipvl0</code> und dem Modus L2 erstellt, das dem Namensraum <code>ns0</code> zugeordnet ist.


== MACVTAP/IPVTAP ==
== MACVTAP/IPVTAP ==
MACVTAP/IPVTAP ist ein neuer Gerätetreiber, der virtualisierte überbrückte Netzwerke vereinfachen soll. Wenn eine MACVTAP/IPVTAP-Instanz auf einer physischen Schnittstelle erstellt wird, erstellt der Kernel auch ein Zeichengerät/dev/tapX, das genau wie ein TUN/TAP-Gerät verwendet werden kann, das direkt von KVM/QEMU verwendet werden kann.
MACVTAP/IPVTAP ist ein neuer Gerätetreiber, der virtualisierte überbrückte Netzwerke vereinfachen soll
 
* Wenn eine MACVTAP/IPVTAP-Instanz auf einer physischen Schnittstelle erstellt wird, erstellt der Kernel auch ein Zeichengerät/dev/tapX, das genau wie ein TUN/TAP-Gerät verwendet werden kann, das direkt von KVM/QEMU verwendet werden kann
Mit MACVTAP/IPVTAP können Sie die Kombination von TUN/TAP- und Bridge-Treibern durch ein einziges Modul ersetzen:


Mit MACVTAP/IPVTAP können Sie die Kombination von TUN/TAP- und Bridge-Treibern durch ein einziges Modul ersetzen


Typischerweise wird MACVLAN/IPVLAN verwendet, um sowohl den Gast als auch den Host direkt auf dem Switch erscheinen zu lassen, mit dem der Host verbunden ist. Der Unterschied zwischen MACVTAP und IPVTAP ist der gleiche wie bei MACVLAN/IPVLAN.
Typischerweise wird MACVLAN/IPVLAN verwendet, um sowohl den Gast als auch den Host direkt auf dem Switch erscheinen zu lassen, mit dem der Host verbunden ist
* Der Unterschied zwischen MACVTAP und IPVTAP ist der gleiche wie bei MACVLAN/IPVLAN


So erstellen Sie eine MACVTAP-Instanz:
So erstellen Sie eine MACVTAP-Instanz
# ip link add link eth0 name macvtap0 type macvtap
<syntaxhighlight lang="bash">
ip link add link eth0 name macvtap0 type macvtap
</syntaxhighlight>


== MACsec ==
== MACsec ==
MACsec (Media Access Control Security) ist ein IEEE-Standard für die Sicherheit in verkabelten Ethernet-LANs. Ähnlich wie IPsec kann MACsec als Layer-2-Spezifikation nicht nur den IP-Verkehr, sondern auch ARP, Nachbarschaftserkennung und DHCP schützen. Die MACsec-Header sehen wie folgt aus:
MACsec (Media Access Control Security) ist ein IEEE-Standard für die Sicherheit in verkabelten Ethernet-LANs. Ähnlich wie IPsec kann MACsec als Layer-2-Spezifikation nicht nur den IP-Verkehr, sondern auch ARP, Nachbarschaftserkennung und DHCP schützen
 
* Die MACsec-Header sehen wie folgt aus


Der Hauptanwendungsfall für MACsec ist die Sicherung aller Nachrichten in einem Standard-LAN, einschließlich ARP-, NS- und DHCP-Nachrichten.
Der Hauptanwendungsfall für MACsec ist die Sicherung aller Nachrichten in einem Standard-LAN, einschließlich ARP-, NS- und DHCP-Nachrichten


; So richten Sie eine MACsec-Konfiguration ein
<syntaxhighlight lang="bash">
ip link add macsec0 link eth1 type macsec
</syntaxhighlight>


So richten Sie eine MACsec-Konfiguration ein:
; Hinweis
# ip link add macsec0 link eth1 type macsec
: Dies fügt nur ein MACsec-Gerät namens <code>macsec0</code> an der Schnittstelle <code>eth1</code> hinzu
''Hinweis'': Dies fügt nur ein MACsec-Gerät namens <code>macsec0</code> an der Schnittstelle <code>eth1</code> hinzu. Für detailliertere Konfigurationen lesen Sie bitte den Abschnitt "Konfigurationsbeispiel" in dieser MACsec-Einführung von Sabrina Dubroca.
:* Für detailliertere Konfigurationen lesen Sie bitte den Abschnitt "Konfigurationsbeispiel" in dieser MACsec-Einführung von Sabrina Dubroca


== VETH ==
== VETH ==
Das VETH-Gerät (Virtual Ethernet) ist ein lokaler Ethernet-Tunnel. Die Geräte werden paarweise erstellt, wie in der Abbildung unten dargestellt.
Das VETH-Gerät (Virtual Ethernet) ist ein lokaler Ethernet-Tunnel
* Die Geräte werden paarweise erstellt, wie in der Abbildung unten dargestellt


Pakete, die auf einem Gerät des Paares gesendet werden, werden sofort auf dem anderen Gerät empfangen. Wenn eines der beiden Geräte ausfällt, ist der Verbindungsstatus des Paares gestört.
Pakete, die auf einem Gerät des Paares gesendet werden, werden sofort auf dem anderen Gerät empfangen
* Wenn eines der beiden Geräte ausfällt, ist der Verbindungsstatus des Paares gestört


Verwenden Sie eine VETH-Konfiguration, wenn Namespaces mit dem Haupt-Host-Namespace oder untereinander kommunizieren müssen


Verwenden Sie eine VETH-Konfiguration, wenn Namespaces mit dem Haupt-Host-Namespace oder untereinander kommunizieren müssen.
So richten Sie eine VETH-Konfiguration ein
<syntaxhighlight lang="bash" line>
ip netns add net1
ip netns add net2
ip link add veth1 netns net1 type veth peer name veth2 netns net2
</syntaxhighlight>


So richten Sie eine VETH-Konfiguration ein:
Dadurch werden zwei Namensräume, <code>net1</code> und <code>net2</code>, und ein Paar VETH-Geräte erstellt, und <code>veth1</code> wird dem Namensraum <code>net1</code> und <code>veth2</code> dem Namensraum <code>net2</code> zugewiesen
# ip netns add net1
* Diese beiden Namespaces sind mit diesem VETH-Paar verbunden
 
* Weisen Sie ein Paar IP-Adressen zu, und Sie können zwischen den beiden Namespaces pingen und kommunizieren
# ip netns add net2
 
# ip link add veth1 netns net1 type veth peer name veth2 netns net2
Dadurch werden zwei Namensräume, <code>net1</code> und <code>net2</code>, und ein Paar VETH-Geräte erstellt, und <code>veth1</code> wird dem Namensraum <code>net1</code> und <code>veth2</code> dem Namensraum <code>net2</code> zugewiesen. Diese beiden Namespaces sind mit diesem VETH-Paar verbunden. Weisen Sie ein Paar IP-Adressen zu, und Sie können zwischen den beiden Namespaces pingen und kommunizieren.


== VCAN ==
== VCAN ==
Ähnlich wie die Netzwerk-Loopback-Geräte bietet der VCAN (Virtual CAN)-Treiber eine virtuelle lokale CAN (Controller Area Network)-Schnittstelle, so dass Benutzer CAN-Nachrichten über eine VCAN-Schnittstelle senden/empfangen können. CAN wird heutzutage hauptsächlich im Automobilbereich eingesetzt.
Ähnlich wie die Netzwerk-Loopback-Geräte bietet der VCAN (Virtual CAN)-Treiber eine virtuelle lokale CAN (Controller Area Network)-Schnittstelle, so dass Benutzer CAN-Nachrichten über eine VCAN-Schnittstelle senden/empfangen können
* CAN wird heutzutage hauptsächlich im Automobilbereich eingesetzt


Weitere Informationen zum CAN-Protokoll finden Sie in der Kernel-CAN-Dokumentation.
Weitere Informationen zum CAN-Protokoll finden Sie in der Kernel-CAN-Dokumentation


Verwenden Sie einen VCAN, wenn Sie eine CAN-Protokollimplementierung auf dem lokalen Host testen möchten.
Verwenden Sie einen VCAN, wenn Sie eine CAN-Protokollimplementierung auf dem lokalen Host testen möchten


So erstellen Sie einen VCAN:
So erstellen Sie einen VCAN
# ip link add dev vcan1 type vcan
<syntaxhighlight lang="bash">
ip link add dev vcan1 type vcan
</syntaxhighlight>


== VXCAN ==
== VXCAN ==
Ähnlich wie der VETH-Treiber implementiert ein VXCAN (Virtual CAN tunnel) einen lokalen CAN-Verkehrstunnel zwischen zwei VCAN-Netzwerkgeräten. Wenn Sie eine VXCAN-Instanz erstellen, werden zwei VXCAN-Geräte als Paar erstellt. Wenn ein Ende ein Paket empfängt, erscheint das Paket auf dem Paar des Geräts und umgekehrt. VXCAN kann für die namensraumübergreifende Kommunikation verwendet werden.
Ähnlich wie der VETH-Treiber implementiert ein VXCAN (Virtual CAN tunnel) einen lokalen CAN-Verkehrstunnel zwischen zwei VCAN-Netzwerkgeräten
* Wenn Sie eine VXCAN-Instanz erstellen, werden zwei VXCAN-Geräte als Paar erstellt
* Wenn ein Ende ein Paket empfängt, erscheint das Paket auf dem Paar des Geräts und umgekehrt
* VXCAN kann für die namensraumübergreifende Kommunikation verwendet werden


Verwenden Sie eine VXCAN-Konfiguration, wenn Sie CAN-Nachrichten über Namespaces hinweg senden wollen.
Verwenden Sie eine VXCAN-Konfiguration, wenn Sie CAN-Nachrichten über Namespaces hinweg senden wollen


So richten Sie eine VXCAN-Instanz ein:
So richten Sie eine VXCAN-Instanz ein
# ip netns add net1
<syntaxhighlight lang="bash" line>
ip netns add net1
ip netns add net2
ip link add vxcan1 netns net1 type vxcan peer name vxcan2 netns net2
</syntaxhighlight>


# ip netns add net2
; Hinweis
 
: VXCAN wird in Red Hat Enterprise Linux noch nicht unterstützt
# ip link add vxcan1 netns net1 type vxcan peer name vxcan2 netns net2
''Hinweis'': VXCAN wird in Red Hat Enterprise Linux noch nicht unterstützt.


== IPOIB ==
== IPOIB ==
Ein IPOIB-Gerät unterstützt das IP-over-InfiniBand-Protokoll. Dieses transportiert IP-Pakete über InfiniBand (IB), so dass Sie Ihr IB-Gerät als schnelle NIC verwenden können.
Ein IPOIB-Gerät unterstützt das IP-over-InfiniBand-Protokoll
* Dieses transportiert IP-Pakete über InfiniBand (IB), so dass Sie Ihr IB-Gerät als schnelle NIC verwenden können


Der IPoIB-Treiber unterstützt zwei Betriebsmodi: Datagramm und verbunden. Im Datagramm-Modus wird der IB UD-Transport (Unreliable Datagram) verwendet. Im Verbindungsmodus wird der IB RC (Reliable Connected)-Transport verwendet. Der Verbindungsmodus nutzt die Vorteile des verbundenen IB-Transports und erlaubt eine MTU bis zur maximalen IP-Paketgröße von 64K.
Der IPoIB-Treiber unterstützt zwei Betriebsmodi: Datagramm und verbunden
* Im Datagramm-Modus wird der IB UD-Transport (Unreliable Datagram) verwendet
* Im Verbindungsmodus wird der IB RC (Reliable Connected)-Transport verwendet
* Der Verbindungsmodus nutzt die Vorteile des verbundenen IB-Transports und erlaubt eine MTU bis zur maximalen IP-Paketgröße von 64K


Weitere Einzelheiten finden Sie in der IPOIB-Kerneldokumentation.
Weitere Einzelheiten finden Sie in der IPOIB-Kerneldokumentation


Verwenden Sie ein IPOIB-Gerät, wenn Sie ein IB-Gerät haben und mit einem entfernten Host über IP kommunizieren wollen.
Verwenden Sie ein IPOIB-Gerät, wenn Sie ein IB-Gerät haben und mit einem entfernten Host über IP kommunizieren wollen


So erstellen Sie ein IPOIB-Gerät:
So erstellen Sie ein IPOIB-Gerät
  # ip link add ib0 name ipoib0 type ipoib pkey IB_PKEY mode connected
  # ip link add ib0 name ipoib0 type ipoib pkey IB_PKEY mode connected


== NLMON ==
== NLMON ==
NLMON ist ein Netlink-Monitor-Gerät.
NLMON ist ein Netlink-Monitor-Gerät


Verwenden Sie ein NLMON-Gerät, wenn Sie System-Netlink-Meldungen überwachen wollen.
Verwenden Sie ein NLMON-Gerät, wenn Sie System-Netlink-Meldungen überwachen wollen


So erstellen Sie ein NLMON-Gerät:
; So erstellen Sie ein NLMON-Gerät
# ip link add nlmon0 type nlmon
<syntaxhighlight lang="bash" line>
ip link add nlmon0 type nlmon
ip link set nlmon0 up
tcpdump -i nlmon0 -w nlmsg.pcap
</syntaxhighlight>


# ip link set nlmon0 up
Damit wird ein NLMON-Gerät namens <code>nlmon0</code> erstellt und eingerichtet
* Verwenden Sie einen Packet Sniffer (z.B. <code>tcpdump</code>), um Netlink-Nachrichten zu erfassen
* Neuere Versionen von Wireshark können Netlink-Nachrichten dekodieren


# tcpdump -i nlmon0 -w nlmsg.pcap
== Dummy ==
Damit wird ein NLMON-Gerät namens <code>nlmon0</code> erstellt und eingerichtet. Verwenden Sie einen Packet Sniffer (z.B. <code>tcpdump</code>), um Netlink-Nachrichten zu erfassen. Neuere Versionen von Wireshark können Netlink-Nachrichten dekodieren.
; Dummy-Schnittstelle
Eine Dummy-Schnittstelle ist eine rein virtuelle Schnittstelle, wie z.&nbsp;B.&nbsp;die Loopback-Schnittstelle
* Der Zweck einer Dummy-Schnittstelle ist es, ein Gerät zur Verfügung zu stellen, durch das Pakete geleitet werden, ohne dass sie tatsächlich übertragen werden


== Dummy-Schnittstelle ==
Mit einer Dummy-Schnittstelle kann man eine inaktive SLIP-Adresse (Serial Line Internet Protocol) wie eine echte Adresse für lokale Programme aussehen lassen
Eine Dummy-Schnittstelle ist eine rein virtuelle Schnittstelle, wie z. B. die Loopback-Schnittstelle. Der Zweck einer Dummy-Schnittstelle ist es, ein Gerät zur Verfügung zu stellen, durch das Pakete geleitet werden, ohne dass sie tatsächlich übertragen werden.
* Heutzutage wird eine Dummy-Schnittstelle meist zum Testen und Debuggen verwendet


Mit einer Dummy-Schnittstelle kann man eine inaktive SLIP-Adresse (Serial Line Internet Protocol) wie eine echte Adresse für lokale Programme aussehen lassen. Heutzutage wird eine Dummy-Schnittstelle meist zum Testen und Debuggen verwendet.
; So erstellen Sie eine Dummy-Schnittstelle
<syntaxhighlight lang="bash" line>
ip link add dummy1 type dummy
ip addr add 1.1.1.1/24 dev dummy1
ip link set dummy1 up
</syntaxhighlight>


So erstellen Sie eine Dummy-Schnittstelle:
== IFB ==
# ip link add dummy1 type dummy
Der IFB-Treiber (Intermediate Functional Block) stellt ein Gerät zur Verfügung, das die Bündelung von Datenverkehr aus verschiedenen Quellen und das Shaping von eingehendem Datenverkehr ermöglicht, anstatt ihn zu verwerfen


# ip addr add 1.1.1.1/24 dev dummy1
Verwenden Sie eine IFB-Schnittstelle, wenn Sie den eingehenden Datenverkehr in eine Warteschlange stellen und formen wollen


# ip link set dummy1 up
; So erstellen Sie eine IFB-Schnittstelle
<syntaxhighlight lang="bash" line>
ip link add ifb0 type ifb
ip link set ifb0 up
tc qdisc add dev ifb0 root sfq
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: u32 match u32 0 0 action mirred egress redirect dev ifb0
</syntaxhighlight>


== IFB ==
Dadurch wird ein IFB-Gerät mit dem Namen <code>ifb0</code> erstellt und der Root-qdisc-Scheduler durch SFQ (Stochastic Fairness Queueing), einen klassenlosen Warteschlangen-Scheduler, ersetzt
Der IFB-Treiber (Intermediate Functional Block) stellt ein Gerät zur Verfügung, das die Bündelung von Datenverkehr aus verschiedenen Quellen und das Shaping von eingehendem Datenverkehr ermöglicht, anstatt ihn zu verwerfen.
* Dann fügt er einen Ingress-qdisc-Scheduler auf <code>eth0</code> hinzu und leitet den gesamten Ingress-Verkehr zu <code>ifb0</code> um
 
Weitere Anwendungsfälle für IFB qdisc finden Sie in diesem Wiki der Linux Foundation über IFB


Verwenden Sie eine IFB-Schnittstelle, wenn Sie den eingehenden Datenverkehr in eine Warteschlange stellen und formen wollen.
== netdevsim ==
; netdevsim-Schnittstelle
netdevsim ist ein simuliertes Netzwerkgerät, das zum Testen verschiedener Netzwerk-APIs verwendet wird
* Zur Zeit konzentriert es sich besonders auf das Testen von Hardware
Offloading, tc/XDP BPF und SR-IOV


So erstellen Sie eine IFB-Schnittstelle:
Ein netdevsim-Gerät kann wie folgt erstellt werden
# ip link add ifb0 type ifb
<syntaxhighlight lang="bash" line>
ip link add dev sim0 type netdevsim
ip link set dev sim0 up
</syntaxhighlight>


# ip link set ifb0 up
So aktivieren Sie tc offload
<syntaxhighlight lang="bash">
ethtool -K sim0 hw-tc-offload on
</syntaxhighlight>


# tc qdisc add dev ifb0 root sfq
Um XDP BPF oder tc BPF Programme zu laden
<syntaxhighlight lang="bash">
ip link set dev sim0 xdpoffload obj prog.o
</syntaxhighlight>


# tc qdisc add dev eth0 handle ffff: ingress
So fügen Sie VFs für SR-IOV-Tests hinzu
<syntaxhighlight lang="bash" line>
echo 3 > /sys/class/net/sim0/device/sriov_numvfs
ip link set sim0 vf 0 mac
</syntaxhighlight>


# tc filter add dev eth0 parent ffff: u32 match u32 0 0 action mirred egress redirect dev ifb0
Um die vf-Nummern zu ändern, müssen Sie sie zunächst vollständig deaktivieren
Dadurch wird ein IFB-Gerät mit dem Namen <code>ifb0</code> erstellt und der Root-qdisc-Scheduler durch SFQ (Stochastic Fairness Queueing), einen klassenlosen Warteschlangen-Scheduler, ersetzt. Dann fügt er einen Ingress-qdisc-Scheduler auf <code>eth0</code> hinzu und leitet den gesamten Ingress-Verkehr zu <code>ifb0</code> um.
<syntaxhighlight lang="bash" line>
echo 0 > /sys/class/net/sim0/device/sriov_numvfs
echo 5 > /sys/class/net/sim0/device/sriov_numvfs
</syntaxhighlight>


Weitere Anwendungsfälle für IFB qdisc finden Sie in diesem Wiki der Linux Foundation über IFB.
; Hinweis
: netdevsim wird in RHEL standardmäßig nicht kompiliert


== Zusätzliche Ressourcen ==
<noinclude>


== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Dokumentation ====
===== Man-Page =====
===== Info-Pages =====
==== Links ====
===== Projekt =====
===== Weblinks =====
; Weitere Ressourcen
* Artikel über virtuelle Netzwerke auf dem Red Hat Developer Blog
* Artikel über virtuelle Netzwerke auf dem Red Hat Developer Blog
* Dynamische IP-Adressverwaltung im Open Virtual Network (OVN)
* Dynamische IP-Adressverwaltung im Open Virtual Network (OVN)
Zeile 308: Zeile 410:
* Open vSwitch-Artikel im Red Hat Developer Blog
* Open vSwitch-Artikel im Red Hat Developer Blog


== netdevsim-Schnittstelle ==
[[Kategorie:Linux/Netzwerk]]
netdevsim ist ein simuliertes Netzwerkgerät, das zum Testen verschiedener Netzwerk-APIs verwendet wird. Zur Zeit konzentriert es sich besonders auf das Testen von Hardware
 
Offloading, tc/XDP BPF und SR-IOV.
 
Ein netdevsim-Gerät kann wie folgt erstellt werden
# ip link add dev sim0 type netdevsim
 
# ip link set dev sim0 up
So aktivieren Sie tc offload:
# ethtool -K sim0 hw-tc-offload on
Um XDP BPF oder tc BPF Programme zu laden:
# ip link set dev sim0 xdpoffload obj prog.o
So fügen Sie VFs für SR-IOV-Tests hinzu:
# echo 3 > /sys/class/net/sim0/device/sriov_numvfs
 
# ip link set sim0 vf 0 mac
Um die vf-Nummern zu ändern, müssen Sie sie zunächst vollständig deaktivieren:
# echo 0 > /sys/class/net/sim0/device/sriov_numvfs
 
# echo 5 > /sys/class/net/sim0/device/sriov_numvfs
<code>Hinweis</code>: netdevsim wird in RHEL standardmäßig nicht kompiliert
 
; Linux interfaces for virtual networking
Linux has rich virtual networking capabilities that are used as basis for hosting VMs and containers, as well as cloud environments. In this post, I will give a brief introduction to all commonly used virtual network interface types. There is no code analysis, only a brief introduction to the interfaces and their usage on Linux. Anyone with a network background might be interested in this blog post. A list of interfaces can be obtained using the command <code>ip link help</code>.
 
This post covers the following frequently used interfaces and some interfaces that can be easily confused with one another:
* Bridge
* Bonded interface
* Team device
* VLAN (Virtual LAN)
* VXLAN (Virtual eXtensible Local Area Network)
* MACVLAN
* IPVLAN
* MACVTAP/IPVTAP
* MACsec (Media Access Control Security)
* VETH (Virtual Ethernet)
* VCAN (Virtual CAN)
* VXCAN (Virtual CAN tunnel)
* IPOIB (IP-over-InfiniBand)
* NLMON (NetLink MONitor)
* Dummy interface
* IFB (Intermediate Functional Block)
* netdevsim
 
After reading this article, you will know what these interfaces are, what's the difference between them, when to use them, and how to create them. For other interfaces like tunnel, please see An introduction to Linux virtual interfaces: Tunnels
 
== Bridge ==
A Linux bridge behaves like a network switch. It forwards packets between interfaces that are connected to it. It's usually used for forwarding packets on routers, on gateways, or between VMs and network namespaces on a host. It also supports STP, VLAN filter, and multicast snooping.
 
 
Use a bridge when you want to establish communication channels between VMs, containers, and your hosts.
 
Here's how to create a bridge:
# ip link add br0 type bridge
# ip link set eth0 master br0
# ip link set tap1 master br0
# ip link set tap2 master br0
# ip link set veth1 master br0
This creates a bridge device named <code>br0</code> and sets two TAP devices (<code>tap1</code>, <code>tap2</code>), a VETH device (<code>veth1</code>), and a physical device (<code>eth0</code>) as its slaves, as shown in the diagram above.
 
== Bonded interface ==
The Linux bonding driver provides a method for aggregating multiple network interfaces into a single logical "bonded" interface. The behavior of the bonded interface depends on the mode; generally speaking, modes provide either hot standby or load balancing services.
 
 
Use a bonded interface when you want to increase your link speed or do a failover on your server.
 
Here's how to create a bonded interface:
ip link add bond1 type bond miimon 100 mode active-backup
ip link set eth0 master bond1
ip link set eth1 master bond1
This creates a bonded interface named <code>bond1</code> with mode active-backup. For other modes, please see the kernel documentation.
 
== Team device ==
Similar a bonded interface, the purpose of a team device is to provide a mechanism to group multiple NICs (ports) into one logical one (teamdev) at the L2 layer.
 
 
The main thing to realize is that a team device is not trying to replicate or mimic a bonded interface. What it does is to solve the same problem using a different approach, using, for example, a lockless (RCU) TX/RX path and modular design.
 
But there are also some functional differences between a bonded interface and a team. For example, a team supports LACP load-balancing, NS/NA (IPV6) link monitoring, D-Bus interface, etc., which are absent in bonding. For further details about the differences between bonding and team, see Bonding vs. Team features.
 
Use a team when you want to use some features that bonding doesn't provide.
 
Here's how to create a team:
# teamd -o -n -U -d -t team0 -c '{"runner": {"name": "activebackup"},"link_watch": {"name": "ethtool"}}'
<nowiki>#</nowiki> ip link set eth0 down
<nowiki>#</nowiki> ip link set eth1 down
<nowiki>#</nowiki> teamdctl team0 port add eth0
<nowiki>#</nowiki> teamdctl team0 port add eth1
This creates a team interface named <code>team0</code> with mode <code>active-backup</code>, and it adds <code>eth0</code> and <code>eth1</code> as <code>team0</code>'s sub-interfaces.
 
A new driver called net_failover has been added to Linux recently. It's another failover master net device for virtualization and manages a primary (passthru/VF [Virtual Function] device) slave net device and a standby (the original paravirtual interface) slave net device.
 
== VLAN ==
A VLAN, aka virtual LAN, separates broadcast domains by adding tags to network packets. VLANs allow network administrators to group hosts under the same switch or between different switches.
 
The VLAN header looks like:
 
 
Use a VLAN when you want to separate subnet in VMs, namespaces, or hosts.
 
Here's how to create a VLAN:
# ip link add link eth0 name eth0.2 type vlan id 2
# ip link add link eth0 name eth0.3 type vlan id 3
This adds VLAN 2 with name <code>eth0.2</code> and VLAN 3 with name <code>eth0.3</code>. The topology looks like this:
 
 
''Note'': When configuring a VLAN, you need to make sure the switch connected to the host is able to handle VLAN tags, for example, by setting the switch port to trunk mode.
 
== VXLAN ==
VXLAN (Virtual eXtensible Local Area Network) is a tunneling protocol designed to solve the problem of limited VLAN IDs (4,096) in IEEE 802.1q. It is described by IETF <nowiki>RFC 7348</nowiki>.
 
With a 24-bit segment ID, aka VXLAN Network Identifier (VNI), VXLAN allows up to 2^24 (16,777,216) virtual LANs, which is 4,096 times the VLAN capacity.
 
VXLAN encapsulates Layer 2 frames with a VXLAN header into a UDP-IP packet, which looks like this:
 
 
VXLAN is typically deployed in data centers on virtualized hosts, which may be spread across multiple racks.
 
 
Here's how to use VXLAN:
# ip link add vx0 type vxlan id 100 local 1.1.1.1 remote 2.2.2.2 dev eth0 dstport 4789
For reference, you can read the VXLAN kernel documentation or this VXLAN introduction.
 
== MACVLAN ==
With VLAN, you can create multiple interfaces on top of a single one and filter packages based on a VLAN tag. With MACVLAN, you can create multiple interfaces with different Layer 2 (that is, Ethernet MAC) addresses on top of a single one.
 
Before MACVLAN, if you wanted to connect to physical network from a VM or namespace, you would have needed to create TAP/VETH devices and attach one side to a bridge and attach a physical interface to the bridge on the host at the same time, as shown below.
 
 
Now, with MACVLAN, you can bind a physical interface that is associated with a MACVLAN directly to namespaces, without the need for a bridge.
 
 
There are five MACVLAN types:
 
1. Private: doesn't allow communication between MACVLAN instances on the same physical interface, even if the external switch supports hairpin mode.
 
 
2. VEPA: data from one MACVLAN instance to the other on the same physical interface is transmitted over the physical interface. Either the attached switch needs to support hairpin mode or there must be a TCP/IP router forwarding the packets in order to allow communication.
 
 
3. Bridge: all endpoints are directly connected to each other with a simple bridge via the physical interface.
 
 
4. Passthru: allows a single VM to be connected directly to the physical interface.
 
 
5. Source: the source mode is used to filter traffic based on a list of allowed source MAC addresses to create MAC-based VLAN associations. Please see the commit message.
 
The type is chosen according to different needs. Bridge mode is the most commonly used.
 
Use a MACVLAN when you want to connect directly to a physical network from containers.
 
Here's how to set up a MACVLAN:
# ip link add macvlan1 link eth0 type macvlan mode bridge
# ip link add macvlan2 link eth0 type macvlan mode bridge
# ip netns add net1
# ip netns add net2
# ip link set macvlan1 netns net1
# ip link set macvlan2 netns net2
This creates two new MACVLAN devices in bridge mode and assigns these two devices to two different namespaces.
 
== IPVLAN ==
IPVLAN is similar to MACVLAN with the difference being that the endpoints have the same MAC address.
 
 
IPVLAN supports L2 and L3 mode. IPVLAN L2 mode acts like a MACVLAN in bridge mode. The parent interface looks like a bridge or switch.
 
 
In IPVLAN L3 mode, the parent interface acts like a router and packets are routed between endpoints, which gives better scalability.
 
 
Regarding when to use an IPVLAN, the IPVLAN kernel documentation says that MACVLAN and IPVLAN "are very similar in many regards and the specific use case could very well define which device to choose. if one of the following situations defines your use case then you can choose to use ipvlan -
 
(a) The Linux host that is connected to the external switch / router has policy configured that allows only one mac per port.
 
(b) No of virtual devices created on a master exceed the mac capacity and puts the NIC in promiscuous mode and degraded performance is a concern.
 
(c) If the slave device is to be put into the hostile / untrusted network namespace where L2 on the slave could be changed / misused."
 
Here's how to set up an IPVLAN instance:
# ip netns add ns0
# ip link add name ipvl0 link eth0 type ipvlan mode l2
# ip link set dev ipvl0 netns ns0
This creates an IPVLAN device named <code>ipvl0</code> with mode L2, assigned to namespace <code>ns0</code>.
 
== MACVTAP/IPVTAP ==
MACVTAP/IPVTAP is a new device driver meant to simplify virtualized bridged networking. When a MACVTAP/IPVTAP instance is created on top of a physical interface, the kernel also creates a character device/dev/tapX to be used just like a TUN/TAP device, which can be directly used by KVM/QEMU.
 
With MACVTAP/IPVTAP, you can replace the combination of TUN/TAP and bridge drivers with a single module:
 
 
Typically, MACVLAN/IPVLAN is used to make both the guest and the host show up directly on the switch to which the host is connected. The difference between MACVTAP and IPVTAP is same as with MACVLAN/IPVLAN.
 
Here's how to create a MACVTAP instance:
# ip link add link eth0 name macvtap0 type macvtap
 
== MACsec ==
MACsec (Media Access Control Security) is an IEEE standard for security in wired Ethernet LANs. Similar to IPsec, as a layer 2 specification, MACsec can protect not only IP traffic but also ARP, neighbor discovery, and DHCP. The MACsec headers look like this:
 
 
The main use case for MACsec is to secure all messages on a standard LAN including ARP, NS, and DHCP messages.
 
 
Here's how to set up a MACsec configuration:
# ip link add macsec0 link eth1 type macsec
''Note'': This only adds a MACsec device called <code>macsec0</code> on interface <code>eth1</code>. For more detailed configurations, please see the "Configuration example" section in this MACsec introduction by Sabrina Dubroca.
 
== VETH ==
The VETH (virtual Ethernet) device is a local Ethernet tunnel. Devices are created in pairs, as shown in the diagram below.
 
Packets transmitted on one device in the pair are immediately received on the other device. When either device is down, the link state of the pair is down.
 
 
Use a VETH configuration when namespaces need to communicate to the main host namespace or between each other.
 
Here's how to set up a VETH configuration:
# ip netns add net1
# ip netns add net2
# ip link add veth1 netns net1 type veth peer name veth2 netns net2
This creates two namespaces, <code>net1</code> and <code>net2</code>, and a pair of VETH devices, and it assigns <code>veth1</code> to namespace <code>net1</code> and <code>veth2</code> to namespace <code>net2</code>. These two namespaces are connected with this VETH pair. Assign a pair of IP addresses, and you can ping and communicate between the two namespaces.
 
== VCAN ==
Similar to the network loopback devices, the VCAN (virtual CAN) driver offers a virtual local CAN (Controller Area Network) interface, so users can send/receive CAN messages via a VCAN interface. CAN is mostly used in the automotive field nowadays.
 
For more CAN protocol information, please refer to the kernel CAN documentation.
 
Use a VCAN when you want to test a CAN protocol implementation on the local host.
 
Here's how to create a VCAN:
# ip link add dev vcan1 type vcan
 
== VXCAN ==
Similar to the VETH driver, a VXCAN (Virtual CAN tunnel) implements a local CAN traffic tunnel between two VCAN network devices. When you create a VXCAN instance, two VXCAN devices are created as a pair. When one end receives the packet, the packet appears on the device's pair and vice versa. VXCAN can be used for cross-namespace communication.
 
Use a VXCAN configuration when you want to send CAN message across namespaces.
 
Here's how to set up a VXCAN instance:
# ip netns add net1
# ip netns add net2
# ip link add vxcan1 netns net1 type vxcan peer name vxcan2 netns net2
''Note'': VXCAN is not yet supported in Red Hat Enterprise Linux.
 
== IPOIB ==
An IPOIB device supports the IP-over-InfiniBand protocol. This transports IP packets over InfiniBand (IB) so you can use your IB device as a fast NIC.
 
The IPoIB driver supports two modes of operation: datagram and connected. In datagram mode, the IB UD (Unreliable Datagram) transport is used. In connected mode, the IB RC (Reliable Connected) transport is used. The connected mode takes advantage of the connected nature of the IB transport and allows an MTU up to the maximal IP packet size of 64K.
 
For more details, please see the IPOIB kernel documentation.
 
Use an IPOIB device when you have an IB device and want to communicate with a remote host via IP.
 
Here's how to create an IPOIB device:
# ip link add ib0 name ipoib0 type ipoib pkey IB_PKEY mode connected
 
== NLMON ==
NLMON is a Netlink monitor device.
 
Use an NLMON device when you want to monitor system Netlink messages.
 
Here's how to create an NLMON device:
# ip link add nlmon0 type nlmon
# ip link set nlmon0 up
# tcpdump -i nlmon0 -w nlmsg.pcap
This creates an NLMON device named <code>nlmon0</code> and sets it up. Use a packet sniffer (for example, <code>tcpdump</code>) to capture Netlink messages. Recent versions of Wireshark feature decoding of Netlink messages.
 
== Dummy interface ==
A dummy interface is entirely virtual like, for example, the loopback interface. The purpose of a dummy interface is to provide a device to route packets through without actually transmitting them.
 
Use a dummy interface to make an inactive SLIP (Serial Line Internet Protocol) address look like a real address for local programs. Nowadays, a dummy interface is mostly used for testing and debugging.
 
Here's how to create a dummy interface:
# ip link add dummy1 type dummy
# ip addr add 1.1.1.1/24 dev dummy1
# ip link set dummy1 up
 
== IFB ==
The IFB (Intermediate Functional Block) driver supplies a device that allows the concentration of traffic from several sources and the shaping incoming traffic instead of dropping it.
 
Use an IFB interface when you want to queue and shape incoming traffic.
 
Here's how to create an IFB interface:
# ip link add ifb0 type ifb
# ip link set ifb0 up
# tc qdisc add dev ifb0 root sfq
# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: u32 match u32 0 0 action mirred egress redirect dev ifb0
This creates an IFB device named <code>ifb0</code> and replaces the root qdisc scheduler with SFQ (Stochastic Fairness Queueing), which is a classless queueing scheduler. Then it adds an ingress qdisc scheduler on <code>eth0</code> and redirects all ingress traffic to <code>ifb0</code>.
 
For more IFB qdisc use cases, please refer to this Linux Foundation wiki on IFB.
 
== Additional resources ==
 
* Virtual networking articles on the Red Hat Developer blog
* Dynamic IP Address Management in Open Virtual Network (OVN)
* Non-root Open vSwitch in Red Hat Enterprise Linux
* Open vSwitch articles on the Red hat Developer Blog
 
== netdevsim interface ==
netdevsim is a simulated networking device which is used for testing various networking APIs. At this time it is particularly focused on testing hardware
 
offloading, tc/XDP BPF and SR-IOV.


A netdevsim device can be created as follows
</noinclude>
# ip link add dev sim0 type netdevsim
# ip link set dev sim0 up
To enable tc offload:
# ethtool -K sim0 hw-tc-offload on
To load XDP BPF or tc BPF programs:
# ip link set dev sim0 xdpoffload obj prog.o
To add VFs for SR-IOV testing:
# echo 3 > /sys/class/net/sim0/device/sriov_numvfs
# ip link set sim0 vf 0 mac
To change the vf numbers, you need to disable them completely first:
# echo 0 > /sys/class/net/sim0/device/sriov_numvfs
# echo 5 > /sys/class/net/sim0/device/sriov_numvfs
<code>Note</code>: netdevsim is not compiled in RHEL by default

Aktuelle Version vom 6. November 2024, 12:34 Uhr

Virtuelle Schnittstelle - Virtuelle Netzwerkschnittstelle

Beschreibung

Schnittstellen für virtuelle Netzwerke

Linux verfügt über umfangreiche virtuelle Netzwerkfunktionen

  • Grundlage für das Hosting von VMs und Containern sowie für Cloud-Umgebungen
  • häufig verwendeten virtuellen Netzwerkschnittstellentypen
Tunnel

Für andere Schnittstellen wie Tunnel lesen Sie bitte

An introduction to Linux virtual interfaces
Tunnels
Übersicht
Option Beschreibung
Brücke
Gebundene Schnittstelle
Team-Gerät
VLAN Virtuelles LAN
VXLAN Virtuelles eXtensible Local Area Network
MACVLAN
IPVLAN
MACVTAP/IPVTAP
MACsec Sicherheit der Medienzugriffskontrolle
VETH Virtuelles Ethernet
VCAN Virtueller CAN
VXCAN Virtueller CAN-Tunnel
IPOIB IP-über-InfiniBand
NLMON NetLink MONitor
Dummy Dummy-Schnittstelle
IFB Intermediate Functional Block
netdevsim

Brücke

Eine Linux-Bridge verhält sich wie ein Netzwerk-Switch

  • Sie leitet Pakete zwischen Schnittstellen weiter, die mit ihr verbunden sind
  • Sie wird normalerweise für die Weiterleitung von Paketen auf Routern, Gateways oder zwischen VMs und Netzwerk-Namespaces auf einem Host verwendet
  • Sie unterstützt auch STP, VLAN-Filter und Multicast-Snooping

Verwenden Sie eine Bridge, wenn Sie Kommunikationskanäle zwischen VMs, Containern und Ihren Hosts einrichten möchten

So erstellen Sie eine Bridge 

ip link add br0 type bridge
ip link set eth0 master br0
ip link set tap1 master br0
ip link set tap2 master br0
ip link set veth1 master br0

Dadurch wird ein Bridge-Gerät mit dem Namen br0 erstellt und zwei TAP-Geräte (tap1, tap2), ein VETH-Gerät (veth1) und ein physisches Gerät (eth0) als seine Slaves festgelegt, wie in der obigen Abbildung dargestellt

Gebundene Schnittstelle

Der Linux-Bonding-Treiber bietet eine Methode, um mehrere Netzwerkschnittstellen zu einer einzigen logischen "gebundenen" Schnittstelle zusammenzufassen

  • Das Verhalten der gebondeten Schnittstelle hängt vom Modus ab; im Allgemeinen bieten die Modi entweder Hot-Standby- oder Lastausgleichsdienste

Verwenden Sie eine gebondete Schnittstelle, wenn Sie die Verbindungsgeschwindigkeit erhöhen oder einen Failover auf Ihrem Server durchführen möchten

So erstellen Sie eine gebondete Schnittstelle 

ip link add bond1 type bond miimon 100 mode active-backup
ip link set eth0 master bond1
ip link set eth1 master bond1

Damit wird eine bonded-Schnittstelle namens bond1 mit dem Modus active-backup erstellt

  • Für andere Modi lesen Sie bitte die Kernel-Dokumentation

Team-Gerät

Ähnlich wie eine gebundene Schnittstelle dient ein Teamdevice dazu, mehrere NICs (Ports) auf der L2-Schicht zu einem logischen Gerät (Teamdev) zusammenzufassen

Das Wichtigste ist, dass ein Teamdevice nicht versucht, eine gebondete Schnittstelle zu replizieren oder zu imitieren

  • Vielmehr wird dasselbe Problem mit einem anderen Ansatz gelöst, z. B. mit einem schlosslosen (RCU) TX/RX-Pfad und einem modularen Design

Es gibt aber auch einige funktionale Unterschiede zwischen einer gebondeten Schnittstelle und einem Team

  • So unterstützt ein Team beispielsweise LACP-Lastausgleich, NS/NA (IPV6)-Link-Überwachung, D-Bus-Schnittstelle usw., die bei Bonding nicht vorhanden sind
  • Weitere Einzelheiten zu den Unterschieden zwischen Bonding und Team finden Sie unter Bonding vs. Team-Funktionen

Verwenden Sie ein Team, wenn Sie einige Funktionen nutzen möchten, die Bonding nicht bietet

So erstellen Sie ein Team 

teamd -o -n -U -d -t team0 -c '{"runner": {"name": "activebackup"}, "link_watch": {"name": "ethtool"}}'
ip link set eth0 down
ip link set eth1 down
teamdctl team0 port add eth0
teamdctl team0 port add eth1

Dadurch wird eine Team-Schnittstelle namens team0 mit dem Modus active-backup erstellt, und eth0 und eth1 werden als Sub-Schnittstellen von team0 hinzugefügt

Ein neuer Treiber namens net_failover wurde kürzlich zu Linux hinzugefügt

  • Er ist ein weiteres Failover-Master-Netzgerät für die Virtualisierung und verwaltet ein primäres (Passthru/VF [Virtual Function]-Gerät ) Slave-Netzgerät und ein Standby-Slave-Netzgerät (die ursprüngliche paravirtuelle Schnittstelle)

VLAN

Ein VLAN, auch bekannt als virtuelles LAN, trennt Broadcast-Domänen durch Hinzufügen von Tags zu Netzwerkpaketen

  • VLANs ermöglichen es Netzwerkadministratoren, Hosts unter demselben Switch oder zwischen verschiedenen Switches zu gruppieren
Der VLAN-Header sieht wie folgt aus

Verwenden Sie ein VLAN, wenn Sie Subnetze in VMs, Namespaces oder Hosts trennen möchten

So erstellen Sie ein VLAN
ip link add link eth0 name eth0.2 type vlan id 2
ip link add link eth0 name eth0.3 type vlan id 3

Dies fügt VLAN 2 mit dem Namen eth0.2 und VLAN 3 mit dem Namen eth0.3 hinzu

  • Die Topologie sieht wie folgt aus
Hinweis
Wenn Sie ein VLAN konfigurieren, müssen Sie sicherstellen, dass der mit dem Host verbundene Switch in der Lage ist, VLAN-Tags zu verarbeiten, z. B. indem Sie den Switch-Port auf den Trunk-Modus einstellen

VXLAN

VXLAN (Virtual eXtensible Local Area Network) ist ein Tunneling-Protokoll, das entwickelt wurde, um das Problem der begrenzten VLAN-IDs (4.096) in IEEE 802.1q zu lösen

  • Es ist im IETF RFC 7348 beschrieben

Mit einer 24-Bit-Segment-ID, auch bekannt als VXLAN Network Identifier (VNI), ermöglicht VXLAN bis zu 2^24 (16.777.216) virtuelle LANs, was dem 4.096-fachen der VLAN-Kapazität entspricht

VXLAN kapselt Layer-2-Frames mit einem VXLAN-Header in ein UDP-IP-Paket ein, das wie folgt aussieht

VXLAN wird normalerweise in Rechenzentren auf virtualisierten Hosts eingesetzt, die über mehrere Racks verteilt sein können

So verwenden Sie VXLAN 

ip link add vx0 type vxlan id 100 local 1.1.1.1 remote 2.2.2.2 dev eth0 dstport 4789

Als Referenz können Sie die VXLAN-Kernel-Dokumentation oder diese VXLAN-Einführung lesen

MACVLAN

Mit VLAN können Sie mehrere Schnittstellen zusätzlich zu einer einzigen erstellen und Pakete auf der Grundlage eines VLAN-Tags filtern

  • Mit MACVLAN können Sie mehrere Schnittstellen mit unterschiedlichen Layer-2-Adressen (d. h. Ethernet-MAC-Adressen) zusätzlich zu einer einzigen Schnittstelle erstellen

Vor MACVLAN mussten Sie, wenn Sie von einer VM oder einem Namensraum aus eine Verbindung zu einem physischen Netzwerk herstellen wollten, TAP/VETH-Geräte erstellen und eine Seite an eine Bridge anschließen und gleichzeitig eine physische Schnittstelle an die Bridge auf dem Host anschließen, wie unten dargestellt

Mit MACVLAN können Sie nun eine physische Schnittstelle, die mit einem MACVLAN verbunden ist, direkt an Namespaces binden, ohne dass eine Bridge erforderlich ist

Es gibt fünf MACVLAN-Typen
  1. Private: Erlaubt keine Kommunikation zwischen MACVLAN-Instanzen auf derselben physischen Schnittstelle, selbst wenn der externe Switch den Hairpin-Modus unterstützt
  2. VEPA: Daten von einer MACVLAN-Instanz zu einer anderen auf derselben physischen Schnittstelle werden über die physische Schnittstelle übertragen
    • Entweder muss der angeschlossene Switch den Hairpin-Modus unterstützen oder es muss ein TCP/IP-Router vorhanden sein, der die Pakete weiterleitet, um die Kommunikation zu ermöglichen
  3. Bridge: Alle Endpunkte sind mit einer einfachen Bridge über die physische Schnittstelle direkt miteinander verbunden
  4. Passthru: Eine einzelne VM kann direkt mit der physischen Schnittstelle verbunden werden
  5. Quelle: Der Quellmodus wird zum Filtern des Datenverkehrs auf der Grundlage einer Liste zulässiger MAC-Quelladressen verwendet, um MAC-basierte VLAN-Zuordnungen zu erstellen
    • Bitte beachten Sie die Commit-Meldung

Der Typ wird je nach den verschiedenen Anforderungen gewählt

  • Der Bridge-Modus ist der am häufigsten verwendete

Verwenden Sie ein MACVLAN, wenn Sie von Containern aus eine direkte Verbindung zu einem physischen Netzwerk herstellen möchten

So richten Sie ein MACVLAN ein 

ip link add macvlan1 link eth0 type macvlan mode bridge
ip link add macvlan2 link eth0 type macvlan mode bridge
ip netns add net1
ip netns add net2
ip link set macvlan1 netns net1
ip link set macvlan2 netns net2

Dadurch werden zwei neue MACVLAN-Geräte im Bridge-Modus erstellt und diese zwei Geräte zwei verschiedenen Namensräumen zugewiesen

IPVLAN

IPVLAN ist ähnlich wie MACVLAN, mit dem Unterschied, dass die Endpunkte dieselbe MAC-Adresse haben

IPVLAN unterstützt die Modi L2 und L3

  • Der L2-Modus von IPVLAN verhält sich wie ein MACVLAN im Bridge-Modus
  • Die übergeordnete Schnittstelle sieht wie eine Brücke oder ein Switch aus

Im IPVLAN L3-Modus verhält sich die übergeordnete Schnittstelle wie ein Router und die Pakete werden zwischen den Endpunkten weitergeleitet, was eine bessere Skalierbarkeit ermöglicht

In der IPVLAN-Kerneldokumentation heißt es, dass MACVLAN und IPVLAN "in vielerlei Hinsicht sehr ähnlich sind und der spezifische Anwendungsfall sehr wohl bestimmen kann, welches Gerät zu wählen ist

(a) Der Linux-Host, der mit dem externen Switch/Router verbunden ist, hat eine Richtlinie konfiguriert, die nur einen Mac pro Port erlaubt

(b) Die Anzahl der auf einem Master erstellten virtuellen Geräte übersteigt die Mac-Kapazität und versetzt die Netzwerkkarte in den Promiscuous-Modus, so dass Leistungseinbußen zu befürchten sind

(c) Wenn das Slave-Gerät in den feindlichen / nicht vertrauenswürdigen Netzwerk-Namensraum gesetzt werden soll, wo L2 auf dem Slave geändert / missbraucht werden könnte

So richten Sie eine IPVLAN-Instanz ein 

ip netns add ns0
ip link add name ipvl0 link eth0 type ipvlan mode l2
ip link set dev ipvl0 netns ns0

Dadurch wird ein IPVLAN-Gerät mit dem Namen ipvl0 und dem Modus L2 erstellt, das dem Namensraum ns0 zugeordnet ist

MACVTAP/IPVTAP

MACVTAP/IPVTAP ist ein neuer Gerätetreiber, der virtualisierte überbrückte Netzwerke vereinfachen soll

  • Wenn eine MACVTAP/IPVTAP-Instanz auf einer physischen Schnittstelle erstellt wird, erstellt der Kernel auch ein Zeichengerät/dev/tapX, das genau wie ein TUN/TAP-Gerät verwendet werden kann, das direkt von KVM/QEMU verwendet werden kann

Mit MACVTAP/IPVTAP können Sie die Kombination von TUN/TAP- und Bridge-Treibern durch ein einziges Modul ersetzen

Typischerweise wird MACVLAN/IPVLAN verwendet, um sowohl den Gast als auch den Host direkt auf dem Switch erscheinen zu lassen, mit dem der Host verbunden ist

  • Der Unterschied zwischen MACVTAP und IPVTAP ist der gleiche wie bei MACVLAN/IPVLAN

So erstellen Sie eine MACVTAP-Instanz 

ip link add link eth0 name macvtap0 type macvtap

MACsec

MACsec (Media Access Control Security) ist ein IEEE-Standard für die Sicherheit in verkabelten Ethernet-LANs. Ähnlich wie IPsec kann MACsec als Layer-2-Spezifikation nicht nur den IP-Verkehr, sondern auch ARP, Nachbarschaftserkennung und DHCP schützen

  • Die MACsec-Header sehen wie folgt aus

Der Hauptanwendungsfall für MACsec ist die Sicherung aller Nachrichten in einem Standard-LAN, einschließlich ARP-, NS- und DHCP-Nachrichten

So richten Sie eine MACsec-Konfiguration ein
ip link add macsec0 link eth1 type macsec
Hinweis
Dies fügt nur ein MACsec-Gerät namens macsec0 an der Schnittstelle eth1 hinzu
  • Für detailliertere Konfigurationen lesen Sie bitte den Abschnitt "Konfigurationsbeispiel" in dieser MACsec-Einführung von Sabrina Dubroca

VETH

Das VETH-Gerät (Virtual Ethernet) ist ein lokaler Ethernet-Tunnel

  • Die Geräte werden paarweise erstellt, wie in der Abbildung unten dargestellt

Pakete, die auf einem Gerät des Paares gesendet werden, werden sofort auf dem anderen Gerät empfangen

  • Wenn eines der beiden Geräte ausfällt, ist der Verbindungsstatus des Paares gestört

Verwenden Sie eine VETH-Konfiguration, wenn Namespaces mit dem Haupt-Host-Namespace oder untereinander kommunizieren müssen

So richten Sie eine VETH-Konfiguration ein 

ip netns add net1
ip netns add net2
ip link add veth1 netns net1 type veth peer name veth2 netns net2

Dadurch werden zwei Namensräume, net1 und net2, und ein Paar VETH-Geräte erstellt, und veth1 wird dem Namensraum net1 und veth2 dem Namensraum net2 zugewiesen

  • Diese beiden Namespaces sind mit diesem VETH-Paar verbunden
  • Weisen Sie ein Paar IP-Adressen zu, und Sie können zwischen den beiden Namespaces pingen und kommunizieren

VCAN

Ähnlich wie die Netzwerk-Loopback-Geräte bietet der VCAN (Virtual CAN)-Treiber eine virtuelle lokale CAN (Controller Area Network)-Schnittstelle, so dass Benutzer CAN-Nachrichten über eine VCAN-Schnittstelle senden/empfangen können

  • CAN wird heutzutage hauptsächlich im Automobilbereich eingesetzt

Weitere Informationen zum CAN-Protokoll finden Sie in der Kernel-CAN-Dokumentation

Verwenden Sie einen VCAN, wenn Sie eine CAN-Protokollimplementierung auf dem lokalen Host testen möchten

So erstellen Sie einen VCAN 

ip link add dev vcan1 type vcan

VXCAN

Ähnlich wie der VETH-Treiber implementiert ein VXCAN (Virtual CAN tunnel) einen lokalen CAN-Verkehrstunnel zwischen zwei VCAN-Netzwerkgeräten

  • Wenn Sie eine VXCAN-Instanz erstellen, werden zwei VXCAN-Geräte als Paar erstellt
  • Wenn ein Ende ein Paket empfängt, erscheint das Paket auf dem Paar des Geräts und umgekehrt
  • VXCAN kann für die namensraumübergreifende Kommunikation verwendet werden

Verwenden Sie eine VXCAN-Konfiguration, wenn Sie CAN-Nachrichten über Namespaces hinweg senden wollen

So richten Sie eine VXCAN-Instanz ein 

ip netns add net1
ip netns add net2
ip link add vxcan1 netns net1 type vxcan peer name vxcan2 netns net2
Hinweis
VXCAN wird in Red Hat Enterprise Linux noch nicht unterstützt

IPOIB

Ein IPOIB-Gerät unterstützt das IP-over-InfiniBand-Protokoll

  • Dieses transportiert IP-Pakete über InfiniBand (IB), so dass Sie Ihr IB-Gerät als schnelle NIC verwenden können

Der IPoIB-Treiber unterstützt zwei Betriebsmodi: Datagramm und verbunden

  • Im Datagramm-Modus wird der IB UD-Transport (Unreliable Datagram) verwendet
  • Im Verbindungsmodus wird der IB RC (Reliable Connected)-Transport verwendet
  • Der Verbindungsmodus nutzt die Vorteile des verbundenen IB-Transports und erlaubt eine MTU bis zur maximalen IP-Paketgröße von 64K

Weitere Einzelheiten finden Sie in der IPOIB-Kerneldokumentation

Verwenden Sie ein IPOIB-Gerät, wenn Sie ein IB-Gerät haben und mit einem entfernten Host über IP kommunizieren wollen

So erstellen Sie ein IPOIB-Gerät 

# ip link add ib0 name ipoib0 type ipoib pkey IB_PKEY mode connected

NLMON

NLMON ist ein Netlink-Monitor-Gerät

Verwenden Sie ein NLMON-Gerät, wenn Sie System-Netlink-Meldungen überwachen wollen

So erstellen Sie ein NLMON-Gerät
ip link add nlmon0 type nlmon
ip link set nlmon0 up
tcpdump -i nlmon0 -w nlmsg.pcap

Damit wird ein NLMON-Gerät namens nlmon0 erstellt und eingerichtet

  • Verwenden Sie einen Packet Sniffer (z.B. tcpdump), um Netlink-Nachrichten zu erfassen
  • Neuere Versionen von Wireshark können Netlink-Nachrichten dekodieren

Dummy

Dummy-Schnittstelle

Eine Dummy-Schnittstelle ist eine rein virtuelle Schnittstelle, wie z. B. die Loopback-Schnittstelle

  • Der Zweck einer Dummy-Schnittstelle ist es, ein Gerät zur Verfügung zu stellen, durch das Pakete geleitet werden, ohne dass sie tatsächlich übertragen werden

Mit einer Dummy-Schnittstelle kann man eine inaktive SLIP-Adresse (Serial Line Internet Protocol) wie eine echte Adresse für lokale Programme aussehen lassen

  • Heutzutage wird eine Dummy-Schnittstelle meist zum Testen und Debuggen verwendet
So erstellen Sie eine Dummy-Schnittstelle
ip link add dummy1 type dummy
ip addr add 1.1.1.1/24 dev dummy1
ip link set dummy1 up

IFB

Der IFB-Treiber (Intermediate Functional Block) stellt ein Gerät zur Verfügung, das die Bündelung von Datenverkehr aus verschiedenen Quellen und das Shaping von eingehendem Datenverkehr ermöglicht, anstatt ihn zu verwerfen

Verwenden Sie eine IFB-Schnittstelle, wenn Sie den eingehenden Datenverkehr in eine Warteschlange stellen und formen wollen

So erstellen Sie eine IFB-Schnittstelle
ip link add ifb0 type ifb
ip link set ifb0 up
tc qdisc add dev ifb0 root sfq
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: u32 match u32 0 0 action mirred egress redirect dev ifb0

Dadurch wird ein IFB-Gerät mit dem Namen ifb0 erstellt und der Root-qdisc-Scheduler durch SFQ (Stochastic Fairness Queueing), einen klassenlosen Warteschlangen-Scheduler, ersetzt

  • Dann fügt er einen Ingress-qdisc-Scheduler auf eth0 hinzu und leitet den gesamten Ingress-Verkehr zu ifb0 um

Weitere Anwendungsfälle für IFB qdisc finden Sie in diesem Wiki der Linux Foundation über IFB

netdevsim

netdevsim-Schnittstelle

netdevsim ist ein simuliertes Netzwerkgerät, das zum Testen verschiedener Netzwerk-APIs verwendet wird

  • Zur Zeit konzentriert es sich besonders auf das Testen von Hardware
Offloading, tc/XDP BPF und SR-IOV

Ein netdevsim-Gerät kann wie folgt erstellt werden 

ip link add dev sim0 type netdevsim
ip link set dev sim0 up

So aktivieren Sie tc offload 

ethtool -K sim0 hw-tc-offload on

Um XDP BPF oder tc BPF Programme zu laden 

ip link set dev sim0 xdpoffload obj prog.o

So fügen Sie VFs für SR-IOV-Tests hinzu 

echo 3 > /sys/class/net/sim0/device/sriov_numvfs
ip link set sim0 vf 0 mac

Um die vf-Nummern zu ändern, müssen Sie sie zunächst vollständig deaktivieren 

echo 0 > /sys/class/net/sim0/device/sriov_numvfs
echo 5 > /sys/class/net/sim0/device/sriov_numvfs
Hinweis
netdevsim wird in RHEL standardmäßig nicht kompiliert


Anhang

Siehe auch

Dokumentation

Man-Page
Info-Pages

Links

Projekt
Weblinks
Weitere Ressourcen
  • Artikel über virtuelle Netzwerke auf dem Red Hat Developer Blog
  • Dynamische IP-Adressverwaltung im Open Virtual Network (OVN)
  • Open vSwitch ohne Root-Rechte in Red Hat Enterprise Linux
  • Open vSwitch-Artikel im Red Hat Developer Blog


Abgerufen von „https://wiki.foxtom.de/index.php?title=Linux/Netzwerk/Virtuelle_Schnittstelle&oldid=114356“