Vermutlich steht das ja schon irgendwo, kann das aber nicht finden.
Verstaendnisfrage: Wieso werden so viele Knoten in ein Layer 2-Netz geworfen, wenn diese dann doch spaeter per DHCP
verschiedene/mehrere Gateways zugeordnet bekommen? Die Gateways stehen ja alle im gleichen Netz.
Koennte man nicht die fastd-Verbindungen auf die zugeordneten (in verschiedenen Netzen befindlichen) Gateways tunneln und zwischen den “Gatewaynetzen” routen? Oder ist das genau das, was ihr unter Split versteht?
Der Vorteil von Layer 2 ist, dass die Anwendungen und Geräte sich so vorkommen als wären sie alle an einem gemeinsamen Switch angeschlossen. Das ist zugleich auch der Nachteil.
Irgendwann kommt eine Grenze, wo kleinere Uplinks dann nur noch damit beschäftigt sind Daten hin und her zu schieben, die von irgendwo im Netz kommen und sie gar nicht interessieren. Dann muss man das Netz teilen und zwischen den Teilen routen. Der Vorteil dabei: Das Grundrauschen wird weniger und die Knoten müssen sich nicht mehr mit Zeug plagen was sie nichts angeht. Aber natürlich können dann zwei Knoten nicht mehr meshen, die nicht im gleichen Segment sind. Also muss man es regional aufteilen und hat eine neue Engstelle: den Router, der zwischen den Segmenten vermittelt.
Im Sinne der Offenheit des Netzes ist Layer2 toll und man kann wirklich ALLES machen, ohne Einschränkungen. Aber das Grundrauschen im Netz ist auch eine ständige Belastung alle Knoten (Rechenleistung) und der Uplinks (Bandbreite)
Wann man den Zeitpunkt für einen Schnitt legt ist eben “Glaubenssache” … es hat beides seine Vor und Nachteile. @leah sieht den Zeitpunkt aus Sicht des Netzes noch nicht, aber es würde natürlich auch den Bug umgehen helfen, der bei 1500 Clients Online zur Zeit alles etwas stresst… Wohlgemerkt, der BUG ist das Problem und nicht die Anzahl an Knoten oder Clients… aber die Auswirkungen des Bugs sieht man eben nicht, wenn man die Netze klein macht und immer unter der Anzahl an Nutzern bleibt. Dafür hat das dann aber zu Folge, dass man an anderer Stelle mehr Aufwand hat (Firmware für jedes Segment, Routing zwischen den Segmenten). Auch wenn Richtfunkstrecken über die Segmentgrenzen hinweg gehen wird es komplexer.
Vorweg: Die Zukunft wird darauf hinauslaufen, dass auf layer3 geroutet wird.
Eine Schwierigkeit bei layer3 liegt darin, dass du halt die Netze nicht beliebig groß machen kannst. Aktuell ist es noch recht egal, ob hinter einem Knoten eine Flüchtlingsunterkunft, Jugendtreff oder die Wohnung der Großeltern hängt. Wenn du jetzt jedem Knoten sein eigens Subnetz geben willst, bräuchten wir die Information, wie viele Clients reinpassen sollen. Weiterhin verschenken wir bei jedem Subnetz drei IPs für Netzadresse, Gateway und Broadcast.
Bei IPv6 könnte man jedem Knoten sein eigenes /64er geben und als Verein/ISP sich ein /32er beschaffen. Damit hätten wir dann Platz für ~4,2Milliarden Knoten. Aktuell hat @leah ein /56er IPv6-Netz (Infos ausm Whois). Darin können wir nur 256 (nicht 8) /64er unterbringen. Es würde sicherlich nicht weh tun, die Subnetzgröße zu verkleinern, um dann mehr Knoten in das /56er zu bekommen. Dummerweise wurde mal die kleinste Netzgröße auf /64 (2^64 Clients!) festgelegt. Wegen so Dingen wie Stateless Address Autoconfiguration werden wir um ein /64er für jeden Knoten nicht so einfach herum kommen. Bei tunnelbroker.com bekommt man /48er Netze. Das kann bedeuten, dass man eine solche Netzgröße auch bei anderen Providern ohne Tunnel bekommen kann. Darin könnten wir dann 65536 Knoten unterbringen. Das Routing müsste dann mit OSPF funktionieren. Was noch fehlt, ist eine zentrale Instanz, von der jeder Knoten sein Netz zugewiesen bekommt.
Soweit ich es mitbekommen habe, hat Batman die Aufgabe, layer2-Pakete mit viel Intelligenz zu routen. Das ganze noch möglichst automagisch, performant und robust. Dazu muss es halt jeden Client und das komplette Netz kennen. Batman wurde eigens für den Einsatz bei Freifunk entwickelt.
Ich denke mal, dass ein brauchbareres Konzept rauskommt, wenn ich mir etwas mehr Zeit lasse und mit anderen darüber diskutiere. Wenn ich mal mehr Zeit habe, wollte ich mal NAT64 ausprobieren. Dabei wird IPv4 im eigenen Netz komplett verzichtet und zu IPv4-only Hosts draußen genattet. Das setzt dann voraus, dass alle Clients IPv6 können. Ich glaube nicht, dass wir so schnell auf IPv4 intern verzichten können.
Eigentlich ist alles schon richtig, was hier gesagt wurde. Das Problem lässt sich aber relativ einfach erklären:
Es gab bisher einfach kein L3 Mesh Routing Protokoll das performant genug ist. Inzwischen gibt es ein neues Protokoll mit dem Namen babel. Dazu gibt es an anderer Stelle schon erste Versuche und Bemühungen das in Gluon zu integrieren. Das ist aber alles nicht so einfach und wird noch Zeit in anspruch nehmen. Eine schöne Erklärung findet ihr hier im Artikel von einem der Gluon Kern Entwickler: https://www.nilsschneider.net/2016/04/10/babel-in-gluon.html
Danke, ich les mich gerade in Layer 3-Meshing ein, muss doch besser gehen.