differenziertes IP routing ermöglichen; (a) falls wir mal mehrere Netze pro Stadt brauchen und (b) für links zu anderen Städten

[ka-ba]

Wir haben noch immer die beiden Szenarien offen, dass (a) wir mal innerhalb einer community mit einem großen mesh nicht mehr effizient hinkommen und in zwei, oder mehr IP-Netze splitten müssen (dafür haben wir im Netzplan ja vorgesorgt) und (b) wir vielleicht in Zukunft mal Netzverkehr zu anderen communities (Wi, Mz, Ffm, Da, ...) über eigene drahtlose links fließen lassen möchten. Aktuell wäre es so, dass der Datenverkehr immer über die privaten DSL-Anschlüsse und die Gates flösse, auch wenn bessere (und damit auch schnellere) Direkt-links verfügbar wären.

B.A.T.M.A.N bietet hier lediglich an, den clients default router zu vermitteln (und das schon mit groben Eingriffen in höhere Protokollschichten). Jeden FF-Knoten zum IP-router zu machen ist auch kein unumstrittener Weg.

Ein guter Lösungsansatz fehlt uns also noch.

[ka-ba]

Was könnte uns denn hier wohl die "IPv6 ND Redirect Function" bringen? (Und da stellt sich raus, v4 hat so etwas ja auch: ICMPv4 Redirect Messages.) Wird das von host-Implementationen unterstützt - ist ja Standard, oder?

http://www.tcpipguide.com/free/t_IPv6NDRedirectFunction.htm http://www.tcpipguide.com/free/t_ICMPv4RedirectMessages.htm

Wir müssten freilich noch etwas Gehirnschmalz in die Wechselwirkungen mit unserem l2-mesh stecken...

[kokel]

Die Redirect Messages funktionieren nur wenn das Gateway auf das redirected wird sich auch im selben Layer2 Netz befindet. Das kann man verwenden wenn die Borderrouter, die die Link Strecken halten je ein Bein im Mainzer bzw. Wiesbadener Netz haben. Da man dafür lokale statische Routen auf den Gates eintragen muss, würden die dann vor den dynamischen Routen, die über BGP reinkommen, bevorzugt werden (Preference). Zur Not müsste man das Peering übers IC-VPN abschalten.

Meiner Meinung nach haben wir uns durch das Teilen der Gateways für beide Communities viele Möglichkeiten verbaut, weil alle Gates beide Netze lokal anliegen haben. WIr sollten ein Testnetz aufbauen, um verschiedene Szenarien einfach mal durchspielen zu können.

[Update] Workaround, der so gut wie keinen Umbau am Bestandsnetz erfordert:

• Rechner/Server (kein Knoten) mit WLAN Link zum Backbone:
  • macht alle Gateway Aufgaben außer fastd für Knoten
  • macht erstmal nur für mainz Sinn da WI noch kein BB hat
  • hat relativ performanten Internet Uplink
  • Gibts schon (parmesan), noch nicht in Betrieb Vorteile:
  • Zumindest ein Teil des Backbone Traffics kann ohne Umweg übers Internet ausgeleitet werden
  • Für diesen Teil wäre das BB dann "wirklich" performant
• Es gab mal einen Vorschlag (glaube von ka-ba) die Knoten selbst routen zu lassen
  • Würde ziemlich viele Probleme auf Anhieb lösen
  • Leider momentan mit Gluon nicht umsetzbar

Solange wir ein Layer 2 haben und die Knoten nicht selbst routen können bleibt uns meiner Meinung nach nichts anderes übrig als den oben beschriebenen Workaround weiter auszubauen. Wir brauchen Gateways mit direktem WLAN Link im Backbone und guter Internetanbindung (Rechenzentren mit Dach wo seid ihr?). Idealerweise alle gemieteten Gates, die weit weg in Europa verteilt stehen durch sowas ersetzen.

[ka-ba]

(Der work-around aus dem update hat IMHO nur am Rande mit diesem issue zu tun. Es gibt Aspekte, die überlappen, aber es sind zwei disjunkte Ansätze für zwei disjunkte Fragestellungen. Vielleicht ist das ein eigenes issue wert?)

