Nur ein MTU Problem ??
Andreas Marx
Konfiguration: Laptop mit XP,Router Draytek 2500WE + WLAN Card Vigor 520,
DSL über 1&1
Das Problem: Ebay Zugang, WEB.de mail versenden etc.nicht möglich!
Gelesen habe ich schon einiges bezüglich der MTU Werte, habe auch
verschiedene eingestellt (per DFÜ Speed) so u.a. 1492,1480,1442 - es hilft
nichts. Meine Fragen nun: Reicht es wenn ich die MTU Werte auf die
beschriebene Weise mit DFÜ Speed in der registry ändere oder muss dies auch
noch woanders geschehen? Müssen noch andere Werte analog dazu geändert
werden und wenn ja wo? Oder gibt es eine andere Lösung für Ebay und Co.?
Vielen Dank!
Gruß Andreas
Alexander Greisle
> noch woanders geschehen? Müssen noch andere Werte analog dazu geändert
> werden und wenn ja wo? Oder gibt es eine andere Lösung für Ebay und Co.?
Du hast das nur am PC eingestellt? Das reicht tatsächlich noch nicht, Du
musst das am Router tun. Leider geht das nur über telnet.
Dazu in der Kommandozeile:
- telnet <Router-IP>
- Router-Passwort
- wan mtu ? (zeigt aktuell eingestellten Wert)
- wan mtu 1492 (stellt den neuen Wert ein)
Bei mir klappts mit 1492.
--
Beste Grüsse,
alex :-)
Hans-Georg Michna
Alexander,
die eingestellte MTU muss lediglich am Computer kleiner oder
gleich der MTU der gesamten Verbindungsstrecke inclusive des
Routers sein.
Dazu braucht man am Router keine MTU einzustellen, denn die ist
schon eingestellt.
Hans-Georg
--
No mail, please.
Andreas Marx
Sorry ich bin relativer Laie deshalb die Nachfrage. Ich konfiguriere meinen
Router über den Browser. Heißt das ich brauche ein extra Programm um den MTU
Wert am Router zu ändern oder geht es auch über den Browser?
Danke, Andreas
Matthias Ender
> Sorry ich bin relativer Laie deshalb die Nachfrage. Ich konfiguriere meinen
> Router über den Browser. Heißt das ich brauche ein extra Programm um den MTU
> Wert am Router zu ändern oder geht es auch über den Browser?
Nicht unbedingt. kenne Deinen Router leider nicht genauer aber bei meinem
Belkin Router kann ich dort wo ich die Verbindungsdaten eingebe auch den
MTU Wert eingeben.Meiner ist 1454 und bei mir gibt es keine Probleme damit.
> Danke, Andreas
Matthias
Nicole Hornung
> die eingestellte MTU muss lediglich am Computer kleiner oder
> gleich der MTU der gesamten Verbindungsstrecke inclusive des
> Routers sein.
Mit Verlaub, Hans-Georg, das ist bei einem richtigen
Router natuerlich Kaese. Hat man einen Router, so ist
dieser i.d.R. Bestandteil eines Ethernet-LAN. Im Ethernet
ist eine MTU von 1500 als richtig anzusehen. Ein guter
Router packt die Pakete bei der NAT um, d.h. er benutzt
WAN-seitig die dort meistens vorgegebene MTU von 1492
und im LAN selbstverstaendlich 1500. Alles andere ist
in einer Standardumgebung kontraproduktiv. Am Client
(Arbeitscomputer) ist die MTU also nicht zu veraendern,
sondern muss bei den fuers Ethernet optimalen MTU von
1500 stehen bleiben.
Gruss
Nicole
--
Zehn Deutsche sind natürlich dümmer als fünf Deutsche.
[Heiner Müller]
Nicole Hornung
telnet ist bei _jedem_ Windows mit installiertem TCP/IP
Protokoll selbstverstaendlich dabei.
Wie Alexander schrubbte:
| Dazu in der Kommandozeile:
| - telnet <Router-IP>
| - Router-Passwort
| - wan mtu ? (zeigt aktuell eingestellten Wert)
| - wan mtu 1492 (stellt den neuen Wert ein)
Also ein DOS-Box oeffnen (Eingabeaufforderung) und die
Kommandos wie o. a. (ohne "-") eintippen und mit <ENTER>
bestaetigen.
Gruss
Nicole
--
Mir sind auch schon vernuenftige Realnamentraeger ueber den Weg
gelaufen. <eg>
[Karl Ernst Roehl in de.soc.netzkultur]
Alexander Greisle
> die eingestellte MTU muss lediglich am Computer kleiner oder
> gleich der MTU der gesamten Verbindungsstrecke inclusive des
> Routers sein.
ACK. Ist bei 1492 ja auch so ;-) (siehe zum Wert auch weiter unten).
Machen wir es mal konkreter, da der OP ja offensichtlich ein Problem mit
den üblichen Verdächtigen (eBay, GMX, web.de, einige Online-Banker) hat.
Auf dem Router, der ja für die Einwahl zuständig ist, wird die MTU für
das DialUp (RAS) eingestellt. Auf dem Client muss es die MTU für den
verwendeten Netzwerkadapter sein. Letzteres ist wichtig, da man auch auf
dem Client die MTU für das DialUp (RAS) eingestellt werden kann - nur
bringt das halt nichts, da der Client dafür nicht zuständig ist.
Bei meiner Konfiguration, die bis auf die WLAN-Card identisch ist,
klappt es mit 1492 auf Router. MTU des Netzwerkadapters auf Desktop
1492, auf Notebook 1480. Wenn ich mich recht erinnere, war mein Draytek
auf eine MTU von 1442 vorkonfiguriert - zumindest hat es auch nicht
geklappt mit eBay.
Bewährt haben sich folgende MTU-Werte:
T-Com (u.a. 1&1): 1492
AOL: 1400
Freenet/Mediaways (noch nicht selbst getestet): 1454
Am Client kann die Settings übrigens recht komfortabel mit DrTCP
(http://www.dslreports.com/drtcp) machen. Aufpassen, dass man die
richtige MTU (Netzwerkadaper) einstellt.
Wichtig ist das Neustarten des Rechners damit die Einstellung aktiv
werden.
> Dazu braucht man am Router keine MTU einzustellen, denn die ist
> schon eingestellt.
Siehe dritter Spiegelstrich und Anmerkung oben.
Andreas Marx
> Kommandos wie o. a. (ohne "-") eintippen und mit <ENTER>
> bestaetigen.
Merci! Ich werde mich mal mit den gemachten Vorschlägen versuche. Mal sehen
was herauskommt.
Was mich als Laien nur verwundert ist das x-versch. Leute mit x-versch.
MTU's arbeiten und Jeder in einer anderen Kombination "Glück" hat mit den
Sorgenkindern Ebay und Co.. Ist denn das Problem nicht eigentlich auf deren
Seite (...und Co.) zu suchen, sprich eigentlich müsste eine
Standardkombination/MTU Wert beim Zugang funktionieren oder besser gesagt
von deren Servern/Firewalls durchgelassen werden und bei jedem ein anderes
Package. (Ich hoffe es ist nicht eine ganz so dämliche Laienfrage, aber das
verstehe ich wirklich nicht so recht).
Andreas
Andreas Marx
1480 (Adapter) hat Ebay mich "reingelassen" ...aber es hat ziemlich lange
gedauert. Frage: Bringt es jetzt was den Wert am Adapter weiter
herunterzusetzen um den Zugang zu beschleunigen (und wenn ja in welchen
Schritten) oder ist das sinnlos?
Andreas
Alexander Greisle
> gedauert. Frage: Bringt es jetzt was den Wert am Adapter weiter
> herunterzusetzen um den Zugang zu beschleunigen (und wenn ja in welchen
> Schritten) oder ist das sinnlos?
Hast Du den Wert am Adapter schon mal auf 1492 gesetzt? Was war der
Effekt?
Hans-Georg Michna
>Hans-Georg Michna schrub:
>> die eingestellte MTU muss lediglich am Computer kleiner oder
>> gleich der MTU der gesamten Verbindungsstrecke inclusive des
>> Routers sein.
>Mit Verlaub, Hans-Georg, das ist bei einem richtigen
>Router natuerlich Kaese. Hat man einen Router, so ist
>dieser i.d.R. Bestandteil eines Ethernet-LAN. Im Ethernet
>ist eine MTU von 1500 als richtig anzusehen. Ein guter
>Router packt die Pakete bei der NAT um, d.h. er benutzt
>WAN-seitig die dort meistens vorgegebene MTU von 1492
>und im LAN selbstverstaendlich 1500. Alles andere ist
>in einer Standardumgebung kontraproduktiv. Am Client
>(Arbeitscomputer) ist die MTU also nicht zu veraendern,
>sondern muss bei den fuers Ethernet optimalen MTU von
>1500 stehen bleiben.
Nicole,
das hat aber den großen Nachteil, dass jedes Paket, das 1500
Byte lang ist und über den Router läuft, von diesem in zwei
zerhäckselt werden muss, es sei denn, die automatische
MTU-Erkennung funktioniert in den Clients (was sie leider nicht
immer tut).
Deswegen ist es besser, die MTU auf allen Clients zu reduzieren,
zumal eine Reduktion um 8 Byte die Performance nur sehr wenig
verringert.
Hans-Georg Michna
Andreas,
die Frage ist sehr berechtigt. Eine Antwort ist, dass die
meisten Computer, genauer gesagt, IP Stacks, die Fähigkeit
haben, die MTU zum gewünschten Ziel selber zu entdecken. Ich
glaube, dazu wird das Protokoll ICMP verwendet, kenne mich aber
in den Details auch nicht aus.
Das Problem dabei ist, dass der eine oder andere Router oder
Server auf ICMP nicht reagiert und daher für diesen Zweck ein
sogenanntes Black Hole darstellt. Black Hole Detection ist zwar
auch eine Funktion vieler IP-Stacks, ist aber z.B. in Windows
per Default deaktiviert. (Bei XP bin ich mir nicht ganz sicher,
glaube aber eher, dass es auch dort nicht aktiviert ist.) Man
kann das von Hand aktivieren, mit Regedit.
Aber MTU Discovery und besonders das eventuell notwendige Teilen
längerer Pakete braucht auch Zeit, so dass man besser fährt,
wenn man die richtige MTU schon vorher einstellt.
Wenn man sich nicht sicher ist, kann man im Computer einfach
eine recht kurze MTU einstellen, z.B. 1440 Byte. Dann
funktioniert es mit allerhöchster Wahrscheinlichkeit überall und
man verliert vielleicht geschätzte 1% Performance. (Die kürzeren
Pakete laufen ja auch in weniger Zeit durch, deswegen sind es
keine 3%.)
Andreas Marx
>Hast Du den Wert am Adapter schon mal auf 1492 gesetzt? Was >war der
>Effekt?
Ja, ich hatte auch beide Werte auf 1492 gesetzt, da blieb ich aber zumindest
bei Ebay "ausgesperrt". Erst als ich am Adapter reduziert habe ging es
halbwegs (aber eben immer noch mit erheblicher Verzögerung)
Andreas
Andreas Marx
> Wenn man sich nicht sicher ist, kann man im Computer einfach
> eine recht kurze MTU einstellen, z.B. 1440 Byte. Dann
> funktioniert es mit allerhöchster Wahrscheinlichkeit überall und
> man verliert vielleicht geschätzte 1% Performance.
Gibt es eigentlich eine Faustformel in welchen Schritten man in punkto MTU
arbeiten sollte oder kann man "frei" reduzieren ohne bestimmte steps
beachten zu müssen (also beispielsweise "krumme" Werte wie 1443) bzw. macht
es vielleicht keinen Sinn und hat keinen Effekt wenn man z.B. nur kleine
Schritte macht?
Gruß Andreas
Alexander Greisle
> Gibt es eigentlich eine Faustformel in welchen Schritten man in punkto MTU
> arbeiten sollte oder kann man "frei" reduzieren ohne bestimmte steps
> beachten zu müssen (also beispielsweise "krumme" Werte wie 1443) bzw. macht
> es vielleicht keinen Sinn und hat keinen Effekt wenn man z.B. nur kleine
> Schritte macht?
Das generelle Vorgehen ist so, dass man die MTU solange runtersetzt,
bis die IP-Pakete unfragmentiert ankommen. Das sieht dann
beispielsweise so aus:
|c:>\ping www.heise.de -f -l 1492
|
|Ping www.heise.de [193.99.144.71] mit 1492 Bytes Daten:
|
|Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
|Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
|Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
|Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
|
|Ping-Statistik für 193.99.144.71:
|Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),
Dann setzt man die MTU solange runter (10 Schritte), bis das Ergebnis
so aussieht:
|c:\>ping www.heise.de -f -l 1462
|
|Ping www.heise.de [193.99.144.71] mit 1464 Bytes Daten:
|
|Antwort von 193.99.144.71: Bytes=1464 Zeit=168ms TTL=248
|Antwort von 193.99.144.71: Bytes=1464 Zeit=166ms TTL=248
|Antwort von 193.99.144.71: Bytes=1464 Zeit=166ms TTL=248
|Antwort von 193.99.144.71: Bytes=1464 Zeit=165ms TTL=248
|
|Ping-Statistik für 193.99.144.71:
|Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
|Ca. Zeitangaben in Millisek.:
|Minimum = 165ms, Maximum = 168ms, Mittelwert = 166ms
Und nun in 1-er Schritten nach oben, bis man das nächste Mal
fragmentierte Pakete bekommt. Dann ist die letzte MTU ohne
fragmentierte die optimale. Egal, wie "krumm" die ist.
So kommst Du an die optimale MTU.
Wenn Du das durchmachen willt, solltest Du _nicht_ eBay nehmen, die
verwerfen den Ping.
Andreas Marx
Danke für den Tip. Ich habe das gleich mal gemacht und es sieht so aus:
C:\>ping www.heise.de
Ping www.heise.de [193.99.144.71] mit 32 Bytes Daten:
Antwort von 193.99.144.71: Bytes=32 Zeit=67ms TTL=246
Antwort von 193.99.144.71: Bytes=32 Zeit=70ms TTL=246
Antwort von 193.99.144.71: Bytes=32 Zeit=70ms TTL=246
Antwort von 193.99.144.71: Bytes=32 Zeit=69ms TTL=246
Ping-Statistik für 193.99.144.71:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 67ms, Maximum = 70ms, Mittelwert = 69ms
Wenn ich das richtig interpretiere ist das o.k., oder deute ich das falsch?
Andreas
Andreas Marx
Noch als Zusatz: Ich hatte beim ersten mal vergessen die Parameter wie von
Dir angegebenen beim Ping anzufügen.
Beim 2.Mal habe ich es gemacht -f -11492, aber komischerweise kommt wieder
die gleiche Statistik zurück Bytes=32
Wie muss ich das deuten (ist etwas bei mir was falsch konfiguriert)?
Andreas
Florian Bannasch
> Noch als Zusatz: Ich hatte beim ersten mal vergessen die Parameter wie von
> Dir angegebenen beim Ping anzufügen.
> Beim 2.Mal habe ich es gemacht -f -11492, aber komischerweise kommt wieder
> die gleiche Statistik zurück Bytes=32
Nicht -11492 sondern -l 1492
^- das soll ein kleines L sein.
HTH, Florian
Andreas Marx
Andreas Marx
bekommen:
C:\>ping www.heise.de -f-l1492
Ping www.heise.de [193.99.144.71] mit 32 Bytes Daten:
Antwort von 193.99.144.71: Bytes=32 Zeit=71ms TTL=246
Antwort von 193.99.144.71: Bytes=32 Zeit=80ms TTL=246
Antwort von 193.99.144.71: Bytes=32 Zeit=70ms TTL=246
Antwort von 193.99.144.71: Bytes=32 Zeit=70ms TTL=246
Ping-Statistik für 193.99.144.71:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 70ms, Maximum = 80ms, Mittelwert = 72ms
Was läuft falsch? Ich erhalte immer nur ein Ergebnis mit 32 Byte.
Andreas
Martin Bodenstedt
> Jetzt habe ich es wie beschrieben gemacht und wieder folgendes Ergebnis
> bekommen:
>
> C:\>ping www.heise.de -f-l1492
>
ein Leerzeichen zwischen -l 1492...
--
Martin Bodenstedt
Landtag von Baden-Württemberg (www.landtag-bw.de)
Nicole Hornung
> das hat aber den grossen Nachteil, dass jedes Paket, das
> 1500 Byte lang ist und ueber den Router laeuft, von diesem
> in zwei zerhaeckselt werden muss, es sei denn, die
> automatische MTU-Erkennung funktioniert in den Clients (was
> sie leider nicht immer tut).
Diese Annahme ist richtig fuer _ein_ _einzelnes_ Paket von
1500 Byte, das geroutet werden soll. Dieser Fall tritt wohl
eher selten ein. Die automagische MTU-Erkennung hat aber auf
diese Funktion keinen Einfluss. Sie sorgt lediglich dafuer,
dass auf einem Interface, sofern vom Protokoll unterstuetzt,
die richtige Paketgroesse verschickt wird. Normalerweise
besteht eine Anfrage an einen beliebigen Client ins Internet
und die Antwort darauf aus einer Vielzahl von Paketen. Ein
Router sollte die die ankommenden Pakete auspacken, in einen
Puffer stellen und entsprechend der MTU des Interfaces, auf
das sie ausgegeben werden, neu verpacken.
Beispiel: 80 Pakete mit 1492 und 1 Paket mit 584 Byte (also
insgesamt 81 Pakete mit 119944 Byte [117,13 kB]) auf einem
PPPoE-Interface werden dabei in 79 Pakete zu 1500 und 1
Paket zu 1444 Byte fuers Ethernet verpackt, nach dem Routing
sind also nur noch 80 Pakete weiterzuleiten. So wird das
zumindest unter Linux gemacht (viele Router arbeiten ja mit
einem Linux-Kern). Deshalb ist reines Ethernetrouting auch
problemlos mit einer schwachbruestigen CPU (386er) zu
schaffen, da das rechenintensive "Umpacken" der Pakete wie
beim PPPoE-Routing entfaellt.
> Deswegen ist es besser, die MTU auf allen Clients zu reduzieren,
Ein "Ich-verschicke1492-plus8-Byte-Pakete-Router" braeuchte
natuerlich fuer optimalen Datendurchsatz auf beiden
Interfaces die gleiche Paketgroesse. Wuerde er die Pakete
nur fragmentieren ohne neu zu packen, wuerde sich beim
Routing Ethernet -> PPPoE die Paketanzahl verdoppeln
(eigentlich 2n -1). Ich befuerchte, dass es schon einige
$Billigteile gibt, die so arbeiten. Von diesen ist deswegen
allein schon wegen der Konzeption abzuraten.
> zumal eine Reduktion um 8 Byte die Performance nur sehr wenig
> verringert.
Die Performance im Ethernet kann gewaltig einbrechen, wenn
auf einigen Clients MTUs von 1492 und auf anderen (die
vielleicht nicht ins Internet duerfen) eine MTU von 1500
eingestellt ist. Zur Vermeidung von solchen vermeidbaren
Problemen empiehlt es sich, einen gegebenen Standard
einzuhalten.
Ein interessantes Rechenbeispiel zur MTU findet sich hier:
http://www.debianforum.de/wiki/?page=Die+Optimale+MTU+f%FCr+ADSL
Ich weise auf diesen Artikel hin, obgleich ich Probleme
habe, der dort aufgemachten Rechnung zu folgen, ich sehe
hier einen logischen Fehler bei der Konzeption der DSLAMs
und der Umsetzung auf ATM. Trotzdem kann der Artikel zum
Verstaendnis der MTU beitragen. Vielleicht sollte man auch
mal auf die guten Dokumentationen bei
http://www.juniper.net/ hinweisen, dort kauft $Sie-nehmen-s
viel der Hardware ein, die letztendlich beim Konzern mit dem
$T eingesetzt wird (ja, ja, es gibt auch viel von
http://www.ecitele.com/ und von http://www.orckit.com/ und
von...). Aber das gehoert dann wohl in einen anderen Fred...
Gruss
Nicole
--
Wenn die Regulars in einer Gruppe sich einig sind, dann elchen
die Elche sich gegenseitig an und sind beschaftigt.
[Oliver Gassner, de.admin.news.groups, 23.1.2000]
Marc Haber
>Beispiel: 80 Pakete mit 1492 und 1 Paket mit 584 Byte (also
>insgesamt 81 Pakete mit 119944 Byte [117,13 kB]) auf einem
>PPPoE-Interface werden dabei in 79 Pakete zu 1500 und 1
>Paket zu 1444 Byte fuers Ethernet verpackt, nach dem Routing
>sind also nur noch 80 Pakete weiterzuleiten. So wird das
>zumindest unter Linux gemacht (viele Router arbeiten ja mit
>einem Linux-Kern). Deshalb ist reines Ethernetrouting auch
>problemlos mit einer schwachbruestigen CPU (386er) zu
>schaffen, da das rechenintensive "Umpacken" der Pakete wie
>beim PPPoE-Routing entfaellt.
Woran weiss der Router, dass nix mehr nachkommt und er die im Puffer
liegenden Daten jetzt verschicken kann? Fragmentierung ist eine
Funktion von IP, und IP ist datagramm-basiert. Somit würde ich
erwarten, dass zwei Pakete mit 1500 Byte auf einer MTU-1490-Strecke in
vier Paketen übertragen werden.
Würde das wirklich so funktionieren wie Du beschrieben hast, wäre ich
_sehr_ überrascht. Ich kann das aber im Moment nicht ausprobieren.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Andreas Marx
Ist das nicht ein bischen niedrig? Der Router steht bei 1492.
Andreas
Manfred Kwiatkowski
Nicole Hornung <20040...@nicocom.de> writes:
> [...] Ein
>Puffer stellen und entsprechend der MTU des Interfaces, auf
>das sie ausgegeben werden, neu verpacken.
Aus RFC 1812 Requirements for IP Version 4 Routers:
5.2.6 Fragmentation and Reassembly: RFC-791 Section 3.2
As was discussed in Section [4.2.2.7], a router MUST support IP
fragmentation.
A router MUST NOT reassemble any datagram before forwarding it.
--
Manfred Kwiatkowski kwiat...@zrz.tu-berlin.de
Nicole Hornung
> Woran weiss der Router, dass nix mehr nachkommt und er die
> im Puffer liegenden Daten jetzt verschicken kann?
Ein Datagramm hat eine 16bit Kennung. Jedes Fragment bei der
Uebertragung dieses Datagrammes enthaelt diese Kennung.
Ausserdem stehen dort auch noch Fragment-Offset und ein Flag,
ob noch weitere Pakete zu diesem Datagramm gehoeren (More-
Flag). Anhand dieser Headerdaten kann ein Router die
Nutzdaten dieser Pakete in einen Puffer schreiben und neu
packen. In einem LAN kommen die Pakete in der korrekten
Reihenfolge an, da es ja nur das sendende und empfangende
Interface und somit keine Laufzeitunterschiede gibt. Es
wird solange in den FIFO-Puffer geschrieben bis ein Paket
ohne gesetztes More-Flag kommt.
> Somit wuerde ich > erwarten, dass zwei Pakete mit 1500 Byte
> auf einer MTU-1490-Strecke in > vier Paketen uebertragen
> werden.
Das ist sicher auch so, wenn die Router nicht auch
gleichzeitig Endpunkte der IP-Verbindung sind. Die Pakete
werden dann natuerlich jeweils soweit fragmentiert, wie dies
die naechste Netzstrecke erfordert. Bei DSL duerften die
ATM-Fragmente des DSLAMs wohl schon so klein sein, dass
keine weitere Fragmentierung mehr erfolgt.
> Wuerde das wirklich so funktionieren wie Du beschrieben
> hast, wäre ich _sehr_ ueberrascht. Ich kann das aber im
> Moment nicht ausprobieren.
Da ein IP-Paket bei der Routenwahl frei ist und somit
Fragmente eines Datagramms unterschiedliche Wege nehmen
koennen, werden diese Fragmente nicht wieder
zusammengesetzt, bevor sie ihren Empfaenger erreicht haben.
Wuerde die Pufferung und Defragmentierung bei jedem Router
stattfinden, so wuerde nie etwas ankommen, wenn die
Fragmente unterschiedliche Routen nehmen. Gelangen Sie aber
an einen Router, der NAT betreibt, so werden die Fragmente
wieder bis zu ihrer urspruenglichen Datagrammgroesse
defragmentiert, mit der neuen Zieladresse versehen und dann
weitergeschickt. Dies passiert, da ja die Header bis zur
Anwendungsschicht dekodiert werden (sonst waere kein
Portforwarding moeglich) und neu geschrieben werden muessen.
Insofern muss ich meine Aussage aus
<news:bv2qec$h0l$05$1...@news.t-online.com> korrigieren bzw.
auf Router mit NAT einschraenken. Bei dieser Diskussion hier
bin ich von NAT ausgegangen. Deine Nachfrage weckte in mir
allerdings Zweifel, ob das alle NAT-Router so machen, sonst
wuerde es ja nicht staendig hier diese Berichte ueber Black-
Holes geben. Ausserdem bin ich mir mittlerweile unsicher, ob
aus- und eingehende Pakete hier unterschiedlich verarbeitet
werden und wenn ja, wie.
Hm, vielleicht gibt es hier ja jemanden, der sich besser
damit auskennt?
Gruss
Nicole
--
Niemand verbietet pseudonymes Posten. Die Schreiberlinge muessen sich
jedoch darueber klar sein, dass sie hier im allgemeinen nicht ernst
genommen werden und bei vielen im Killfile landen. That's life.
[Sabine Becker in de.soc.netzkultur]
Ulrich Moellmann
> Hallo!
> Konfiguration: Laptop mit XP,Router Draytek 2500WE + WLAN Card Vigor 520,
> DSL über 1&1
> Das Problem: Ebay Zugang, WEB.de mail versenden etc.nicht möglich!
> Gelesen habe ich schon einiges bezüglich der MTU Werte, habe auch
> verschiedene eingestellt (per DFÜ Speed) so u.a. 1492,1480,1442 - es hilft
> nichts. Meine Fragen nun: Reicht es wenn ich die MTU Werte auf die
> beschriebene Weise mit DFÜ Speed in der registry ändere oder muss dies auch
> noch woanders geschehen? Müssen noch andere Werte analog dazu geändert
> werden und wenn ja wo? Oder gibt es eine andere Lösung für Ebay und Co.?
> Gruß Andreas
Hallo,
bei mir lage es an etwas Anderem. Vielleicht hilft es ja.
Meine Konfiguration Draytek2500WE, WLAN abgeschaltet, IP fest
vergeben, DSL ueber 1&1. Unter Windows die Router-IP als Gateway und
DNS-Server eingetragen.
Ebay war langsam und Google konnte ich gar nicht erreichen.
Habe dann einen Tip gefunden der in eine andere Richtung ging:
http://www.dsl-webseiten.de/forum/showthread.php?s=&threadid=2051
Darunter war ein Hinweis zu finden, das man einen zweiten Eintrag als
DNS-Server eintragen koennte.
Ich habe als ersten DNS-Server meinen Router angegeben und als zweiten
die IP 194.25.2.129
Die habe ich aus der Liste (fuer 1&1):
http://www.fli4l.de/german/dns.htm
Seitdem kann ich die Seiten erreichen.
Gruss Ulrich
C. Smolne
Bei mir waren es die Google-Groups und die Windows-Update-Seite ;-)
> bei mir lage es an etwas Anderem. Vielleicht hilft es ja.
Bei mir auch.
> Meine Konfiguration Draytek2500WE, WLAN abgeschaltet, IP fest
> vergeben, DSL ueber 1&1. Unter Windows die Router-IP als Gateway und
> DNS-Server eingetragen.
WLAN funktioniert schon, auch mit 128 Bit Verschlüsselung. Bei mir lag
es wohl daran, dass ich meine WLAN-SSID umbenannt hatte und sie außerdem
verborgen hatte.
> Ich habe als ersten DNS-Server meinen Router angegeben und als zweiten
> die IP 194.25.2.129
Vom 1&1-Support habe ich folgende Angaben:
IP-Adressen fest vergeben
Subnetz-Maske [255.255.255.0]
Standard-Gateway [Adresse des Routers]
DNS1 [195.20.224.234]
DNS2 [194.25.2.129]
Man wollte mir eine ziemlich niedrige MTU anbieten, hat aber nichts
gebracht, also fahre ich jetzt wieder mit 1492 am Client.
Viel Erfolg,
--
Carmen
Steffen Leist
> Hallo!
> Konfiguration: Laptop mit XP,Router Draytek 2500WE + WLAN Card Vigor
> 520, DSL über 1&1
> Das Problem: Ebay Zugang, WEB.de mail versenden etc.nicht möglich!
> Gelesen habe ich schon einiges bezüglich der MTU Werte, habe auch
> verschiedene eingestellt (per DFÜ Speed) so u.a. 1492,1480,1442 - es
> hilft nichts. Meine Fragen nun: Reicht es wenn ich die MTU Werte auf
> die beschriebene Weise mit DFÜ Speed in der registry ändere oder
> muss dies auch noch woanders geschehen? Müssen noch andere Werte
> analog dazu geändert werden und wenn ja wo? Oder gibt es eine andere
> Lösung für Ebay und Co.? Vielen Dank!
> Gruß Andreas
>
Hallo NG,
ich muss ehrlich gestehen, daß mir die ganze MTU Geschichte langsam
gehörig auf den Nerv geht.
Nach langen Experimenten mit den verschiedenen MTU Werten und den dazugehörigen
TcpWindowSize Werten, habe ich jetzt folgende Einträge in der Registry gemacht
EnablePMTUBHDetect=1 und EnablePMTUDiscovery=1 (Win2000 prof SP4)
Seit dem habe ich keine Probleme mehr mit irgendwelchen WebSeiten.
Der Router steht auf 1380
Hintergrund: Ich habe über Wochen MTU Werte getestet, mal gings, mal gings net.
Interessanterweise habe ich an gleichen Tagen zu verschiedenen Zeiten auch verschiedene
Ergebnisse erhalten. Test mit ping www.t-online.de -f -l xxxx ergab einen Wertebereich von 1300
- 1492. Was morgens mit ner größeren MTU ging, ging abends net mehr.
Warum ??? Keine Ahnung
Ach so zu meiner Umgebung: 1 Win2000 Server mit Exchange 2003, 5 WS Win2000 prof,
DSL Modem von der Telekom (altes Siemens), U/B/A/G/I DSL Router, diverse Hubs und ein
Belkin WLAN. Zugang T-DSL Business 3072/512
Schönen Abend
Steffen Leist
Andreas Marx
Danke an Alle für die Tips und die Hilfe. Ich hab's hinbekommen. Alle
"Problemkinder" wie Ebay und Co. laufen bestens und auch die Werte für Up's
and Downs sind sehr gut!
Gruß Andreas