Paketverlust auf den Wupper-VMs

Community Wuppertal
1

Hallo zusammen,

seit Anfang des Monats erleben wir heftige Paketverluste auf den VMs. Die VM selbst ist nicht nennenswert ausgelastet. Wie sieht die Leitung aus?

                                                                                                    My traceroute  [v0.92]
xxxxxx (xxxxxxxxxxxxx)                                                                                                                                                                                       2019-06-16T23:26:47+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                             Last 200 pings
 1. xxxxxxxxxxxxxxxxxxxxxxxx ........................................................................................................................................................................................................
 2. xxxxxxxxxxxxxxxxxxxxxxxx ........................................................................................................................................................................................................
 3. xxxxxxxxxxxx             ........................................................................................................................................................................................................
 4. xxxxxxxxxxx              ........................................................................................................................................................................................................
 5. xxxxxxxxxxxxxx           ........................................................................................................................................................................................................
 6. xxxxxxxxxxxxx            ....................................................................................................................................................................................................... 
 7. xe-2-0-0-501.bno1-r1.sys ....................................................................................................................................................................................................... 
 8. ae8-0.blu1-r2.syseleven. ....................................................................................................................................................................................................... 
 9. ae2-0.bak1-r1.syseleven. ....................................................................................................................................................................................................... 
10. 185-46-137-93.syseleven. ....................................................................................................................................................................................................... 
11. 185-46-137-139.syseleven .....................??????????????????????..?????????????..>.?...........................................?????..??????????????????????..???...................???...........................??........

Scale:  .:14 ms  1:55 ms  2:124 ms  3:220 ms  a:343 ms  b:494 ms  c:673 ms  >

bitte teilt uns mit, wenn die Kisten überbelegt wurden. Natürlich wäre es schön zu erfahren, wenn es andere Gründe für den Paketverlust gibt. Hier noch eine Ausgabe der Zusammenfassung:

                              My traceroute  [v0.92]
xxxxxx (xxxxxxxxxxxxx)                                   2019-06-16T23:41:55+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                         Packets               Pings
 Host                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  0.0%  1115    1.8   1.2   0.7  17.2   0.8
 2. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  0.0%  1114    8.5   9.1   8.1  55.9   1.7
 3. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  0.0%  1114    9.2   9.2   8.2  17.8   0.8
 4. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  0.0%  1114   12.5  12.1  11.1  18.6   0.6
 5. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  0.0%  1114   11.6  12.0  10.6  46.4   2.7
 6. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  0.0%  1114   20.6  20.3  19.2  69.6   1.6
 7. xe-2-0-0-501.bno1-r1.syseleven.net  0.0%  1114   31.8  32.5  30.9  75.9   2.1
 8. ae8-0.blu1-r2.syseleven.net         0.0%  1114   32.8  33.4  31.7  86.3   2.6
 9. ae2-0.bak1-r1.syseleven.net         0.0%  1114   33.1  32.6  31.3  81.1   2.2
10. 185-46-137-93.syseleven.net         0.0%  1114   30.8  30.2  28.9 105.7   2.9
11. 185-46-137-139.syseleven.net       32.1%  1114   31.9  32.6  30.0 879.3  30.9

Danke und viele Grüße
phip

2

geht leider der Foren-VM in Berlin ähnlich. Da gehen immer mal auch Routen über dem community-ix kaputt.
„eigenes Blech“ ist die Lösung. Die FFRL-VMs „als Community-Supernodes“ stehen seit längerer Zeit auf „Entwöhnung“.

3

auf dem „eigenen Blech“ schaut es noch viel schlimmer aus. Zwar gehen keine Pakete zum/vom Server verloren, aber auf der Batman-Ebene gehen sehr lange viele Pakete verloren:

                                                                                                  My traceroute  [vUNKNOWN]
