Wir hätten für eine automatisierte Lösung nun auch endlich die fastd Daten zur Verfügung…
Da kommt pro verbundener Node / Client dann dieser Datensatz raus:
Naja … solange die Server die gleichen werte haben sollte es ja bei einer Gleichverteilung bleiben.
Aber ja, der 100 MBit Server wird dadurch unterpriorisiert.
Wonach habt Ihr die Werte festgelegt ?
Habt ihr einfach einen einheitlichen Wert auf allen Servern gesetzt oder nehmt ihr hier messbare Kriterien als Basis ?
Greetz,
VOID
Ich vermute die meisten setzen pauschal 96/96 einfach so.
Im Ruhrgebiet haben wir die derzeitige Maximallast genommen 48/48.
Aber wie Du schon sagst, spielt im Grunde keine Rolle solange der Wert identisch ist…
Ja die hab ich mir auch schon angesehen … da lässt sich noch einiges an Infos herausholen 
Hab halt nur die Scripte dafür noch nicht fertig.
Da ist zwischendurch so ein Arbeiten-Ding …
VOID
Aber wenn doch in der neuen FW beim flashen neue Supernodes enthalten sind (in der site.conf, nehme ich an), warum bleiben die alten dann erhalten?
Wenn da immer nur dazuaddiert wird: Würde das nicht im Umkehrschluss bedeuten, dass ein „alter Router“, der innerhalb einer Domain immer wieder geupdated wird (und wo in der Domain die Supernodes über die Monate/Jahre wechseln inkl. ihrer Namen), immernoch versucht wird, längst verblichene Eisen zu konnektieren?
Oder anders gefragt: Wenn es neue backbone-peers für’s fastd_mesh_vpn gibt beim Sysupgrade, warum fliegen dann die alten bei sysupgrade nicht raus? Wäre das nicht die Stelle an der man ansetzen könnte/sollte?
naja, ist doch logisch:
Im Ruhrgebiet werden fastd.mesh_vpn_backbone_peer_ruhrgebiet0…3 definiert. Die Namen und Keys in den Definitionen können ausgetauscht werden, dann werden alte durch neue überschrieben.
Im Rheinufer werden entsprechend fastd.mesh_vpn_backbone_peer_rheinufer0…3 definiert.
Wie die Peers in Münster heißen, weiß ich nicht, aber sie werden der Form fastd.mesh_vpn_backbone_peer_xyz0…3 definiert sein.
Werden die Configs überbügelt, dann addieren sich die Definitionen, die unterschiedlich heißen, weil alte Definitionen nicht gelöscht werden.
E gibt dann z.B. fastd.mesh_vpn_backbone_peer_ruhrgebiet0…3 und fastd.mesh_vpn_backbone_peer_rheinufer0…3
Klingt doch einleuchtend, oder?
Dann mache ich mal die Ingrid:
Ich erfahre gerade vom Neoraider:
das ist nen Bug, der seit 2014.3.1 behoben ist"
Vielleicht mal eine direkter Anschub an diverse Communities, keine 2014.3(.0) (aka ffrg.0.5stable" ) mehr zu verteilen…
Das könnte man doch übergehen wenn bei einen update immer alle Supernodes gelöscht und neu hinzugefügt werden.
Ich habe es zumindest so verstanden, dass genau das seit Gluon-2014.3.1 genau so gemacht wird.
Solange keine neuere Stable released ist, bleibt uns nichts anderes übrig. Ich werde keine Beta- oder Experimental-Versionen verteilen.
Genau das ist ja das „Problem“: Gluon 2014.3.1. wurde am 20. Oktober released
(Also kein Experimanl-Master oder Beta. Nur müssen die natürlich in den Domains auch noch den Compiler und qualifiziert werden. Das kann man dann natürlich als „experimentell“ bezeichnen. Ich hoffe schlicht, dass daran gearbeitet wird und dass das noch dieses Jahr Ergebnisse bringt.)