Performance Thread Rheinufer

Wer das möchte, der kann das tun. Auf der Kommandozeile. Und sich die Befehle dazu selbst zusammensuchen. (Und bei der Suche vielleicht nochmal ins Nachdenken kommen.)
Ich werde niemanden dazu anstiften.

Hi

wie sieht es denn bei fastd mit sowas wie AES-NI aus?
Ich hab das bisher nur für luks verwendet, aber ich glaub hab schon gut was gebracht. Keine Ahnung was fastd für n Crypto macht, aber so n bisschen hardwarebeschleunigung kann nie schaden.

FastD macht mit der neuen Firmware Salsa2012+UMAC.

Soweit ich es verstanden habe haben wir für das letzte Wochenende wichtige Erweiterungen des Backends auf der Agenda gehabt, die den Performance Problemen entgegentreten sollten.

Ist das geglückt? Wie kann man™ das nachvollziehen bzw. wie wird das gemessen und herausgestellt?

Viele Grüße, Fx

Menge laufender Gateways mit:

batctl gwl

und/oder zusätzlich Blick in die Map wo die Tunnel terminieren…

Hi zusammen,

Die neue Gateways sind schon fertig, allerdings gibt es noch Probleme mit den Client-Verbindungen die wir momentan prüfen. Danach kommt ein neuer Stable-Release welche die neue Supernodes in der Config bereithält.
Wir sind bereits mit dem Provider in Kontakt um das Problem zu lösen, scheint ein Netzwerkproblem beim Provider zu sein der IPv6 nicht durchlässt.

Sobald das erfolgreich getestet ist haben wir 7 Supernodes aktiv.

2 „Gefällt mir“

Die Verbindungen zu den neuen Supernodes funktionieren nun, Beta Nodes haben bereits die neue Konfiguration. Die Stable Version folgt spätestens heute Abend.

1 „Gefällt mir“

Man kann sich übrigens einen groben Überblick über die Supernodes und die Verbindungen in der Graph Darstellung anschauen. http://ffmap.freifunk-rheinland.net/graph.html

Edit: natürlich ist die Darstellung aufgrund von ALFRED/Map-Foo manchmal ein bisschen buggy, das wollte ich keinem vorenthalten :stuck_out_tongue:

Woran hat es denn jetzt eigentlich gelegen, dass die VMs keine v6-Konnektivität hatten? :smiley:

V6 läuft noch nicht (Von Netcup, das interne FFRL V6 klappt natürlich).
Warum wissen wir noch nicht, da aber die meisten User per V4 verbinden habe ich die Nodes jetzt schon in Betrieb genommem.

mtu = 1426

könnte sein das es schlicht nicht durch die Anschlüsse passt, weil der v6 header größer ist…

Habe wir bei uns auch getestet… IPv6 ohne MTU 1406 ging garnicht oder nur selten / mit abbrüchen.

Joa, da muss man minimum auf 1406 runter, das ist auch der empfohlene Wert aktuell.

Wobei da je nach Region die Meinungen auseinander gehen, zwischen 1312 und 1406 sind da sämtliche berechenbaren Werte bei. Kommt eben auf die Anbindung der Nodes an, was da durchgeht, oder eben auch nicht mehr durchpasst, da fastd derzeit noch nicht fragmentieren kann…

Ja Ich habe hier die letzten Tage an allen Providern die ich so finden konnte getestet. Mit 1406 ging es überall.

1 „Gefällt mir“

Deutschlandweit scheint es wohl ein paar abstruse Aufschaltungen zu geben, nennen wir es mal einfach „Sonderlocken“.

Hattest Du auch schon Kabelanschlüsse dabei, z.b. Unitymedia?

Ja. Unitymedia war der Problemauslöser… Es ist ein Unitymedia Anschluss mit DS-Lite… Über die NAT v4 adresse kommt zwar ein Tunnel zustande, der ist aber total instabil. Desswegen wollten wir IPv6 Testen. Mit einem Tunnel über IPv6 geht der anschluss

2 „Gefällt mir“

@FxFx hat daran mit Sicherheit großes Interesse, wir haben in Aachen einen für uns wichtigen Anschluss bei einem Unitymedia Kunden.
Hast du uns Details zur Config Anpassung?

@CyrusFox Die Alfred Config wurde beim mutmaßlichen clonen der VMs anscheinend noch nicht angepasst. Auf der Liste tauchen Supernode 1-3 doppelt auf, die Duplikate jedoch ohne Angabe der Zahl der Tunnel. Dadurch haben Knoten die zu den neuen Supernodes verbunden sind auch fälschlicherweise nur 0-1 VPN Tunnel angezeigt.

1 „Gefällt mir“

Wir haben einiges getestet… Rausgekommen ist folgendes:

  • fastd Server und Node mit MTU 1406
  • fastd IPv6 Aktiviert (site.conf und Server)
  • Auf dem Node muss anscheinend auf dem WAN Interface IPv4 deaktiviert werden, da der Node ansonsten die Verbindung über IPv4 herstellt, weil die IPv4 adresse zuerst zugewiesen wird.

Die richtige MTU hatte ich bei euch auf der Supernode bereits bei der initialen Config IPv6 gerecht eingestellt > 1406

Meine zwei Rheinufer Knoten schickten kurz vor 19 uhr einen Hilferuf durch das monitoring. Seit dem sind sie nicht mehr zu erreichen