Mmmh, da gab es vor einiger Zeit schon mal Probleme:

Vielleicht ist es ja etwas aehnliches… Zum Monitoring verwende ich folgendes Script unter OpenWrt (per cron taeglich kurz nach Mitternacht gestartet, um den Paketverlust ohne Last zu bestimmen):

#!/bin/bash
# I occasionally end up with a pppoe session with background packetloss
# in the range of >= 0.5% (normally there is 0 spurious packet loss)
# so is that loss dependent on the IP segment and does the routing to
# pingbox1.thinkbroadband.com actually differ between lossy and lossless IPs

# maybe unify these and avoid -4/-6, what to do about wan/wan6
# cloudflare, O2, google, quad9, thinkbradband (pingbox1, IPv4 only)
# IPv4: DNS server plus pinggbox1
IP4_LIST=(1.1.1.1 62.109.121.2 8.8.8.8 9.9.9.9 pingbox1.thinkbroadband.com)
# IPv6: DNS-server; pingbox1 is IPv4-ony, www.thinkbroadband.co is served from cloudflare Hamburg, not London
IP6_LIST=("2606:4700:4700::1111" "2a01:c30::531" "2001:4860:4860:0:0:0:0:8888" "2620:fe::9")

OUT_DIR=/srv/persistent/routine_mtr_data
TMP_PROBE_COUNT=${1}
PROBE_COUNT=${TMP_PROBE_COUNT:=500} # reduced to 500 from 1000 to make room for the IPv6 probes: 9 * 500 -> >= 4500 seconds
# if empty use default order: "-o LSNABWV"
order_string="-o LSRDNBAWVGJMXI"        # everything

mtr_options_string="-ezbw"


for cur_ip in "${IP4_LISTI@]}"
do
    cur_outfile_fqn="${OUT_DIR}/${cur_ip}.mtr.txt"
    date >> ${cur_outfile_fqn}
    echo "testing ${cur_ip} for ${PROBE_COUNT} samples."
    echo "testing ${cur_ip} for ${PROBE_COUNT} samples." >> ${cur_outfile_fqn}
    ifstatus wan | grep \"address\" >> ${cur_outfile_fqn}
    ifstatus wan | grep \"ptpaddress\" >> ${cur_outfile_fqn}
    mtr -4 ${mtr_options_string} ${order_string} -c ${PROBE_COUNT} ${cur_ip} >> ${cur_outfile_fqn}
    echo "" >> ${cur_outfile_fqn}
    echo "" >> ${cur_outfile_fqn}
done

for cur_ip in "${IP6_LISTI@]}"
do
    cur_outfile_fqn="${OUT_DIR}/${cur_ip}.mtr.txt"
    date >> ${cur_outfile_fqn}
    echo "testing ${cur_ip} for ${PROBE_COUNT} samples."
    echo "testing ${cur_ip} for ${PROBE_COUNT} samples." >> ${cur_outfile_fqn}
    ifstatus wan6 | grep \"address\" >> ${cur_outfile_fqn}
    mtr -6 ${mtr_options_string} ${order_string} -c ${PROBE_COUNT} ${cur_ip} >> ${cur_outfile_fqn}
    echo "" >> ${cur_outfile_fqn}
    echo "" >> ${cur_outfile_fqn}
done

Seit Fruehjahr dieses Jahres antworten die O2 DNS Server nicht mehr auf ICMP Echo Requests…

Das Indiz war damals erhoehter Loss vom ersten Hop nach meinem Router bis zum Endpunkt. O2 hat sich des Problems angenommen und es letztlich auch behoben...

Tatsache, das liest sich so als wäre die Ursache ähnlich. Jedoch gibt es den Unterschied dass bei mir bisher egal welche IP ich erhalten habe den Packet Loss aufgetreten ist, allerdings die Hops die sich unmittelbar nach bzw. vor (je nach Sichtweise) meinem Router befinden, wenn von aussen gemonitored, sauber antworten und kein Verlust sichtbar ist. Ich konnte somit auch erstmal keine Gateways als “gut” einstufen, wie bei deinem Anschluss, aber ich habe auch nicht täglich den jeweils tagesaktuellen gemessen. Ggf. wäre das hilfreich, bin ich mir aber nicht so ganz sicher, da auch ohne dieses zusätzliche Monitoring bereits erkennbar ist, dass es noch keinen “guten Gateway” gab.

Sieht daher für mich danach aus, als wäre es den gleichen oder zumindest einen sehr ähnlichen Fehler, aber an eine andere Stelle im Netz, gerade weil es relativ Standortgebunden zu sein scheint. Wenn ich meine IP direkt eintrage in Thinkbroadband und diese jemanden anderes Zugewiesen wird, verschwindet der Packet Loss damit genauso.

Bisher habe ich lediglich anlassbezogenes “Monitoring” in der Uploadrichtung, im Download wird über Thinkbroadband dauerhaft gemessen. Bisher hat es aber gereicht, spuren zu finden die zu eine erste Vermutung führen.

