Von Tunneln und anderen Sonderbarkeiten

Äh. WTF?! Verschiedene Tunnel, kein vernünftiger Durchsatz? :(

Ich habe mal vom 100/40-Anschluß in GT (z. Zt. noch gedrosselt auf 100/20) zum 50/10-Anschluß in Berlin über verschiedene Wege ge-iperf-t; “direkt” geht vom Futro hinter der FB durch das NAT der FB ins Netz bis zur Ziel-FB, die den Port auf den Futro auf der anderen Seite durchläßt. Dann gibt es einen GRE-Tunnel, wieder sind die FBs so konfiguriert, GRE an den jeweils anderen Futro durchzulassen. Außerdem haben beide FBs einen IPSec-Tunnel untereinander, über den ebenfalls iperf möglich ist. Und schließlich haben die Futros jeweils auch eine IP aus dem »Ortsnetz«, was über zwei OpenVPN-Tunnel – je Standort liegt ein Tunnel zwischen RZ und VDSL-Anschluß – erreicht werden kann.

Das Ergebnis:

Technik Durchsatz (MBit/sec) MSS (Byte)
Direkt (kein Tunnel) [1] 18,8 1440
GRE v4 [2] 5,15 1424
FB-IPSec v4 [3] 10,9 1362
OpenVPN via RZ [4] 9,38 1200

Traceroutes siehe unten; was ich überhaupt nicht nachvollziehen kann: warum ist der direkte GRE-Tunnel die langsamste Variante?! OpenVPN leidet, wie wohl der FB-IPSec-Tunnel, an zu schwacher CPU-Performance; wobei so gesehen das Userspace-Protokoll OpenVPN eigentlich einen sehr guten Eindruck macht, nur marginal schlechterer Durchsatz über die uralte Sheeva-Plug-CPU im Vergleich zu aktuellem AVM-Blech … wobei bei nur rd. der Hälfte des möglichen Durchsatzes sich die 7362 natürlich für IPSec an VDSL disqualifiziert.

So. Und wie koppele ich nun die beiden Netze (Layer 3 ist ausreichend) mit »Wirespeed«, d. h. mit mind. 50 MBit/sec in jede Richtung?

Traces:
[1]

root@gw-gt:~# traceroute 93.219.164.213
traceroute to 93.219.164.213 (93.219.164.213), 30 hops max, 60 byte packets
 1  192.168.177.11 (192.168.177.11)  0.251 ms  0.352 ms  0.410 ms
 2  62.155.243.28 (62.155.243.28)  8.225 ms  8.641 ms  8.638 ms
 3  b-ec4-i.B.DE.NET.DTAG.DE (62.154.46.190)  18.871 ms  18.880 ms b-ec4-i.B.DE.NET.DTAG.DE (62.154.47.94)  18.850 ms
 4  217.0.77.61 (217.0.77.61)  18.942 ms  19.264 ms  19.516 ms
 5  p5DDBA4D5.dip0.t-ipconnect.de (93.219.164.213)  34.069 ms !X  34.062 ms !X  34.575 ms !X


[2]

root@gw-gt:~# traceroute 100.127.254.2
traceroute to 100.127.254.2 (100.127.254.2), 30 hops max, 60 byte packets
 1  100.127.254.2 (100.127.254.2)  31.636 ms  32.262 ms  32.467 ms


[3]

root@gw-gt:~# traceroute 192.168.176.9
traceroute to 192.168.176.9 (192.168.176.9), 30 hops max, 60 byte packets
 1  192.168.177.11 (192.168.177.11)  0.307 ms  0.329 ms  0.510 ms
 2  192.168.176.9 (192.168.176.9)  29.899 ms  30.984 ms  31.351 ms
 3  192.168.176.9 (192.168.176.9)  33.436 ms  33.673 ms  34.242 ms


[4]

root@gw-gt:~# traceroute 193.26.120.97
traceroute to 193.26.120.97 (193.26.120.97), 30 hops max, 60 byte packets
 1  nslug-1.uu.org (192.168.5.245)  0.212 ms  0.184 ms  0.199 ms
 2  susan2nslug.uu.org (193.26.120.228)  24.407 ms  24.448 ms  24.520 ms
 3  congstar-b.vpn.uu.org (193.26.120.211)  58.444 ms  58.573 ms  58.702 ms
 4  dhcp-30.berlin.uu.org (193.26.120.97)  58.984 ms  60.562 ms  60.670 ms

One thought on “Von Tunneln und anderen Sonderbarkeiten

  1. Dings, äh; MTU, hast Du Dir angeguckt und auf dem Tunnelträger nachgeschaut, ob auch alle den tunnel tragenden Pakete die MTU des Trägermediums ausfüllen? Gerade bei OpenVPN habe ich schon gesehen, dass bei Ausnutzung der MTU des Tunnels jedes zweite Paket nur knapp über 100 Byte hatte.

Comments are closed.