Linux/Netzwerk/Virtuelle Schnittstelle: Unterschied zwischen den Versionen

Aus Foxwiki
Zeile 56: Zeile 56:
===== Weblinks =====
===== Weblinks =====


= TMP =  
= TMP =
== 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 <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 ==
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 <code>bond1</code> 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:
<nowiki># teamd -o -n -U -d -t team0 -c '{"runner": {"name": "activebackup"}, "link_watch": {"name": "ethtool"}}'</nowiki>
 
# 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 <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 ==
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 <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.
 
== 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.
 
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 <code>ipvl0</code> und dem Modus L2 erstellt, das dem Namensraum <code>ns0</code> 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 <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.
 
== 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, <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 ==
Ä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 <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. 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 <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.
 
Weitere Anwendungsfälle für IFB qdisc finden Sie in diesem Wiki der Linux Foundation über IFB.
 
== Zusätzliche 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
 
== 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
<code>Hinweis</code>: netdevsim wird in RHEL standardmäßig nicht kompiliert
</noinclude>

Version vom 9. August 2024, 08:57 Uhr

topic - Kurzbeschreibung

Beschreibung

Linux-Schnittstellen für virtuelle Netzwerke

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 ip link help abgerufen werden.

Dieser Beitrag behandelt die folgenden häufig verwendeten Schnittstellen und einige Schnittstellen, die leicht miteinander verwechselt werden können:

  • 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-Schnittstelle
  • IFB (Intermediate Functional Block)
  • netdevsim

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

Syntax

Optionen

Parameter

Umgebungsvariablen

Exit-Status

Anwendung

Fehlerbehebung

Konfiguration

Dateien

Anhang

Siehe auch

Dokumentation

RFC
RFC Titel
0000
Man-Pages
Info-Pages

Links

Projekt
Weblinks

TMP