Internetverbindungsprobleme - IPv6 MTU DNS - Versionsgeschichte

Gehrke: interne Verlinkung

2013-11-23T15:56:00Z

interne Verlinkung

Jengelh: /* IPv6 */ Grammatik

2008-01-29T20:35:05Z

‎IPv6: Grammatik

Jengelh am 28. Januar 2008 um 16:46 Uhr

2008-01-28T16:46:53Z

Jengelh: Extrem überarbeiten

2008-01-28T16:33:38Z

Extrem überarbeiten

Änderungen zeigen

Yehudi: /* Anmerkung */

2007-07-15T19:33:00Z

‎Anmerkung

Yehudi: /* DNS-Probleme */

2007-07-15T19:19:35Z

‎DNS-Probleme

Jengelh: alles

2007-06-03T15:31:11Z

alles

Yehudi: Netzwerk

2007-05-20T17:19:17Z

Netzwerk

Yehudi: /* DNS-Probleme */ Wikimäßig angepasst

2007-05-14T08:10:24Z

‎DNS-Probleme: Wikimäßig angepasst

Yehudi: /* MTU zu gross */ kleine Wikianpassungen

2007-05-14T08:05:39Z

‎MTU zu gross: kleine Wikianpassungen

@@ Zeile 129: / Zeile 129: @@
 == MSS (Maximum Segment Size) ==
-Wenn man einen eigenen Linux-basierten DSL-Router hat, dann besteht die Möglichkeit, dass dieser via ''iptables'' die Datenpakete (nur TCP!) an die MTU des eingehenden und ausgehenden Interfaces anpasst. Dazu muss das Firewallskript um folgende Zeile erweitert werden:
+Wenn man einen eigenen Linux-basierten DSL-Router hat, dann besteht die Möglichkeit, dass dieser via [[iptables]] die Datenpakete (nur TCP!) an die MTU des eingehenden und ausgehenden Interfaces anpasst. Dazu muss das Firewallskript um folgende Zeile erweitert werden:
   iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu

@@ Zeile 32: / Zeile 32: @@
   '''unreachable''' 2001::1 from :: dev lo  table unspec  proto none  src ::1  metric -1  '''error -101''' hoplimit 255
-Error 101 steht für "Network unreachable", d.h. das Zielnetzwerk in dem sich 2001::1 befindet, ist nicht erreichbar. Die meisten Programme&nbsp;- bzw. wird es sogar die zentrale glibc-Bibliothek sein die das intern behandelt&nbsp;- versuchen somit gar nicht erst, sich mit IPv6 zu verbinden, oder machen es zumindest ohne es dem Benutzer zu sagen, wie in diesem Test:
+Error 101 steht für "Network unreachable", d.h. das Zielnetzwerk in dem sich 2001::1 befindet, ist nicht erreichbar. Die meisten Programme&nbsp;- bzw. wird es sogar die zentrale glibc-Bibliothek sein, die das intern behandelt&nbsp;- versuchen somit gar nicht erst, sich mit IPv6 zu verbinden, oder machen es zumindest ohne es dem Benutzer zu sagen, wie der folgende Test zeigt:
   $ '''telnet netfilter.org 80'''

@@ Zeile 12: / Zeile 12: @@
 * ungelöste DNS-Probleme bei Routern
-Ihr solltet keineswegs einfach mal alles so abändern wie hier beschrieben. Es geht hier darum, einen Fehler einzukreisen und zu umgehen. Ein 'korrekt' arbeitendes System wird hierdurch nicht schneller.
+Ihr solltet keineswegs einfach mal alles so abändern wie hier beschrieben. Es geht hier darum, einen Fehler einzukreisen und zu umgehen. Dazu werden verschiedene Ansätze beschrieben, welche man ausprobieren kann (idealerweise in der Reihenfolge wie sie gleich erscheinen).
 == IPv6 ==
@@ Zeile 20: / Zeile 22: @@
 Viele Programme versuchen, sich bevorzugt mit einer IPv6-Adresse zu verbinden. Erst wenn dies fehlschlägt (nach einem Timeout) oder es keine IPv6-Adresse zu einem Hostnamen gibt, wird IPv4 verwendet.