Aber schön zu sehen, dass o2 sich auch solchen kniffligeren Sachen annimmt und auch beheben kann, das kann auch nicht jeden Anbieter von sich behaupten. Es drückt auch weniger als bei deinem Thread, die Performanceeinbussen habe ich auch nicht bzw. spüre diese nicht und konnte diese auch nicht messen. Nur den Packetverlust ist messbar und gemessen worden.

Sieht daher für mich danach aus, als wäre es den gleichen oder zumindest einen sehr ähnlichen Fehler, aber an eine andere Stelle im Netz, gerade weil es relativ Standortgebunden zu sein scheint. Wenn ich meine IP direkt eintrage in Thinkbroadband und diese jemanden anderes Zugewiesen wird, verschwindet der Packet Loss damit genauso.

Mmmh, das deutet eventuell auf ein defektes Element ganz nah bei Dir hin. Hast Du Nachbarn die im selben PON-Baum haengen und auch FTTH nutzen? Waere interessant zu wissen, ob die auch betroffen sind.

Und ja, war schoen, dass O2 das nicht ignoriert hat und dran geblieben ist; hat etwas gedauert den Fehler zu finden und zu beheben. Leider gab es kein oeffentliches Post-Mortem so, dass unklar ist was genau die Ursache war.

Das dürften die allermeisten sein, hier gibt es sonst nur ADSL2+.

Ohne jetzt gefragt zu haben, werden sie mit hoher Wahrscheinlichkeit nicht bei o2 sein und der Aussage der o2 Technik, dass es auf PON Ebene sauber aussieht, glaube ich nach wie vor, unter anderem, weil das Problem erst nach dem wechsel auf den Zugangsdaten von o2 auftrat (und wahrscheinlich im BNG das umschalten von WIA auf L3-BSA, da direkt nach der Schaltung meine alten WIA Zugangsdaten nicht mehr funktionierten, vor der Schaltung auch die L3-BSA nicht gingen, obwohl sie Vertragstechnisch beide am selben Tag funktional sein sollten) aber auch weil die Telekom bisher auf der letzten Meile sehr unauffällig war, somit auch ein gewisses Vertrauensvorteil existiert.

Allerdings ist das natürlich ein Ansatzpunkt, der eigentlich zu prüfen gilt, da hast du völlig recht, ist aber im Rahmen des Tickets den ich eröffnet hatte von o2 bereits gecheckt worden. Man müsste also diese Prüfung erstmal infrage stellen, ich bevorzuge aber weiterhin noch die Variante des gestörten Netzelements im o2 Netz zwischen BNG und den ersten Hop nach meinem Router. Auch weil die Problematik in ähnlicher Form bei o2, siehe dein Thread, bereits in der Vergangenheit vorkam.

Im Rahmen der Migration auf dem Gigabit Geschäftssystem hat der BNG auch den Namen gewechselt, was entweder bedeuten kann dass aus einem zwei BNGs wurden, oder dass der alte BNG nur für die alte Plattform galt (was mich aber eher wundern würde, wenn ein BNG agnostisch gegenüber Übertragungstechnologie sein soll, daher denke ich eher dass gesplittet wurde, oder er wurde nur umbenannt). Jedoch gab es auch mit dem neuen BNG (und die neue GGS Plattform) und dem alten Anbieter kein Paketverlust, somit werte ich den BNG (und die neue GGS Plattform) erstmal auch als sauber.

Gut!

Hat O2 denn tatsaechlich Einsicht in ie PON Ebene? Soweit ich weiss werden die bei L3-BSA ueber die L1-Details des Zugangslinks eher weniger informiert?

Ah, macht Sinn. WIA war ueber 1&1?

Da sind allerdings noch eine Reihe von Telekom-Elementen zwischen BNG und O2-Uebergabepunkt die potentiell Probleme haben koennten. Aber O2 ist Dein ISP, da macht es Sinn erstmal die Komponenten unter O2-Kontrolle zu ueberpruefen...

Nur die Nummer oder auch der Orts-Code?

Klang jedenfalls sehr stark danach, der Techniker hat die Modemwerte sich angesehen und auch die Fehlerrate, es sei (und das glaube ich auch gerne) sauber. Das ist jetzt natürlich aus dem Gedächtnis aus dem Gespräch, vielleicht habe ich auch zu viel hineininterpretiert.

Korrekt. AS3320 und so, ist ja keine unbekannte Thematik :)

Genau, mehr einschränken kann ich aus meiner Perspektive nicht (oder es gibt etwas was ich nicht versucht habe), es liegt (allem Anschein nach) zwischen mein Router und den ersten sichtbaren Hop. Ich kann weder OLT noch BNG “anfassen”, noch sonstigen Geräten die dazwichen liegen aber in einem Traceroute nicht sichtbar sind. Lediglich ein wenig Ausschlussverfahren kann ich betreiben, indem ich das ausschliesse, was vorher über WIA noch fehlerfrei lief (also den Modem, den PON, den Router und solchen Sachen).

