[Freifunk-Bonn] FSM dyn. Bridging

[Linus Lüssing]

On Sun, Feb 05, 2012 at 12:24:50PM +0100, Jan Lühr wrote:
> Hallo,
> 
> fup2 Bonner Liste - ggf. interessiert's ja noch andere :-)
> Antworten siehe unten.
> 
> Am 05.02.2012 um 05:05 schrieb Linus Lüssing:
> 
> > On Sat, Feb 04, 2012 at 05:24:47PM +0100, Jan Lühr wrote:
> >> Hallo Linus,
> >> 
> >> leider ist unsere Wiki aktuell im Umbau, s.d. wir aktuell keine Struktur haben, in der Du den Artikel findest :-(.
> >> Da weiterhin Jabber meine Nachricht verschluckt zu haben scheint, kurz per E-MailL:
> >> http://kbu.freifunk.net/index.php/FSM-Dynamisches-Bridging
> > 
> 
> > 
> > Hmm, ich hatte noch Nachrichten auf dem Handy gefunden und die
> > erst später gesehen, nachdem ich dir per jabber vom Laptop aus
> > geantwortet hatte. kA ob das dort nun alle waren, hmm.
> > 
> > Na ja egal. Hab's mir jetzt mal angeschaut das FSM von dir. Und
> > wenn ich das richtig sehe, ist es ziemlich identisch zu dem
> > Vorschlag, den du auch am Telefon schon gemacht hattest, oder
> 
> Ja.
> 
> > 
> > Also auf jedenfall ist das ganze um einiges übersichtlicher als
> > mein wirrer Kram *hust* :). Und jau, es hat bei weitem weniger
> > Timeouts und der einzige Timeout, der da momentan drin ist, ist
> > eigentlich unkritisch (`nodeTimeOut`), da wie du dort schon
> > anmerktest, batman-adv vorher greifen sollte bei Pfad/Link
> > Problemen. Also ist TBD.1 vermutlich eher unkritisch - das Minimum
> > dort sollte vom OGM Intervall und/oder vom batman-adv purge
> > timeout (=3min.) abhängen, also sind deine 3min. als Minimum schon
> > gut geschätzt - aber jau, länger warten tut eigentlich auch nicht
> > weh, weil's wohl ne unkritische Ressource ist.
> > Und bei ne'm
> > DoS-Angriff würde vll. auch sogar ein 3min. timeout nicht helfen,
> > hmm. Aber ist auch eher unwichtig erstmal.
> 
> Puh - ich denke, bei einem DoS-Angriff sind Timer das einzige, was helfen kann. Aber dann brauchen wir weitere (z.B. die maximale Zahl neuer l2tp-Links pro Minute)
> Das Thema DoS würde ich aber gerne mal außen vorlassen.

ack

> 
> > 
> > Warum gibt es TBD.2? Hatte es so verstanden, dass `removeL2TPLink`
> > das eigentlich schon machen sollte.
> > 
> > Glaube wanUP und wanDown müsste man noch etwas
> > ausführlicher/komplexer spezifizieren. Wenn man nur den
> > Link-Status nehmen würde... da würde es bestimmt ne Menge Leute
> > geben, die da evtl. mal etwas falsch zusammen stecken. Oder deren
> > Firewall blockt irgendwie den intracity-VPN Aufbau.
> 
> Was imho relativ egal wäre, da in diesem Fall die VPN Verbindung nie aufgebaut wird, d.h. der Init-State nie verlassen wird.
> Ich

Ah, stimmt, das wäre da unkritisch, ack.

> 
> > Oder deren Internetverbindung wackelt regelmäßig, weil z.B. die Putzfrau immer 
> > um 10:00 morgens den Stromstecker des DSL-Modems stattdessen für den
> > Staubsauger benutzt :P. Da kann (und wird) alles mögliche
> > passieren, und würde jener Router würde dann sicherlich für einige
> > Leute in der Umgebung dann trotzdem noch zum schwarzen Loch
> > werden (auch wenn nicht mehr ganz so tragisch wie bei meinem
> > ersten Vorschlag).
> 
> Puh - das kann natürlich zu einem Problem werden - ich würde den Punkt aber gerne erstmal außen vorlassen, mein Gedanke:
> -> Wan-UP ist einfach zu implementieren (OpenWRT erlaubt einen entsprechenden hook)
> -> Der Fall (sollte) in erster Linie einzelne Router (<< 5 betreffen). Hier helfen ggf. händische Workarounds
> 
> Das wäre (imho analog zu DoS) ein Thema, das wir mit Prio-2 angehen sollten.

