Paketverlust auf den Wupper-VMs

Community Wuppertal
10

Das stimmt, ich habe die stillen Mitleser („Google“) vergessen. Wie soll ich die Problemlösung beschreiben, ohne, dass es mir mein ganzes restliches Leben nachgetragen wird? Ich versuche es mal zu beschreiben, in der Hoffnung, dass ich nicht gesteinigt werde.

Ich habe hier mehrere Unbekannte:

  • k. A., ob mit der FFRL VM alles in Ordnung ist (keine Rückmeldung hier im Forum)
  • k. A., wie das FFRL Wetter ist; sprich: Wie ist der BB zustand
  • k. A., wie dicht die Leitung zur VM ist

Ich habe mehrere Störquellen:

  • fastd stürzt reproduzierbar ab und ich habe keine Zeit es zu melden, da mir FF um die Ohren fliegt und ich auch noch irgendwie „leben“ muss
  • bleche in der freien Wildbahn stürzen reproduzierbar mit FFW und den anderen Huckepack-Comunities ab und sind keine Hilfe, um das Problem zu lösen
  • ich habe die FF-Nutzer, die – Gott weiß – was mit dem FF anstellen
  • ich habe einen „mit“-Administrator, der überhaupt nicht administriert. Als ich vor dem Beginn meines Studiums jede Woche eine Übergabe im Hackerspace machen wollte, wollte dieser nichts davon wissen und verwies auf später. Ich behaupte, ich bin der Einzige, der FFW administriert.

Was ich tat:

  • die eine VM stürzt reproduzierbar nach einem Neustart ab
  • alle fastd-Tunnel wurden deaktiviert und nach und nach wieder erlaubt
    • gleichzeitig wurde eine IP erkannt, die der VM auf der BB Paketverluste verursacht hatte
      • siehe erster Beitrag im Thread
    • ich meine, das muss man sich mal vorstellen: Paketverluste auf der BB, bei 10 Mbit/s Last
  • das Netz wurde regelmäßig auf Funktion überprüft; es scheint nun performant zu laufen
    • die fastd-Tunnel wurden stufenweise wieder in den Freifunk integriert
    • die Störer (mir bekannt) wurden nicht mehr zum Tunnel zugelassen
      • dies bleibt noch, bis ich das Netz mit weiteren Servern stabilisiert habe
      • leider gilt das auch für neue Knoten
      • in dringenden Fällen kann hier im Forum ein fastd key genannt werden, der dann aktiviert wird
    • die Youtube-Gucker (nicht die oben erwähnten Störer) sind abgesprungen, was eine zusätzliche Entspannung bewirkt
  • dies hier geschrieben

Es muss aber noch ausdrücklich erwähnt werden, dass der von mir oben als Störer bezeichnete FF-Teilnehmer nicht unbedingt der Störer sein muss, sondern ein Freifunknutzer bei ihm. Neun fastd-Tunnel von einer IP sind aber auch schon ein bisschen derbe. Krank dabei ist, dass das zur Abhilfe hinzugezogenes Blech (dritter Beitrag) sich im gleichen Rechenzentrum befindet, wie die IP des Störers. Hierbei muss aber unterschieden werden zwischen Rechenzentrum und Standleitung nach X (Ort bekannt), beide befinden sich jedoch im selben AS. Auf jeden Fall, hat das Blech nur einen Tag als GW überlebt. Davor war es passiv im Verbund.

Was ich daraus lerne:

  • ich (Co-Administrator) habe keinen anderen Co-Administrator
  • wenn
    • nichts mehr geht
    • auf der Arbeit gerade ein Projekt kurz vor dem Abschluss steht
    • privat so viel zu erledigen ist, dass man nicht mal in Ruhe ein Hackerspace besuchen kann
    • die Arbeit kündigen müsste, um die/das FF-Pensum/-Debugging/-Ursachenforschung/-Administration zu bewältigen
    • die Steuererklärung abgegeben werden sollte
  • dann einfach mal FF abschalten und kontrolliert wieder hochfahren
    • es hat ja nur eine Nacht gedauert
      • eine Nacht, die ich schon wieder wegen FF nicht gepennt habe
  • es ist nur ein ehrenamtliches Projekt
  • Furos (aka. Powerfreifunker) meinen sich an den FF-fastd anstöpseln zu können statt eine bessere alternative zu wählen
    • die Durchsatzrate eines Plasterouters bewirkt, dass alle was vom FF haben und nicht nur die allseits bekannte Person mit dem Namen „ich“.

Mag sein, dass ich lange nichts mehr für den FF getan habe, aber ich habe auch ein Leben. Gespendete Server, die ich nicht mal ein- und ausschalten kann, geschweige über eine Konsole debuggen kann, nützen mir nicht viel, da sie sofort abstürzen. Da sie kommen und gehen, ich FFRL aber von ständigen GRE-Änderungen verschonen möchte, und weil wir Spenden für VMs gesammelt haben, bleibt erst ein Mal alles, so wie es ist, bis die Leitung in unser Rechennetz steht.

Wer FF nur zum Speedtesten nutzen möchte, dem Empfehle ich IPoverBrieftaube: nichts ist schneller.

BTT. Ich mutmaße, dass sich neben dem Störer noch ein paar Experimentierer im FF befinden, die den FF, ohne zu wissen was sie tun, zusätzlich instabilisierten. Ich finde es zutiefst traurig, dass Experimente hier im Forum nicht ein Mal angekündigt werden.

10 „Gefällt mir“