Container-Netzwerke: Bridge, macvlan und Overlay im Vergleich

1. Wie das Standard-Bridge-Netzwerk funktioniert

Der Bridge Treiber ist bei Docker und Podman der Standard und basiert auf einer Linux Bridge, einem virtuellen Layer 2 Switch im Kernel, an den jeder Container über ein virtuelles Ethernet Paar (veth) angebunden wird. Eine Seite des veth Paars steckt im Network Namespace des Containers als eth0, die andere Seite hängt als Port an der Bridge auf dem Host, üblicherweise docker0 oder eine benutzerdefinierte Bridge pro Netzwerk.

Container innerhalb derselben Bridge erhalten private IP Adressen aus einem intern verwalteten Subnetz und erreichen sich untereinander direkt über Layer 2, während der Zugriff nach außen über NAT läuft: Der Host übersetzt ausgehenden Traffic per iptables MASQUERADE Regel auf seine eigene IP, und eingehender Traffic muss über explizites Port Publishing (-p 8080:80) durchgereicht werden. Das ist einfach einzurichten und funktioniert praktisch überall, kostet aber bei jedem Paket eine zusätzliche NAT Übersetzung und verbirgt die tatsächliche Container IP vor dem restlichen Netzwerk.

# Benutzerdefiniertes Bridge Netzwerk anlegen und Container anbinden
docker network create --driver bridge --subnet 172.20.0.0/24 shop-net
docker run -d --name shop-php --network shop-net -p 127.0.0.1:9000:9000 php-fpm:8.4

# Bridge und veth Paare auf dem Host inspizieren
ip link show type bridge
bridge link show

2. macvlan: Eigene MAC-Adresse und eigene IP im physischen Netz

Der macvlan Treiber verzichtet komplett auf NAT und die interne Bridge: Jeder Container erhält eine eigene, vom Kernel generierte MAC Adresse und hängt darüber direkt am physischen Netzwerk Interface des Hosts, als wäre er ein eigenständiges Gerät im selben Subnetz. Damit lässt sich dem Container eine reguläre IP Adresse aus dem produktiven Netzwerk zuweisen, sichtbar und erreichbar für jeden anderen Host im selben Layer 2 Segment, ganz ohne Port Publishing oder NAT Übersetzung.

Das eliminiert den NAT Overhead vollständig und macht Container im Netzwerk Monitoring genauso sichtbar wie physische Server, was in regulierten Umgebungen mit strikten Firewall Regeln pro IP oft explizit gefordert ist. Der Preis ist geringere Flexibilität: macvlan Container können in den meisten Standardkonfigurationen nicht direkt mit dem Host selbst kommunizieren, weil der Kernel Traffic zwischen dem physischen Interface und dessen eigenen macvlan Kindern standardmäßig blockiert, ein als macvlan Bridge Isolation bekanntes Verhalten, das sich nur mit einem zusätzlichen macvlan Interface auf dem Host umgehen lässt.

# macvlan Netzwerk direkt am physischen Interface eth0 anlegen
docker network create -d macvlan \
  --subnet=192.168.10.0/24 --gateway=192.168.10.1 \
  -o parent=eth0 shop-macvlan

# Container mit fester IP aus dem produktiven Subnetz starten
docker run -d --name shop-web --network shop-macvlan \
  --ip=192.168.10.50 nginx:1.27-alpine

3. Der macvlan-Host-Kommunikationsfallstrick und seine Lösung

Weil der Host per Kernel Design nicht direkt mit seinen eigenen macvlan Kindern sprechen kann, scheitert ein naiver ping vom Host auf einen macvlan Container regelmäßig, was in der Praxis für Verwirrung sorgt, weil derselbe Container von jedem anderen Host im Netzwerk problemlos erreichbar ist. Die Standardlösung besteht darin, auf dem Host selbst ein zusätzliches macvlan Interface anzulegen, das im selben Subnetz liegt, aber als separates Layer 2 Gerät behandelt wird.

Dieses zusätzliche Interface erhält eine eigene IP außerhalb des Container Bereichs und kommuniziert dann korrekt sowohl mit dem Host als auch mit sämtlichen macvlan Containern, weil der Traffic in diesem Fall tatsächlich über das physische Netzwerk läuft statt intern im Kernel kurzgeschlossen zu werden. Für Monitoring Systeme, die vom selben Host aus Health Checks gegen Container IPs durchführen müssen, ist dieser Workaround in der Praxis unverzichtbar.

