Docker Macvlan erklärt: Wann du es wirklich brauchst (und wann nicht)

Docker Macvlan: Das Netzwerk-Feature das du wahrscheinlich nicht brauchst

Du hast dutzende Docker-Container laufen und noch nie von Macvlan gehört? Kein Problem - du bist in guter Gesellschaft. In diesem Artikel erkläre ich, warum Docker’s Standard-Networking für 95% aller Fälle ausreicht, wann Macvlan wirklich sinnvoll ist, und wie du es auf dem Raspberry Pi einrichtest.

DarkWolfCave.de

Die Überraschung: Du brauchst Macvlan (wahrscheinlich) nicht

Bevor wir tief in Macvlan eintauchen, eine wichtige Erkenntnis: Die meisten Docker-Setups funktionieren perfekt ohne Macvlan.

Ich habe meine eigene Infrastruktur analysiert - dutzende Container, mehrere Server, komplexe Setups mit Traefik, Datenbanken, Home Assistant - und das Ergebnis:

Null Macvlan-Nutzung. Alles funktioniert trotzdem.

Wie kann das sein? Lass uns das verstehen.

Docker Netzwerk-Modi im Überblick

Docker bietet verschiedene Netzwerk-Treiber. Hier die wichtigsten:

Modus	Beschreibung	Container-IP	Typischer Einsatz
bridge	Standard, isoliertes Netzwerk	172.x.x.x (Docker-intern)	95% aller Container
host	Teilt Host-Netzwerk komplett	Gleiche wie Host	mDNS, Performance
macvlan	Eigene MAC + IP im physischen Netz	Echte LAN-IP (z.B. 192.168.1.x)	IoT, Legacy-Apps
ipvlan	Ähnlich macvlan, gleiche MAC	Echte LAN-IP	Cloud-Umgebungen
none	Kein Netzwerk	-	Sicherheit, Batch-Jobs

Warum Bridge-Netzwerke (fast) immer reichen

Das Geheimnis: Docker DNS

Wenn du Container im selben Netzwerk startest, können sie sich per Service-Name erreichen:

# docker-compose.yml
services:
  backend:
    image: myapp
    networks:
      - internal
    environment:
      - DB_HOST=postgres  # Nicht 172.18.0.5, sondern der NAME!
      - REDIS_HOST=redis

  postgres:
    image: postgres:16
    networks:
      - internal

  redis:
    image: redis:7
    networks:
      - internal

networks:
  internal:
    driver: bridge

Was passiert hier?

1. Docker erstellt ein internes Netzwerk (internal)
2. Alle Container bekommen IPs aus dem Bereich 172.x.x.x
3. Docker’s eingebauter DNS-Server löst Service-Namen auf
4. postgres wird zu 172.18.0.3, redis zu 172.18.0.4

Du musst keine IPs kennen! Der Name reicht.

Das Traefik-Pattern: Externe Erreichbarkeit ohne Port-Chaos

Für externen Zugriff nutzen wir einen Reverse Proxy wie Traefik:

services:
  frontend:
    image: my-frontend
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.frontend.rule=Host(`darkwolfcave.de`)"
      - "traefik.docker.network=proxy"

networks:
  proxy:
    external: true  # Traefik's Netzwerk

Das Ergebnis:

• Container hat interne IP (172.x.x.x)
• Traefik routet Traffic von außen zum Container
• Kein einziger Port nach außen exponiert
• Alles über HTTPS mit automatischen Zertifikaten

Multi-Netzwerk-Architektur

Für komplexere Setups nutze mehrere Netzwerke:

KI-BildGeneriert mit Gemini

Vorteile:

• Datenbank nicht aus dem Internet erreichbar
• Backend in beiden Netzwerken (intern + proxy)
• Klare Trennung der Zuständigkeiten

Wann Bridge NICHT reicht

Es gibt Situationen, in denen Bridge-Netzwerke an ihre Grenzen stoßen:

Problem 1: Automatische Geräteerkennung (mDNS/Bonjour)

