[Freifunk-Bonn] Grüße aus Lübeck / Bad Schwartau

[Jan Lühr]

Hallo,

Am 11.01.2012 um 06:55 schrieb Bjoern Franke:

> Moin,
> 
>> 1) L2TP / Dynamische bridging / bridge-loop-avoidance (bla):
>> Wir denken, dass es prinzipiell mgl. wäre, die dynamisches
>> Bridging-Architektur mit L2TP umzusetzen. Hierbei könnte eine "VPN-Routing"
>> Variante erweitert werden. Vorteil von L2TP + routing (im Gegensatz zu tinc
>> oder vlan-ids): Einfachere Handling (kein Key-Austausch nötig) sowie die
>> bessere Skalierbarkeit (L2TP-Pakete gehen nur an die Hosts im
>> Bridge-Verbund und nicht an das gesamte Netz) Weiterhin gibt es von L2TP
>> eine Kernel-Implementation, die eine gute Performance liefern soll.
>> Nachteil (im vgl. zu tinc): l2tp verläuft zwischen 2 Nodes, d.h. die
>> VPN-Last wird zentral verteilt, während tinc p2p arbeitet. Ebenfalls haben
> 
> Welchen l2tp verwenden die Lübecker denn? xl2tp?

Bislang gibt es keine konkret verwendete Version. Alle Überlegungen sind konzeptionell (~> vgl. Lübecker Wiki)

> Haben die Lübecker oder ihr 
> Erfahrungen mit vtun? Tinc spinnt bei uns leider ab und an rum, wo dann nur 
> ein Restart des Daemons auf dem Gateway hilft.

Weiß ich Leider nicht. -> fup 2 freifunk.luebeck at asta.uni-luebeck.de?


>> die Lübecker Freifunker Kernel Panics bei l2tp beobachtet (es gibt jedoch
>> eine userland l2tp-Implementierung, bei der dieses Problem nicht existieren
>> soll) Denkbar wäre auch, das Netz via bla zu skalieren: Werden VPN und bat0
>> bridged, so werden keine (praktisch gesehen: einige wenige) batman-Pakete
>> über das VPN abgewickelt, s.d. hier weniger management-Overhead entsteht.
>> Diese Alternative haben die Oldenburger vor kurzem getestet - jedoch nur
>> mit mäßigem Erfolg (Details: Lübecker Freifunk-Mailingliste). Zudem kommt,
>> dass der Code selbst zur Zeit "im Fluss" ist und noch nicht alle Bedenken
>> ausgeräumt sind. Hier werden wir die Experimente aus Oldenburg weiter
>> verfolgen. Grundsätzlich sind wir zuversichtlich, die Skalierungsprobleme /
>> -bedenken auf die eine oder andere Art in den Griff zu bekommen. Da sich
>> beide Ansätze parallel  zur aktuell KBU-Netzarchitektur betreiben lassen
>> (insb. integriert), sind sie für uns kein Blocker.
> 
> Wir haben nun zuletzt bla2 getestet, es lief zwar runder als bla1, aber 
> produktiv lässt sich das wohl noch nicht einsetzen. Jedenfalls erwies sich 
> eine WLAN-Verbindung über drei Nodes und einer Strecke von 600m mit bla2 als 
> wesentlich instabiler als mit dem normalen 2011.4.0.
> 

Danke für die Info. :-)

Alles Gute
Jan