xxxxxx (10.3.xx.xx)                                                                                                                                                                                          2019-06-22T04:45:25+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                             Last 200 pings
 1. 10.3.0.245               ???????????????????????????????......?????....?.....?????..???.....????...........?..?...??????????.????????????????????????????????????????????????????????????????????????????????????????????????????
 2. 185.66.194.0             ???????????????????????????????......????.....?....??????...>?....??????..?......??......???????????????????????????????????????????????????????????????????????????????????????????????????????????????
 3. de-cix.fra.google.com    ???????????????????????????????.....?????.....?..>.?????.....?....??????...........?....??????.?????????????????????????????????????????????????????????????????????????????????????????????????????????
 4. 108.170.252.65           ???????????????????????????????.....?????..........?????.?.?.?....?????...?.?.......?...???????????????????????????????????????????????????????????????????????????????????????????????????????????????
 5. 216.239.40.57            ???????????????????????????????.....?????..........?????..........?????..........?......???????????????????????????????????????????????????????????????????????????????????????????????????????????????
 6. 8.8.8.8                  ???????????????????????????????.....?????.?.......???????.....?...?????.?........?..?...???????????????????????????????????????????????????????????????????????????????????????????????????????????????

Scale:  .:30 ms  1:48 ms  2:78 ms  3:121 ms  a:175 ms  b:242 ms  c:321 ms  >

auf den Freifunk-VMs liegt der verlust bei ca 75% hier sind es mehr

                        My traceroute  [vUNKNOWN]
xxxx (10.3.xx.xx)                             2019-06-22T04:46:48+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                Packets               Pings
 Host                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.3.0.245                83.8%   285   34.0  34.9  24.0  60.4  11.5
 2. 185.66.194.0              84.9%   285   35.7  51.0  28.1 365.6  65.2
 3. de-cix.fra.google.com     84.1%   284   37.1  54.0  29.2 412.2  63.6
 4. 108.170.252.65            84.8%   284   45.7  58.6  30.1 537.8  83.5
 5. 216.239.40.57             83.0%   284   36.9  53.6  28.9 374.7  52.6
 6. 8.8.8.8                   85.5%   284   50.2  40.7  28.4 171.4  23.1

entweder passiert im FF was ganz eviles oder ich weiß einfach nicht mehr weiter.

4

Das Problem ist gelöst … vielen Dank.

5

Was war es denn? Oder hat es sich unerkannt selbst gefixt?

6

Ein Teil der Antwort auf diese Frage könnte die Freifunk-Gemeinschaft verunsichern.

Privat erzähle ich Dir gern, was für eine simple, menschliche Funktion nicht ein mal von sich allein geht. Wäre zu derb fürs Forum. Ich würde hier mehr erzählen wollen, aber a) dieser Thread hat außer Dir niemanden Interessiert (erzähle ich Dir, wenn wir uns mal sehen), b) ich bin viel zu frustriert und c) ich will meine zur Lösung dieses Problems verplemperte Zeit zurück. LG

zu a) ich weiß, dass es gute Sitte ist Lösungen und -swege zu beschreiben. In diesem Fall – glaubt mir – kann darauf verzichtet werden. Die VMs sind in Ordnung, das Backbone auch. Das Problem hier im Forum zu nennen, war aber nicht verkehrt. Schade, dass niemand außer mir eine Lösung fand.

1 „Gefällt mir“
7

… das lässt jetzt verschiedene Menschen („stille Mitleser“) ratlos zurück. Zumindest ich hätte aber sowieso nichts beitragen können, weshalb ich eben auch nur still bin. :wink:

2 „Gefällt mir“
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“
11

Bist Du Dir sicher das alles wieder ok ist?

Es sind mehr als die Hälfte aller Nodes offline.

ff-meltdown1
ff-meltdown11307×768 411 KB

12

Ansonsten sieht es wieder halbwegs ok aus an meinem Node.

ff-meltdown3
ff-meltdown31307×768 433 KB

13

