[Frage] Fritz VPN LAN LAN Kopplung - Verbindung sehr langsam, ist das normal?

[test2010de]

Hallo,
ich wundere mich etwas über die VPN LAN LAN Kopplung Performance und frage mich, ob das wohl alles normal ist.

Standort Server (Diskstation hinter der Fritzbox):
Internet via Kabel Deutschland mit 100 Mbit down 6 Mbit up mittels Fritzbox 6360 mit Firmware 6.05

Standort Client:
Internet via Vodafone mit 6 Mbit down und 0,5 Mbit up. Hier ist der Vodafone Router und dahinter eine Fritzbox 7390 International (via Lan 1) mit Firmware 6.20 angeschlossen.
Alle Netzwerkgeräte hängen an der 7390. Der Vodafone Router ist nur dazwischen, da Vodafone in Spanien (daher 7390 International) mir keine Zugangsdaten nennen wollte. Könnte Sie auch umflashen zu einer normalen 7390. Wusste nicht das Vodafone sich da querstellt.

Beide Standorte erreichen bei Speedtests auch die angegebenen Geschwindigkeiten.

Wird nun von Standort Server (Diskstation) etwas via FTP an den Client übertragen, dann ergeben sich folgende Geschwindigkeiten:

• 
  Client greift auf Server ohne irgendein VPN zu: ~720 kB/s (6 Mbit)

• 
  Client (Windows PC) mit Shrewsoft VPN greift auf Server (VPN in der 6360 Fritzbox) zu: ~300-320 kB/s (~2,5 Mbit) --> hier dachte ich mir, ok wegen Overhead und die 6360 CPU ist halt nicht schneller bei VPN.

• 
  Client und Server Fritzbox haben ein LAN LAN Kopplung-VPN. Die Geschwindigkeit liegt bei ~170 kB/s (1,5 Mbit)--> WARUM? CPU Auslastung liegt bei beiden Fritzboxen bei ~73% bzw. 75 % im UI.

Wieso ist das LAN LAN Kopplungs VPN so langsam? Mit 300-320 kB/s hätte ich ja nun gerechnet, aber nicht mit 170 kB/s.

Im UI der Fritzboxen sind genau die gleichen Werte im Online Monitor sichtbar. Es liegt auch nicht am 0,5 Upstream von Vodafone - dieser wird nicht annähernd ausgereizt.

Dachte beide Fritzboxen sind gleich schnell und daher wird die Leitung bei VPN nur einmal gedrosselt und nicht gleich zweimal.

Hat hier jemand ähnliche Erfahrungen? Würde es evtl. etwas bringen die 7390 auf eine normale Firmware zu flashen?

Oder hilft es hier nur das VPN der Fritzboxen zu deaktivieren und ggf. auf andere Geräte (VPN über zwei Diskstations oder andere Router) auszuweichen.

Vielen Dank für Infos!

 

[PeterPawn]

Ich tippe mal darauf, daß da relativ lange Paketlaufzeiten den Engpass darstellen.

Erst mal dazu, was da gehen sollte/könnte - so ist es bei mir:

1. Anschluß KDG 100/6 mit 6360 wie bei Dir
2. Anschluß 1&1 VDSL 50 mit 7390
3. LAN-LAN-VPN zwischen diesen beiden Boxen - allerdings angepaßte Algorithmen ohne Kompression, da die bei den übertragenen Daten nur Zeit kostet und keinen Effekt bringt
4. Roundtrip zwischen 40 und 50 ms
4. Regelmäßiges Kopieren von Enigma2-Aufnahmen (TS-Files mit MPEG2-Daten) von einem Linux-Server hinter 1. per NFS auf ein weiteres Enigma2-Gerät bei 2.
5. Durchsatz im Upload von 1. nach 2. schwankt etwas - auch abhängig von der Auslastung im Kabelsegment je nach Tageszeit - zwischen 3,5 MBit/s und 5,3 MBit/s (Anzeige mit iftop)

Meine Theorie, warum es bei Dir so langsam läuft, ist nun, daß das Quittieren der Pakete von der Gegenseite zu lange dauert und/oder das Send-/Receive-Window/-Timeout auf einer oder beiden Seiten zu klein ist, weil der zusätzliche Zeit- und Paketaufwand nicht berücksichtigt wird.