-Sofern auf dem betroffenem Rechner nicht explizit eine IPv6-Adresse und -Routen konfiguriert wurden, gibt es nur die vom Linuxkernel automatisch angelegte Link Local-Adresse (<code>fe80::...</code> wenn man <code>/sbin/ip a</code> eingibt) und <code>fe80::</code>-Routen. Es fehlen 'normale' Routen und Standardgateway, sodass jeder Versuch, sich mit einer "dem Internet zugewiesenen" IPv6-Adresse zu verbinden (z.B. <code>2001::1</code>), sofort scheitert und IPv6 somit eigentlich keine Ursache für einen langsamen Verbindungsaufbau sein kann.
+Sofern auf dem betroffenem Rechner nicht explizit eine IPv6-Adresse und -Routen konfiguriert wurden, gibt es nur die vom Linuxkernel automatisch angelegte Link Local-Adresse (<code>fe80::...</code> wenn man <code>/sbin/ip a</code> eingibt) und <code>fe80::</code>-Routen. Es fehlen 'normale' Routen und Standardgateway, sodass jeder Versuch, sich mit einer für das Internet zugewiesenen IPv6-Adresse zu verbinden (z.B. <code>2001::1</code>), sofort scheitert und IPv6 somit eigentlich keine Ursache für einen langsamen Verbindungsaufbau sein kann.
 Um dies zu überprüfen, kann man folgendes in einer Konsole eingeben:
@@ Zeile 30: / Zeile 32: @@
   '''unreachable''' 2001::1 from :: dev lo  table unspec  proto none  src ::1  metric -1  '''error -101''' hoplimit 255
-Error 101 steht für "Network unreachable", d.h. das Zielnetzwerk in dem sich 2001::1 befindet, ist nicht erreichbar. Die meisten Programme - bzw. wird es sogar die zentrale glibc-Bibliothek sein die das intern behandelt - versuchen somit gar nicht erst, sich mit IPv6 zu verbinden, oder machen es zumindest ohne es dem Benutzer zu sagen, wie in diesem Test:
+Error 101 steht für "Network unreachable", d.h. das Zielnetzwerk in dem sich 2001::1 befindet, ist nicht erreichbar. Die meisten Programme&nbsp;- bzw. wird es sogar die zentrale glibc-Bibliothek sein die das intern behandelt&nbsp;- versuchen somit gar nicht erst, sich mit IPv6 zu verbinden, oder machen es zumindest ohne es dem Benutzer zu sagen, wie in diesem Test:
   $ '''telnet netfilter.org 80'''
@@ Zeile 44: / Zeile 46: @@
   Trying 2001:780:45:1d:20d:93ff:fe9b:e443...
-und bleibt dort für weniger als 10 Sekunden stehen, da mein Router auf IPv6 nicht reagiert. Wenn der Zielrechner nicht antwortet, kommt dann
+und bleibt dort für weniger als 10 Sekunden stehen, da mein Router nicht auf IPv6 reagiert. Wenn der Zielrechner nicht antwortet, kommt dann
   telnet: connect to address 2001:780:45:1d:20d:93ff:fe9b:e443: No route to host
@@ Zeile 51: / Zeile 53: @@
   Escape character is '^]'.
-Wie aber oben beschrieben sollte man eigentlich keine IPv6-Route ins Internet haben, wenn es nicht explizit konfiguriert ist - und explizit konfigurieren tut man nur dann, wenn man genau weiß, dass sowohl Router als auch Internetanbieter IPv6 vollständig unterstützen. Sollte der Router IPv6 unterstützen, der Internetanbieter aber nicht, sollte auch ein "Network unreachable" zurückkommen (diesmal vom Router).
+Wie aber oben beschrieben sollte man eigentlich keine IPv6-Route ins Internet haben, wenn es nicht explizit konfiguriert ist&nbsp;- und explizit konfigurieren tut man nur dann, wenn man genau weiß, dass sowohl Router als auch Internetanbieter IPv6 vollständig unterstützen. Sollte der Router IPv6 unterstützen, der Internetanbieter aber nicht, sollte auch ein "Network unreachable" zurückkommen (diesmal vom Router).
 == MDNS und Firewall ==