Kokel, hast Du konkret Erfahrungen mit / Wissen über diese redirect messages? Können wir die und das hier direkt nuzen? :)

Ansonsten möchte ich aber doch Deinen Kommentar mal etwas auseinander nehmen (sorry, hoffe Du nimmst mir das nicht übel ;) ):

Wenn wir mal nur eine der B.A.T.M.A.N-Wolken betrachten, so ist die Voraussetzung, die Du als notwendig benennst ja erfüllt. Sowohl der default router eines Mainzer Knoten (Kmz) (aktuell immer ein gate (Gdef_kmz)), als auch unser fiktiver Funkstrecken-Router nach Darmstadt (Rda) befinden sich im selben L2-Netz. Das passt also! Gdef_kmz könnte also das erste Paket von Kmz nach DA an Rda weiterleiten und gleichzeitig Kmz einen redirect auf Rda zukommen lassen. Kokel, muss die Route vie Rda auf Gdef_kmz wirklich statisch eingetragen werden, damit dieser einen redirect schickt? Eine via BGP gelernte Route wird dafür nicht hergenommen? Das wäre ja recht unsinnig, oder?

Ein Wiesbadener Knoten Kwi befindet sich natürlich in einem anderen L2-Netz und kann Rda nicht direkt nutzen; er würde auch keinen redirect bekommen, sondern müsste nach DA weiterhin über seinen Gdef_kwi routen. Gdef_kwi entscheidet - wie bisher - nach seinen routing tables.

Symetrisch kann man sich das Szenario auch mit getauschten Rollen vorstellen, wenn Wi direkt-Links zu anderen Städten hat.

Habe ich hier einen Denkfehler, oder eine Wissenslücke bzgl. der Funktion der redirects?

[kokel]

Bitte keine Scheu meine Kommentare in der Luft zu zerreißen ;-)

• Die Redirects können wir direkt nutzen. Die Clients erhalten dann ein ICMP Redirect und schicken den Traffic für DA/FFM dann an das im ICMP Redirect genannte Gateway statt zum Default Gateway.
• Die Routen können natürlich auch über dynamische Protokolle kommen. Nur sollte man das das IC-VPN Peering mit dieser einen Community abschalten.

[Maesto]

Ich grabe das hier mal aus, weil ich aktuell hier "49.977969, 7.914861" W-Lan antennen aufhänge. (Satellit einschalten ist ein alter Schornstein)

Jetzt würde ich gerne eine Richtfunkstrecke mit Bingen machen. Um dass sinnvoll zu realisieren, würde ich wohl dort ein gateway aufbauen müssen, da sonst ich einfach nur einen Binger Knoten in Rüdesheim hab und dort Traffic ins internet leite. Das widerspricht sich mir jedoch, da meines erachtens Freifunk auch ohne Internetverbindung klappen sollte.

So wie ich das sehe kommt eigentlich "nur" ein routing an diesem Knoten in frage. Der Knoten selbst muss dafür aber ein Gateway sein, damit dieser den Traffic überhaupt abbekommen kann. Hier müsste es jedoch einen Fallback geben, falls mal dieses GW nicht erreichbar ist. (BATMAN gateway funktion?)

Eventuell würde es Sinn machen eine zweite art Gateway ein zu führen, welches nach möglichkeit funktioniert wie ein normales GW, für den fall des Ausfalls der Internetverbindung jedoch ein fallback auf andere GW macht.

Wenn diese Gateways z.B. einen Tinc tunnel zu den anderen Gateways über das FF netzwerk aufbauen. Dann würden auch dinge wie z.B. IC-VPN weiterhin funktionieren solange mindestens ein knoten in der lokalen wolke internet hat. Und das routing zu anderen Communities würde weiterhin funktionieren, solange die Mesh wolke zumindest einen Link in die Community hat.

Über routen priorität sollte es auch möglich sein, diesen internen Tunnel bevorzugt über den Internet Uplink zu routen. Zumindest so lange bis die Internetverbindung wegbricht.

Macht das sinn?