Platzhalter eingefügt von Tarnatos.
oftmals haben wir beobachtet, dass ein Großteildes Problems eben dadurch entsteht, dass es sehr viele gateways gibt. Jedes zusätzliche Gateway führt zu viel mehr Background-Traffic als ein zusätzlicher Knoten.
Insofern sollte man überlegen, ob es nicht sinnvoller ist nur zwei potente Gateways zu betreiben (mit jeweils mehreren fastd-Instanzen, falls ihr fastd nutzt)
bei gluon upstream konkurrieren seit Anfang des Jahres die Konzepter „hoodselector“ und „multi site support“ um eine Aufnahme.
Es ist unwahrscheinlich, dass beide aufgenommen werden…
A post was merged into an existing topic: Netsplit und Alternativen - B.A.T.M.A.N. Domain verkleinern
Auf die Gefahr, dass es etwas OffTopic wird (weil es sich nicht an der Frage des TS orientiert):
Der Traffic entsteht doch nicht dadurch, dass mehr Nodes als GW geflagt sind, sondern die Unart, zwei fastd-Tunnel pro Wifi-Hotspot aufzubauen. Leider fehlt da noch ein ordentliches Script, welches einen fastd-Tunnel, hinter dem kein Supernode sinnvoll erreichbar ist, abbaut, zugunsten eines Neuversuchs bei einem anderen.
Und dann kommt noch die unüberlegte Schlauheit vieler Domain-Admins, zusätzlich noch die 2-7 „Supernodes“ per Batman n-fach untereinander zu verbinden.
Mit dem Effekt, dass der Routinggraph (also die Anzahl der möglichen Wege) für die Knoten exponentiell ansteigt.
Umgekehrt ist es natürlich schon peinlich, wenn das eigentlich Key-Feature eines Mesh-Netzes (autonomes Routing, redundante Links) zum Scheitern führt.
(BTW: Das ist einer der Gründe, warum Domains mit L2TP „statt fastd“ meist gefühlt besser laufen: Die Hotspots haben bei L2TP per Default nur einen batman-Link zu ihrem Gateway statt zwei, wie default bei fast-Installationen. Und nein, das ist beides nicht in Stein gemeißelt. Aber eben der Standard, von dem viele (die meisten?) nicht abweichen.)
Das ist einfach eine Frage des Geldes.
Unsere aktuelle Finanzlage erlaubt es nicht wenige potente dedizierte Server zu mieten. Daher setzen wir auf eine größere Anzahl an OVH Cloud VMs (3,50€). Abgesehen davon haben Tests gezeigt, dass Proxmox VMs auf potenten Servern nicht wesentlich oder gar nicht schneller waren, so das maximal, so wie du schon sagst, mehrere fastd Instanzen eingesetzt werden könnten.
Das würde mich auch interessieren. Wir nutzen derzeit nur eine VPN Verbindung pro Node.
Bei uns sind alle GWs untereinander via fastd Backbone (eigene fastd Peer Group) verbunden. Wie soll es auch anders gehen?!
Ist es nicht Standard, das sich alle Komponenten in einer Layer2 Domäne untereinander im Batman sehen, ich wüsste gar nicht wie man das ausstellen kann.
Besser ist natürlich eine L3 Verbindung zwischen den Gateways
Ihr könntet diesen Backbone nicht in das gleiche batman-Netz hängen, sondern das erst am vswitch zusammenfassen.
Und nur der mapserver verbindet sich mit allen Supernodes, hat aber eine extreme Hop-Penalty (50…), so dass der Quertraffic und der „innerhalb der Domain“ über den Mapserver muss. Aber es gibt dann nur noch einen Verbreitungsweg.
Oder man trennt das Batman-Netz komplett auf, dann hängt das Netz nur noch auf dem Layer2 mit einem Batman-Subnetz pro Supernode und ggf. Querlinks wenn Wolken mehrere Uplinks haben. Aber das regelt ja dann die Hop-Penalty…
Zugegeben, das ist keine wirklich schöne Lösung. Aber bei dem leider realistischen Szenario der meisten Netze (wenig Wolken mit mehreren Uplinks, >80% Hotspots) durchaus Effektiv gegen Batman-probleme.
Dann noch ein paar rigorose Regeln gegen Martians/Roguenets, Broadcasts, Unicasts und Multicast-Groups und dertig ist das die performante Hotspot-Architektur…
Um auf Deine Antwort einzugehen:
Das ist die Frage, über welche Layer2-Seiten Du sprichst.
Kaum zu ändern ist, dass alle Knoten eines Batman-adv-Netzes, die über diverse Layer2-Switches (die in jedem Router zwischen Batman und den Fastd-Tunneln, in den Supernodes zwischen den Fastd-Tunneln etc) irgendwie zusammenhängen, sich gegenseitig sehen. (ohne im Batman-Code zu patchen. Ich wüsste aber nicht, wie man das tun könnte, ohne potentiell haufenweise Dinge zu ruinieren)
Dass Client-Layer2-Netz ist natürlich auch durchgehend. Aber darüber sehen die Batman-Router sich nicht gegenseitig.
Von daher: Nein, sie sehen sich nicht im Client-Layer2.
Da Du auf einen Satz von mir antwortest, der für mich in keinem erkennbaren Zusammenhang mit meiner Aussage steht, nochmal erläutert:
Ich schreib auch nicht von „überhaupt miteinander verbinden“. Sondern von von „n-fach“…
Warum nicht? Ist um Folgeabsatz erläutert.
„Aber das ist doch absurd“: Siehe noch ein Absatz weiter.
Sorry, dann hatte ich dich falsch verstanden, es ging um das mesh layer 2 netz. das ich meinte.
fastd zwischen GWs verbrät doch nur unnütz CPU; wir verbinden die GWs per L2TP-Tunnel.
Je mehr Gateways und auch Knoten in einer Layer2 Domäne sind umso mehr Grundrauschen/Overhead, wie auch immer ihr es nennen wollt gibt es. Wir haben bei uns meistens 3 Gateways pro 250 Router in einer Broadcast Domäne. Die Gateways sind in der Domäne über Batman miteinander verbunden. Ausserhalb der Domäne sind die Gateways über GRE-Tunnel mit Babel als Protokoll miteinander verbunden. Man kann die Gateways innerhalb auch noch mal über GRE-Tunnel verbinden. Grundrauschen geschätzt 64K
Wir fahren aktuell fastd und L2TP paralell
Wobei ich noch erwähnen sollte dass wir kein Gluon einsetzen, daher keine Feste Gateway Zuordnung in der Firmware haben.
well well, manche möchten aber nur verschlüsselte VPNs nutzen.
Die Diskussion vermag ich ja zwischen Knoten und Gateway ganz am Rande noch tolerieren zu können (»weil wir das so versprochen haben« oder »weil wir dem ISP zutrauen, uns zu drosseln«); inwiefern ein öffentliches WLAN, getunnelt zwischen VMs auf dem gleichen Host oder VMs im gleichen DC – oder selbst zwischen VMs in verschiedenen DCs – verschlüsselungswürdig sein sollte, zumal diese Inhalte hernach eh’ wieder nackig beim Exit ins Internet kullern, erschließt sich mir nicht. Verschwendung von CPU-Zyklen und damit – insbesonderen angesichts der Bandbreite – Energie ist das, mehr nicht 
Bitte beim Thema bleiben.
Die Art der inter GW Vernetzung (crypto ja/nein) hat erstmal nix mit den Auswirkungen der Anzahl der GWs auf das Netz an sich zu tun. Dafür gibt es den Mit verknüpftem Thema antworten Button.