Wie Gateway Durchsatz erhöhen?

Technik
1

Moin!

Wir betreiben zur Zeit bei uns 4 Gateways. Eines davon ein 5 Euro KVM Maschine mit 2 vCPU mit angeblich 3,5 GHZ Intel CPU und 1 GB RAM. 3 davon sind virtuelle Root Server M von Netcup. Unser Netz besteht zur Zeit aus ca. 210 Knoten Online, mal mehr mal weniger. Die Außenanbindung erfolgt über OpenVPN Schweden Tunnel. Die Anbieter sind AirVPN, Mullvad und Websecuritas. Zusätzlich läuft auf einem Gateway ein Sixxs Tunnel für Public IPv6 mit AICCU. Während unser Netz noch klein war, so um die 70 Knoten und nur zwei Gateways konnte ein 1043v2 problemlos die 20-25 MBit auf IPv4 schaffen. Seit einiger Zeit schafft ein Knoten bzw. Offloader allerdings nur noch maximal 10 MBit/s auf IPv4, aber auch nur wenn sonst das Gateway nicht viel zu tun hat. In der Mitte schafft man bei Speedtest gerade mal so um die 5 MBit. Auch wenn ich mir spät nachts mal ein Gateway frei Räume und nur meinen 1043v2 Knoten angebunden lasse, bleibt diese magische 10 MBit/s Grenze bestehen. Wenn ich einen wget Speedtest vom Gateway aus durch den Schwedentunnel starte kommen aber gut und gerne 40-50 MBit zu stande. Auch ein Testlauf mit FastD ohne Verschlüsselung brachte nicht mehr als 10 MBit/s zu Tage.

So sieht TOP auf einem der Gateways aus:

top - 19:56:10 up 3 days, 11:42,  1 user,  load average: 0.27, 0.31, 0.38
Tasks:  82 total,   2 running,  80 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.9 us,  5.5 sy,  0.0 ni, 82.0 id,  0.0 wa,  0.0 hi, 11.2 si,  0.4 st
KiB Mem:   6130020 total,  2099436 used,  4030584 free,   154700 buffers
KiB Swap:  1492988 total,        0 used,  1492988 free,  1699348 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           
 2289 nobody    20   0 44572 2856 1932 R  23.3  0.0 587:50.95 fastd             
  129 root      20   0     0    0    0 S   3.3  0.0  58:34.20 kworker/u:1       
21928 root      20   0 31000 3276 2372 S   2.0  0.1  58:15.54 openvpn           
 2341 root      20   0  4728  928  236 S   1.0  0.0  35:11.09 haveged           
 2409 bind      20   0  231m  73m 2204 S   1.0  1.2  22:24.93 named             
 2423 root      20   0  8652 1268  660 S   1.0  0.0  14:53.41 alfred            
 2209 root      20   0  116m 3264 1176 S   0.7  0.1  36:10.94 rsyslogd          
 2189 nobody    20   0 21692 5588 2948 S   0.3  0.1  12:13.16 darkstat          
 2364 ntp       20   0 39072 2424 1764 S   0.3  0.0  12:56.43 ntpd

Für mich sieht das noch nicht nach Überlastung auf. Wir haben FastD auf 50 Knotentunnel pro Gateway begrenzt und jeder Knoten baut auch nur noch einen Tunnel zu einem Gateway auf.

Die Verbindung zwischen den Knoten habe ich vor zwei Wochen von Fastd auf L2TP umgestellt. Dieses hat eine ganze Ecke CPU Entlastung von Seiten des FastD mit sich gebracht. Einen nennenswerten Durchsatzanstieg jedoch nicht.

Jemand ne Idee wo ich die Handbremse lösen muss? Mit den MTUs habe ich auch schon gespielt. Aber es ist egal ob ich 1280 oder unseren normalen Wert von 1390 fahre. Bleibt beides gleich schnell bzw. langsam.

Unsere Traffic Statistik ist hier zu sehen, pro Gateway.

http://uegw1.freifunk-uelzen.de/vnstat/
http://ffuegw2.freifunk-uelzen.de/vnstat/
http://ffuegw3.freifunk-uelzen.de/vnstat/
http://ffuegw4.freifunk-uelzen.de/vnstat/

