Ein paar Betrachtungen zur neuen Infrastruktur …

Bekanntlich schwankt die Performance im Güterloher Freifunk derzeit, und wie schon mehrfach erwähnt, bauen wir im Hintergrund an der Version 2 des Netzes; schicke Bildchen werden noch gepinselt, aktuell müssen wir mit Text vorlieb nehmen. Und ja, es wird z. T. ziemlich technisch ;)

tl;dr (Zusammenfassung): die neue Infrastruktur steht soweit, nach finalen Tests mit externen Betatestern wird der Umstieg vollzogen.

Um Performancedaten der neuen Infrastruktur zu bekommen, wurde eine Linux-Test-VM hinter eine Gluon-VM gehängt – dies entspricht quasi einem Endgerät und einem Freifunk-Knoten, nur eben virtualisiert –, und diese im gleichen Rechenzentrum zu einem der neuen Gateways verbunden. Der Datenverkehr zwischen Client und Knoten läuft hier intern auf einer Mehrprozessor-Mehrkern-Maschine (2 CPUs zu je 4 Cores), das GW läuft auf einem anderen Host im gleichen Datacenter — allerdings noch über ein 100 MBit/sec-Interface angebunden. Mehr als 100 MBit/sec, entsprechend ca. 12 MByte/sec, sind also z. Zt. nicht drin.
Als zweites Testsystem hängt ein Raspberry Pi per Kabel an einem normalen TP-Link 841; dieser hängt per Mesh-on-WAN an einem Futro S550 – ein Thin-Client mit 1-GHz-AMD-CPU, der, mit Freifunk-Firmware bestückt, rd. 80 MBit/sec mit fastd verschlüsseln kann –, sodaß die 25 MBit/sec der Testleitung ausgelastet werden könnten.
Als Datenquelle für die Tests nehmen wir http://cachefly.cachefly.net/100mb.bin — Cachefly ist ein Anbieter von Caching-Services, somit sollte die Performance relativ nah an normalen Internetdiensten sein.

Ein erster Test vom Raspberry Pi ergab im Schnitt 2.29 MB/s, was dem Ideal von 25 MBit/sec der (mit anderem Traffic geteilten) Testleitung recht nahe kommt, sie wurde zwischenzeitlich jedenfalls voll ausgelastet. Die Pakete liefen in diesem Falle wie folgt:

pi@ffgt-rpi1 ~ traceroute cachefly.cachefly.net
traceroute to cachefly.cachefly.net (205.234.175.175), 30 hops max, 60 byte packets
 1  gw01.ffgt (10.255.0.11)  36.012 ms  36.757 ms  37.600 ms
 2  bgp3-gw01.ospf.ffgt (10.255.145.18)  37.324 ms  38.326 ms  38.334 ms
 3  100.64.1.144 (100.64.1.144)  55.577 ms  55.496 ms  55.836 ms
 4  100.64.1.148 (100.64.1.148)  57.105 ms  57.547 ms  57.273 ms
 5  ber023isp006.versatel.de.bcix.de (193.178.185.15)  61.490 ms  61.840 ms  62.698 ms
 6  10g-8-4.hhb003isp005.versatel.de (62.214.110.41)  62.862 ms 10g-7-4.hhb003isp005.versatel.de (62.214.110.181)  58.969 ms 62.214.106.45 (62.214.106.45)  166.812 ms
 7  10g-9-1.hhb002isp005.versatel.de (62.214.110.105)  58.897 ms  58.619 ms 62.214.106.41 (62.214.106.41)  59.824 ms
 8  vip1.G-anycast1.cachefly.net (205.234.175.175)  64.091 ms  63.816 ms  65.043 ms

Von der VM im Rechenzentrum gibt es zwei Meßwerte: einmal ein wget von 100 MB vom verwendeten Gateway — dies zeigt die zu erwartende Maximalgeschwindigkeit für Internetverbindungen, denn erst vom Gateway aus geht’s gen Internet. Und der zweite Wert ist dann wieder ein wget von Cachefly, siehe oben — dies gibt einen Richtwert für den zu erwartenden Durchsatz einer Verbindung zum Internet.