Protokolle wie mDNS (Multicast DNS) funktionieren nur im lokalen Netzwerk-Segment:

• Philips Hue Bridge Discovery
• Chromecast/AirPlay
• Drucker-Erkennung
• Home Assistant Auto-Discovery

Bridge-Netzwerk: Container ist in 172.x.x.x - mDNS-Pakete aus dem LAN (192.168.x.x) erreichen ihn nicht.

Problem 2: Container braucht “echte” LAN-IP

Manche Anwendungen erwarten eine IP aus dem physischen Netzwerk:

• Legacy-Software die auf bestimmte IP-Bereiche prüft
• Anwendungen die ihre IP an andere Systeme melden
• Geräte die nur mit IPs aus dem lokalen Subnet kommunizieren

Problem 3: VLAN-Direktanbindung

Du willst einen Container direkt in ein VLAN setzen - nicht über Host-Routing:

• Container soll im IoT-VLAN sein
• Firewall-Regeln sollen auf Container-IP greifen
• Netzwerk-Monitoring soll Container als eigenes Gerät sehen

Die Lösungen im Vergleich

Problem	Lösung	Aufwand
mDNS-Discovery	network_mode: host	Einfach
mDNS-Discovery	Macvlan	Mittel
mDNS-Discovery	Avahi-Reflector	Einfach
Echte LAN-IP	Macvlan	Mittel
VLAN-Direktanbindung	Macvlan mit VLAN-Interface	Komplex

Lösung A: network_mode: host (Der einfache Weg)

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    network_mode: host
    privileged: true  # Nur wenn wirklich nötig!

⚠️ Sicherheitshinweis: privileged: true gibt dem Container vollen Zugriff auf das Host-System. Nutze es nur wenn unbedingt nötig (z.B. für USB-Geräte bei Home Assistant). Für reine Netzwerk-Features reicht oft network_mode: host allein.

Vorteile:

• Einfachste Lösung
• Voller Zugriff auf alle Netzwerk-Features
• mDNS, SSDP, Broadcasts funktionieren

Nachteile:

• Keine Netzwerk-Isolation
• Port-Konflikte möglich (Port 80 belegt?)
• Kein Multi-Container-Setup auf gleichen Ports
• Traefik-Labels funktionieren nicht

Lösung B: Avahi-Reflector (mDNS weiterleiten)

Statt Macvlan einen mDNS-Reflector zwischen Docker-Netzwerken und dem LAN:

services:
  avahi-reflector:
    image: flungo/avahi
    container_name: avahi-reflector
    network_mode: host
    restart: unless-stopped
    environment:
      - REFLECTOR_ENABLE_REFLECTOR=yes

💡 Hinweis: Das flungo/avahi Image ist älter, funktioniert aber noch. Alternativ kannst du Avahi direkt auf dem Host installieren (apt install avahi-daemon) und in /etc/avahi/avahi-daemon.conf den Reflector aktivieren.

Vorteile:

• Andere Container bleiben in Bridge-Netzwerk isoliert
• Nur Avahi braucht host-mode
• Saubere Trennung der Zuständigkeiten

Nachteile:

• Zusätzlicher Container/Service zu verwalten
• Funktioniert nur für mDNS - SSDP (UPnP) wird nicht reflektiert
• Manche Geräte (z.B. ältere Chromecasts) brauchen mehr als nur mDNS

Lösung C: Macvlan (Eigene IP im LAN)

Jetzt wird’s interessant. Macvlan gibt dem Container eine eigene MAC-Adresse und damit eine eigene IP im physischen Netzwerk. Das ist die mächtigste Option - aber auch die komplexeste.

Macvlan verstehen

Was passiert technisch?

Der Unterschied zwischen Bridge und Macvlan lässt sich am besten visuell verstehen:

KI-BildGeneriert mit Gemini

Bridge-Modus (Standard): Alle Container teilen sich die IP des Hosts. Der Traffic wird per NAT übersetzt - für das Netzwerk existiert nur der Pi.