Hmm, kommt drauf an. Wenn man den Verursacher, der sich vermutlich
der Problematik selber nicht bewusst ist, nicht erreichen kann,
dann wird's mit den händischen Workarounds schon etwas kniffliger.
Dann müsste man auf netfilter oder batman-adv Ebene anfangen,
blacklisting zu implementieren, sowie mindestens bei den
betroffenen Nachbarn die Geräte updaten. Klar, es sollte jetzt
keine hochkomplexer Verbindungstest sein, keine magische Funktion,
die Latenz, Durchsatz, Paketverlust, Temperatur, Luftfeutigkeit,
Radioaktivität, Neutrinos, Higgs-Bosonen, ... auswertet. Aber
irgendwas rudimentäre(res) sollte mit wenig Aufwand machbar sein
und bei einem rudimentären Verbindugstest sehe ich jetzt eine
relative geringe Gefahr, dass man da zu weit / falsch messen
könnte.

> 
> > 
> > Ein wanDown müsste außerdem auch noch ein StopDhcpServer
> > beinhalten, oder?
> 
> Ja.
> 
> > 
> > Hmm, downloadNetConfig und establishVPN würde ich glaub' ich nicht
> > parallel machen. So würde es beides über das Internet gezogen
> > werden, oder? downloadNetConfig würde ich vorschlagen über das
> > intracity-VPN dann, also nach dem establishVPN zu machen, um
> > zumindest vor anonymen Trollen aus dem Internet geschützt zu sein,
> > die sich mal eben alle Adressen und Subnetze holen.
> 
> Nacheinander geht natürlich auch - bringt aber kaum Sicherheitsgewinn:
> -> Ein "Saboteur" kann immer über das VPN kommen.
> -> Aktuell benötigst du zum Download MAC-Adressen als Username & Password. Bots bleiben also außen vor.
> 

Musst du mir vll. nochmal off-list ein wenig genauer erklären,
wie eure "authentifizierung" genau funktioniert und warum die
gegen Bots sicher wäre.

> Dennoch hat ein sequentieller Ablauf den Charm, dass die Join-Punkt entfällt, das ganze also einfacher zu bauen wird.

Joa. Ist ja nix zeitkritisches, was unbedingt parallelisiert
werden muss.

> 
> > 
> > downloadNetConfig würde ich dort in den Klammern neben 'Subnet,
> > Range für dhcp' noch IP Adresse im Transfer-Netz, also im intracity-VPN,
> > noch mit rein schreiben.
> 
> Ändere es einfach in der Wiki :-)

k :).

> 
> > 
> > Außerdem stellt sich noch die Frage, ob wir einen gewissen
> > Zusammenhang zwischen Transfer-Netz-IP und zugeiltem Subnetz für
> > die WLAN-Wolke haben wollen. Also sowas was ich ein wenig wirr
> > unter 'Adressing' beschrieben hatte. Z.B. würde dann mein TP-Link
> > Router dann in Lübeck für das Transfer-Netz die 10.130.0.22/24
> > bekommen, und dann in seiner Wolke selber 10.130.22.1/24 haben und
> > 10.130.22.0/24 per DHCP anbieten. Vorteil: Man braucht im
> > intracity-VPN nur noch OSPF für die default-Routen / Internet-Exit-Gateways.
> 
> Können wir überlegen. Ist eigentlich eine gute Idee. Das würde zugleich die Traffic-Mange auf dem VPN-Link reduzieren.
> 
> 
> > Hab' auch nochmal überlegt, vom Prinzip her wäre das ja das gleiche,
> > ob man jetzt seine Subnets/IPs sich von 1 bis x web servern im
> > intracity-VPN oder von 1 bis x DHCP servern im intracity-VPN holt.
> > Sollte dann quasi ich gleich robust und "dezentral" sein. Und wäre
> > dann nur noch eine Frage des Implementierungaufwandes, wenn ich
> > nicht sonst noch weitere Nachteile von einem der beiden übersehe.
> > In OpenWrt hat man den Vorteil, dass man beim Erhalt eines DHCP
> > Leases gleich seine eigenen Skripte darauf hin laufen lassen kann.
> > Und der DHCP Server im intracity-VPN sich dann die Vergabe schon
> > selbstständig merkt. Ein paar Layer höher per HTTP müsste man das
> > dann wohl noch den ganzen Reservierungsprozess noch
> > implementieren, oder (okay, wäre auch nicht so viel, aber
> > trotzdem)? Hmm, vll. klingt das konfigurieren per DHCP noch etwas
> > seltsam/ungewöhnlich, sehe jetzt aber noch keine Nachteile dadran
> > und ich glaube wir kriegen damit schon eine Menge "geschenkt".
> > Oder fallen dir noch Nachteile oder extra Aufwand bei der DHCP
> > methode auf?
> 
> Die Idee hat - wie fast jede gut durchdachte IPv4-Adress-vergabe Strategie - die Eigenschaft, dass die Adressen schnell ausgehen können.
> Mir kommen an sich noch 2 andere Ideen in den Sinn.

