Hallo, > On 23.04.2016, at 16:37, David Hopfmueller <[email protected]> wrote: > ... > Die Anforderungen von Nachbar-Knoten und Clients in diesem Konzept stehen > einander diametral gegenüber: Auf Interfaces zu anderen Knoten will OLSR > eindeutige IPs, die Clients sollen aber aber immer dieselbe verwenden können. > Ich teile Deine Einschätzung, Erich, dass der skizzierte Ansatz zumindest in > Verbindung mit OLSR mehr Probleme kreiert denn löst. Multi-SSID + ein > Overlay-Netz wären IMHO der richtige Ansatz, um diese Anforderungen sauber in > den Griff zu bekommen bzw. auseinander zu halten. Also ich sehe hier OLSR nicht anders als BGP/OSPF mit der eindeutigen “Router ID”, man hat ja sehr häufig mehrere Routen zu einem Nachbar, und doppelte Nachbarn erkennen Routing-Daemons ja auch problemlos. Die Probleme fangen dann an, wenn ich “schlau” bin, und meinem Client-AP traffic-shaping verpasse, und da aber mein Nachbar, vielleicht sogar mein Upstream mit dabei ist, weil der sich nicht an die “gedachte” upstream Einstellung hält.
Die meisten Routingfehler passieren ja, weil Router und Sysop sich nicht einig sind, was jetzt die “richtige” Route ist. > > ... > Insofern ist eine separate SSID mit eigener IPv4 + NAT bzw. einem > zusätzlichen IPv6-Prefix auf absehbare Zeit IMHO die einfachste und sauberste > Lösung, um Clients anzubinden. Solange wir immer /64 Linknetze haben, ist da immer ein wenig Platz :) KISS, wenn wir ein funktionierendes Mesh haben, lieber Probleme lösen, statt mit shaping, asym-Tunnel, usw. zu tricksen, ist die Unterscheidung Knoten/Client fast irrelevant. Muss halt auf Layer1/2 funktionieren für den Client. Also v6, worauf warten wir? *let’s go, let’s go*. Matthias ps: die “eindeutigen IPs zu Nachbarn sind ja temporal auf die Verbindung bezogen, die kann man beim reboot auch wechseln, no problemo. -- Discuss mailing list [email protected] https://lists.funkfeuer.at/mailman/listinfo/discuss
