Tunndeldigger - Durchsatzprobleme ab 300 Knoten

wie groß der Durchsatz je tunnel ist liegt ja nicht nur am gateway sondern an den internetleitungen der betroffen user, wenn du einen bereich hast wo die leute nur 16Mbit Anschlüsse haben können die am Ende auch nichtmehr leisten… ( sorry für die RS Fehler)

Es geht nicht nur um den Durchsatz pro Tunnel, das ganze Gateway lahmt dann einfach.

Nehmen wir z. B. einen VDSL-100 Anschluss. Der performt erst noch super mit Freifunk über das Gateway. Wenn aber durch einen Serverausfall woanders plötzlich die Tunnelanzahl steigt, geht deutlich weniger bis gar nichts mehr.

So was ist ja dann letztlich eine Aufgabe fuer ausgewiesene Linux Performance Troubleshooting Geeks.

An welcher User- oder Kernelland-Ressource skaliert der Kram ab einem bestimmten Punkt nicht mehr ?

In gewissen Grenzen kann man das aber schon vorqualifizieren und bestimmte Fragen stellen:

Mit steigenden n geht die CPU Last rauf oder hoert das dann irgendwann auf ?
Mit sieht es dabei mit dem Verhaeltnis User/SystemCPU aus ?
Gibt es Prozesse/Threads, die fuer sich betrachtet, dauerhaft 100% CPU haben und leider nicht parallelisiert werden koennen ? Meist ist da dann des Pudels Kern.

Ob die SystemCPU steigt haengt zB mit den verwendeten Synchronisationsmitteln zusammen, Wenn der Overhead gross ist, schlagen sich die dann die Koepfe ein um irgendein Semaphor und es werden dauernd n-1 Kontexte aufgeweckt, weil ja gerade wieder was frei geworden ist. Oder ist das besser geloest ?

Und sowas erfordert dann die Mittel, dem Kernel dabei ueber die Schulter schauen zu koennen.
Wir haben kitrace immer unter HPUX verwendet, ich weiss aber dass das Linuxlab das auch fuer Linux verfuegbar gemacht hat (ki == kernel instrumentation), ich habe aber keinen Schimmer, wie distriportabel das mittlerweile ist. .

Vielleicht gibt es aber im Netz aber auch Grundaussagen zur Skalierbarkeit der e.g. l2tp Tunnelhandler ?
Ich kann hier mangels Praxis unter Linux hier nur generische Denkanstoesse liefern.

Hmm, -v?

Denn:

root@ping-ffgt:~# iperf3 -t 60 -i 10 -c 10.255.0.10
Connecting to host 10.255.0.10, port 5201
[  4] local 10.255.8.118 port 48142 connected to 10.255.0.10 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-10.00  sec   801 MBytes   671 Mbits/sec   88    872 KBytes       
[  4]  10.00-20.01  sec   801 MBytes   671 Mbits/sec   57    535 KBytes       
[  4]  20.01-30.00  sec   828 MBytes   695 Mbits/sec    0    844 KBytes       
[  4]  30.00-40.01  sec   730 MBytes   612 Mbits/sec  105    230 KBytes       
[  4]  40.01-50.00  sec   738 MBytes   620 Mbits/sec   33    184 KBytes       
[  4]  50.00-60.01  sec   694 MBytes   582 Mbits/sec   31    160 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.01  sec  4.48 GBytes   642 Mbits/sec  314             sender
[  4]   0.00-60.01  sec  4.48 GBytes   642 Mbits/sec                  receiver

iperf Done.

Setup:

