MTU

Die Maximum Transmission Unit (MTU) beschreibt die maximale Paketgröße eines Protokolls auf Layer 3 (IP). Diese in der MTU angegebene Paketgröße passt also genau in die Payload eines Layer 2 Protokolls (Beispielsweise Ethernet).

MTU bei Tunneln

Da das Tunnelprotokoll in ein anderes IP bzw. UDP Paket eingefügt wird, verringert sich die maximale Paketgröße innerhalb des Tunnels. Hierbei muss darauf geachtet werden, dass eine passende MTU gewählt wird, damit die äußeren Pakete nicht fragmentiert werden müssen, weil sie zu groß sind. Weiterhin kann der Linux-Kernel Wireguard aktuell überhaupt nicht fragmentieren, daher geht Wireguard mit zu großer MTU innerhalb des Tunnels ganz kaputt.

Generell sollte die MTU immer auf beiden Seiten gleich sein. Auch wenn es erstmal kein Problem ist, wenn sie unterschiedlich ist, solange an beiden Seite klein genug für die Leitung.

Das ganze kann man sich leicht ausrechnen. Zuerst braucht man die MTU des Transportweges. Die kann man entweder ausmessen, oder man weiß sie schon. Bei einem typischen DSL ist das normalerweise 1492, bei Cable (DOCSIS) 1500 Bytes.

Dann muss man den Overhead von allem, was zwischen Transportweg und den "inneren" Paketen liegt abziehen. Beispiel Wireguard: - IPv4 (20 Bytes) oder IPv6 (40 Bytes) - UDP (8 Bytes) - Wireguard Overhead (32 Bytes)

Somit kommt man bei "normaler" MTU (1500) auf dem Transportweg und IPv6 als Transportprotokoll (als das _worüber_ der Tunnel aufgebaut wird) auf die "magischen" 1420 Bytes, die ja auch Standard sind.

MTU Probleme bei Tunneln

MTU innerhalb des Tunnels zu groß

Wie oben bereits erwähnt, kann es problematisch sein, die MTU innerhalb des Tunnels zu groß zu wählen.

Normalerweise sollten zu große Pakete von der Tunnelsoftware fragmentiert werden. Allerdings kann das nicht jede Software. GRE und Wireguard können dies nicht, daher gehen Verbindungen mit großen Paketen innerhalb des Tunnel dann häufig kaputt und Seiten laden (teilweise) nicht.

PMTUD funktioniert nicht

Damit Clients überhaupt wissen können, dass die MTU auf dem Weg plötzlich kleiner wird, müssen Router passende Fehlerpakete (ICMP) senden können. Diese teilen dann dem Client mit, dass er seine Pakete kleiner machen muss. Das betroffene Paket wird vom Router verworfen.