Ich bin noch unschlüssig, was davon „Messfehler“ ist und z.B. „Anbindung des Kartenservers an die FF-Domain“ geschuldet sein könnte.

grafik
grafik742×1188 224 KB

Oder long-Term-View der Wupper-L2-Domain:

grafik
grafik740×899 240 KB

Dass in der Domain manchmal komischer Traffic ist: Habe ich eigentlich schon aufgehört mich zu wundern im vergangenn Jahr.
Peaks von >600kBit/s Traffic auf einem Node (hier:Kartenserver), der „kein geroutetes IPv6“ (geschweige denn IPv4) macht und nur „seitlich an der Domain dranhängt“: komisch:

grafik
grafik775×801 236 KB

18

Deshalb noch mal meine Frage: Es sind immer noch ca. die Hälfte aller Wuppertaler Nodes offline. Einige meiner Router sind davon ebenfalls betroffen. Mehrfacher Neustart brachte keine Änderung.

Bitte untertänigst um Antwort.

19

Potentiell (Spekulation) gibt es schlicht einen Netsplit, d.h. zwei Gruppen/Wolken von Supernodes, die keinen Kontakt zueinander haben und der Mapserver sieht halt nur die Hälfte von diesen.
Oder wechseln die offline-Nodes und die Knotenzahl ist sehr konstant? Dann könnte irgendwo ein „Max-Peers“ irgendwo zuschlagen.

20

Wie nebenan geschrieben: die Nodes scheinen mir hier lokal zumindest „echt“ offline, nicht nur ohne korrekte Info auf dem Kartenserver. Pingen von der Shell nicht nach draußen und sind von Clients nicht nutzbar (Default-IP, „keine Internetverbindung“). Angemeldeter Client kommt nicht mal auf die 10.3.0.1.

21

Wenn ich „hier“ richtig deute, dann ist damit Utopiastadt/Mirker Bahnhof gemeint, korrekt?
Dann habe ich Phips Posting so verstanden, dass von dort netztechnisch problematische Pakete kamen und daher die Site ausgesperrt wurde.

Ich weiss nicht, um was es da geht, ich unterstelle jedoch Gesprächsbedarf.

22

Der ist definitiv gegeben. Nein, ich rede von den drei Schafen drunter (Wolkenschaf, Strassenschaf, fabrikschaf), die stehen gegenüber vom Bf. bei mir zuhause und hatten eigentlich immer separaten fastd über meine Leitung, falls die US-Wolke mal keinen Uplinik hat etc. Fürs Protokoll: drei Zugänge über eine IP, aber hier schon einigemale Thema gewesen und keine Experimente, reines „mein Uplink ist fett genug, um auch ein wenig Last rauszunehmen“.

23

Jein, das sind entweder die über IPv6 angebundenen Knoten, die eine andere MTU benutzen, oder FF-Nutzer, denen ein FF-Gerät „aufgezwungen“ wurden und nicht wissen, was für ein Schätzchen bei ihnen auf der Fensterbank steht, und keinen Neustart durchführen.

Da B.A.T.M.A.N.-advanced scheinbar immer noch einen Bug in der internen Paketfragmentierung aufweist, stürzt der Kernel ab. Zum Reporten komme ich aus Gründen nicht, hier kann man nachlesen, was früher geschah. Aus diesem Grund hat batman auf der VM nun ein Hop-Penalty von 250. Kann sein, dass dadurch die KArte nichts von diesen Knoten mitbekommt.

ich habe einen der Schafe zugelassen, k. A. warum dieser nicht möchte … ich habe nun den zuvor gesperrt und den nächsten zugelassen.

k. A. was Du mit USA anstellst

kann man machen, geht aber schöner. Nichts für ungut und nicht falsch verstehen. Ich habe im Moment keine Zeit und die Wahl zwischen mehreren fastd-Tunneln von einer IP oder ständigen VM-Crash für alle. Ich hoffe, dass meine Entscheidung nachvollziehbar ist.