root@ping-ffgt:~# ip addr show dev br0
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 36:a9:da:92:b4:e6 brd ff:ff:ff:ff:ff:ff
    inet 10.255.8.118/20 brd 10.255.15.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2001:bf7:1310:10:fd91:9b1:4919:fd51/64 scope global temporary dynamic 
       valid_lft 86400sec preferred_lft 14400sec
    inet6 2001:bf7:1310:10:34a9:daff:fe92:b4e6/64 scope global mngtmpaddr dynamic 
       valid_lft 86400sec preferred_lft 14400sec
    inet6 fd42:ffee:ff12:aff:fd91:9b1:4919:fd51/64 scope global temporary dynamic 
       valid_lft 86400sec preferred_lft 14400sec
    inet6 fd42:ffee:ff12:aff:34a9:daff:fe92:b4e6/64 scope global mngtmpaddr dynamic 
       valid_lft 86400sec preferred_lft 14400sec
    inet6 fe80::34a9:daff:fe92:b4e6/64 scope link 
       valid_lft forever preferred_lft forever

root@ping-ffgt:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.36a9da92b4e6       no              Egw00

Egw00 ist ein L2TP-Tunnel zu gw00 (VM auf, derzeit, dem gleichen Host).

root@gw00:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-ffgt         8000.063799d0accd       no              Epingff
                                                        bat-ffgt
root@gw00:~# /usr/sbin/batctl -m bat-ffgt if
Egw10: active

Epingff ist die andere Seite von Egw00 auf, eben, gw00. gw00 ist ein Pseudo-Gateway, welches wir für spezielle Anbindungen (nicht über fastd oder Tunneldigger) nutzen. gw00 hängt per L2TP-Tunnel an gw10 (welches, derzeit, auf dem gleichen Host wie gw00 & ping-ffgt läuft):

root@gw10:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-ffgt         8000.deadbeef0210       no              bat-ffgt
root@gw10:~# batctl-ffgt if 
ffgt-mesh-vpn: active
Egw02: active
Egw04: active
Egw00: active

root@gw10:~# ip addr show br-ffgt
25: br-ffgt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether de:ad:be:ef:02:10 brd ff:ff:ff:ff:ff:ff
    inet 10.255.0.10/20 brd 10.255.15.255 scope global br-ffgt
       valid_lft forever preferred_lft forever
    inet6 2001:bf7:1310:10::10/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd42:ffee:ff12:aff::1:10/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::1cbe:d3ff:fed2:3099/64 scope link 
       valid_lft forever preferred_lft forever

Dürfte selbsterklärend sein. Fakt ist: ping-ffgtgw10 lief über eine batman-Strecke (gw00 <> gw10) und lieferte >600 MBit/sec. Heißt: batman kann auch >200 MBit/sec transportieren, auch wenn L2TP involviert ist.

(Oops, Korrektur/Nachtrag: Der Kram ging tatsächlich über’s Netz im DC, denn nur gw10 und ping-ffgt laufen auf dem gleichen Host, gw00 läuft auf einem anderen: Wunder der Wirrtualisierung :wink: Aber das zeigt umsomehr, daß auch über batman „fast GBit“ erreicht werden kann.)

1 „Gefällt mir“

Ja, das ist bei uns auch so. Mir wurde gestern noch ein 900 Mbit/s Speedtest einer VM hinter einem virtuellen Knoten bei Hetzner gezeigt. Alles kein Problem.

Das funktioniert aber nur etwa bis 300 Knoten auf einem Gateway, darüber nicht mehr.

Das funktioniert aber nur etwa bis 300 Knoten auf einem Gateway, darüber nicht mehr.

Naja, Jammern auf hohem Niveau, oder? Bei 300 Knoten auf einem über GBit angebundenen Gateway bleiben um und bei 3 MBit/sec pro Knoten. Wenn das nicht gut austariert ist, bleibt doch auch bei den Knoten die Performance auf der Strecke?

Das sage ich mal den Leuten, die in Foren über die die Vorteile von RAM-Parametern (CL…) diskutieren, die sich dann in RL-Benchmarks im unteren einstelligen %-Bereich was ändern.

Aber im Kern heisst es für mich: die Server mit 1G-Interface und 250MBit/s Anbindung sind technisch besser zu nutzen als die mit 1G-Interface und garantierten 500er (plus Burst), weil der Aufpreis nicht sinnvoll genutzt werden kann.

