<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2014-10-06 um 15:24 schrieb Stefan Schultheis (home):<br>
</div>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<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>
</div>
</div>
</div>
</blockquote>
Das ist wohl des Pudels Kern.<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<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"> 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>
</blockquote>
IF oder IP? ;-)<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</div>
</div>
</blockquote>
An sich ist das richtig. Allerdings passiert das aufgrund der
Dynamik etwas zeitversetzt.<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><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>
</div>
</blockquote>
Stimmt. Darum empfahl ich ja das per-Interface-Default-LQMultiplying
anstelle des per IP-LQMulten.<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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. </div>
</div>
</div>
</div>
</blockquote>
Dann trage für die bestehenden einfach erst einmal 1.0 ein. Das
sollte sich einfach aus der Routingtabelle skripten lassen.<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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 wi, htigen 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!</div>
</div>
</div>
</div>
</blockquote>
Prozentzahlen sind kein direktes Indiz für das, was wir hier
besprechen und vorhaben, oder?<br>
...obwohl das sicher ein toller Erfolg ist.<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</div>
</div>
</blockquote>
Das es keine offzielle AirOS-Version ist und auch kein vollwertiges
OpenWRT-Derivat - nachdem was Bernhard mir von der PHP-Version
darauf erzählt, stufe ich das als Hack ein.<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
Das ist eine tolle Arbeit, die sich bei mir auf > 30
Geräten als schneller und stabiler als OpenWRT gezeigt
hat, </div>
</div>
</div>
</div>
</blockquote>
warum wohl: das Ding macht Packet Aggregation auf hohem Niveau und
hat einen stabilen Treiber.<br>
Da hat übrigens OpenWRT nachgelegt.<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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>
</div>
</div>
</div>
</div>
</blockquote>
Es ist eine Herstellerlösung mit definiertem Use Case, der hier
"aufgebohrt" wurde.<br>
OpenWRT zwar den Anspruch erweiterbar zu sein, das UI der LuCI
verfolgt aber ebenfalls den Anspruch der Einfachheit, wobei wichtige
Funktionen leider unkonfigurierbar sind.<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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"> 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>
</div>
</div>
</blockquote>
Auf der Krypta-Bridge zur Zeltgasse geht es mir leider auch ab...
@Markus?<br>
<blockquote
cite="mid:CAHanXmGJ=zz5bYeg9=yP-6866YmW1m1BZ1LF62ErRopCgdjKgg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</div>
</blockquote>
<br>
LG<br>
Erich<br>
<br>
</body>
</html>