Macvlan-Modus: Der Container bekommt eine eigene MAC-Adresse und erscheint als separates Gerät im Netzwerk - so als hättest du einen zweiten Raspberry Pi angeschlossen.

Der Traffic-Fluss im Detail

Modus	Container-IP	Sichtbar im LAN als	Traffic-Weg
Bridge	172.18.0.5 (intern)	Host: 192.168.1.36	Container → NAT → Host → Netzwerk
Macvlan	192.168.1.100	Eigenes Gerät: 192.168.1.100	Container → direkt → Netzwerk

Der entscheidende Punkt: Bei Bridge sieht dein Router nur den Pi. Bei Macvlan sieht er zwei separate Geräte mit unterschiedlichen MAC-Adressen.

Der große Gotcha: Host kann Container nicht erreichen!

Das überrascht fast jeden: Wenn du Macvlan nutzt, kann der Host (dein Pi) den Container nicht direkt erreichen - und umgekehrt!

# Vom Pi aus:
ping 192.168.1.100  # Container IP
# KEINE ANTWORT!

# Vom Container aus:
ping 192.168.1.36   # Host IP
# KEINE ANTWORT!

Warum? Es ist ein Linux-Kernel-Feature, keine Bug. Der Host “sieht” den Macvlan-Traffic nicht - er geht direkt an die Netzwerkkarte vorbei.

Die Lösung: Macvlan-Shim Interface

Du erstellst ein zusätzliches Macvlan-Interface auf dem Host:

# Macvlan-Shim auf dem Host erstellen
sudo ip link add macvlan-shim link eth0 type macvlan mode bridge
sudo ip addr add 192.168.1.99/32 dev macvlan-shim
sudo ip link set macvlan-shim up

# Route zum Container
sudo ip route add 192.168.1.100/32 dev macvlan-shim

Damit funktioniert:

ping 192.168.1.100  # Container
# ANTWORT!

Für permanente Konfiguration in /etc/network/interfaces.d/macvlan-shim:

auto macvlan-shim
iface macvlan-shim inet manual
    pre-up ip link add macvlan-shim link eth0 type macvlan mode bridge
    up ip addr add 192.168.1.99/32 dev macvlan-shim
    up ip link set macvlan-shim up
    post-up ip route add 192.168.1.100/32 dev macvlan-shim
    pre-down ip route del 192.168.1.100/32 dev macvlan-shim || true
    down ip link del macvlan-shim || true

Macvlan praktisch: Docker Compose Setup

Einfaches Macvlan-Netzwerk

# docker-compose.yml
services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:stable
    restart: unless-stopped
    privileged: true
    networks:
      macvlan-net:
        ipv4_address: 192.168.1.100
    volumes:
      - ./config:/config
    environment:
      - TZ=Europe/Berlin

networks:
  macvlan-net:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1
          ip_range: 192.168.1.100/32  # Nur diese eine IP für Docker

Wichtig: ip_range begrenzt welche IPs Docker vergeben darf. Ohne das könnte Docker IPs vergeben, die schon belegt sind!

Macvlan mit VLAN-Tag (IoT-VLAN)

Container direkt im VLAN 20:

networks:
  iot-macvlan:
    driver: macvlan
    driver_opts:
      parent: eth0.20  # VLAN 20 Interface
    ipam:
      config:
        - subnet: 192.168.20.0/24
          gateway: 192.168.20.1
          ip_range: 192.168.20.100/32

Voraussetzung: Das VLAN-Interface muss existieren:

# VLAN 20 Interface erstellen (falls nicht vorhanden)
sudo ip link add link eth0 name eth0.20 type vlan id 20
sudo ip link set eth0.20 up

Oder permanent in /etc/network/interfaces:

auto eth0.20
iface eth0.20 inet manual
    vlan-raw-device eth0

Hybrid-Setup: Macvlan + Bridge

Die beste Lösung für Home Assistant mit Traefik:

