Mailinglist Archive: opensuse-de (5949 mails)
| < Previous | Next > |
Re: MTU-Problem vielleicht Hardware-Problem? Was: T_DSL und MTU Problem
- From: Andreas Koenecke <akoenecke@xxxxxxxxxxxx>
- Date: Wed, 31 Oct 2001 19:44:35 +0100
- Message-id: <20011031194435.A4606@xxxxxxxxxxxxxxxxxx>
* Mittwoch, 31. Oktober 2001 um 12:06 (+0100) schrieb Dieter Kluenter:
>
> Ich denke, ein paar grundsätzliche Bemerkungen zu ADSL, Ethernet und
> TCP/IP zum Verständnis des Problems sind mal angebracht.
Da stimme ich dir zu, die Bemerkungen sollten aber richtig sein...
> Das Ethernet Protokoll kann nur Datenpakete bis 1500 byte
> behandeln. Das TCP/IP Protokoll benötigt für jedes Datenpaket einen
> Header von min. 8 byte, bleiben für ethernet netto 1492 byte übrig.
Dazu hat Matthias ja schon die Berichtigung gepostet.
> Der Linux Kernel kann grundsätzlich größere Datenpakete behandeln,
> dies kann mit dem Parameter Allow_Large_Frames eingestellt werden,
Das gilt aber nur für Gigabit-Ethernet. Nur dort gibt es bisher die
sog. "Jumbo-Frames".
> allerdings können Paketfilter diese großen Datenpakete nicht
> handhaben, daher erstellt und behandelt der Kernel als default nur
> Datenpakete bis zu 1500 byte.
Nicht wegen des Paketfilters, sonder weil 10/100 Base-X-Ethernet keine
größere MTU haben kann.
> Sowohl über die Konfiguration der Ethernetkarte als auch über die
> Konfiguration des ppp Devices kann der Gegenstelle die mögliche
> Paketgrößere mitgeteilt werden.
Die MTU der Ethernetkarte (solange sie nur an das T-DSL-"Modem"
angeschlossen ist) ist bei PPPoE _ohne_ Relevanz.
Die MTU des ppp-Devices wird beim Verbindungsaufbau mit der
Gegenstelle ausgehandelt. Ich habe noch keinen Fall (T-DSL) gesehen,
wo dort nicht 1492 ausgehandelt wurde, unabhängig von den Optionen des
pppd.
> Die Aufgabe der Umwandlung von Datenpaketen in die unterschiedlichen
> Protokolle obligt dem Splitter
Dem Splitter mit Sicherheit nicht, das ist lediglich eine
Frequenzweiche und sonst nichts...
Eventuell meinst du den NTBBA (ADSL-"Modem"). Aber auch das nimmt
keine Umwandlung der Datenpakete vor, sondern eine Kapselung: Die
Ethernet-Frames, in denen schon die PPP-Pakete gekapselt sind, werden
in ATM-Zellen gekapselt und über ADSL and den DSLAM übertragen.
> und ich denke daß hier das Problem
> liegt, da im Header der Datenpakete noch weitere ATM relevante Daten
> enthalten sein können, die die Größe des Nettodatensatzes
> reduzieren.
Nein, sie ATM-Zellen sind um den ATM-Overhead größer als die
Ethernet-Frames.
> Ich vermute aber, daß dies ein Problem des jeweiligen
> Splittermodels ist, das konnte ich aber noch nicht verifizieren.
Sehr unwahrscheinlich, denn die MTU betriftt die Verbindung
Computer -- AC, der NTBBA und der DSLAM (in der Vermittlungsstelle)
sind für die Ethernet-Frames und erst recht für PPP transparent.
Falls man nach systematischen, hardwarebedingten Fehlern suchen will,
wäre eher der Typ und Ort des AC interessant, da es dort schon
Unterschiede geben kann.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke <akoenecke@xxxxxxxxxxxx>"
PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3
PGP-Key on request or on public keyservers
--
>
> Ich denke, ein paar grundsätzliche Bemerkungen zu ADSL, Ethernet und
> TCP/IP zum Verständnis des Problems sind mal angebracht.
Da stimme ich dir zu, die Bemerkungen sollten aber richtig sein...
> Das Ethernet Protokoll kann nur Datenpakete bis 1500 byte
> behandeln. Das TCP/IP Protokoll benötigt für jedes Datenpaket einen
> Header von min. 8 byte, bleiben für ethernet netto 1492 byte übrig.
Dazu hat Matthias ja schon die Berichtigung gepostet.
> Der Linux Kernel kann grundsätzlich größere Datenpakete behandeln,
> dies kann mit dem Parameter Allow_Large_Frames eingestellt werden,
Das gilt aber nur für Gigabit-Ethernet. Nur dort gibt es bisher die
sog. "Jumbo-Frames".
> allerdings können Paketfilter diese großen Datenpakete nicht
> handhaben, daher erstellt und behandelt der Kernel als default nur
> Datenpakete bis zu 1500 byte.
Nicht wegen des Paketfilters, sonder weil 10/100 Base-X-Ethernet keine
größere MTU haben kann.
> Sowohl über die Konfiguration der Ethernetkarte als auch über die
> Konfiguration des ppp Devices kann der Gegenstelle die mögliche
> Paketgrößere mitgeteilt werden.
Die MTU der Ethernetkarte (solange sie nur an das T-DSL-"Modem"
angeschlossen ist) ist bei PPPoE _ohne_ Relevanz.
Die MTU des ppp-Devices wird beim Verbindungsaufbau mit der
Gegenstelle ausgehandelt. Ich habe noch keinen Fall (T-DSL) gesehen,
wo dort nicht 1492 ausgehandelt wurde, unabhängig von den Optionen des
pppd.
> Die Aufgabe der Umwandlung von Datenpaketen in die unterschiedlichen
> Protokolle obligt dem Splitter
Dem Splitter mit Sicherheit nicht, das ist lediglich eine
Frequenzweiche und sonst nichts...
Eventuell meinst du den NTBBA (ADSL-"Modem"). Aber auch das nimmt
keine Umwandlung der Datenpakete vor, sondern eine Kapselung: Die
Ethernet-Frames, in denen schon die PPP-Pakete gekapselt sind, werden
in ATM-Zellen gekapselt und über ADSL and den DSLAM übertragen.
> und ich denke daß hier das Problem
> liegt, da im Header der Datenpakete noch weitere ATM relevante Daten
> enthalten sein können, die die Größe des Nettodatensatzes
> reduzieren.
Nein, sie ATM-Zellen sind um den ATM-Overhead größer als die
Ethernet-Frames.
> Ich vermute aber, daß dies ein Problem des jeweiligen
> Splittermodels ist, das konnte ich aber noch nicht verifizieren.
Sehr unwahrscheinlich, denn die MTU betriftt die Verbindung
Computer -- AC, der NTBBA und der DSLAM (in der Vermittlungsstelle)
sind für die Ethernet-Frames und erst recht für PPP transparent.
Falls man nach systematischen, hardwarebedingten Fehlern suchen will,
wäre eher der Typ und Ort des AC interessant, da es dort schon
Unterschiede geben kann.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke <akoenecke@xxxxxxxxxxxx>"
PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3
PGP-Key on request or on public keyservers
--
| < Previous | Next > |