Paketverlust 2020-06-18

Hallo zusammen,

fast einen Monat später erlebe ich erneut Paketverluste zum FFRL-BB:

                             My traceroute  [v0.87]
6_c01 (185.66.195.57)                                  Thu Jun 18 21:35:32 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 185.66.194.0                     63.3%   357    9.7   9.2   8.6  12.5   0.4

                         My traceroute  [v0.87]
6_c01 (100.64.2.169)                           Thu Jun 18 21:35:48 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 100.64.2.168             45.9%   244    0.2   0.3   0.2   1.5   0.1

                         My traceroute  [v0.87]
6_c01 (100.64.2.173)                           Thu Jun 18 21:35:51 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 100.64.2.172             39.5%   243    0.2   0.3   0.2   1.0   0.0

                         My traceroute  [v0.87]
6_c01 (100.64.0.227)                           Thu Jun 18 21:35:55 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 100.64.0.226             54.5%   243   16.5  16.4  16.3  16.8   0.0

                         My traceroute  [v0.87]
6_c01 (100.64.0.223)                           Thu Jun 18 21:36:00 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 100.64.0.222             61.5%   245    9.0   9.2   8.7  11.2   0.4

Da der letzte Ticket nicht abgearbeitet wurde (nicht reproduzierbar, dann doch, dann Fehlerbehebung durch Magie ohne die gewünschte Nennung der Ursache), spare ich mir die Ticketschreiberei. Ich bitte untertänigst um Hilfe seitens des FFRL. Ich bitte auch um eine Diskussion zum Stand der Dinge.

Ich möchte bitte immer noch gern erfahren, was die Ursache für den regelmäßigen Paketverlust ist, da dieses Problem ab und zu schon auftritt und die Lösung seitens FFRL schon eine Weile dauert, während der der Zugang zum Internet aus dem FF für die Nutzer nicht nutzbar ist und somit nach herrschender Nutzermeinung FF nicht funktioniert.

Großen Dank und liebe Grüße

edit: ich habe doch einen Ticket geschrieben, denn das Thema ist eigentlich sehr wichtig.

Nicht böse gemeint: Ich stelle fest, dass es hier und im Ticketsystem niemanden gibt, der mir helfen kann. Es wäre zumindest hilfreich mir mir mitzuteilen, dass mir nicht geholfen werden kann, damit ich mich nicht auf Andere verlassen muss. Das Problem besteht immer noch

                         My traceroute  [v0.87]
6_c01 (185.66.195.57)                          Fri Jun 19 19:33:56 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 185.66.195.0             83.4% 32030    9.0   6.2   0.1  35.9   3.5
    185.66.194.0
    185.66.195.1
    185.66.193.0
 2. google.ber.ecix.net      86.0% 32030    8.6   8.8   8.3 145.1   4.3
    de-cix.fra.google.com
    google.bcix.de
    google.dus.ecix.net
 3. 108.170.241.193          88.4% 32029   16.6  15.6  14.2  63.6   1.5
    108.170.252.1
    108.170.251.129
 4. 72.14.238.245            88.6% 32029   14.9  14.7  14.2  31.1   0.8
    216.239.48.45
 5. dns.google               87.8% 32029   14.7  14.5  14.1  42.7   1.1

und ist nachts etwas schwächer – etwa 10% zwischen 2 und 6 Uhr

                         My traceroute  [v0.87]
6_c01 (185.66.195.57)                          Sat Jun 20 21:21:03 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 185.66.194.0             76.6% 30987    9.2   6.9   0.1  34.5   2.8
    185.66.195.0
    185.66.193.0
    185.66.195.1
 2. de-cix.fra.google.com    78.9% 30987    8.9   8.5   8.3 147.9   5.2
    google.ber.ecix.net
    google.dus.ecix.net
    google.bcix.de
 3. 108.170.252.1            81.9% 30986   16.2  15.7  14.2  77.3   1.8
    108.170.241.193
    108.170.251.129
 4. 216.239.48.45            81.6% 30986   15.5  14.6  14.1  40.4   1.1
    72.14.238.245
    66.249.95.29
 5. dns.google               81.1% 30986   15.2  14.5  14.1  42.7   1.2
                         My traceroute  [v0.87]
