MTU bei PPPoe | Deutsche Glasfaser | Proxmox - Drops beim Surfen

[s.meier68]

Exklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann.

Das habe ich jetzt schon ein paar mal gelesen und das ist aus meiner Sicht falsch. Die MTU und die Größe des Ethernetframes haben nur bedingt etwas miteinander zu tun. Die MTU gehört zum Layer3 Header des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 des Paketes. Dieser hat mit der MTU überhaupt nichts zu tun.
Die MTU kleiner machen, damit das gesamte Paket unter einer bestimmten Größe bleibt ist ungefähr so als wenn man ein Ikea-Paket aufteilt ohne zu wissen was die Spedition für einen LKW verwendet. (Was übrigens auch im Bezug zum Ethernetpaket vollkommen egal ist, da sich die Spedition drum kümmert und nicht das Ikea-Paket!!!)

[s.meier68]

Exklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann.

Das habe ich jetzt schon ein paar mal gelesen und das ist aus meiner Sicht falsch. Die MTU und die Größe des Ethernetframes haben nur bedingt etwas miteinander zu tun. Die MTU gehört zum Layer3 Header "Teil" des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 "Teil" des Paketes. Dieser hat mit der MTU überhaupt nichts zu tun.
Die MTU kleiner machen, damit das gesamte Paket unter einer bestimmten Größe bleibt ist ungefähr so als wenn man ein Ikea-Paket aufteilt ohne zu wissen was die Spedition für einen LKW verwendet. (Was übrigens auch im Bezug zum Ethernetpaket vollkommen egal ist, da sich die Spedition drum kümmert und nicht das Ikea-Paket!!!)

[Patrick M. Hausen]

Die MTU gehört zum Layer3 Header "Teil" des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 "Teil" des Paketes.

Die MTU gilt für den Layer 2 Payload und der beginnt dann üblicherweise mit dem Layer 3 Header, ja. Falls es ein Layer 3 gibt, was ja nicht sein muss. Also hier bei OPNsense schon, aber es gibt so Audio-Kram und ähnliches, was direkt auf Ethernet aufsetzt.

Du hast aber m.E. vollkommen Recht, dass ein 802.1q (VLAN) Header immer "außen" an den Layer 2 Frame dran geklebt wird und nicht auf Kosten der MTU geht. Ich hab das noch nie gesehen und wir haben mit VLANs angefangen, als man auch noch ISL statt 802.1q verwendet hat, ein proprietäres Format von Cisco.

[s.meier68]

Genau, natürlich gibt es eine Maximalgröße des gesamten Pakets. Diese ist bei der Verwendung von vLAN aber normalerweise um den vLAN-Header ergänzt (dann 1518) damit der Payload weiterhin 1500 Byte groß sein kann. Das gilt dann auch noch nicht als Jumboframe.... Und, ja. stimmt. MTU ungleich Payload.... :-)

[Patrick M. Hausen]

Und, ja. stimmt. MTU ungleich Payload.

Die MTU ist die Größe des Layer 2 Payloads. Also die Ethernet MTU, von der wir hier die ganze Zeit reden.

Ich wollte an deinem vorangegangenen Post nur korrigieren, dass du geschrieben hattest, die MTU sei Layer 3. Im Layer 2 Payload sind üblicherweise Layer 3 Frames. So stimmt's dann.

Cisco IOS kennt übrigens eine Ethernet MTU und eine IP MTU. Ich muss nochmal nachgucken, was letztere eigentlich genau angibt.

EDIT:

Die Interface MTU in Cisco IOS ist erwartungsgemäß die Layer 2 MTU, also meistens aber nicht immer Ethernet. Die IP MTU gibt ebenfalls die Layer 2 MTU an, aber nur für die Frames, bei denen Layer 3 IP ist. Wenn sie größer ist als die MTU wird die Einstellung verworfen und die MTU gilt. Wenn sie kleiner ist, gilt für IP die IP MTU und für alles andere die MTU.

Wozu man das braucht erschließt sich mir nicht auf Anhieb, aber jedes Feature hat eine Geschichte. Ich hab nie selbst MPLS oder L2TP Tunnel für andere geliefert - evtl. kommt das daher.

[s.meier68]

Ja, ich weiß. :-) Ich habe es aber (das war auch lange vor vlans) auch mal mit den jeweiligen OSI Headern und dem dazugeghörigen Payload gelernt... Da weiß ich manchmal nicht wie ich das nennen soll...

Zumindest MPLS wird auch draußen dran gehängt und wird eigentlich auf den Endpunkten so konfiguriert, dass die MTU auch wieder 1500 betragen kann

[meyergru]

Wenn wir schon spitzfindig werden:

"Meistens" - nicht bei allen ISPs, die Telekom ist ein gutes Beispiel, sonst bräuchte es ja die Reduktion auf 1492 Bytes MTU dort nicht.

Und ja, es ist richtig, dass nach der Einführung von 802.1q die Hersteller dafür gesorgt haben, dass die VLAN-Tags noch zusätzlich zu den üblichen 1500 Bytes passen. Das war aber nicht immer so, z.B. vor Einführung von 802.1q und außerdem stimmt das spätestens nicht mehr, wenn man dann QinQ macht, das ist nämlich NICHT einkalkuliert.

Klar, es kann funktionieren, weil manche moderne Netzwerkhardware sogar Frames bis 9014 Bytes unterstützt, ich habe das aber im Guide so beschrieben, dass es IMMER funktioniert (gesetzt den Fall, dass Mini-Jumbo-Frames auf der ISP-Strecke auch gehen).

Mal ganz abgesehen davon, dass OpnSense auch noch ein paar Glitches hat bei der automatischen Berechnung von MSS usw. aus den gegebenen Werten. Deshalb rate ich dazu, die Werte explizit zu setzen und eher zu hoch als zu niedrig. Und dann: Nicht glauben, sondern testen - deswegen gibt es das Tool.

[Patrick M. Hausen]

"Meistens" - nicht bei allen ISPs, die Telekom ist ein gutes Beispiel, sonst bräuchte es ja die Reduktion auf 1492 Bytes MTU dort nicht.

Das liegt an den 8 Oktetts PPPoE Header, die eben im Layer 2 Payload transportiert werden. Hat nichts mit den 802.1q Tags zu tun.

[meyergru]

Korrekt. Ganz safe wären 1488. Die Telekom erlaubt tatsächlich 1500 Bytes plus VLAN Tag abzüglich PPPoE - wie heutzutage die meiste Netzwerk-Hardware auch.

Die Bemerkung mit der Erhöhung der Proxmox-Payload bezieht sich darauf, dass man das tun muss, weil sonst die virtio-Karte auch auf 1500 Bytes plus VLAN beschränkt ist, nämlich als Antwort hierauf:

https://forum.opnsense.org/index.php?msg=257341