Tag: mtu

Es gibt so Momente in der Karierre als Entwickler/DevOp, bei denen man sich fragt, ob man nicht mehr ganz Dicht ist und überhaupt keine Ahnung hat, was man eigentlich tut.

Genau so einen Moment hatte ich diese Woche mit einem Kollegen, als unser Docker Swarm Stack ein sehr komisches Verhalten zeigte. Wir haben eine simple Webapp mit einer extra API, Datenbanken, Storage usw. dahinter und lassen die Systeme mittels Nginx Reverse Proxy miteinander reden. All das funktionierte wunderbar, aber aus unerfindlichen Gründen wurde von der React Website nur der HTML Teil ausgeliefert, aber das Laden der komprimierten CSS und JS schlug fehl. Natürlich schießt einem da gleich in den Kopf, dass es vielleicht ein Permission Problem ist, oder dass die Dateien in einem Unterordner liegen. Vielleicht ist Nginx hinter einem anderen Nginx ein Problem usw. Wir haben sogar den Webserver ausgetauscht weil uns die Lösung nicht einfallen wollte.

Irgendwann kam ich auf die Idee, die funktionierende index.html Datei einfach in den Dateinamen der komprimierten CSS sowie der komprimierten JS umzubenennen und auf einmal konnte ich beide Dateien ohne Probleme abrufen. Sprich, es konnte nicht am Dateityp oder Pfad liegen, sondern es war relativ schnell klar, dass die Größe der Datei scheinbar einen Einfluss auf das Verhalten hat.

Nach etwas Google Magic hatten wir dann herausgefunden, dass scheinbar die MTU der Netzwerkinterfaces das Problem verursacht.

Kurzer Exkurs:
Die MTU ist eine Abkürzung für “Maximum Transmission Unit” und steht für die maximale Größe eines Pakets, das über ein Netzwerk gesendet werden kann, ohne fragmentiert zu werden. In einfacheren Worten bedeutet dies, dass MTU die maximale Größe eines Datenpakets ist, das über das Netzwerk gesendet werden kann, ohne in kleinere Teile aufgeteilt zu werden. Wenn ein Paket größer als die MTU-Einstellung ist, muss es in kleinere Pakete aufgeteilt werden, um über das Netzwerk gesendet zu werden. Zum Beispiel beträgt die Standard-MTU für Ethernet 1500 Bytes. Wenn ein Paket größer als 1500 Bytes ist, wird es in kleinere Pakete aufgeteilt, um über das Netzwerk gesendet zu werden.

Problematisch wird es, wenn Netzwerkinterfaces unterschiedliche MTU verwenden, in unserem speziellen Fall die virtuellen Netzwerk Interfaces von Docker (Swarm) sowie die Netzwerkschnittstellen des Servers selbst. Denn bei virtualisierter Hardware, wie sie viele Cloud Anbieter nutzen (speziell wenn OpenStack oder auch Qemu zum Einsatz kommt), kann es sein, dass die MTU dieser virtuellen Netzwerkschnittstellen geringer als die Default 1500 Bytes ist. Ich habe es so verstanden dass die virtualisierung sich hier einfach 50 Bytes nimmt und diese für Verschlüsselung usw verwendet.

Prüfen kann man das einfach mittels

ip link

auf der Linux Shell und bekommt dann folgende Ausgabe:

1: lo:  mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1400 qdisc pfifo_fast qlen 1000
link/ether 00:0f:ea:91:04:07 brd ff:ff:ff:ff:ff:ff
3: docker0:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 00:0f:ea:91:04:08 brd ff:ff:ff:ff:ff:ff

Wenn ihr so eine Konstellation vorfindet, also dass die MTU eures Netzwerkinterfaces (eth0 in diesem Fall) KLEINER ist als der Wert, der bei docker0 steht, dann könnte ein Problem bestehen.

Da das virtuelle Docker Interface auf der “echten” Hardware aufsetzt, muss dessen MTU gleich oder kleiner der MTU des Netzwerk-Interfaces sein.

Man kann nun einfach versuchen, die MTU mittels

ip link set dev eth0 mtu 1500

setzen und das Problem ist gelöst. In meinem Fall ging das aber nicht, da das virtuelle Netzwerkinterface keinen höheren Wert erlaubte.

Also mussten wir anders heran gehen und Docker dazu zwingen, nicht seinen Default Wert von 1500 zu nehmen, sondern einen geringeren Wert. Dazu gibt es zwei Punkte, an denen man ansetzen kann.

Zum einen kann man in der Datei /etc/docker/daemon.json den Wert

{
"mtu": 1400
}

setzen, den Docker Service neu starten und wird dann sehen, dass die MTU von docker0 sich entsprechend geändert hat. Dies bringt aber nur etwas, wenn man Docker als Single Node betreibt.

Wenn man aber Docker Swarm einsetzt (evtl passiert das auch im Kubernetes Umfeld, da bin ich nicht ganz sicher), dann reicht das nicht aus. Denn dann verwendet Docker virtuelle Netzwerke, die jeweils eigene virtuelle Interfaces anlegen. Ausserdem sind zwei Netzwerke standardmäßig auf allen Nodes vorhanden:

ingress
docker_gwbridge

Wir haben es folgendermaßen gelöst:
Bevor eine Node dem Docker Swarm beitritt, löschen wir ihr docker_gwbridge und setzen es so neu auf:

docker network create \
--subnet 10.11.0.0/16 \
--opt com.docker.network.bridge.name=docker_gwbridge \
--opt com.docker.network.bridge.enable_icc=false \
--opt com.docker.network.bridge.enable_ip_masquerade=true \
docker_gwbridge

Wichtig: “docker_gwbridge” wird zwar vom Typ lokal angezeigt, es ist aber DAS Netzwerk über welches die Swarm Nodes/Docker Daemons miteinander sprechen!

Anschließend lassen wir die Nodes dem Docker Swarm beitreten. Nachdem alle Nodes drin sind, haben wir auf der Swarm Manage Node das Ingress Netzwerk gelöscht (wahrscheinlich reicht es auch, dass der Swarm erstmal initialisiert wurde) und dann mittels folgendem Befehl neu angelegt:

docker network create -d overlay --ingress --opt com.docker.network.driver.mtu=1400 ingress

Dieses neue Ingress Netzwerk ist dann erstmal nur auf der Master Node des Swarms sichtbar, wird auf den anderen Nodes aber dymanisch erzeugt, sobald der erste Container darauf deployed wird. Wenn aktuell kein Container aus dem Swarm auf dieser Node läuft, verschwindet das Ingress Netzwerk wieder von der Node bzw. wird von ihr gelöscht!

Anschließend haben wir den Swarm Stack deployed und schon konnten alle Services wieder miteinander sprechen und auch größere Datein konnten ohne Probleme ausgetauscht werden.