Hätte ich dran denken sollen, Ortscode ist gleich, Nummer ist von 01 auf 02.

Hätte ich dran denken sollen, Ortscode ist gleich, Nummer ist von 01 auf 02.

Ah also anderes BNG Chassis in der selben Betriebsstelle, da kann dann natuerlich schon der neue BNG einen Schaden haben.

Jaein, könnte sein, jedoch war der neue BNG vor dem Anbieterwechsel bereits einiger Zeit aktiv und zeigte keine Auffälligkeiten. Könnte aber sein, in so einem Nischenfall darf man nur wenig ausschließen.

Vielleicht schaut mal demnächst freundlicherweise ein Moderator vorbei, mit Infos wie ich personenbezogene Daten zum zu entstördenem Anschluss (wobei rein theoretisch hier ein ganzer “BNG Bereich” -möglicherweise- betroffen ist) mitteilen kann :)

IPv4 Adressen hatte ich mal (93.x, 78.x, auch wenn selten) in andere Bereiche wie sonst üblich (77.x), machte aber keinen Unterschied. Spricht also weiterhin für eine Störung die in BNG nähe ist.

Ah, heute gab es wieder einen (seltenen) Tag wo wenige Stunden kein Packetverlust gemessen worden ist.

Präfix (IPv4) ist zurzeit 78.48.0.0/13, PPPoE Verbindung hat sich aber nicht getrennt/geändert zwischen den Zeiten mit und ohne Packetverlust.

Hilft zwar nicht viel, aber es ist besser als gar keine Daten/Messungen würde ich mal sagen.

Und wieder einmal einen kurzen Zeitraum mit (so gut wie) kein Packetverlust. Ich habe auch von meinem Client heraus 3000 ICMP Pakete gesendet, auch da betrug den Loss in dem Zeitraum 0% bzw. 0 verlorene Pakete von 3000.

Mache ich den Test “jetzt”, wo den Packetverlust wieder auftritt, bin ich bei 0.2% (6 von 3000), auch wenn es sich hier natürlich um eine Momentaufnahme von wenigen Minuten handelt.

Der heutige IPv4 Netz ist 77.176.0.0/12, auch wenn das eigentlich egal ist, da es bisher bei allen IPv4 präfixe auftritt.

Ich habe mich mal bei diesem Friendly User Test angemeldet, mal sehen ob das Problem mit der Messung etwas sichtbarer wird.

Hi @o2_Lars,

du hast bei pufferueberlauf0 damals dir das Thema angesehen, es scheint “hier” ein ähnliches Verhalten zu geben, jedoch deutlich regionaler.

Kannst du dir das bei gelegenheit ansehen bzw. mir sagen wie ich personenbezogene Daten übermitteln kann, so dass zu den Graphen und Messungen auch einen Anschluss zugeordnet werden kann?

Vielen Dank im Voraus

Hallo @almightyloaf,

bitte entschuldige die späte Rückmeldung, der Beitrag scheint mir durchgerutscht zu sein :-/

Ganz kurz vorab zu einer potentiellen Datenübermittlung: Sollte sich der Festnetzanschluss unter der gleichen Kundennummer befinden wie unter den Daten, mit denen du dich auch hier in unserer Community anmeldest, werden wir das schon hinbekommen, falls nicht, na, ich bin sicher, da werden wir auch einen Weg finden. :-)

Es kommt auch weiterhin zum Packetloss auf deiner Leitung? Zum Glück ist er nicht ganz soOo hoch aber ja, du hast recht, sauber ist das nicht. Ich behalte das ganze erst einmal in meiner Inbox, werde aber leider erst wieder in zwei Wochen in unserer Community unterwegs sein, hab das dann aber auch schon mal direkt im Auge :-)

Gruß,

Lars

Hi Lars, kein Thema. Wie gesagt, ist eher unschön als schmerzhaft, daher auch recht unkritisch.

Genau letzteres ist der Fall, der Anschluss läuft über einen anderen o2 Account, den ich auch nicht mit “diesem hier” verknüpfen kann da er nicht mir direkt gehört. Sollte es Bedarf geben, habe ich jedoch alle nötigen Daten für die Verwaltung des Anschlusses, dann eben über die Hotline.

Ja, seit Schaltung am 01.08.2024 ist die Situation unverändert. “pingbox1.thinkbroadband.com” ist nur per IPv4 erreichbar, bei “google.com” (dann über IPv6), gibt es den Packetloss ebenso, auch in vergleichbarer Menge. Somit dürfte es auch den Argument, der Fehler liege nah am Endkunde nochmals unterstützen. Den beschriebenen Test ist dann von meinem Client aus zu den jeweiligen Zielen. Die Graphen oben sind wiederum “die andere Richtung”, also aus dem Internet zu meinem Router.

Kein Problem, dir erstmal eine gute Auszeit :)