# Packetloss, quantelnd **URL:** \ **Category:** FFRL Backbone\ **Created:** [7. Juli 2018 um 15:47 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137 "2018-07-07T15:47:33Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [7. Juli 2018 um 15:47 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/1 "2018-07-07T15:47:33Z")
Hat jemand einen Tipp, wie man da weiter debuggen könnte? (Es besteht Zugriff auf den Router, der die ffrl-gretunnel baut) Und nein, es betrifft allem Anschein mehrere ffrl-AS-Bleche, neanderfunk (2a03:2260:300e::/48) ist hier nur ein willkürlich gewähltes Beispiel. ![grafik](https://forum.freifunk.net/uploads/default/original/3X/4/2/4235bfeae85a5ba2e2c0eb9ae8a4eaf0b1ee7f38.png) Und ja, die beiden Probes liefen parallel, auf dem gleichen clientdevice, das definitiv nur „über Freifunk“ angeschlossen ist. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [7. Juli 2018 um 16:17 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/2 "2018-07-07T16:17:17Z")
p.s Echte Aussetzer gab es in dem Zeitraum nicht. der wget-spiderrequest (test alle 5 Minuten) auf ipv4 und ipv6 einer bekannten Webseite mit Timeout 1000ms und 2 maxTries hat immer funktioniert spätestens im zweiten Versuch. ![grafik](https://forum.freifunk.net/uploads/default/original/3X/a/c/ac717d93d3aa6ca865fa5a0c108229262fb56a46.png) ---
**Author:** ![MPW](https://forum.freifunk.net/user_avatar/forum.freifunk.net/mpw/32/4433_2.png) [@MPW](https://forum.freifunk.net/u/MPW)\ **Post date:** [8. Juli 2018 um 16:43 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/3 "2018-07-08T16:43:20Z")
MTR ist ja immer so eine Sache, hast du mal einen normalen Dauerping getestet? ---
**Author:** ![rotanid](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/r/3ec8ea/32.png) [@rotanid](https://forum.freifunk.net/u/rotanid)\ **Post date:** [8. Juli 2018 um 20:30 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/4 "2018-07-08T20:30:02Z")
> [@MPW](#): > > MTR ist ja immer so eine Sache leicht OT, aber was sind die Probleme die du damit siehst? ---
**Author:** ![ChrisD](https://forum.freifunk.net/user_avatar/forum.freifunk.net/chrisd/32/20560_2.png) [@ChrisD](https://forum.freifunk.net/u/ChrisD)\ **Post date:** [8. Juli 2018 um 20:37 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/5 "2018-07-08T20:37:13Z")
ich hab z.t. auch bei mtr Packetloss auf manchen Strecken bei 50% und mehr… Die Verbindung ist aber absolut stabil (surfen, Downloads, Videostream & co gehen total problemlos) und ein „normaler“ Ping hat nahezu 0% packetloss. Wo das herkommt hab ich nie analysiert aber ich denke darauf will @MPW hinaus mfg Christian ---
**Author:** ![rotanid](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/r/3ec8ea/32.png) [@rotanid](https://forum.freifunk.net/u/rotanid)\ **Post date:** [8. Juli 2018 um 21:33 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/6 "2018-07-08T21:33:06Z")
hm, das hatte ich noch nie, und ich nutze es bei Freifunk und beruflich sehr häufig… ---
**Author:** ![MPW](https://forum.freifunk.net/user_avatar/forum.freifunk.net/mpw/32/4433_2.png) [@MPW](https://forum.freifunk.net/u/MPW)\ **Post date:** [9. Juli 2018 um 05:47 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/7 "2018-07-09T05:47:57Z")
@rotanid, die Jungs die Netzwerk professionell machen, können das sicher besser erklären, aber soweit ich es verstanden habe: MTR ist darauf angewiesen, dass dir die Hosts sagen, wenn die TTL eines Paketes abgelaufen ist. Nicht alle Hosts bzw. Router tun das immer, manche maximal alle x Sekunden. Es ist schon ein gutes Tool, hat aber seine Tücken bei der Interpretation. Viele Grüße und einen guten Start in die Woche! Matthias ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [10. Juli 2018 um 01:39 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/8 "2018-07-10T01:39:11Z")
> [@MPW](#): > > MTR ist darauf angewiesen, dass dir die Hosts sagen, wenn die TTL eines Paketes abgelaufen ist. Nicht alle Hosts bzw. Router tun das immer, manche maximal alle x Sekunden. Das gilt für MTR wie für tracer[ou]t[e]. Router sollen routen, Fehlermeldungen senden sie ggf. nur verzögert/nicht für jedes Paket/nur x Pakete pro Zeiteinheit. Tracer senden wiederum für jeden Hop ein neues Paket, welches am Ende des Lebenszyklus mit »Lebensdauer erreicht« vom Router beantwortet werden muß. Während für jedes „ping [mail.4830.org](http://mail.4830.org)“ genau ein (ICMP-) Paket auf die Reise geht, sind es bei einem herkömlichen traceroute wie unten z. B. 21 Pakete: eins mit Lebensdauer 1 (Hop), wird von 192.168.5.33 mit „Lebensdauer überrschritten“ beantwortet. Das nächste mit Lebensdauer 2 Hops, wird von 192.168.177.11 mit „Lebensdauer überrschritten“ beantwortet. Und so weiter, bis bei Paketen mit Lebensdauer 7 sich dann das Zielsystem (mit »alles angekommen hier bei W.X.Y.Z) meldet: ``` wusel@ysabell:~$ traceroute mail.4830.org traceroute to mail.4830.org (193.26.120.251), 30 hops max, 60 byte packets 1 192.168.5.33 (192.168.5.33) 3.038 ms 3.004 ms 2.976 ms 2 192.168.177.11 (192.168.177.11) 2.967 ms 3.007 ms 5.913 ms 3 62.155.243.28 (62.155.243.28) 10.673 ms 10.658 ms 10.631 ms 4 217.239.40.10 (217.239.40.10) 17.987 ms 17.969 ms 17.944 ms 5 bgp-ber01.4830.org (193.34.79.248) 20.568 ms 20.553 ms 20.521 ms 6 de2.as206946.net (193.26.120.246) 43.655 ms 40.355 ms 40.325 ms 7 mail.4830.org (193.26.120.251) 42.962 ms 42.962 ms 47.532 ms ``` ---
**Author:** ![MPW](https://forum.freifunk.net/user_avatar/forum.freifunk.net/mpw/32/4433_2.png) [@MPW](https://forum.freifunk.net/u/MPW)\ **Post date:** [10. Juli 2018 um 04:53 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/9 "2018-07-10T04:53:12Z")
Der Unterschied ist, dass bei einem normalen Traceroute eine Rückmeldung über die abgelaufene TTL ausreicht, wohingegen beim MTR das sekündlich erforderlich ist und das machen nicht alle Geräte mit. ---
**Author:** ![InaktiverAccount](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/i/f04885/32.png) [@InaktiverAccount](https://forum.freifunk.net/u/InaktiverAccount)\ **Post date:** [21. Juli 2018 um 17:16 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/10 "2018-07-21T17:16:11Z")
Ist das Problem weiterhin akut? ---
**Author:** ![Zumpel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/zumpel/32/407_2.png) [@Zumpel](https://forum.freifunk.net/u/Zumpel)\ **Post date:** [24. Juli 2018 um 06:41 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/11 "2018-07-24T06:41:40Z")
Ich hatte mal ähnliche Probleme. es lag an Proxmox. als ich dennserver für die vms aktualisiert habe war das problem erledigt. wenn ihr keine idee habt ggf auch hier mal schauen. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [24. Juli 2018 um 06:49 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/12 "2018-07-24T06:49:42Z")
da könnte ich allenfalls downdaten. Da sind wir leider evtl. etwas zu mutig… Derzeit sind es 4.13.13-5, 4.15.17-3 und 4.15.18-1 auf dem Proxmox im Einsatz und ich sehe keine Unterschiede. Wobei das Monitoring der äußeren IPs der VMS (als „FO-IPv4“ und der „IP aus dem Prefix des Bleches“) „aus dem Internet“ keine Auffälligkeiten zeigt. Sprich: Das virtio-ethernet der VM hat keine erkennbare Probleme „zum/ins Internet“. ---
**Author:** ![Zumpel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/zumpel/32/407_2.png) [@Zumpel](https://forum.freifunk.net/u/Zumpel)\ **Post date:** [24. Juli 2018 um 09:08 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/13 "2018-07-24T09:08:46Z")
Mich irritiert gerade, dass du mehrere Kernel gleichzeitig laufen hast. Deshalb nur sicherheitshalber: Bei uns war es das Blech. Also der Proxmox Server, kein Problem in der VM. Ich vermute dass ebtables paket was dabei installiert wurde hat es behoben. kann es aber nicht sagen. Soll nur ein Feedback sien manchmal auch zu schauen ob es auf dem blech ausserhalb der vm hängt… ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [24. Juli 2018 um 09:15 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/14 "2018-07-24T09:15:00Z")
> [@Zumpel](#): > > Mich irritiert gerade, dass du mehrere Kernel gleichzeitig laufen hast. Deshalb nur sicherheitshalber: Bei uns war es das Blech. > [@adorfer](#): > > Derzeit sind es 4.13.13-5, 4.15.17-3 und 4.15.18-1 auf dem Proxmox im Einsatz Ich verstehe Deine Antwort nicht. Es sind mehrere Systeme betroffen und dort laufen die genannten Kernel. Wenn Du sagst „nach einem Update ging es“, dann sei doch bitte so konkret zu sagen, mit WELCHEM GENAU es dann besser lief. (_„nimm den aktuellen Kernel“_ klingt für mich nach „Preisliste-aktuell.xls“) Und ja, ich kenne das Problem, dass die Österreicher je nach verwendeter Prozessorarchitektur durchaus unterschiedliche Kernel als „aktuell“ ausliefern. Daher würde eine fassbare Ansage zu „aktuell“ wirklich doppelt helfen, denn selbst „war der, der vorgestern aktuell war“ würde jetzt nur die Rückfrage von mir bringen: _„Für welche CPU?“_ ---
**Author:** ![Zumpel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/zumpel/32/407_2.png) [@Zumpel](https://forum.freifunk.net/u/Zumpel)\ **Post date:** [24. Juli 2018 um 09:24 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/15 "2018-07-24T09:24:08Z")
Ich hatte vermutet dass du mehrere VM meintest und nicht verstanden hattest, dass ich das Blech meinte. Du hast aber offensichtlich mehrere Proxmox Bleche laufen. Ich weiss nicht mehr welches Update es war. Ich wollte nur darauf hinweisen, dass ihr ggf. auch oberhalb der VMs auf Fehlersuche gehen sollt, wenn euch die Ideen ausgehen. Hier hat es geholfen. Mehr kann ich gar nicht beitragen. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [24. Juli 2018 um 09:42 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/16 "2018-07-24T09:42:05Z")
> [@Zumpel](#): > > Du hast aber offensichtlich mehrere Proxmox Bleche laufen. Im Freifunk-Kontext ich selbst 4 „eigene“, plus 4-5 weitere, um die mich mit kümmere. Und dann noch eine Hand voll außerhalb von Freifunk. Sprich: Ich kann -wenn es am Hypervisor liegen sollte- durchaus Dinge durchprobieren, zumal da auch eine bunte Mischung von phy/NICs, Prozessoren (Opteron, Xeon, i7) und Boards (Intel, Supermicro, HP). Ich kenne halt nur noch nichtmal eine sinnvolle Metrik mit der man dieses Problem „gegen einen Datenbannk/Graphen“ laufen lassen könnte. Sprich: Was/wie sollte man sinnvoll messen? Welche Endpunkte, welche dann herausfallenden Daten. (Ich habe ansatzweise verstanden, wie das mit den gretunneln funktioniert und dass es eine größere Menge von möglichten Metriken geben könnte. Ich nehme auch gern „mehr“, um dann die passende zu finden.) ---
**Author:** ![Zumpel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/zumpel/32/407_2.png) [@Zumpel](https://forum.freifunk.net/u/Zumpel)\ **Post date:** [24. Juli 2018 um 13:11 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/17 "2018-07-24T13:11:29Z")
hmmm… dein fehler scheint ja ausserhalb eures netzes zu entstehen. was wusel schreibt könnte relevant sein. sprich dass es kein packetloss ist, sondern lediglich keine rückmeldung der router. evtl könntest du das testen indem du zeitgleich gegen jeden der knoten in der mtr liste einen ping laufen lässt und ob der packetloss hier äquivalent ist. wenn du glück hast lügt lediglich mtr. das würde ich zumindest mal zum ausschluss probieren. ebenfalls spannend wäre ein externes Ziel (einen eigenen Server) zu tracen und von diesem aus den Rückweg zu prüfen… könnten routing probleme verantwortlich sein? was würde passieren, wenn ein server behauptet er kennt die route aber dort die pakete versacken. würde dann automatisch ein anderer server gewählt, der die pakete in das entsprechende netz routen würde, oder ist damit alles platt? wenn du ping machst, wäre es spannend zu sehen wie der packetloss zustande kommt. burstweise oder gleichmässig Stehen die Server in einem Verhältnis zueinander? Sind sie gleich konfiguriert? Also könnte der gleiche „Fehler“ in alle Systeme betreffen weil man immer übernommen hat? Für mich ist schräg, dass da soviel ausserhalb verloren gehen soll… habe aber gerade nur gedanken dazu Edit: Könntest Du ggf. mal die firewalleinstellungen des proxmox bleches posten? insbesondere die nf\_conntrack parameter? ich habe die bei mir hochgesetzt. Hast Du das an dieser Stelle auch? (Ich weiss nicht sicher ob das nötig ist) Weiter: gibt es auf Blechseite Auffälligkeiten im dmesg? ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [20. August 2018 um 11:26 UTC](https://forum.freifunk.net/t/packetloss-quantelnd/19137/18 "2018-08-20T11:26:09Z")
Leider hat sich bislang keine weitere Klarheit ergeben. Was ich sehen kann: 1. Services, die ich am Berliner-Standort des FFRL vermute, haben seit etwa 4. Juni ca- 13 Uhr irgendeine Änderung. (Achtung: Das Monitoring misst hier nur den Packetloss bei den Probes, bei denen überhaupt ein solcher eingetreten ist, nicht die Fälle in denen 0/5 verloren gehen, daher bewusst überzeichnend.) ![grafik](https://forum.freifunk.net/uploads/default/original/3X/6/b/6b54da0f10c9a7b19ad0bebb081c8c690d4492b8.png) ![grafik](https://forum.freifunk.net/uploads/default/original/3X/3/9/394f66c8a93c19a233047d836ddf843fdf769341.png) 1. eine andere Discourse-Installation (an anderem Standort) ist im gleichen Zeitraum völlig unauffällig, obwohl sie nicht im gleichen Rack (des Monitorings) steht, aber auf einem ähnlichen Setup aufgesetzt ist. Damit sind zumindest effekte "vom Discourse selbst) ![grafik](https://forum.freifunk.net/uploads/default/original/3X/5/5/558d5bbcb4564193cd4765caf79a97c5dcc0637e.png) das 1) läuft synchron mit dem Ping-Packetloss auf den äußeren Tunnelenden: ![grafik](https://forum.freifunk.net/uploads/default/original/3X/8/3/83005d248aec6eaa8a001e40e09fcbe3e706462b.png) Mir ist nicht klar, ob man da Phantome jagd oder nicht. Prinzipiell bin ich seit einigen Monaten geneigt vorzuschlagen, die (diese!) Forums-VM auf einen Host zu verlagern, der weniger mit Packetloss zu kämpfen hat (egal ob nun IPv4 oder IPv6, da beides irgendwie betroffen ist.). Einfach um die Häufigkeit der „Artikel kann nicht geladen werden“-Fehlermeldungen zu reduzieren.