<div dir="ltr">Hallo,<br><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">
>> OLSR beherrscht die Möglichkeit LQMults nur per Interface zu setzen,<br>
>oder<br>
>> eben global.<br>
>> Wenn Du also nur Dein sit0-olsrd6-Interface aus den genannten Gründen<br>
>> pönalisieren möchtest, so ist das grundsätzlich möglich.<br>
>> Ebenso besteht die Möglichkeit eines default-LQMults für ein ganzes<br>
>> Interface, sodass Du nur bevorzugten Strecken einen LQMult von 1.0<br>
>zuweist.<br>
>> Das ist zwar Alles nicht wirklich schön, aber wirksam.<br>
>><br>
>Stimmt. LQmult über Nachbar-IP sollte die Lösung sein!<br>
><br>
><br>
>>  M.E. müsste man die Pönalisierung für die Tunneladresse auf dem<br>
>> Tunnel-Router selbst anpassen, und zwar in Abhängigkeit der Anbindung<br>
>> des Tunnels.<br>
</span>Damit war gemeint: Die Anzahl der hops /latenz /etc. sollte in den LQ-mult eingehen, sprich, der Tunnel am duer9 ist sehr nahe an der idealen Nativroute und braucht eine nicht so hohe Pönale, wie z.B. der Tunnel am OZW.<br></blockquote><div>OK, das ist aber wesentlich mehr Aufwand, falls das am Tunnelserver passieren sollte. Außerdem verändert sich das Mesh-Netzwerk doch öfters und man müsste die Änderungen am Tunnelserver nachziehen...<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">>Ich glaube Wolfgang meint, dass der lqmult schon am Tunnelserver für<br>
>alle<br>
>Endpunkte eingetragen sein sollte, damit den Admins der Endpunkte ein<br>
>Arbeitsschritt erspart bleibt.<br>
<br>
</span>Das hatte ich auch kurz überlegt, aber letztendlich löst dies nicht das o.g. Problem. Denn wenn bsp. der Tunnel an duer9 genauso pönalisiert wird, wie der am ozw, wird zB. trt6 wieder den ozw tunnel bevorzugen, obwohl die Tunnel- (v4)Pakete dann insgesamt den längeren Weg gehen müssen. Also erscheint mir eine individuelle Konfiguration derzeit am sinnvollsten.<br></blockquote><div>Da gebe ich dir recht. Ich vergleiche es mit den OpenVPN-Tunneln. Dort ist es auch so, dass der jeweilige Tunnelendpunkt den lqmult anpasst.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">>> Ich meine, dass IPv6 langsam einmal nativ auf allen wichtigen<br>
>> 5Ghz-Strecken (ich vermeide jetzt absichtlich das Wort "Freebone"<br>
>oder<br>
>> "Backbone" ) Einzug halten sollte.<br>
>><br>
</span>Nur zum Verständnis: Warum läuft v6 zwischen subway und duer9 eigentlich über tunnel statt nativ?<br></blockquote><div>Weil zwischen Subway (Server im Keller) und duer9 noch die Devices am Dach sind (kryptaroof), die kein IPv6 unterstützen... :( Wir "scheitern" nur mehr an dem 1 Hop!<br></div><div>Das wäre auch aus meiner Sicht der dringendste Punkt, um IPv6 hinzubekommen. Leider ist bisher niemand von den Node-Betreibern bereits gewesen, das anzugreifen... Vielleicht lässt sich durch deine Anregung jemand motivieren!?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">

</div></div>Dem möchte ich mich voll anschließen! Die 0xff AirOS FW ist an meinem Standort vollkommen stabil. Bei großem Respekt für die in bubbles hineingesteckte Arbeit, AirOS kann alles, was ich derzeit auf meinen ubiquiti devices brauche und bietet interessanterweise auch noch höhere link speeds, warum auch immer.<br>
Und keine Abstürze mehr.<br></blockquote><div>Ich glaube, dass sich die beiden gut ergänzen: Bubbles hat sehr viele Funktionen, das wird es bei AirOS in der Form nicht geben. Dafür hat man dort mehr Stabilität. Die Basisfunktionen für's Funkfeuer-Netz können beide Devices...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">
</span>LG Wolfgang<br></blockquote><div>LgS<br></div><br></div></div></div></div>