services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:stable
    restart: unless-stopped
    privileged: true
    networks:
      traefik_network:        # Für Traefik-Routing
      iot-macvlan:        # Für direkte IoT-Kommunikation
        ipv4_address: 192.168.20.100
    volumes:
      - ./config:/config
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.ha.rule=Host(`home.example.de`)"
      - "traefik.docker.network=traefik_network"  # Traefik nutzt Bridge!
      - "traefik.http.services.ha.loadbalancer.server.port=8123"

networks:
  traefik_network:
    external: true
  iot-macvlan:
    driver: macvlan
    driver_opts:
      parent: eth0.20
    ipam:
      config:
        - subnet: 192.168.20.0/24
          gateway: 192.168.20.1
          ip_range: 192.168.20.100/32

Das Beste aus beiden Welten:

• Traefik routet HTTPS-Traffic über Bridge
• Macvlan ermöglicht direkte IoT-Kommunikation
• Container ist in beiden Netzwerken

Macvlan vs IPvlan

Es gibt auch IPvlan - ähnlich aber mit Unterschieden:

Aspekt	Macvlan	IPvlan
MAC-Adresse	Eigene pro Container	Gleiche wie Host
Switch-Kompatibilität	Kann Probleme machen	Besser
Cloud-Provider	Oft blockiert	Meist erlaubt
Promiscuous Mode	Benötigt	Nicht benötigt
Raspberry Pi	Funktioniert	Funktioniert

Für den Raspberry Pi zu Hause: Macvlan ist die bessere Wahl.

In Cloud-VMs: IPvlan, da viele Provider MAC-Spoofing blockieren.

# IPvlan statt Macvlan
networks:
  ipvlan-net:
    driver: ipvlan
    driver_opts:
      parent: eth0
      ipvlan_mode: l2  # Layer 2 mode
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1

Entscheidungsbaum: Welches Netzwerk brauchst du?

KI-BildGeneriert mit Gemini

Troubleshooting

Container bekommt keine IP

# Prüfe ob Parent-Interface existiert
ip link show eth0

# Prüfe ob VLAN-Interface existiert (bei eth0.20)
ip link show eth0.20

# Falls VLAN fehlt:
sudo ip link add link eth0 name eth0.20 type vlan id 20
sudo ip link set eth0.20 up

Host kann Container nicht erreichen

Das Macvlan-Shim fehlt! Siehe oben: “Die Lösung: Macvlan-Shim Interface”

Container kann Internet nicht erreichen

# Prüfe Gateway im Docker-Netzwerk
docker network inspect macvlan-net | grep Gateway

# Prüfe Routing im Container
docker exec -it container_name ip route

# Gateway muss erreichbar sein!
docker exec -it container_name ping 192.168.1.1

”Address already in use”

Die IP ist schon vergeben! Prüfe:

# Welche IPs sind im Netzwerk?
nmap -sn 192.168.1.0/24

# Oder ARP-Tabelle
arp -a

Lösung: Nutze eine freie IP oder reserviere einen Bereich im DHCP.

Zusammenfassung

Szenario	Empfohlene Lösung
Standard-Container	Bridge (Default)
Extern erreichbar	Bridge + Traefik
Container-zu-Container	Bridge + Service-Namen
mDNS-Discovery (einfach)	network_mode: host
mDNS-Discovery (sauber)	Bridge + Avahi-Reflector
Echte LAN-IP benötigt	Macvlan
Container im VLAN	Macvlan + VLAN-Interface
Hybrid (Traefik + IoT)	Bridge + Macvlan dual-network

Die wichtigste Erkenntnis: Du brauchst Macvlan nur in Spezialfällen. Docker’s Bridge-Networking mit Service-Namen-DNS und Traefik als Reverse Proxy deckt 95% aller Anwendungsfälle ab.

Weiterführende Artikel

• Traefik Reverse Proxy einrichten
• Home Assistant mit Traefik und VLANs

Fragen zu Docker-Networking? Schreib in die Kommentare oder komm auf meinen Discord-Kanal.