Max. MTU bei PPTP

[hardliner]

Wenn man nun die MTU (auf einem Windows-System mit Einwahl via PPTP) auf 1400 setzt ist es ratsam auch all andere Interfaces im Netzwerk auf 1400 zu setzen.
Sonst kommt es zu den merkwürdigsten Effekten: z.B gehen dann einige Seiten auf einigen PCs nicht oder nur schlecht.
Die meisten SW-NAT-Firewalls fragmentieren nämlich nicht.
Ich hab hier bei mir z.B. 1400 auf allen PCs eingetragen.
Es gibt zwar in der Registry den Parameter "EnablePMTUDiscovery", der die günstigste MTU aushandeln sollte, nur funzt dies unter gewissen Bedingungen nicht immer einwandfrei.
H.

[superracer]

Ein Ping mit bis zu 1236 Byte Payload geht unfragmentiert (nur 12 Byte GRE-Header).
Von 1237 bis 1372 wird fragmentiert. Der Ping geht aber durch, weil beim äußeren IP-Paket das DF-Bit nicht gesetzt ist.

dann macht windoof eh alles richtig. da gibt's dann auch keinen wirklich guten grund, die MTU künstlich auf 1400 zu limitieren...

Wenn man nun die MTU (auf einem Windows-System mit Einwahl via PPTP) auf 1400 setzt ist es ratsam auch all andere Interfaces im Netzwerk auf 1400 zu setzen.
Sonst kommt es zu den merkwürdigsten Effekten: z.B gehen dann einige Seiten auf einigen PCs nicht oder nur schlecht.
Die meisten SW-NAT-Firewalls fragmentieren nämlich nicht.
Ich hab hier bei mir z.B. 1400 auf allen PCs eingetragen.

tja, windoof halt

[cremor]

dann macht windoof eh alles richtig. da gibt's dann auch keinen wirklich guten grund, die MTU künstlich auf 1400 zu limitieren...

Ja.
Und sogar in Vista ist diese Beschränkung wieder enthalten


edit:

Wenn man nun die MTU (auf einem Windows-System mit Einwahl via PPTP) auf 1400 setzt ist es ratsam auch all andere Interfaces im Netzwerk auf 1400 zu setzen.
Sonst kommt es zu den merkwürdigsten Effekten: z.B gehen dann einige Seiten auf einigen PCs nicht oder nur schlecht.
Die meisten SW-NAT-Firewalls fragmentieren nämlich nicht.
Ich hab hier bei mir z.B. 1400 auf allen PCs eingetragen.
Es gibt zwar in der Registry den Parameter "EnablePMTUDiscovery", der die günstigste MTU aushandeln sollte, nur funzt dies unter gewissen Bedingungen nicht immer einwandfrei.
H.

Moment...
Wenn du bei dem PC, der die Einwahl per PPTP macht die MTU der NIC auf 1400 reduzierst kann das aber nicht gut sein.
Mit NIC MTU von 1500 würden die PPTP Pakete durchkommen (1400 + 36 bzw. 40 Byte Header).
Mit NIC MTU von 1400 wird das allerdings fragmentiert.

mfg cremor

[hardliner]

