INODE xDSL Business Silber: MTU auf 1452 setzen?

[Master One]

Bei meiner Suche nach mehr Info zur Netzwerktechnik bin ich auf diese Seite gestoßen, die anschaulich erklärt, daß man bei einer PPPoE Verbindung optimalerweise die MTU auf 1452 setzt.

Dies mag plausibel sein, wenn der Computer direkt an das DSL Modem angeschlossen ist, und den PPPoE Tunnel selbst herstellt (wie bei einem normalen INODE xDSL Privat Anschluß ohne Mehrplatzoption).

Wie ist das aber nun bei einem INODE xDSL Privat Anschluß mit Mehrplatzoption, bzw. einem xDSL Business Silber Anschluß (ist praktisch das selbe, mit anderen Übertragungsbandbreiten, 8 fixen IP-Adressen, und einem höheren Preis), bei dem das DSL Modem für das dahinter liegende LAN den PPPoE Tunnel transparent herstellt?

Angenommen es handelt sich um einen INODE xDSL Business Silber 2048/512 Anschluß, an dem vermutlich ein Zyxel 600er Modem zum Einsatz kommt. Am Zyxel hängt nun ein Firewall-Router, und an diesem ein Switch mit den Rechnern des LANs.

Bei allen Rechnern im LAN ist prinzipiell eine MTU von 1500 eingestellt, da es sich ja um ein Ethernet handelt.

Wie und wo kommt es nun zu einer Umsetzung, damit für den PPPoE Tunnel zwischen DSL Modem und entbündeltem Wählamt die optimale MTU von 1452 benutzt wird?

Ich vermute mal, daß hierfür eigentlich das Setup des DSL Modems selbst verantwortlich sein müßte, da dieses nun mal den PPPoE Tunnel verwaltet. Ob das Zyxel aber bei bei der Konfiguration durch INODE auf eine MTU von 1452 gesetzt wurde, läßt sich wohl weder nachvollziehen, noch kann man dies selbst ändern.

Oder reicht es, wenn die MTU von 1452 auf dem Netzwerkinterface des Firewall-Routers, das mit dem Zyxel verbunden ist, gesetzt wird? Ist das Ergebnis hierbei dann nicht ungewiß, wenn man nicht weiß, was das Zyxel damit anstellt?

Irgendwie fehlt mir hierbei der Durchblick: Wenn ein Computer mit 2 Netzwerkkarten als Router eingesetzt wird, auf dem externen Interface die MTU auf 1452, und auf dem internen Interface die MTU auf 1500 (da alle weiteren Geräte im LAN mit einer MTU on 1500 arbeiten) gesetzt ist, müßte es doch auf Grund der Differenz zu einer
Fragmentierung kommen, die den Overhead weiter erhöht. Diese Fragmentierung ließe sich doch nur vermeiden, wenn alle beteiligten Geräte (also vom DSL Modem bis zu den Workstations im LAN) einheitlich auf eine MTU von 1452 gesetzt wären. Oder ist diese Annahme falsch?

Mangels vorhandenem asymmetrischen Zugang habe ich heute ein paar Tests an einer symmetrischen INODE xDSL unlimited 2320 Leitung durchgeführt. Der TCP/IP Analyser von speedguide.net hat eine MTU von 1442 ergeben ("MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings."), sowie eine MSS von 1402 ("MSS is not optimized for broadband. Consider increasing your MTU value."). Dies sind ziemlich seltsame Werte, wenn man bedenkt, daß diese Leitung nicht mit einem PPPoE Tunnel arbeitet, und deswegen meiner Ansicht nach eine MTU von 1500 zur Anwendung kommen sollte.

Noch seltsamer ist, daß ein ping-Versuch nach der Erklärung von dieser Seite mit den Optionen "-f -l" gezeigt hat, daß die maximale Paketgröße, die ohne Fragmentierung über diese Leitung übertragen werden kann, 1472 beträgt. 1472 plus 28 (Overhead) ergibt eine MTU von 1500! Wie läßt sich das bloß erklären?

[jutta]

> Ob das Zyxel aber bei bei der Konfiguration durch INODE auf eine MTU von 1452 gesetzt wurde, läßt sich wohl weder nachvollziehen, noch kann man dies selbst ändern.

mit sehr hoher wahrscheinlichkeit nicht. die zyxel-modems und router funktionieren hinsichtlich fragmentierung naemlich sehr gut und, anders als bei anderen geraeten, kann man die mtu gar nicht bei einem menuepunkt einstellen, sondern im ci durch editieren einer autoexec-datei, die man ohne zwingenden grund nicht anruehrt.
http://www.zyxel.com/support/knowledgeb ... search=mtu

hier ein output von ip ifconfig bei standardeinstellungen:

Code: Alles auswählen

p660> ip ifconfig
enif0: mtu 1500
    inet 83.65.119.89, netmask 0xfffffff8, broadcast 83.65.119.95
    RIP RX:None, TX:None,
    [InOctets      41128503] [InUnicast    512508] [InMulticast        86926]
    [InDiscards           0] [InErrors          0] [InUnknownProtos        0]
    [OutOctets      3066382] [OutUnicast    52463] [OutMulticast        4154]
    [OutDiscards          0] [OutErrors         0]
