Tja, da hab ich doch gleich mal probieren müssen, was da dran ist und habe mal Pings losgeschickt:
muenster:~# ping -s 1400 www.strato.de PING www.strato.de (192.67.198.33): 1400 data bytes 1408 bytes from 192.67.198.33: icmp_seq=0 ttl=245 time=159.6 ms 1408 bytes from 192.67.198.33: icmpseq=1 ttl=245 time=157.3 ms 1408 bytes from 192.67.198.33: icmpseq=2 ttl=245 time=327.5 ms 1408 bytes from 192.67.198.33: icmpseq=3 ttl=245 time=160.3 ms 1408 bytes from 192.67.198.33: icmpseq=4 ttl=245 time=159.0 ms --- www.strato.de ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 157.3/192.7/327.5 ms muenster:~# ping -s 1500 www.strato.de PING www.strato.de (192.67.198.33): 1500 data bytes --- www.strato.de ping statistics --- 8 packets transmitted, 0 packets received, 100% packet loss
Was passiert hier? Ich schicke Pakete mit 1400 Byte und 1500 Byte Länge. Die mit 1500 Byte werden an unserem Router - ein Router der Telekom mit einer DSL-Festanbindung - sauber fragmentiert und eben als Fragmente verschickt:
goggle# tcpdump -i ppp0 icmp tcpdump: listening on ppp0 09:29:01.223186 62.153.201.130 > 62.226.72.1: (frag 33019:28@1480) 09:29:01.316521 62.153.201.130 > 62.226.72.1: icmp: echo request (frag 33019:1472@0+) 09:29:01.316707 62.153.201.130 > 62.226.72.1: (frag 33019:8@1472+) 09:29:01.317017 62.226.72.1 > 62.153.201.130: (frag 14273:36@1472) 09:29:01.317148 62.226.72.1 > 62.153.201.130: icmp: echo reply (frag 14273:1472@0+)
So sieht das zum Beispiel aus wenn ich meine Kiste zu Hause anpinge. Worauf deutet das hin? Ich würde mal darauf tippen das Strato eine Firewallstrategie hat, bei der transparente Firewalls vor den Strato-Servern stehen. Und da gehen wohl Fragmente verloren. Möglicherweise machen die das, weil TCP/IP-Fragmente bei Angriffen gerne benutzt werden, weil Fragmente mit falschen Headerdaten gerne TCP/IP-Stacks zum Absturz bringen. Trotzdem würde ich mal sagen das das ein klarer Konfigurationsfehler bei Strato ist. Zumindestens riecht es stark danach ...
Joern Aug. 29, 2003, 9:52 a.m.
Es ist eher ein DSL-Problem.
http://www.sauff.com/dsl-faq/mtu-mini-faq.html#2
hugo Aug. 29, 2003, 10:09 a.m.
Das Problem liegt definitiv auf Seiten der Serverbetreiber und er Fragmentierung. Ob es jetzt die von mir vermutete Filterung von Fragmenten ist, oder die in der FAQ vermutete Filterung von ICMP 'Fragmentation needed' Meldungen, das ist letztlich egal: der Fehler liegt auf der Serverseite.
Die Fragmentierung die durch das Zusammentreffen von grösseren MTUs und DSL passiert, ist ganz normal für TCP/IP. Dafür gibt es eben die passenden Mechanismen (zum Einen die Fragmentierung selber und zum Anderen die ICMP-Meldungen die eine Fragmentierung anfordern).
Bei Endbenutzern mit DSL-Karten direkt im Rechner kann es natürlich sein das die Kombination Probleme macht - aber sobald ein Router dazwischen hängt wird dieser in fast allen Fällen die Fragmentierung korrekt umsetzen (in unserem Fall ist das übrigens ein Cisco Router an einer DSL Festverbindung - keine Endbenutzereinwahl, sondern eine T-Interconnect-Anbindung, nur das halt eine DSL-Strecke dazwischen hängt).
Es kann nicht sein das Endbenutzer alle ihre technischen Geräte umkonfigurieren müssen, weil ein Spielzeugprovider meint seine nicht korrekt konfigurieren zu müssen :-)
Das ist kein Fehler von DSL.
Der Schockwellenreiter Aug. 29, 2003, 12:55 p.m.
Es kann kein DSL-Problem sein, da der Schockwellenreiter meistens via DSL erreichbar ist, aber -- wie mir inzwischen von diversen Lesern mitgeteilt wurde -- nicht aus den Firmennetzen.
Zur Zeit kann ich ihn auch nicht von hier aus dem Institut erreichen, und wir sitzen direkt auf einer 44 MBit-Verbindung zum DFN via Cisco -- also auf der ganzen Strecke kein DSL.
Dafür habe ich eine absolut unbefriedigende Antwort von Strato erhalten:
Uns ist bekannt, daß einige Peeringpoints innerhalb Deutschlands momentan Probleme bereiten, so daß Strato-Seiten nicht oder nur teilweise angezeigt werden. Wir haben jedoch keinen Einfluß auf diese Knotenpunkte und können daher nur um Geduld bitten, bis der Betreiber dieser Punkte den Fehler behoben hat.
Ich sitze gerade an einer Antwort. Da ich nicht an den Schockwellenreiter komme, kann mir jemand die URL (Permalink) meiner heutigen Meldung schicken? Danke.
hugo Aug. 29, 2003, 1:09 p.m.
Übersetzt also: "Wir wissen das was kaputt ist, wir machen uns aber lieber keine Gedanken darüber sondern schieben die Schuld auf die Anderen. Lecken Sie uns am Allerwertesten."
Der Schockwellenreiter Aug. 29, 2003, 1:12 p.m.
Permalink ist angekommen. Danke!
Und ansonsten hast Du mit Deiner Bemerkung natürlich recht. :-(
Joern Aug. 29, 2003, 1:40 p.m.
Das MTU-Problem bei DSL entsteht ja erst durch die Nutzung von pppoe, daher ist es für mich eher ein Problem der Telekom die sich den Blödsinn ausgedacht hat und als Firewall-Betreiber würde ich auch keine Fragmente durchlassen, da kann ich sie auch gleich wieder abschalten. Anscheinend liegt das Problem vom SWR aber woanders.
hugo Aug. 29, 2003, 2:01 p.m.
Nö, das mit den Fragmenten ist offizieller Bestandteil der TCP/IP-RFC und aller Dokumente die TCP/IP beschreiben. Und das durch pppoe durch zusätzliche Headerdaten halt nicht 1500 als MTU genutzt werden kann, ist auch eine bekannte Tatsache und dokumentierte Eigenschaft des pppoe (zu dem es auch eine RFC gibt). Wenn jemand damit nicht klar kommt, verstösst er massiv gegen die Standards des Internet und der TCP/IP Kommunikation.
Sowohl der ICMP 'Fragmentation needed' als auch TCP/IP-Fragmente selber sind vollkommen normale vorkommnisse im Internet. Damit muss man eben umgehen können - und mitnichten kann man dann seine Firewall abschalten. Statt dessen schaltet man bei der Firewall einfach ein, das sie eine defragmentierung vornimmt und gut ist.
Und weder hat die Telekom sich das PPPoE ausgedacht, noch hat sie sonstwas mit den Problemen zu tun die durch falsch konfigurierte Firewalls entstehen.
Natürlich wäre es mir auch lieber wenn nicht PPPoE benutzt würde - andererseits hat das ganz handfeste Gründe, warum das benutzt wird: PPPoE erlaubt die Authentifizierung von Sessions über einen Radius-Server auf die gleiche Art wie bei einer Einwahl. Daher haben die das wohl gewählt. So wie eigentlich alle DSL-Provider weltweit für dynamische DSL-Verbindungen PPPoE verwenden, selbst in den USA (die ja bekanntlich gerne auch mal eigene Wege gehen in der Telekommunikation).
Übrigen nochmal (ich schrub es schon): mein Anschluss ist kein T-DSL-Anschluss, sondern eine T-Interconnect-Festanbindung. Das ist etwas _ganz_ anderes als die T-Online-Einwahl (z.B. kein PPPoE). Trotzdem entstehen Fragmente und die fragmentierten Pakete kommen nicht bei Strato an (oder die Antworten nicht bei mir).