[IPv6-wien] link quality / route bevorzugen

[Stefan Schultheis (home)]

Hallo,

>  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.
>
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.

>  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.
>
Stimmt. LQmult über Nachbar-IP sollte die Lösung sein!


>  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 ;-)
>
Macht OLSR eigentlich eh korrekt, da sich der ETX aus LQ & NLQ ergibt und
in beide Richtungen wirkt.

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.


> 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.
>
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.

>  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.
>
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!

Ich lege euch eine aktuelle Statistik bei, die ich seit Anfang des
IPv6-Vorhabens führe!


> 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.
>
Ich würde die 0xFF-AirOS-Version nicht als mehr als "Hack" bezeichnen.

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.).

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.
>
Das machen wir auch genau so. Aber stimmt: es könnten mehr sein ;)

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
>
LgS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20141006/e1a95eb0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rts6.pdf
Type: application/pdf
Size: 68251 bytes
Desc: not available
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20141006/e1a95eb0/attachment.pdf>