@@ Zeile 57: / Zeile 59: @@
 Im SUSE-Supportdatenbankartikel http://portal.suse.com/sdb/de/2003/10/90_mozilla_ipv6.html wird beschrieben, dass IPv6 und/oder DNS von SuSEfirewall2 blockiert wird.
-''Der Artikel ist ziemlich zweideutig!'' -Anm.v.~~
+(''Der Artikel ist ziemlich zweideutig! -Anm.v.[[Benutzer:Jengelh|j.engelh]]'')
 Daher ein paar alternative Erklärungsversuche. Wenn in <code>/etc/resolv.conf</code> keine IPv6-Adressen stehen, wird auch kein IPv6 zur Kontaktierung des DNS-Servers verwendet. Selbst wenn laut Artikel IPv6 gesperrt ist, würde die Namensauflösung nicht ins leere laufen. Zwar werden in den DNS-Antworten auch generell IPv6-Adressen mit zurückgegeben, diese aber entsprechend der vorigen Sektion bei Fehlen einer Route nicht verwendet.
-Allein Multicast DNS würde mir im Moment einfallen das zu Timeouts führen könnte, wenn es keinen MDNS-Server gibt, der antworten könnte. Hier kann man versuchen, die Zeroconf-Komponenten zu deaktivieren:
+Allein Multicast DNS würde mir im Moment einfallen, das zu Timeouts führen könnte, wenn es keinen MDNS-Server gibt, der antworten könnte. Hier kann man versuchen, die Zeroconf-Komponenten zu deaktivieren:
   /etc/init.d/avahi-dnsconfd stop
@@ Zeile 72: / Zeile 74: @@
 == IPv6 deaktivieren ==
-=== global (Kernelebene) ===
+Möchte man dennoch IPv6 global auf Kernelebene deaktivieren, so kann man dies über YaST bewerkstelligen, oder manuell in <code>/etc/modprobe.d/ipv6</code> nachtragen. Dort steht meistens schon
-Möchte man dennoch IPv6 deaktivieren, so kann man dies über YaST bewerkstelligen, oder manuell in <code>/etc/modprobe.d/ipv6</code> nachtragen. Dort steht meistens schon
+ #install ipv6 /bin/true
- #install ipv6 /bin/true
+Um IPv6 zu deaktivieren, ist das Kommentarzeichen <code>#</code> zu entfernen, sodass beim Versuch, <code>ipv6</code> zu laden stattdessen der Befehl <code>/bin/true</code> ausgeführt wird (der nichts tut).
-Um IPv6 zu deaktivieren, ist das <code>#</code> zu entfernen sodass nicht <code>ipv6</code> geladen wird, sondern der Befehl <code>/bin/true</code> ausgeführt wird (der nichts tut).
+Sollte auch dies keine Abhilfe schaffen, so kann man zusätzlich noch spezifisch auf Anwendungsebene Änderungen vornehmen, wie folgend beschrieben.
 === Konqueror ===
-wbast hat folgendes geschrieben:
+User wbast schreibt:
-Ich habe jetzt heraus gekriegt woran das lag. Und zwar versuchte bei mir der Konqueror(und nur der) IPv6-Adressen aufzulösen. Das habe ich im abgewöhnt mit einem
+Ich habe jetzt heraus gekriegt woran das lag. Und zwar versuchte bei mir der Konqueror (und nur der) IPv6-Adressen aufzulösen. Das habe ich i[h]m [mit einem]
   export KDE_NO_IPV6=1
-in der <code>~/.bashrc</code> gelöst.
+in der <code>~/.bashrc</code> [abgewöhnt].
 === Firefox ===
-geko hat folgendes geschrieben:
+User geko schreibt:
 Firefox aufrufen und in Adresszeile <code>about:config</code> eingeben. Folgenden Wert suchen:
