Nochmals eine Frage zu einem Effekt, zu den ich auch noch nichts greifbares hier oder per Google finden konnte.
Wir setzen batman-adv-14 mit alfred.2014.3 auf unseren Gateways ein, in der site.mk von Gluon 2016.1 wurde das Paket gluon-mesh-batman-adv-14 für die Nodes ausgewählt.
Seit der Umstellung der Knoten auf die neue Firmware scheinen ab und zu einige Knoten laut Alfred mal für ein paar Minuten offline zu gehen, allerdings nur auf der Map. Die Geräte selber laufen durch und haben ihre Verbindung noch.
Die „Aussetzer“ kann man gut im Graphen der Arbeitsspeicher-Belegung der Nodes sehen, hier ein Beispiel:
Alfred liegt unter /usr/sbin/ und wird ueber einen Aufruf in der /etc/network/interfaces auf dem Gateway gestartet. Eine grundlegende Config fuer alfred finde ich nicht, so dass Parameter wohl nur ueber diesen Aufruf uebergeben werden. Ist diese besagte Einstellung jetzt fest in die Executable einkompiliert so dass ich neu kompilieren muss oder geht das auch anders?
Ok, dann waere das schon mal ein Ansatz. Weiss denn jemand, was der Grund fuer das Problem ist und ob da ein Fix geplant ist? Das Problem scheinen ja mehrere Communties zu haben.
Alfred wird es in nächsten (Haupt-)gluon-Release vermutlich nicht mehr geben, ist also sowieso nur ein Auslaufmodell.
Wer Probleme mit Gluon hat, der sollte als Lösung besser gleich den den Announced benutzen, das macht auch nur einmal Arbeit.
Also Announced hat bei uns in Tests nicht besser abgeschnitten, es sorgt sogar teils für noch mehr Traffic und oft kommen Metriken noch seltener an als in Alfred.
Wer Probleme mit Alfred hat das die „letzten Bits“ nicht ankommen, sollte Alfred mit einem Mac-Vlan Interface und geringerer MTU betreiben.
Alfred hat das Problem das es manchmal Pakete verwirft wenn diese fragmentiert ankommen.
Wir überlegen noch ob wir Metriken ala „prometheus-style“ via HTTP anbieten anstatt alfred bzw announced zu nutzen. Die Node würde sich dann einmalig via curl call an der Map anmelden und von da aus einfach alle 5 Minuten abgefragt wird.
Allerdings wird dann wohl die ursprüngliche Map nicht mehr klappen, die Topologiedaten werden ja auch via Alfred/Announced übertragen.
UDP ist so lange effektiv, wie es keinen/kaum Packetloss gibt, insbesondere bei Broadcast/Multicast.
Das mit Announced vorgesehene (und beim Node-Informant leider nicht wirklich funktionierend implementierte) Verfahren ist, bei (mehrfach) ausbleibenden Daten direkt bei den „vermissten“ Knoten die Daten zu pullen.
Angedachter Ansatz ist, den 1001er-Broadcast nur nur noch für „Discovery“ zu nutzen. (Und neue Nodes nach dem Boot ebenfalls ein paar Mal broadcasten zu lassen, damit es fixer geht.
Und ab „Knoten gelernt“ nur noch mit unicast zu arbeiten, nach dem Motto „Knoten Online ist häufiger als Knoten offline“. (kann man ja auch einstellen, sobald ein Knoten als Offline erkannt und vielleicht nochmal die doppelte Zeit verstrichen ist.)
Aber das hat jetzt weniger mit dem konkreten Alfred zu tun.
Faktisch ist es für mich, dass meshviewer zu Knoten, die per Alfred sich nicht melden, sagt „offline“ ist für viele Nutzende schlicht irreführend.
Richtig, Alfred nutzt auch UDP aber kommt damit anscheinend besser klar.
Ich nehme an das es daran liegt das es zwischen den Supernodes noch merged und wenn ich das richtig gelesen habe mittels Transaktion arbeitet.
Broadcast wollen wir halt komplett vermeiden für sowas, es gibt fest konfigurierte Fastd/L2TP Server… Da fällt ein zusätzlicher Eintrag für die Map nicht ins Gewicht und macht das ganze auch nicht unbedingt „dezentraler“
Lieber eine solide Unicast Umsetzung als weiterhin Broadcast zu verwenden wo wir doch schon so viel davon filtern.
Mir ist jetzt nicht klar, worauf Deine Einschränkungen abziehen. (Fettung durch mich)
a) es gibt nicht einen, sonder zwei Ansätze.
b) Einer davon benutzt aber nicht den Meshviewer, sondern einen Fork davon
c) Eventuell sind jedoch beide Deiner Definition nach nicht „sauber genug“.
