Macvlan-Netzwerke: Einsatzgebiete und Grenzen

1. Was ein Macvlan-Netzwerk technisch ist

Ein Macvlan-Netzwerk weist jedem angeschlossenen Container eine eigene, virtuelle MAC-Adresse zu, die auf dem physischen Netzwerk-Interface des Hosts aufsetzt. Aus Sicht des restlichen LANs erscheint der Container dadurch wie ein eigenständiges physisches Gerät mit eigener Ethernet-Adresse, nicht wie ein Prozess, der sich einen Host teilt. Das unterscheidet ein Macvlan-Netzwerk fundamental von einem Bridge-Netzwerk, bei dem alle Container hinter der IP-Adresse des Hosts per NAT versteckt bleiben.

Technisch nutzt Docker dafür den Linux-Kernel-Treiber macvlan, der auf einem physischen Parent-Interface mehrere virtuelle Interfaces mit jeweils eigener MAC-Adresse erzeugt. Jedes dieser virtuellen Interfaces wird einem Container zugewiesen und bekommt über DHCP oder eine feste Zuweisung eine reguläre IP-Adresse aus dem physischen Subnetz des LANs. Damit ist ein Macvlan-Netzwerk die direkteste Methode, einen Container als vollwertiges Gerät im bestehenden Netzwerk erscheinen zu lassen, ohne Port-Weiterleitungen oder NAT-Regeln zu benötigen.

2. Wann Macvlan die richtige Wahl ist

Der klassische Anwendungsfall für ein Macvlan-Netzwerk ist die Migration einer Legacy-Anwendung in einen Container, die zwingend eine eigene, feste IP-Adresse im Firmennetz braucht, weil andere Systeme genau diese IP in ihrer Konfiguration erwarten. Statt die Anwendung umzuschreiben, damit sie mit Port-Mapping funktioniert, bekommt der Container über Macvlan einfach die erwartete IP-Adresse zugewiesen und fügt sich nahtlos in bestehende Firewall-Regeln und Monitoring-Systeme ein.

Ein zweiter häufiger Einsatzzweck ist Netzwerk-Monitoring und Security-Tooling, das direkten Zugriff auf Layer-2-Informationen wie ARP-Anfragen oder Broadcast-Traffic benötigt, was hinter einer NAT-basierten Bridge nicht sichtbar wäre. Auch Multicast-Anwendungen und Geräte-Simulationen, bei denen ein Container ein bestimmtes physisches Gerät im Netzwerk vortäuschen soll, profitieren von einem Macvlan-Netzwerk, weil es echte Layer-2-Sichtbarkeit liefert statt der abstrahierten Sicht eines Bridge-Netzwerks.

3. Ein Macvlan-Netzwerk erstellen

Die Erstellung eines Macvlan-Netzwerks erfordert die Angabe des physischen Parent-Interfaces, also der Netzwerkkarte des Hosts, an die die virtuellen Interfaces gebunden werden. Zusätzlich müssen Subnetz und Gateway des physischen LANs angegeben werden, damit Docker weiß, in welchem Adressbereich sich die Container bewegen. Anders als bei einem Bridge-Netzwerk erfindet Docker hier kein eigenes Subnetz, sondern nutzt exakt das bestehende Netzwerk der physischen Infrastruktur.

Wichtig ist, dass das gewählte Parent-Interface tatsächlich mit dem gewünschten LAN-Segment verbunden ist, sonst erhalten Container zwar eine IP-Adresse, sind aber im falschen Netzwerksegment isoliert. Bei Servern mit mehreren Netzwerkkarten oder VLAN-Trunks muss das richtige Interface explizit ausgewählt werden, was in der Praxis der häufigste Stolperstein beim ersten Einrichten eines Macvlan-Netzwerks ist.

# Identify the physical parent interface first
ip link show

# Create a macvlan network bound to the physical interface eth0
docker network create -d macvlan \
  --subnet 192.168.10.0/24 \
  --gateway 192.168.10.1 \
  -o parent=eth0 \
  lan-macvlan

# Inspect the network to confirm subnet and parent interface
docker network inspect lan-macvlan

4. Container mit eigener LAN-IP starten

Sobald das Macvlan-Netzwerk existiert, wird ein Container einfach mit --network und optional einer festen IP-Adresse gestartet. Der Container ist danach direkt aus dem gesamten LAN unter dieser Adresse erreichbar, ohne dass am Docker-Host ein Port veröffentlicht werden musste. Andere Geräte im Netzwerk sehen den Container als eigenständigen Netzwerkteilnehmer mit eigener MAC-Adresse, was bei ARP-Anfragen und in Netzwerk-Scans klar sichtbar wird.