Eine Anbindung ans Rheinland Backbone ist für uns keine Option, da wir uns 1,50 pro Knoten (noch) nicht leisten können.

1 „Gefällt mir“
2

Diese Erfahrung habe ich auch bereits gemacht. In einem Netz mit hunderten Nodes steigt der Broadcast-Traffic auf Layer 2 zwischen den Nodes immens an; ab mehreren hundert Clients passiert dies auf Layer 3.

Beachte hier, dass es nicht nur ein Problem des Datenvolumens ist, das verschickt werden muss. Die Anzahl der Pakete pro Sekunde steigt an und da ist nicht erheblich, wie groß diese Pakete sind. Durch eine große Anzahl an Paketen werden CPU-Zyklen belegt, Port-Buffer vollgestopft und die nutzbare Air-Time auf den Wifi-Interfaces nimmt ab.

Hast du bei deinem Test den Gateway vollkommen getrennt oder war dieser noch mit den anderen Supernodes verbunden? In dem Fall wird natürlich der Broadcast-Traffic auf beiden Layern durch den Tunnel zu deiner Node geschoben. Da du nur eine CPU hast, macht das dennoch einen Unterschied, denn so hat der Gateway mehr CPU-Zeit exklusiv für deine Node übrig.

Ich schlage vor, du schließt einmal einen Laptop per Ethernet an deine Node an und verwendest iftop, um den Broadcast-Traffic zu betrachten. Wenn du auf deiner Node ‚Mesh on LAN‘ aktivierst, kannst du auch den Layer 2 auf den Schirm bekommen.

Mit iperf kannst du auf deinen Supernodes einen Dienst zur Messung der Bandbreite laufen lassen. Ich vermute, durch den UDP-Modus und verschiedene Einstellungen ist hier die Performance in Paketen pro Sekunde messbar. Das habe ich jedoch selber noch nicht probiert.

Schreibe mal, was deine Ergebnisse sind und vielleicht kann ich das eine oder andere bei uns auch einmal ausprobieren. :slight_smile:

2 „Gefällt mir“
3

Ich kann dazu keine fundierte Aussage machen, habe da aber auch das Grundrauschen im Verdacht. Wobei 200 Knoten jetzt nicht so viel sind.

Bei uns ist der Prozessor eines 841ers im Idle bereits zu 50 % ausgelastet. Das kannst du bei dir sehen, wenn du auf einem Knoten per ssh top ausführst und im Kopf 1-nice rechnest. Der fastd Wert ist unerheblich, weil die Pakete im Kernel verarbeitet werden müssen. Meiner Erfahrung nach, zeigt das das top auf den Knoten nicht richtig an. Wir haben allerdings 900 Knoten.

Mich wundert daher, dass du da bei 200 Knoten schon solche Probleme hast. Stößt der fastd Prozess auf den Gateways eventuell an 100% an oder ist vielleicht der Schweden-Tunnel dicht? Die sollen ja auch nicht sooo viel machen, eventuell kommt es da zu Engpässen.

Ob es am Grundrauschen liegt, kann man übrigens testen, wenn man einen starken x86-Prozessor verwendet, den juckt das nicht. Wenn du mit so einem Offloader mehr Durchsatz bekommst, liegt es am Grundrauschen, sonst gibt es noch mehr Engpässe.

Grüße
MPW

4

Das Gateway war noch mit den anderen Gateways verbunden. Die 3 L2TP Tunnel zu diesen wiesen einen Traffic von 5-8 KiByte/s in und out auf.

