Änderungen im Ruhrgebiets-Netz

Hallo zusammen,

ich habe wie angekündigt gestern und heute daran gearbeitet das Ruhrgebiets Netz umzubauen.

Die bisherigen Supernodes ffrg0 und ffrg1 bedienen zukünftig nur noch die alten 0.4er Nodes.

Neu hinzugekommen sind die Supernodes ffrl-ffrg0 und ffrl-ffrg1 welche bei IN-Berlin gehostet werden.

Auch wenn es von den Namen ein wenig verwirrend sein mag, diese reagieren zukünftig auf den fqdn ffrg0.freifunk-ruhrgebiet.de und ffrg1.freifunk-ruhrgebiet.de während die beiden alten Supernodes zu ffrg004 und ffrg104 geworden sind.

Entsprechende DNS Einträge wurden bereits umgestellt, so dass nun sukzessive die jüngeren Nodes auf die beiden neuen Supernodes bei IN-Berlin umziehen werden.

Darüber hinaus wurde fastd nun getrennt in eine Client und eine Server Session. Fortan laufen nun zwei unterschiedliche fastd Prozesse pro Server auf unterschiedlichen Ports. Der fastd Prozess für die Clients bleibt unverändert auf Port 10.000.

Parallel habe ich noch in allen fastd.conf einen Unix Socket angelegt, der es mir nun zukünftig erlaubt alle Sitzungen mit sämtlichen Daten zu sehen. Derzeit kann ich davon leider nichts zeigen, da zunächst die Daten gefiltert werden müssen, da diese einen direkten Zusammenhang zwischen IP-Adressen der benutzten Leitungen, Mac-Adressen und Node-Namen herstellen - genau das was nie irgendwo auftauchen darf…

Beste Grüße

Chris

5 Likes

Wieso wurde das so gemacht? Welche Vorteile bring es mit sich?

Klasse, das Netz reagiert hier wesentlich direkter als vor 2 Tagen.

2 Likes

Meine Vermutung(!): Um Licht in die Blackbox zu bringen.
Wir leiden derzeit an Instabilitäten im Netz, ohne dass klar wird, wo der Wurm drin ist.
Für Debbing ist es unerlässlich, dass man hier und da ggf. einen Abgriffspunkt hat, damit man sehen kann, warum es holpert. (Und ggf. auch im Rahmen des Allgemeinwohls einzelne Nodes/Sessions aussperren zu können, ohne dafür das ganz große Besteck auffahren zu müssen.)

1 Like

…zusätzlich hatte das nun aber darüber hinaus auch noch einen direkten Nutzen, nämlich das wir in Clientrichtung den selben fastd Key auf ffrg0/1 und ffrl-ffrg0/1 benutzen können, damit die Tunnel der Clients/Nodes sich nahtlos auf beiden anmelden können, während alle Supernodes mit unterschiedlichen Keys zum Traffic ins Internet bringen zeitgleich die Tunnel zu bb0 offen haben…das geht im fastd nämlich sonst nicht, der letzte Server mit identischem Key bekommt den Tunnel, der andere wird gekickt…

Hat da wer das Netz gekillt? http://map.freifunk-ruhrgebiet.de/graph.html keine Hosts, über meinen FF Router komme ich nimmer raus…
Ich geh schlafen und ihr macht das wieder heile, ja?? Dankööö :smile:

Wie heisst der Router Martin?

Hast Du den mal neugestartet?

Heute morgen ist wieder alles okay. Ich habe auch über mein normales WLAN surfen können, die Karte war komplett leer bis auf einen Host…
Meiner ist der FF-Ham-Ammerweg

Ja, hab ich noch mit einem Auge gesehen, bevor die Map Daten wieder da waren - ich halte Dich nicht für verrückt, keine Sorge :wink:

Kam mir gestern Abend so vor als würde batman die Routen untereinander ständig neu lernen, dann war die Map kurz weg, aber auch nach kurzer Zeit wieder da…