@@ Zeile 108: / Zeile 110: @@
 Ethernetpakete haben eine maximale Nutzlast von 1500 Bytes, die für IP zur Verfügung stehen (alternativ 9000 Byte "Jumboframes" bei Gigabit); diesen Wert nennt man MTU, Maximal Transmission Unit. Kommt nun aber noch die zusätzliche PPP-Paketierung dazu, so reduziert sich dieser Wert um 8, lässt also 1492 nutzbare Bytes für IP. Siehe hierzu auch http://de.wikipedia.org/wiki/Maximum_Transmission_Unit .
-Dies gilt nicht nur für PPP, sondern generell bei allen Verkapselungen, also auch OpenVPN, IPsec, GRE und IP-in-IP.
+Dies gilt nicht nur für PPP, sondern generell auch bei allen Verkapselungen, also OpenVPN, IPsec, GRE, IP-in-IP, usw.
-Die Path MTU wird generell automatisch gefunden, es muss aber sichergestellt sein, dass ICMP von Firewalls '''nicht''' blockiert wird. Auch wenn die eigene Firewall ICMP erlaubt, können falsch konfigurierte Firewalls der Seitenbetreiber auf der Gegenseite für Probleme sorgen.
+Die Path MTU wird üblicherweise automatisch gefunden ("PMTU Discovery"), es muss aber sichergestellt sein, dass ICMP von Firewalls '''nicht''' blockiert wird. Damit ist nicht ICMP "ping" gemeint, sondern ICMP mit "fragmentation-needed" als Code. Auch wenn die eigene Firewall ICMP erlaubt, können falsch konfigurierte Firewalls der Seitenbetreiber für Probleme sorgen.
 Die Einstellung für die MTU befinden sich bei SuSE 9.1 tief versteckt im YaST in den Experteneinstellungen zur Netzwerkkarte:
@@ Zeile 125: / Zeile 127: @@
   _nm_name='bus-pci-0000:00:11.0'
-== MSS ==
+== MSS (Maximum Segment Size) ==
-Wenn man einen eigenen Linux-basierten DSL-Router hat, dann besteht die Möglichkeit daß dieser via ''iptables'' die Datenpakete (nur TCP!) an die MTU des eingehenden und ausgehenden Interfaces anpaßt. Dazu muß das Firewallskript um folgende Zeile erweitert werden:
+Wenn man einen eigenen Linux-basierten DSL-Router hat, dann besteht die Möglichkeit, dass dieser via ''iptables'' die Datenpakete (nur TCP!) an die MTU des eingehenden und ausgehenden Interfaces anpasst. Dazu muss das Firewallskript um folgende Zeile erweitert werden:
   iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu
 == Weitere Infos zum Thema 'MTU' gibt es hier ==

@@ Zeile 224: / Zeile 224: @@
 == Anmerkung ==
 {{Überarbeiten}}
 Dort gibt es noch eine weiterführende Diskussion, die habe ich nicht eingearbeitet:
 http://www.linux-club.de/ftopic16677.html

@@ Zeile 178: / Zeile 178: @@
   yast2 - Netzwerkdienste - DNS- und Hostname
-'''Nachtrag:''' Ein Fehler in der Datei <code>/etc/nsswitch.conf</code> kann dazu führen, dass DNS zur Namensauflösung gar nicht verwendet wird. Deshalb sicherheitshalber die Zeile 'hosts:' überprüfen. Eine i.A. funktionierende Variante ist:
   hosts: files dns
-'''Nachtrag:''' IPv6 für Konqueror abschalten
+== IPv6 für Konqueror abschalten ==
 wbast hat Folgendes geschrieben:
@@ Zeile 195: / Zeile 198: @@
 in der ~/.bashrc
 geko hat Folgendes geschrieben:

@@ Zeile 3: / Zeile 3: @@
 Zunächst einmal muss geklärt werden:
-ist die Datentransferrate niedrig (z.B. bei Downloads) oder dauert es ewig bis z.B. im Mozilla eine Seite aufgebaut wird ? Oder lassen sich bestimmte Seiten einfach nicht aufrufen ?
+ist die Datentransferrate niedrig (z.B. bei Downloads) oder dauert es ewig bis z.B. im Mozilla eine Seite aufgebaut wird? Oder lassen sich bestimmte Seiten einfach nicht aufrufen?
 Es gibt drei Standardursachen für dieses Problem (nicht notwendigerweise in dieser Reihenfolge):