Für Speedtests in unserem Netz haben ich auf dem vom der CPU GHz Zahl stärksten Gateway (3,5 GHz) eine Speedtest Seite eingerichtet. http://uegw1.freifunk-uelzen.de/speed/
Sowohl ein Flash basierter Speedtest auch auch mehrere Files bis 1 GB Größe. Der Test ist extern wie intern erreichbar. Intern über die URL http://speedtest.ffue. Ich habe nen 100er Kabeldeutschland Anschluss und kann sowohl via Flashspeedtest als auch die Files vom Gateway mit 100 MBit ziehen. Aus dem Freifunk Netz, mit via LAN Kabel angeschlossenem Notebook am Knoten bleibts aber bei maximal 10 MBit. Es ist auch egal was für Hardware, ob nun 841er, WDR4300, 1043v2 oder mit einem Testweise aufgesetzen Offloader in einer VM auf einem schnellen Vierkern PC. Und abhängig ob ich nun FastD mit Null oder Salsa2012+umac laufen lasse. Allerdings habe ich beobachtet das beim testen über FastD im Freifunk Netz, auch bei NULL, der FastD Prozess einen Kern zu 100% auslastet.

Aber irgendwas muss sich ja nun geändert haben was mich auf diese 10 Mbit bzw. die hohe Auslastung eines Kerns durch FastD v17 begrenzt.

Ich werde nachher mal weitere tests durchführen.

5

Das ist leider normal, fastd verursacht Interrupts auf der CPU, dadurch hilft das abschalten der Verschlüsselung minimal da die Pakete genauso oft durch die CPU gehen.

6

Was ist dann der Ausweg aus der miesere? Fetteste Hardware Mieten die man bekommen kann?

7

Für uns funktioniert das mit der fetten Hardware ziemlich gut. Wir haben auch jeweils nur zwei Kerne, die stehen aber unseren Supernodes exklusiv zur Verfügung.

Wir brennen dadurch mit vier (+1) Supernodes die, wie ich befürchte, inzwischen größte Kollisiondomäne des Vereins ab.

Ich bin daher der Meinung man sollte lieber eigenes Blech mit einer guten CPU mieten statt vieler kleiner VMs.

Durch die geringe Zahl der Supernodes bleibt nach meinen Beobachtung auch der Overhead Traffic geringer.

8

Welches Blech empfiehlt sich denn? Die Netcup VM haben 2,6 GHz wobei hier ja „echte“ Kerne durchgereicht werden angeblich. Die andere VM hat laut Hoster eine 3,5 GHz Xeon CPU unbekannter Modellreihe. Das viel GHz hilft war mir schon von Anfang an klar. Leider sprudeln bei uns noch nicht so die Einnahmen, was sowohl Vereins Mitgliedsbeiträge, wie auch Spenden betrifft. Im Moment Kosten uns die 4 VMs 30,47 Euro im Monat + 18,90 Euro für die 4 OpenVPN Schwedentunnel. Davon wir ein Gateway immer noch privat durch mich finanziert.

9

Da ich davon keine Ahnung habe, hier mal unser Munin vom UEGW1. Keine Ahnung ob das jetzt viel oder wenig ist.

http://uegw1.freifunk-uelzen.de/munin/ffue/uegw1.ffue/interrupts.html

10

https://munin.ffac.aachalon.net/nodes.freifunk-aachen.de/01.nodes.freifunk-aachen.de/interrupts.html

Da sind wir auch so weit über dem Stand den ihr vor dem verteilen auf mehrere Gateways hattet.

Xeon cpu ist auf alle Fälle eine gute Sache, die können auch ordentlich was ab I/O ab.

Wobei ich auch zugeben muss, dass ich noch nicht ganz durchschaut habe warum wir unseren Supernodes so viel zumuten können, ich hege den Verdacht, dass es auch etwas mit den enorm geringen Latenzen zwischen den Supernodes zu tun hat.

11

s/Knoten/Gateways/ vermute ich? Kannst Du zu dem Setup etwas mehr sagen/auf eine Webseite verweisen? Ich würde nämlich gerne vom fastd zwischen den GWs untereinander weg. Ich weiß, daß einige dort tincd nutzen, von dessen Stabilität bin ich aber nicht überzeugt.
Andererseits schreckt mich ein FullMesh an P2P-Tunneln (L2TP, GRETAP, …) jenseits 4 GWs doch etwas ab, um jene Konfig korrekt zu halten, braucht man imho erst einmal Skripte, die je GW die Tunnelkonfig rauswerfen … (FullMesh: bei 4 GWs ist jedes mit jedem verbunden, also 4 mal 3 Tunnel. Bei 5 GWs reden wir schon über 5 mal 4 Tunnel, oder?)