Der Gesamtdurchsatz ist sowieso auf Gigabit mal Anzahl der Nat-IPs gedrosselt. Es geht hier eigentlich mehr darum, auf wie viele VMs man das unterverteilen muss.

Ich hatte es so verstanden, also ob auch das Blech der Limit-Faktor wäre bei Euch in Münster.

Das wissen wir nicht abschließend. In einer Perf-Analyse am Mittwoch, schien es so, als ob die Syncs im Batman der Engpass sind. Aber wir hatten nur Batman 2016.4 auf dem Gateway. Wir wollen nochmal mit einer neueren Version testen.

Was wir wissen ist, dass die Netzwerkanbindung nicht der Engpass ist. Mit Layer-3-Paketen gehen locker 450-500 Mbit/s in beide Richtungen durch eth0. Das sind dann BGP-Tunnel die Gateways ohne direkte FFRL-Anbindung anbinden.

Also im Rahmen der Meßungenauigkeit, ja? Probier’s, wird nicht helfen :wink:

Du beziehst Dich auf dem @mpw seine Aussagen (dt. Genitiv-s und Discourse, zwei Welten :frowning:)?

Also, wenn ich 1000 MBit/sec durch 20 MBit/sec teile, komme ich bei 50 raus. Demnach sollten nicht mehr als 50 Münsterländer Knoten sich einen GBit-Netzzugang teilen müssen (lies: Worstcase einen Host/Hypervisor). Das ist ein Sechstel der 300 Knoten/VM, bei denen scheinbar der Durchsatz auf „150-200 MBit/sec“ einbricht, wobei ja „300 MBit/sec Dauerlast“ auch wieder kein Problem sind?

Ich komme also ehrlich gesagt nicht mehr mit, auf welche Probleme ich mich bei der anstehenden Umstellung von fastd auf l2tp per tunneldigger einstellen muß.

»Durchsatz« im Threadtitel ist Durchsatz vom Client im Freifunk-Netz ins öffentliche v4-Internet?

… weil die Anzahl der v4-IPs des FFRL (wie bei jeder neuen LIR seit Anbruch des letzten /8) ziemlich endlich ist.

Aber wenn ich zu einem 100 MBit/sec-Anschluß nun noch 10 weitere zuschalte, auf denen auch 100 Mbit/sec abgerufen wurden, bin ich bei einem Bandbreitenbedarf von 1100 MBit/sec über das 1000 MBit/sec-Interface.

Lies: ist es tatsächlich die schiere Anzahl – sprich: mit 1 genutzen und 100 Dummy-L2TP-Tunneln ist’s schick, irgendwo zwischen 101 und 300 Dummy-Tunneln kackt der eine genutzte auch ab – oder eher eine Kombination von Tunnelanzahl und (NAT-) Traffic?

Ich hab’ ja schon Pferde kotzen sehen (lies: wc -l /proc/net/tcp ab ca. 10k Verbindungen zu Sekunden langen Freezes auch für andere Prozesse führen — so um 2001 herum), insofern halte ich lustige Effekte ab gewisser Grenzwerte für durchaus möglich. Und >200 Interfaces halte ich für eine nicht alltägliche Anwendung für den Linux-Kern; aber auch die „900 MBit/sec Speedtest“ können eigentlich nicht bei 100 weiteren Tunneln auf dem System zustandekommen, außer die 100 weiteren Tunnel machen eher so gar keinen Traffic?

Was mir aufgefallen ist: meine „iperf3“-Tests über’s Internet (Plusserver <> Hetzner), inkl. NAT (wir NATen lokal, FFRL ist Fallback), werden über die Dauer immer langsamer:

