Grösse der MTU Size?
Joerg Lang
bei meinem Problem mit VPN über Netgear Router, wurde mir als Hinweis
gegeben, dass die MTU Size zu gross ist.
Jetzt frage ich mich, was dieser Wert aussagen soll und wie er zu
verstehen ist.
Grüsse Jörg
Daniel Meyer
Wie gross ein IP Paket sein darf um ueber ein Medium uebertragen werden
zu koennen ohne das es fragmentiert wird.
Daniel
--
Whenever, wherever http://www.cyberdelia.de
We're meant to be together ea...@cyberdelia.de
I'll be there and you'll be near
And that's the deal my dear Try it: www.trustix.net
Thorsten Dahm
In der Newsgroup de.alt.sysadmin.recovery hat Lutz (Donnerhacke) im Thread
"http & firewall" eine ziemlich gute Erklärung zu PMTUD geschrieben, das
sollte eigentlich Deine Frage beantworten. Und zur Übung suchst Du das
Posting selbst, deshalb keine Message-ID.
Gruß, Thorsten
--
Das Schicksal beschützt Narren, kleine Kinder und Schiffe mit dem Namen
Enterprise
(William T. Riker)
Felix von Leitner
Wie kommst du eigentlich dazu, ein VPN einrichten zu wollen, wenn du
noch nicht mal weißt oder selbständig rauszufinden in der Lage bist, was
eine MTU ist?
Was geht eigentlich in Leuten wie dir vor, wenn sie ihre Unwissenheit so
selbstdemontierend öffentlich zur Schau stellen? Tut das weh? Stehst
du vielleicht unter dem Einfluß irgendwelcher Pillen?
Ich verstehe es einfach nicht!
Markus Gurnig
das versteh wiederum ich - und sicher auch einige andere hier nicht....
übrigens...unwissenheit ist keine schande....überheblichkeit schon!
markus
"
Stefan Bellon
> und du lässt deinen Frust ab auf jemand der höflich gefragt hat....
> das versteh wiederum ich - und sicher auch einige andere hier
> nicht....
"Ich möchte gerne ein Auto bauen, weiß aber noch nicht richtig, was
eine Achse ist. Kann mir bitte einer helfen?"
"Wenn Du nicht selber rausfinden kannst, was eine Achse ist, lass
lieber das Autobauen sein."
Gültige Antwort.
SCNR,
--
Stefan Bellon
Marcus Frings
> Was geht eigentlich in Leuten wie dir vor, wenn sie ihre Unwissenheit so
> selbstdemontierend öffentlich zur Schau stellen? Tut das weh? Stehst
> du vielleicht unter dem Einfluß irgendwelcher Pillen?
Anstatt ihn nur langweilig zu flamen (Ich kenne wesentlich bessere
Flames von Dir!), hättest Du ihm wenigstens noch "MTU + Google" mit auf
den Weg geben können.
Gruß,
Marcus
--
"Du kannst doch nicht Frauen und Kinder erschiessen!" - "Das ist leicht. Du
darfst nur nicht so weit vorhalten! Hahahaha... Krieg ist die Hölle!"
Markus Gurnig
weiteren bin ich durchaus der Hochsprache mächtig. Aber für so miese kleine
Flames und Motzer (übrigens auch ein Produkt des Bildungssystems, jeder
denkt nur noch er hat Recht, so wie du auch gerade - waren wir wohl auf der
Hauptschule, oder?), verschleudere ich meine Ressourcen nicht.
Fröhlichen Dienstag
Markus
Jan Voelkers
die Frage ist etwas dürftig gestellt und der $OP hätte noch Infos mit warum
und wieso bringen können, aber vermutlich hat ihm ein Admin gesagt, daß die
MTU zu groß sei für den VPN Server.
> "Wenn Du nicht selber rausfinden kannst, was eine Achse ist, lass
> lieber das Autobauen sein."
Und dann wäre es nicht "eine Achse ans Auto bauen" sondern eher "Den Einstellungsknopf
für die Sitzhöhe finden" - und das kann man dem $OP auch mitteilen.
z.B. wie folgt:
MTU = Maximum Transfer Unit
Heißt: Die maximale Größe der Netzwerkpakete, die gesendet werden. Wenn zwischendurch
ein Router hängt wird eventuell fragmentiert weil die MTU des Routers kleiner ist.
Für VPNs (Und andere Verbindungen) möglicherweise schlecht.
Standard Windoof = 1500
Oftmals Standard = 1492
Jan
Urs [Ayahuasca] Traenkner
Selbstueberschaetzung ist das wesentliche Merkmal.
Gruss Urs...
--
Wenn man nur einen Hammer als Werkzeug hat, sieht jedes
Problem aus wie ein Nagel.
H. Gremming
> * Felix von Leitner <usenet-...@fefe.de> wrote:
>
> > Was geht eigentlich in Leuten wie dir vor, wenn sie ihre Unwissenheit so
> > selbstdemontierend öffentlich zur Schau stellen? Tut das weh? Stehst
> > du vielleicht unter dem Einfluß irgendwelcher Pillen?
>
> Anstatt ihn nur langweilig zu flamen (Ich kenne wesentlich bessere
> Flames von Dir!), hättest Du ihm wenigstens noch "MTU + Google" mit auf
> den Weg geben können.
Wieso? Damit weiterpfuschen kann?
Es ist besser, die Leute begreifen dass man erst lernen muss
statt einfach drauf los zu probieren. Wer keine Ahnung hat
muss eben alles lernen. Das zu begreifen ist der erste Schritt.
Heinrich
--
Juergen P. Meier
> Zugegeben,
>
> die Frage ist etwas dürftig gestellt und der $OP hätte noch Infos mit warum
> und wieso bringen können, aber vermutlich hat ihm ein Admin gesagt, daß die
> MTU zu groß sei für den VPN Server.
Was voelliger Bloedsinn ist. Ich kann Pakete von 65000 Byte groesse
ueber einen Modemlink mit MTU 256 schicken. Auch IPSEC pakete.
Die Aussage des "Admins" entspricht ungefaehr: "Es scheint heute die
Sonne, darum sind Bananen krumm".
>> "Wenn Du nicht selber rausfinden kannst, was eine Achse ist, lass
>> lieber das Autobauen sein."
>
> Und dann wäre es nicht "eine Achse ans Auto bauen" sondern eher
> "Den Einstellungsknopf für die Sitzhöhe finden".
Eher "den Zuendparameter der Elektronischen Einspritzung
modifizieren". Oder "Den Pedalhub des Bremspedals veraendern".
Von sowas laesst man die Finger, wenn man die Zusammenhaenge nicht
versteht. Oder man qualifiziert sich fuer einen Darwin-Award.
> z.B. wie folgt:
> MTU = Maximum Transfer Unit
>
> Die maximale Größe der Netzwerkpakete, die gesendet werden.
Auf Layer-3, ja.
> Wenn zwischendurch ein Router hängt wird eventuell fragmentiert
> weil die MTU des Routers kleiner ist.
Ja.
> Für VPNs (Und andere Verbindungen) möglicherweise schlecht.
Nein.
> Standard Windoof = 1500
Nein. Das ist Standard Ethernet.
> Oftmals Standard = 1492
Nein.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
USENET incompatible and broken newsreaders are not supported.
Don't complain to me! Complain to the vendor of your software.
Thomas Braun
> Es ist besser, die Leute begreifen dass man erst lernen muss
> statt einfach drauf los zu probieren.
Falls man den aktuellen Zustand der Menschheit als "Fortschritt" wertet,
kann dieses "drauf los probieren" nicht ganz der falsche Ansatz sein.
"Drauf los probieren"[tm] ist auch ein Weg etwas zu lernen.
> Wer keine Ahnung hat muss eben alles lernen.
Ach? Willkommen auf dem Allgemeinplatz ;-)
grüße
Thomas Braun
--
web: www.wegasoft.de / email: nos...@wegasoft.de
Email an nospam wird im normalfall nicht beantwortet, falls
gewünscht, bitte nospam mit meinen Initialen ersetzen.
Jan Voelkers
> Was voelliger Bloedsinn ist. Ich kann Pakete von 65000 Byte groesse
> ueber einen Modemlink mit MTU 256 schicken. Auch IPSEC pakete.
Dann hast Du am Ende
(65000+$PPPId+$IPSECHeader[+$AuthenticationHeader])/256 Pakete.
Viel Spaß damit. Und Danke fürs vollballern des Netzes mit Fragmenten.
Damits noch mehr Spaß macht, dreh doch bitte die TTL aufs Minimum.
> Die Aussage des "Admins" entspricht ungefaehr: "Es scheint heute die
> Sonne, darum sind Bananen krumm".
Das ist vielleicht leider wohl wahr. Wenn aber sein Gateway fragmentierte Pakete
ablehnt, was dann?
> Eher "den Zuendparameter der Elektronischen Einspritzung
> modifizieren". Oder "Den Pedalhub des Bremspedals veraendern".
> Von sowas laesst man die Finger, wenn man die Zusammenhaenge nicht
> versteht. Oder man qualifiziert sich fuer einen Darwin-Award.
Oder man fragt in einer Newsgroup, die sich
"de.auto.motor.einspritzung oder .bremse" nennt, nach?
Es sei denn, da sind nur Leute, die meinen, wer nicht mit der Muttermilch alle
Zündungsparameter aufgesogen hat und sein Frühstück von Bremsscheiben isst, ist
ein Idiot.
> > Für VPNs (Und andere Verbindungen) möglicherweise schlecht.
>
> Nein.
Und warum steht dann in diversen Howto's, man solle die MTU niedriger setzen,
damit die Verbindung klappt?
> > Standard Windoof = 1500
>
> Nein. Das ist Standard Ethernet.
Ok. Mein Fehler geht gar weiter. Standard XP=1480
> > Oftmals Standard = 1492
>
> Nein.
Aus RFC 2516 (PPPoE)
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
larger size than 1492. Since Ethernet has a maximum payload size of
1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is
2 octets, the PPP MTU MUST NOT be greater than 1492.
Jan
--
"begin end" Spacken fressen auch kleine Kinder und schmeißen Omis von der Brücke,
weil Sie nicht das Standardalter haben. (TM)
Lutz Donnerhacke
> Am Tue, 10 Dec 2002 21:20:52 +0000 (UTC) schrub "Juergen P. Meier" <ne...@jors.net>:
>> Was voelliger Bloedsinn ist. Ich kann Pakete von 65000 Byte groesse
>> ueber einen Modemlink mit MTU 256 schicken. Auch IPSEC pakete.
>
> Dann hast Du am Ende
> (65000+$PPPId+$IPSECHeader[+$AuthenticationHeader])/256 Pakete. Viel Spaß
> damit. Und Danke fürs vollballern des Netzes mit Fragmenten. Damits noch
> mehr Spaß macht, dreh doch bitte die TTL aufs Minimum.
Wenn Du nicht weißt, wozu man eine niedrige MTU des Modemlinks haben will,
dann schweig bitte. Diese halbverstandenen angelesenen Vorurteile sind ja
erbärmlich. Mein Modemlink lief jahrelang mit einer MTU kleiner 700 Byte.
Mit voller Absicht.
>> Die Aussage des "Admins" entspricht ungefaehr: "Es scheint heute die
>> Sonne, darum sind Bananen krumm".
>
> Das ist vielleicht leider wohl wahr. Wenn aber sein Gateway fragmentierte
> Pakete ablehnt, was dann?
Dann muß man des Gateways-Admins Wunsch, nicht zu kommunizieren, eben
beherzigen.
>> > Für VPNs (Und andere Verbindungen) möglicherweise schlecht.
>>
>> Nein.
>
> Und warum steht dann in diversen Howto's, man solle die MTU niedriger
> setzen, damit die Verbindung klappt?
Weil zwei Hyperschlaue und eine Masse von mit dem Klammerbeutel gepuderten
Admins richtig große Scheiße genaut haben. Man setzt die MTU nicht herab,
damit man über einen TCPMSS Hack die Fehlkonfiguration des Paketfilters auf
der Gegenseite umgeht. Man schaltet selbst PMTUD lokal ab und respektiert
den Wunsch von Firmen, die ihren Server PMTUD zuschalten und auf dem
Paketfilter davon ICMP unreachable droppen: Man stellt die Kommunikation ein.
>> > Oftmals Standard = 1492
>>
>> Nein.
>
> Aus RFC 2516 (PPPoE)
Und nun denke bitte über PPPoE nach. Gründlich. Im Zusammenhang mit der
Ethernet MTU. Danke.
> The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
> larger size than 1492. Since Ethernet has a maximum payload size of
> 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is
> 2 octets, the PPP MTU MUST NOT be greater than 1492.
Eben. Und das nächste Kabelstük wird mit HDLC und 1200 Byte Containern
gefahren. Was sagt ein Link über die Pfad MTU aus?
Jörg Lang
Sorry, dass ich Euch belästige, aber generell ist mir wurscht was MTU
ist. Mein Problem ist, dass ich mit ner Software (secu remote client)
arbeiten muss, die mich ehrlichgesgt nen Scheissdreck interessiert.
Auf meine Frgae bei Checkpoint warum das nicht tut habe ich nur gesagt
bekommen MTU Size zu gross. Nicht mehr!
Okay dann dachte ich ich frage eben Leute die Ahung haben, worum es
geht. Wenn das aber zuviel verlangt ist, sorry!
Behaltet Euer Wissen für Euch, teilt es auf keinen Fall mit jemand und
werdet glücklich damit!
Jörg Lang
>Es ist besser, die Leute begreifen dass man erst lernen muss
>statt einfach drauf los zu probieren. Wer keine Ahnung hat
>muss eben alles lernen. Das zu begreifen ist der erste Schritt.
Sorry, dass ich Euch belästige, aber generell ist mir wurscht was MTU
Lutz Donnerhacke
> Sorry, dass ich Euch belästige, aber generell ist mir wurscht was MTU
> ist. Mein Problem ist, dass ich mit ner Software (secu remote client)
> arbeiten muss, die mich ehrlichgesgt nen Scheissdreck interessiert.
Sorry, daß ich Dir antworte, aber generell ist mir wurscht was die Poster
wollen. Mein Problem ist, daß ich Antworten nur in begrenzter Zeit und nach
bestem Wissen und Gewissen geben kann. Dabei interessieren mich die
persönlichen Probleme von Fragestellern mit meiner Antwort einen Scheißdreck.
> Auf meine Frgae bei Checkpoint warum das nicht tut habe ich nur gesagt
> bekommen MTU Size zu gross. Nicht mehr!
Und hier hast Du einen Verweis auf
http://groups.google.com/groups?selm=slrnali687.om.lutz%40taranis.iks-jena.de
bekommen.
> Okay dann dachte ich ich frage eben Leute die Ahung haben, worum es geht.
> Wenn das aber zuviel verlangt ist, sorry! Behaltet Euer Wissen für Euch,
> teilt es auf keinen Fall mit jemand und werdet glücklich damit!
Was stört Dich an meiner Antwort, deren Link ich Dir nochmal rausgesucht habe?
Ist sie Dir zu technisch oder fehlt das Klopapier?
Thorsten Dahm
> Auf meine Frgae bei Checkpoint warum das nicht tut habe ich nur gesagt
> bekommen MTU Size zu gross. Nicht mehr!
Du hast für das Produkt bezahlt, also ist es der Job von Checkpoint, Dir zu
helfen, das Ding ans Laufen zu kriegen. Punkt.
Thorsten Dahm
> Und hier hast Du einen Verweis auf
> http://groups.google.com/groups?selm=slrnali687.om.lutz%40taranis.iks-j
> ena.de bekommen.
Vielleicht solltest Du den Text auch mal in die FAQ aufnehmen.
Urs [Ayahuasca] Traenkner
> begin Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Und hier hast Du einen Verweis auf
>> http://groups.google.com/groups?selm=slrnali687.om.lutz%40taranis.iks-j
>> ena.de bekommen.
> Vielleicht solltest Du den Text auch mal in die FAQ aufnehmen.
Dafuer.
Lutz Donnerhacke
> begin Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Und hier hast Du einen Verweis auf
>> http://groups.google.com/groups?selm=slrnali687.om.lutz%40taranis.iks-j
>> ena.de bekommen.
>
> Vielleicht solltest Du den Text auch mal in die FAQ aufnehmen.
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#PMTUD
Warum muß man die MTU Größe anpassen, wenn Paketfilter eingesetzt
werden?
Man darf nicht planlos ICMP sperren, dann gibt es die Probleme
nicht mehr. Der Hintergrund ist eigentlich ganz einfach: Path MTU
Discovery.
Wenn man ein IP Paket auf die Reise schickt, dann kann es
passieren, daß unterwegs die Leitungs-MTU kleiner wird und das
Paket nicht mehr druchpaßt. Normalerweise zerlegt der Router dem
das passiert, das IP Paket in Fragmente und schickt die durch.
Einfach, trival, funktioniert.
Manchmal will man das nicht, so daß man ein 'Dont Fragment' Bit
im IP Header setzen kann, wenn das Paket nicht zerlegt werden
darf. In dem Fall schickt der Router, dem das trotzdem passiert
ein ICMP 'Destination unreachable: Fragmentation needed, but DF
set.' an den Absender zurück. Der weiß nun, daß es nicht
geklappt hat.
Nun ist vor einigen Jahren jemand sich gedacht, daß es prima
wäre, den Routern die Arbeit zu erleichtert. Er hat nun alle
Pakete mit gesetztem DF Bit gesendet. Kam von einem Router eine
ICMP Fehlermeldung zurück, dann hat er die in der Fehlermeldung
mit angegebene maximale Größe der Strecke genommen und nur für
diese Verbindung kleinere Pakete gesendet. Das Ganze nennt man
PMTUD.
Darüberhinaus gibt es Buffergrenzen, die ein IP-Stack vorhält
kann, wenn er TCP-Segmente verarbeitet. Um der Gegenseite
mitzuteilen, welche maximalen Segmentgrößen er verträgt, setzt
er beim Verbinungsaufbau (SYNC) die Option TCPMSS (TCP Maximum
Segment Size).
Irgendwann beobachtete jemand anderes, daß die "dünneren"
Leitungen, die also kleinere MTUs haben, meist beim Endpunkt einer
Verbindung stehen und dachte sich, man könne die Buffergrenzen
des TCP Stacks als Obergrenze der MTU ebenfalls interpretieren.
Der Gedanke allein ist derartig schwachsinnig, daß es schmerzt:
Hier wurde Kausalität und Korrelation verwechselt. Man setzt
nämlich die Puffergrenzen so, daß sie in der lokalen Umgebung
sinnvoll sind, und das ist zufällig die LeitungsMTU am nächsten
Interface, weil ja einkommende Pakete eh' nicht größer sein
können. Das sagt natürlich gar nichts über die MTU der
Leitungen zwischen den Endgeräten aus, besonders, da die
allerletzte Strecke meist ein "dickes" Ethernetinterface ist.
Kurz gesagt hat sich der Letztgenannte also eine Modifikation des
TCP/IP Stacks dahingehend einfallen lassen, daß der den TCPMSS
Parameter als Startwert für PMTUD nimmt.
Neu in dem Szenario sind jetzt die strunzdämlichen
Paketfilter-Admins, die ICMP als Angriff werten und abschalten.
Danach geht nichts mehr, wenn einer von beiden PMTUD probiert. Die
Pakete grundsätzlich nicht druchkommen können, weil die
Fehlermeldungen weggeworfen werden. So und anstatt nun einfach
PMTUD abzuschalten, so daß es gar keine Fehlermeldungen mehr
gibt, setzt man die MTU auf dem Interface so geschickt niedrig,
daß die ausgenden Pakete grundsätzlich klein genug sind, um
überall durchzukommen. Außerdem signalisiert man mit TCPMSS der
Gegenstelle, doch bitte kleine Pakete zu senden. Das ist zwar
ineffizient, aber es gibt keine Fehlermeldungen mehr, die von dem
strunzdämlichen Paketfilter-Admins des Serverproviders
weggeworfen werden könnten.
Anstatt den Wunsch der betreffenden Firma zu respektieren und die
Webseiten links liegen zu lassen, setzen die Leute ihre MTU auf
den Interfaces herab, produzieren so kleinere Buffer im TCP-Stack,
der von anderen Systemen bequem überschrieben werden kann, so
daß man sich selbst eine Sicherheitslücke baut und von der
Kommunikation mit anderen Systemen ausschließt. Es sei denn, man
sagt die kleinere MTU /allen/ Geräten im lokalen Netz, auch dem
Server.
Thorsten Dahm
ich will ja nicht meckern, aber Du hast da einen kleinen Rechtschreibfehler
drin:
"... daß die ausgenden Pakete grundsätzlich ..."
Ich glaube, das soll "ausgehenden" heißen :-)
Ali Ender Yalcin
cu ali
Eckhard Sebastian Maass
> Wenn man ein IP Paket auf die Reise schickt, dann kann es
> passieren, daß unterwegs die Leitungs-MTU kleiner wird und das
> Paket nicht mehr druchpaßt. Normalerweise zerlegt der Router dem
> das passiert, das IP Paket in Fragmente und schickt die durch.
> Einfach, trival, funktioniert.
>
> Manchmal will man das nicht, so daß man ein 'Dont Fragment' Bit
> im IP Header setzen kann, wenn das Paket nicht zerlegt werden
> darf.
Wann will man das denn nicht?
SEcki
--
The broad mass of a nation... will more easily fall victim to a big lie
than to a small one.
-- Adolf Hitler, "Mein Kampf"
Thorsten Dahm
> * Lutz Donnerhacke <lu...@iks-jena.de>:
>> Manchmal will man das nicht, so daß man ein 'Dont Fragment' Bit
>> im IP Header setzen kann, wenn das Paket nicht zerlegt werden
>> darf.
> Wann will man das denn nicht?
Bei manchen SNA-Verbindungen beispielsweise.
Lutz Donnerhacke
> begin Eckhard Sebastian Maass <Eckhar...@gmx.net> wrote:
>> * Lutz Donnerhacke <lu...@iks-jena.de>:
>>> Manchmal will man das nicht, so daß man ein 'Dont Fragment' Bit im IP
>>> Header setzen kann, wenn das Paket nicht zerlegt werden darf.
>>
>> Wann will man das denn nicht?
>
> Bei manchen SNA-Verbindungen beispielsweise.
Nein, bitte nicht SNA erwähnen. Danke. SNA hat ganz andere Anforderungen, da
bei dem Verlust von einem einzelnen Paket sofort die komplette Session
hinfliegt.
Man verwendet DF, wenn man Technik ansprechen will, die über geringe
Eigenintelligenz verfügt (z.B. Switch/Printserver/USV/...). Diese Geräte
unterstützen zwar Protokolle wie SNMP, aber bearbeiten jedes Paket einzeln
und sofort. Der IP Stack ist somit sehr minimal ausgeführt und beherrscht
oft keine Fragmentierung.
Man verwendet DF auch dann, wenn es auf Paketverlust weniger ankommt als auf
extrem kurze Latenzen, z.B. bei Sprach- und Videoübertragung.
Man verwendet DF auch dann, wenn man nicht weiß mit wem man es zu tun hat,
z.B. bei Multicasting, wo mehrere Empfänger für das gleiche Paket existieren.
Reicht das?
Thorsten Dahm
> Anforderungen, da bei dem Verlust von einem einzelnen Paket sofort die
> komplette Session hinfliegt.
Ok, ich entschuldige mich dafür :)
Wieso mögen eigentlich so viele Netzwerker SNA nicht? Nicht, daß ich ein
Fan dieses Protokolls wäre, aber jeder, bei dem man SNA erwähnt, verzieht
direkt das Gesicht. Es sind wohl noch mehr IBM-geschädigte da draußen als
ich gedacht habe.
Lutz Donnerhacke
> begin Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Nein, bitte nicht SNA erwähnen. Danke. SNA hat ganz andere
>> Anforderungen, da bei dem Verlust von einem einzelnen Paket sofort die
>> komplette Session hinfliegt.
>
> Ok, ich entschuldige mich dafür :)
Nicht mit dem Grinsen im Gesicht.
> Wieso mögen eigentlich so viele Netzwerker SNA nicht? Nicht, daß ich ein
> Fan dieses Protokolls wäre, aber jeder, bei dem man SNA erwähnt, verzieht
> direkt das Gesicht. Es sind wohl noch mehr IBM-geschädigte da draußen als
> ich gedacht habe.
Ich habe für eine verteilte IBM Struktur, die sich mit alten und neuen PCs
gemischt hatte (historisch gewachen) und so IPX und IP wild durcheinander
benutzte (wobei SNA auch über IPX und IP gesprochen wurde) die Infrastruktur
komplett erneuert. Dabei lernt man, SNA zu hassen. Wirklich. Man kann es
nicht routen, man bekommt Ausschlag von den Explorerstürmen zum Beginn der
Bürozeiten im gesamten Landkreis etc. pp. Man kann natürlich auch viel
machen, z.B. Explorerproxies betreiben, SNA Sessions lokal terminieren und
nur die Datenmenge übers WAN schieben, um dann dem Host gegenüber wieder ein
logisches Gerät zu simulieren. Aber schön ist das nicht. IPX ist schön. IP
ist brauchbar.
Jakob Creutzig
Ich nitpicke 'mal. Wenn ich schon was
so nett erklaert kriege;-)
> Wenn man ein IP Paket auf die Reise schickt, dann kann es
> passieren, daß unterwegs die Leitungs-MTU kleiner wird und das
> Paket nicht mehr druchpaßt. Normalerweise zerlegt der Router dem
^^ ^,
> Manchmal will man das nicht, so daß man ein 'Dont Fragment' Bit
^'
> im IP Header setzen kann, wenn das Paket nicht zerlegt werden
> darf. In dem Fall schickt der Router, dem das trotzdem passiert
^,
> Nun ist vor einigen Jahren jemand sich gedacht, daß es prima
hat^^^ ^------------------^^^^^^^^^^^
> wäre, den Routern die Arbeit zu erleichtert. Er hat nun alle
> Pakete mit gesetztem DF Bit gesendet. Kam von einem Router eine
> ICMP Fehlermeldung zurück, dann hat er die in der Fehlermeldung
> mit angegebene maximale Größe der Strecke genommen und nur für
> diese Verbindung kleinere Pakete gesendet. Das Ganze nennt man
> PMTUD.
<dumm nachfrag> Und das ist nur relevant, wenn man sein Paket wirklich
nicht zerhackt haben will (warum auch immer), richtig?
Das kann man ohne Probleme ignorieren/abschalten, oder?
> Darüberhinaus gibt es Buffergrenzen, die ein IP-Stack vorhält
^^^^^
> kann, wenn er TCP-Segmente verarbeitet. Um der Gegenseite
> mitzuteilen, welche maximalen Segmentgrößen er verträgt, setzt
> er beim Verbinungsaufbau (SYNC) die Option TCPMSS (TCP Maximum
> Segment Size).
>
> Irgendwann beobachtete jemand anderes, daß die "dünneren"
> Leitungen, die also kleinere MTUs haben, meist beim Endpunkt einer
> Verbindung stehen und dachte sich, man könne die Buffergrenzen
> des TCP Stacks als Obergrenze der MTU ebenfalls interpretieren.
^-----------------------^^^^^^^^^
Oder hab' ich das missverstanden?
> Neu in dem Szenario sind jetzt die strunzdämlichen
> Paketfilter-Admins, die ICMP als Angriff werten und abschalten.
Gibt es auch einen Grund fuer diese Interpretation?
> Danach geht nichts mehr, wenn einer von beiden PMTUD probiert. Die
> Pakete grundsätzlich nicht druchkommen können, weil die
^ ^^ +^^^^^^
+-------------------------------|
> Fehlermeldungen weggeworfen werden. So und anstatt nun einfach
^,
> PMTUD abzuschalten, so daß es gar keine Fehlermeldungen mehr
<wirklich dumm nachfrag>
Also, das heisst, einfach kein DF-Bit zu setzen und fertig, ja?
</>
> Anstatt den Wunsch der betreffenden Firma zu respektieren und die
> Webseiten links liegen zu lassen, setzen die Leute ihre MTU auf
> den Interfaces herab, produzieren so kleinere Buffer im TCP-Stack,
^und
Merci bien,
Jakob
Lutz Donnerhacke
> Ich nitpicke 'mal. Wenn ich schon was so nett erklaert kriege;-)
Danke. Nur so funktioniert's.
>> wäre, den Routern die Arbeit zu erleichtert. Er hat nun alle
>> Pakete mit gesetztem DF Bit gesendet. Kam von einem Router eine
>> ICMP Fehlermeldung zurück, dann hat er die in der Fehlermeldung
>> mit angegebene maximale Größe der Strecke genommen und nur für
>> diese Verbindung kleinere Pakete gesendet. Das Ganze nennt man
>> PMTUD.
>
><dumm nachfrag> Und das ist nur relevant, wenn man sein Paket wirklich
> nicht zerhackt haben will (warum auch immer), richtig?
Ja.
> Das kann man ohne Probleme ignorieren/abschalten, oder?
Abschalten, ja. Ignorieren, nein, sonst wäre es keine FAQ.
>> Neu in dem Szenario sind jetzt die strunzdämlichen
>> Paketfilter-Admins, die ICMP als Angriff werten und abschalten.
>
> Gibt es auch einen Grund fuer diese Interpretation?
Strunzdämlichkeit? Arbeiten ohne Kenntnisse? Ich weiß nicht, warum man das
tut.
>> PMTUD abzuschalten, so daß es gar keine Fehlermeldungen mehr
>
><wirklich dumm nachfrag>
> Also, das heisst, einfach kein DF-Bit zu setzen und fertig, ja?
></>
Ja.
Rainer Sokoll
> Lutz Donnerhacke <lu...@iks-jena.de> writes:
> > Neu in dem Szenario sind jetzt die strunzdämlichen
> > Paketfilter-Admins, die ICMP als Angriff werten und abschalten.
>
> Gibt es auch einen Grund fuer diese Interpretation?
Angst vor Portscans (die oftmals mit einem icmp echo request beginnen),
ping of death, Haluk-Syndrom...
Rainer
Thorsten Dahm
>> Ok, ich entschuldige mich dafür :)
> Nicht mit dem Grinsen im Gesicht.
*in die Ecke stell und schäm*
Besser?
> Ich habe für eine verteilte IBM Struktur, die sich mit alten und neuen
> PCs gemischt hatte (historisch gewachen) und so IPX und IP wild
> durcheinander benutzte (wobei SNA auch über IPX und IP gesprochen
> wurde) die Infrastruktur komplett erneuert. Dabei lernt man, SNA zu
> hassen. Wirklich. Man kann es nicht routen, man bekommt Ausschlag von
> den Explorerstürmen zum Beginn der Bürozeiten im gesamten Landkreis
> etc. pp. Man kann natürlich auch viel machen, z.B. Explorerproxies
> betreiben, SNA Sessions lokal terminieren und nur die Datenmenge übers
> WAN schieben, um dann dem Host gegenüber wieder ein logisches Gerät zu
> simulieren.
Das ist allerdings wirklich schlimm. Das letzte mal, als ich mit dem
Protokoll zu tun hatte, ging SNA über die guten alten 3270 und wurde im
LAN einfach huckepack auf IPX draufgepackt. Das lief eigentlich recht
problemlos.
> Aber schön ist das nicht. IPX ist schön. IP ist brauchbar.
Full ACK. IPX ist ein gutes Protokoll, Appletalk ebenfalls (obwohl ich
wegen dem blöden Protokoll einmal durch die Support-Prüfung gefallen
bin). Mit IP kann man leben.
Lutz Donnerhacke
> Full ACK. IPX ist ein gutes Protokoll, Appletalk ebenfalls (obwohl ich
> wegen dem blöden Protokoll einmal durch die Support-Prüfung gefallen
> bin). Mit IP kann man leben.
Appletalk ist nicht schön.
Lasse J. Kolb
<lu...@iks-jena.de> wrote:
>* Thorsten Dahm wrote:
>> begin Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>> Und hier hast Du einen Verweis auf
>>> http://groups.google.com/groups?selm=slrnali687.om.lutz%40taranis.iks-j
>>> ena.de bekommen.
>>
>> Vielleicht solltest Du den Text auch mal in die FAQ aufnehmen.
>
>http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#PMTUD
>
> Warum muß man die MTU Größe anpassen, wenn Paketfilter eingesetzt
> werden?
Ich verwende eine MTU-Size von 1492 und hatte bisher keine (bewußten)
Probleme mit irgendwelchen Webseiten. Verwende IPtables.
Ist diese MTU-Size brauchbar, oder sollte ich sie ändern/optimieren?
Sollte ich bei IPtables die Regeln mit MTU-Parametern modifizieren?
Provider ist T-Online, DSL.
Gruß,
Lasse
--
http://www.bsn.ch/Lasse
PGP: 0xBCF7BF1B (DSS/D-H) · 0x4A1802C9 (RSA)
Thorsten Dahm
Ich mochte immer das "reinstecken und geht, aber keiner weiß warum". Und
ich denke, auch mit Cableranges etc. kann man sich anfreunden, wenn man
damit arbeitet.
Lutz Donnerhacke
> Ich verwende eine MTU-Size von 1492 und hatte bisher keine (bewußten)
> Probleme mit irgendwelchen Webseiten. Verwende IPtables.
Du hast das getan, was in der Antwort als TCPMSS Hack beschrieben ist.
Lutz Donnerhacke
> begin Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Appletalk ist nicht schön.
>
> Ich mochte immer das "reinstecken und geht, aber keiner weiß warum". Und
> ich denke, auch mit Cableranges etc. kann man sich anfreunden, wenn man
> damit arbeitet.
Versuche damit großflächig zu routen.
Thorsten Dahm
> Versuche damit großflächig zu routen.
Ok, ich bin zwar seit besagter Support-Prüfung in der Theorie bewandert,
allerdings habe ich noch nie ein Appletalk-Netz mit mehr als 5 Nodes
betreut. Im LAN war das ganze dann recht erträglich.
Felix von Leitner
> Mein Modemlink lief jahrelang mit einer MTU kleiner 700 Byte. Mit
> voller Absicht.
Bei mir hat das nie was gebracht :-(
> > Und warum steht dann in diversen Howto's, man solle die MTU niedriger
> > setzen, damit die Verbindung klappt?
> Weil zwei Hyperschlaue und eine Masse von mit dem Klammerbeutel gepuderten
> Admins richtig große Scheiße genaut haben.
Genau genommen steht das da gar nicht.
Da steht, man soll MSS Clamping benutzen.
Nicht, daß das besser wäre...
> >> > Oftmals Standard = 1492
> >> Nein.
> > Aus RFC 2516 (PPPoE)
> Und nun denke bitte über PPPoE nach. Gründlich. Im Zusammenhang mit der
> Ethernet MTU. Danke.
Wenn du ihm weiter hilfst, explodiert sein Kopf.
Felix
--
>>Irgendwo in D-Dorf koennenten wir ihn sicherlich "verlieren",
>>einmauern, versenken oder so.
> Es gibt doch in der Gegend bestimmt eine Sondermuelldeponie, oder?
Du meinst Köln? --slrnavl4qf....@nepomuk.stw.uni-duisburg.de
Felix von Leitner
> Sorry, dass ich Euch belästige, aber generell ist mir wurscht was MTU
> ist. Mein Problem ist, dass ich mit ner Software (secu remote client)
> arbeiten muss, die mich ehrlichgesgt nen Scheissdreck interessiert.
Und wie kommst du dann darauf, daß wir uns hier für deine
Schweine-Software interessieren, wenn du noch nicht mal selber genügend
Interesse für dein Problem aufbringen kannst, um dich erst mal
grundlegend zu informieren?
> Auf meine Frgae bei Checkpoint warum das nicht tut habe ich nur gesagt
> bekommen MTU Size zu gross. Nicht mehr!
Das haben sie mit großer Wahrscheinlichkeit nicht gesagt.
Checkpoint sind zwar nicht die Hellsten, aber so schlecht sind sie nicht.
Felix von Leitner
> wäre, den Routern die Arbeit zu erleichtert. Er hat nun alle
> Pakete mit gesetztem DF Bit gesendet.
Das stimmt nicht.
> Kam von einem Router eine ICMP Fehlermeldung zurück, dann
> hat er die in der Fehlermeldung mit angegebene maximale
> Größe der Strecke genommen und nur für diese Verbindung
> kleinere Pakete gesendet. Das Ganze nennt man PMTUD.
Bei _TCP_ macht man das so. Oben sprachst du von IP.
> Darüberhinaus gibt es Buffergrenzen, die ein IP-Stack vorhält
> kann, wenn er TCP-Segmente verarbeitet. Um der Gegenseite
> mitzuteilen, welche maximalen Segmentgrößen er verträgt, setzt
> er beim Verbinungsaufbau (SYNC) die Option TCPMSS (TCP Maximum
> Segment Size).
Das ist auch Unfug. In TCP ist mit Puffergröße noch am ehesten die
Window Size zu assoziieren. Die Segment Size sagt aus, wie viel
Nutzdaten in einem TCP Paket höchstens enthalten sind. Es macht Sinn,
diesen Wert möglichst so zu wählen, daß zuzüglich IP Header die Path MTU
nicht überschritten wird. Das liegt daran, daß IP sonst fragmentiert,
und keinen Mechanismus kennt, um einzelne Fragmente nochmal zu schicken.
Wenn aus einem 32k Paket ein Fragment verloren geht, müssen alle
Fragmente dieses Paketes nochmal geschickt werden. Das verschwendet
Bandbreite und Speicherplatz auf dem Zielrechner, weil der für Fragmente
gewöhnlich nur einen relativ begrenzten nicht swapbaren Platz im Kernel
reserviert hat.
> Irgendwann beobachtete jemand anderes, daß die "dünneren"
> Leitungen, die also kleinere MTUs haben, meist beim Endpunkt einer
> Verbindung stehen und dachte sich, man könne die Buffergrenzen
> des TCP Stacks als Obergrenze der MTU ebenfalls interpretieren.
Schlußfolgerung aus falsch dargestellten Fakten.
> Der Gedanke allein ist derartig schwachsinnig, daß es schmerzt:
> Hier wurde Kausalität und Korrelation verwechselt. Man setzt
> nämlich die Puffergrenzen so, daß sie in der lokalen Umgebung
> sinnvoll sind, und das ist zufällig die LeitungsMTU am nächsten
> Interface, weil ja einkommende Pakete eh' nicht größer sein
> können. Das sagt natürlich gar nichts über die MTU der
> Leitungen zwischen den Endgeräten aus, besonders, da die
> allerletzte Strecke meist ein "dickes" Ethernetinterface ist.
Das ist eine Effizienzüberlegung. Wenn ich 1500er Pakete rausschicke
und die dann unterwegs in zwei Fragmente zerlegt werden, dann muß das
erstens die Gegenseite wieder zusammensetzen und zweitens verdopple ich
den Overhead durch die IP-Header. Und mehr Pakete heißt auch: mehr Last
auf den Routern.
Deine Darstellung ist also nicht nur sachlich falsch, sie empfiehlt auch
noch Maßnahmen, die die Infrastruktur des Internets unnötig schädigen.
> Kurz gesagt hat sich der Letztgenannte also eine Modifikation des
> TCP/IP Stacks dahingehend einfallen lassen, daß der den TCPMSS
> Parameter als Startwert für PMTUD nimmt.
Unfug. Die Path MTU Discovery ist kein eigener Prozeß oder eine
Unterroutine sondern einfach nur eine kleine Modifikation in der TCP
State Machine. Die Path MTU findet genau so statt wie vorher, nur wird
der (im Übrigen ja völlig überflüssige und die Latenz verschlechternde)
erste Schritt des Fehlers und darauffolgenden Senkens der MTU vermieden.
Es kommt also nicht nur dem Internet und den Routern zugute, sondern
vor allem auch dem User selber.
> Anstatt den Wunsch der betreffenden Firma zu respektieren und die
> Webseiten links liegen zu lassen, setzen die Leute ihre MTU auf
> den Interfaces herab, produzieren so kleinere Buffer im TCP-Stack,
> der von anderen Systemen bequem überschrieben werden kann, so
> daß man sich selbst eine Sicherheitslücke baut und von der
> Kommunikation mit anderen Systemen ausschließt.
Lutz, das Herabsetzen der MTU ist wirklich dämlich und hat mit dem
Senken der TCP MSS genau nichts zu tun. Man kann prima auf dem PPPOE
Router die MSS senken und im lokalen LAN trotzdem die vollen 1500 Bytes
fahren. Ich mache das hier z.B. so.
> Es sei denn, man sagt die kleinere MTU /allen/ Geräten im
> lokalen Netz, auch dem Server.
Auch das ist falsch. Das Senken der MTU verhindert nicht, daß mir
andere im LAN große Pakete schicken können. Es verhindert nur, daß ich
anderen Pakete mit den vollen 1500 Bytes schicken kann. Das unilaterale
Senken der MTU verhindert nicht, daß man sich mit anderen im selben LAN
unterhalten kann.
Felix
Felix von Leitner
[DF Bit]
> > Wann will man das denn nicht?
> Bei manchen SNA-Verbindungen beispielsweise.
ROTFL, lange habe ich nicht mehr so einen uninformierten Müll gelesen!
Für Anwendungen und Tunnel über IP ist die Fragmentierung
selbstverständlich absolut transparent. Das ist ja gerade die Idee bei
dem Schichtenmodell.
Felix von Leitner
> Eigenintelligenz verfügt (z.B. Switch/Printserver/USV/...).
?!
Mit Switches und Printservern spricht man sogar TCP, die müssen also per
Definition genug Eigenintelligenz für Fragmentierung haben. Ansonsten
sind sie halt kaputt.
> Diese Geräte unterstützen zwar Protokolle wie SNMP, aber bearbeiten
> jedes Paket einzeln und sofort. Der IP Stack ist somit sehr minimal
> ausgeführt und beherrscht oft keine Fragmentierung.
ROTFL! Bei SNMP über TCP kann der dumme Stack einfach die MSS klein
wählen, und bei UDP sind die einzelnen Pakete normalerweise eh deutlich
kleiner als die Paketgröße. Und wenn sie größer als die MTU sind, dann
hilft DF natürlich auch nicht. Im Gegenteil, die Pakete können dann gar
nicht erst geschickt werden.
> Man verwendet DF auch dann, wenn es auf Paketverlust weniger ankommt als auf
> extrem kurze Latenzen, z.B. bei Sprach- und Videoübertragung.
Unfug. Die dahin führende Argumentation ist ja auch Unsinn. Gerade bei
Sprach- und Videoübertragung ist die Qualität der Übertragung
vollständig von der Höhe des Paketverlustes abhängig. Man kann das
kompensieren, indem man weitere redundante Pakete überträgt, aber die
sind genau so groß wie die Datenpakete, d.h. würden dann auch gedroppt.
Natürlich ist hohe Latenz schlecht, aber hohe Latenz ist besser als gar
keine Übertragung.
> Man verwendet DF auch dann, wenn man nicht weiß mit wem man es zu tun hat,
> z.B. bei Multicasting, wo mehrere Empfänger für das gleiche Paket existieren.
Auch das war wohl nichts. Wenn du bei Multicast-Pakete DF setzt,
kriegen sie Leute hinter einer Leitung mit kleiner MTU gar nicht.
Welchen Vorteil soll das haben? Richtig, gar keinen.
Die Wahrheit ist, daß man DF in der Praxis nur für Path MTU Discovery
braucht.
Ach ja, mich interessiert noch, wie du eigentlich aus deiner Anwendung
heraus das DF Bit beeinflußt. Ich kenne da nämlich keine Methode, auch
wenn das nichts heißen will.
Felix
Felix von Leitner
Nein.
Felix von Leitner
> > Also, das heisst, einfach kein DF-Bit zu setzen und fertig, ja?
> ></>
> Ja.
Nein. Wenn das signifikant viele Leute tun, bricht uns die
Infrastruktur zusammen.
Laßt euch von Lutz hier keine Scheiße erzählen, Leute! Router sollen
_routen_ und nicht anderer Leute Pakete fragmentieren!
Felix von Leitner
> Ich verwende eine MTU-Size von 1492 und hatte bisher keine (bewußten)
> Probleme mit irgendwelchen Webseiten. Verwende IPtables.
Auf dem Router selber gibt es sowieso keine Probleme. Denn der sieht ja
seine lokale MTU und setzt daher die MSS für ausgehende TCP-Verbindungen
eh auf 1492.
Probleme gibt es nur, wenn der DSL-Rechner auch für andere Leute Traffic
routet, und die dann als MSS ihre MTU (1500) nehmen und irgendwelche
Deppen-Sites oder der DSL-Router keine Fragmentation Needed Pakete
verschicken, verstehen oder rein- oder rauslassen.
> Ist diese MTU-Size brauchbar, oder sollte ich sie ändern/optimieren?
Die ist genau richtig.
> Sollte ich bei IPtables die Regeln mit MTU-Parametern modifizieren?
Bei IPtables modifiziert man die TCP MSS, nicht die MTU.
Felix
Felix von Leitner
> Man verwendet DF, wenn man Technik ansprechen will, die über geringe
> Eigenintelligenz verfügt (z.B. Switch/Printserver/USV/...).
?!
Mit Switches und Printservern spricht man sogar TCP, die müssen also per
Definition genug Eigenintelligenz für Fragmentierung haben. Ansonsten
sind sie halt kaputt.
> Diese Geräte unterstützen zwar Protokolle wie SNMP, aber bearbeiten
> jedes Paket einzeln und sofort. Der IP Stack ist somit sehr minimal
> ausgeführt und beherrscht oft keine Fragmentierung.
ROTFL! Bei SNMP über TCP kann der dumme Stack einfach die MSS klein
wählen, und bei UDP sind die einzelnen Pakete normalerweise eh deutlich
kleiner als die MTU. Und wenn sie größer als die MTU sind, dann hilft
Lutz Donnerhacke
> Das ist eine Effizienzüberlegung. Wenn ich 1500er Pakete rausschicke
> und die dann unterwegs in zwei Fragmente zerlegt werden, dann muß das
> erstens die Gegenseite wieder zusammensetzen und zweitens verdopple ich
> den Overhead durch die IP-Header. Und mehr Pakete heißt auch: mehr Last
> auf den Routern.
'Den Routern' ist auch falsch.
> Deine Darstellung ist also nicht nur sachlich falsch, sie empfiehlt auch
> noch Maßnahmen, die die Infrastruktur des Internets unnötig schädigen.
Ich bitte Dich den Antworttext korrekt zu schreiben. Ich habe nur meine
Meinung des Sachverhalts wiedergegeben. Aber bitte keine djb artige
Propaganda.
> Lutz, das Herabsetzen der MTU ist wirklich dämlich und hat mit dem
> Senken der TCP MSS genau nichts zu tun. Man kann prima auf dem PPPOE
> Router die MSS senken und im lokalen LAN trotzdem die vollen 1500 Bytes
> fahren. Ich mache das hier z.B. so.
Du machst es an einer ganz anderen Stelle, als ich beschrieb, oder?
> Auch das ist falsch. Das Senken der MTU verhindert nicht, daß mir
> andere im LAN große Pakete schicken können. Es verhindert nur, daß ich
> anderen Pakete mit den vollen 1500 Bytes schicken kann. Das unilaterale
> Senken der MTU verhindert nicht, daß man sich mit anderen im selben LAN
> unterhalten kann.
Ich hatte so einen Linuxkernel, der Pakete ueber der MTU entsorgt hat. Ob
das normkonform war, hat mich nicht interessiert.
Lutz Donnerhacke
>> ><wirklich dumm nachfrag>
>> > Also, das heisst, einfach kein DF-Bit zu setzen und fertig, ja?
>> ></>
>> Ja.
>
> Nein. Wenn das signifikant viele Leute tun, bricht uns die
> Infrastruktur zusammen.
Nein.
> Laßt euch von Lutz hier keine Scheiße erzählen, Leute! Router sollen
> _routen_ und nicht anderer Leute Pakete fragmentieren!
Und die Studien zu PMTUD setzen ungefiltertes ICMP voraus.
Laßt euch von Felix hier keine Scheiße erzählen, Leute! Router sollen
_routen_ und wenn notwendig transparent Pakete fragmentieren!
Lutz Donnerhacke
> braucht.
Quelle?
Juergen P. Meier
Also irgendwie muss ich das "An Internet router must not fragment
packets" in RfC-1812 uebersehen haben.
Ich konnte dazu nur folgendes finden:
2.3 Router Characteristics
An Internet router performs the following functions:
[...]
(3) Receives and forwards Internet datagrams. Important issues in
this process are buffer management, congestion control, and
fairness.
o Recognizes error conditions and generates ICMP error and
information messages as required.
o Drops datagrams whose time-to-live fields have reached zero.
o Fragments datagrams when necessary to fit into the MTU of the
next network.
Aber womoeglich sprichst du ja von einem anderen Internet.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
USENET incompatible and broken newsreaders are not supported.
Don't complain to me! Complain to the vendor of your software.
Marc 'zebroc' Herbrechter
> Laßt euch von Felix hier keine Scheiße erzählen, Leute!
OK.
> Router sollen _routen_ und wenn notwendig transparent Pakete
> fragmentieren!
Aha?
Du beschäftigst dich zwar intensiver mit Routing als ich, aber ich
verstehe nicht wie du auf so etwas kommst. -v bitte.
Ich für meinen Teil habe mal ein paar Minuten lang einem Router bei
einem großen Frankfurter Provider über die Schulter geschaut. Würde
diesem noch die Aufgabe des fragementierens übertragen, au weia.
--
Best regards,
Marc Herbrechter <m...@zebroc.de>
http://www.zebroc.de/ | http://www.project-genuine.net/
"Zwei Dinge sind unendlich: das Universum und die menschliche Dummheit;
aber bei dem Universum bin ich mir noch nicht ganz sicher." A. Einstein
Juergen P. Meier
> Lutz Donnerhacke wrote:
>
>> Router sollen _routen_ und wenn notwendig transparent Pakete
>> fragmentieren!
>
> verstehe nicht wie du auf so etwas kommst. -v bitte.
RfC-1812
> Ich für meinen Teil habe mal ein paar Minuten lang einem Router bei
> einem großen Frankfurter Provider über die Schulter geschaut. Würde
> diesem noch die Aufgabe des fragementierens übertragen, au weia.
Hat er Links mit unterschiedlicher MTU? Nein? Was soll dieses
Null-Argument dann?
Marc 'zebroc' Herbrechter
> > einem großen Frankfurter Provider über die Schulter geschaut. Würde
> > diesem noch die Aufgabe des fragementierens übertragen, au weia.
>
> Hat er Links mit unterschiedlicher MTU? Nein? Was soll dieses
> Null-Argument dann?
Wenn er Links mit unterschiedlicher MTU hätte, müsste er fragmentieren.
Täte er dies selber, hätte er nen Arsch voll zu tun. In diesem Fall
deutlich zu viel.
Es steht doch auch nicht vor jedem Tunnel ein Trupp halbstarker, welche
dir die Fährräder vom Dach holen, wenn du zu blöde warst die Schilder
zu lesen, oder?
Lutz Donnerhacke
> Juergen P. Meier wrote:
>> > einem großen Frankfurter Provider über die Schulter geschaut. Würde
>> > diesem noch die Aufgabe des fragementierens übertragen, au weia.
>>
>> Hat er Links mit unterschiedlicher MTU? Nein? Was soll dieses
>> Null-Argument dann?
>
> Wenn er Links mit unterschiedlicher MTU hätte, müsste er fragmentieren.
> Täte er dies selber, hätte er nen Arsch voll zu tun.
Richtig.
> In diesem Fall deutlich zu viel.
Nein. Mit der kaputten PMTUD generiert er sackweise ICMP Nachrichten. Das
ist etwas komplexer als Fragmentierung (das einfach im Queuing mit geschieht).
> Es steht doch auch nicht vor jedem Tunnel ein Trupp halbstarker, welche
> dir die Fährräder vom Dach holen, wenn du zu blöde warst die Schilder
> zu lesen, oder?
Bei Autos ist DF aus gutem Grund fast immer gesetzt.
Juergen P. Meier
>> > einem großen Frankfurter Provider über die Schulter geschaut. Würde
>> > diesem noch die Aufgabe des fragementierens übertragen, au weia.
>>
>> Hat er Links mit unterschiedlicher MTU? Nein? Was soll dieses
>> Null-Argument dann?
>
> Wenn er Links mit unterschiedlicher MTU hätte, müsste er fragmentieren.
> Täte er dies selber, hätte er nen Arsch voll zu tun. In diesem Fall
> deutlich zu viel.
Wenn irgend ein Depp einen Router mit verschiedenen MTUs hinstellt,
der mit Fragmentierung ueberfordert waere, dann *hat* *er* *es*
*nicht* *anders* *verdient* wenn ihm die schrottkiste um die Ohren
fliegt. Ein Router, der Teil des Internet sein soll, muss sich ganz
einfach an die dort geltenden Standards halten. Lies dir also nochmal
RfC 1812 durch.
Es gibt einen Grund warum Ethernetrouter dahingehend optimiert sind,
Pakete zu routen ohne sie erst fragmentieren zu muessen, weil sie
garnicht erst in die Verlegenheit kommen fragmentieren zu muessen.
Im Zusammenhang mit PMTUD von Core-routern zu sprechen ist purer FUD.
Bei einem Accessrouter (da sind MTU-unterschiede normal) oder Router
zu anderen Layer-1 Netzen (Framerelay, Toterring, ATM) muss man eben
mit Fragmentierungsaufwand rechnen. Wenn man da eine kiste hinstellt,
die allein durchs Routen schon bis auf 2µm an die Wand gefahren wird,
dann hat der Depp^WEinkaeufer was falsch gemacht. Diesen Fehler dann
einfach dem Rest der Welt aufzutischen und alle anderen dazu zwingen
zu wollen, PMTUD zu machen mag zwar bequem und modern sein, aber mir
solltest du damit nicht gegenuebertreten.
Es sollte einem zu denken geben, wenn hier Leute behaupten, ein Router
wuerde weniger belastet, wenn er fuer jedes grosse Paket ein ICMP paket
generieren muesste (wo er den Header reinkopieren muss), als wenn er
diese einfach nur in Fragmente zerlegen wuerde. Letzteres kann nicht
viel mehr Aufwand machen und hat den gewaltigen Vorteil, das das Paket
auch tatsaechlich ohne groessere Verzoegerung beim Ziel ankommt.
(Gehirntote Paketfilter: s/ohne groessere Verzoegerung/ueberhaupt/)
Sicher, bei persistenten TCP Verbindungen wo gleich ein ganzer Movie
oder ein CD-Image irgendeiner Software gesaugt wird ist es
effizienter, wenn die MSS der PMTU angepasst wird, aber gerade bei
normalen HTTP wo eine TCP Verbindung oft aus weniger als 20 Paketen
besteht (inkl. Handshake), rechnet sich das eben genau nicht.
Und bei anderen Protokollen ist das sowieso nicht relevant.
> Es steht doch auch nicht vor jedem Tunnel ein Trupp halbstarker, welche
> dir die Fährräder vom Dach holen, wenn du zu blöde warst die Schilder
> zu lesen, oder?
Aehem, du hast die RfCs gelesen, die das Internet seit spaetestens
1987 dahingehend spezifizieren? Ein Blick in den aktuellen RfC-index
zeigt das zumindest RfC 1812 noch immer gueltig ist.
Achja: gerade bei der PMTUD diskussion sollte jeder auch mal einen
kurzen Blick auf RfC 1122 Abschnitt 1.2.2 werfen.
Felix von Leitner
> > und die dann unterwegs in zwei Fragmente zerlegt werden, dann muß das
> > erstens die Gegenseite wieder zusammensetzen und zweitens verdopple ich
> > den Overhead durch die IP-Header. Und mehr Pakete heißt auch: mehr Last
> > auf den Routern.
> 'Den Routern' ist auch falsch.
Nein, wieso?
Zwischen meinem momentanen DSL-Anschluß und www.iks-jena.de liegen 18
Hops. Willst du mir sagen, das seien keine Router?
> > Deine Darstellung ist also nicht nur sachlich falsch, sie empfiehlt auch
> > noch Maßnahmen, die die Infrastruktur des Internets unnötig schädigen.
> Ich bitte Dich den Antworttext korrekt zu schreiben.
Das war korrekt.
> Ich habe nur meine Meinung des Sachverhalts wiedergegeben.
Du hast es als Fakten dargestellt.
> > Lutz, das Herabsetzen der MTU ist wirklich dämlich und hat mit dem
> > Senken der TCP MSS genau nichts zu tun. Man kann prima auf dem PPPOE
> > Router die MSS senken und im lokalen LAN trotzdem die vollen 1500 Bytes
> > fahren. Ich mache das hier z.B. so.
> Du machst es an einer ganz anderen Stelle, als ich beschrieb, oder?
Nein. Das Herabsetzen der MTU am Endgerät beeinträchtigt auch den
LAN-Traffic. Das Herabsetzen der MSS im Router beeinträchtigt nicht nur
nichts, es reduziert sogar die Latenz gegenüber normaler Path MTU
Discovery, weil der Schritt mit dem ICMP im Normalfall wegfällt.
Dein Gerante ist also inhaltlich falsch. Rein von der Ästhetik her ist
es nicht toll, wenn die Path MTU Discovery nicht funktioniert. Aber
praktisch macht es auch Sinn, die MSS runterzusetzen, wenn sie doch
funktioniert, weil das eben wie gesagt Latenz spart.
Felix
Felix von Leitner
> Nein. Mit der kaputten PMTUD generiert er sackweise ICMP Nachrichten. Das
> ist etwas komplexer als Fragmentierung (das einfach im Queuing mit geschieht).
Soso, ein Paket auf zwei aufzuteilen, neue Header davor zu tun, und
_zwei_ Checksummen zu erzeugen, das ist also aufwendiger als ein Paket
wegzuschmeißen und ein ICMP-Pakete mit einer Checksumme zu generieren,
ja? Es ist deiner Meinung weniger aufwendig, zwei Pakete rauszuschicken
als zwei?
Lutz, das mit der Arithmetik üben wir besser noch mal.
Felix von Leitner
> > braucht.
> Quelle?
Die Praxis.
Alle anderen von dir genannten Fälle sind widerlegt worden.
Wenn du doch einen anderen Fall zeigen kannst, wo man DF braucht, dann
tu es und betrachte mich als widerlegt. Die Beweislast liegt bei dir.
Felix
Lutz Donnerhacke
>> > Das ist eine Effizienzüberlegung. Wenn ich 1500er Pakete rausschicke
>> > und die dann unterwegs in zwei Fragmente zerlegt werden, dann muß das
>> > erstens die Gegenseite wieder zusammensetzen und zweitens verdopple ich
>> > den Overhead durch die IP-Header. Und mehr Pakete heißt auch: mehr Last
>> > auf den Routern.
>> 'Den Routern' ist auch falsch.
>
> Nein, wieso?
> Zwischen meinem momentanen DSL-Anschluß und www.iks-jena.de liegen 18
> Hops. Willst du mir sagen, das seien keine Router?
Das sind keine Router, die fragmentieren, da sie überall die gleiche MTU
vorfinden.
>> > Deine Darstellung ist also nicht nur sachlich falsch, sie empfiehlt auch
>> > noch Maßnahmen, die die Infrastruktur des Internets unnötig schädigen.
>> Ich bitte Dich den Antworttext korrekt zu schreiben.
>
> Das war korrekt.
Aber nicht FAQ gerecht. Einfach per Mail.
>> Ich habe nur meine Meinung des Sachverhalts wiedergegeben.
>
> Du hast es als Fakten dargestellt.
Ich bin der Meinung, daß meine Meinung den Fakten entspricht.
>> > Lutz, das Herabsetzen der MTU ist wirklich dämlich und hat mit dem
>> > Senken der TCP MSS genau nichts zu tun. Man kann prima auf dem PPPOE
>> > Router die MSS senken und im lokalen LAN trotzdem die vollen 1500 Bytes
>> > fahren. Ich mache das hier z.B. so.
>>
>> Du machst es an einer ganz anderen Stelle, als ich beschrieb, oder?
>
> Nein. Das Herabsetzen der MTU am Endgerät beeinträchtigt auch den
> LAN-Traffic.
Das ist das, was ich sagte.
> Das Herabsetzen der MSS im Router beeinträchtigt nicht nur nichts, es
> reduziert sogar die Latenz gegenüber normaler Path MTU Discovery, weil
> der Schritt mit dem ICMP im Normalfall wegfällt.
Das setzt aber voraus, daß der Router in den TCP Datenstrom zwischen zwei
Endgeräten eingreift und darin Optionen setzt oder modifiziert. Und das nur,
damit er nicht fragmentieren muß?
> Dein Gerante ist also inhaltlich falsch. Rein von der Ästhetik her ist
> es nicht toll, wenn die Path MTU Discovery nicht funktioniert. Aber
> praktisch macht es auch Sinn, die MSS runterzusetzen, wenn sie doch
> funktioniert, weil das eben wie gesagt Latenz spart.
Rein praktisch gesehen hat meine Argumentation aber den betroffenen Firmen
deutlich besser geholfen als die Versuche weitere Hack - ala Deine
Interpretation - einzuführen. Ich mag mich irren, aber IMHO entspricht meine
Schilderung der Realität.
Lutz Donnerhacke
>> > Die Wahrheit ist, daß man DF in der Praxis nur für Path MTU Discovery
>> > braucht.
>> Quelle?
> Die Praxis.
Witzigerweise benutzen wir beide das gleiche Argument. Und nun?
> Alle anderen von dir genannten Fälle sind widerlegt worden.
Die wesentliche Studie zu PMTUD habe ich vor einigen Wochen in der passenden
Newsgruppe zerlegt. Und nun?
> Wenn du doch einen anderen Fall zeigen kannst, wo man DF braucht, dann tu
> es und betrachte mich als widerlegt. Die Beweislast liegt bei dir.
Beweislast zu postuliern ist armselig.
Andre Peper
Dennis Herbrich
Hash: SHA1
On 17 Dec 2002 at 15:00 GMT, Andre Peper wrote:
>>> IPX ist schön.
>>
>>Nein.
>
> Dann frag mal Novell
Genau.
Und wenn wir dabei sind, koennen wir ja nochmal kurz IBMs Meinung zu
TokenRing, und Microsofts Meinung zu NetBIOS einholen, nicht wahr?
Bitte, bitte lass das Ironie ohne Smiley gewesen sein! ;)
Gruss,
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE9/y8XemI2sSs8ZG0RAqgYAJ9xdtvikUtlivnMvVifnaE2A/0f9gCeKXY7
WKzy1IszAFGHzBY2d3+sW4c=
=lZoj
-----END PGP SIGNATURE-----
--
We're Germans and we use Unix. That's a combination of two demographic
groups known to have no sense of humour whatsoever.
-- Hanno Mueller in de.comp.os.unix.programming GPG 0x2B3C646D
Felix von Leitner
> >> > Das ist eine Effizienzüberlegung. Wenn ich 1500er Pakete rausschicke
> >> > und die dann unterwegs in zwei Fragmente zerlegt werden, dann muß das
> >> > erstens die Gegenseite wieder zusammensetzen und zweitens verdopple ich
> >> > den Overhead durch die IP-Header. Und mehr Pakete heißt auch: mehr Last
> >> > auf den Routern.
> >> 'Den Routern' ist auch falsch.
> > Nein, wieso?
> > Zwischen meinem momentanen DSL-Anschluß und www.iks-jena.de liegen 18
> > Hops. Willst du mir sagen, das seien keine Router?
> Das sind keine Router, die fragmentieren, da sie überall die gleiche MTU
> vorfinden.
Ich habe behauptet, daß zwei Pakete mehr Last sind als ein Paket.
Ich sprach nicht von der Fragmentierung, die betrifft ja die Router
zwischen uns nicht.
> >> Ich habe nur meine Meinung des Sachverhalts wiedergegeben.
> > Du hast es als Fakten dargestellt.
> Ich bin der Meinung, daß meine Meinung den Fakten entspricht.
;)
> >> Du machst es an einer ganz anderen Stelle, als ich beschrieb, oder?
> > Nein. Das Herabsetzen der MTU am Endgerät beeinträchtigt auch den
> > LAN-Traffic.
> Das ist das, was ich sagte.
Ja. Daher ist das Senken der MTU am Endgerät schlecht, das Senken der
MSS aber nicht.
> > Das Herabsetzen der MSS im Router beeinträchtigt nicht nur nichts, es
> > reduziert sogar die Latenz gegenüber normaler Path MTU Discovery, weil
> > der Schritt mit dem ICMP im Normalfall wegfällt.
> Das setzt aber voraus, daß der Router in den TCP Datenstrom zwischen zwei
> Endgeräten eingreift und darin Optionen setzt oder modifiziert. Und das nur,
> damit er nicht fragmentieren muß?
Fragmentieren ist auch ein Eingriff in den Datenstrom. Das Senken der
MSS ist eine Sache, die der Router einmal pro SYN Paket machen muß.
Fragmentieren muß er pro Paket machen.
> > Dein Gerante ist also inhaltlich falsch. Rein von der Ästhetik her ist
> > es nicht toll, wenn die Path MTU Discovery nicht funktioniert. Aber
> > praktisch macht es auch Sinn, die MSS runterzusetzen, wenn sie doch
> > funktioniert, weil das eben wie gesagt Latenz spart.
> Rein praktisch gesehen hat meine Argumentation aber den betroffenen Firmen
> deutlich besser geholfen als die Versuche weitere Hack - ala Deine
> Interpretation - einzuführen. Ich mag mich irren, aber IMHO entspricht meine
> Schilderung der Realität.
Ich sage ja nicht, daß du den Firmen nicht MSS Clamping empfehlen
sollst. Und das Senken der MTU hilft ja auch; das macht es nicht zu
einer guten Lösung.
MSS Clamping ist die beste Lösung für das Problem, weil es die Anzahl
der Pakete reduziert, die der Router rausschicken muß, und es reduziert
auch die Last auf dem Router selber.
Felix
Felix von Leitner
> >> > Die Wahrheit ist, daß man DF in der Praxis nur für Path MTU Discovery
> >> > braucht.
> >> Quelle?
> > Die Praxis.
> Witzigerweise benutzen wir beide das gleiche Argument. Und nun?
Na ganz einfach. Du mußt ja nur ein einziges Paketchen zeigen außerhalb
Path MTU Discovery, bei dem DF gesetzt ist und Sinn macht. Wenn ich
denn Sinn nicht widerlegen kann, hast du Recht.
> > Alle anderen von dir genannten Fälle sind widerlegt worden.
> Die wesentliche Studie zu PMTUD habe ich vor einigen Wochen in der passenden
> Newsgruppe zerlegt. Und nun?
Was hat das damit zu tun?
> > Wenn du doch einen anderen Fall zeigen kannst, wo man DF braucht, dann tu
> > es und betrachte mich als widerlegt. Die Beweislast liegt bei dir.
> Beweislast zu postuliern ist armselig.
Sehe ich auch so. Warum tust du es dann?
Zeig doch einfach ein Beispiel neben PMTUD für DF, das ich nicht
widerlegen kann. Ganz einfach. Statt dessen von mir einen
Ausschlußbeweis zu verlangen ist mehr als unseriös.
Felix
Lutz Donnerhacke
> Ich sprach nicht von der Fragmentierung, die betrifft ja die Router
> zwischen uns nicht.
Gut. Und ich hatte schon öfter ausgeführt, was ich von Rechnungen halte, die
gerade so konstruiert sind, daß maximale Overhead für die Gegenthese gezeigt
wird. Ich möchte mich daran nicht beteiligen.
Wenn Du aber PMTUD predigst, dann sorge bitte für ein Netz ohne
Firewallblindfische, die ICMP Unreachable - Fragmentation needed filtern.
Solange es diese Filter gibt, ist PMTUD nicht einsetzbar.
Der Rückgang in die gute alte Zeit ohne DF Bits ist dagegen immer möglich.
> Ja. Daher ist das Senken der MTU am Endgerät schlecht, das Senken der
> MSS aber nicht.
Was hat nur die MSS mit der abgehenden Paketgröße zu tun? Was machst Du,
wenn die gegenüberliegende Kiste IP Options dranklemmt? Das sind völlig
verschiedene Layer die nur mittelbar einen Effekt aufeinander haben!
Ich ziehe es vor, an den Ursachen, statt an den Symptomen zu doktoren.
>> Das setzt aber voraus, daß der Router in den TCP Datenstrom zwischen
>> zwei Endgeräten eingreift und darin Optionen setzt oder modifiziert.
>> Und das nur, damit er nicht fragmentieren muß?
>
> Fragmentieren ist auch ein Eingriff in den Datenstrom. Das Senken der
> MSS ist eine Sache, die der Router einmal pro SYN Paket machen muß.
Dazu muß er TCP verstehen. Und damit ist das Problem für UDP und IPinIP und
GRE und ESP und ... nicht gelöst. Was soll der Unsinn also?
> Fragmentieren muß er pro Paket machen.
Ja, aber dafür braucht er keine Ahnung von Schicht vier zu haben. Und damit
sind die Punkte, in die er eingreift, statisch ermittelbar. Kein Parsing,
keine Fehlerbehandlung, es tut einfach.
>> Rein praktisch gesehen hat meine Argumentation aber den betroffenen
>> Firmen deutlich besser geholfen als die Versuche weitere Hack - ala
>> Deine Interpretation - einzuführen. Ich mag mich irren, aber IMHO
>> entspricht meine Schilderung der Realität.
>
> Ich sage ja nicht, daß du den Firmen nicht MSS Clamping empfehlen sollst.
> Und das Senken der MTU hilft ja auch; das macht es nicht zu einer guten
> Lösung.
Ich empfehle den Firmen PMTUD abzuschalten. Mit durchschlagendem Erfolg.
Und dann empfehle ich den Firmen, ihren Firewalladmins die Ohren lang zu
ziehen. Mit noch besserem Erfolg, weil ein ursächlicher Zusammenhang und ein
praktischer Effekt für meine Aussagen sprechen.
> MSS Clamping ist die beste Lösung für das Problem, weil es die Anzahl
> der Pakete reduziert, die der Router rausschicken muß, und es reduziert
> auch die Last auf dem Router selber.
Nein. Das gilt nur für Surf-Only-Daddel-Netz.
Lutz Donnerhacke
> Ausschlußbeweis zu verlangen ist mehr als unseriös.
Ich verlange keine Ausschlußbeweis, sondern eine saubere Erklärung, die ich
in die FAQ aufnehmen kann, von Dir. Wenn Du es allerdings vorziehst, nur
Daddelnetze mit TCP zu betrachten, dann werde ich das nicht tun.
Juergen P. Meier
>> > In diesem Fall deutlich zu viel.
>> Nein. Mit der kaputten PMTUD generiert er sackweise ICMP Nachrichten. Das
>> ist etwas komplexer als Fragmentierung (das einfach im Queuing mit geschieht).
>
> Soso, ein Paket auf zwei aufzuteilen, neue Header davor zu tun, und
s/neue/eine kopie des/
> _zwei_ Checksummen zu erzeugen, das ist also aufwendiger als ein Paket
> wegzuschmeißen und ein ICMP-Pakete mit einer Checksumme zu generieren,
Nein.
> ja? Es ist deiner Meinung weniger aufwendig, zwei Pakete rauszuschicken
> als zwei?
Fragmentierung hat zwei Vorteile:
a) es ist nicht von einer konstanten, symmetrischen Route abhaengig
und
b) die pakete kommen ohne Verzoegerungen und Wiederholungen an.
PMTUD hat zwei Vorteile:
a) Accessrouter auf dem Weg muessen bei laengeren TCP Verbindungen
nichts fragmentieren
b) Bei diesen laengeren TCP Verbindungen verringern sich die
Auswirkungen von Paketverlust (z.b. bei Ueberlastung) auf die
Uebertragungsrate.
Felix von Leitner
> > Ich sprach nicht von der Fragmentierung, die betrifft ja die Router
> > zwischen uns nicht.
> Gut. Und ich hatte schon öfter ausgeführt, was ich von Rechnungen halte, die
> gerade so konstruiert sind, daß maximale Overhead für die Gegenthese gezeigt
> wird. Ich möchte mich daran nicht beteiligen.
Offenbar bist du gerade nicht richtig ausgeschlafen. Ich habe hier gar
nichts konstruiert. TCP-Pakete von Bulk-Verbindungen sind in der Regel
(HTTP und FTP Downloads) alle bis auf das letzte MSS+Header groß. Bei
interaktiven Verbindungen ist es egal, weil eh nicht fragmentiert würde,
daher kannst du die nicht gemeint haben.
> Wenn Du aber PMTUD predigst, dann sorge bitte für ein Netz ohne
> Firewallblindfische, die ICMP Unreachable - Fragmentation needed filtern.
Im Gegenteil, ich predige MSS Clamping. Konzeptionell sollte es wegen
PMTUD überflüssig sein, ist es aber nicht. Aber auch wenn es
überflüssig wäre, würde MSS Clamping einen Performancegewinn bringen und
wäre damit predigenswert.
> Solange es diese Filter gibt, ist PMTUD nicht einsetzbar.
Da sind wir uns einig.
> Der Rückgang in die gute alte Zeit ohne DF Bits ist dagegen immer möglich.
Ja, nur ist das halt ineffizient.
> > Ja. Daher ist das Senken der MTU am Endgerät schlecht, das Senken der
> > MSS aber nicht.
> Was hat nur die MSS mit der abgehenden Paketgröße zu tun? Was machst Du,
> wenn die gegenüberliegende Kiste IP Options dranklemmt?
Dann hast du verloren. Genau wie bei dem einzigen Gegenvorschlag, dem
Senken der MTU.
> Das sind völlig verschiedene Layer die nur mittelbar einen Effekt
> aufeinander haben!
Ich will dich ja nicht mit Fakten bei deinem Rant stören, aber auf
Client-Seite kann man das Problem nicht lösen, außer man schaltet PMTUD
ab. Das ist aber nicht nur eine schlechte Idee, es geht z.B. bei IPv6
gar nicht.
> Ich ziehe es vor, an den Ursachen, statt an den Symptomen zu doktoren.
Gute Idee. Du besuchst jetzt also alle inkompetenten Firewall-Betreiber
mit einer Cruise Missile?
> > Fragmentieren ist auch ein Eingriff in den Datenstrom. Das Senken der
> > MSS ist eine Sache, die der Router einmal pro SYN Paket machen muß.
> Dazu muß er TCP verstehen.
Das muß NAT auch. Und trotzdem setzen es fast alle ein.
> Und damit ist das Problem für UDP und IPinIP und GRE und ESP und ...
Es gibt bei UDP kein Problem.
Niemand ist so dämlich, große UDP-Pakete mit gesetztem DF-Bit durch die
Gegend zu schicken.
Bei ESP macht natürlich der Tunnel Endpunkt MSS Clamping. Oder sprichst
du gerade von einem hypothetischen zukünftigen Internet, in dem man Peer
to Peer IPsec einsetzt? ROTFL
Genau so bei GRE und anderen Tunnels.
> nicht gelöst. Was soll der Unsinn also?
NAT funktioniert auch nicht mit ESP. Trotzdem setzen es fast alle ein.
Im realen Leben ist es nicht wichtig, ob es seltene Sonderfälle gibt,
bei denen ein Ansatz nicht hilft. Es ist wichtig, daß die Lösung die
ganzen typischen Fälle löst. Du bist doch gerade derjenige, der immer
"den Informatikern" vorgeworfen hat, was du gerade selber betreibst.
> > Fragmentieren muß er pro Paket machen.
> Ja, aber dafür braucht er keine Ahnung von Schicht vier zu haben.
Ja und? Interessiert doch kein Schwein. Wir leben in einer Zeit, wo
Layer 5 Switches verkauft werden.
> Und damit sind die Punkte, in die er eingreift, statisch ermittelbar.
Was soll denn bitte "statisch ermittelbar" heißen?
> Kein Parsing, keine Fehlerbehandlung, es tut einfach.
Natürlich parst man. Zumindest die Paketlänge muß man aus dem Header
rausparsen.
> > Ich sage ja nicht, daß du den Firmen nicht MSS Clamping empfehlen sollst.
> > Und das Senken der MTU hilft ja auch; das macht es nicht zu einer guten
> > Lösung.
> Ich empfehle den Firmen PMTUD abzuschalten. Mit durchschlagendem Erfolg.
Klar, für die Firma tut es. Für das Internet ist es schlecht.
Empfiehlst du den Leuten auch, im Winter mit Spikes zu fahren?
Für den einzelnen ist das sicherer, aber die Straßen macht es für alle
kaputt.
> Und dann empfehle ich den Firmen, ihren Firewalladmins die Ohren lang zu
> ziehen. Mit noch besserem Erfolg, weil ein ursächlicher Zusammenhang und ein
> praktischer Effekt für meine Aussagen sprechen.
Daß der Zusammenhang ursächlich ist, ist für die ungebildete Firma
erstmal eine reine Glaubens- oder Vertrauensfrage.
> > MSS Clamping ist die beste Lösung für das Problem, weil es die Anzahl
> > der Pakete reduziert, die der Router rausschicken muß, und es reduziert
> > auch die Last auf dem Router selber.
> Nein. Das gilt nur für Surf-Only-Daddel-Netz.
?
Du bist offensichtlich stark verwirrt.
Schlaf dich mal aus.
Felix von Leitner
> in die FAQ aufnehmen kann, von Dir. Wenn Du es allerdings vorziehst, nur
> Daddelnetze mit TCP zu betrachten, dann werde ich das nicht tun.
Daddelnetze mit TCP sind der einzige relevante Anwendungsfall, denn wir
sprachen davon PMTUD abzuschalten. Das ist nun mal schlicht ein TCP
Feature. Wenn du jetzt plötzlich UDP einbringst, ist das mehr als
unseriöse Argumentation.
Aber gut, daran soll es nicht scheitern. UDP-Pakete sind im Internet
laut allen mir vorliegenden Trafficstatistiken unter 10%, und zwar
sowohl von der Bandbreite als auch von der Paketanzahl her. Und von den
beobachteten UDP-Paketen sind fast alle DNS, d.h. <500 Bytes und damit
automatisch nicht betroffen von dem Problem, von dem wir hier reden.
Die anderen spielen rein statistisch keine Rolle. Und selbst wenn, gibt
es keine Alternative als sie mit nicht gesetztem DF-Bit zu verschicken.
Und da DF nicht Default ist bei UDP, sieht man auch üblicherweise keine
großen UDP-Pakete mit DF. Warum auch. Der Ansatzpunkt für Handlungen
ergibt sich also nicht.
Man könnte darüber diskutieren, ob jemand große ICMP Pakete mit DF Bit
verschickt, aber das ist mir in der Praxis auch noch nicht begegnet.
Felix
Felix von Leitner
> Fragmentierung hat zwei Vorteile:
> a) es ist nicht von einer konstanten, symmetrischen Route abhaengig
?
PMTUD auch nicht.
> und
> b) die pakete kommen ohne Verzoegerungen und Wiederholungen an.
Nein. Im Gegenteil. Bei Packet Loss gehen automatisch gleich alle
Fragmente des Pakets verloren, d.h. es muß mehr verschickt werden, und
wenn die Außenleitung eh schon fast voll ist, erzeugt das eine widerlich
hohe Latenz.
Und was das mit den Wiederholungen soll ist mir jetzt gerade auch unklar.
> PMTUD hat zwei Vorteile:
> a) Accessrouter auf dem Weg muessen bei laengeren TCP Verbindungen
> nichts fragmentieren
s/Accessrouter/& und VPN+Tunnel-Endpunkte/
> b) Bei diesen laengeren TCP Verbindungen verringern sich die
> Auswirkungen von Paketverlust (z.b. bei Ueberlastung) auf die
> Uebertragungsrate.
Die Übertragungsrate ist die meisten Leuten nicht so wichtig wie die
Latenz. Denn die meisten TCP Verbindungen sind heute HTTP, und da merkt
man Latenzen deutlicher als kleine Bandbreite.
Felix
Lutz Donnerhacke
>> Fragmentierung hat zwei Vorteile:
>> a) es ist nicht von einer konstanten, symmetrischen Route abhaengig
>
> ?
> PMTUD auch nicht.
Dann hast Du eine andere Definition von PMTUD als der Rest der Welt.
Nimm einfach zwei Leitungswege mit unterschiedlicher MTU, die abwechselnd
mal zum Zuge kommen.
Felix von Leitner
> >> a) es ist nicht von einer konstanten, symmetrischen Route abhaengig
> > ?
> > PMTUD auch nicht.
> Dann hast Du eine andere Definition von PMTUD als der Rest der Welt.
> Nimm einfach zwei Leitungswege mit unterschiedlicher MTU, die abwechselnd
> mal zum Zuge kommen.
Ja und? Gar kein Problem. Auf der Route mit der kleineren Path MTU
gibt es dann halt ein "Fragmentation Needed" und der Sender senkt die
MSS. Das schadet der anderen Route mit der größeren MTU nicht.
Felix
Juergen P. Meier
>> Fragmentierung hat zwei Vorteile:
>> a) es ist nicht von einer konstanten, symmetrischen Route abhaengig
>
> ?
> PMTUD auch nicht.
Was nuetzt es dir, wenn Endpunkt A zu Endpunkt B den Router C als
Geraet mit kleinster Wege-MTU von 1482 identifiziert hat und dies per
MSS dem Endpunkt B mitteilt, wenn dessen Pakete ueber Router D gehen,
der eine MTU von 256 hat?
Genau: garnichts. Endpunkt B muss selbst PMTUD betreiben und den
Entpunkt A davon ueberzeugen, das seine PMTU unbrauchbar ist, oder das
PMTUD RfC ignorieren und in seinen Paketen garnicht erst ein DF Bit setzen.
>> und
>> b) die pakete kommen ohne Verzoegerungen und Wiederholungen an.
>
> Nein. Im Gegenteil. Bei Packet Loss gehen automatisch gleich alle
> Fragmente des Pakets verloren, d.h. es muß mehr verschickt werden, und
> wenn die Außenleitung eh schon fast voll ist, erzeugt das eine widerlich
> hohe Latenz.
Was ist wenn dein ICMP Paket verloren geht? Genau: Timeout und Restart
von PMTUD.
Wenn du sowieso schon merklich Paketloss hast (>>1%) ist das auch ohne
Fragmentierung nicht meher brauchbar. Die Grenze des merkbaren
verschiebt sich bei MSS-Anpassung durch PMTUD halt um ein paar
Prozentpunkte.
Gegen Congestion auf dem Transportweg gibt es jedoch wesentlich
bessere Verfahren als das vermeiden von Fragmenten durch mehr kleinere
Pakete (was letzlich auch den Overhead vergroessert). ECN ist eines
davon.
> Und was das mit den Wiederholungen soll ist mir jetzt gerade auch unklar.
PMTUD: Sender muss das zu grosse Paket erneut senden.
>> PMTUD hat zwei Vorteile:
>> a) Accessrouter auf dem Weg muessen bei laengeren TCP Verbindungen
>> nichts fragmentieren
>
> s/Accessrouter/& und VPN+Tunnel-Endpunkte/
Ich hab Accessrouter hier als Platzhalter fuer jeden Router mit
unterschiedlichen Layer-1 links verwendet.
>> b) Bei diesen laengeren TCP Verbindungen verringern sich die
>> Auswirkungen von Paketverlust (z.b. bei Ueberlastung) auf die
>> Uebertragungsrate.
>
> Die Übertragungsrate ist die meisten Leuten nicht so wichtig wie die
> Latenz. Denn die meisten TCP Verbindungen sind heute HTTP, und da merkt
> man Latenzen deutlicher als kleine Bandbreite.
Gerade bei HTTP wuerde ich das heutzutage (bei dem ganzen Muelltimedia
Content) genau andersherum sehen. Nicht umsonst ist Webbrowsen neben
Mailabrufen eine der Hauptanwendungen von notorisch lahmen Protokollen
wie GPRS (vergleichsweise hohe Bandbreite bei idiotisch hoher Latenz.)
Und die Latenz sieht bei PMTUD nicht viel anders aus als wie ohne.
(Rein auf Paketlaufzeit betrachtet ist sie wegen der kleineren Pakete
besser. Bei Betrachtung der Latenz auf Datenmenge hin ist sie
schlechter.) Und bei TCP ist die initial hoehere Latenz beim
Verbindungsaufbau durch PMTUD meist eh nicht relevant, also hier nicht
wirklich als Nachteil anfuehrbar.
Und ausserhalb von TCP hast du sowieso Fragmentierung. Also ist die
Begruendung fuer generelles PMTUD aufgrund der Forderung nach
Entlastung der {Accesa|VPN|Tunnel|Framerelay|ATM|...}-Router sehr an
den Haaren herbeigezogen.
Lutz Donnerhacke
> nichts konstruiert.
Entschuldige, daß ich die ernsthaften PMTUD Studien auch Dir zurechne.
>> Wenn Du aber PMTUD predigst, dann sorge bitte für ein Netz ohne
>> Firewallblindfische, die ICMP Unreachable - Fragmentation needed filtern.
>
> Im Gegenteil, ich predige MSS Clamping. Konzeptionell sollte es wegen
> PMTUD überflüssig sein, ist es aber nicht.
Jetzt machst Du mich aber neugierig. Wie schafft MSS Clamping es, für den
kompletten Pfad (der nicht konstant bleibt) die richtige MTU zu ermitteln.
Ja, ich weiß, daß Du alle Router TCP SYN mitlesen lassen willst.
Was ist mit dem Rest der IP-Protokolle?
> Aber auch wenn es überflüssig wäre, würde MSS Clamping einen
> Performancegewinn bringen und wäre damit predigenswert.
Der Performancegewinn wird duch deutlich komplexere Paketforwarder erzeugt.
Ich wage gar nicht daran zu denken, was man mit einem geschickt zwischen IP
und TCP Teil fragmentierten Paket alles anstellen kann. Oder mit IP Options.
>> Solange es diese Filter gibt, ist PMTUD nicht einsetzbar.
>
> Da sind wir uns einig.
Gut. Also sagt die Praxis: Kein PMTUD.
>> Der Rückgang in die gute alte Zeit ohne DF Bits ist dagegen immer möglich.
>
> Ja, nur ist das halt ineffizient.
Es ist wenigstens effektiv, sprich: Es funktioniert. Was man von den MSS
Hacks nicht sagen kann.
>>> Ja. Daher ist das Senken der MTU am Endgerät schlecht, das Senken
>>> der MSS aber nicht.
>>
>> Was hat nur die MSS mit der abgehenden Paketgröße zu tun? Was machst Du,
>> wenn die gegenüberliegende Kiste IP Options dranklemmt?
>
> Dann hast du verloren. Genau wie bei dem einzigen Gegenvorschlag, dem
> Senken der MTU.
Mein Gegenvorschlag war jedoch, auf das sinnfreie Setzen von DF Bits zu
verzichten. Und siehe da, es funktioniert, wie Postel es wollte.
>> Das sind völlig verschiedene Layer die nur mittelbar einen Effekt
>> aufeinander haben!
>
> Ich will dich ja nicht mit Fakten bei deinem Rant stören, aber auf
> Client-Seite kann man das Problem nicht lösen, außer man schaltet PMTUD
> ab.
Das ist meine Argumentation. Wenn die Welt schlecht ist, dann muß man nicht
noch mehr Hacks machen, sondern aufhören zu hacken.
> Das ist aber nicht nur eine schlechte Idee, es geht z.B. bei IPv6 gar
> nicht.
Richtig, aber davon rede ich nicht.
>> Ich ziehe es vor, an den Ursachen, statt an den Symptomen zu doktoren.
>
> Gute Idee. Du besuchst jetzt also alle inkompetenten Firewall-Betreiber
> mit einer Cruise Missile?
Eine wird nicht reichen. Ich schreibe lieber eine FAQ. Die jetzige Antwort
paßt Dir nicht und ich bitte Dich, eine besser Fassung zu geben.
>> > Fragmentieren ist auch ein Eingriff in den Datenstrom. Das Senken der
>> > MSS ist eine Sache, die der Router einmal pro SYN Paket machen muß.
>> Dazu muß er TCP verstehen.
>
> Das muß NAT auch. Und trotzdem setzen es fast alle ein.
NAT ist aber eine punktuelle Sache.
>> Und damit ist das Problem für UDP und IPinIP und GRE und ESP und ...
>
> Es gibt bei UDP kein Problem.
> Niemand ist so dämlich, große UDP-Pakete mit gesetztem DF-Bit durch die
> Gegend zu schicken.
Willkommen in der Realität. PMTUD tut auch das: Große Pakete mit gesetztem
DF-Flag. Man kennt ja die Path MTU, nicht? Oder wie bekommst Du ein größeres
UDP Paket über die Leitung, wenn Du die MTU schon kennst?
> Bei ESP macht natürlich der Tunnel Endpunkt MSS Clamping.
Bullshit. Und Du weißt das.
>> nicht gelöst. Was soll der Unsinn also?
>
> NAT funktioniert auch nicht mit ESP. Trotzdem setzen es fast alle ein.
NAT ist eine singuläre Baustelle. Und NAT macht mit Tunneln aller Art
Probleme, wie Du weißt. Wir reden von Netzinfrastruktur und der dümmlichen
Mißachtung der Grundfunktionen (Fragmentierung) aufgrund von
zusammengesponnenen Performanceüberlegungen gefolgt von gescheiterten
Versuchen und noch häßlicheren Hacks für einen kleinen Teil der Protokolle.
> Im realen Leben ist es nicht wichtig, ob es seltene Sonderfälle gibt,
> bei denen ein Ansatz nicht hilft. Es ist wichtig, daß die Lösung die
> ganzen typischen Fälle löst. Du bist doch gerade derjenige, der immer
> "den Informatikern" vorgeworfen hat, was du gerade selber betreibst.
Ich leide - wie Du weißt - an NIH. Insofern trifft mich der Vorwurf nicht.
Ich sage nur, wie die Sachlage ist und daß man mit den dümmlichen Hacks
aufhören soll.
>> > Fragmentieren muß er pro Paket machen.
>> Ja, aber dafür braucht er keine Ahnung von Schicht vier zu haben.
>
> Ja und? Interessiert doch kein Schwein. Wir leben in einer Zeit, wo
> Layer 5 Switches verkauft werden.
Und die sind alle mit Fragmentierung überfordert? Fefe! *Kopfschüttel*
>> Und damit sind die Punkte, in die er eingreift, statisch ermittelbar.
>
> Was soll denn bitte "statisch ermittelbar" heißen?
Die Offsets, an denen man was schreiben und lesen muß sind vorab bekannt.
>> Kein Parsing, keine Fehlerbehandlung, es tut einfach.
>
> Natürlich parst man. Zumindest die Paketlänge muß man aus dem Header
> rausparsen.
Das ist eine feste Stelle und ein fester Zugriff. IP Options wollen
übersprungen und TCP Options geparst werden, um MSS Clamping zu machen.
Das ist ein erheblicher Unterschied im Aufwand. Fragmentierung eignet sich
blendet für Hardware. MSS Clamping ist Software. Ich habe gewählt.
>> Ich empfehle den Firmen PMTUD abzuschalten. Mit durchschlagendem Erfolg.
>
> Klar, für die Firma tut es. Für das Internet ist es schlecht.
Ja. Nein, Fragmentierung ist Hardware.
> Daß der Zusammenhang ursächlich ist, ist für die ungebildete Firma
> erstmal eine reine Glaubens- oder Vertrauensfrage.
Warum landen sie dann bei mir?
>> Nein. Das gilt nur für Surf-Only-Daddel-Netz.
> Du bist offensichtlich stark verwirrt.
Nein. Ich sehe deutlich klarer als Du.
Lutz Donnerhacke
> es keine Alternative als sie mit nicht gesetztem DF-Bit zu verschicken.
> Und da DF nicht Default ist bei UDP, sieht man auch üblicherweise keine
> großen UDP-Pakete mit DF. Warum auch. Der Ansatzpunkt für Handlungen
> ergibt sich also nicht.
PMTUD funktioniert mit UDP genauso wie mit allen anderen IP Protokollen.
Warum sollte man es nicht machen?
> Man könnte darüber diskutieren, ob jemand große ICMP Pakete mit DF Bit
> verschickt, aber das ist mir in der Praxis auch noch nicht begegnet.
Und mit sind keine Router begegnet, die MSS Clamping machen. Was nun?
Rüstest Du mir den Backbone neu aus?
Lutz Donnerhacke
>> >> Fragmentierung hat zwei Vorteile:
>> >> a) es ist nicht von einer konstanten, symmetrischen Route abhaengig
>> Dann hast Du eine andere Definition von PMTUD als der Rest der Welt.
>> Nimm einfach zwei Leitungswege mit unterschiedlicher MTU, die abwechselnd
>> mal zum Zuge kommen.
>
> Ja und? Gar kein Problem. Auf der Route mit der kleineren Path MTU
> gibt es dann halt ein "Fragmentation Needed" und der Sender senkt die
> MSS. Das schadet der anderen Route mit der größeren MTU nicht.
Soweit die Theorie und jetzt bitte wieder zurück zum praktische Kontext der
Frage in der FAQ.
Stephan Holtwisch
> Im Gegenteil, ich predige MSS Clamping. Konzeptionell sollte es wegen
> PMTUD überflüssig sein, ist es aber nicht. Aber auch wenn es
> überflüssig wäre, würde MSS Clamping einen Performancegewinn bringen und
> wäre damit predigenswert.
Aber weitgehend unbrauchbar für ipsec, weil nicht wenige
ipsec-Implementationen MSS=1500-ESPHEADER-IPHEADER
annehmen. Das "clamping" kannste ja wohl kaum auf verschlüsselte
Pakete anwenden.
> Bei ESP macht natürlich der Tunnel Endpunkt MSS Clamping.
Das mag ja bei einigen so sein, bei den meisten wie gesagt
nicht. Ein DSL-Tunnel sieht ja wohl im Regelfall so aus, daß das
"PPPOE-Interface" clamping reinpfuscht, und alle internen Rechner
und auch ipsec-Interfaces von der oben genannten MSS ausgehen.
Stephan
--
Stephan Holtwisch - in...@immutec.com
immutec GmbH - Mendelstraße 11 - 48149 Münster
Tel: +49(0)251/980-1230 - Fax: +49(0)251/980-1231
www.immutec.com - in...@immutec.com
Stephan Holtwisch
> Ich sage nur, wie die Sachlage ist und daß man mit den dümmlichen Hacks
> aufhören soll.
Ein nützlicher Hack ist auf jeden Fall DF-Bits auf nem Paketfilter
zu clearen ;-)
Lutz Donnerhacke
> Lutz Donnerhacke wrote:
>> Ich sage nur, wie die Sachlage ist und daß man mit den dümmlichen Hacks
>> aufhören soll.
>
> Ein nützlicher Hack ist auf jeden Fall DF-Bits auf nem Paketfilter
> zu clearen ;-)
Das ist nicht lustig. Man schalte einfach PMTUD am Client ab.
Felix von Leitner
> > PMTUD überflüssig sein, ist es aber nicht.
> Jetzt machst Du mich aber neugierig. Wie schafft MSS Clamping es, für den
> kompletten Pfad (der nicht konstant bleibt) die richtige MTU zu ermitteln.
Gar nicht. MSS Clamping beseitigt das Problem genau so wenig im
generischen Fall wie das Senken der MTU. In der Praxis reicht es aber.
> Ja, ich weiß, daß Du alle Router TCP SYN mitlesen lassen willst.
Nein.
> Was ist mit dem Rest der IP-Protokolle?
Die kommen nicht in nennenswerter Größe vor und/oder setzen DF nicht.
> > Aber auch wenn es überflüssig wäre, würde MSS Clamping einen
> > Performancegewinn bringen und wäre damit predigenswert.
> Der Performancegewinn wird duch deutlich komplexere Paketforwarder erzeugt.
Sag mal, warst du nicht derjenige, der Cisco einsetzt? Die mit der
dreistilligen Anzahl Protokolle im Stack, die Hälfte davon nicht oder
unzureichend dokumentiert? Und du erzählst mir hier was von
Komplexität? Verzeih, wenn ich das nicht ernst nehmen kann.
> >> Solange es diese Filter gibt, ist PMTUD nicht einsetzbar.
> > Da sind wir uns einig.
> Gut. Also sagt die Praxis: Kein PMTUD.
Nein. Die Praxis sagt, daß außer durch meinen Dialup-Equipment nie
MTU senkende Tunnel auftauchen, weil der ISP sonst seine Kunden
verlieren würde.
> >> Der Rückgang in die gute alte Zeit ohne DF Bits ist dagegen immer möglich.
> > Ja, nur ist das halt ineffizient.
> Es ist wenigstens effektiv, sprich: Es funktioniert. Was man von den MSS
> Hacks nicht sagen kann.
Die funktionieren auch prächtig. Die Anzahl der TCP-Pakete, die trotz
MSS Clamping nicht zugestellt werden konnten, waren bei mir bisher: 0.
Und ich clampe seit über zwei Jahren.
> Mein Gegenvorschlag war jedoch, auf das sinnfreie Setzen von DF Bits zu
> verzichten. Und siehe da, es funktioniert, wie Postel es wollte.
Postel wollte sicher nicht, daß du durch unnötige Fragmentierung die
Paketanzahl verdoppelst.
> > Ich will dich ja nicht mit Fakten bei deinem Rant stören, aber auf
> > Client-Seite kann man das Problem nicht lösen, außer man schaltet PMTUD
> > ab.
> Das ist meine Argumentation. Wenn die Welt schlecht ist, dann muß man nicht
> noch mehr Hacks machen, sondern aufhören zu hacken.
Hast du eine Krankenversicherung? Wieso?
Hast du eine Altersversorgung? Wieso?
Deine Dogmen halten in der Praxis nicht. Nur weil mich theoretisch auf
der Straße ein Meteor treffen könnten, werde ich nicht mein Leben im
Atombunker verbringen. Manche Gefahren sind in der Praxis so gering,
daß man ihretwegen keine Nachteile in Kauf nehmen muß.
> Eine wird nicht reichen. Ich schreibe lieber eine FAQ. Die jetzige Antwort
> paßt Dir nicht und ich bitte Dich, eine besser Fassung zu geben.
Nach dem Congress. Ich muß noch vorbereiten.
> >> Dazu muß er TCP verstehen.
> > Das muß NAT auch. Und trotzdem setzen es fast alle ein.
> NAT ist aber eine punktuelle Sache.
Kaputte Firewalls sind auch eine punktuelle Sache.
> >> Und damit ist das Problem für UDP und IPinIP und GRE und ESP und ...
> > Es gibt bei UDP kein Problem.
> > Niemand ist so dämlich, große UDP-Pakete mit gesetztem DF-Bit durch die
> > Gegend zu schicken.
> Willkommen in der Realität. PMTUD tut auch das: Große Pakete mit gesetztem
> DF-Flag.
Ja, große _TCP_-Pakete. Hast du schon mal jemanden PMTUD für UDP machen
sehen? Ich nicht. Andere Leute offenbar auch nicht, denn das
zuständige RFC (2923) beschränkt sich auch auf TCP. Die Formulierung
ist vorsichtig genug, daß der Mann andere upper layer Protokolle
explizit nicht ausschließt, aber gesehen hat er sie offensichtlich auch
noch nie, zumindest im Zusammenhang mit PMTUD.
> Man kennt ja die Path MTU, nicht? Oder wie bekommst Du ein größeres
> UDP Paket über die Leitung, wenn Du die MTU schon kennst?
Na mit sendto. Der Kernel fragmentiert das dann.
Ich würde immer noch gerne wissen, wie man überhaupt dem Kernel sagen
kann, daß man DF bei UDP gesetzt haben will. Ich meine das ernst, ich
weiß nicht, wie man das anstellen würde.
> > Bei ESP macht natürlich der Tunnel Endpunkt MSS Clamping.
> Bullshit. Und Du weißt das.
Nein, wieso? ESP setzt eh so gut wie niemand produktiv ein. Wer es
tut, kann auch gleich MSS Clamping machen. Ich habe es bei meinem
Tunnel gemacht.
Der Punkt ist doch: MSS Clamping und PMTUD ausschalten schließt sich
nicht aus, auch wenn du das hier gerne so darstellen möchtest. Wenn du
möchtest, kannst du gerne PMTUD ausschalten. Die Nachteile werden durch
das MSS Clamping weitgehend abgefangen.
> >> nicht gelöst. Was soll der Unsinn also?
> > NAT funktioniert auch nicht mit ESP. Trotzdem setzen es fast alle ein.
> NAT ist eine singuläre Baustelle. Und NAT macht mit Tunneln aller Art
> Probleme, wie Du weißt.
Nein, das weiß ich nicht. Tut es das? Ich habe eigentlich immer
streßfrei durch NAT durchtunneln können. Deshalb tunnelt man ja.
> >> > Fragmentieren muß er pro Paket machen.
> >> Ja, aber dafür braucht er keine Ahnung von Schicht vier zu haben.
> > Ja und? Interessiert doch kein Schwein. Wir leben in einer Zeit, wo
> > Layer 5 Switches verkauft werden.
> Und die sind alle mit Fragmentierung überfordert? Fefe! *Kopfschüttel*
Nein, sind sie nicht. Aber TCP Header lesen ist heute
Standardfunktionalität und es wird in Hardware gemacht. Man kann das
kaufen. Kostet eine handvoll Dollar. Deine Argumentation basiert
darauf, daß das in irgendeiner Form Kosten verursachen würde. In der
Realtität tut es das nicht.
> >> Und damit sind die Punkte, in die er eingreift, statisch ermittelbar.
> > Was soll denn bitte "statisch ermittelbar" heißen?
> Die Offsets, an denen man was schreiben und lesen muß sind vorab bekannt.
Die eine Addition bringt niemanden um.
> >> Ich empfehle den Firmen PMTUD abzuschalten. Mit durchschlagendem Erfolg.
> > Klar, für die Firma tut es. Für das Internet ist es schlecht.
> Ja. Nein, Fragmentierung ist Hardware.
Der Nachteil kommt durch die höhere Paketanzahl, nicht durch das
Fragmentieren.
> > Daß der Zusammenhang ursächlich ist, ist für die ungebildete Firma
> > erstmal eine reine Glaubens- oder Vertrauensfrage.
> Warum landen sie dann bei mir?
Offenbar eignest du dich prima als langhaariger Guru ;)
> >> Nein. Das gilt nur für Surf-Only-Daddel-Netz.
> > Du bist offensichtlich stark verwirrt.
> Nein. Ich sehe deutlich klarer als Du.
Das denken leider viele Verwirrte von sich.
Felix von Leitner
> >Bei ESP macht natürlich der Tunnel Endpunkt MSS Clamping.
> Das mag ja bei einigen so sein, bei den meisten wie gesagt
> nicht. Ein DSL-Tunnel sieht ja wohl im Regelfall so aus, daß das
> "PPPOE-Interface" clamping reinpfuscht, und alle internen Rechner
> und auch ipsec-Interfaces von der oben genannten MSS ausgehen.
Ja und? Welche Rolle spielt das schon? Die ESP-Tunnel-Pakete werden ja
nicht mit DF-Bit verschickt. Weil es völlig logisch ist, daß das Streß
machen würde. Ihr prügelt hier gerade auf ein totes Pferd ein, nachdem
euer Strohmann offensichtlich kein gutes Ziel mehr abgibt.
Felix
Felix von Leitner
> Warum sollte man es nicht machen?
Ist das eine Fangfrage?
Du hast die Gründe doch selber genannt!
> > Man könnte darüber diskutieren, ob jemand große ICMP Pakete mit DF Bit
> > verschickt, aber das ist mir in der Praxis auch noch nicht begegnet.
> Und mit sind keine Router begegnet, die MSS Clamping machen. Was nun?
Doch. Du hast mich mal zuhause besucht. Da stand ein solcher Router rum.
> Rüstest Du mir den Backbone neu aus?
Was hat das mit dem Backbone zu tun? Hat dein Backbone MTU-Übergänge?
Felix
Lutz Donnerhacke
> nicht aus, auch wenn du das hier gerne so darstellen möchtest. Wenn du
> möchtest, kannst du gerne PMTUD ausschalten. Die Nachteile werden durch
> das MSS Clamping weitgehend abgefangen.
Ich sehe, wir stimmen überein, wenn ich auch die Akzentuierung auf einen
anderen Punkt lege als Du. Wir widersprechen einander nicht wirklich, also
hier EOD und Du sendest mir eine Neufassung der PMTUD Antwort nach dem
Kongreß.
Stephan Holtwisch
> Ja und? Welche Rolle spielt das schon? Die ESP-Tunnel-Pakete werden
> ja nicht mit DF-Bit verschickt.
Das stimmt so nicht.
Das ist Konfigurationssache (RFC2401), Default ist aber, daß das DF-Bit
von dem Inneren in den Äußeren Header kopiert wird. Das kann also
manchmal mit manchmal ohne sein.
> Weil es völlig logisch ist, daß das Streß
> machen würde.
Na mir ist das auch logisch, aber sag das mal den ganzen Security
Appliance Entwicklern :-)
> Ihr prügelt hier gerade auf ein totes Pferd ein, nachdem
> euer Strohmann offensichtlich kein gutes Ziel mehr abgibt.
Den hab ich nicht kapiert :-)
Das ist hier doch eine sachliche Diskussion oder?