Denke ich auch, dass ich doch mal wieder einen Plausch mit der Hotline halte.
Vorher teste ich das Verhalten aber doch nochmal auf ner anderen Leitung von einem anderen Provider. Ich wollte mir halt den Schwenk auf die 2te Leitung sparen. - Das nervt immer, vor allem weil die Backup-Leitung nicht so breit ist.
Danke für Deine Bemühungen
Das ist nicht korrekt. Das Längenfeld hat eine Größe von 16
Bit, d.h. IP Pakete mit einer Länge von 65535 Bytes sind
zulässig.
Die 1518 Byte Grenze (1500 Byte Payload) stammt von einem
Layer weiter unten: Ethernet.
Du hast Recht, da hab ich mich nicht korrekt/genau ausgedrückt
Kommt darauf an. Vielleicht möchte man ja auch viele VoIP
Pakete (die sind eher klein) übertragen und nicht so viele
große HTTP Pakete, die Jitter erzeugen können?
hmm, stimmt, an VoIP hab ich in dem Zusammenhang nicht gedacht
Warum eigentlich?
Wegen des anteilsmäßig deutlich höheren Overheads.
Header wech, bleiben 1772.
uups, meinte 1472
Nein.
1.) es sind 1500 Netto.
2.) IP-Frame kann beliebige Größe haben (siehe z.B.
DNS-Abfragen oder ACK-Pakete, das sind nur eine handvoll
Bytes).
3.) Die 1500 kommen aus dem Ethernet
4.) Es gibt auch noch andere Netzwerk-Arten. Insbesondere die
Anbindung an’s Web (sprich: die Leitung vom
Access-Concentrator zur Zentrale deines Providers und
besonders die dicken Transatlantik-Leitungen) haben mit
Ethernet nicht das geringste zu tun. Ethernet ist aufgrund der
Längen-Beschränkungen (max. 100 m zwischen zwei Geräten, max.
300 m zwischen zwei Endgeräten) prinzipiell nur innerhalb
eines Gebäudes bzw. eines kleineren Komplexes geeignet. Sobald
eine längere Strecke dazwischen liegt, muss man auf ein
anderes Netz wechseln, ATM oder was es da alles gibt (da hab
ich jetzt auch nur ein nebulöses halbwissen).
Und andere Netze können durchaus andere Framegrößen haben.
Stimmt, Du hast Recht, ich hab mich unsauber ausgedrückt, eigentlich das eine gemeint (Ethernet-Paket) und das andere (IP) geschrieben.
Speziell deshalb gibt es die ja Möglichkeit, Pakte zu
fragmentieren.
Und es ist immer sinnvoll, seine Geräte an diese Technik
anzupassen:
Hast du eine zu große MTU, dann werden deine Pakte an der
dünnsten Stelle auf zwei Pakete (oder mehr) verteilt. Das
kostet a) Zeit und b) zusätzlichen Protokoll-Overhaed, also
Bandbreite.
Hast du eine zu kleine MTU, dann ist das Verhältnis
Gesamtdaten zu Nutzlast nicht mehr optimal, du verschenkst
also auch ein bischen (nur wenig) Bandbreite.
Ja, genau, ich verschenke die Bandbreite, die ich für die Header der durch die Aufteilung zusätzlich entstehenden Pakete brauche.
Vor allem gibt es aber einige Seiten (besonders Banken!), die
keine fragmentierten Frames akzeptieren! Ich hab in meinem
Bekanntenkreis einige Leute, die nur mit einer richtig
eingestellten MTU Online-Banking machen können (ist wohl eine
Sicherheitsmaßnahme der Banken), auch eBay ist bei falscher
MTU machmal störrisch.
Das Problem hatte ich zum Glück noch nicht. - Weder mit der Bank, noch mit Ebay.
Welcher Scherzkeks verbraucht mir dann die noch verbleibenden 436 Byte? - Wenn das so ist, wie Du beschreibst, kann das für mich nur ein Konfig-Fehler auf Seiten des Providers sein, da doch eigentlich jeder der solche Gerätschaften professionell betreibt ein Interess daran hat die mögliche Framegröße möglichst gut auszunutzen um den Overhead durch die Header möglichst klein zu halten. Oder sehe ich das so falsch?
Das siehst du in der Tat falsch. Die Bytes werden nicht
verbraucht. Es gibt zwischendurch nur eine technische Einheit
(Netzwerk, Gerät), die mit solchen großen Frames nicht
zurechtkommt - aus welchen Gründen auch immer - und deshalb
dein großes Frame auf zwei kleinere verteilt.
Ja, dass die Bytes nicht „verbraucht“ in dem Sinne werden ist mir klar. Ich meinte damit hinzukommende Header. Durch das was Du unten schreibst wird klar warum es durchaus sein könnte, das jemand eine 1024er MTU brauchen könnte.
Das ist absolut gängige Technik, auch wenn die reine Größe
deiner MTU von 1024 eher ungewöhnlich ist. Also, ungewöhnlich
im Sinne dessen, was es bei anderen Providern gibt.
Eben, und mein Provider sagt ja auch ich soll eine 1460er MTU einstellen, wobei mir ein anderer Hotliner dieses Providers im Zuge einer Fehlersuche sagte ich solle den TCP-Optimizer verwenden, der bei mir aber eine 1500er MTU einstellen will (vgl. unten).
Sie ist außerordentlich logisch, wenn es verarbeitende Geräte
in der Leitung gibt (transparente Proxys, Filter oder sowas),
weil Speicher in solchen Geräten natürlich meist volle
KiloBytes sein werden.
Kann ich nachvollziehen
Besorg dir den TCP-Optimizer
(http://sg-tcp-optimizer.softonic.de/, Freeware), der
analysiert deine Verbindung und passt MTU (und ein paar andere
Einstellungen) optimal an. Dauert nur eine Minute, dannach
läuft deine Leitung auf max.
Habe ich gemacht… und gleich wiedererkannt. Den bekommst Du auch über Speedguide.net. Der Optimizer hatte bei mir eine 1500er MTU eingestellt. Wenn man hier auf den Reiter „largest MTU“, dann probiert das Prog. verschiedene Frame-Größen aus, bricht aber dann bei 1125 Bytes wegen „Couldn’t determine largest possible MTU due to packets being lost.“ ab.
lg, mabuse
Danke für Deine Bemühungen
vielen Dank für den Hinweis, probier ich mal aus, auch wenns mir komisch vorkommt.
Ganz offen: mir kommt diese Zahl auch komisch vor.
Ich gehe mal davon aus, das der „Fehler“ in deiner
unmittelbaren Nähe liegt (Konfiguration des
Access-Concentrators). Aber ich bezweifele wirklich, das sich
der Provider von deinen Fehlermeldungen groß was annehmen
wird. Und selbst wenn, dann wird das wohl eher Monate als
Wochen dauern, bis die da was ändern.
Letzteres befürchte ich auch. Alleine die Schwierigkeit den Sachverhalt ein Hotliner verständlich zu machen. Ich bin schließlich kein hauptberuflicher Netzwerker, bei mir ist das Nebensache.
Warum kommts mir komisch vor?
- Weil der Provider (Kabel BW) selbst behauptet ich solle die MTU auf 1460 einstellen.
Das heisst nichts. Die haben ja auch nicht überall die gleiche
Hardware. Ich selber musste nach einem Umzug (zwei
verschiedene Städte) auch die MTU umstellen, obwohl ich beim
gleichen Provider (Telekom) geblieben bin. In MG war die MTU
1472, in Krefeld sind’s „nur“ noch 1456. Aber der Unterschied
verhagelt einem schon die eine oder andere Seite.
hmm, wenn ich das alles so lese, sollte ich mein Netz doch mal testweise auf 1024 umstellen und schauen was geht.
- Ich das Problem bei allen Domains habe
Das ist nur logisch. Wenn’s einen Engpass auf dem Weg ins
Internet gibt, dann betrifft der natürlich das gesamte
Internet.
- Wenn ich den Paramter -f angebe und das Paket zu groß ist nicht einfach keine Antwort mehr zurückkommt, sondern normalerweise die Meldung „Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.“
Nein, die werden einfach nur verworfen.
hab ich gerade mal eben ausprobiert, wenn ich Google oder
andere mit 1500 anpinge, dann kommt einfach nur
„Zeitüberschreitung der Anforderung“
- Dieses seltsame Verhalten nur bei Framesizes zwischen 1025 und 1472 Bytes vorhanden ist. Ab 1473 bekomme ich die unter 3. genannte Meldung.
Das überrascht mich. Ich hab solch eine Meldung noch nie zu
gesicht bekommen. Vieleicht eine Sonderfunktion irgendeines
Gerätes vor der eigentlichen Engstelle, die vorher schon auf
etwas kleineres fragmentieren müsste.
Dieses würde dann bei den großen Paketen diese Fehlermeldung
zurückschicken und kleinere durchlassen. Und die kleineren
werden dann erst später bei einem anderen Gerät verworfen,
wenn das erste Gerät keine Meldung mehr zurücksendet, weil es
denkt, alles wäre in Ordnung.
Ich glaube Deine letzten 2 Sätze könnten eine plausible Erklärung sein.
… Du verstehst meine Verwirrung?
Sagen wir: ich kann sie nachvollziehen.
danke, endlich einer, der meine manchmal etwas queren Gedankengänge nachvollziehen kann.
Wie oben schon geschrieben: zieh dir den TCP-Optimizer und
pass dich an die Technik deiner Leitung an. Du kannst ja
außerdem mit deinem Provider kommunizieren, vieleicht hast du
ja Glück, und der ändert etwas. Daher den TCP-Optimizer einmal
die Woche oder so laufen lassen, damit du es auch mitbekommst,
wenn sich was ändert.
Ersteres werde ich wohl jetzt mal testen, das Zweite… naja, vielleicht hab ich auch mal Glück.
Das mit dem Optimizer kann ich machen
Und nicht vergessen: alle Geräte deines lokalen Netzes
anpassen, vor allem auch den Router.
Scho klar, alles bis auf das Modem des Providers, da komm ich nicht rein.
lg, mabuse
Danke nochmal für Deine Mühe.
Hi!
Habe ich gemacht… und gleich wiedererkannt. Den bekommst Du auch über Speedguide.net. Der Optimizer hatte bei mir eine 1500er MTU eingestellt. Wenn man hier auf den Reiter „largest MTU“, dann probiert das Prog. verschiedene Frame-Größen aus, bricht aber dann bei 1125 Bytes wegen „Couldn’t determine largest possible MTU due to packets being lost.“ ab.
Oh ha.
Das hab ich ja noch nie erlebt.
Da würd ich mal mit den Entwicklern Kontakt aufnehmen, auf das es da eine Weiterentwicklung gibt. Eiegtnlcuh sollte er das das können, aber 1025 ist ja nun mal ungewohnt niedrig.
Aber egal, stell sie halt von Hand so ein.
Schönes Wochenende wünsch ich dir!
mabuse
Hallo,
Das Problem ist eher, daß viele Leute „bekannte“
Server/Adressen mißbrauchen.
Was hat denn das mit Path MTU Discovery zu tun? Und ganz abgesehen davon, wie will man denn Server geheim halten?
Als Admin dort würde ich auch Pingfloods abwürgen
Ein einzelner Echo Request ist wohl kaum eine „Flut“. Und außerdem ist ICMP Typ 3 nicht Typ 8 oder 0. Ich würde einen Admin, der ICMP gandenlos abwürgt, weil er eines der Kernprotokolle von TCP/IP nicht verstanden hat, eher mal auf 'ne Schulung schicken.
Gruß
Fritze