6_c01 (185.66.195.57)                          Sun Jun 21 23:17:38 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 185.66.194.0             71.0% 33175    9.1   7.4   0.1  36.0   2.3
    185.66.195.0
    185.66.195.1
    185.66.193.0
 2. de-cix.fra.google.com    71.8% 33174    8.7   8.5   8.3 180.6   6.5
    google.ber.ecix.net
    google.dus.ecix.net
    google.bcix.de
 3. 108.170.252.1            73.2% 33174   16.9  15.7  14.2  88.6   2.2
    108.170.241.193
    108.170.251.129
 4. 216.239.48.45            72.6% 33174   15.2  14.7  14.2  54.6   1.0
    72.14.238.245
    66.249.95.29
 5. dns.google               74.6% 33174   15.0  14.5  14.1  34.2   1.0
                         My traceroute  [v0.87]
6_c01 (185.66.195.57)                          Mon Jun 22 18:19:46 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 185.66.194.0             75.1% 28808    9.4   7.2   0.1  33.2   2.5
    185.66.195.0
    185.66.195.1
 2. de-cix.fra.google.com    75.7% 28808    8.6   8.6   8.2 173.9   6.1
    google.ber.ecix.net
    google.bcix.de
 3. 108.170.252.1            79.2% 28808   15.9  15.6  14.1 118.3   2.6
    108.170.241.193
 4. 216.239.48.45            79.7% 28808   16.0  14.6  14.2  37.2   0.9
    72.14.238.245
 5. dns.google               79.5% 28807   16.2  14.4  14.1  43.7   0.9

Hallo @phip,

ihr benutzt noch die oVirt Plattform, auf der die Communities eigentlich nichts mehr Hosten sollen?
Mein letzter Stand war, dass dort gefühlt 1x im Jahr ein Update installiert wird und ansonsten nur
das Reset-Knöpfchen gedrückt wird falls das blech abgeraucht ist.

Das mag an der Tatsache liegen, dass damals von ein paar „Menschen“ beschlossen wurde oVirt
zu benutzen und anschließend keiner aus dem alten Team bock hatte sich den Mist ans Bein zu hängen. (IMHO Verständlich denn oVirt ist echt mies)

@CHRlS hat es treffend formuliert wie das oVirt da läuft :wink:
https://forum.freifunk.net/t/umstellung-der-vm-auf-eine-neue-plattform-ist-beschlossen/11646/12

Ich kann Dir zwar bei deinem Problem nicht helfen, aber wir haben keine Probleme mehr,
seitdem wir unsere Supernodes/Router selber auf eigener Hardware hosten.

Grüße von nebenan :wink:

Ist das die IP, von wo aus Du die Probleme hast?

Dann liegen die Problem doch eher auf den ersten Metern; von unserem Server in Berlin, 2 Hops entfernt:

--- 185.66.195.57 ping statistics ---
100 packets transmitted, 77 received, 23% packet loss, time 99558ms
rtt min/avg/max/mdev = 8.881/10.086/61.286/5.908 ms

Von Zuhause, Telekom-VDSL:

[…]
 4. 217.5.101.30                                                0.0%    28   15.9  15.8  15.2  17.1   0.4
 5. 217.5.101.30                                                0.0%    28   15.3  15.5  15.0  16.1   0.2
 6. ae4-0.blu1-r1.syseleven.net                                 0.0%    28   15.0  16.3  14.7  34.4   4.4
 7. ae0-0.blu1-r2.de.syseleven.net                              0.0%    28   15.5  17.5  15.1  53.4   7.2
 8. ae2-0.bak1-r1.syseleven.net                                 0.0%    28   16.6  15.7  14.9  17.6   0.6
 9. 185.66.195.1                                                0.0%    28   13.8  13.7  13.5  14.0   0.1
10. 185.66.195.57                                              63.0%    28   19.0  19.1  18.7  19.9   0.3
1 „Gefällt mir“

Ja.

