VPN über DSL: Citrix, Tastaturverzögerungen

[Wordo 11]

Wenn es dich so sehr interessiert das einzuschraenken, wieso liest du dann nicht die RFCs von Mr. Oiso? Gib any any frei, wenns geht, schraenke ein und teste weiter. Allerdings musst du den Client wahrscheinlich immer wieder neu starten weil er sich die Werte im Cache oder sonst wo speichert.

[mr._oiso 10]

hi glady, hi wordo,

 

immer ruhig mit den wilden Pferden.

@wordo - ja, es ist schon ganz schön krass was die Provider da so alles machen.

QSC kenn ich hier oben im Norden garnicht mal.

Wobei es nicht nur die Provider sind, sondern auf Firmen wie Siemens, welche

durch ihre Service Techniker teilweise abenteuliche WAN/VPN Verbindungen zaubern.

Zumindest steht irgendwo in der Mitte dann doch irgendwo wieder mal eine Firewall

welche in der Regel bis auch echo/echo reply alles filtert.

 

Das bedeutet allgemein, dass es manchmal vorkommt, das MTU Path Discovery teilweise

sowieso nicht von End-to-End durchgeht. (Server-Client)

 

@glady - wordo hat recht, am ATM0 Interface interessiert die MTU so gut wie garnicht.

Das interface welches PPPoE macht ist (der dialer), an diesem sind 1492 richtig.

1500 -8 für den PPPoE Offset.

Auch die operation tcp adjust mss ist richtig, gilt jedoch nur für "tcp", ergo bring der extended echo nur folgende Erkenntnis.

 

Der Router antwortet mit ICMP Source Quench, Fragmentation needed, welches der Host, mit dem Du den echo abgesetzt hast auch erhält. (gut soweit)

Die Antwort ab 1472byte bedeutet nur, dass der Router im allgemeinen für die gewünscht Verbindung hier, bei mehr als 1472byte großen Packeten anfangen will zu fragmentieren.

 

Im Umkehrschluss hieße das, dass wenn du einen Ping durch den Tunnel abgesetzt hast, er hier die den IPSec Offset mit 20byte veranschlagt, um am dialer das Packet mit max 1500byte weiterzuleiten.

 

Die -40 byte, welche Du bereits durch mss-adjust auf 1452 reduziert hast, reichen dafür also vollständig aus.

Dieses gilt jedoch eben ausschließlich für tcp-packete >1452 !

Für genau diese Packete muss der Router also genau wie für den extended Ping nun den ICMP SourceQuench an den Server senden. In diesem teilt er mit "fragmentation needed"

Nun kommt es auf den verwendeten RFC an, ob der Router dem Server auch klar machen kann wie groß das Packet maximal sein darf, um Fragmentation zu vermeiden.

 

Und zusätzlich muss diese Info auch beim Server ankommen und verwendet werden.

Hier behindert dann oft eine Firewall, da diese den ICMP nicht zum Server kommen lässt.

Sollte es in Deinem Fall nicht so sein, bleibt die Frage danach, ob der Server mit dem verwendeten RFC klar kommt.

Der RFC 791 z.B. ist hier etwas schlauer, dieser veranlasst, das der Router den Offset mit bekannt gibt, wonach sich der Server richten sollte, wenn er RFC 791 versteht oder auch erhält.

Der RFC 792 z.B. umgeht diesen Prozess mit dem Hintergrund:

Wenn der Server mit DF-Bit kommt (Path MTU Discovery) schickt der Router Fragmentation needed, dadurch sollte der Server die mss nach unten korregieren, und es erneut versuchen. Dieses Prinzip so lange, bis er den SourceQuench nicht mehr erhält.

Dann fixed er den Wert (nur für diese Session), und setzt das BF-Bit erneut.

Dieses tut er, um auch hinter den Router (also beim Provider oder in Deinem Remote LAN)

weiter via MTU Path Discovery arbeiten zu können.

 

