Drosselungen beginnen - Freifunk an solchen Anschlüssel kaum nutzbar

Hallo,

jetzt wird es interessant, ob die Technikabteilung das Grundrauschen in den Griff bekommt. Bei O2 gibt es in den günstigsten Tarifen nur noch 100 GB und das Grundrauschen frisst davon 60 GB. 40 GB dürfte wohl für jeden eng werden.

Grüße
MPW

1 Like

Das ist kein Bug, das ist ein Feature

1 Like

Wie ich immer sage: Mit BATMAN nicht. Das Flooden der OGM-Pakete im ganzen Netzwerk ist zwingend notwendig für die Funktion des Protokolls. :wink:

Noch ein Grund mehr nicht zu O2 zu gehen.

3 Likes

Und falls man noch Kunde ist sofort zu kündigen.

3 Likes

Üblicherweise verstehen manche den Kunden erst, wenn er kündigt.

2 Likes

Ja, mit nem DSL Lite ist Freifunk im Vollumfang schwierig.

Klar muss das OGM sein, aber könnte man nicht für den VPN Uplink die Multicast-Rate (oder wie hieß das nochmal) ändern? Die Änderungen über VPN dürften doch ruhig träger übertragen werden (bzw. sollten eben deswegen vielleicht sogar).

Ähm ich sehe gerade orig_interval im batmanconfigfile.
War das zuletzt nicht noch 12000? Jetzt sehe ich hier 5000 stehen. Das ist doch die Rate in Millisekunden, oder vertausch ich jetzt was?

2 Likes

Ich werdet es auch noch verstehen, wenn die ersten Knoten abgeschaltet werden. „Entschuldige, aber das verbraucht meinen ganzen Traffic.“ :wink: Nicht böse gemeint, wird aber passieren. Ich persönlich würde auch nie einen gedrosselten Vertrag abschließen. Aber darum geht es ja nicht.

Ich wäre auch dafür die Multicast-Pakete nicht über VPN/DSL zu schicken.

Beispiel:

Haus1: Router A

Haus2: Router B <-> Router C

Wozu musst Router C wissen, wo Router A steht? Alles was er in seinem lokalen LAN/WLAN nicht findet, geht ohnehin ans Gateway. Auch so, wie es derzeit implementiert ist.

Meiner Logik nach reicht es also vollkommen, alles, was er lokal nicht findet, ans Gateway zu schicken. Das Gateway muss es ohnehin weiterleiten.

Es würde mich technisch sehr interessieren, warum das nicht machbar sein sollte?

1 Like

Dann müsste halt jeder Mesh-VPN-Knoten ein eigenes Subnetz haben und IP-Adressen der lokalen Wolke verwalten. Dann braucht man also auf jedem Gateway-Knoten einen DHCPd, und bei mehreren VPNs müssen die sich noch abstimmen, wer jetzt den DHCP macht (und wenn einer ausfällt muss es dann Failover geben, jeder bekommt dann neue IPs). Das hatte man früher in Rheinufer mal, da hießen die Gateways Queens und das lief nie so richtig 100% gut :wink: (aber ehrlich gesagt in der Praxis doch besser als man es annehmen würde)

Ich weiß nicht, ob das der primäre Grund ist, wieso man das nicht mehr so macht, aber das wäre schon einmal ein Grund.

Nö, man kann trotzdem für eine Community eindeutige IPs zentral an den Gateways vergeben. Es geht hier nur ums Routing.

Meines Wissens verursacht doch das „finden der besten Route“ in BATMAN die Grundlast. Wenn man BATMAN so konfiguriert, dass es über fastd nur prüft, ob die Verbindung zum Gateway da ist, surrt das zu einem Bruchteil zusammen.

Und trotzdem kann dann über WLAN alle 5 Sekunden (oder dann sogar häufiger) nach optimalen Routen gesucht werden.

Ich denke einfach, dass Mesh-on-VPN einfach gleichgesetzt wurde mit einem lokalen Mesh. Und das darf eben nicht sein.

Wie denn? Dafür muss ich erst einmal per DHCP die Knoten, die IPs haben wollen adressieren können. Wie mach ich das ohne die MAC-Adressen zu kennen?

Zumindestens das Gateway muss die gesamte Topologie des Netzes kennen. Dafür braucht zumindest das Gateway alle Infos vom Mesh-VPN-Knoten.

Okay, hier kommen wir der Sache endlich mal näher. Dazu hätte ich spontan folgende Idee:

Jeder fastd-Client merkt sich alle anhängenden Macs und meldet nur noch neue und nicht mehr vorhandene Geräte nach oben.

D.h. nur, wenn sich etwas ändert, wird auch Traffic verbraucht. Statt das Rad alle 5 Sekunden neu zu erfinden.

Ich habe hier den Eindruck, dass ständig Layer2 und Layer3 durcheinandergebracht werden. Deshalb hier in Kürze was ein L3 Netz bedeuten würde.

Im Layer3 Netz hat jeder Router disjunkte IP-Adressen. Das bedeutet jeder Router benötigt eine einzigartige, angepasste Konfiguration. Jeder Client bekommt je nach Router eine andere IP-Adresse zugewiesen.

Die Kommunikation in einem solchen Netz bedingt Routing. Im einfachsten Fall eine statische default Route, die auf einen default Router (Gateway) zeigt. Dann ist es aber aus mit Meshing. Die einzelnen Router „wissen“ nichts voneinander, sie kennen nur das Gateway. Es wird also ein dynamisches Routing Protokoll (Bsp. OSPF,ISIS…) benötigt. Bei jeder Tolologieänderung des Netzes werden dann entsprechende Informationen (z.B. Link State Advertisements (LSA) bei OSPF) in das Netz geflutet.

Inwieweit MASH Routingprotokolle im L3 arbeiten entzieht sich meiner Kenntnis.

Zusammenfassung: EInfach Router flashen und anstöpseln ist im Layer3-Netz nicht mehr möglich, da jeder Router eine angepasste Konfiguration benötigt.

Es geht nicht um Layer3 oder 2, Layer2 ist schon ziemlich gut hierfür geeignet. Es geht darum das Routingprotokoll über DSL effizienter zu machen.

Und für mich persönlich geht es einfach auch darum, zu verstehen, was wie warum genauso gemacht wurde, wie es ist.

Sorry, dann habe ich das wohl falsch verstanden. Jedoch liessen mich Formulierungen wie „eigenes Subnetz haben und IP-Adressen der lokalen Wolke verwalten“ und „Es geht hier nur ums Routing.“ annehmen das Layer3 Netze gemeint seien.

Das war nicht mein Vorschlag.

Ich habe lediglich gefragt, warum man nicht statt alle 5 Sekunden alles zu übertragen, einfach nur die Änderungen senden kann.

Vllt. müsste man auch einfach mal diesen Traffic genau analysieren, und gucken, was wirklich diese 20-30 KB/s sind. Denn das ist ja mehr z.B. als ein VoIP-Telefonat. Da muss ja schon was drin sein.

Oder hat das Mal jemand gemacht?

Ist der Tarif soviel günstiger, dass sich die Akzeptanz so einer Maßnahme lohnt? o_o

Darum geht es nicht, früher oder später werden Leute deswegen Router bei sich nicht aufstellen, oder sogar abbauen.

Dir geht es im Konkreten um die Effizienz des Batman MESH-Protokolls, richtig?

Richtig. Ich möchte gerne verstehen, warum das Grundrauschen wirklich in dem Maß notwendig ist und ggfs. überlegen, ob man das nicht effizienter machen kann.

Mir ist das auch wichtig, wenn mal ein Knotenaufsteller nachfragt, warum der Router so viel Traffic verursacht.

Ich denke es geht darum, wie man BATMAN datensparsamer realisieren könnte buw. konfigurieren.