Für DNS-Einträge in der internen Namensauflösung des Unternehmens bedeutet das: der Container kann wie ein reguläres Gerät im DNS-Server der Firma eingetragen werden, mit fester IP-Adresse und eigenem Hostnamen. Das ist ein deutlicher Unterschied zu einem Bridge-Netzwerk, bei dem der Container nur über den Host und dessen Ports von außen erreichbar wäre. Ein Macvlan-Netzwerk macht die Container-zu-Gerät-Transformation im Netzwerk vollständig, statt sie hinter einer NAT-Schicht zu verstecken.

# Start a container with a fixed LAN IP on the macvlan network
docker run -d --name legacy-app \
  --network lan-macvlan \
  --ip 192.168.10.50 \
  --mac-address 02:42:c0:a8:0a:32 \
  legacy-app:latest

# From another device on the LAN, the container answers like a real host
ping -c 2 192.168.10.50
arp -a | grep 192.168.10.50

5. Das Promiscuous-Mode-Problem bei Host-Kommunikation

Die bekannteste Einschränkung eines Macvlan-Netzwerks betrifft die direkte Kommunikation zwischen dem Docker-Host selbst und den Containern, die auf demselben Parent-Interface laufen. Der Linux-Kernel verhindert standardmäßig, dass der Host-Netzwerk-Stack Pakete an Macvlan-Interfaces sendet, die auf demselben physischen Interface aufsetzen, aus dem Host abgeleitet wurden. In der Praxis bedeutet das: der Host kann Container in seinem eigenen Macvlan-Netzwerk nicht per Ping erreichen, obwohl alle anderen Geräte im LAN das problemlos können.

Die gängige Lösung ist, ein zusätzliches Macvlan-Subinterface direkt auf dem Host anzulegen, das derselben physischen Netzwerkkarte zugeordnet ist, aber als separater Netzwerkteilnehmer agiert. Über dieses Subinterface kann der Host dann mit seinen eigenen Containern im Macvlan-Netzwerk kommunizieren. Diese zusätzliche Konfiguration wird oft übersehen und führt zu Verwirrung, wenn Health-Checks vom Host aus fehlschlagen, während der Container selbst korrekt funktioniert und von außen erreichbar ist.

# Create a macvlan sub-interface on the host to talk to its own containers
ip link add macvlan-shim link eth0 type macvlan mode bridge
ip addr add 192.168.10.5/24 dev macvlan-shim
ip link set macvlan-shim up

# Route traffic to the macvlan subnet through the shim interface
ip route add 192.168.10.0/24 dev macvlan-shim

# The host can now reach containers in the macvlan network
ping -c 2 192.168.10.50

6. VLANs mit Macvlan-Subinterfaces abbilden

In Umgebungen mit VLAN-Segmentierung lässt sich ein Macvlan-Netzwerk direkt an ein 802.1Q-Subinterface binden, statt an die physische Netzwerkkarte selbst. Dazu wird zunächst ein VLAN-Subinterface auf dem Host angelegt, das den entsprechenden VLAN-Tag trägt, und dieses Subinterface anschließend als Parent-Interface für das Macvlan-Netzwerk verwendet. So lassen sich Container gezielt einem bestimmten VLAN zuordnen, ohne dass der gesamte Trunk-Traffic auf dem Host sichtbar sein muss.

Das ist besonders wertvoll in Umgebungen, in denen unterschiedliche Kundenumgebungen oder Sicherheitszonen über VLANs voneinander getrennt sind. Ein Docker-Host kann so mehrere Macvlan-Netzwerke parallel betreiben, jedes gebunden an ein eigenes VLAN-Subinterface, und Container gezielt dem passenden Segment zuweisen. Docker selbst muss dabei nichts vom VLAN-Tagging wissen, die gesamte Kapselung passiert bereits auf Kernel-Ebene, bevor der Traffic überhaupt beim Macvlan-Treiber ankommt.

# Create a VLAN sub-interface for VLAN ID 20 on eth0
ip link add link eth0 name eth0.20 type vlan id 20
ip link set eth0.20 up

# Bind a macvlan network to the VLAN sub-interface instead of eth0
docker network create -d macvlan \
  --subnet 192.168.20.0/24 \
  --gateway 192.168.20.1 \
  -o parent=eth0.20 \
  vlan20-macvlan

7. Sicherheit und Netzwerksegmentierung mit Macvlan

