MTU 1492 vs MTU 1480 / Fragmentierung bei ICMP-Replies

3 years ago

Hallo,

 

seit einiger Zeit stelle ich mir die Frage, welche MTU für PPPoE bei der Telekom idealerweise eingestellt werden sollte.

Ich fahre derzeit eine FritzBox 7590 im Bridge-Modus (Routed Bridge Encapsulation + keine Zugangsdaten + PPPoE für andere Geräte) mit einem Mikrotik Router dahinter. Der Mikrotik Router baut die PPPoE-Verbindung auf, während die FritzBox das VLAN-Tagging in VLAN 7 übernimmt.

 

Die FritzBox erlaubt eine maximale MTU von 1518 Byte auf ihren Interfaces. PPPoE erlaubt eine maximale Frame-Größe von 1500 Byte mit 1492 Byte Nutzdaten + 6 Byte PPPoE-Session und 2 Byte PPP. Demnach wäre eigentlich die ideale MTU 1492 Byte auf dem PPPoE-Interface und 1500 Byte auf dem physischen Interface zur FritzBox.

 

Wenn ich nun einen ping mit gesetztem "don't fragment" Bit sende, kommt dieser ping in voller Länge und unfragmentiert beim Ziel an. Der reply dagegen wird fragmentiert. Laut tracepath passiert das bei einem Hop mit einem Namen nach dem Schema xxxxxxxxx.dip0.t-ip-connect.de. Damit der reply nicht mehr fragmentiert wird, müsste ich eine MTU (oder MRU) von 1480 im Router eintragen. 

 

Warum wird hier diese merkwürdige MTU gewählt? Warum nur in eine Richtung? Ist das ein Konfigurationsfehler seitens der Telekom oder mein Unverständnis?

 

MfG,

Daxter

 

Zur Ergänzung:

Ich führe pings unter Linux mit ping -4 redacted.invalid -s 1464 -M do durch. 1464, weil 1492 = 1464 + 20 (IPv4-Header) + 8 (ICMPv4-Header)

6511

7

    • 3 years ago

      Guten Morgen🌞

       

      Also ich habe eine MTU von1492 im Router stehen, und es wird auch nichts fragmentiert. Hab allerdings keine Fritzbox

      0

    • 3 years ago


      @mrdaxter25  schrieb:
      Wenn ich nun einen ping mit gesetztem "don't fragment" Bit sende, kommt dieser ping in voller Länge und unfragmentiert beim Ziel an. Der reply dagegen wird fragmentiert.

      Kann ich so nicht beobachten.

      Unbenannt.JPG


      5

      Answer

      from

      3 years ago

      Danke fürs Testen 👍

      Bei mir sieht das bei einer Länge von 1464 Byte so aus:

      mrdaxter25_0-1642938062632.png

      Was ich besonders interessant finde ist, dass die ausgehenden Frames bei dir 1516 Byte und bei mir 1518 Byte lang sind.

       

      Answer

      from

      3 years ago

      mrdaxter25

      Pingt man mit DF-Bit ist nur der Echo-request damit gekennzeichne

      Pingt man mit DF-Bit ist nur der Echo-request damit gekennzeichne
      mrdaxter25
      Pingt man mit DF-Bit ist nur der Echo-request damit gekennzeichne

      Mein Windows-Rechner schickt das zu große Paket gar nicht erst auf die Reise, wenn -f (DF) gesetzt ist.

      Demzufolge gibt es kein Reply-Paket.

       

       

       

      Answer

      from

      3 years ago

      mrdaxter25

      Was ich besonders interessant finde ist, dass die ausgehenden Frames bei dir 1516 Byte und bei mir 1518 Byte lang sind.

      Was ich besonders interessant finde ist, dass die ausgehenden Frames bei dir 1516 Byte und bei mir 1518 Byte lang sind.
      mrdaxter25
      Was ich besonders interessant finde ist, dass die ausgehenden Frames bei dir 1516 Byte und bei mir 1518 Byte lang sind.

      Das ist abhängig davon, was das Capture-Modul anzeigt.

      Meine DB zeigt da auch schonmal 1494 (2Bytes PPP + 8Bytes ICMP + 20Bytes IP + 1464) an.

       

       

      Unlogged in user

      Answer

      from

    Unlogged in user

    Ask

    from

    This could help you too

    15 years ago

    30891

    0

    7

    in  

    8182

    0

    2

    7 years ago

    in  

    16229

    0

    4

    Solved

    in  

    1149

    1

    2