root@ping-ffgt:~# iperf3 -t 60 -i 10 -c tiffany.uu.org ; sleep 5 ; iperf3 -t 60 -i 10 -c tiffany.uu.org 
Connecting to host tiffany.uu.org, port 5201
[  4] local 10.255.8.118 port 40552 connected to 136.243.22.43 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-10.01  sec   596 MBytes   500 Mbits/sec    0   1.34 MBytes       
[  4]  10.01-20.00  sec   502 MBytes   421 Mbits/sec    6    375 KBytes       
[  4]  20.00-30.00  sec   260 MBytes   218 Mbits/sec    5    366 KBytes       
[  4]  30.00-40.00  sec   237 MBytes   199 Mbits/sec    6    284 KBytes       
[  4]  40.00-50.00  sec   238 MBytes   200 Mbits/sec    5    314 KBytes       
[  4]  50.00-60.00  sec   238 MBytes   200 Mbits/sec    5    341 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  2.02 GBytes   290 Mbits/sec   27             sender
[  4]   0.00-60.00  sec  2.02 GBytes   289 Mbits/sec                  receiver

iperf Done.
Connecting to host tiffany.uu.org, port 5201
[  4] local 10.255.8.118 port 40556 connected to 136.243.22.43 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-10.00  sec   335 MBytes   281 Mbits/sec    8    280 KBytes       
[  4]  10.00-20.00  sec   237 MBytes   199 Mbits/sec    5    301 KBytes       
[  4]  20.00-30.00  sec   236 MBytes   198 Mbits/sec    5    327 KBytes       
[  4]  30.00-40.00  sec   238 MBytes   200 Mbits/sec    5    354 KBytes       
[  4]  50.00-60.00  sec   234 MBytes   196 Mbits/sec    5    296 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  1.48 GBytes   212 Mbits/sec   34             sender
[  4]   0.00-60.00  sec  1.48 GBytes   212 Mbits/sec                  receiver

Etwas gewartet.

root@ping-ffgt:~# iperf3 -t 60 -i 10 -c tiffany.uu.org ; sleep 5 ; iperf3 -t 60 -i 10 -c tiffany.uu.org 
Connecting to host tiffany.uu.org, port 5201
[  4] local 10.255.8.118 port 40560 connected to 136.243.22.43 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-10.03  sec   576 MBytes   482 Mbits/sec    2    803 KBytes       
[  4]  10.03-20.00  sec   587 MBytes   494 Mbits/sec    0   1.16 MBytes       
[  4]  20.00-30.00  sec   561 MBytes   471 Mbits/sec    4    730 KBytes       
[  4]  30.00-40.00  sec   282 MBytes   237 Mbits/sec    7    290 KBytes       
[  4]  40.00-50.00  sec   239 MBytes   201 Mbits/sec    5    320 KBytes       
[  4]  50.00-60.00  sec   240 MBytes   201 Mbits/sec    5    351 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  2.43 GBytes   347 Mbits/sec   23             sender
[  4]   0.00-60.00  sec  2.43 GBytes   347 Mbits/sec                  receiver

iperf Done.
Connecting to host tiffany.uu.org, port 5201
[  4] local 10.255.8.118 port 40564 connected to 136.243.22.43 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-10.00  sec   356 MBytes   299 Mbits/sec    8    346 KBytes       
[  4]  10.00-20.00  sec   244 MBytes   204 Mbits/sec    6    266 KBytes       
[  4]  20.00-30.00  sec   236 MBytes   198 Mbits/sec    5    291 KBytes       
[  4]  30.00-40.00  sec   236 MBytes   198 Mbits/sec    5    315 KBytes       
[  4]  40.00-50.00  sec   238 MBytes   200 Mbits/sec    5    342 KBytes       
[  4]  50.00-60.00  sec   241 MBytes   202 Mbits/sec    6    266 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  1.51 GBytes   217 Mbits/sec   35             sender
[  4]   0.00-60.00  sec  1.51 GBytes   217 Mbits/sec                  receiver

iperf Done.

Im LAN hingegen fällt das nicht so dramatisch ab:

root@ping-ffgt:~# iperf3 -t 60 -i 10 -c 192.251.226.115 ; sleep 5 ; iperf3 -t 60 -i 10 -c 192.251.226.115
Connecting to host 192.251.226.115, port 5201
[  4] local 10.255.8.118 port 41730 connected to 192.251.226.115 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-10.01  sec   684 MBytes   573 Mbits/sec   47    648 KBytes       
[  4]  10.01-20.00  sec   593 MBytes   498 Mbits/sec   27    197 KBytes       
[  4]  20.00-30.00  sec   600 MBytes   503 Mbits/sec   40    194 KBytes       
[  4]  30.00-40.00  sec   533 MBytes   447 Mbits/sec   36    140 KBytes       
[  4]  40.00-50.00  sec   611 MBytes   512 Mbits/sec   40    167 KBytes       
[  4]  50.00-60.00  sec   592 MBytes   496 Mbits/sec   39    187 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  3.53 GBytes   505 Mbits/sec  229             sender
[  4]   0.00-60.00  sec  3.53 GBytes   505 Mbits/sec                  receiver

iperf Done.
Connecting to host 192.251.226.115, port 5201
[  4] local 10.255.8.118 port 41734 connected to 192.251.226.115 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-10.01  sec   612 MBytes   513 Mbits/sec   41    160 KBytes       
[  4]  10.01-20.00  sec   579 MBytes   486 Mbits/sec   38    180 KBytes       
[  4]  20.00-30.01  sec   612 MBytes   513 Mbits/sec   41    146 KBytes       
[  4]  30.01-40.00  sec   582 MBytes   488 Mbits/sec   38    182 KBytes       
[  4]  40.00-50.00  sec   547 MBytes   459 Mbits/sec   36    204 KBytes       
[  4]  50.00-60.03  sec   567 MBytes   475 Mbits/sec   38    181 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.03  sec  3.42 GBytes   489 Mbits/sec  232             sender
[  4]   0.00-60.03  sec  3.42 GBytes   489 Mbits/sec                  receiver

iperf Done.

Jedenfalls: wenn noch NAT/externes Routing mit reinspielt, sehe ich nicht, wie man das Rätsel lösen will :frowning:

1 „Gefällt mir“

@wusel, irgendwie fehlen deinen Rechnungen die Gaußkurven. Oder anders ausgedrückt: Du hast nicht verstanden, dass natürlich nicht alle Knoten gleichzeitig genutzt werden.

Probier mal bei Unitymedia in der ganzen Nachbarschaft 400 Mbit/s gleichzeitig abzurufen, natürlich geht das nicht.

Es geht um folgendes: Wenn 500 oder 600 Knoten an einem Gateway hängen, fast alle nichts tun, sollen einige wenige immer noch 20-30 Mbit/s schaffen.

Und das geht derzeit nicht, weil irgendwelche Kernelverwaltungsstacks oder der Tunneldigger oder das Batman oder was weiß ich, damit überfordert sind.

3 „Gefällt mir“

In der Telefontechnik wäre der gesuchte Begriff hier nicht „gauss“ sonder „erlang“.

Also nachdem der L2TP Tunnel aufgebaut ist, läuft sämtlicher Traffic nur über den Kernel Space.
Nur die keep-alive Pakete werden von Tunneldigger in diesem Fall verarbeitet.
D.h. es wird eigentlich nur durch die Implementierung von L2TP, Batman sowie der Hardware Performance ausgebremst.
Wenn es an Tunneldigger liegt dann würde sich das mit häufigen VPN disconnects bemerkbar machen.

500~ VPN Sessions sind schon eine ganze Menge, da kann es gut sein das der Hypervisor auch die Paketflut eindämmt um andere VMs nicht zu beeinträchtigen.
Ich würde das ganze mal auf Bare-Metal testen um genauere Werte zu bekommen :slight_smile:

4 „Gefällt mir“

Was heisst denn das: Reicht es zwei Testkisten zu nehmen, einen belasteten Tunnel zwischen beiden zuschaffen und dann unbelastete Tunnel one by one dazu zu bauen und peu a peu zu sehen, dass der Overhead immer groesser wird, nur um den Traffic des einen Tunnels zu stemmen ?