-. TCP/IP v6 (abschalten)<br />
+# TCP/IP v6 (abschalten)
-. bei DSL ist die MTU zu groß<br />
+# bei DSL ist die MTU zu groß
-. Probleme mit dem DNS<br />
+# Probleme mit dem DNS
-Ihr solltet keineswegs einfach mal alles so abändern wie hier beschrieben. Es geht hier darum einen Fehler einzukreisen und zum umgehen. Ein 'korrekt' arbeitendes System wird hierdurch nicht schneller.
+Ihr solltet keineswegs einfach mal alles so abändern wie hier beschrieben. Es geht hier darum, einen Fehler einzukreisen und zu umgehen. Ein 'korrekt' arbeitendes System wird hierdurch nicht schneller.
 Der Reihe nach:
@@ Zeile 19: / Zeile 19: @@
-TCP/IP verwendet vier Bytes zur Adressierung von Rechnern. Durch das rasante Anwachsen des Internets besteht das Problem dass so langsam die Adressen ausgehen.
+TCP/IP verwendet vier Bytes zur Adressierung von Rechnern. Durch das rasante Anwachsen des Internets besteht das Problem, dass so langsam die Adressen ausgehen.
-Deswegen hat man einen Nachfolger definiert der 16 statt 4 Bytes für die Adressierung verwendet.
+Deswegen hat man einen Nachfolger definiert, der 16 statt 4 Bytes für die Adressierung verwendet.
 Details: http://de.wikipedia.org/wiki/Ipv6
-Wenn ipv6 aktiviert ist passiert es dass Linux zuerst versucht ipv6 und dann das 'gute alte' [[TCP/IP-Referenzmodell|TCP/IP]] zu benutzen. Da ipv6 momentan im Internet noch nicht benutzt wird kann man es auf dem Client abschalten.
+Wenn ipv6 aktiviert ist, passiert es, dass Linux zuerst versucht, ipv6 und dann das 'gute alte' ipv4 (([[TCP/IP-Referenzmodell|TCP/IP]])) zu benutzen. Da ipv6 momentan im Internet noch nicht flächendeckend benutzt wird, kann man es auf dem Client abschalten.
-Wie man ipv6 abschaltet steht in diesem Artikel der SuSE Supportdatenbank:
+Wie man ipv6 abschaltet, steht in diesem Artikel der SuSE Supportdatenbank:
 http://portal.suse.com/sdb/de/2003/10/90_mozilla_ipv6.html
@@ Zeile 36: / Zeile 36: @@
 Sobald sie irgendetwas in die Mozilla URL-Leiste eingeben friert Mozilla ein.
-Ursache
+Ursache:
-Mozilla versucht Namensauflösung zuerst über IPv6. Wenn Sie SuSEfirewall2 benutzen ist IPv6 allerdings komplett gesperrt. Deswegen läuft die Abfrage ins Leere und wartet auf einen Timeout von ca. 60 Sekunden.
+Mozilla versucht Namensauflösung zuerst über IPv6. Wenn Sie SuSEfirewall2 benutzen, ist IPv6 allerdings komplett gesperrt. Deswegen läuft die Abfrage ins Leere und wartet auf einen Timeout von ca. 60 Sekunden.
-Lösung
+Lösung:
 Sie können, wenn Sie ihn nicht benötigen, den IPv6 Support komplett abschalten.
