Wir haben mit Gluon 2015.1 unsere Knoten so konfiguriert dass stets je einem Tunnel zu einem unserer Rechenzentrums Standorte aufbauen.
Seltsamerweise haben daraufhin die gut 3/4 der Knoten das Rechenzentrum mit der schwächeren Hardware als Gateway ausgewählt. Möglicherweise weil dieses Rechenzentrum die kürzeren Routen zu den Typischen DSL Anbietern hat.
Um dem gegenzusteuern habe ich nun die Hop Penalty auf den schwächeren Supernodes erhöht.
Siehe da mit einiger Verzögerung hat sich das in etwa das gewünschte Ergebnis eingestellt, wobei meine Werte wohl etwas zu extrem gewählt sind:
Ja, das gefällt mir aber nicht wirklich, wir haben hier etliche DSL Anschlüsse die im Rechenzentrum von Node 3&4 ihren Übergabepunkt haben, diese sollten nach Möglichkeit auch einen vpn Tunnel zu diesen Supernodes haben und dann hoffentlich auch trotz Penalty diesen auswählen.
Der @tcatm hat dazu was in der der Gluon Mailingliste geschrieben:
Die Hoppenalty begrenzt auch den Durchmesser es Meshes (als Graphen), denn sobald die Penalty 255 erreicht, sind die Knoten nicht mehr erreichbar. So könnte ein Mesh in disjunkte Teilnetze zerfallen.
Bei einer Hoppenalty von 30 (IIRC batman default) ist der Durchmesser auf ca. 8 Knoten begrenzt.
Bei 15 (Gluon default) sind es 17 Knoten Durchmesser.
Wenn man nun einen (oder gar zwei!) Gateways mit einer Penalty von 100 auf dem Weg hat, bleiben auf beiden Seiten der Gateways nur Restradien von 1 bis 2 Knoten übrig. Knoten die dann mehr als 2 Hops vom Gateway entfernt sind, könnten keine anderen Knoten, die auch mehr als 2 Hops entfernt sind erreichen.
batman-adv ist leider für solche VPN lastigen Netze wie wir sie bauen derzeit nur mäßig geeignet. In den meisten Fällen kann es dann keinen optimalen Pfad mehr finden.