Da muss man dann die richtigen Tools haben, um zu sehen, wo im Kernel die Zeit hingeht.

Irgendwie … ist das alles etwas fischig. Wenn ich von meiner Test-VM – die einen L2TP-Tunnel (handgeklöppelt, kein Tunneldigger) zu einer anderen VM hat, die wiederum im Batman-Netz (batman via L2TP) hängt und über eine 3. VM ins Netz geht – per iperf3 einen Durchsatztest mache, komme ich derzeit auch im LAN nicht über ~460 MBit/sec im Schnitt hinaus. (ping-ffgt <l2tp> gw00 <batman-via-l2tp> gw10 <NAT> LAN).

Und auch bei der Wiederholung des Tests von vor ein paar Tagen – da waren’s 640 MBit/sec – komme ich jetzt auf nur 460 bis 490 MBit/sec.

Was ich sehe ist, daß im Durchleitungsfall „ksoftirqd“ bei ca. 500 MBit/sec schon mal 25% CPU verbrät.

iperf3 von ping-ffgt direkt über ens9 zu gw00 bringt knapp 930 MBit/sec und auf gw00 taucht nur „iperf3“ mit ca. 25% CPU auf (ksoftirqd bleibt unter 1%) — das ist im Grunde nur Bridging, da werden noch keine Pakete groß umgepackt.

„iperf3 -t 60 -i 10“ von ping-ffgt zu gw00 über den L2TP-Tunnel (auf die br-ffgt-IP von gw00) bringt wieder nur knapp 460 MBit/sec, jetzt schlagen jeweils „iperf3“ und „ksoftirqd“ mit 25-30% CPU auf.

Ich würde in L2TP insofern schon ein signifikantes Nadelöhr verrorten; auch zu unserem BGP-Router am Community-IX kommen über den L2TP-Tunnel „nur“ 420 bis 470 MBit/sec zustande, „außenrum“ sind’s 700 bis 750 MBit/sec (beide Seiten sind VMs). (Mal davon ausgehend, daß IN-Berlin, unser Uplink dort, selbst „etwas“ Traffic nutzt, erscheinen die Werte plausibel.)

Zwar „kostet“ L2TP weniger CPU-Overhead als fastd, aber augenscheinlich doch zuviel, um ein GBit vollzumachen? Wobei ich ~50% jetzt doch als etwas zuviel „Verlust“ empfinde?

2 „Gefällt mir“

Ja, aber um wirklich objektiv auf einer Kiste testen zu können, müsstest du die weiteren Tunnel von anderen Maschinen aus aufbauen.

Wo steht die VM? Manche Hoster drosseln diese Tunnel. Zwischen Hetznerkisten intern bei denen im Netz habe ich schon 950 Mbit/s über L2TP inklusive Batman gesehen, da war aber nichts anderes auf den Kisten auch keine anderen Knoten.

Die Hosts (und damit die VMs) stehen lokal im RZ. Filter auf L2TP auf den Switches halte ich für hinreichend unwahrscheinlich. Was sich allerdings geändert hat: die zum Testen verwendeten Hosts haben seit dem 640-MBit/sec-Test weitere VMs, z. T. mit deutlicher (CPU-, Netzwerk-) Last, bekommen. Aber „eigentlich“ sollten sie weit von einem Lastproblem entfernt sein (Summe vCPUs je Host < 50% der vorhandenen Cores).

Das war HW-zu-HW oder schon mit Virtuallisierung dazwischen?

Auf beiden Seiten virtualisiert. Das Gateway war das, wo ich das GRE-Nat ausprobiert habe und das andere war ein virtuelles Gluon und dahinter ein virtuelles Debian, was im Freifunk hängt. War auch nicht nur ein lokaler Speedtest, sondern ein externer von speedtest.net.

Ich habe aber auch schon Erlebnisse gehabt, wo bei 5-600 Schluss war. Hängt vielleicht von der CPU ab oder so.