Welche Idee? Per DHCP? Per HTTP? Oder beides? Das Transfernetz
braucht ungefähr eins von 255 /24-Subnetze, also 0.04% eines zur
Verfügung stehenden /16-Subnetzes. Um das Mapping einigermaßen
übersichtlich zu haben, wie oben vorgeschlagen, dann komme ich auf
6.2% eines /16-Subnetzes, es können also immernoch 239 Router mit
intracity-VPN betrieben werden. Und von diesen 6.2% können
immernoch sehr bequem Adressen an Hosts im transfer/intracity-Netz
vergeben werden, für Internet-Exit-Gateways oder Services im Mesh.

> 1. Das Transfer-Netz ist IPv6 Only (hat einen gewissen Charme, ist aber komplexer)

Das eine /24 (im obigen Beispiel 10.130.0.0/24) könnte man sich
mit IPv6 und den Sachen wie SIIT/NIIT, an denen die Berliner
glaube ich ne Menge mal gebastelt und geplant hatten, vermeiden,
vielleicht würde man dadurch die 6.2% auch auf 0% bekommen können
und alle /24 dann ausgeben.
Hmm, trotzdem lohnt sich das glaube ich vom Aufwand her nicht
wirklich. Und könnte man glaube ich wenn man das später unbedingt
haben wollen würde, immernoch relativ fließend updaten.

Wenn die Anzahl an Adressen / zu großzügige Ausgabe das große
Problem sei, dann ist vermutlich das Ausgeben von weiterhin /24,
aber dass jeder Knoten nur erst einmal hieraus z.B. nur die
.2-.127 anbietet bei seinem DHCP-Server die effektivere
Möglichkeit, Adressen zu sparen. Dann könnte man immernoch
schauen, ob es später sinnvoll wäre, einige auf /25
degradieren und/oder andere das ganze /24 verteilen zu lassen.

> 2. Intracity arbeitet nur auf OSI-3 und baut p2p-Links zum Server auf, die die default-Route setzen.
> (Vorteil: Wenig komplex, Nachteil: Zentrale Struktur, Sternförmiges Routing)
> 
> Nichts destro trotz gefällt mir Vorschlag 2. fast am besten, da wir uns in der Anfangszeit viel Komplexität sparen (kein OSPF, keine Skalierungsprobleme auf Intracity-VPN, keine IP-Vergabe außerhalb von OpenVPN für das Transfernetz), so dass ich damit fast am liebsten Anfangen würde.

Jau, das wäre relativ einfach gemacht und hat weniger verschiedene
Layer und Protokolle und somit vermutlich die niedrigste
Komplexität. Praktisch hat es natürlich als den direkten Nachteil
die nicht vorhandene Redundanz. Sowie den Flaschenhals (und damit
evtl. Skalierungsprobleme?)

Ideologisch gesehen... ist der wichtige Aspekt und eine wichtige,
politische Motivation, ein demokratischeres, also dezentrales Netz
zu bauen um gerade zentralen, zensuranfälligen Machtstrukturen
entgegen zu wirken. Prinzipiell kann man natürlich mit etwas
zentralerem Anfangen - aber meiner Meinung nach nur, wenn es einen
Plan gibt, wie man dann mit den nächsten Schritten jene Strukturen
wieder dezentralisieren kann. Bei dem Vorschlag 2 kommt es mir ein
wenig schwer vor, dass im Nachhinein zu dezentralisieren. 

Hey, und OSPF ist doch ne coole Sache, die das schön sauber trennt
und organisiert, sowie eine ausgereifte, viel benutzte
Technologie. Und neben jener Praktikabilität(TM), eigentlich schon
vom geek-spaß-Faktor her eine super Sache für Freifunk ;).

Sehe die Punkte "kein OSPF, keine IP-Vergabe [...] für das
Transfernetz" als nicht wirklich kritisch. Welche
Skalierungsprobleme siehst du mit einem Transfer-Subnetz?