@@ Zeile 101: / Zeile 101: @@
-MTU und DNS sind Hauptverdächtige wenn sich bestimmte Webseiten nicht aufrufen lassen.
+MTU und DNS sind Hauptverdächtige wenn sich bestimmte Webseiten nicht aufrufen lassen. Allerdings sind hier die Seitenbetreiber schuld[http://www.phildev.net/mss/].
 MTU = Maximum Transfer Unit
@@ Zeile 109: / Zeile 109: @@
 DSL verwendet hierzulande in der Regel das PPPoE Protokoll. PPP ist ein Protokoll zur Einwahl in TCP/IP-Netze das z.B. bei der Einwahl über Analog-Modem oder ISDN verwendet wird. PPPoE verwendet das PPP-Protokoll, nur eben über Ethernet und nicht Telefonleitung.
-Das Problem besteht nun darin dass Ethernet-Pakete eine maximale Paketgröße haben. Wenn man nun ein Ethernet-Paket in ein PPP-Paket verpackt und das wiederum in ein Ethernet-Paket steckt (so wie das bei PPPoE geschieht) dann wird der maximal nutzbare Teil des Paketes kleiner. Und dieser ist die MTU.
+Das Problem besteht nun darin, dass Ethernet-Pakete eine maximale Paketgröße haben. Wenn man nun ein Ethernet-Paket in ein PPP-Paket verpackt und das wiederum in ein Ethernet-Paket steckt (so wie das bei PPPoE geschieht) dann wird der maximal nutzbare Teil des Paketes kleiner. Und dieser ist die MTU.
 Eigentlich sollte das automatisch umgesetzt werden und ein zu großes Paket gesplittet werden. Da das nicht immer so funktioniert kann man das Problem umgehen indem man auf dem Client die MTU kleiner macht.
@@ Zeile 119: / Zeile 119: @@
 yast2- Netzwerkgeraete - Netzwerkkarte - ändern - Karte auswählen - Erweitert - Besondere Einstellungen - MTU
-Man kann aber auch (als root) die zugehörige Konfigurationsdatei in /etc/sysconfig/network selbst bearbeiten.
+Man kann aber auch (als root) die zugehörige Konfigurationsdatei in <code>/etc/sysconfig/network</code> selbst bearbeiten.
-Unter SuSE 9.0 heißen die:
+Unter SuSE 9.0 heißen diese <code>/etc/sysconfig/network/ifcfg-ethX</code>, wobei <code>ethX</code> hier als Platzhalter für <code>eth0</code>, <code>eth1</code> und so weiter steht.
- /etc/sysconfig/network/ifcfg-ethx
+Unter SuSE 9.1 heißen die Dateien etwas anders, <code>/etc/sysconfig/network/ifcfg-eth-id-00:00:39:c8:91:88</code> oder ähnlich. Hier wird die MAC-Adresse der Netzwerkkarte zur Identifikation verwendet.
 Da drin gibt es eine Zeile 'MTU='.
@@ Zeile 159: / Zeile 151: @@
-=== Weitere Infos zum Thema 'MTU' gibts hier ===
+=== Weitere Infos zum Thema 'MTU' gibt es hier ===
@@ Zeile 180: / Zeile 172: @@
-Es hat sich gezeigt dass manche [[DSL]]-[[Router]] Probleme mit der DNS-Weiterleitung haben.Der DSL-Router bekommt in der Regel bei der Einwahl über PPPoE die Adresse eines DNS-Servers des Providers dynamisch zugewiesen.Client-PCs wiederum verwenden dann als DNS-Server die IP-Adresse des DSL-Routers. Der DSL-Router soll DNS-Anfragen von Clients an den DNS-Server des Providers weiterleiten und ebenso die Antwort an den Client weiterreichen. Aus irgendwelchen mir unbekannten Gründen hakt es dabei immer wieder. Die Symptome sind nicht eindeutig - mal gehts, mal nicht, mal gehen bestimmte Seiten aber andere nicht. Es wurde auch schon mehrfach berichtet daß es unter Windows funktioniert, unter Linux aber nicht. Ich habe schon mal mit einem Firmwareupdate des DSL-Routers Besserung erzielen können. Eine Alternative ist es das Problem einfach zu umgehen und die Adresse eines DNS-Servers des Providers direkt beim Client einzutragen. Das stellt dann ein Problem dar wenn der Provider den DNS auf einen anderen Server umzieht oder bei mehreren DNS-Servern einer ausfällt. Da viele T-DSL über T-Online verwenden hier ein Link mit Adressen mehrerer DNS-Server von T-Online:
+Es hat sich gezeigt dass manche [[DSL]]-[[Router]] Probleme mit der DNS-Weiterleitung haben. Der DSL-Router bekommt in der Regel bei der Einwahl über PPP die Adresse eines DNS-Servers des Providers mitgeteilt. Client-PCs wiederum verwenden dann als DNS-Server die IP-Adresse des DSL-Routers. Der DSL-Router soll DNS-Anfragen von Clients an den DNS-Server des Providers weiterleiten und ebenso die Antwort an den Client weiterreichen. Aus irgendwelchen mir unbekannten Gründen hakt es dabei immer wieder. Die Symptome sind nicht eindeutig - mal gehts, mal nicht, mal gehen bestimmte Seiten aber andere nicht. Es wurde auch schon mehrfach berichtet, dass es unter Windows funktioniert, unter Linux aber nicht. Ich habe schon mal mit einem Firmwareupdate des DSL-Routers Besserung erzielen können. Eine Alternative ist es das Problem einfach zu umgehen und die Adresse eines DNS-Servers des Providers direkt beim Client einzutragen. Das stellt dann ein Problem dar, wenn der Provider den DNS auf einen anderen Server umzieht oder bei mehreren DNS-Servern einer ausfällt. Da viele T-DSL über T-Online verwenden hier ein Link mit Adressen mehrerer DNS-Server von T-Online:
 * http://atelier89.de/users/dirk/t-o/010.html
-Bei meinem DSL-Router kann man im Webinterface nachsehen welche DNS-Server er momentan benutzt. Der DNS-Server lässt sich auch so einstellen:
+Bei meinem DSL-Router kann man im Webinterface nachsehen, welche DNS-Server er momentan benutzt. Der DNS-Server lässt sich auch so einstellen:
   yast2 - Netzwerkdienste - DNS- und Hostname
-'''Nachtrag:''' Ein Fehler in der Datei /etc/nsswitch.conf kann dazu führen daß DNS zur Namensauflösung gar nicht verwendet wird. Deshalb sicherheitshalber die Zeile 'hosts:' überprüfen. Eine i.A. funktionierende Variante ist
+'''Nachtrag:''' Ein Fehler in der Datei <code>/etc/nsswitch.conf</code> kann dazu führen, dass DNS zur Namensauflösung gar nicht verwendet wird. Deshalb sicherheitshalber die Zeile 'hosts:' überprüfen. Eine i.A. funktionierende Variante ist:
   hosts: files dns

@@ Zeile 231: / Zeile 231: @@
 Dort gibt es noch eine weiterführende Diskussion, die habe ich nicht eingearbeitet:
 http://www.linux-club.de/ftopic16677.html
-eingefügt von --[[Benutzer:Yehudi|Yehudi]] 08:52, 12. Sep 2006 (CEST)
+----
-[[TCP/IP-Netzwerke und Internetzugang]][[Category:TCP/IP]]

@@ Zeile 122: / Zeile 122: @@
 Unter SuSE 9.0 heißen die:
-Code:
   /etc/sysconfig/network/ifcfg-ethx
@@ Zeile 153: / Zeile 153: @@
 Wenn man einen eigenen linuxbasierten DSL-Router hat dann besteht die Möglichkeit daß dieser via iptables die Datenpakete an die MTU anpaßt. Dazu muß das Firewallskript erweitert werden um folgende Zeile:
-Code:
   iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
@@ Zeile 163: / Zeile 163: @@
 Ermitteln des optimalen MTU Wertes:
-http://www.gschwarz.de/mtu-wert.htm
+* http://www.gschwarz.de/mtu-wert.htm
 Internetverbindung: Manche Webseiten lassen sich nicht aufrufen:
@@ Zeile 169: / Zeile 169: @@
 MTU optimieren:
-http://gw.renner.bei.t-online.de/windowsxp/mtu.htm
+* http://gw.renner.bei.t-online.de/windowsxp/mtu.htm
 MTU-Mini-FAQ (für xDSL-Zugänge über PPPoE)
-http://www.sauff.com/dsl-faq/mtu-mini-faq.html
+* http://www.sauff.com/dsl-faq/mtu-mini-faq.html
 Lexikonbeschreibung MTU
-http://de.wikipedia.org/wiki/Maximum_Transfer_Unit
+* http://de.wikipedia.org/wiki/Maximum_Transfer_Unit
 == DNS-Probleme ==