<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 13:55 schrieb Wolfgang:<br>
</div>
<blockquote
cite="mid:E581EFCE-ADD5-4ECD-A584-B115D3043CBB@medicaldb.net"
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>
(Dezentrale) Tunnel im Mesh-Netz sind generell ein Problem beim
Mesh-Routing.<br>
Es gibt aber im Rollout-Prozess dafür keine reellen Alternativen.<br>
<blockquote
cite="mid:E581EFCE-ADD5-4ECD-A584-B115D3043CBB@medicaldb.net"
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>
?<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.<br>
<blockquote
cite="mid:E581EFCE-ADD5-4ECD-A584-B115D3043CBB@medicaldb.net"
type="cite">
<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. </blockquote>
Ja, beim bidirektionalen Datenverkehr sollte man stets beide Seiten
im Auge haben ;-)<br>
<blockquote
cite="mid:E581EFCE-ADD5-4ECD-A584-B115D3043CBB@medicaldb.net"
type="cite">Damit würde der Tunnel automatisch in den Hintergrund
<br>
treten, sobald eine native route besteht.<br>
</blockquote>
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.<br>
<blockquote
cite="mid:E581EFCE-ADD5-4ECD-A584-B115D3043CBB@medicaldb.net"
type="cite">
Und auf native Routen wollen wir doch letztendlich hinaus...<br>
Was meint Ihr?<br>
</blockquote>
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>
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>
<br>
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>
<br>
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
cite="mid:E581EFCE-ADD5-4ECD-A584-B115D3043CBB@medicaldb.net"
type="cite">
<br>
LG Wolfgang<br>
<br>
</blockquote>
LG<br>
Erich<br>
<blockquote
cite="mid:E581EFCE-ADD5-4ECD-A584-B115D3043CBB@medicaldb.net"
type="cite">
<br>
On 05/10/14 11:33, Wolfgang wrote:<br>
> Danke,<br>
> das war die Lösung!<br>
> <ipv6 adresse> 0.2 bringt den gewünschten Erfolg.<br>
> LG Wolfgang<br>
><br>
><br>
> Am 05. Oktober 2014 09:46:51 MESZ, schrieb "Stefan Schultheis
(home)" <br>
> <a class="moz-txt-link-rfc2396E" href="mailto:stefan@schultheis.at"><stefan@schultheis.at></a>:<br>
><br>
> Hallo Wolfgang,<br>
><br>
> manche Einstellungen erfordern einen Reboot. Explizit kenne
ich<br>
> das vom lqmult. Mit einem Reboot sollte die Einstellung dann<br>
> wunschgemäß übernommen werden.<br>
><br>
> LgS<br>
><br>
><br>
> Am 5. Oktober 2014 09:37 schrieb Wolfgang
<<a class="moz-txt-link-abbreviated" href="mailto:0xff@medicaldb.net">0xff@medicaldb.net</a><br>
> <a class="moz-txt-link-rfc2396E" href="mailto:0xff@medicaldb.net"><mailto:0xff@medicaldb.net></a>>:<br>
><br>
> Guten Morgen Alle,<br>
> ich habe folgende Frage:<br>
> im Moment wird ipv6 an einigen Tunnelendpunkten ins Netz<br>
> geroutet, in meinem Fall ozw und duer9. Nun geht eine der<br>
> Verbindungen wesentlich besser, was der olsrd4 auch richtig<br>
> abbildet. Dummerweise bevorzugt der olsrd6 aber die andere<br>
> route als default, da deren tunnelendpunkt näher liegt (der<br>
> Tunnel selbst läuft aber über eine wesentlich längere
Strecke).<br>
> Meine Überlegung war, das über den LQ-Multiplikator<br>
> anzupassen. Ist das korrekt? Ich hatte einmal probeweise die<br>
> v6-Adresse der schlechteren Route eingetragen, gefolgt von<br>
> einem Multiplikator 0.5, hat jedoch nicht den gewünschten<br>
> Erfolg gezeigt. Firmware ist 0xff AirOS 5.5.8.<br>
> Weiß jemand eine Lösung für das o.g. Problem?<br>
> LG Wolfgang<br>
> _______________________________________________<br>
> IPv6-wien mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:IPv6-wien@lists.funkfeuer.at">IPv6-wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-rfc2396E" href="mailto:IPv6-wien@lists.funkfeuer.at"><mailto:IPv6-wien@lists.funkfeuer.at></a><br>
> <a moz-do-not-send="true"
href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> IPv6-wien mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:IPv6-wien@lists.funkfeuer.at">IPv6-wien@lists.funkfeuer.at</a><br>
> <a moz-do-not-send="true"
href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a><br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
IPv6-wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPv6-wien@lists.funkfeuer.at">IPv6-wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien">https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien</a>
</pre>
</blockquote>
<br>
</body>
</html>