enif0:0: mtu 1500
    inet 0.0.0.0, netmask 0x00000000, broadcast 0.0.0.0
    RIP RX:None, TX:None,
    [InOctets             0] [InUnicast         0] [InMulticast            0]
    [InDiscards           0] [InErrors          0] [InUnknownProtos        0]
    [OutOctets            0] [OutUnicast        0] [OutMulticast           0]
    [OutDiscards          0] [OutErrors         0]
enif0:1: mtu 1500
    inet 0.0.0.0, netmask 0x00000000, broadcast 0.0.0.0
    RIP RX:None, TX:None,
    [InOctets             0] [InUnicast         0] [InMulticast            0]
    [InDiscards           0] [InErrors          0] [InUnknownProtos        0]
    [OutOctets            0] [OutUnicast        0] [OutMulticast           0]
    [OutDiscards          0] [OutErrors         0]
wanif0: mtu 1492
    inet 83.65.119.89, netmask 0xffffffff, broadcast 255.255.255.255
    RIP RX:None, TX:None,
    [InOctets       2400698] [InUnicast     45498] [InMulticast            0]
    [InDiscards           0] [InErrors          0] [InUnknownProtos        0]
    [OutOctets       796231] [OutUnicast    12703] [OutMulticast           0]
    [OutDiscards          0] [OutErrors         0]
p660>



solange du keine auffallenden probleme hast (ftp upload unmoeglich, bestimmte websites laden nicht, unerklaerliche verzoegerungen ...) passt die mtu ohnehin. gut erzogene geraete finden die richtigen einstellungen von alleine

wenn du das thema genauer erforschen willst, nimm dir einen sniffer. damit kannst du jedes einzelne paket anschauen, das rein- oder rausgeht.

[superracer]

... bin ich auf diese Seite gestoßen ...

auf der seite ist gleich am anfang ein gravierender(?) fehler: der ethernet-header ist 14 bytes, nicht 18, somit ist die max. frame-länge inkl. header 1514 bytes, nicht 1518. (wobei man mit FCS auf 1518 kommt, wobei ich aber nicht weiß, ob die FCS auch übers ATM übertragen wird oder nicht, anscheinend hängt das von der verwendeten enkapsulierung bzw. der implementation im detail ab)

... die anschaulich erklärt, daß man bei einer PPPoE Verbindung optimalerweise die MTU auf 1452 setzt.

ohne das jetzt selbst durchgerechnet zu haben: sind dir (falls alles stimmt) 0,6% weniger overhead das wirklich wert?

[umsetzung] Ich vermute mal, daß hierfür eigentlich das Setup des DSL Modems selbst verantwortlich sein müßte, da dieses nun mal den PPPoE Tunnel verwaltet.

richtig, das macht einen router zum router.

Ob das Zyxel aber bei bei der Konfiguration durch INODE auf eine MTU von 1452 gesetzt wurde, läßt sich wohl weder nachvollziehen, ...

ist es nicht.

Oder reicht es, wenn die MTU von 1452 auf dem Netzwerkinterface des Firewall-Routers, das mit dem Zyxel verbunden ist, gesetzt wird?

nein, denn in dem fall würde der firewall-router von mtu 1500 auf mtu 1452 "umrechnen", sprich fragmentieren müssen, somit wird aus jedem größeren paket zwei kleinere pakete, was schon mal 20 bytes IP-header zusätzlich bedeuten, plus möglw. weiteres padding auf ATM-ebene, je nachdem wie groß die resultierenden fragmente sind.

Ist das Ergebnis hierbei dann nicht ungewiß, wenn man nicht weiß, was das Zyxel damit anstellt?

was das zyxel damit anstellt, läßt sich verhersagen und durchrechnen. weniger vorhersehbar ist, was der firewall-router nach der fragmentierung der zu großen pakete ausspuckt: auf jeden fall zwei pakete, aber ist das erste das größere und das zweite enthält den rest, oder umgekehrt, oder gar ganz anders? (das ist je nach IP-stack unterschiedlich)

... Diese Fragmentierung ließe sich doch nur vermeiden, wenn alle beteiligten Geräte (also vom DSL Modem bis zu den Workstations im LAN) einheitlich auf eine MTU von 1452 gesetzt wären.

prinzipiell richtig, aber es gibt noch einen weiteren mechanismus: path mtu discovery (oder PMTU discovery). als geübter googler wirst du sicher schnell rauskriegen, was das is und wie das funktioniert

... TCP/IP Analyser ...

von solchen tools halt ich persönlich nicht viel. besser: selbst in die protokolle einlesen, die verwendeten mechanismen studieren, selbst tests durchführen und das ergebnis selbst ausrechnen. mühsam, aber dann stimmt's wenigstens (und falls man einen fehler drinhat, läßt sich wenigstens nachvollziehen, wo er ist).

... daß die maximale Paketgröße, die ohne Fragmentierung über diese Leitung übertragen werden kann, 1472 beträgt. 1472 plus 28 (Overhead) ergibt eine MTU von 1500! Wie läßt sich das bloß erklären?

was is daran seltsam? ist doch genau wie erwartet, oder?