[wlanfhain] Re: olsr.freifunk.net / kanal / IPs

[Jens Nachtigall]

> da in fhain nur 4 cubes betroffen sind schlage ich vor, dass wir alle
> auf kanal 10 umstellen. im wiki habe ich das schon eingetragen. ok?

Meine wrts laufen jetzt auch auf Kanal 10.

>
> eine andere idee waere, den kanal in die essid einzubinden, also z.b.
> olsr10.freifunk.net, olsr6.freifunk.net olsr1.freifunk.net, ... damit
> haetten wir mehr flexibilitaet, an einem ort das mesh auf mehreren
> kanaelen zu verteilen, zb mit zwei verschiedenen wlan-karten und
> unterschiedlichen antennen.

Gute Idee. Das können wir dann immer noch nutzen, sobalb wir auf diese 
Flexibilität angewiesen sind.

> > das mit den ips sollten wir uns am mittwoch ueberlegen.
>
> hrm, dabei sind wir ja nicht wirklich zu einem ende gekommen.

Soweit ich weiß, sollte das sowieso am _letzten_ Mittwoch im Monat 
besprochen werden, sprich kommenden Mittwoch. So wurde das auch sowohl 
hier als auch bei der Einsteigerpräsentation geäußert. Es dann 
plötzlich doch an diesem Mittwoch zu machen (von dem niemand weiß) 
hätte ich nicht gut gefunden.
 
> ich sehe 5 ansaetze:
>
> 1) egal: wenn in der olsrd.conf IP4BROAD 255.255.255.255 eingetragen
> ist, muessen die IP adressen nicht aus dem gleichen netz kommen, dh
> jeder kann irgendeine IP verwenden. vorteil -> keine vorgaben ->
> nachteil: man kann sich routing maessig ueberhaupt nicht auf das mesh
> einstellen, und wenn jemand eine IP oder ein netz verwendet, dass
> intern im lokalen netz auch existiert kommt es zu konflikten.
>
> 2) 10.x.y.z/8: derzeit von sven, conny, jens verwendet. -> nachteil:
> wird haeufig in internen LANS oder transit netzen verwendet (z.b: von
> juergen)
>
> 2) 10.10.y.z/16: ist durch das 10.10 besser routebar und gegen andere
> lokale netze abgrenzbar, dafuer haben wir nur 255x255 adressen, was
> aber vorerst mal genug ist.
>
> 3) 172.16.x.y/12: wird meiner erfahrung nach weniger haeufig in
> lokalen netzen verwendet und ist default konfiguration der cubes.
>
> 4) 1.x.y.z/8: ein nicht benutztes netz, wird von WIANA verwendet.
>
> 5) 104.x.x.x/8: vorschlag von count fuer das infrastrukturnetz, die
> adressen oder einen teil davon koennten wir im mesh verwenden.
>
> egal welches netz wir verwenden halte ich es fuer eine gute idee, pro
> bezirk eine nummer zu verteilen, damit wir die moeglichkeit haben,
> wenn notwendig einzelne meshes aufzuteilen, und auch einfach damit
> man ungefaehr einen anhaltspunkt hat, wo sich eine bestimmte IP
> befindet.

Das finde ich auch. Für mich wäre das kombinierbar mit counts Vorschlag. 
Jeder Hauptknoten kriegt einen IP-Bereich (abhängig vom Stadtbezirk 
oder anderen geogr. Grenzen wie Flüsse, Str., Kanal, S-Bahn). Innerhalb 
dieses IP-Bereiches kann jeder Hauptknoten dann einen best. Bereich zu 
Meshing nehmen. 
Vorteil:
Routingmäßig ist ein Übergang von cvens BerlinBackBone zum Mesh-Bereich 
leicht möglich. Der Hauptknoten muss im BBB nur seinen IP-Bereich 
verkünden, in dem auch der lokale Meshing-Bereich liegt. Wenn wir 
sagen, dass 172.16.x.x/12 Mesh-Bereich sein soll, dann ist ein Übergang 
vom BBB zum Meshing schwieriger, da der Meshing-Bereich so über ganz 
Berlin verteilt wäre.

Allerdings ist das jetzt alles Kaffeesatzleserei, da ich nicht weiß, was 
cven mit dem BBB vorhat. Soll eine Kommunikation zw. beiden Netzen 
möglich sein? Warum soll das BBB zwanghaft im Infrastruktur-Modus 
aufgebaut werden, was nicht sinnvoll ist [1]?


Jens



[1] http://article.gmane.org/gmane.org.freifunk.wlanware/343