folgendes Setting, wir könnten auf den Knoten ein Limit von 5 einrichten zu 5 distinkten Maschine im Netz (also Supernodes, wobei da auch Gruppen drunter sind mit limit 1) …
Frage1: was bedeutet es für die Knoten/Router wenn die 4 fastd Tunnel auf haben zu supernodeXY …
das ganze Batman-Grundrauschen geht dann von und zu allen Supernodes durch alle 4 Tunnel oder nur den gewählten GW (batctl gwl)
Frage2: was bedeutet das für die untereinander verbundenen Supernodes, macht es einen Unterschied für die ob die 300 Knoten über nur einen fastd tunnel haben oder über 2.3.4.5 ? multiplitziert sich da deren Grundrauschen ?
Frage3: wie genau würde ich das Grundrauschen am besten messen? am Knoten und am Supernode.
naiv_und_kurz: lieber viele fastd tunnel zu distinkten Maschinen (also nicht 2 Supernodes als 2 Vm auf einem Server) oder lieber nur 1 fastd und wenn der stirbt dann wechseln …
Hallo,
die Erfahrung zeigt dass der negative auf die Knoten massiv ist. Die Layer 2 Routing Tabelle von Batman steigt exponentiell an, da durch mehrfach Verbindungen im Netz enorm viel alternative Routen zur Verfügung stehen.
All diese Möglichkeiten müssen dauerhaft getestet und bewertet werden.
das gibt es bei Tunneldigger nicht, du kannst dem meherere „Gegenstellen“ mitteilen, aber er baut immer nur eine Verbindung zu einer auf. Die Frage stellt sich bei L2TP/Tunneldigger also nicht.
[quote=„chrisno, post:5, topic:10280“]
u kannst dem meherere "Gegenstellen
[/quote] das gilt für FastD genauso … kenn den tunneldigger Spass nicht, wenn du mir eine gute Doku mit Gluonbezug hast, schau ich mir das gerne an. Oder vieleicht sogar etwas das fastd und tunneldigger miteinander vergleicht
[quote=„MrMM, post:2, topic:10280“]
Sieh dir zum Start mal dieses Thema an:
[/quote]Danke dafür … so richtig ganz schlau bin ich aus den Begründungen nicht geworden. Will das ja glauben … daher die Fragen nochmal spezifischer
A. mehr fastd verbindungen pro Knoten bedeuten je mehr incoming broadcast * Anzahl der fastd tunnel
B. gleiches gilt auf dem Knoten für Outgoing ? bzw. weiter: leitet Fastd den gesamten udp broadcast traffic an alle seine real verbundenen tunnel?
C. weil die Pakete zu den Knoten dann viele Wege gehen können werden auch viele Pakete geschickt - zwischen den supernodes …
D. wenn ein sn hinter einem fstd nicht so wirklich verkackt - dann würde der auch nicht weg-wechseln. Das heisst man ist stark an die eigene Fähigkeit der SN Selbstdiagnose zu betreiben gebunden
und korrektur, des verlinkten Artikels … batman korrigiert innerhalb von 5 Sekunden seine Route. (so jedenfalls mit spielereien hier festgestellt)
ich scheine da so einne knoten im Hirn zu haben, der sich nicht so recht lösen will beim verstehen des Problems welcher Traffic eigtl genau hier ärger macht. Sind es es diese Batman ogm udp pakete ? Kann das nicht jemand in Sendung-mit-der-Maus-manier erklären … ich mein, mein Ansatz wäre - wenn ich das nicht kann, weis ich das ich selbst was nicht begriffen hab.
in konsequenz wird es darum gehen die fastd tunnel zu minimieren, evtl sogar die tunnel der sn untereinander …
(mit dem neuen Batman wird diese udp anouncen schleudern massiv besser - so jedenfalls mein verständnis vom mitlesen des batman-dev mailinglists das explodiert die letzten wochen)
Da gibt es hier im Forum reichlich zu, einfach mal nach suchen. Wenn du in die Richtung tatsächlich Bedarf hast und Hilfe bei der Einrichtung für einen Test etc. brauchst, kannst du mich gerne anschreiben. Dann können wir das mal zusammen machen.
Es wird defacto kein zweiter (oder mehr) tunnel aufgebaut. es ist wirklich immer nur >1< Tunnel verbunden. Der nächste wird erst aufgebaut, wenn der vorherige weg bricht/ nicht erreichbar ist/ whatever.
genau das macht doch fastd mit limit 1 auch. das checkt regelmässig nur noch ob andere eingetragene Supernodes da sind (handshake) - ein auth oder connect gibt es nicht. Entsprechend erwarte ich darüber hinaus auch absolut keinen Traffic.
Das einzige was ich mir denken kann, ist das die Auswahl welcher idealerweise Tunnel aufgemacht wird in dem einen oder anderen Fall „intelligenter“ ist. (man will nicht alle Knoten 1.2.3.4 die liste durchgehen lassen, eher random connect)
zum Verständnis: die l2tp tunneldigger variante ist komplett unverschlüsselt und ohne authentifizierung? soweit ich das jetzt rein gelesen hab.
Für mich bedeutet das aus euren Antworten bisher : ja reduziere die Tunnel in jedem Fall - ob tunneldigger/l2tp oder fastd is da nicht wirklich relevant - zumindest seh ich das noch nicht.
Nur zu meinem Verständis: Das ganze Batman und die dahinterliegenen udp OGM Pakete und so berühren wir hier garnicht weiter - es geht darum multiple routen zu dem selben Ziel rauszunehmen - weil das mit dem Batman wie wir es kennen nicht besonders gut nach oben hin skaliert?! (erwähnte das da auf der batman dev list viel passiert in den letzten 2 Monaten : hier die Einführung eines neuen Pakettyps um nicht immer die linkquality im GANZEN netz zu spreaden git.open-mesh.org Git - batman-adv.git/commit )
Es empfiehlt sich also fastd so zu betreiben, dass nur ein Tunnel zur Zeit aufgebaut ist. Ansonsten unnötig hohe Last auf DSL-Anschluss und Gateway/Supernode
Wenn dem also so ist, warum will man dann überhaupt mehr wie eine Verbindung offen haben, die aktuellen Beschreibungen auf freifunk#gluon legen das implizit nahe das zu tun. Daher kamen wir auf die Gruppeirung unserer Supernodes zu Gruppen per Rootserver und Externe und je 1 Verbindung dorthin. Das ja bis auf maximal ausfallsicher dann eine sehr ungünstige Wahl wenn das Netz größer wird.
da ist ein limit von 2 mal vorgegeben, wen man dann dem Beispiel von gruppen und nestet gruppen folgt, bekommt man für jede nochmal ein limit von 1 dazu (sonst machen die Gruppen ja keinen Sinn)
keine Worte der Warnung - für mich machen nach dem oben geschriebenem nur mehrere Fastd Sinn wenn die jeweils einzelne geschlossen batman clouds am anderen Ende haben. Dann kennen die Knoten immer alle Verbindungen aber die Supernodes nicht - die kennen dann nur ihre Spezis (vorrausgesetzt das forward an der Stelle is ausgestellt)
Die Supernodes waren in der Vergangenheit durch batman kernel panic sehr unstabil.
Da nicht überall ein schneller reboot erfolgte konnte man so längere Downtimes vermeiden.
Meiner Ansicht nach ist die Einstellung >1 also historischer Natur. Damals waren auch die Netze noch sehr überschaubar, da haben die zusätzlichen Tunnel nicht gestört.
ein Effekt wurde noch nicht beschrieben, wenn die SN kein Limit kennt - aber aufgrund ihrer Geschwindigkeit sehr schnell reagiert wird diese fast alle Router an sich ziehen.
fastd verbindungen sind extrem stabil, überstehen DSL reconnects ohne Probleme. Wir haben hier ettliche fastd Verbindungen von über einer Woche.
das führt also dazu das Knoten auch mit theoretischen alternativen (bei limit=1) nur schwer bis garnicht von der supernode/fastdserver weg kommen. das muss dieser irgendwie clever lösen durch
nicht zu viele clients anzunehmen
sein monatiliche Trafficlimit zu haushalten
ggf. bei mieser internetverbindung fastd verbindungen zu canceln
Ein Limit gleich 1 kann da schnell nach hinten losgehen. Zwar sieht Batman durch die Tunnel noch andere GW … aber der Traffic würde immer durch diese Supernode gehen
(Supernode is oft gleich Gateway - is bei uns so)
… ich mein, mein Ansatz wäre - wenn ich das nicht kann, weis ich das ich selbst was nicht begriffen hab.