So viel zum Dynamische Prozess.

 

Nun zu dem Probelm:

Was ist beim DF-Bit lsöchen der Unterschied zu diesem Verfahren:

Cisco IOS Security Configuration Guide, Release 12.4 - DF Bit Override Functionality8 with IPSec Tunnels* [Cisco IOS Software Releases 12.4 Mainline] - Cisco Systems

 

Da steht folgender Hinweis:

Performance Impact

Because each packet is reassembled at the process level, a significant performance impact occurs at a high data rate. Two major caveats are as follows:

•The reassemble queue can fill up and force fragments to be dropped.

•The traffic is slower because of the process switching.

 

 

Den Performance Impact hast Du wahrscheinlich so schon :shock:

 

Next post follow

 

Mr. Oiso

[mr._oiso 10]

hi again

 

Vor dem Performance Impact wird immer gewarnt.

Dadurch, dass in der Routerkonfiguration mit einer route policy gearbeitet wird,

welche das DF-Bit löscht (auf 0 setzt), wird aber nicht anderes erreicht, als dass es dem Router nun erlaubt ist zu fragmentieren, wenn er es für nötig hält.

Dadurch, dass eine route policy immer als erstes am Interface (Inbound) greift, nimmt

man also das DF-Bit weg, noch bevor der Router kalkuliert, ob er es auch wirklich fragmentieren muss.

Sollte dieses nun notwendig sein, so gehe ich davon aus (könnte auch falsch sein), das der

Router trotzdem den ICMP (Fragmentation needed sendet), jedoch bei ausbleibendem reply vom Server dann einfach damit anfängt.

Und genau das verursacht nun Prozessor Last am Router.

Jedes Packet welches nun (tcp) zu groß ist, nimmt er auseinander und zerstückelt es so,

bis es passt. Teilweise auch ungünstig !

Beispiel: MTU 1452 seien erlaubt -

Packet kommt mit 1500 -

daraus wird eins mit 1452 -

und eins mit "nur" 68 z.B. (ein paar byte mehr durch neuen IP Header etc.)

 

Das kostet Zeit und Rechenleistung.

Dazu kommt, dass die Netto Datenübertragungsleistung (Bandbreite) sinkt.

 

Zum Übel ist nun genau Citrix, oder auch RDP, oftmals so konzipiert, dass eben Bilddaten

die einzigen wirklichen Daten sind, mit welchen der Client versorgt wird.

Diese Daten (Packete) sind "groß" und machen in Deinem Fall den Stress am Router.

 

Jetzt hast Du gesagt, dass der Router mit nur 4-10% CPU Last daher kommt, was entweder bedeutet, er ist stark genug, oder er fragmentiert ordentlich oder auch garnicht.

Was aber macht der Router auf der anderen Seite, oder irgendein Device dazwischen.

 

Ich würde hier entweder wie Wrodo gesagt hat die mss adjust size drastisch senken um zu schauen ob es funktioniert. Dann eventuell Schritt für Schritt nach oben gehen, um den

Grenzwert zu ermitteln.

Oder den Sniffer zum Einsatz bringen und schauen, ob der Server sich überhaupt auf den

mss adjust einlässt.

 

Wenn alles nix hilft, pack das Übel an der Quelle -> dem Server

und fix die MTU entweder mit nem Treiber der die Einstellung beherscht, oder auch via

reg dword in der Registry.

Was nicht heisst, das Citrix sich auch darauf einlässt.

Nur so kannst Du die Dynamik unterwandern, die in diesem ICMP Prozess steckt.

Auf jeden Fall kannst Du mit Dr.TCP Tool die Einstellungen auch schnell korregieren und sehen ob PMTU eingeschaltet ist oder nicht.

 

Halte uns aber bitte auf dem laufenden, wenn Du erfolg hattest !

 

Danke

 

greez and a nice weekend

 

Mr. Oiso