Da die VM per fastd direkt mit gw02 verbunden ist, wurde der Durchsatz dorthin ermittelt und er liegt bei ca. 80 MBit/sec für eine Verbindung. Kein überragender Wert, aber immerhin noch immer mehr als Faktor 4 einer 16 MBit/sec-Leitung. Inwiefern das 100-MBit/sec-Interface hier bremst, müssen wir noch verifizieren.

Der Test gegen cachefly ergab leider nur 36 MBit/sec, was etwas überrascht; der Weg selbst zu dem/durch den Freifunk-Rheinland-Backbone sieht an sich gut aus:

ffgt@testvm:~$ traceroute cachefly.cachefly.net
traceroute to cachefly.cachefly.net (205.234.175.175), 30 hops max, 60 byte packets
 1  gw02.ffgt (10.255.0.12)  0.573 ms  0.484 ms  0.529 ms
 2  bgp1-gw02.ospf.ffgt (10.255.145.20)  0.863 ms  0.849 ms  0.867 ms
 3  100.64.0.178 (100.64.0.178)  7.174 ms  7.189 ms  7.208 ms
 4  irb-1050.bb-a.fra3.fra.de.oneandone.net (195.20.242.193)  8.613 ms  8.596 ms  8.586 ms
 5  xe-3-1-0-275.fra20.ip4.tinet.net (213.200.65.205)  17.895 ms  17.868 ms  17.836 ms
 6  vip1.G-anycast1.cachefly.net (205.234.175.175)  8.383 ms  9.131 ms  9.108 ms

Tests von bpg1, wo der Datenverkehr geNATtet und ins Internet geschickt wird, ergaben nur marginale Abweichungen zwischen direkter Verbindung (95 MBit/sec) und der über NAT und FFRL (90 MBit/sec).

Was wir bislang nicht lösen konnten, sind die Irrungen und Wirrungen von batman_adv, dem Protokoll, welches unser Maschennetzwerk erst bildet. Leider wählt es die Gateways für den IPv4-Datenverkehr nicht zwingend optimal aus; im konkreten Fall wurde die Gluon-VM fest an gw04.ffgt gebunden, um auch dieses testen zu können. Leider wählte batman_adv dennoch gw02 als DHCP-Server, sodaß die Test-VM erneut gw02 als IPv4-Gateway bekam:

ffgt@testvm:~$ traceroute cachefly.cachefly.net
traceroute to cachefly.cachefly.net (205.234.175.175), 30 hops max, 60 byte packets
 1  gw02.ffgt (10.255.0.12)  1.303 ms  1.265 ms  1.221 ms
 2  bgp1-gw02.ospf.ffgt (10.255.145.20)  2.362 ms  2.336 ms  2.311 ms
 3  100.64.0.178 (100.64.0.178)  7.865 ms  7.844 ms  7.816 ms
 4  irb-1050.bb-a.fra3.fra.de.oneandone.net (195.20.242.193)  9.693 ms  9.670 ms  9.644 ms
 5  xe-3-1-0-275.fra20.ip4.tinet.net (213.200.65.205)  22.840 ms  22.822 ms  22.795 ms
 6  vip1.G-anycast1.cachefly.net (205.234.175.175)  9.465 ms  9.981 ms  9.932 ms

Der Datenverkehr läuft nun über fastd von der Gluon-VM zum gw04, dort über das batman-Protokoll in einen L2TP-Ethernet-Tunnel zu gw02, wo er dann den Tunnel wieder verläßt. Jedes Antwortpaket muß ebenfalls den Umweg über gw02/gw04 antreten, man erkennt das in der – hier deutlich – gestiegenen Laufzeit zu gw02. Der Anstieg von 0,5 auf 1,2 ms ist auf den ersten Blick nicht viel, aber zeigt auch doch, wieviel Mehrarbeit im Hintergrund geleistet werden muß.
Solange das im gleichen DC geschieht, ist das nur bedingt tragisch, aber es reduziert dennoch den Durchsatz: zu gw02 sind’s nun nur noch 52 MBit/sec, zu Cachefly ergibt sich nur eine marginale Änderung von 32 MBit/sec.

Diese Umwege stehen als bekanntes Problem auf der ToDo-Liste, ob/wie wir das lösen können, ist derzeit nicht absehbar. Immerhin, da in der neuen Infrastruktur nur noch die Verbindungen zu den Knoten über fastd laufen, verbraten wir deutlich weniger wertvolle CPU-Zyklen für diese ›Umwege‹.

As fast as it gets …