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
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
_______________________________________________
IPv6-wien mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/ipv6-wien
LG
Erich
--
Wien mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/wien
