[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Subject: RE: ADSL einrichten unter SUSE 7
From: Meer Michael SBS ITS TNS 23 LAN 5
Date: 22 Jan 2001 10:25:43 -0000


Hi *
Anbei eine Mail von Krischan Jodies aus der
Göttinger LUG (GALUG):

Ist Zwar einwenig viel - aber genau beschrieben
und da sich Krischan damals soviel arbeit gemacht hat, gebe
ich dies hier einfach mal weiter ...

> Hi Micha, 
> wieviel ist den bei dir "etwas kleiner" ?? 
> 
>>Denk bitte an die MTU (Maximum Transfer Unit) sollte etwas kleiner 
>>sein als der Standart da das PPPoE noch einen Header hinzu fügt und 
>>die Cisco-Router der Telekom das (immernoch) nicht richtig händeln. 
>

Am Die, 17 Okt 2000 schrieb Eberhard Moenkeberg

> Die Aenderung bei den Clients ist nicht erforderlich.
> Deren Pakete muessen im Linux-TDSL-Router wegen Masquerading ohnehin
> umgewurstet werden, und selbst als normaler Router wuerde der Linux-PC zu
> lange Pakete passend fragmentieren.

Das stimmt nicht. Bei den Clients ist -wenn man es richtig macht- wirklich
keine Aenderung noetig, aber der Grund ist viel komplizierter:

Man hat in einem Netzwerk wie dem Internet das Problem, dass die Teilnehmer 
an Leitungen angeschlossen sind, die unterschiedlich grosse Pakete
transportieren koennen. Diese Groesse heisst MTU (Maximum Transmission
Unit).
Bei Ethernet ist die MTU z.B. 1500 Bytes, an einer PPP Modemleitung in der
Regel 296 Bytes. Bei einer PPP over Ethernet Leitung (T-DSL) sind es 1492
Bytes. Wie kriegt man nun ein urspruenglich 1500 Bytes grosses Paket durch
die
Modemleitung? Die Loesung liefert IP. Das zu grosse IP-Datagramm wird in
mehrere kleinere IP-Pakete zerlegt (fragmentiert) die genau passen.

So weit so gut. Aber man moechte Fragmentierung vermeiden, weil darunter die
Performanz der Leitung aus verschiedenen Gruenden geringer wird. Dazu gibt
es
die Path MTU Discovery. Die Path MTU ist die kleinste MTU die irgendwo
auf der Strecke auftritt. Typischerweise ist das die Modemleitung am Ende,
oder
neuerdings wie in diesem Fall die ADSL Leitung. Wenn einem Rechner die Path
MTU
bekannt ist weil er einen neueren TCP/IP Stack hat der path mtu discovery
unterstuetzt, kann er von vorneherein immer ausreichend kleine Pakete
senden,
die nicht fragmentiert werden.

Path MTU Discovery funktioniert so: Die Partner verschicken ihre ersten TCP
Datagramme (und danach in bestimmten Abstaenden wieder), mit gesetztem
"Don't
Fragement" (DF) Flag. Ein Router der so ein Paket mit DF Flag erhaelt, und
es
eigentlich fragmentieren muesste fragmentiert es nicht, sondern schmeisst es
weg und schickt eine ICMP Nachricht "Fragmentation needed, but DF bit set"
zurueck. Der Sender weiss daher, dass die Pakete die er verschickt zu gross
sind, verschickt die Pakete danach in kleineren groessen, bis er die Path
MTU erwischt hat und keine Fehlermeldung mehr zurueckkommt.

Was passiert jetzt, wenn jemand solche Pakete wegschmeisst, und keine
Fehlermeldung zurueckschickt, oder die Fehlermeldung es nicht zurueckschafft
(manche Rechner stehen hinter Firewalls die falscherweise ueberhaupt keine
ICMP
Pakete durchlassen? (Z.B. ist Freshmeat so ein beruechtigter Kandidat.) Der
Sender erfaehrt ueberhaupt nicht, dass seine Pakete verworfen wurden! Er
merkt
lediglich, dass der Empfaenger die Pakete nicht bestaetigt. Was tut er? Er
darf
keine neuen Pakete senden solange die alten noch nicht bestaetigt sind, und
wiederholt die Sendung der nicht bestaetigten Pakete. Die werden wieder von
dem
Router verworfen. Und genau das passiert anscheinend bei der Telekom und
einem
Haufen anderer DSL Provider. Wo genau der Fehler ist konnte ich nicht
rauskriegen. Diese Netze werden auch als Netze mit ICMP Blackholes genannt.

Nun zur Loesung des Problems:

Es gibt bei TCP noch einen Mechanismus mit dem Fragmentation vermieden wird.
Die Partner senden sich in ihren Verbindungsaufbaupaketen einen Wert zu, der
mss heisst. Maximum Segment Size. Das ist die maximale groesse fuer TCP
Segmente, die der Sender empfangen moechte. Bzw. die Maximale groesse fuer
TCP
Segmente die die Gegenstelle schicken darf. Sie wird natuerlich so gewaehlt,
dass Pakete dieser Groesse genau durch die Leitung an die der jeweilige
Partner angeschlossen ist durchpassen.

Das ist bei Ethernet mit einer MTU von 1500 also:
1500 (MTU) - 20 (IP Header) - 20 (TCP Header) = 1460 (MSS).

Und genau diesen Wert setzen auch Linux Rechner die hinter einem
maskierenden
ADSL Router an einem Ethernet LAN haengen. Dahinter steht der ADSL Router
mit
einer Leitung deren MTU nur 1492 Bytes gross ist. Davon wissen die
maskierten
Hosts aber nichts. Was passiert? Die Antworten der Gegenstellen sind zu
gross,
die schicken dann naemlich wie gefordert zu grosse Pakete und setzen das
Don't
fragment bit und es passiert das oben beschriebene.

Neuere pppoe Software greift hier ein, indem sie die ersten Pakete, die die
mss enthalten einfach veraendern. Z.B. der Roaring Penguin pppoed setzt die
mss
ausgehender Pakete standardmaessig immer auf 1412, was ausreichend klein
ist.
Dieser Wert auf den die MSS manipuliert wird heisst clampMSS

Fuer das Optimum ist dieser Wert meiner Rechnung nach noch etwas zu klein.

          MTU   MSS bzw.  Overhead fuer 
                clampMSS  nicht-Daten (also die Header)
Ethernet  1500  1460      2,73%
PPPoE     1492  1452      2,75%    
RP-PPPoE  1492  1412      2,83%

Mir bekannte funktionierende PPP over Ethernet Daemonen sind der oben
beschriebene rp-pppoe (http://www.roaringpenguin.com/pppoe.html) und der
Standardmaessig von SuSE 7.0 eingesetzte von Jamal Hadi Salim
(http://www.davin.ottawa.on.ca/pppoe/). Fuer letzteren muss das mss_clamp
von
Hand nachcompiliert werden (Anleitung steht auf 
http://support.suse.de/sdb/de/html/hoe_adsl_router.html).

Und es gibt noch mehr...

Krischan

----------------------------------------------------------------------
Mails an die Liste bitte an gulag@goe.net schicken. Wer nicht mehr auf
dieser Liste sein moechte, sollte eine Mail an majordomo@goe.net
schicken mit folgendem Inhalt: unsubscribe gulag


Mit freundlichen Grüßen
with kind regards

Michael Meer         SBS ITS TNS 23 LAN 5
LAN München M        St.-Martin-Str. 76
Team WAN Encryption  D-81541 München
  for Infineon           Germany
Telefon: 0049-89-636-22727

Was die Raupe "Ende der Welt" nennt,
nennt der Rest der Welt Schmetterling.
                       Laotse