# Zusätzliches macvlan Interface auf dem Host für Host-Container Kommunikation
sudo ip link add macvlan-shim link eth0 type macvlan mode bridge
sudo ip addr add 192.168.10.9/24 dev macvlan-shim
sudo ip link set macvlan-shim up

# Jetzt vom Host aus erreichbar
ping -c1 192.168.10.50

4. Overlay-Netzwerke für Multi-Host-Kommunikation

Sowohl Bridge als auch macvlan sind grundsätzlich auf einen einzelnen Host beschränkt: Container auf unterschiedlichen Maschinen können sich über diese Treiber nicht direkt erreichen, es sei denn, der Host selbst leitet Traffic explizit weiter. Overlay Netzwerke lösen dieses Problem, indem sie ein virtuelles Layer 2 Netzwerk über mehrere physische Hosts hinweg aufspannen, technisch realisiert über VXLAN Kapselung, bei der jedes Layer 2 Frame in ein UDP Paket verpackt und über das darunterliegende physische Netzwerk zum Ziel Host transportiert wird.

In Docker Swarm oder Kubernetes übernimmt der Overlay Treiber diese Kapselung transparent: Container auf Host A und Host B, die demselben Overlay Netzwerk angehören, sehen sich gegenseitig als wären sie im selben lokalen Subnetz, unabhängig davon, über wie viele physische Netzwerksegmente der tatsächliche Traffic läuft. Das erfordert zusätzlich einen Key Value Store oder eingebauten Gossip Mechanismus zur Synchronisation der Netzwerkzustände zwischen den beteiligten Hosts.

# Overlay Netzwerk in einem Docker Swarm Verbund anlegen
docker network create -d overlay --attachable shop-overlay

# Service auf mehreren Nodes im selben Overlay Netzwerk deployen
docker service create --name shop-api \
  --network shop-overlay --replicas 3 shop-api:latest

5. VXLAN-Kapselung im Detail und ihre Kosten

Jedes Paket, das ein Overlay Netzwerk verlässt, wird vom sendenden Host in einen VXLAN Header eingepackt, der eine 24 Bit Netzwerk Kennung (VNI) sowie Quell und Ziel Informationen für den Tunnel enthält, bevor es als reguläres UDP Paket über Port 4789 an den Ziel Host geschickt wird. Der empfangende Host entpackt das Paket wieder und reicht das ursprüngliche Layer 2 Frame an den lokalen Container weiter, für den es bestimmt war.

Diese Kapselung kostet pro Paket etwa 50 Byte zusätzlichen Overhead und erzwingt eine kleinere effektive MTU als bei einer direkten Bridge Verbindung, was bei falsch konfigurierten Netzwerken zu Fragmentierung und spürbaren Performance Einbußen führen kann. In der Praxis empfiehlt es sich, die MTU auf beteiligten Interfaces explizit auf einen Wert wie 1450 statt der Standard 1500 zu setzen, um Fragmentierung von vornherein zu vermeiden.

# VXLAN Overhead durch reduzierte MTU auf dem Overlay Interface kompensieren
ip link set dev docker_gwbridge mtu 1450

# VXLAN Traffic auf dem Host mitschneiden zur Fehlersuche
sudo tcpdump -i eth0 udp port 4789 -nn

6. Performance-Unterschiede zwischen den drei Modellen

In Latenz und Durchsatz Messungen liegt macvlan durchweg am nächsten am nativen Host Netzwerk, weil weder NAT Übersetzung noch Tunnel Kapselung anfällt: Pakete verlassen den Container praktisch ungehindert über das physische Interface. Das Standard Bridge Netzwerk verliert durch die zusätzliche NAT Übersetzung und den iptables Verarbeitungsaufwand pro Paket messbar an Durchsatz, insbesondere bei sehr hohen Paketraten mit vielen kleinen Paketen, wie sie etwa bei Redis oder Memcached Workloads typisch sind.

Overlay Netzwerke zeigen den größten Overhead, weil zur NAT ähnlichen Verarbeitung noch die VXLAN Kapselung und Entkapselung auf beiden Seiten hinzukommt. Für Workloads mit hohem Netzwerk Durchsatz zwischen Hosts, etwa Datenbank Replikation oder große Datei Transfers zwischen Services, sollte diese zusätzliche Latenz explizit eingeplant werden, wenn keine dedizierte Hardware Beschleunigung wie VXLAN Offloading auf der Netzwerkkarte zur Verfügung steht.

