[IPv6-wien] link quality / route bevorzugen

Erich N. Pekarek (spam-protected)
Mon Oct 6 14:42:49 CEST 2014


Hallo!

Am 2014-10-06 um 13:55 schrieb Wolfgang:
> Bezgl der Tunnellösung generell:
> Das beschriebene Problem tritt sicherlich immer wieder auf und je mehr
> v6-Tunnel existieren, desto mehr wird das v6-routing verzerrt.
(Dezentrale) Tunnel im Mesh-Netz sind generell ein Problem beim 
Mesh-Routing.
Es gibt aber im Rollout-Prozess dafür keine reellen Alternativen.
> Meine Lösung, die v6-Route an einem meiner Router zu pönalisieren ist
> wohl nur eine Behelfslösung, da sie auch native Routen zu Nachbarn
> unnötig benachteiligt.
?
OLSR beherrscht die Möglichkeit LQMults nur per Interface zu setzen, 
oder eben global.
Wenn Du also nur Dein sit0-olsrd6-Interface aus den genannten Gründen 
pönalisieren möchtest, so ist das grundsätzlich möglich.
Ebenso besteht die Möglichkeit eines default-LQMults für ein ganzes 
Interface, sodass Du nur bevorzugten Strecken einen LQMult von 1.0 zuweist.
Das ist zwar Alles nicht wirklich schön, aber wirksam.
>
> M.E. müsste man die Pönalisierung für die Tunneladresse auf dem
> Tunnel-Router selbst anpassen, und zwar in Abhängigkeit der Anbindung
> des Tunnels. 
Ja, beim bidirektionalen Datenverkehr sollte man stets beide Seiten im 
Auge haben ;-)
> Damit würde der Tunnel automatisch in den Hintergrund
> treten, sobald eine native route besteht.
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:
Ein Problem sind dabei instabile Funklinks beim Peer. Das hätte nämlich 
permanentes Flapping zur Folge.
> Und auf native Routen wollen wir doch letztendlich hinaus...
> Was meint Ihr?
Ich meine, dass IPv6 langsam einmal nativ auf allen wichtigen 
5Ghz-Strecken (ich vermeide jetzt absichtlich das Wort "Freebone" oder 
"Backbone" ) Einzug halten sollte.
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...

Wie das mit den aktuellen AirOS-Hacks gelöst ist, entzieht sich mangels 
Zeit und Testhardware meiner Kenntnis.

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.

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.
>
> LG Wolfgang
>
LG
Erich
>
> On 05/10/14 11:33, Wolfgang wrote:
> > Danke,
> > das war die Lösung!
> > <ipv6 adresse> 0.2 bringt den gewünschten Erfolg.
> > LG Wolfgang
> >
> >
> > Am 05. Oktober 2014 09:46:51 MESZ, schrieb "Stefan Schultheis (home)"
> > <(spam-protected)>:
> >
> > Hallo Wolfgang,
> >
> > manche Einstellungen erfordern einen Reboot. Explizit kenne ich
> > das vom lqmult. Mit einem Reboot sollte die Einstellung dann
> > wunschgemäß übernommen werden.
> >
> > LgS
> >
> >
> > Am 5. Oktober 2014 09:37 schrieb Wolfgang <(spam-protected)
> > <mailto:(spam-protected)>>:
> >
> > Guten Morgen Alle,
> > ich habe folgende Frage:
> > im Moment wird ipv6 an einigen Tunnelendpunkten ins Netz
> > geroutet, in meinem Fall ozw und duer9. Nun geht eine der
> > Verbindungen wesentlich besser, was der olsrd4 auch richtig
> > abbildet. Dummerweise bevorzugt der olsrd6 aber die andere
> > route als default, da deren tunnelendpunkt näher liegt (der
> > Tunnel selbst läuft aber über eine wesentlich längere Strecke).
> > Meine Überlegung war, das über den LQ-Multiplikator
> > anzupassen. Ist das korrekt? Ich hatte einmal probeweise die
> > v6-Adresse der schlechteren Route eingetragen, gefolgt von
> > einem Multiplikator 0.5, hat jedoch nicht den gewünschten
> > Erfolg gezeigt. Firmware ist 0xff AirOS 5.5.8.
> > Weiß jemand eine Lösung für das o.g. Problem?
> > LG Wolfgang
> > _______________________________________________
> > IPv6-wien mailing list
> > (spam-protected) <mailto:(spam-protected)>
> > https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
> >
> >
> >
> >
> > _______________________________________________
> > IPv6-wien mailing list
> > (spam-protected)
> > https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
>
>
>
> _______________________________________________
> IPv6-wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20141006/b83051fe/attachment.html>


More information about the IPv6-wien mailing list