<div dir="ltr">Hallo,<br><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">
<div text="#000000" bgcolor="#FFFFFF">
<span class="">
<blockquote type="cite">Bezgl der Tunnellösung generell:<br>
Das beschriebene Problem tritt sicherlich immer wieder auf und je
mehr <br>
v6-Tunnel existieren, desto mehr wird das v6-routing verzerrt.<br>
</blockquote></span>
(Dezentrale) Tunnel im Mesh-Netz sind generell ein Problem beim
Mesh-Routing.<br>
Es gibt aber im Rollout-Prozess dafür keine reellen Alternativen.<span class=""><br></span></div></blockquote><div>Ich würde mich sehr freuen, wenn wir native Uplinks bekommen. Bisher wurde mein Wunsch leider von den Personen, die das umsetzen könnten, nicht aufgenommen.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class="">
<blockquote type="cite">
Meine Lösung, die v6-Route an einem meiner Router zu pönalisieren
ist <br>
wohl nur eine Behelfslösung, da sie auch native Routen zu Nachbarn
<br>
unnötig benachteiligt.<br>
</blockquote></span>
?<br>
OLSR beherrscht die Möglichkeit LQMults nur per Interface zu setzen,
oder eben global.<br>
Wenn Du also nur Dein sit0-olsrd6-Interface aus den genannten
Gründen pönalisieren möchtest, so ist das grundsätzlich möglich.<br>
Ebenso besteht die Möglichkeit eines default-LQMults für ein ganzes
Interface, sodass Du nur bevorzugten Strecken einen LQMult von 1.0
zuweist.<br>
Das ist zwar Alles nicht wirklich schön, aber wirksam.<span class=""><br></span></div></blockquote><div>Stimmt. LQmult über Nachbar-IP sollte die Lösung sein!<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class="">
<blockquote type="cite">
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. </blockquote></span>
Ja, beim bidirektionalen Datenverkehr sollte man stets beide Seiten
im Auge haben ;-)<span class=""><br></span></div></blockquote><div>Macht OLSR eigentlich eh korrekt, da sich der ETX aus LQ & NLQ ergibt und in beide Richtungen wirkt.<br><br></div><div>Ich glaube Wolfgang meint, dass der lqmult schon am Tunnelserver für alle Endpunkte eingetragen sein sollte, damit den Admins der Endpunkte ein Arbeitsschritt erspart bleibt.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class="">
<blockquote type="cite">Damit würde der Tunnel automatisch in den Hintergrund
<br>
treten, sobald eine native route besteht.<br>
</blockquote></span>
Wer immer einen Tunnel-Endpoint/Router auf v6-Basis betreibt täte
gut daran, einen Default-LQMult per Interface auf das
Tunnelinterface zu setzen - aber mit Ausnahmen:<br>
Ein Problem sind dabei instabile Funklinks beim Peer. Das hätte
nämlich permanentes Flapping zur Folge.<span class=""><br></span></div></blockquote><div>Ich glaube auch, dass ein generelles lqmult auf 0.2 am Tunnelserver technisch ein guter Vorschlag ist. Ich würde aber ungern alle bestehenden Links einfach ändern. In Zukunft werde ich das berücksichtigen und mit den 6in4-Standortbetreibern ansprechen.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class="">
<blockquote type="cite">
Und auf native Routen wollen wir doch letztendlich hinaus...<br>
Was meint Ihr?<br>
</blockquote></span>
Ich meine, dass IPv6 langsam einmal nativ auf allen wichtigen
5Ghz-Strecken (ich vermeide jetzt absichtlich das Wort "Freebone"
oder "Backbone" ) Einzug halten sollte.<br></div></blockquote><div>Da hat sich einiges getan. Wenn ich nur die Anzahl der Prefixe ("Routen") in OLSRv4 mit v6 vergleiche, sind wir mittlerweile auf > 24%. Das heißt (rein von der Statistik), dass bereits ein Viertel des Netzes IPv6 auf den Links unterstützt!<br></div><div><br></div><div>Ich lege euch eine aktuelle Statistik bei, die ich seit Anfang des IPv6-Vorhabens führe!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Ein Showstopper kann dabei wieder einmal die Firmware sein. Die
kommenden OpenWRT-Versionen haben leider in LuCI immer noch eine
mittlerweile in olsrd als "deprecated" gekennzeichnete
Funktionsweise: "6and4". Prinzipiell funktionieren beide Arten noch,
aber watchdog und Info-Seiten funktionieren damit nicht wie
beabsichtigt - und mit der richtigen Umsetzung laufen zwar die
Dienste korrekt, aber die Info-Seiten bleiben leer oder zeigen nur
ein Protokoll an...<br>
<br>
Wie das mit den aktuellen AirOS-Hacks gelöst ist, entzieht sich
mangels Zeit und Testhardware meiner Kenntnis.<br></div></blockquote><div>Ich würde die 0xFF-AirOS-Version nicht als mehr als "Hack" bezeichnen.<br><br>Das ist eine tolle Arbeit, die sich bei mir auf > 30 Geräten als schneller und stabiler als OpenWRT gezeigt hat, einfacher in der Bedienung (Web Interface) ist aber halt genau das kann was sie soll und nicht durch Pakete erweiterbar ist (zB. eben für 6in4, OpenVPN/Tunnel, uvm.).<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Ein Weg, die Machbarkeit herauszufinden, wäre es, dass jeder
Knotenbetreiber, der nativ über IPv6 verfügt, die Betreiber seiner
Nachbarknoten anschreibt und seine Hilfe bei der Umsetzung anbietet.
Auf diese Weise würde, wenn es richtig gemacht wird und im der
Verein eine Art 2nd-level-Support für dabei auftretende Probleme
organisieren kann, die Umsetzung einerseits vorangetrieben und
andererseits das Know-How weitergegeben, da jeder Betreiber, der
seinen Knoten im Grunde selbst administriert, irgendwann sowohl
Supportwerber als auch als Supporter auftreten würde.<br></div></blockquote><div>Das machen wir auch genau so. Aber stimmt: es könnten mehr sein ;)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Ziel sollte es meiner Ansicht nach sein, mittelfristig auf
Single-Stack-OLSRv2 via IPv6 umzusteigen. Wenn es nach mir ginge:
link-local/64 (besser /128) mit HNAs der externen Ranges und mit
Nat64 für v4-only-Geräte. Aber soweit sind die Firmwares noch nicht
und es passt mit dem aktuellen Rollout-Konzept nicht zusammen.<br>
<blockquote type="cite">
<br>
LG Wolfgang<br>
<br>
</blockquote>
LG<span class="HOEnZb"><font color="#888888"><br>
Erich</font></span></div></blockquote>LgS<br><br></div></div></div>