Ein Macvlan-Netzwerk bringt Container auf dieselbe Sichtbarkeitsebene wie physische Geräte im LAN, was Vor- und Nachteile für die Sicherheit hat. Der Vorteil: bestehende Netzwerk-Firewalls, IDS-Systeme und Access-Control-Listen greifen direkt auf Container-Traffic, ohne dass Docker-spezifische NAT-Regeln umgangen werden müssten. Der Nachteil: ein Container im Macvlan-Netzwerk ist genauso im gesamten LAN sichtbar wie jedes andere Gerät, was die Isolationsvorteile eines Bridge-Netzwerks aufhebt.

Wer ein Macvlan-Netzwerk produktiv einsetzt, sollte die physische Netzwerksegmentierung, etwa über VLANs, konsequent nutzen, um Container nicht ungewollt im selben Segment wie sensible interne Systeme zu platzieren. Da Docker selbst keine Firewall-Regeln zwischen Containern im selben Macvlan-Segment durchsetzt, liegt die gesamte Verantwortung für die Segmentierung bei der physischen Netzwerkinfrastruktur, nicht bei Docker.

8. Grenzen von Macvlan in der Praxis

Die größte praktische Grenze eines Macvlan-Netzwerks zeigt sich in Cloud-Umgebungen. Die meisten Cloud-Provider filtern Traffic mit unbekannten MAC-Adressen auf ihren virtuellen Switches, um Spoofing zu verhindern, was ein Macvlan-Netzwerk in solchen Umgebungen faktisch unbrauchbar macht, sofern der Provider keine explizite Ausnahme erlaubt. Das beschränkt Macvlan weitgehend auf On-Premise-Umgebungen mit physischem Netzwerkzugriff.

Auch die Portabilität leidet: ein Compose-Setup mit Macvlan-Netzwerk lässt sich nicht einfach auf eine andere Maschine kopieren, weil Parent-Interface, Subnetz und Gateway host-spezifisch konfiguriert sind. Der Promiscuous-Mode-Workaround aus Abschnitt fünf erhöht zusätzlich den Wartungsaufwand. In der Praxis bleibt ein Macvlan-Netzwerk deshalb die Ausnahme für spezifische Legacy- und Monitoring-Anforderungen, während die Mehrheit der Container-Workloads mit einem gewöhnlichen Bridge-Netzwerk deutlich einfacher und portabler bleibt.

# Quick check whether macvlan traffic actually leaves the host
# (run from another device on the same LAN segment)
tcpdump -i eth0 -n host 192.168.10.50

# List all macvlan networks currently configured on this host
docker network ls --filter driver=macvlan

# Remove a macvlan network no longer needed (detach containers first)
docker network rm lan-macvlan

9. Macvlan, Bridge und Host-Netzwerk im Vergleich

Die folgende Tabelle stellt die drei wichtigsten Docker-Netzwerktreiber für Single-Host-Szenarien gegenüber und zeigt, wofür ein Macvlan-Netzwerk im Vergleich zu Bridge und Host-Netzwerk tatsächlich geeignet ist.

Diese Gegenüberstellung macht deutlich, dass ein Macvlan-Netzwerk eine gezielte Speziallösung ist, keine allgemeine Empfehlung für neue Projekte. Wer keine der genannten Anforderungen an eigene LAN-Sichtbarkeit hat, fährt mit einem regulären Bridge-Netzwerk in fast allen Fällen einfacher und portabler.

10. Zusammenfassung

Ein Macvlan-Netzwerk gibt Docker-Containern eine echte, im physischen LAN sichtbare IP- und MAC-Adresse, ganz ohne Port-Mapping über den Host. Das löst konkrete Probleme bei Legacy-Anwendungen mit hartcodierten IP-Erwartungen, bei Netzwerk-Monitoring auf Layer 2 und bei der Abbildung von VLAN-Segmenten über Macvlan-Subinterfaces. Die bekannteste Einschränkung ist die fehlende direkte Kommunikation zwischen Host und Container im selben Macvlan-Netzwerk, die einen zusätzlichen Subinterface-Workaround erfordert.

In Cloud-Umgebungen scheitert ein Macvlan-Netzwerk meist an der MAC-Adress-Filterung der virtuellen Switches, was den praktischen Einsatz auf On-Premise-Infrastruktur mit physischem Netzwerkzugriff beschränkt. Wer keine der genannten Spezialanforderungen hat, sollte bei einem regulären Bridge-Netzwerk bleiben, das portabler, einfacher zu warten und in jeder Umgebung verfügbar ist. Macvlan bleibt damit ein gezieltes Werkzeug für spezifische Netzwerkanforderungen, keine allgemeine Empfehlung für neue Container-Projekte.

11. FAQ: Macvlan-Netzwerke