> 
> 
> > 
> > Zum Weglassen des batman-adv gateway Features hatte ich ja schon
> > gesagt, da ist der Nachteil dann die geringere
> > Ankunftswahrscheinlichkeit oder höhere Broadcast-"Verpestung" der
> > WLAN-Mesh-Wolke, je nachdem, wie man die Anzahl an
> > Rebroadcasts einstellt in batman-adv. Und sehe jetzt noch nicht
> > ganz die Nachteile, die ein Einschalten des Gateway-Features für
> > DHCP hätte.
> > 
> > 
> > Bei L2TPv3 kann man sich den UDP header auch sparen. Und weil's in
> > tinc ja schon drin ist, sollte es ohne den UDP header auch keine
> > Probleme mit Firewalls oder NAT geben. Hab' letztens nochmal
> > dieses Kommandos stattdessen benutzt:
> > l2tpv3tun add tunnel remote 141.83.153.180 local 141.83.65.45 tunnel_id 1 peer_tunnel_id 1 encap ip
> > l2tpv3tun add session tunnel_id 1 session_id 1 peer_session_id 1
> > (und glaube l2tp patches wurden immernoch nicht in die ip-utils
> > gemerged, kA ob das noch kommen sollte/wird)
> 
> Ja - sehe ich auch so.
> 
> > Unterschiedliche Ports brauchen wir dann also nicht, dann
> > unterschiedliche Tunnel IDs (die eigentlich Control Connection IDs
> > heißen sollten bei l2tpv3 laut RFC) stattdessen für ein Knoten Paar.
> > Bei den Session IDs glaube ich brauchen wir auch zwei
> > verschiedene, klingt irgendwie so in den RFCs, dass Datenpakete
> > nach der Session ID und ohne Tunnel ID übertragen und zugestellt
> > würden - müsste man aber nochmal testen.
> > 
> > Zumindest nach dem was l2tpv3tun (kA wie das bei openl2tp
> > aussieht) an Parametern vorschreibt, bräuchten wir dann also wirklich
> > ein Handshaking Protokoll zum Austausch der Peer Tunnel/Session IDs.
> > Hmm, mich wundert nur ein wenig, dass die Grafik auf
> > https://en.wikipedia.org/wiki/Layer_2_Tunneling_Protocol#L2TP_packet_exchange
> > einen automatischen Austausch der Peer Tunnel/Session IDs
> > suggeriert - aber der Artikel ist eh ein wenig komisch und sehr
> > L2TPv2 beschränkt / falsch für L2TPv3
> 
> Fies - sollte aber nicht schwer zu bauen sein.
> 
> > 
> > Vom Prinzip her, mit den mehreren Layer 3 Subnetzen pro Wolke muss
> > ich dir aber recht geben, dass mein erster Ansatz und dessen
> > Vorteil, das sich zwei Clients in der WLAN-Mesh-Wolke dann immer
> > über den batman-adv-besten Weg dann finden, die extra Komplexität
> > nicht rechtfertigt. Insbesondere, weil's ja eigentlich nicht
> > kritisch ist, jener nicht-optimale Weg, weil wohl davon
> > ausgeganegn werden kann, dass der Pfad über die default-Route zwar
> > länger aber immernoch bei weitem gut genug ist. Und den
> > Hauptnachteil zum 4.3 Szenario haben wir damit ja eliminiert,
> > nämlich die Möglichkeit zu komplett unnutzbaren Routen bzw. danach
> > dann das neues DHCP Lease holen (=Verbindungsabrüche) im Fall von
> > Roaming.
> 
> Ok. Also rann ans Werk :-)
> 
> > 
> > Ansonsten war ich noch wegen zwei weiteren architektonischen
> > Varianten für 4.4 am überlegen:
> > a) Könnte man später noch mit Routen-Announcements im
> > Falle von IPv6 rumspielen? Z.B. wenn ich zwei solche Knoten, zwei
> > Gateways mit intracity Anbindung hätte:
> > Könnte ein Client dann zwar vll. eine IPv6 Adresse X/64 + default
> > Route immernoch bekommen, aber wenn der zweite intracity gateway
> > dann auftaucht, dass dann der Client eine extra Route für Y/64
> > bekäme? Mit radvd kann man ja noch hübsche extra Routen bekannt
> > machen... Oder wie genau verhält sich IPv6 bei mehreren
> > default-Routen und IP-Adressen/Subnetzen?
> 
> Es gibt ein Tie-Breaking-Verfahren. RFC hab' ich gerade nicht im Kopf. 
> Je nach Verfahren (last-wins) hätte das nervige Folgen. Ich meine aber irgendwo im Hinterkopf zu haben, dass die OSI-2 Distanz mit einbezogen wird. Das wäre dann wieder besser.
> 
> 
> > Matthias, eigentlich
> > unser Layer 3 Spezi hier in Lübeck, hatte mir immer stark von
> > mehreren Adressen abgeraten... aber hmm, ich frage mich, ob die
> > ganzen Verfügbarkeitserkennungsmechanismen, wie ich meine sie im
> > stateless autoconfiguration RFC gelesen zu haben, in der Praxis
> > auch so funktionieren könnten.
> 
> Ich denke, IPv6 ist hier praktisch kaum erprobt. Also das ideale Feld für Freifunk-Spielerreien.

