HOWTO Multi-Fastd

Technik Infrastruktur / Backbone
1

Hier mal die “Anleitung” für multi-fastd, auf das dies jemand automatisieren kann.

Kontext
fastd, unsere VPN Waffe der Wahl zur Zeit, ist super für Clients (da klein und effizient) aber auf den Supernodes genau das Gegenteil. Es ist Single-Threaded und es setzt auf TAP auf. Langfristig gibt es andere Optionen aber momentan ist es halt fastd.

Der Single-Threaded Aspekt führt dazu das fastd die vorhanden Kapazität nicht nutzen kann. Sobald fastd halbwegs in die CPU Sättigung fährt, fängt es an Pakete zu verlieren was die Performance der Clients dramatisch verschlechtert (siehe “Mathis formula”). Dieser Effekt ist bei fastd Instanzen mit weniger als 100% CPU zu beobachten. D.h. man schafft es nichtmal einen Core auszulasten. Sehr ineffizient.
Überliefert ist die Daumenregel von 100 VPN connections pro fastd instanz auf x86.

Der Workaround ist simpel: Mehrere fastd Instanzen. Das ist ziemlich simpel, die Unterschiede zu einer single instanz installation:

  • Man brauch pro Instanz ein Schlüsselpaar und Config File (auf den kgbvax’ nodes heissen die fastd-a … fastd-d
  • Pro fastd instanz wird ein eigener Port verwendet
  • Wichtig kann man aber schnell vergessen: Pro fastd wird ja ein Netzwerk Interface erzeugt welches auch eine individuelle MAC Adresse braucht. Da könnte man einfach das vierte Oktett hochzählen oder so.

Also nochmal, unterschiede in den Config Files bei (kgbvax2|3)

  • status socket
  • bind addresses (port nummer)
  • interface (abweichende namen, zb meshvpn-a … meshvpn-d)
  • private key
  • on up… eigene MAC Adresse
  • Sowie eignen .service, damit systemd die Instanz auch startet.

Das war’s dann schon. Klinkt sich automatisch in batman ein.

Ich hoffe damit kann man das nun nachbauen :smile:

Damit kann man nun die Hardware besser nutzen und spart massiv Blech und VMs.
Apropos VM: Es macht aus meiner durchaus Sinn mehr fastd instanzen zu fahren als Cores vorhanden sind. Also zb. 3xfastd auf einer VM mit 2 vCPU (bis diese in die Sättigung fahren halt).
Und noch einen aus der Kiste: Statische Allokation von Cores zu VMs reduziert ebenfalls die Effizienz des Gesamtsystems.

6 „Gefällt mir“
2

Ich habe das mal ausprobiert und es ist natürlich gleich schiefgegangen. Wahrscheinlich habe ich zu wenig Ahnung von Netzwerkzeug. :wink:

Also auf den Emscherland Supernodes gibt es es jeweils zwei fastd-Instanzen, einmal zum Backbone und einemal für die User.

Die Instanz ruhrgebiet verweist auf TAP0, die Instanz backbone verweist auf TAP1. Ich muss also erst ein TAP2, TAP3, TAPx anlegen bevor ich eine weitere Instanz einrichte?

3

Das Interface wird von fastd IMHO selbst erzeugt, config “interface”. Habe ich oben vergessen ;.-)

1 „Gefällt mir“
4

Der Fehler war woanders, klappt jetzt!

1 „Gefällt mir“
5

Willkommen zu einem völlig neuem fastd Gefühl :wink:

6

