Multidomain Backend

Technik
1

Hallo,

ich habe mal ein paar Fragen zur Umsetzung des Themas Multidomain im Bezug auf das Backend.
Wir vom Freifunk Harz setzen bisher auf eine einzige große BATMAN-Wolke mit über 1200 Gluon-Knoten an 4 Gateways (Blech).
Von der Perfomance können wir bisher nicht meckern, nur das Grundrauschen ist doch schon recht erheblich. Für ein zukünftiges Wachstum kommen wir nicht umhin, uns mit einer Netztrennung zu beschäftigen

Meine Überlegung ist, die 4 Blech-Gateways durch KVM-Hosts zu ersetzten und auf diesen mehrere Gateway-VMs zu betreiben. Zwecks Ausfallsicherheit sollten es pro Domain mindestens 2 Gateways auf verschiedenen Hosts sein. Ich hoffe das ist alles so sinnvoll?
Mir bleiben da noch einige weitere offene Fragen, wo ich hoffe, dass Ihr mir einen Rat geben könnt, wie Ihr das gelöst habt.
Die Gateways einer Domain werden untereinander per FastD o.ä. verbunden. Wie löst man am besten das Routing zwischen den Domains? Ein Routing-Server, an den alle Gateways/Domains angebunden sind oder jede Domain mit jeder Anderen verbunden? Ein zentraler DNS/DHCP oder für jede Domain separat.

Hat vielleicht jemand mal die Server-Struktur eines Multidomain-Setups aufgezeichnet?

Liebe Grüße

Helmut

2

Ich kann als Beispiel FFMUC erwähnen. Bei uns laufen alle Domains auf allen Gateways um die Ausfallsicherheit zu erhöhen. Wir haben drei Gateways auf jeweils einem anderem KVM Host.

Damit übernimmt auch jeweils das Gateway das Routing (Layer-3) in die anderen Domains (fun-fact eigentlich nutzt das niemand).

Die Gateways untereinander (innerhalb einer Domain) werden entweder direkt per VLAN, FASTD oder L2-Tunnel-deiner-Wahl verbunden.

3

Layer 3 Routingprotokoll: BGP, Babel, OSPF, etc. Dann kann man die Gateways frei verbinden, nicht jeder muss mit jedem reden, da es mit „Transit“ auch über mehrere Hops geht. So gemacht in Franken:

root@fff-gw-cd-home:~# traceroute fd43:5602:29bd:e4:c6e9:84ff:fe87:9917
traceroute to fd43:5602:29bd:e4:c6e9:84ff:fe87:9917 (fd43:5602:29bd:e4:c6e9:84ff:fe87:9917), 30 hops max, 64 byte packets
1 fd43:5602:29bd:1e:6666:b3ff:fede:f5cd (fd43:5602:29bd:1e:6666:b3ff:fede:f5cd) 11.851 ms 5.408 ms 3.069 ms
2 fd43:5602:29bd:2a:7a8a:20ff:febc:667c (fd43:5602:29bd:2a:7a8a:20ff:febc:667c) 9.057 ms 10.213 ms 5.775 ms
3 fd43:5602:29bd:2b:a62b:b0ff:fead:a44c (fd43:5602:29bd:2b:a62b:b0ff:fead:a44c) 18.562 ms 14.357 ms 37.000 ms
4 fd43:5602:29bd:e4:c6e9:84ff:fe87:9917 (fd43:5602:29bd:e4:c6e9:84ff:fe87:9917) 20.913 ms 33.757 ms 28.238 ms

wir nutzen btw. Babel und sind sehr zufrieden damit.

Gruß

Christian

1 Like
4

Danke! Ich hatte schon ein schlechtes Gewissen weil wir nicht untereinander vernetzen. :slight_smile:

5

spätestens wenn ein Gateway keine default Route hat (weil z.b. privat betrieben wird und man rechtlich aus dem Schneider sein will) wird es sehr intensiv genutzt :wink: Ja hier kann jede Privatperson die in dem Layer 3 Netz ist ein eigenes Gateway betreiben ohne rechtliche Probleme zu bekommen da irgendwer im Layer 3 Netz schon eine default route hat, andersherum können mehrere Vereine/Firmen in einer Community (dezentral!) default routen anbieten. Auch das hat Freifunk Franken schon seit einiger Zeit :wink:

6

Gut sowas haben wir nicht ;). Unsere Gateways stehen in den PoPs und haben Default Routen :).

7

böse Antwort lieb gemeint dann seid ihr zu zentral :wink:

8

Stimmt :smiley: .

Aber so gewählt und im Moment glücklich. Kann sich ja noch ändern :).

1 Like
9

wollen wir es noch weiter führen? Man kann das L3 Netz sogar durch die Stadt in ein Richtfunknetz ziehen. Siehe mein Traceroute oben, das waren eigentlich gar keine Gateways im RZ sondern durch eine gute Hand voll Richtfunkstrecken quer durch die Stadt (genaugenommen sogar von Fürth nach Nürnberg, also über die Stadtgrenze hinweg). Verrückt oder? :wink:

2 Likes
10

Ist im Grunde das, was wir auch machen, allerdings haben wir mittlerweile die fastd-Prozesse auf den Host verlagert und wir bridgen die fastd-Interfaces in die Gateway-VMs. Das ist deutlich weniger schmerzhaft als früher, als die Gateway-VMs lokal fastd laufen hatten.

root@thunderflare:~# brctl show
[…]
fastd176-br             8000.deafbee00001       no              gut176-vpn
                                                        one-199-1
fastd177-br             8000.deafbee00002       no              gut177-vpn
                                                        one-199-2