Das ist echt ehrenvoll und komplett als FF-Gedanke zu verstehen; „drüben“ ist aber etwas™ extrem schief gelaufen. Eine Analyse wollte ich am Wochenende vornehmen, das Leben lies es aber nicht zu. Übrigens, könnte die Fehlkonfiguration „drüben“ auch einer der Gründe für das Fehlverhalten sein, welches Du mal berichtet hast und ich nicht genau eingrenzen konnte.

Ich schlage vor, Du sendest mir einen fastd-Key, des Knotens, welches Du am liebsten an das Gateway angeschlossen hättest. Du hattest drei, das erste im alphabetischen Sinne war freigegeben. Nach deiner Meldung hier versuche ich es nun mit dem 2ten Key.

Entschuldigt die voreilige Meldung oben, ich hätte das Problem gelöst. Es war auch gelöst, bis neue auftraten. Da dies FFRL nicht interessierte (aus Gründen oder weil alles dort i. O. ist) Habe ich das mit so einer Meldung abgehackt.

Das Problem ist teils Batman, teils falsche Konfiguration der Aufsteller (2 sind raus, aus kommunizierten Gründen, im Übrigen, das erste Mal, dass ich zu dieser Maßnahme greife – aus zeitlichen und Erfolgs-Gründen – ), teils hausgemacht (mein Co-Admin deffiniert eine andere MTU auf dem gleichen Port, statt auf einem Anderen). Ich mutmaße auch, dass irgendwo bei den Schuldigen Bridge Loop Avoidance nicht aktiviert wurde.

Ich möchte mich nicht aus dem Fenster lehnen und nichts versprechen, was ich zeitlich nicht einhalten kann, aber eine neue Firmware muss her … Dies steht mittlerweile ganz oben auf meiner Liste, da ich nach den Jahren es doch geschafft habe die davor liegenden Punkte abzuarbeiten.

Dass der Bahnhof und ein weiterer Akteur offline sind, tut mir wirklich furchtbar traurig. Leider muss man hier an alle denken, und nicht an die, die „to big to fail“ sind. Warum die anderen Knoten nicht in der Map sichtbar sind, weiß ich nicht, ich nehme an, dass dies an der Firmware liegt, die sich bei der MTU-Entscheidung verschluckt hat. Ein Reset würde echt helfen. Sollten die sich aber für die richtige MTU und IPv4 entscheiden, muss ich diese aber manuell freigeben – IPv6 darf ungeprüft rein, bis es auch ein Grund für Paketverluste wird.

Bei den Knoten in der Wolke, die daran teilnehmen, sollte FF aber ohne Paketverluste und mit allem, was die Hardware her gibt, funktionieren. Ab und zu – in einer freien Sekunde – füge ich neue Knoten in die White-List hinzu. Wenn, die VM aus Paketfragmentierungsgründen abstürzt, ist sie in ca. 1 min wieder online und stellt DHCP in 2 min bereit.

Bis Bald

1 „Gefällt mir“
24

Falls es hilft: stell uns die aktuell genutzte site.conf und die Änderungswünsche in dieser zur Verfügung.
Wir haben gerade Übung im Firmwarebau und können eure Konfiguration gerne auf die aktuelle gluon Version migrieren und auf dem build-server von FFDUS und Neanderfunk für euch bauen.

3 „Gefällt mir“
25

Die Nodes sind wirklich offline, nicht nur auf der Karte, z.B der hier bleibt stur offline (wichernhaus-martin-luther-3) nachdem er drei Jahre brav seinen Dienst versah. Neustart usw bringt nix. Und ich garantiere das an dem Teil nichts aber auch gar nichts gebastelt wurde.

26

Welches ist lastworking site-conf?
Dann bauen wir darauf auf.
2017 hatten wir schonmal was „inoffizielles“ (noch Gluon 2016.2) gemacht.