T-DSL (u.a.): Manche Server sind nicht erreichbar

Supportdatenbank (cg_pmtu2)
Bezieht sich auf

SuSE Linux: Version 7.3
Kernel: Versionen ab 2.4.0

Symptom

Sie verwenden DSL mit SuSE Linux 7.3 und manche Rechner im Internet sind nicht erreichbar. Dies äußert sich darin, dass zum Teil die Verbindung noch aufgebaut werden kann, aber dann die Datenübertragung hängen bleibt.

Ursache

Das "Hängenbleiben" der Verbindung ist nichts T-DSL spezifisches, sondern durch die kleinere zulässige MTU von T-DSL (durch PPPOE) bedingt. Falls Ihnen die hier beschriebene Methode nicht weiterhilft beachten Sie bitte auch den SDB Artikel "Internetverbindung: Manche Webseiten lassen sich nicht aufrufen" (http://sdb.suse.de/de/sdb/html/cg_internet.html).

Leider gibt es einige Betreiber von Servern, die davorliegende "Firewalls" falsch konfiguriert haben. Das ist die eigentliche Ursache des Problems.

Lösung

Sie müssen in folgenden Dateien den MTU und den MRU Wert auf 1492 setzen.

/etc/ppp/options
/etc/ppp/peers/pppoe

Fügen Sie in die Datei /etc/ppp/peers/pppoe folgende Zeilen ein:

mtu 1492
mru 1492

In der Datei /etc/ppp/options suchen Sie nach mtu und mru, und ändern die auskommentierten Zeile wie folgt ab:

mtu 1492
mru 1492

Wichtig hierbei ist, dass Sie in beiden Dateien die Werte gleich setzen. Haben Sie alle Werte auf 1492 gesetzt, sollten Sie danach ohne Probleme Seiten wie gmx.de oder postbank.de erreichen.

T-DSL in Zusammenhang mit Routern

Sie verwenden einen zentralen Router der für mehrere Rechner das Masquerading übernimmt. Die Clients können bestimmte Rechner im Internet nicht erreichen. Lokal auf dem Router haben Sie keine Probleme.

Als ersten sollten Sie auf einer der Clientmaschinen testen ob wirklich PMTU discovery das Problem bei Ihnen verursacht. Hierzu können Sie an der Kommandozeile das ifconfig Kommando verwenden um die verwendete Paketgröße einzustellen. Beachten Sie daß Sie auf dem Router die Netzwerkkarte an der das T-DSL Modem direkt angeschlossen ist nicht in der MTU verkleinern dürfen.

tux@erde:~ $ /sbin/ifconfig
eth0      Protokoll:Ethernet  Hardware Adresse 00:10:10:00:01:A4  
          inet Adresse:10.10.11.102  Bcast:10.10.255.255  Maske:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:93589710 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14879178 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100 
          RX bytes:3770027551 (3595.3 Mb)  TX bytes:2994365512 (2855.6 Mb)
          Interrupt:11 Basisadresse:0xd000 

Oben fett hervorgehen sehen Sie die Voreinstellung der MTU von 1500 Byte. Probieren Sie nun die MTU zu verkleinern (root rechte erforderlich).

root@erde:~ # /sbin/ifconfig eth0 mtu 1400

Sollte Sie nun die problematischen Server erreichen können so können Sie für diesen Fall folgende Veränderungen vornehmen:

Möglichkeit 1: Mit iptables

Wenn Sie iptables verwenden genügt es wenn Sie lediglich den T-DSL Router umkonfigurieren. Eine explizite Konfiguration der Clientmaschinen ist unnötig. Um iptables verwenden zu können muß auf Ihrem Router ein Linux Kernel Version 2.4 installiert sein.

Geben Sie auf dem Router als Benutzer root folgendes Kommando ein:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Dieses Kommando bewirkt daß die "MSS" Option die beim Verbindungsaufbau zwischen dem Internet-Server und einer Clientmaschine Ihres Netzwerkes ausgetauscht wird vom Router "umgeschrieben" wird.

Möglichkeit 2: Umkonfiguration der Clientmaschinen

Falls Sie auf den Router keinen administrativen Zugriff haben können Sie auch die Clientmaschinen umkonfigurieren und die MSS für eine bestimmte Route festlegen.

  1. Verkleinern Sie die angebotete Segmentgröße mit der MSS Option des route Kommandos. Dazu können Sie z.B. die Datei /etc/route.conf wie folgt verändern:
    Steht bei Ihnen z.B.
    default          10.10.0.8          0.0.0.0   eth0
    
    setzen Sie ans Zeilenende einfach
    default          10.10.0.8          0.0.0.0   eth0 mss 1400
    
    um zum Beispiel die Segmentgröße auf 1400 Byte zu setzen (Normal: 1448 Byte).
    Vorteil: LAN Verbindungen erhalten die volle Packetgröße. Nur TCP Verbindungen zu entfernten Rechnern bekommen kleinere Paketgrößen vorgeschlagen.
    Nachteil: Bei falschen lokalem Setup gibt es evtl. trotzdem Problem (z.B. eine lokale, falsch konfigurierte Firewall). Funktioniert nicht für UDP (z.B. Realaudio, Netmeeting, Real-Video verwenden UDP).
  2. Verkleinern Sie die MTU der Netzwerkkarte. Dies können Sie z.B. in /etc/rc.config erledigen. Suchen Sie nach der Konfiguration des Netzwerkinterfaces in dieser Datei, die beispielsweise so aussehen kann:
    IFCONFIG_0="10.10.11.102 broadcast 10.10.255.255 netmask 255.255.0.0"
    
    und setzen Sie
    IFCONFIG_0="10.10.11.102 broadcast 10.10.255.255 netmask 255.255.0.0 mtu 1400" 
    
    ein um die MTU auf 1400 Byte zu begrenzen.
    Vorteil: Funktioniert sehr zuverlässig da auch die MSS Option richtig vorgeschlagen wird. Funktioniert auch für UDP Pakete.
    Nachteil: Alle Pakete werden kleiner. Damit wird der Overhead durch Header größer und damit der Durchsatz im lokalen Netz ein wenig geringer. Ist eher die "Holzhammermethode".
  3. Eine Variation der 1. Methode: Setzen Sie eine Route auf den/die "problematischen" Rechner den Sie nicht erreichen können mit einer verringerten Segmentgröße. Um zum Beispiel eine Route auf den Web-Server (213.95.15.200) der SuSE Linux AG mit einer MSS von 1400 Byte zu setzen nehmen Sie in /etc/route.conf folgende Zeile auf.
    213.95.15.200  10.10.0.8  255.255.255.255 eth0 mss 1400
    
    oder -temporär - an der Kommandozeile (root rechte erforderlich!)
    route add -host 213.95.15.200 gw 10.10.0.8 eth0 mss 1400
    

Hintergrund

Das "Hängenbleiben" der Verbindung ist nichts T-DSL spezifisches, sondern durch die kleinere zulässige MTU von T-DSL (durch PPPOE) bedingt. Die zulässige MTU kann auch verkleinert sein wenn Sie manche kommerziellen Einwahlrouter oder Windows als Router verwenden und andere Ethernet Frames statt normalen Ethernet_II Frames im LAN verwenden. Ebengleiches gilt für IP-over-IP oder CIPE Tunnel.

Die Netzwerkpakete die über diese Verbindungen geschickt werden müssen also ein bißchen kleiner sein als überall sonst üblich.

Kommt ein zu großes Paket an, so würde normalerweise passieren: Beim Eintritt des Paketes in die Strecke mit kleinerer MTU wird vom Router der die Netzwerkschnittstelle mit der kleineren MTU hat, transparent fragmentiert. Das Netzwerkpaket wird von diesem Router in mehrere, kleinere IP Pakete zerlegt die dann klein genug sind. Der Zielrechner setzt diese IP Fragmente wieder zusammen.

Diese transparente Fragmentierung ist eine enorme Belastung für die Backbone-Router des Internets die Ihre Pakete fragmentieren müssen (Im Falle von T-DSL wäre das z.B. der Router der Telekom). Um die Kosten für die Internet Infrastruktur zu senken wird bei modernen Betriebssystemen diese Belastung der Infrastruktur durch ein spezielles Flag in jedem IP Paket, das sog. "DF" (Don't fragment) Bit vermieden. Bei Linux wird dies seit Kernel Version 2.4 eingesetzt. Das ganze nennt sich Path MTU discovery und ist in RFC 1191 beschrieben.

Die Router die so ein großes Packet normalerweise fragmentieren müssten senden bei gesetztem DF bit im IP Paket eine ICMP (Internet Control message protocol)-Nachricht "ICMP: destination unreachable: need to fragment" an den Absender des großen Paketes zurück. Sogar mit Vorschlag einer neuen MTU. Das ursprüngliche Paket wird vom Router verworfen. Der absendende Rechner empfängt die ICMP Nachricht und verkleinert das Paket um es dann nochmals zu verschicken.

Kommt dieses ICMP Paket beim Absender nicht an, so bleibt die Verbindung hängen. Leider gibt es einige Betreiber von wichtigen Servern die davorliegende "Firewalls" falsch konfiguriert haben und diese ICMP Pakete wegwerfen. Das ist die eigentliche Ursache des Fehlers.

Die Verbindung bleibt scheinbar hängen, da beide Seiten denken es wäre lediglich ein Packet verloren gegangen und eine erneute Übertragung des unveränderten Paketes probieren - die aber natürlich wieder fehlschlägt.

Glossar

Frame: Mit Frame bezeichnet man den Rahmen eines Netzwerkpaketes. Damit die an der Datenübertragung beteiligten Rechner wissen woher und wohin ein Netzwerkpaket gehen soll und was da eigentlich drin ist, werden die Daten "verpackt". Diese "Verpackung" wird als Rahmen (engl. frame) bezeichnet und besteht bei Ethernet aus Ziel- und Quelladresse und dem Typ der enthaltenen Daten. Bei manchen Typen ist auch noch die Paketlänge gespeichert.
MSS: Maximum segment size. Die maximal zulässige Größe eines Segments. Dies ist eine Option einer TCP Datenverbindung die die zulässige Paketgröße beim Verbindungsaufbau festlegt. Die MSS kann für eine Route mit dem route Kommando festgelegt werden. Die MSS ist eng mit der MTU verwandt.
MRU: Maximum receive unit. Diese Einstellmöglichkeit haben Sie nur für PPP Verbindungen wo die Paketgröße beim Verbindungsaufbau ausgehandelt wird. Es gilt sinngemäß das gleiche wie für die MSS und die MTU.
MTU: Maximum transmit unit. Die maximal zulässige Größe eines Netzwerkpaketes in Byte. Normalerweise darf ein (Ethernet-) Netzwerkpaket maximal 1514 Byte groß sein. Daraus ergibt dann die für TCP/IP nutzbare MTU von 1500 Byte). Bei bestimmten Verfahren (Tunnel, PPPOE) wird die zulässige Größe kleiner, da ein Paket in einem anderen eingepackt wird. Bei der Verwendung von PPPOE darf ein Paket nur noch 1492 (Standard Ethernet II Frames), bzw. 1490 Byte groß sein.
PPPOE PPP over ethernet (Point to point protocol over ethernet) ist eine Erfindung die es der deutschen Telekom ermöglicht die bestehende Einwahlstruktur für Modem und ISDN Verbindungen auch für das nicht verbindungsorientierte DSL verwenden zu können. Beachten Sie die Informationsseite der Telekom hierzu.

Siehe auch:
o Internetverbindung: Manche Webseiten lassen sich nicht aufrufen
o Langsame Internetanbindungen effektiv nutzen

Stichwörter: PMTU, PATH, DISCOVERY, T-DSL, TDSL, FRAGMENTIERUNG, NEEDED

Kategorien: Internet

SDB-cg_pmtu2, Copyright SuSE Linux AG, Nürnberg, Germany - Version: 03. Nov 2001
SuSE Linux AG - Zuletzt generiert: 06. Mai 2002 von cg (sdb_gen 1.40.0)