[Freifunk-Bonn] Prinzip_Modell_2

[Jan Lühr]

Hallo,

Am 15.03.2011 um 21:24 schrieb eGeist:

> Am 15.03.2011 21:09, schrieb Jan Lühr:
>> Hallo,
> Hallo Jan,
>> 
>> Am 15.03.2011 um 19:16 schrieb eGeist:
>> 
>>> Hallo FF,
>>> Andere Variante.
>>> http://cerberon.net/~egeist/kbu/netzwerk-routing/modell_v1.1.jpg
>>> Kritik und Verbesserungsvorschläge erwünscht.
>>> 
>> 
>> Danke für Deine Mühe. Ich bevorzuge zwar eher yEd / Dia, aber im Grunde genommen erkenne ich schon, was Du planst. 
> ;) Wenigstens einer der schonmal erkennt was ich möchte. ;)
> 
>> Ich habe aber nach wie vor Bedenken, dass es sinnvoll ist, Nodes aus Köln, Bonn u.U. in der gleichen Broadcast / Anycast Domäne zu haben, da es effektiv kein Roaming zwischen ihnen geben wird (dafür sind die Nodes zu weit auseinander).
> 
> Das Problem sehe ich auch so, bzw. erkenne ich auch.
> 
>> Die Achilles-Ferse der Mesh-Cloud wird auf jeden Fall die Größe eben dieser Domänen sein und wir sollten nach Möglichkeit dort auf OSI-3 routen, wo wir es ohne Einschränkung können.
>> D.h. Es macht in meinen Augen keinen Sinn, zwischen den verschiedenen Wolken zu Bridgen - ein Routing zwischen Ihnen ist auf jeden Fall problemlos möglich.
> 
> Solange aber einige nodes im Umfeld noch keine direkte WLAN Ananbindung an einen
> anderen Node der Cloud haben, was natürlich möglich wird, wenn das Netz wächst,
> verbaut man sich aber durch Ausschluss dieser Nodes diese zukünftige Möglichkeit.


Nicht direkt - wenn wir so viele Nodes haben, dass wirklich ein Roaming zwischen Köln und Bonn möglich wird (also nicht: einzelne Richtfunkstrecke zum Load-Balacing, die man mit Routing abfackeln kann), können wirklich gut skalieren und das Problem existiert in der Form nicht.
Darüber hinaus: Auch wenn wir jetzt die Broadcast-Domänen trennen heißt dass nicht, dass wir sie in Zukunft nicht auf dem Server zusammenlegen (bridgen) können - nur anders herum ist schwierig ...

Alles Gute
Jan