fastd178-br             8000.deafbee00003       no              gut178-vpn
                                                        one-199-3
fastd179-br             8000.deafbee00004       no              gut179-vpn
                                                        one-199-4
[…]

(gutNNN-vpn ist ein VXLAN zwischen unseren Hosts, somit kann auf jedem eine GW-VM gestartet werden. Wie man sieht, laufen hier 4 fastd-Tunnel in eine VM (one-199; wir nutzen OpenNebula als Virrtualisierungsfrontend), die ohne fastd nichts rechenintensives mehr zu leisten hat.)

Weil fastd aber auf mehreren Ebenen »keinen Spaß« macht, schwenken wir ›derzeit‹ auf L2TP als Tunnelprotokoll; tunneldigger läuft dann wieder in der GW-VM (die bei uns traditionell – batman_adv.ko hat sonst phasenweise Stabilitätsprobleme – 1 CPU haben). Die alten GWs haben wir mit Puppet nach dem Muster von Freifunk Nord aufgesetzt, für das neue Setup setzen wir auf die Ansible-›Rollen‹ nach Münsteraner Muster.

Jene setzt die GWs dann so auf, daß dann je Mesh (»Domäne«) u. a. ein tunneldigger läuft, eine entsprechende Bridge besteht, ein batman-Interface, …

root@l2tp-ham01 ~ # ps -Aelf|grep tunneld
4 S root       578     1  0  80   0 - 16378 ep_pol Jun14 ?        00:00:02 /srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /srv/tunneldigger/broker/l2tp_broker_domain00.cfg
4 S root       607     1  0  80   0 - 16442 ep_pol Jun14 ?        00:04:37 /srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /srv/tunneldigger/broker/l2tp_broker_domain02.cfg
4 S root       608     1  0  80   0 - 16378 ep_pol Jun14 ?        00:00:00 /srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /srv/tunneldigger/broker/l2tp_broker_domain03.cfg
4 S root       609     1  0  80   0 - 16742 ep_pol Jun14 ?        00:15:46 /srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /srv/tunneldigger/broker/l2tp_broker_domain04.cfg
4 S root       614     1  0  80   0 - 16378 ep_pol Jun14 ?        00:00:00 /srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /srv/tunneldigger/broker/l2tp_broker_domain06.cfg
4 S root       616     1  0  80   0 - 17007 ep_pol Jun14 ?        01:31:21 /srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /srv/tunneldigger/broker/l2tp_broker_domain01.cfg
4 S root       637     1  0  80   0 - 16475 ep_pol Jun14 ?        00:16:25 /srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /srv/tunneldigger/broker/l2tp_broker_domain05.cfg
root@l2tp-ham01 ~ # brctl show
bridge name     bridge id               STP enabled     interfaces
br00            8000.02caffee0002       no
br01            8000.02caffee0102       no              l2tp379-379
                                                        l2tp436-436
                                                        l2tp437-437
                                                        l2tp443-443
                                                        l2tp445-445
                                                        l2tp446-446
                                                        l2tp447-447
br02            8000.02caffee0202       no
br03            8000.02caffee0302       no
br04            8000.02caffee0402       no              l2tp153-153
br05            8000.02caffee0502       no              l2tp152-152
br06            8000.02caffee0602       no
root@l2tp-ham01 ~ # batctl -m bat00 if
br00: active
t00-karte: active
t00-l2tp-ams01: active
root@l2tp-ham01 ~ # batctl -m bat06 if
br06: active
t06-karte: active
t06-l2tp-ber01: active

Wieviele Meshes je GW laufen sollen kann man einstellen, so ist der Partner für die zukünftige »Domäne 00« nicht, wie für alle anderen, eine VM auf unserem System in Berlin sondern eine VM in Amsterdam.

Tunnel zum Kartenserver und zu anderen GWs werden auch automatisch angelegt (auf Wunsch auch die Kartenserver-VM gebaut), das macht das recht pflegeleicht :wink:

BTW: Ich würde bevorzugt auf L2TP o. ä. zwischen den Gateways setzen, keinesfalls fastd: fastd verbrät nur unnütz Rechenzeit, das geht heute eleganter und performanter.

Nachtrag: Das Routing zwischen den Meshes läuft über OSPF, auch das wird automagisch eingerichtet.

11

interesaanter ansatz …

12

fastd in der VM bedeutet ja, der VPN-Traffic muß durch den Host in die VM, dort dann jedes Paket vom Kernel- in den Userspace und das entpackte Paket dann wieder in den Kernelspace und wieder durch VirtIO aus der VM raus, vorher ggf. noch frisch in einen anderen Tunnelenvelope eingepackt — und für jedes Antwortpaket das ganze wieder rückwärts. Das scheint nicht nur theoretisch ineffektiv zu sein, die einzelnen fastd auf dem Blech zeigen weniger CPU-Belastung als vorher in den VMs, und bei hoher fastd-Belastung verhält sich das Netz weniger „zickig“. Aber, wie immer: YMMV.

1 Like
13

Vielen Dank für den Input!
Da habt ihr mir einige interessante Gedankenanstöße gegeben.

1 Like
14

bin da komplett bei dir. nur sorum hab ich das noch nicht gedacht und ja: es macht def sinn

15

Wir haben für den Anwendungsfall Ansible-Rollen, die so gehalten sind, dass sie auch von anderen Freifunk-Communities verwendet werden können:

Die Anleitung dort ist vllt. schon etwas alt. Aber das System wird immer noch gepflegt. FF Ingolstadt hat gerade mit @citronalco darauf umgestellt. Man kann jetzt anders als dort noch erklärt, auch wieder Fastd-Domänen betreiben.