Jain. Im ersten Post dieses Threads wird beschrieben, dass es an den GRE-Tunneln liegt. Es ist dann egal welche IP es ist, denn das Routing zu dieser hapert an diesen Tunneln. Bird würde sich ja einen optimalen Tunnel auswählen, aber alle vier sind betroffen. Die Maschine ist aber ohne Probleme ohne Paketverluste direkt erreichbar. Die Paketverluste auf den Tunneln treten im Monatsrhythmus auf. Im letzten Monat hat sich das Problem nach einer Woche scheinbar von selbst behoben.

Entweder werden die Server genutzt oder sie werden abgestellt. Ich habe Hilfe zur Administration der Vereinsinfrastruktur angeboten … Eigene Supernodes stehen unsererseits längst im Rack und es fehlt nur ein kleiner Schritt, weil hier beschlossen wurde, es „perfekt“ statt „nutzbar“ zu machen. Das ist aber kein Grund dieses hier beschriebene, bestehende Problem nicht zu lösen.

                         My traceroute  [v0.87]
6_c01 (185.66.195.57)                          Tue Jun 23 20:54:17 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                               Packets               Pings
 Host                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 185.66.194.0             63.6% 41934   10.5   7.2   0.1  73.0   2.6
    185.66.195.0
 2. de-cix.fra.google.com    62.5% 41934   11.9   8.5   8.2 190.7   7.0
    google.ber.ecix.net
 3. 108.170.252.1            67.0% 41934   15.9  15.7  14.2 150.1   2.5
    108.170.241.193
 4. 216.239.48.45            65.8% 41934   15.7  14.7  14.2  63.4   1.2
    72.14.238.245
 5. dns.google               64.5% 41933   14.7  14.5  14.1  66.4   1.5

Die Ovirt-Platform für Supernodes von Communties ist seit 3 (4?) Jahren abgekündigt. (Ich suche die Protokolle von den öffentlichen Vorstandsmumbles gern nochmal raus, wenn Bedarf besteht.)
Alle Communities wurden mehrfach dringend aufgefordert, sich Alternativen zu suchen.
Einige haben sich leider taub gestellt oder ein Lamento gestartet in der Richtung „sie hätten doch so viele Mitglieder/Mitgliedsbeiträge beim FFRL“, respektive „so viele Spenden gesammelt“, dass sie erwarten würden, dass das auch weiter so laufe.

Wenn Du möchtest, dann lasse ich die VM abschalten.

2 „Gefällt mir“

Was Du meinst, sind die Server bei OVH …

Wenn Du Dir die Mühe machen möchtest, sehr gern. Denn ich wurde über die Abschaltung nicht informiert und es wurde auch nicht abgeschaltet. Außerdem laufen noch andere Instanzen da drauf …

Mir fehlt die Kraft, sich auf dieses Niveau zu begeben und mir die Mühe zu machen und die Zeit zu nehmen mit Dir darüber hier offtopic zu diskutieren.

Ich möchte zuerst, dass mein Anliegen bearbeitet wird: Ursache der sich monatlich wiederholenden Paketverluste auf den GRE-Tunnen, die tagsüber unzumutbar sind und die eine Woche dauern. Wir haben ja einen Bildungsauftrag.

Die VM kann ich selbst abschalten … und ich schrieb Server und nicht VM … und ich schrieb abstellen im Sinne von „aus der Vereinsmasse entfernen“ und nicht „Abschalten“.

                             My traceroute  [v0.87]
6_c01 (185.66.195.57)                                  Wed Jun 24 19:15:21 2020
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 185.66.194.0                     39.8% 17961    9.0   8.7   8.5  37.1   0.9
 2. de-cix.fra.google.com            37.8% 17961    8.5   8.5   8.2 177.3   6.3
 3. 108.170.252.1                    39.2% 17961   16.4  15.8  15.5 151.3   3.0
 4. 216.239.48.45                    43.3% 17961   16.3  14.8  14.6  48.0   1.2
 5. dns.google                       43.9% 17961   16.1  14.6  14.4  41.2   1.1

Ich sehe hier null nutzbare Daten um das zu debuggen.

  1. Welcher Tunnel ist betroffen? Bitte eigentsändig isolieren und einen konkreten benennen. IP Adressen beider Endpunkte benennen.
  2. mtr von eurem zu unserem Endpunkt dabei packen
  3. Kommandos mit denen gemessen worden ist stets dazu nennen (inkl. aller Parameter)