Hmm, jepp, stimmt. Aber gut, auch erstmal nicht so wichtig für den
Anfang.

> 
> > 
> > und b) war ich noch am überlegen, ob es noch eine etwas andere
> > Möglichkeit zu unseren beiden aktuellen Vorschlägen gäbe. Nämlich
> > das man die DHCP Server für die Mesh-Wolken ganz in die Rechenzentren
> > verlagert. Und ein WLAN-Router, ein intracity gateway, dann nur
> > noch ein oder mehrere Tunnel zu jeweils ein oder mehreren
> > DHCP-Servern aufbaue. Dadurch würde man sich im Vergleich zu
> > meinem ersten Vorschlag das ganze DHCP-Server/batman-adv gateway
> > ein/ausschalten sparen, es würde dann "nur" noch um das dynamische
> > Tunnel auf und abbauen gehen. Wobei aber genau wie bei deinem
> > Vorschlag das Auf- und Abbauen zeitlich unkritisch sein sollte,
> > da auch hier wieder batman-adv das auf der ganzen Strecke, inklusive
> > den Rechenzentren-DHCP-Servern, regeln würde. Wenn du meinst es
> > könnte Sinn machen, diesen Ansatz noch ein wenig
> > auszuformulieren/diagrammisieren, kann ich das gerne noch machen.
> > Oder klingt das in deinen Ohren jetzt schon immernoch zu wackelig
> > oder hat schon ne Menge Nachteile, sodass wir doch lieber auf dem
> > alten Pfad, dem Umsetzen + ein paar Verfeinerungen deines letzten
> > Ansatzes, setzen sollten?
> 
> Puh - ich denke, dieser Ansatz ist komplex. An sich ist - so wie ich dich verstehen - die Idee nur noch ausgewählte Netzteilnehmer DHCP machen zu lassen. (ob sie nun auf Nodes dezentral oder in einem RZ zentral betrieben werden) spielt imho keine große Rolle.
> Ich finde es wird schwierig ein Verfahren zu finden, dass
> a) Ausreichend Robust ist: auch ein Server in einem RZ kann ausfallen.
> b) Nicht-Komplex ist: Es muss ohne großes Handshaking / Tie-Breaking erkennbar sein, wer wann einen DHCP fährt.
> 
> Ob wir hinterher einzelnes, die Probleme machen nicht mehr DHCP spielen lassen oder nur einige wenige DHCP-Nodes/Server identifizieren führt imho zum gleichen Ergebnis.
> 
> Ich würde uns ungern von diesen Bedenken aufhalten lassen - das instabile Nodes (egal in welcher Topologie) ein Problem sein, ist imho kaum verhinderbar (zumindest dann, wenn der wlan-Link mangels Strom oder durch Störung ausfällt). 
> Wichtig für den Anfang ist imho vor allem eine geringe Komplexität. Dann können wir Probleme identifizieren (z.B. instabile Nodes, Links, etc.) und nachsteuern.

Ok, jo, gut. Lassen wa das erstmal. War vielleicht auch noch nicht
ganz durchdacht von mir.

> 
> > 
> > 
> > Hrm, hehe, mal wieder viel Text geworden. Aber na ja, ich glaube
> > wir sind auf dem richtigen Weg.
> 
> Ich auch :-) - evtl. könnten wir ja mal eine Hackathon machen um die ganzen Dinge zu versuchen.

Hackathon klingt gut :). Wenn alles dann relativ gut vorher
geplant ist, sollte es ja (hoffentlich) auch kaum Komplikationen
dann bei der Umsetzung geben, sodass man so einen Hackathon sehr
zügig/zielstrebig durchführen könnte.

> 
> Alles Gute
> Jan
> 

> -- 
> _______________________________________________
> Freifunk-Bonn mailing list
> Freifunk-Bonn at lists.bonn.freifunk.net
> http://bonn.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn