[Berlin-wireless] Batman ADV auf Eth+Luft

[Bastian]

Hallo,

nachdem ich gestern noch ein bisschen im batman-Wiki gestöbert hatte,
glaub ich inzwischen batman-adv auf Ethernet muss nicht sein:

MTU sucks - zumindest wenn man den Wert nicht passend einstellen kann.
Wie z.B. bei unserer Ubiquiti und TP-Link Hardware bzw. Atheros-LAN
allgemein. Mehr als 1500 geht nicht, dann meckert das batman-adv
Kernel-Module zurecht wegen Fragmentierung. Benchmarks von einem
Kirchturm mit 'ungünstigen' MTU-Werten stehen noch aus...

Support your local Clients - zumindest hätte ich gern die Option mich
einfach an einen Switch-Port klemmen zu können ohne MTU anpassen zu
müssen, ein spezielles Kernel-Module zu laden oder sonstiges Mesh-Foo zu
sprechen. Das betrifft natürlich auch andere Clients wie z.B. den
VLAN/PoE-Switch mit management-interface oder irgendwelche anderen
Ethernet-Devices die in so einem Netz evtl. zukünftig angeschlossen
werden wollen...

Einleuchtend fand ich auch die FAQ [1] und die beiden ausführlichen BLA
Erläuterungen [2] & [3].

Das Ethernet wird also zum Backbone, der zentrale DHCP-Server (unser
Core-Router) braucht kein batman-adv sondern soll sauber via OLSR den
besten Gateway finden. Die batman-adv Nodes sind alle im Gateway-Mode
und annoncen "den selben Gateway".
Das Split-Horizon Problem (Siehe [3], Limited Horizon tests) wird
mindestens zwischen den 5Ghz und 2.4Ghz Nodes auftreten - die Frage ist
nur ob uns das überhaupt stört...

In der E-LOK hab ich momentan noch die WAN-Ports vermasht, mit üblen
Verrenkungen (batman-adv Proxy VM) den alten zentralen DHCP-Server
integriert und muss mich über MTU-Probleme aufregen. Nur noch bestimmte
Switch-Ports, naemlich die welche mit bat0 in einer Bridge hängen sind,
können von normalen Ethernet-Clients verwendet werden. Bei nächster
Gelegenheit werde ich das mal mit Backbone+BLA austesten.

Über eine Diskussion zum Thema batman-on-the-ethernet würde ich mich
beim nächsten MABB-Treffen sehr freuen!

[1]
http://www.open-mesh.org/projects/open-mesh/wiki/FAQ#batman-adv-bridge-loop-avoidance-questions
[1]
http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance-II
[3]
http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance-Testcases

Gruß
Bastian


On 01/04/2014 09:13 PM, Sven-Ola Tuecke wrote:
> Hey,
> 
> soweit ich aus den bisherigen Setups sehen kann, werden die OGMs auf 2.4
> mit 1MBit verteilt. Da dürfte der Packetloss zwischen Luft unter Ether
> keinen Unterschied machen. Und echt Bridge-Loop-Avoidance!? Ich hatte
> nicht auf'm Schirm, dass wir da noch Extra-Bridge-Interfaces brauchen wo
> so Rückkoppelungen auftreten können.
> 
> Aber egal - warum Probleme vordenken die noch gar nicht auftreten.
> Erstmal den Kram hochbekommen, dann testen, dann fixen.
> 
> Danke // Sven-Ola
> 
> Am 04.01.2014 18:48, schrieb Bastian:
>> Hallo Sven-Ola,
>>
>> wenn ich das richtig verstanden habe, sollte batman-adv beim
>> Vorhandensein von mehreren möglichen Pfaden immer den günstigeren
>> nehmen. Wenn also auf dem WLAN-Interface viel los ist, sinkt die
>> Qualität und LAN wird automatisch bevorzugt. Zumindest hat Elektra davon
>> mal was erwähnt.
>> Beim Setup fuer die E-LOK musste ich auf einem Knoten
>> "bridge_loop_avoidance" aktivieren, jetzt wird auch brav das LAN als
>> default route verwendet.
>>
>> Gruß
>> Bastian
> 
> 
> 
> 
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> 


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 555 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140105/a3c66a94/attachment.pgp>