[Wien] [IPv6-wien] link quality / route bevorzugen

[Erich N. Pekarek]

Hallo!

Die verworrenen Zitat-Einschübe bitte zu verzeihen.
...
>> 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 könnte aber auch daran liegen, dass im Moment noch niemand Mittel 
und Arbeitszeit für eine Umrüstung des Kryptaroof beigesteuert hat.
Solche Hürden sind nur gemeinschaftlich zu bewältigen.
>>>   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.
Das verstehe ich nicht. Tunnelinterfaces gibt's immer zwei. Auf welchem 
möchtest Du was pönalisieren?
Du kannst ganze Interface und/oder einzelne direkte Nachbarn 
pönalisieren oder übersteuern. Das fein granuliert einstellbar.
Trotzdem: jeder manuelle Eingriff in die automatische Bewertung der 
Metrik erzeugt zusätzlichen Wartungsbedarf.
Ein Hop der zwischen zwei Tunneln liegt hat kein natives v6, er hat 
nativ erscheinendes, getunneltes v6.
Tunnelmechanismen (transitional mechanisms gemäß den diversen RFC) haben 
stets eine gegenüber nativen IPs erhöhte Metrik.
Da bei uns unbestimmte (d.h. den Mechanismus nicht erkennbar machende) 
öffentliche IPs verwendet werden, liegt es in der Verantwortung der 
Tunnelbereitsteller, dies einvernehmlich zu adjustieren.


>>> OLSR ...
> 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.
Wenn Knoten als Tunnelserver nicht die notwendige Eignung haben, dann 
sollte man darauf verzichten, dort einen Tunnelserver anzubieten. Oder 
Funk-Links, die Tunnel-Konnektivität vermitteln, nur nach Absprache für 
andere Teilnehmer freigeben.

Wer auch IPv6 nicht verzichten kann, aber keine brauchbaren Peers dafür 
hat, so bleibt immer noch eine andere Zuweisungsart, auch, wenn das 
zusätzlichen ausgehenden Datenverkehr mit sich bringt. (Teredo, sixxs, 
he.net, ... 6to4 gilt als deprecated, weil die Routing retour in der 
Praxis Probleme bereiten kann.)
Auch ein zentraler Tunnel im Housing sollte nur solange verwendet 
werden, bis die native Anbindung vorhanden ist.
Wenn zwei unmittelbar benachbarte Knoten Tunnel betreiben sollen, dann 
soll eben aufgrund der Fähigkeiten entschieden werden, wer den Tunnel 
belässt, bzw. welcher höher priorisiert werden muss.

Was hier angesprochen ist, ist wohl das, wovor Euch Josef im Umgang mit 
Tunneln schon vor einem Jahr eindringlich gewarnt hat.
> ...
> 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.
Ein v6-nativ angebundener Knoten sollte aus oben genannten Gründen 
meines Erachtens auch dann bevorzugt werden, wenn die Hopanzahl "weiter 
weg" von der "Nativroute" ist.
Betrachtet das IPv6-Netz bitte nicht als v4 Huckepack-Rollout, sondern 
als eigenständiges Netz, für das diesselben, wenn nicht sogar strengere 
Regeln für die Linkqualität und Verfügbarkeit gelten sollen.

Wenn die Redundanz auf v4-Ebene bei der Verwendung von Tunneln bereits 
gegeben ist, ist ein zweiter Tunnel oder zweiter Link mit ähnlichen 
Kriterien relativ witzlos. Da ist Verzicht wohl die bessere Lösung.

Ziel muss es sein, das, was wir auf v4-Basis haben, "neu und neu besser 
zu machen" und Brücken ins v4-Netz schlagen; nicht umgekehrt.

Ein dynamisches Netzwerkroutingprotokoll ist eben dynamisch und wird 
durch Tunnel - anders als in einem statischen Schienennetz - schlicht 
"untergraben", oder?

Die sinnvollere Alternative zu Tunneln ist es in jedem Fall, die 
Integration voranzutreiben:
     * Die nicht v6-fähigen Knoten identifizieren
     * Betreiber anschreiben und erforderlichenfalls auch 
gemeinschaftliche Hilfe anbieten
     * falls Hilfe und v6 dort generell unerwünscht ist, dann dürft (aus 
meiner Sicht) Ihr einen Hop untertunneln oder besser: einen Direktlink 
anstreben.


>>
>>> 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?
Weil duer9 über die Krypta-Brigde (meines Wissens am alternden 
Routerboard dort) kein IPv6 bekommt.
Einerseits der Hardware wegen, ...
>> 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.
Das bestreitet niemand. Trotzdem ist's ein Hack oder sagen wir "Mod".
>   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.
Weil die Firmware für dieses Device angepasst ist, weil der Hersteller 
bessere Treiber bekommt, und OpenWRT von OpenSource-Aktivisten gemacht 
wird, die üblicherweise von den Chipherstellern Infos nur unter NDAs 
u.a. bekommen.

Hauptgrund ist wohl die Optimierung der Packet Aggregation.
Ein Problem darin ist, dass es keine Community-Software ist, mit der wir 
die Adhoc-Funktionalität nachbilden könnten - aber da hat Bernhard 
Besserung versprochen ... schauen wir einmal.
> Und keine Abstürze mehr.
Ich hatte mit OpenWRT seit Ewigkeiten keine Abstürze. Ab und an eine 
DMA-Fehlermeldung, aber das ist seit Barrier Breaker auch Geschichte.

Soll jeder mit der Firmware arbeiten, die im besser erscheint - aber 
bitte den Community-Gedanken nicht aus den Augen verlieren. Die 
Umstellung von adhoc auf ap/client geschah unter der Prämisse, "das 
bessere adhoc" damit machen zu können. Das ist momentan anscheinend in 
den Hintergrund getreten und entfernt uns von der ursprünglichen 
Zielsetzung des "Überall-Netzes".
>
>> 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
>
> _______________________________________________
> IPv6-wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
LG
Erich