Hi, im Thread "Grundrauschen, Netsplit etc." haben wir festgestellt, dass wir für das Overhead Problem schnellstmöglich ein Übergangsnetz umsetzen müssen bevor wir nach einer nachhaltigen und langfristigen Lösung suchen. Damit mögliche Lösungen jeder nachvollziehen und verstehen kann, habe ich auch dafür wieder ein Pad angelegt um ein solches Netz zu konzipieren: https://pad.freifunk.net/p/ffnw-uebergangsnetz Bitte ergänzen und bisherige Ideen und Ergebnisse dort eintragen. Viele Grüße Clemens
Hi, ich denke in einem Pad können wir die Aufgaben und Ideen relativ einfach verwalten. Habe auch mal ein paar Kleinigkeiten hinzugeschrieben. Im Endeffekt sind es ja nur 2-3 Anpassungen an der Firmware und die ensprechende Config der Gateways - dies sollten wir wirklich sehr zeitnah anpeilen. -- Viele Grüße, Stefan Am 28.07.2015 um 15:41 schrieb Clemens John:
Hi,
im Thread "Grundrauschen, Netsplit etc." haben wir festgestellt, dass wir für das Overhead Problem schnellstmöglich ein Übergangsnetz umsetzen müssen bevor wir nach einer nachhaltigen und langfristigen Lösung suchen.
Damit mögliche Lösungen jeder nachvollziehen und verstehen kann, habe ich auch dafür wieder ein Pad angelegt um ein solches Netz zu konzipieren:
https://pad.freifunk.net/p/ffnw-uebergangsnetz
Bitte ergänzen und bisherige Ideen und Ergebnisse dort eintragen.
Viele Grüße Clemens
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hoi, Am Dienstag, den 28.07.2015, 15:41 +0200 schrieb Clemens John:
Hi,
im Thread "Grundrauschen, Netsplit etc." haben wir festgestellt, dass wir für das Overhead Problem schnellstmöglich ein Übergangsnetz umsetzen müssen bevor wir nach einer nachhaltigen und langfristigen Lösung suchen.
Die Idee des Bridged Setups mit Bridge Loop Avoidance hat sich als Fail erwiesen - die folge war ein massiver Trafficanstieg bis hin zur kompletten Auslastung der Server, sodass sogar SSH-Sessions hingen. Idee nun: Hoodsystem ähnlich der Franken, mit GRE-Tunnel zwischen den Supernodes und iBGP (oder OSPF?) auf den GRE-Tunneln. Aus dem /48-Prefix vom Rheinland könnte man für jede Supernode ein /64 nehmen und dazwischen ebenso routen, Netmon müsste dann die Router per Public Ipv6 abfragen (Stefan will sich darum kümmern). Die Meshviewer -Daten müssten dann jeweils gemerged werden. Zwecks Sicherstellung des Roamings würde es IMHO Sinn machen, wenn VPN -Server durchaus regional sind. vg bjo [0]https://wiki.freifunk-franken.de/w/Portal:Netz -- xmpp bjo@schafweide.org
Hi, Am 04.08.2015 um 23:49 schrieb Bjoern Franke:
(Stefan will sich darum kümmern). Die Meshviewer Sofern der Prefix gleich bleibt, habe ich schon eine Lösung - wenn dieser pro GW anders sein sollte, müssten wir uns was anderes überlegen.
-Daten müssten dann jeweils gemerged werden. Meshviewer sammelt direkt per Alfred die Daten der VPNs - diese sind auch anhand der MAC schon angegeben. Wir bräuchten hier nichts ändern.
-- Viele Grüße, Stefan
Am 04.08.2015 um 23:49 schrieb Bjoern Franke:
Idee nun: Hoodsystem ähnlich der Franken, mit GRE-Tunnel zwischen den Supernodes und iBGP (oder OSPF?) auf den GRE-Tunneln. ich bin für direkte verbindung zwischen den SN. ohne zu wissen wie was geht. aus last und traffic sicht für die SN wird es weniger sein wie mit dem alten setup. vermute ich.
mit der hoodverwaltung und überlegung der größen sehe ich einen größeren verwaltungs aufwand wie jetzt. aber es scheint eine bessere aufteilung möglich zu sein.
participants (4)
-
Bjoern Franke -
Clemens John -
picard -
Stefan