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
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)
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.
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.
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.
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“.
Ich sehe hier null nutzbare Daten um das zu debuggen.
Welcher Tunnel ist betroffen? Bitte eigentsändig isolieren und einen konkreten benennen. IP Adressen beider Endpunkte benennen.
mtr von eurem zu unserem Endpunkt dabei packen
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.
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.
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.
erster Post
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?
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.
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.
