[IPv6-wien] link quality / route bevorzugen

[Wolfgang]

Am 06. Oktober 2014 15:24:51 MESZ, schrieb "Stefan Schultheis (home)" <(spam-protected)>:
>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.
>>
>> ?
Naja, gemeint war, dass ich die 'ganze' Route zu meinem Nachbarn pönalisieren muss (in meinem Fall 110deg.ozw) und nicht bloß den traffic, der von dort ins tunnel interface geht. Das ist, meine ich unnötig, da damit ja auch alle anderen Ziele, die ich über 110deg.ozw sehr gut und kurz erreichen kann, ebenfalls pönalisiert werden.
Deshalb ist es also besser (s.u.), den LQ-mult erst am Tunnelinterface selbst zu setzen, wie wir uns eh schon einig sind.

>> 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.
Damit war gemeint: Die Anzahl der hops /latenz /etc. sollte in den LQ-mult eingehen, sprich, der Tunnel am duer9 ist sehr nahe an der idealen Nativroute und braucht eine nicht so hohe Pönale, wie z.B. der Tunnel am OZW.

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

Das hatte ich auch kurz überlegt, aber letztendlich löst dies nicht das o.g. Problem. Denn wenn bsp. der Tunnel an duer9 genauso pönalisiert wird, wie der am ozw, wird zB. trt6 wieder den ozw tunnel bevorzugen, obwohl die Tunnel- (v4)Pakete dann insgesamt den längeren Weg gehen müssen. Also erscheint mir eine individuelle Konfiguration derzeit am sinnvollsten.
>
>
>> 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.
>>
Nur zum Verständnis: Warum läuft v6 zwischen subway und duer9 eigentlich über tunnel statt nativ?

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

Dem möchte ich mich voll anschließen! Die 0xff AirOS FW ist an meinem Standort vollkommen stabil. Bei großem Respekt für die in bubbles hineingesteckte Arbeit, AirOS kann alles, was ich derzeit auf meinen ubiquiti devices brauche und bietet interessanterweise auch noch höhere link speeds, warum auch immer.
Und keine Abstürze mehr.

>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
>
LG Wolfgang
>
>------------------------------------------------------------------------
>
>_______________________________________________
>IPv6-wien mailing list
>(spam-protected)
>https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien