Für’s Setup v2 (neue und mehr VMs, funktionale Trennung, Konfiguration via puppet) hab’ ich für die Verbindung zwischen den GWs auf L2TP-Tunnel gesetzt (siehe Grafik). Die L2TP-Tunnel sind per batctl if einfach zugeschaltet, wie es vorher das Backbone-fastd-Interface war. Aber weder inner- noch intra-DC sehe ich die Notwendigkeit der Verschlüsselung des unverschlüsselten WLAN-Verkehrs, schon daher weg mit fastd an der Stelle:
root@gw01:~# batctl-ffgt if
gw01-gw02: active
gw01-gw03: active
gw01-gw04: active
ffgt-mesh-vpn: active
Geplant und derzeit umgesetzt ist ein FullMesh (siehe Grafik), was aber mit mehr Gateways irgendwann (also eigentlich ab dem 5. ;)) nicht mehr zwingend praktikabel ist. Evtl. wird es auf 2 designierte GWs pro „RZ“ rauslaufen, die den Traffic in- und außerhalb des jeweiligen Bereichs transportieren und im jeweiligen RZ/beim jeweiligen Hoster werden weitere GWs nur parallel an jene beiden angebunden. Selbst zw. verschiedenen Hetzner-RZen sind die Laufzeiten i. d. R. unter 1 ms — ich glaube nicht, daß sich da ein FullMesh wirklich lohnt. Zumal Inter-GW-Verkehr eigentlich gering sein sollte?
Randbedingungen: batman_adv v14. GWs machen bei uns nur Mesh, IPvX-Defaultroute kommt per OSPF von einem von zwei lokalen Routern (je 1 priorisiert über OPSF-Kosten). Damit ist die fastd-Ebene unabhängiger skalierbar. Inwiefern das noch toll ist, wenn nicht mehr die CPU das Bottleneck ist sondern die GBit-Ports (nach Wechsel von fastd zu L2TP auch zwischen Knoten und Gateway), wird sich zeigen.
Außerdem fangen wir den bisherigen Hoster-Zoo ein, aktuell sieht’s danach aus, daß wir in Gütersloh weiter Hardware stehen haben werden und ein, zwei Hosts bei Hetzner anmieten für Redundanz und Lastspitzen. (Die i7-Kisten aus der Serverbörse machen eine nette Figur und sind mit ~40 EUR/Monat für Kiste, 20 TB und /64er v6- und 5 v4-Adressen für uns erstmal ausreichend.) Außerhalb Güterslohs gehen wir, aus Latenz- und Redundanzgründen, über den FFRL ins v4-Internet. fastd-Ausbalancierung erfolgt durch minütlichen Check der Größe des Meshes, der aktiven (batman-) Gateways und der fastd-Verbindungen, jedes GW nimmt nicht mehr als (KnotenImMesh + 50)/AnzahlBatmanGateways fastd-Verbindungen an. Bei Überschreiten des dynamischen Wertes lehnt das Gateways neue fastd-Verbindungen ab, fastd auf dem Knoten sollte dann ein anderes Gateways ansprechen, was auch zu tun scheint 
Ungelöst (und partiell ungeklärt) ist derzeit noch die ungleiche Verteilung von Clients auf (IPv4-) Gateways; trotz zentralem DHCPd kommt es vor, daß trotz fastd-Verbindung z. B. zu gw03 gw01 als DHCP-Gateway auserkoren wird. Geschieht dies RZ-übergreifend, geht der Datenverkehr pro Paket ggf. mehrfach zwischen Gütersloh und Frankfurt hin und her 
Aber das Problem hatten wir auch schon vor L2TP und zentralem DHCP …
Bislang finde ich L2TP super; wir fahren aber noch keinen Kernel, mit dem die MAC-Adressen änderbar sind. Sofern sich das als Problem herausstellt, werden wir darüber nachdenken Wichtig für uns war, daß die Sessions per „name“ benamst werden können, l2tpXX ist doch etwas unhandlich. Evtl. werden die GRE-Tunnel mit der Zeit, wo möglich, bei uns durch L2TP ersetzt, um das Setup zu vereinfachen.
HTH,
-kai
.