7. Sicherheitsaspekte der drei Netzwerkmodelle

Beim Bridge Modell profitieren Container implizit von der NAT Isolation: Eingehender Traffic aus dem externen Netzwerk erreicht einen Container ausschließlich über explizit publizierte Ports, alles andere wird vom Host verworfen, bevor es überhaupt einen Container erreicht. Diese eingebaute Sicherheitsgrenze entfällt bei macvlan vollständig, weil jeder Container als eigenständiges Gerät im Netzwerk erscheint und deshalb genauso von externen Firewall Regeln oder Netzwerksegmentierung geschützt werden muss wie ein physischer Server.

Bei Overlay Netzwerken ist die Verschlüsselung des Tunnel Traffics ein oft übersehener Punkt: Docker Swarm bietet optionale IPsec Verschlüsselung für Overlay Netzwerke über das Flag --opt encrypted, die standardmäßig jedoch deaktiviert ist. Wer Overlay Netzwerke über ein nicht vollständig vertrauenswürdiges physisches Netzwerk betreibt, etwa zwischen Rechenzentren über eine gemietete Verbindung, sollte diese Verschlüsselung explizit aktivieren, da VXLAN Traffic sonst unverschlüsselt über die zugrunde liegende Infrastruktur läuft.

# Verschluesseltes Overlay Netzwerk für Traffic zwischen Rechenzentren
docker network create -d overlay --opt encrypted --attachable secure-overlay

8. DNS und Service Discovery je Netzwerkmodell

Im Standard Bridge Netzwerk lösen Container Namen anderer Container über einen eingebauten DNS Server auf, den Docker und Podman auf einer internen Adresse innerhalb des jeweiligen Netzwerks bereitstellen, sodass ein Dienst einen anderen einfach über dessen Containername statt über eine fest verdrahtete IP erreichen kann. Diese Namensauflösung funktioniert automatisch für alle Container im selben benutzerdefinierten Bridge Netzwerk, jedoch nicht im veralteten Default Bridge Netzwerk ohne eigenen Namen, wo weiterhin nur die Verknüpfung über explizite Links funktioniert.

Bei macvlan entfällt diese eingebaute Namensauflösung, weil Container hier wie eigenständige Geräte im physischen Netzwerk auftreten und deshalb dieselbe DNS Infrastruktur wie andere Server im Netz benötigen, etwa einen zentralen internen DNS Dienst oder statische Hosts Einträge. Overlay Netzwerke bringen wiederum eine eigene, Cluster weite Namensauflösung mit, die Dienste über mehrere Hosts hinweg konsistent auflöst, was für Multi Host Setups mit dynamisch skalierenden Services ein entscheidender Vorteil gegenüber reinem macvlan ist.

# Interne DNS Aufloesung im Bridge Netzwerk testen
docker exec shop-php getent hosts shop-db

# Overlay Service über seinen Namen aus einem anderen Container erreichen
docker exec shop-api getent hosts shop-cache

9. Praxisempfehlung für Magento-Hosting-Umgebungen

Für einen klassischen Single Host Magento Stack aus PHP FPM, Nginx, MySQL und Redis ist das Standard Bridge Netzwerk fast immer die richtige Wahl: Die interne Kommunikation zwischen den Services bleibt vollständig innerhalb des Hosts, NAT Overhead spielt bei diesen Paketraten kaum eine Rolle, und die eingebaute Isolation reduziert die externe Angriffsfläche auf explizit veröffentlichte Ports wie 443.

macvlan lohnt sich dagegen gezielt für einzelne Services, die im internen Netzwerk mit einer eigenen, festen IP sichtbar sein müssen, etwa ein dediziertes Monitoring Interface oder ein Legacy System, das IP basierte Zugriffskontrolle voraussetzt statt Port basierter Regeln. Overlay Netzwerke werden erst relevant, sobald der Stack über mehrere physische oder virtuelle Hosts verteilt wird, etwa bei einem Cluster mit getrennten Datenbank und Applikations Nodes, wo die Multi Host Transparenz den zusätzlichen VXLAN Overhead in aller Regel rechtfertigt.

10. Zusammenfassung

11. FAQ: Container-Netzwerke