Wie bereits in einem anderen Thread geschrieben, habe ich derzeit keine Ahnung was da im batman los ist.

Ich werde die Frage mal im Backbone und Gluon Team offen zur Disposition stellen, vielleicht hat noch jemand eine Idee :frowning:

1 Like

Zumindest meine Vermutung geht immernoch darauf, dass sich im Netz mehr als ein Alfred-Master befindet.
(Technisch ist das zulässig, nur in der Praxis scheinen die ab einer Netzgröße von gefühlt 100 Nodes die Master nicht mehr zuverlässig synchronisieren)

tcpdump -i br-client -n udp port 16962

fe80::200c:44ff:fe94:55c7.16962 > ff02::1.16962: UDP, length 4
fe80::3007:96ff:fec2:802b.16962 > ff02::1.16962: UDP, length 4
fe80::50ea:3bff:fe44:b080.16962 > ff02::1.16962: UDP, length 4
fe80::98ec:26ff:fe2e:3113.16962 > ff02::1.16962: UDP, length 4
fe80::9c07:25ff:fe7d:4a1c.16962 > ff02::1.16962: UDP, length 4
fe80::b824:9eff:fe22:16e4.16962 > ff02::1.16962: UDP, length 4
fe80::c99:b6ff:fe86:f449.16962 > ff02::1.16962: UDP, length 4
fe80::ea94:f6ff:fe63:960.16962 > fe80::c99:b6ff:fe86:f449.16962:

Bei uns ist jede Supernode + der Map Server Alfred Master…

Folgende Dinge werde ich heute im Laufe des Tages umstellen:

  • Alfred Master ist zukünftig nur noch der Map Server
  • tap1 auf allen Supernodes bekommt einen eigenen Mac Adressen Kreis

Danach werde ich dann versuchen die Erklärung dafür zu finden:

  • warum batman der Meinung ist, dass externe (nicht Supernodes!) Systeme eine Brücke zwischen tap0 und tap1 haben und über diese die Supernodes untereinander erreichbar sind

Ich denke dann sind wir zumindest einen Schritt weiter…

1 Like

Dann drücke ich mal die Daumen.

Das betrifft dann „nur“ ruhrgebiet oder auch rheinufer?

Alles natürlich nur das Ruhrgebiet!

Da bb0 halbwegs autark läuft und ich da nicht ran muss, sind die anderen Domänen davon nicht betroffen.

Aber ich erwarte keine Ausfälle während der Umstellung, wenn überhaupt dann dass die Map immer mal wieder nicht läuft.

was bedeutet das? tap0/1?

Das bedeutet, dass es sich um Maschinen handelt mit einem vernünftigen Kernel (und es keine ganz billigen vps sind)

Sieht sehr gut aus, bin soeben mit allen Änderungen fertig geworden.

Hinzu gekommen sind noch ein paar Aufräumarbeiten und das vorbereitende Senden einer MTU von 1280 über den dnsmasq, um zukünftig keine Probleme mit dem IPv6 zu bekommen, wenn wir uns auf das neue Backbone aufschalten.

Wenn ihr könnt, dann testet mal:

  • wie schnell bekommen Clients an den Nodes IP-Adressen
  • wie performant ist der Zugang ins Internet
  • funktioniert IPv6 einwandfrei auch beim Zugriff vom Internet aus
  • und was euch sonst noch zum Testen einfällt
3 Likes

Danke für die Mühen.
Werde dann mal meinen Wackelnode anwerfen.

1 Like

mein Node ff-kk-reka ist seit heut Vormittag down und ich habe gehofft, es liegt an den Arbeiten am Netz. :frowning:

Aus der Ferne kann ich nur sehen, dass die Fritzbox davor arbeitet und der Node von der Fritzbox ne IP bekommen hat und eigentlich laufen müsste. Heute Abend lasse ich dann mal physisch Hand anlegen…

Hmmm, welche Firmware ist denn da drauf?