Für Ennigerloh prüfen wir gerade, inwieweit wir hier vor Ort was auf die Beine stellen können.
Wenn man den Kreis Borken auf der Karte mal betrachtet fällt einem schnell auf, das in den größten Städten (Bocholt,Borken,Ahaus…) noch kaum was los ist. Wenn die erstmal kommen kann man das mit Gebieten IMHO kaum noch realisieren. Ich glaube auch, das es sinnvoller ist, Städte, die jetzt schon eine höhere knotendichte haben rauszunehmen.
Und dann muss man natürlich auch klären, wie man sowas finanziert bekommt…
aus Neugierde: Wie genau sieht das aus?
2 „Gefällt mir“
Wie schon oben geschrieben finde ich das Modell einzelne Städte herauszunehmen gut. Jedoch ist es imho die Entscheidung der WML Community, wie sie aufteilen wollen.
Ist mir doch egal. Ich kenne mich dort nicht aus, habe die daher erstmal so genannt.
Jap, Grundlage sollte schon der IST-Zustand sein. Aber auch dort ist WML schon so groß, dass man mit Überlegungen beginnen sollte.
Die Frage ist, wie viel Traffic wir durch einen Host so schießen wollen. Ich denke spätestens nach dem nächsten Monat auf unserer „neuen“ Infrastruktur werden wir merken, dass wir für den ganzen Traffic noch etwas mehr Geld in die Hand nehmen müssen. Und dann kommen wir zur Frage: Machen wir Multi-Batman und zahlen dann extra für den Traffic. Oder mieten wir weitere Bleche und nutzen jeweils den Inklusiv-Traffic. Wir können uns natürlich jetzt vorwerfen lassen, dass wir auf Hoster setzen die keine volle Traffic-Flatrate anbieten, wir können dann aber auch gerne ausproieren, was passiert wenn wir bei einem Hoster mit Traffic-Flatrate sind und da ein paar Monate ordentlich was durchschieben. Entweder wir werden wieder zu irgendwelchen Urban-Legends, wie „Hoster xy drosselt wv-Pakete“ kommen oder wir werden rausgeworfen. Oder anders ausgedrückt: Meiner Meinung nach macht Multi-Batman Sinn, wenn wir in der derzeitigen Situation die Domänen einfach nur verkleinern wollen. Wenn wir das jedoch machen, um weiteres Wachstum zu verkraften, werden wir sehr schnell in die Traffic-Falle geraten.
Ja. Aber hier muss sich auch erst noch zeigen, ob das in der Praxis wirklich so funktioniert wie erdacht.
Ja, da bin ich optimistisch. Wir sollten nur noch mehr nach außen kommunizieren, dass die ganze Infrastruktur Geld kostet und das nicht irgendwo eine ominöse Wolke ist, die einfach da ist. Wenn wir von heute auf morgen sagen wir brauchen Geld, könnte das zu Unverständnis führen. Daher lieber die Leute jetzt schon für das Thema sensibilisieren.
1 „Gefällt mir“
@d00: Das Aachener-Modell sieht es vor, dass jede lokale Wolke automatisch separiert wird. Jeder kann mit jedem meschen, aber erst wenn zwei Wolken über die Luft meschen, werden sie auch am Gateway zusammen geschaltet.
Die Aachener bauen das gerade. Das ist dann defacto das Ende des Layer2-Netzes und funktioniert in der Theorie bis zu Wolkengrößen von 250-300 Knoten.
Ob die Flatrate bei MyLoc eine bleibt, werden wir denke ich schnell auf Greyworm merken. Da müsste ungefähr fast genauso viel durchgehen, wie durch Remü. @kgbvax, kannst du mal Statistiken zu dem Blech veröffentlichen?
Naja, ich habe das anders verstanden. Nicht JEDE Wolke wird separiert respektive bekommt ein eigenes Netz. Vielmehr gibt es dort eine Aufteilung ganz ähnlich wie bei uns. Der entscheidende Unterschied ist, dass die nicht für jede Domäne eine eigene Firmware backen wollen, sondern die Zuweisung serverseitig lösen wollen. Das macht einen unterschied von > 1000 Segmenten zu einigen Dutzend (am Anfang einem Dutzend) Segmenten.
Also im Grunde findet die Entscheidung immer noch aufgrund der Positionsdaten der Knoten statt. Jedoch macht es der Automatismus möglich Planquadratepolygone nach technischen Gegebenheiten zu wählen und man muss nicht darauf achten, dass die Unterteilungen für Außenstehende Sinn ergeben (so wie bei uns → Kreis- & Stadtgrenzen). Mit hin und her schalten ist gemeint, dass ein Knoten, der nach seinen Positionsdaten eigentlich in ein Segment A gehört, aber mit Nodes aus Segment B mesht nach Segment B verschoben wird. Bei der Segmentierung sind nur VPN-Nodes relevant, weil alle Nodes mit Allen meshen können. Und solange alle VPN-„Erdungen“ einer lokalen Wolke im selben Segment sind, geht alles gut. Also bilden die Knoten einer lokalen Wolke kein eigenes Segment, sondern SIND (mit anderen) in einem Segment. Genau das (also lokale Meshwolke hat einer stärkere Bindung als die Geo-Position) findet im Übrigen in unserem Migrationsscript auch schon Berücksichtigung.
Das ist für mich jedoch nur eine (in der Umsetzung natürlich nicht zu vernachlässigende) Randnotiz. Wesentlich ist halt, dass deren Infrastruktur wohl ganz ähnlich (von layer2 segmentation sind die abgerückt und machen jetzt auch layer3 routing) wie unsere Aufgebaut ist, „nur“ dass deren Black-&White-Listing ein „bisschen“ Magie enthält, dafür aber nur eine Firmware ausgeliefert werden muss.
Nachdem ich bei dem zuvor berichteten eher skeptisch war, bin ich jetzt sehr angetan von dieser Lösung. Ich bin dafür, dass wir ebenfalls in dieses Experiment einsteigen. Ich denke da können sich gute Synergien ergeben. Das ein oder andere haben wir ja auch schon gelernt in Bezug auf Routing und Systeme mit mehr als einer Handvoll VMs zu fahren. 
Falls dieser Kurswechselkorrektur auf breite Ablehnung stoßen sollte, bliebe uns noch die Möglichkeit die Firmwaremigration weiter zu automatisieren. Ich denke, dass wir nun ausreichend Erfahrungen gesammelt haben um den Vorgang nahezu automatisch ablaufen zu lassen. Es würde sicherlich ein paar weitere Zeilen Code benötigen, aber sich im Rahmen des Machbaren bewegen. Jedoch zieht diese Vorgehensweise einen ganzen Rattenschwanz negativen Aspekten hinter sich her; es muss diverse Firmware gebaut werden;es muss Firmware getestet werden;es muss Firmware signiert werden;der Knotenbetreiber muss herausfinden, welche Firmware er braucht…
Meine Idee wäre, das in einer Domäne, die zeitnah unterteilt werden soll zu testen. Also natürlich nur mit ausgewählten Knoten.
Au ja! Das probiere ich auch mal: einfach anhand der mac Adresse des Knoten entscheiden, dass der in eine andere Wolke kommt. Kann man anfangs ja statisch machen. Muss dafür aber den DHCP Server für jede Wolke einen Range geben. Das wird bestimmt lustig!
Wie gesagt, die haben genau so wie wir Domänen. Alles gleich. Nur wollen die mit einer FW auskommen, indem die Knoten sich nur mit bestimmten fastd Instanzen verbinden dürfen.
Hier deren Ansatz in Code: GitHub - ffac/segmenter: Superseded by Autosegmenter - which works for Wireguard
PS: Ich bin mir gerade nicht sicher, inwieweit dein Beitrag ironisch gemeint ist.
Du kannst lachen, sobald ich damit fertig bin… danke für den Link.
Hö??? Ich dachte du würdest das „Aachener Modell“ aus irgendeinem Grund bescheuert finden. Ich finde es toll
Die Aachener haben es nur ein bisschen schwerer als mit einer l2tp-Lösung. Dort (in der L2TP-Lösung) wird folgendes Skript genutzt, wann immer ein tunnel online kommt:
Tue, 02 Feb 2016 21:26:13 DEBUG Executing hook 'session.up' via script '/srv/tunneldigger/scripts/bataddif.sh ['190', '1', 'l2tp1901', '1446', 'A.B.C.D', '37730', '15190', '60e327xxxxxx']'.
l2tp1901 ist das entstandene Tunnel-Interface und 60e327xxxxxx die MAC-Adresse. In dem Scrip kann man Interface dann wahlweise in das eine oder das andere Batman-Interface aufnehmen und so verschiedene Broadcast-Domains (mit verschiedenen IP-Ranges) laufen lassen. Können erstmal immer alle in deine Default-Domäne, und dann bei Bedarf in eine eigene geschupst werden. Wenn zwei so Domänen meshen, dann sollte das nicht soo schlimm sein, und der „Störenfried“ sollte auch ausgeschlossen werden können, indem man ihn in eine tote Domäne meshen lässt… Fast fertig, oder? Und da die L2TP Variante auch auf dem Server keine Last macht, kann man so einem Server auch mächtig viele Clients abbügeln. Denke das gesamte Münsterland, wenn man irgendwo einen Server mit 10G-Interface unterbekommt.
Ah jo, daran habe ich ja noch gar nicht gedacht. Es wächst zusammen, was zusammen gehört.
Bist du am Mittwoch in der WZ? Dann können wir mal drüber sprechen, wie wir unsere „Forschungen“ in diesem Gebiet fortsetzen.
Das Problem an Paulos Vorschlag dürfte sein, dass Batman regelmäßig abschmiert, wenn man ein Interface entfernt. Aber in der Theorie ein sehr geiler Vorschlag.
Ich entferne keine Interfaces aus dem Batman. Immer geht das l2tp über eine Bridge die permanent drin hängt. Siehe tunneldigger Thread im Freifunk.net Forum. Auszüge von ffwaf-srv3:
#
# dummy, nur für mac im batman
#
auto supernode
iface supernode inet manual
pre-up ip link add $IFACE type dummy
pre-up ip link set address de:ad:be:ef:43:03 dev $IFACE
pre-up ip link set $IFACE up
post-down ip link delete $IFACE
dann:
auto l2tp-vpn
iface l2tp-vpn inet manual
pre-up ip link add $IFACE type bridge
pre-up ebtables -A FORWARD --logical-in $IFACE -j DROP
pre-up ip link set dev $IFACE up
post-down ip link del $IFACE
post-down ebtables -D FORWARD --logical-in $IFACE -j DROP
dann:
iface bat0 inet manual
pre-up modprobe batman-adv
pre-up ip link add $IFACE type batadv
pre-up batctl -m $IFACE bl 1
pre-up ip link set address b2:92:3f:f5:af:4e dev $IFACE
pre-up ip link set dev $IFACE promisc on
pre-up ip addr add 10.43.112.6/21 broadcast 10.43.119.255 dev $IFACE
post-up ip route replace 10.43.112.0/21 dev $IFACE table ffnet
pre-up ip rule add iif $IFACE table ffnet
pre-up ip link set $IFACE up
post-up batctl gw server 1024Mbit/1024Mbit
post-up batctl if add supernode
post-up batctl if add l2tp-vpn || true
post-down ip link del $IFACE || true
post-down ip rule del iif $IFACE table ffnet
Beim start vom fastd wird das übliche mesh-vpn in das Batman-Interface eingetragen, Kommt ein fasdt-Tunnel hoch, wird es in das mesh-vpn Interface eingehängt. Kommt ein L2TP-Tunnel hoch, wird es in das l2tp-vpn Interface eingehängt.
Natürlich können verschiedene batX Interface angelegt werden, in denen jeweils ein l2tp-vpnX Interface hängt. Der hook ‘session.up’ hängt neue l2tp-Interfaces immer in eines der l2tp-vpnX. Fertig sind die verschiedenen Broadcast-Domänen. In jeder hängt ein DHCP-Server und vergibt aus dem Zugewiesenen Netz IP-Adressen.
Ein Profi erledigt sowas in fünf Minuten.
3 „Gefällt mir“
@WMLer Pläne?
War es nicht Konsens, dass (wenn bis Osten wirklich Bocholt knapp 200 Router hat) die direkt raus genommen werden? Und dann vielleicht noch stadtlohn und Borken könnte bald auch verdammt schnell explodieren.
Im Moment ist erstmal alles top. Wir müssen meiner Meinung nach da jetzt keinen unnötigen Schnellschuss machen.
Wir sollten da am besten in einer Runde darüber sprechen. Vllt. Können ja ein paar Leute am nächsten Mittwoch mit nach Münster ?!!? @BauerJup
@desmaster @guido_spoltmann @Karsten
2 „Gefällt mir“
Wenn alles gut geht, werde ich Mittwoch in MS sein, da es dann von meiner Arbeit recht gut klappt.
1 „Gefällt mir“
Wenn jemand ein Plätzchen im Auto frei hat, fahr ich auch gerne mit.
1 „Gefällt mir“