Fragen zu MTU und MSS

[n3]

WAN MTU = LAN MTU

Wie meinst du das genau? Aktuell habe ich ja nur in proxmox die MTU der NIC, Bridge und vnet für WAN angepasst und die PPPoE MTU. Beim WAN Interface und LAN Interface steht kein Wert. So richtig rund läuft es noch nicht.

Meinst du mit WAN MTU = LAN MTU, dass ich in den Interfaces auch eine MTU setze? Wäre das dann die 1492? Laut dem HowTo soll mal ja in den MTUs der Interfaces ja nichts einstellen, wenn man die MTU in der PPPoE einstellt.

[meyergru]

Ich meinte mit WAN MTU die effektiv erreichbare MTU, weil man das im WAN selbst nicht einstellen kann/sollte. Und ja, wenn Du weißt, dass nur 1492 Bytes durchgehen, sollte Dein LAN das den Clients auch signalisieren (und dafür muss es dort eingetragen sein) - der Default sind eben die durch das Howto angestrebten 1500 Bytes.

Entweder das oder eben 1500 am LAN, aber dann per MSS-Clamping eine Anpassung zwischen LAN und dem WAN mit 1492 Bytes machen. Ansonsten werden Websites mit defekter PMTUD nicht (richtig) funktioneren, weil Dein Client mit 1500 Bytes MTU arbeitet, davon aber immer die letzten 8 Bytes nicht ankommen.

[Patrick M. Hausen]

Ansonsten werden Websites mit defekter PMTUD nicht (richtig) funktioneren, weil Dein Client mit 1500 Bytes MTU arbeitet, davon aber immer die letzten 8 Bytes nicht ankommen.

Ähm ... der MTU-Sprung findet doch in diesem Fall schon am ersten Hop statt. Und der Client macht PMTUD. Und die OPNsense sagt ihm sofort "Fragmentation needed, DF bit set". Deshalb verstehe ich den ganzen Wirbel auch nur teilweise.

Wir hatten doch bestätigt, dass die OPNsense das ordentlich tut - also PMTUD per ICMP-Antwort unterstützen? War da was, was klemmt?

[n3]

Ich meinte mit WAN MTU die effektiv erreichbare MTU, weil man das im WAN selbst nicht einstellen kann/sollte. Und ja, wenn Du weißt, dass nur 1492 Bytes durchgehen, sollte Dein LAN das den Clients auch signalisieren (und dafür muss es dort eingetragen sein) - der Default sind eben die durch das Howto angestrebten 1500 Bytes.

Entweder das oder eben 1500 am LAN, aber dann per MSS-Clamping eine Anpassung zwischen LAN und dem WAN mit 1492 Bytes machen. Ansonsten werden Websites mit defekter PMTUD nicht (richtig) funktioneren, weil Dein Client mit 1500 Bytes MTU arbeitet, davon aber immer die letzten 8 Bytes nicht ankommen.

Sprich in den LAN und WAN Interface die 1492 einstellen?

You cannot view this attachment.

[meyergru]

Nur auf dem LAN. Was auf dem WAN geht, ist ja bekannt und wenn Du es dort setzt, besteht das Potential, dass das die pppoe-MTU implizit noch kleiner macht. Das LAN soll nur nicht mehr haben als die wirkliche Größe.

[meyergru]

Ansonsten werden Websites mit defekter PMTUD nicht (richtig) funktioneren, weil Dein Client mit 1500 Bytes MTU arbeitet, davon aber immer die letzten 8 Bytes nicht ankommen.

Ähm ... der MTU-Sprung findet doch in diesem Fall schon am ersten Hop statt. Und der Client macht PMTUD. Und die OPNsense sagt ihm sofort "Fragmentation needed, DF bit set". Deshalb verstehe ich den ganzen Wirbel auch nur teilweise.

Wir hatten doch bestätigt, dass die OPNsense das ordentlich tut - also PMTUD per ICMP-Antwort unterstützen? War da was, was klemmt?

Also, mal ganz von vorne:

1. Früher war die Nutzlast eines Ethernet Pakets mit 1518 Bytes spezifiziert. Sucht man im Internet nach dieser Zahl und "Ethernet", wird man sehr oft fündig. Diese Größe war z.B. bei den anfangs am meisten verbreiteten PC-Karten von Novell, der NE2000 auch exakt die Größe für ein Paket.

2. Nutzbar davon war eine MTU von 1500 Bytes.

3. Später wurde mit der Erfindung des VLAN-Standards dem Paket ein VLAN-Header von 4 Bytes hinzugefügt, der bei sehr alten Karten nicht in den RAM-Puffer passte, weshalb man dann mit einer verkleinerten MTU arbeiten musste.
Der Standard verlangte eigentlich eine Hardware-Erweiterung auf 1522 Bytes für die Paketdaten - heutige Karten können das und deshalb funktionieren meistens auch 1500 Bytes plus VLAN-Tagging.

4. Diese Rechnung hört spätestens dann auf, wenn man mehrfache VLAN-Tags (QinQ, nach 802.1q-in-802.1q) benötigt, um VLAN-Frames in VLANs einzupacken, beispielsweise, wenn man das VLAN für PPPoE-Pakete für den ISP noch in ein weiteres VLAN zur Separierung auf dem Switch einpacken möchte (z.B. VLAN 7 in VLAN 700). Hier reichen dann auch 1522 Byte Paketgröße nicht mehr aus, um weiterhin 1500 Bytes Nutzlast zu transportieren.

5. Diese Diskussion ist aber müßig, denn wenn man schon anfängt, größere Frames für das Hinzufügen von weiteren Kapselungen wie PPPoE zulassen zu wollen, schaden weitere 4 Bytes auf keinen Fall, deshalb schlage ich die sicherheitshalber immer auf. Außerdem illustriert das das Prinzip besser: jede "Schicht" erfordert durch Hinzufügen von weiteren Kapselungen mehr Platz, die man normalerweise von der Bruttokapazität abziehen muss. Der Guide zeigt, wie man umgekehrt die Bruttokapazität erhöhen muss, um die gewünschte Netto-MTU zu erhalten.


Und zum Thema MTU: Die Kommunikation zwischen Client und OpnSense funktioniert - egal, ob mit 1492 oder 1500 Bytes. Alerdings passen sich manche Clients einer kleineren MTU als 1500 Bytes auch nicht selbsttätig an, weshalb ich im LAN 1500 Bytes bevorzuge.
Außerdem: wenn die OpnSense "denkt", dass die erzielbare MTU nach außen 1500 Bytes ist und die externe Site das Gegenteil nicht signalisiert, dann wird niemandem mitgeteilt, dass es nicht geht, sondern die Pakete werden verworfen.
Also sollte man der OpnSense im Zweifel explizit "sagen", was maximal auf dem WAN geht. Und wenn das von der LAN-MTU abweicht, braucht man MSS Clamping.

Daraus folgt:

- Entweder man stellt WAN-MTU und LAN-MTU gleich ein (auf das maximal erzielbare)
- oder man lässt die OpnSense die MTUs per MSS-Clamping matchen.

Und die Königsvariante ist IMHO, sowohl LAN als auch WAN auf 1500 Bytes zu trimmen, wenn es denn irgendwie möglich ist, dann braucht man kein MSS-Clamping und alles funktioniert ohne Probleme.