Bei IPv4 wurde hier (ohne extra Flags) vom Router fragmentiert. Nur wenn der Client explizit danach fragte (Don't Fragment Flag), wurden Pakete verworfen und ICMP Fehler gesendet. Heute wird aber so gut wie alles mit DF-Flag gesendet, daher gilt für IPv4 mittlerweile das gleiche, wie für IPv6 (dort gibt es ein solches Flag nicht, Pakete werden NIE von Routern fragmentiert)

Testen kann man das ganze leicht mit einem Traceroute. Dort muss (in beide Richtungen!) jeder Router ICMP Pakete (traceroute forciert das Senden von Fehlerpaketen durch eine stark limitierte TTL) antworten können, bei dem ein Übergang von einem MTU-technisch größeren zu einem kleineren Link stattfindet. Es dürfen bei solchen Routern also keine * * * auftauchen.

Beispiel: Internet <-> dezentraler Freifunk Router

fbl@ns2:~$ traceroute --mtu 2a0b:f4c0:c8:6d::1
traceroute to 2a0b:f4c0:c8:6d::1 (2a0b:f4c0:c8:6d::1), 30 hops max, 65000 byte packets
 1  2a03:4000:24::2 (2a03:4000:24::2)  0.463 ms F=1500  0.861 ms  0.477 ms
[..]
 7  2a0b:f4c0:100:1::2 (2a0b:f4c0:100:1::2)  4.217 ms  4.166 ms  4.165 ms
 8  aquarius.sgstbr.de (2a01:4f8:160:14d5:a04b:0:6171:7561)  7.150 ms F=1448  7.188 ms  7.292 ms
 9  2a0b:f4c0:c8:6d::1 (2a0b:f4c0:c8:6d::1)  27.221 ms F=1420  26.144 ms  27.303 ms

• Zu Hop 1 ist Ethernet, daher 1500 MTU. (F=1500)
• Bei Hop 7 wird der Link zum ersten mal kleiner, weil das Paket dort durch einen GRE-Tunnel geht. (Daher steht bei Hopt 8 F=1448)
• Bei Hop 8 wird der Link erneut kleiner, da das Paket dann durch einen Wireguard zu mir nach Hause geht und Wireguard mehr Overhead hat als GRE. Daher muss auch Hop 8 passende ICMP Nachrichten senden können. (F=1420)

Anders herum genauso:

fbl@fbl-desktop:~$ traceroute -6 --mtu ns2.sgstbr.de
traceroute to ns2.sgstbr.de (2a03:4000:24:14a::1), 30 hops max, 65000 byte packets
 1  2a0b:f4c0:c8:6d::1 (2a0b:f4c0:c8:6d::1)  0.436 ms F=1500  0.402 ms  0.434 ms
 2  aquarius.sgstbr.de (2a01:4f8:160:14d5:a04b:0:6171:7561)  21.724 ms F=1420  18.931 ms  24.074 ms
 3  zeus.sgstbr.de (2a01:4f8:160:14d5:a04b:0:7a65:7573)  21.473 ms  20.666 ms  19.321 ms
 4  ext.zbau.f3netze.de (2a0b:f4c0:100::1)  25.951 ms  25.401 ms  26.324 ms
[..]

• Bei Hop 1 wird der Link kleiner, weil Übergang von Ethernet (1500) -> Wireguard (1420).
• Bei Hop 2 wird der Link nicht mehr kleiner, obwohl getunnelt wird, da GRE weniger Overhead hat als Wireguard.

NAT

In einem ICMP Fehlerpaket ist ein Ausschnitt des Pakets, das zum Fehler geführt hat, enthalten. Das ist nötig, damit der Client weißt, welche Verbindung betroffen ist.

Bei NAT wird ein IP Paket verändert. Passiert hinter dem NAT ein Fehler, der zu einem ICMP Fehlerpaket führt, hängt im ICMP das durch NAT veränderte Paket an.

Findet das ICMP Paket nun einen anderen Weg zum Client, der am NAT vorbei führt, kann das NAT dieses ICMP Paket nicht berichtigen, daher kann der Client das Paket nicht zuordnen.

Bei uns tritt dieses Problem leider sehr häufig auf, da die Tunnel meist erst hinter dem NAT kommen, häufig aber eine eigene unabhängige Verbindung ins Internet haben (um die Tunnel aufbauen zu können).

Eine mögliche Lösung kann die Option net.ipv4.icmp_errors_use_inbound_ifaddr = 1 sein. Diese sorgt dafür, dass ICMP Fehlerpakete auf dem Interface gesendet werden, auf dem das zum Fehler führende Paket eingetroffen ist.

Siehe auch Freifunk-Gateway_aufsetzen#ICMP_Fehlerpakete_f.C3.BCr_IPv4

Maximale PMTU einer Strecke messen

TODO

MTU Probleme erkennen

IPv4

Diese Webseiten können nur IPv4 und laden bei verringerter MTU nur, wenn PMTUD korrekt funktioniert:

• github.com
• twitter.com

Diese Webseiten können nur IPv4 und laden bei verringerter MTU auch bei korrekt funktionierender PMTUD nicht:

• telekom.de
• ui.com

Das liegt daran, dass die Webseitenbetreiber die ICMP Fehlerpakete ignorieren, vermutlich weil diese dort gefirewalled werden. Hier müssen die Netzwerkadmins dieser Seiten nochmal ihre Hausaufgaben machen.. ;-)