[Moment...
Wenn du bei dem PC, der die Einwahl per PPTP macht die MTU der NIC auf 1400 reduzierst kann das aber nicht gut sein.
Mit NIC MTU von 1500 würden die PPTP Pakete durchkommen (1400 + 36 bzw. 40 Byte Header).
Mit NIC MTU von 1400 wird das allerdings fragmentiert.

mfg cremor

Der NIC (10.0.0.140) hab ich 1400 explizit zugewiesen. Pakete bis 1372 werden nicht fragmentiert. 1372+28(Header)=1400. Der Rest auf 1500 wird durch die PPTP-encapsulation verbraten.
H.

[cremor]

Der NIC (10.0.0.140) hab ich 1400 explizit zugewiesen. Pakete bis 1372 werden nicht fragmentiert. 1372+28(Header)=1400.

Wie hast du das getestet?
Eines stimmt schon, bei einer NIC MTU von 1400 werden Pings bis 1372 Byte Payload auch mit DF-Flag funktionieren.
In Wirklichkeit (zu sehen mit einem Packetsniffer) werden Pakete ab 1336 Byte Payload aber fragmentiert, weil zu dem ICMP- und IP-Header (28 Byte) auch noch die PPP-, GRE- und (nochmal) IP-Header dazukommen (36 bzw. 40 Byte). Dadurch sind die Pakete 1436 bzw. 1440 Byte groß und werden fragmentiert.
Und dieses Fragmentieren wird durch das innere (beim Ping angegebene) DF-Flag nicht verhindert.

Der Rest auf 1500 wird durch die PPTP-encapsulation verbraten.

Das ist somit falsch. Hat die NIC eine MTU von 1400 verschickt sie keine Pakete mit mehr als 1400 Byte.
Wenn sie den Rest mit PPTP-Headern verbraten soll, muss die MTU auch auf 1500 stehen.

Generell:
Wählt man sich direkt per Windows ein (egal ob PPPoE oder PPTP) sollte man die MTU der NIC auf 1500 lassen. Ansonsten hat man nur zusätzliche Fragmentierung.

Das gilt natürlich nicht, wenn man sich per Router einwählt. Dann kann es erforderlich sein, dass man die MTU der NIC auf die MTU des Routers vermindert um das bekannte MTU-Problem (Seiten werden nicht angezeigt) zu vermeiden.

mfg cremor

[hardliner]

Falsch!??
Ursprünglich hatte ich keinerlei MTU-Einstellungen aktiv.
Pings mit DF-Flag ermittelten mir 1372 mit den bekannten Problemen auf bestimmten Seiten mit exzessiven Cookies (standart.at, krone.at, usw)
H.
An sich ist der Schluß logisch, doch die Preaxis lehr mich anderes.

[superracer]

Falsch!??

jep. wenn der ach-so-tolle windoof nat-router (der den namen router dann eigentlich nicht verdient hat) nicht fragmentieren kann, passiert die fragmentierung durch solche einstellungen einfach an anderer stelle.

paket mit 1400 bytes kommt rein -> wird genattet -> wird übers ppp-interface rausgeschickt(1) -> pptp-header wird draufgepappt -> paket ist somit 14xx bytes groß -> soll übers lan-interface rausgeschickt werden -> dieses hat aber MTU 1400, somit wird das paket (vom OS) fragmentiert.

wenn die MTU am lan-interface 1500 wäre, müßte das paket schon an stelle (1) fragmentiert werden, und zwar von der nat-software (und dafür später dann nicht mehr).

alles in allem ist so eine einstellung aber trotzdem nur ein workaround bzw dirty hack.

[cremor]

Bei Direkteinwahl per Windows wirst du mit dem Pingtest immer auf 1372 kommen (wie schon gesagt).
Damit sollte man allerdings auch keine MTU-Probleme haben

Gehst du wirklich nur mit einem PC ins Internet oder hast du ICS?

mfg cremor

[hardliner]

Bei Direkteinwahl per Windows wirst du mit dem Pingtest immer auf 1372 kommen (wie schon gesagt).
Damit sollte man allerdings auch keine MTU-Probleme haben

Gehst du wirklich nur mit einem PC ins Internet oder hast du ICS?

mfg cremor

Hab einen dedizierten NAT-Firewall-Rechner (WinXP) der die "Einwahl" via PPTP tätigt.!
Funzt zuverlässiger als jeder externe Router. Hab damit auch keine Probs mit den Sessionlimits!
Ohne MTU 1400 funktioniert der UpLoad nicht! Auch bei den Clients!
H.

[superracer]

Funzt zuverlässiger als jeder externe Router. Hab damit auch keine Probs mit den Sessionlimits!

und

Ohne MTU 1400 funktioniert der UpLoad nicht! Auch bei den Clients!

findest nicht, daß sich das irgendwie widerspricht?

[hardliner]

Funzt zuverlässiger als jeder externe Router. Hab damit auch keine Probs mit den Sessionlimits!

und

Ohne MTU 1400 funktioniert der UpLoad nicht! Auch bei den Clients!

findest nicht, daß sich das irgendwie widerspricht?

keineswegs!
Wenn die max. Datengröße nur mit 1372 (wegen PPTP) möglich ist, sehe ich da prinzipiell kein Problem!
Immerhin läuft der Rechner mehrere Wochen hindurch ohne Probleme.
Zuvor stand dort eine LINUX-Gurke die man fast täglich neu booten musste. (Freeze!) .
LINUX - Nein danke!
H.

[superracer]

keineswegs!
Wenn die max. Datengröße nur mit 1372 (wegen PPTP) möglich ist, sehe ich da prinzipiell kein Problem!

und daß das ding nicht fragmentieren kann und somit einen kaputten IP-stack hat und du weiters auf sämtlichen angeschlossenen devices was umstellen mußt, das ist für dich kein "problem"?
vielleicht bin ich da auch einfach anspruchsvoller, aber so ein ramschding würd mir nicht ins haus/netz kommen. (was auch ko-kriterium für die mehrzahl von netgear-routern ist.)

Zuvor stand dort eine LINUX-Gurke die man fast täglich neu booten musste. (Freeze!)

da seh ich mehrere mögliche fehlerquellen... könnte ein layer-8 problem sein, oder PICNIC oder auch PEBKAC, oder vielleicht error 99 (replace user).

ps: typische uptime einer richtig administrierten "linux-gurke":

Code: Alles auswählen

08:32:55 up 405 days,  4:46,  1 user,  load average: 1.08, 1.55, 1.56

[hardliner]

da seh ich mehrere mögliche fehlerquellen... könnte ein layer-8 problem sein, oder PICNIC oder auch PEBKAC, oder vielleicht error 99 (replace user).

Das war eine astreines PPTP-Problem. Irgendwann riss die Verbidung ab und eine neuerliche Einwahl war nicht möglich. Dann waren noch Probleme mit den TrafficShaper.
Bei M$ weiß ich wo ich nachschauen muss, bei LINUX sind die Infos im ganzen Netz verstreut bzw muss man in den diversen NGs rumfragen!
Zudem habe ich einfach nicht die Zeit (und Lust) mich mit diesen LINUX-Problemen auseinanderzusetzen!
H.
Aber das ist hier O.T.

[superracer]

Das war eine astreines PPTP-Problem. Irgendwann riss die Verbidung ab und eine neuerliche Einwahl war nicht möglich. Dann waren noch Probleme mit den TrafficShaper.

und was ist mit dem von dir angesprochenen "freeze"?

im übrigen sind solche probleme nichts, was einen reboot rechtfertigen würde. rebooten ist die übliche lösung von windoof-usern, unter linux (bzw allen anderen vernünftigen OSn) gibt's immer eine möglichkeit, solche probleme anders zu lösen (weil es einfach nix "magisches" im OS gibt, was sich nur durch einen reboot restarten läßt), dazu muß man allerdings wissen, was man tut. einzige ausnahme sind hardware-probleme oder treiber-probleme (welche es in der praxis nur selten gibt, außer bei relativ exotischer hardware).

Bei M$ weiß ich wo ich nachschauen muss, bei LINUX sind die Infos im ganzen Netz verstreut bzw muss man in den diversen NGs rumfragen!

reine gewohnheitssache - ich hätt absolut keinen plan, wo ich nachschauen/fragen müßte, wenn bei einem windoof-system das PPTP mal spinnt. (bzw wett ich was, daß ich außer "reboot the system" keine brauchbare antwort kriegen würd.) dafür krieg ich zu jeder linux-komponente innerhalb sekunden alle infos, die ich brauch (ever heard of google?)

aber wem erzähl ich das eigentlich? ist ja so, als ob man gegen ne mauer redet... also aus jetz.

[hardliner]

und was ist mit dem von dir angesprochenen "freeze"?

Der "Task" wo PPTP läuft, ließ sich nich mehr killen!
H.