[IPv6-wien] link quality / route bevorzugen

[Erich N. Pekarek]

Hallo!

Am 2014-10-06 um 15:24 schrieb 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.
Das ist wohl des Pudels Kern.
>
>>     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!
IF oder IP? ;-)
>
>>     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.
An sich ist das richtig. Allerdings passiert das aufgrund der Dynamik 
etwas zeitversetzt.
>
> 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.
Stimmt. Darum empfahl ich ja das per-Interface-Default-LQMultiplying 
anstelle des per IP-LQMulten.
>
>>     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.
Dann trage für die bestehenden einfach erst einmal 1.0 ein. Das sollte 
sich einfach aus der Routingtabelle skripten lassen.
> 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 wi, htigen
>     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!
Prozentzahlen sind kein direktes Indiz für das, was wir hier besprechen 
und vorhaben, oder?
...obwohl das sicher ein toller Erfolg ist.
> 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 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.
>
> Das ist eine tolle Arbeit, die sich bei mir auf > 30 Geräten als 
> schneller und stabiler als OpenWRT gezeigt hat,
warum wohl: das Ding macht Packet Aggregation auf hohem Niveau und hat 
einen stabilen Treiber.
Da hat übrigens OpenWRT nachgelegt.
> 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.).
Es ist eine Herstellerlösung mit definiertem Use Case, der hier 
"aufgebohrt" wurde.
OpenWRT zwar den Anspruch erweiterbar zu sein, das UI der LuCI verfolgt 
aber ebenfalls den Anspruch der Einfachheit, wobei wichtige Funktionen 
leider unkonfigurierbar sind.
>
>     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 ;)
Auf der Krypta-Bridge zur Zeltgasse geht es mir leider auch ab... @Markus?
>
>     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

LG
Erich

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