Außerdem kommt da sicherlich noch hinzu, daß das AVM-IPSec-VPN mit UDP-Paketen arbeitet (NAT-T mal angenommen, ist aber bei ESP-Paketen am Ende genauso problematisch) und gerade bei großen Übertragungen müssen die TCP-Pakete in der Größe der MTU (der Sender weiß ja nicht, daß es hinterher über's VPN weiter geht) erst einmal neu segmentiert bzw. ganz simpel fragmentiert werden und - nach der IPSec-Kapselung - noch einmal in UDP-Pakete verpackt werden. Da das VPN nicht die TCP-Pakete komplett "umpacken" und damit wirklich neu segmentieren kann, läuft die Rechnung wohl immer auf 2 UDP-Pakete für ein volles TCP-Paket hinaus, da ja die IPSec-Kapselung auch noch hinzukommt und damit die volle Größe eines TCP-Ethernet-Pakets nicht in ein einziges UDP-Paket passt (da ist die noch einmal kleinere MTU beim DSL mit PPPoE noch nicht berücksichtigt). Solche Automatismen wie PMTU Discovery greifen bei VPN-Verbindungen in der Regel auch nicht, da natürlich das VPN ein gesetztes DF-Flag einfach ignoriert und erst der nächste Router nach dem Auspacken des Payloads auf der Gegenseite wieder darauf reagieren wird.

Erst wenn beide UDP-Pakete auf der Gegenseite angekommen sind und dort wieder zu einem TCP-Paket zusammengesetzt und weitergeleitet wurden, kommt irgendwann mal eine Quittung für dieses eine TCP-Paket zurück. Wenn dann auch noch ein zu kleiner Wert für irgendwelche Receive-Timeouts verwendet wird, der den zusätzlichen Zeitverlust durch das Kapseln/Übertragen/Auspacken nicht berücksichtigt, dann führt der zusätzliche Zeitbedarf durch das VPN u.U. auch zu unnötigen Retransmissions (die den Durchsatz dann weiter beeinträchtigen), denn die Daten sind schon richtig angekommen, die Quittungen trafen bloß nicht rechtzeitig ein.

Geht dann irgendeines dieser UDP-Pakete auch noch mit schöner Regelmäßigkeit unterwegs verloren (UDP-Traffic darf ja per Definition "verworfen" werden, wenn es klemmt und Verluste von 2-3% sind über weite Strecken bei mehrfachem Peering keine Seltenheit), muß für ein solches verlorenes UDP-Paket i.d.R. auch noch mehr als ein Paket wiederholt werden, da das Fehlen des Pakets ja erst wieder auf der TCP-Ebene bemerkt wird.

Die ganzen ausgeklügelten TCP-Mechanismen zur Regelung des Traffics (congestion avoidance/congestion control) greifen bei IPSec-VPNs eben nicht, da ja auf der anfälligen Internet-Strecke eben kein TCP-Verkehr übertragen wird, sondern UDP. Dein FTP-Test hingegen basiert auf reinem TCP, da greifen dann auch die Mechanismen wieder, die selbst bei Latenzen von einer Sekunde noch brauchbare Ergebnisse liefern. Damit landen solche TCP-Verbindungen im UDP-Gewand dann ganz schnell auf einen Übertragungsniveau, wo quasi nach jedem einzelnen Paket erst einmal auf die Quittung der Gegenseite gewartet wird und das verursacht dann astronomische Wartezeiten.

Diese vermutlich recht hohen Latenzen (überwiegend darauf stützt sich die Theorie und sie ist Makulatur, wenn Du von einem Client hinter der 7390 auf die DiskStation eine ACK-Latenz von <= 50 ms haben solltest - für TCP-Pakete mit voller Ethernet-Länge und dauerhaft, ein Standard-Ping ist da nur ein ungenauer Indikator, schon wegen der geringen Paketgröße, die nicht einmal ansatzweise an die MTU heranreicht) sorgen dann auch dafür, daß da trotz nicht ausgelasteter CPU und nicht ausgelasteter Leitung ziemlich lange Wartezeiten entstehen, die einen ordentlichen Durchsatz verhindern.

Soviel zu meiner Theorie ... ob sie stimmen könnte, muß man halt testen. Wenn schon das Clampen der MSS einer TCP-Verbindung auf einen kleineren Wert (MTU - IPSec-Header - UDP-Header für NAT-T usw. - oder auch platt auf 1200 meinetwegen) einen besseren Durchsatz dadurch erzielt, daß dann eben ein gesendetes TCP-Paket auch nach IPSec-Kapselung und UDP-Adressierung noch in ein einziges UDP-Paket für die Gegenstelle paßt (ggf. die PPPoE-Kapselung auch noch beachten, wenn das DSL von Vodafone nicht mit DHCP arbeitet), dann könnte an meiner Theorie ja etwas dran sein und einige Einstellungen auf der DiskStation könnten dann den Durchsatz auch durch das VPN steigern.

Ob eine Anpassung anderer TCP-Parameter (RWIN u.ä.) überhaupt hilft bei Verwendung des AVM-VPN, weiß ich gar nicht ... aber durch die zusätzliche Kapselung verzögert sich das natürlich auch, denn imho wird nicht das AVM-IPSec selbst noch einmal eine Sicherungsschicht zur Verhinderung von Paketverlusten über die TCP-Verbindung des Clients legen.
Bei den geringen Latenzen und nur einem einzigen Peering (da klemmt es i.d.R. ja am ehesten, wenn da Netze mit unterschiedlichen Durchsatzmöglichkeiten aufeinander treffen) zwischen meinen Boxen (1. und 2.), mußte ich dann doch keine besonderen Vorkehrungen treffen.

 

[test2010de]

Hallo PeterPawn,
vielen Dank für die ausführliche Beschreibung!

Ich frage mich aber wie Du das hier gemacht hast:

3. LAN-LAN-VPN zwischen diesen beiden Boxen - allerdings angepaßte Algorithmen ohne Kompression, da die bei den übertragenen Daten nur Zeit kostet und keinen Effekt bringt

Über Standard mittel oder mit Fretz und co.?

Vielen Dank für die Info!

 

[PeterPawn]

Ich frage mich aber wie Du das hier gemacht hast:
[...]
Über Standard mittel oder mit Fretz und co.?

Weder noch oder halbe-halbe ... je nach Standpunkt.

Ich habe mir eigene Einträge in der /etc/default.Fritz_Box_HW185/avm/ipsec.cfg zusammengestellt, dort lassen sich die IPsec-Proposals konfigurieren, der Name eines solchen Sets wird bei der VPN-Verbindung in 'phaseXss' angegeben. Für no-comp ist nur phase2 relevant. Allerdings liegt diese Datei normalerweise im SquashFS und ist read-only.

Da es bei AVM kein Set ohne Kompression gibt, muß man es auf einer zugänglichen Box selbst eintragen. Da das am Ende ausgewählte Verfahren ja der gemeinsame Nenner mit der größten Sicherheit ist (oder sein sollte), reicht es auch aus, wenn man auf einer Seite der Verbindung das passende Proposal als einzige Möglichkeit einstellt und dafür sorgt, daß dieses auf der Gegenseite auch erlaubt ist.

Eine read-only-Datei kann man entweder beim Erstellen des SquashFS-Images schon ändern (da wäre dann Freetz eine Hilfe, man braucht aber kein Freetz-Mod in das Image aufzunehmen, nur auspacken/ändern/neu packen) oder man macht es dynamisch mittels bind-Mount zur Laufzeit. Ich hatte schon beide Methoden im Einsatz, welche man wählt, hängt u.a. davon ab, ob man eine originale Firmware verwenden will/muß oder nicht.

Wenn man ohnehin den Weg über das Modifizieren des SquashFS-Images wählt, kann man (zumindest für die Testphase, bis es dann läuft) auch einen Symlink nach /var/media/ftp oder nach /var/flash anstelle der o.a. Datei ins SquashFS setzen (das Prüfen auf das Vorhandensein des "Standard-Inhalts" und dessen Restaurierung im Fall der Fälle kann man in einem Init-Skript wie S01-head mit unterbringen), dann kann man zur Laufzeit jederzeit wieder ändern und sich eine fertige Konfiguration basteln.

 

[andilao]

Bei mir (7490+KD100, 7390+1&1-VDSL50) habe ich keinerlei Zuwachs durch die Abschaltung der Kompression (beim Shrew Client) feststellen können: http://www.ip-phone-forum.de/showthread.php?t=272954&p=2034664&viewfull=1#post2034664

Allerdings scheint die 7390 (1&1 VDSL) den Upload nicht ganz ausnutzen zu können, da vorher schon die CPU-Auslastung auf 99% steigt.

 

[PeterPawn]

Bei mir (7490+KD100, 7390+1&1-VDSL50) habe ich keinerlei Zuwachs durch die Abschaltung der Kompression (beim Shrew Client) feststellen können

Du schreibst gleichzeitig, daß bei Dir der Shrewsoft-Client nie komprimiert ... egal, was man einstellt.

Das verstehe ich allerdings so, daß der Shrewsoft-Client beim Deflate immer einfach "store" macht, denn die zusätzliche Transformation des Paketes muß ja trotzdem stattfinden, sonst versteht die Gegenseite das ja nicht mehr.

Ich wollte auch nicht unbedingt zum Ausdruck bringen, daß das Abschalten der Komprimierung beim AVM-IPSec irgendwelche Verbesserungen im Peak-Durchsatz bringen muß (oder auch nur kann), ich wollte nur die exakten Rahmenbedingungen beschreiben.

Trotzdem dürfte - kommt eben immer darauf an, wo und was man mißt bzw. was man überträgt - die Übertragung einer einzelnen Textdatei (bei identischem Peak-Durchsatz im Upload) eben eher beendet sein, wenn man Kompression eingeschaltet hat (und diese funktioniert). Bei einer Datei mit bereits komprimierten Daten müßte in aller Regel die Übertragung mit Kompression schon deshalb länger dauern, weil durch die zusätzliche Transformation Daten hinzugefügt werden (ein Deflate oder auch ein LZJH wird i.d.R. schlechter komprimieren, als ein MPEG-Encoding und keine zusätzliche Reduktion der Daten erzielen - vielleicht noch bei unkomprimierten Audiodaten, wenn solche Formate im Stream sind) und auf beiden Seiten zusätzliche Schritte notwendig werden.

Rein von der zu übertragenden Datenmenge ist natürlich auch eine externe Kompression immer besser, denn bei der IPSec-Kompression wird ja nur der Payload des IP-Paketes komprimiert (also das resultierende Paket kleiner und deshalb braucht es "auf der Leitung" weniger Zeit zur Übertragung), der Overhead durch die Header bleibt ja konstant und auch die Anzahl der Pakete verringert sich nicht. Deshalb wird auch das Komprimieren von 100-Byte-Paketen bei identischer Rate von 20% verbleibender Größe deutlich weniger bringen, als bei 1500-Byte-Paketen, wo dann nicht 80, sondern 1200 Byte eingespart werden können (mal 1500 genommen wegen des leichteren Rechnens, da sind natürlich bei Ethernet auch schon Header drin, die nicht zum Payload gehören).

Selbst wenn es bei der nochmaligen Kompression von MPG-Daten nur minimal länger benötigen sollte (es ist immer noch mehr zu übertragen, wenn der Payload sich nicht komprimieren läßt), weil der limitierende Faktor am Ende nur die Upload-Bandbreite ist, verschwendet es einfach nur Energie auf beiden Seiten und bringt damit imho null Punkte, deshalb verwende ich es bei dieser VPN-Verbindung eben prinzipiell nicht. Das bißchen Text, was da in den Begleitdateien zu einem TS-File noch auftaucht, ist zu vernachlässigen.

Die 6360 ist bei einer solchen Übertragung seitens der CPU auch keineswegs ausgelastet ... ganz im Gegenteil:

Mem: 109088K used, 16660K free, 0K shrd, 10584K buff, 34688K cached
CPU:  1.5% usr  4.1% sys  0.0% nic [COLOR="#FF0000"]34.9% idle[/COLOR]  0.0% io  0.0% irq 59.3% sirq
Load average: 1.25 0.84 0.60 3/122 22994
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1693     2 root     RWN      0  0.0   0  7.4 [cni_rx_wq/0]
10442     1 root     S     3352  2.6   0  1.9 multid
22986 22936 root     R     1216  0.9   0  0.7 top
10629     1 root     S N  11220  8.9   0  0.5 /sbin/mount.davfs -o conf=/var/tmp/davfs2.conf -o dir_mode=777 -o file_mode=777 https://sd2dav.1und1.de /var/media/ftp/Online-
 1724     1 root     S    38368 30.4   0  0.3 ctlmgr
 1268     1 root     S     1748  1.3   0  0.3 /usr/sbin/pcd -f /etc/scripts/vsdk.pcd -p -t 20 -e /nvram/pcd_error_log.txt
 2103     1 root     S     1208  0.9   0  0.3 telnetd -l /sbin/ar7login
 1793  1268 root     S    20292 16.1   0  0.2 /usr/sbin/downstream_manager 4 8
 1980     1 root     S    13140 10.4   0  0.2 telefon a127.0.0.1
 1685     1 root     S     2532  2.0   0  0.2 l2tpv3d
 2049     1 root     S    60780 48.2   0  0.0 /usr/bin/aha
 1889     1 root     S    28068 22.2   0  0.0 pbd
[...]

Da kann man schön sehen, daß das System die meiste Zeit mit dem Bedienen von Interrupts verbringt, da wird aber imho auch das Ver-/Entschlüsseln (mit oder ohne Kompression) gecountet, wenn es im Rahmen des Interrupt-Handlings erfolgt. Ansonsten ist der hohe Prozentsatz für die Behandlung von Interrupts nicht zu erklären (tritt ja bei "Vollast" der 7490 im WLAN auch auf).

Ob das auch noch für den doppelten Durchsatz im Upload reichen würde (also 12 MBit/s nominell, die man ja auch nicht erreicht), wage ich nicht einzuschätzen.

Bei einer 6360 ist der gesamte System-Load vermutlich auch etwas höher, da bei DSL-Boxen das Channel-Handling zum größten Teil im FrontEnd-Prozessor laufen dürfte, beim Puma5 ist das - imho und nur anhand dessen, was man da sehen kann - überwiegend auf dem Main-Prozessor (Splitting/Bonding für die Channels - es gibt für jeden einen "Manager"-Prozess, AES-Encryption (noch mal eine ) zur CMTS, usw.).

Die VPN-Verbindung nutzt (hoffentlich, beim AVM-VPN kann man das leider nicht mal in der ike.log sehen, auch nicht mit "cat /proc/kdsld/dsliface/internet/ipsec/assocs") folgendes Proposal (getestet gegen eine racoon-Installation):

cfg_security_strategien {
      ike_strategien {
[...]
      }

      ipsec_strategien {
[...]
              name = "movie-transfer";
              comment = "Filmuebertragung";
              pfs = yes;
              life_dur_sec = 1h;
              life_dur_kb = 0;
              proposals {
                      comp = comp_none;
                      ah = ah_none;
                      esp {
                              typ = esp_aes;
                              enc_key_length = 0;
                              hash = sha;
                      }
              }
[...]
}

Da die Filme keinesfalls "geheim" sind, reicht mir da AES128 locker, die geringere Anzahl von Runden entlastet auch den Prozessor (ob der das nun braucht oder nicht, vieles von den Übertragungen läuft absolut unauffällig im Hintergrund). Die 6360 ist bei aktiver Übertragung zwar im GUI etwas träge (und die Traffic-Grafik in der Internet-Übersicht klappt auch nicht mehr), aber der Routing-Durchsatz (paralleler Download) ist ziemlich unbeeindruckt. Ob da auch eine "Packet Acceleration" in Hardware läuft, weiß ich nicht ... meines Wissens gibt es keine "offiziellen" Angaben zu den Funktionen des Puma5 (also, ob der auch einen internen Switch mit eigenem Processing hat, wie die Lantiq-Chips).

Am Ende ergibt das dann - auf einem Server hinter der 6360, der auch der nfs-Client für das entfernte Enigma2-Gerät ist - mit iftop:

TX:             cum:   1.00GB   peak:   4.52Mb
RX:                    25.7MB            103Kb
TOTAL:                 1.02GB           4.62Mb

Also ist es - keine 3 Minuten altes iftop - heute wieder mal etwas eng im Segment. Das schwankt eben stark ... aber auch 5.38Mb sind drin. Mehr geht wohl nicht von den angeblichen 6.4 MBit/s im Upload lt. Anzeige de FRITZ!Box, jedenfalls nicht bei mir und wer weiß schon, wo das genau sein soll ... vielleicht sind ~15% Overhead bei DOCSIS auch normal, ich weiß es nicht (und den IPSec-Overhead bei der Übertragung müßte man auf die 5.38 ja noch draufrechnen, denn das ist reines NFS).