das gleiche Problem gab es im September, als ein Node zur Bridge zwischen Ruhrgebiet und Rheinufer wurde:
Daher denke ich, dass ein automatischer Mechanismus, der solche Fälle erkennt und unterbindet, sehr wichtig für die Stabilität der Netze ist.
Ich glaube, es kann keiner mit Sicherheit sagen, dass es der Node Gemen die Ursache aller Störungen in Gelsenkirchen war. Ihr habt Störungen, die unterschiedlicher Natur sind, daher tippe ich mal darauf, dass ein Teil der Störungen daher kam. Einfach weiter beobachten…
Wenn ich das gewusst hätte, hätte ich den uplink nach Münster und diesen Gemen sofort gemeldet.
Aber - man (ich) traut sich ja schon gar nicht mehr hier was zu schreiben… (ist übrigens nur teilweise ironisch gemein, aber ich will hier kein neues Fass aufmachen)
Nachtrag:
Ich gehe davon aus, dass das hier gesehen und als ungefährlich eingestuft wurde - frei von Störeinflüssen?
Ich habe hierfür auf unseren Gateways ein Nagios Plugin implementiert … aktuell wird zwar zur die Anzahl der Gateways geprüft aber für einen Hinweis reicht es ja schon mal.
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 ?
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?
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?
(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.)
