Openvpn überlastet

[da_phil]

Also erstmal OpenVPN läuft inzwischen einwandfrei als Server auf meinem Windows XP Rechner.

mit der Streamdatenrate bin ich inzwischen auf 512 kb/s runter gegangen. Aber scheinbar ist es immer noch zuviel des Guten oder OpenVPN ist einfach nicht für Live-Videostreams gemacht.

MTU steht auf beiden Sieten auf 1492. Ob fragment 1300 gesetzt ist oder nicht spielt keine Rolle. Nach spätestens 20 Sekunden bleibt der Stream komplett stehen.

Im Client Logfile taucht noch 2-3 mal Replay-window backtrack occurred [5] auf.

Als UDP Stream funktioniert es mit einer Datenrate von 512 kb/s sogar halbwegs. Aber auch 768 kb/s als UDP Stream sind wohl über das OpenVPN Protokoll zu viel

Ohne OpenVPN klappts dagegen mit 768 kb/s und TCP Protokoll einwandfrei, nur dann kann ja jeder auf meinen Stream gucken und nicht nur ich

 

[MaxMuster]

... und noch ein letzter Vorschlag (für heute), falls du noch weiterexperimentierfreudig bist ;-)
Vielleicht auf deinem "Streaming-Server" die Paketgröße (MTU) drosseln auf 1300 oder sogar noch etwas kleiner, dann sollte zumindest Fragmentieren nicht nötig sein...
(Geht z.B. mit http://www.speedguide.net/files/TCPOptimizer.exe, damit kann man bei Bedarf aber auch sein Windows komplett "vergurken" ;-) )

Jörg

 

[da_phil]

werde ich morgne mal Testen, aber denke nicht dass es was bringt

 

[da_phil]

werde ich morgne mal Testen, aber denke nicht dass es was bringt

Warum musst die MTU eigentlich auf 1300 herabgesenkt werden? Wegen dem VPN Protokoll oder?

 

[hermann72pb]

Ich bin mir nicht sicher, ob das hier auch ein reines UDP betrifft. Es hat aber auf jeden Fall mit PPPoE zu tun...
http://openvpn.net/archive/openvpn-users/2005-04/msg00362.html :

While OpenVPN uses a TUN/TAP interface MTU of 1500, it down-negotiates the
TCP MSS to 1450 by default (use the mssfix directive to set a different
value). This tends to magically solve most MTU issues, and should
accomodate an 8 byte overhead added by PPPoe, because 1500 - IP header (20
bytes) - UDP header (8 bytes) - PPoe header (8 bytes) = 1464 which is
still greater than the default mssfix value of 1450.

Es gab auch ein erweitertes ping-Befehl, mit dem du die Fragmentierung testen kannst. Parat habe ich die Option jetzt nicht. Google mal danach. Aber eigentlich sind wir hier schon längst OT! Benutze bitte GOOGLE und lese dich auf openvpn.net etwas ein.

 

[MaxMuster]

Hi,

Warum musst die MTU eigentlich auf 1300 herabgesenkt werden?

Die 1300 als konkreter Wert ist nur so eine Vermutung. Die Nutzung eines Tunnels und der Verschlüsselung führt halt dazu, dass die Nutzbare maximale Paketgröße sinkt. Normalerweise ist es bei einer TCP-Verbindung so, dass diese zu Begin die maximal nutzbare Größe "aushandelt", das Discovery. Durch bestimmte Dinge (z.B. Firewalls, die ICMP Meldungen ausfiltern) könnte das misslingen. Dann müsste der Router die Pakete, die zu groß sind "aufteilen" und die Gegenstelle die Pakete wieder zusammensetzen ("Fragmentierung"). Das ist ziemlich zeit- und auch (Puffer-)Speicherintensiv und würde beim Streaming quasi permanent vorliegen und könnte einfach "zu viel" sein. Der Wert 1300 ist halt "deutlich unter" dem zu erwartenden möglichen Wert...

Es gab auch ein erweitertes ping-Befehl, mit dem du die Fragmentierung testen kannst.

... Ich sage nur ping -f -l <Größe>: Das sagt deinem Ping, es soll Pakete einer bestimmten Größe verschicken und diese dürfen nicht fragmentiert werden. In beiden Richtungen müsstest du dann (das ist die Voraussetzung für das "Aushandeln" der korrekten MTU) bei zu großen Paketen eine Meldung der folgenden Art bekommen:
Meldung von a.b.c.d: Paket müßte fragmentiert werden, DF-Bit ist jedoch gesetzt.

Damit kann man die maximal mögliche Paketgröße bestimmen. Dazu könnte dann aber kommen, dass du evtl. mit den "OpenVPN-MTU-Parametern" eine größere MTU "vorgaukelst" als du hast. Dann würde der Tunnel quasi "heimlich" Fragmentieren, jedoch behaupten "ich kann das auch so!".

Jörg

EDIT 2007-05-22 11:35:

Noch eine weitere Idee: Kann es sein, dass die QoS-Sachen da mit reinspielen? Dass die Box also der Meinung ist, der OpenVPN-Stream zieht einfach zu viel Bandbreite?