Der Hauptgrund, weshalb ich so wenig Lust habe Support zu leisten ist, dass auch nach 6 Jahren Leute einfach null selber dabei behilflich sind und nur nach Hilfe betteln. Und am Ende liegt’s dann doch fast immer außerhalb von AS201701…

Um es mit C. Drosten zu sagen: Da hab ich persönlich besseres zu tun.

Und wenn dann wirklich mal ein Link fehlerhaft ist, dann gehen die Meldungen darüber noch in diesem Geschrei unter.

2 „Gefällt mir“

Hallo zusammen,

die Ursache dieses wiederkehrenden Problems ist, dass hier die /etc/sysctl.conf beim Booten nicht geladen wurde. Ein simples sysctl -p ist hier die Lösung. Warum das nicht geschehen ist, werde ich noch analysieren und darüber berichten. Dass das Problem so regelmäßig auftrat kann man hier mit dem Nutzerverhalten erklären. Danke @mat, der sich die Zeit genommen und Mühe gemacht hat in die Logs hineinzuschauen.


Hallo takt, vielen lieben Dank für die Antwort. Die Informationen zum Entwanzen der Verbindung sind alle im ersten Post.

  1. Dort stehen die Tunnel (100.64.2.169 → 100.64.2.168 usw…) explizit benannt. in diesem Fall waren alle vier betroffen und wurden genannt.
  2. erster Post
  3. entschuldige, die Kommandos habe ich mir gespart, weil es für mich trivial war und in meinen Augen es auch aus der Ausgabe im ersten Post direkt ersichtlich ist welche IPs beteiligt sind.
    mtr -a 185.66.195.57 185.66.194.0
    mtr -a 100.64.2.169 100.64.2.168
    mtr -a 100.64.2.173 100.64.2.172
    mtr -a 100.64.0.223 100.64.0.222
    mtr -a 100.64.0.227 100.64.0.226

Ich kann Deinen Unmut total nachvollziehen. Aus diesem Grund benutze ich das Ticketsystem auch äußerst selten. Verstehe ich das richtig? Ich habe einen falschen Link in die Meldung gepackt?

Moin,

mit Tunnel IPs meine ich die IPs mit denen der Tunnel transportiert wird.
Mit den Angaben „100.64…“ kann ich auf allen 6 Routern des FFRL (oder im IP Management) nachforschen wo der Tunnel ist. Wenn ich dann den Router habe muss ich mir da rauskramen, wie eure Public IP lautet. Das könnte ich zwar tun. Aber das ist einfach unnötig mühselig.

Also bitte immer liefern: Eure Public IP, unsere Public IP, und dazwischen den MTR.
Mit den Privaten Adressen sieht man eben nur, dass der Tunnel loss hat. Aber eben nicht wo. Und das ist entscheidend.

Wenn mtr dann schon loss zeigt, bevor 185.66.192.0/22 erreicht ist, dann stinkt es außerhalb von AS201701. Gerne bin ich dann behilflich rauszufinden, wieso da loss ist. Aber soviel Struktur erwarte ich.

Gruß
takt

Tja, das ist meinerseits dann wohl extrem dumm gelaufen. Entschuldige. Und die MTR zwischen unsererIP und FFRL-IP habe ich wohl deshalb nicht mitgeliefert, weil da alles in Ordnung war. Ich habe angenommen, dass, wenn sich dort kein Paketverlust bemerkbar macht, dies dann auch keine Ursache für die Paketverluste auf den Tunneln sein könnte. Und dann kommt noch der gestreute FUD, das oVirt und die Plattform, auf der es Läuft, nichts kann; und dann schaue ich auf die falschen Ecken in der wenigen, vorhandenen Zeit.

Vielen Dank für die Infos zu den von Euch benötigten Daten.

Was stand denn nun so kritisches im sysctl.conf drin ? Ich möchte jetzt nun auch nicht dumm sterben ! :slight_smile:

Arrrgs never mind, habe im Moment viel nachzuholen hier im Forum und gerade habe ich den Erklärbär dazu gefunden ! :slight_smile:

Evtl vllt in #12 ergänzen ?