Man braucht übrigens kein eigenes .service. Bei Debian8 ist schon ein fastd@.service, das darauf ausgelegt ist, mehrere Instanzen von fastd zu starten: eine pro /etc/fastd/*/fastd.conf. Und die Keys können die Instanzen sich auch teilen. (Ist so übrigens auf ffms-map mit ansible konfiguriert.)

7

Ich würde gerne auf den Maschinen der neuen Domänen mehrere fastd Instanzen (in diesem Fall zwei) laufen lassen. Auch wenn die Maschinen (wegen eines batman-bugs) nur einen CPU-Kern haben.

Ich bin dafür, @MPW ist dagegen. Hast du da schon Erfahrungen gesammelt, was Durchsatz und Overruns, etc. angeht? Dann würde ich das gerne für Mittwoch auf die Diskussionsliste setzen, dann können wir uns ein bisschen zanken. :stuck_out_tongue:

8

Probieren ist immer gut. Aber bitte nicht auf allen VMs einer Domäne gleichzeitig.

9

Ein Supernode der nur als fastd-server ist. muss doch zwei fastd Instanzen haben. er muss als Client gegenüber die anderen Supernodes und als Server gegenüber die Routern.

ich habe zwei Instanzen aber eine funktioniert nicht (Device is Busy). kann mir jemand helfen ?

10

Hallo,

das Multi-Fastd was hier mal angedacht gewesen ist, war die Idee, mehre Kerne auf einem Multikernsystem nutzen zu können, da Fastd nur einen Kern nutzen kann.

Das wurde verworfen, weil Batman 15 nicht mehr mit mehreren Kerne umgehen kann, bzw. dabei häufig abstürzt und auch die Rechenleistung dank L2TP keine Rolle mehr spielt.

Was du möchtest, ist aber zwei Geräte mit fester IP zu verbinden, also zwei Gateways bzw. einen Superknoten an ein Gateway anbinden. Davon kann ich erstmal abraten, weil wir gemerkt haben, dass das zu Durchsatzeinbußen führt, zumindest reine Superknoten, die nur im Layer-2 routen. Insbesondere der IPV6-Verkehr, der 40-50% ausmacht, fließt dadurch noch chaotischer, als ohnehin schon.

Wenn du es trotzdem versuchen möchtest, würde ich den Superknoten per GRETAP anbinden, hier ein Beispiel aus unserer Konfiguration, wie wir zwei Gateways einer Domäne untereinander verbinden:

auto tap-greyworm-03
iface tap-greyworm-03 inet manual
        pre-up ip link add $IFACE type gretap local 148.251.208.171 remote 89.163.253.62 dev eth0
        pre-up ip link set dev $IFACE address de:ad:be:ef:45:2
        pre-up ip link set $IFACE up
        post-up batctl if add $IFACE ||:
        pre-down batctl if del $IFACE ||:
        post-down ip link del $IFACE

Der Name ist natürlich frei wählbar, die lokale und die gegenüber IP musst du entsprechend anpassen. Wenn man mehrere Tunnel (für verschiedene) Domänen zwischen denselben IPs aufbauen möchte, geht das mit einem Schlüssel, den man an die Konfiguration anhängt. Man nummeriert die Tunnel quasi durch.

Wir haben dazu eine Ansible-Rolle: https://github.com/FreiFunkMuenster/ansible-ffms/blob/master/roles/gateways_gretap/templates/gretap.j2

Grüße
Matthias

Begriffserklärung, wie wir sie verwenden:
Superknoten := reines Layer 2 routen, also quasi ein Fastd-Konzentrator, der VPN-Tunnel terminiert und die Pakete durch einen Gretap-Tunnel zum Gateway schickt.
Gateway := Übergang vom Layer-2 ins Layer-3 Netz, oft einhergehend mit dem Natting, dies kann aber auch noch eine Ebene höher im Backbone geschehen.

11

wissen Sie ob das auch der Fall in Wupper-Domäne ist ?

12

Hi,

ich glaub wir können uns ruhig duzen :).

Was genau meinst du damit, ob es in der Wupperdomäne auch so ist?

Grüße
Matthias

13

Hi, :slight_smile:
ich meine ob die Verbindung zwischen die Supernodes von der Wupperdomäne mit GRETAP realisiert ist oder mit Tinc ? und die Verbindung zwischen Supernodes (Gateway) und Rheinland IC-VPN (Tinc und BGP).

also

Supernode -> Supernode (Gateway) per tinc ?
Supernode (Gateway)-> Rheinland Server per IC-VPN ?

Danke

14

Hallo,

Tinc kenne ich überhaupt nicht. Wie die Vernetzung in der Wupperdomäne ist, müsstest du am Besten im Rheinlandforum fragen, dort sind deren Admins aktiv.

Das Rheinlanfbackbone ist überall per GRE (nicht GRETAP) angebunden. Ebenso das ICVPN.

GRE ist Layer 3, GRETAP Layer 2.

Grüße
Matthias

15

Ein Beitrag wurde in ein neues Thema verschoben: Iperf auf Gluonroutern