Packetverlust o2 über Telekom FTTH

Warum O₂

Warenkorb

Service

Mein O₂

Vertragsverlängerung & Tarifwechsel

Jetzt Vertrag verlängern

mein-o2 flyout forwardlink with image

Schenken sie bis zu 50 % Rabatt

3 Codes für Familie und Freunde sichern

forwardlink with image

Hallo Zusammen,

seit etwa 2 Wochen bin ich nun über das Netz von Telefonica o2 online, konnte allerdings verzeichnen dass bei meinem Anschluss ein Packetverlust im Rahmen von 0.05-0.20% auftritt, das quasi rund um die Uhr.

Eine einschränkung in der Nutzung ist nicht wirklich spürbar, die meisten Anwendungen kommen mit solch geringfügigen Verlust klar und gleichen das aus, allerdings ist es nicht “sauber”.

Es wurde meinerseits ein Störungsticket über der Hotline eröffnet, dies wurde nach einem Telefonat mit der technischen Abteilung auch mit einer aus meiner Sicht legitime Begründung geschlossen. Hier sollte/darf man erwähnen, dass o2 mich hier absolut positiv überrascht hat, es wurde sich ausgiebig Zeit genommen und die Fachabteilung wusste auch wovon sie redet, das habe ich bisher (bei anderen Anbietern) nicht so erleben dürfen. Die Kurzfassung ist, GPON ist sauber, Paketverlust kommt von woanders.

Da ich der einzige Kunde der solch eine Störung meldet, würde sich das die entsprechende Abteilung auch nicht ansehen, was ich völlig nachvollziehen kann. Daher hier den öffentlichen Versuch, das Licht auf der Thematik zu rücken. Letzten endes kann ich mir auch gut vorstellen, dass ich mit dieser Kombination (o2 auf Telekom FTTH) in der näheren Umgebung ein Exot bin, da die Telekom erst vor wenigen Monaten endlich dazu kam die FTTH Plattform auf das Gigabit Geschäftssystem zu migrieren, was aber vorraussetzung ist um bei o2 über FTTH ein Anschluss zu erhalten.

Der Packetverlust hat erst angefangen, als die PPPoE Daten vom alten Anbieter zu o2 gewechselt wurden. Sowohl die Aktive als auch die Passive technik ist exakt gleich geblieben, wie vor dem Wechsel des Anbieters.

Um den Monitoring gegenzuprüfen, habe ich den Ausschlussverfahren gewählt.
Hier habe ich mich einer RIPE Atlas Probe bedient, bzw. dessen IPv4 Adresse, die sich im o2 Netz (AS6805) befindet. Diese ist allerdings laut den Angaben per VDSL2 angebunden, befindet sich aber geographisch möglichst nah an mein Wohnort. Gemonitort wird nur IPv4.

Wenn ich beispielsweise den Monitoring statisch konfiguriere, also nicht per Dynamischen DNS meinem Anschluss “verfolge”, verschwindet auch den Packetverlust sobald meine “alte IP” jemand anderes erhält.

Auch konnte ich am 05.08.24 feststellen, dass morgens etwa 2h der Anschluss sauber lief, leider fing den Packetverlust danach wieder an.

Eventuell kriege ich über diesen Kanal das nötige Licht auf das Thema gerückt, vor allem wenn sich weitere betroffenen finden, die ebenfalls mehr “masse” bilden, so dass sich die entsprechend korrekte Stelle das ganze ansieht.

Wenn ich irgendwelche Diagnosedaten oder irgendwas tun kann um zu unterstützen, tue ich das selbstverständlich sehr gerne.

So sieht zurzeit (und seit der Schaltung des Anschlusses auf o2) aus:

Am 31.07.24, vor dem Anbieterwechsel:

Am 01.08.24, vor und nach dem Wechsel der PPPoE Verbidung:

Hier die 100% Verlust abschnitte ignorieren, das waren reboots des Routers, wichtig ist den Verlust um etwa 0.1% seit etwa 8 Uhr (die Zeitangabe der Grafik ist die UK Zeit).

Am 05.08.24 mit dem Zeitfenster, als der Anschluss 2h sauber lief:

Man sieht ab etwa 9 Uhr bis 11 Uhr auf der Grafik, dass kein Verlust mehr auftrat.

Heute:

PPPoE Reconnect ist auf 6:09 morgens eingestellt, deshalb findet man auch täglich um die Zeit einen erhöhten Verlust, während der Router sich neu einwählt und die neue IPv4 per DNS propagiert wird, das ist aber völlig normal und auch nicht das Problem.

Den Packetverlust kann ich ebenfalls betrachten, wenn ich meinem first hop nach meiner öffentlichen IPv4 Adresse anpinge. Ping geht in diesem Test von meinem Client im LAN zu dem first Hop nach der öffentlichen IPv4 des Routers.

Wenn ich bei Thinkbroadband den Router +1 Hop und Router +2 Hop monitore sieht es so aus:

Router +1

Router +2

Allerdings muss man hier erwähnen, dass das nur sehr wenig aussagekräftig ist, da Router zwischen Quelle und Ziel nicht unbedingt immer auf ICMP antworten, da das nicht essenziell ist. Sie sollen ja eher den Traffic weiterleiten als auf “dumme Pings” zu antworten, aber ich denke zur Fehlesuche ist es besser als garnichts.

Zwar ist auch der Zeitraum noch extrem Kurz, allerdings erkennt man schon den nicht vorhandenen Paketverlust. Ich bin erst vorhin auf die Idee gekommen die Monitore so zu ergänzen...

Trotz dieser Einschränkung, sieht man dass beide Hops fehlerfrei zu Thinkbroadband antworten, somit würde ich laienhaft die Vermutung stellen, dass es zwischen mein Router und den ersten (sichtbaren) Hop ins o2 Netz liegt. Zwischen BNG und meinem Router aber eher weniger, da er den gleichen ist wie beim alten Anbieter (o2 schaltet ja auch L3-BSA, und der alte Anbieter war WIA, beide “Arten” nutzen den BNG des Vorleisters) und auf xPON Ebene ist es sowohl laut der o2 Technik als auch laut meine Meinung sauber, da sonst auch hier der Packetverlust beim alten Anbieter aufgetreten wäre.

Nun bleibe ich gespannt, wie sich hier die Geschichte entwickeln wird :)

Seite 1 / 2

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...

Vielleicht ist es ja etwas aehnliches…

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.

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

Gut!

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,

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?

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.

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?

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.

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?

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.

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

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).

Nur die Nummer oder auch der Orts-Code?

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

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

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.

kommt auch weiterhin zum Packetloss auf deiner Leitung?

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.

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 :-)

Kein Problem, dir erstmal eine gute Auszeit :)

Hi @o2_Lars,

wie sieht es inzwischen aus? Schickst du mir eine Privatnachricht dass ich die verschiedenen Daten (BNG Namen, Router IP Adressen, ...) geben kann? :)

Danke vorab

Hallo @o2_Lars,

die Privatnachricht zur Übertragung der Informationen war natürlich nur ein Vorschlag, vielleicht gibt es einen besseren Weg, dir die Infos zu übermitteln damit die infragekommenden Netzelemente überprüft werden können

Hallo @o2_Giulia,

scheint so, als wäre @o2_Lars nicht mehr aktiv.

Gerne eröffne ich auch erneut einen Ticket über die Hotline, oder irgendwas in der Richtung, bin für jeden Vorschlag offen.

Allerdings wäre es mir schon recht, wenn sich die Anbindung zwischen “meinem” BNG und euer Netz angeschaut wird, da das Paketverlust nach wie vor vorhanden ist und “eigentlich” nicht da sollte. Sollte ich mit meiner Vermutung richtig liege, wären alle o2 Kunden an “meinem” BNG vom Problem betroffen, sofern sie dies überhaupt messen würden/können (was ja die wenigsten Kunden tun).

Ebenfalls, sofern meine Vermutung korrekt ist, müsste man sich nicht direkt meinem Anschluss ansehen, da er bisher, vor Anbieterwechsel zu euch, problemlos lief. Jedoch habe ich nicht die selbe Kenntnis und nicht die selben Werkzeugen die euch zur Verfügung stehen und kann daher auch nicht unbedingt in die nötige Detailtiefe das Problem analysieren.

Damals konnte es Lars mit pufferueberlauf0, der quasi das selbe Problem hatte, lösen, aber leider antwortet er nicht mehr. Da du dich auch mit Glasfaser super auskennst, habe ich mich erlaubt dich hier zu taggen.

Der Vollständigkeit wegen gehört allerdings auch dazu, dass vertraglich bis zu 1% Paketverlust in Ordnung sind, diese Schwelle wird hier nicht überschritten. Es würde also der Leistungsbeschreibung nach, kein Handlungsbedarf bestehen.

Hey @almightyloaf,

bin durchaus noch aktiv, im Regelfall aber ein wenig in anderen Bereichen und etwas weiter hinter den Kulissen, hab da leider weniger auf meine Inbox geachtet, mea culpa… :-/

Ich wollte mal einen Blick auf den Anschluss werfen, leider ist mit dem Community-Profil kein Festnetzanschluss verbunden. Naja, finden wir im Zweifelsfall eine Lösung :-)

Magst du einmal einen Trace hochladen (ohne deine öffentliche IP), wo da grundlegend schon mal der durchgehende Packetloss ersichtlich ist?

Das wäre dann schon einmal ein erster Ansatzpunkt, wo ich schon mal jemanden drauf hinweisen kann, dass da allen Anscheins nach wohl etwas hakt.

Gruß,
Lars

Hi @o2_Lars,

kein Thema, kann ich verstehen. Hatte mich nur schon angefangen zu wundern warum es keine Rückmeldung mehr gab und vermutet, dass du in der Community eben nicht mehr aktiv bist :)

Gerne mache ich gleich für IPv4 und IPv6 Traceroutes zu 2-3 verschiedenen Zielen.

Allerdings vorab, da meine Vermutung auf ein Problem zwischen BNG und Übergabe in euer Netz ist, fürchte ich dass man daraus noch nicht schlau wird.

Zum Profil, den Anschluss mit meinem Profil zu verknüpfen ist sagen wir mal schwierig da er nicht “mir direkt” gehört, die Trennung ist bewusst und so erwünscht. Sollte es Bedarf geben, habe ich jedoch alle nötigen Daten für die Verwaltung des Anschlusses, dann eben über die Hotline. Somit besteht auch die Möglichkeit ein Ticket bei Bedarf zu eröffnen, und/oder den Tarif zu wechseln etc., aber eben halt leider nicht die Kundendaten für “diesen” Anschluss in meinem Profil zu hinterlegen.

So, lange Rede wenig Sinn, hier die Traceroutes:

IPv6:

Ziel: www.heise.de

  1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-5c8d-e707-IPv6-e7a9.310.pool.telefonica.de 32a02:3100:5c8d:e707:IPv6:e7a9]
  2     6 ms     6 ms     6 ms  2a02:3001::23c
  3     *        *        *     Timeout.
  4     6 ms     *        *     ipv6.de-cix.fra.de.as12306.plusline.net e2001:7f8::3012:0:1]
  5     *        *        *     Timeout.
  6     6 ms     6 ms     6 ms  2a02:2e0:3fe:0:c::1
  7     6 ms     6 ms     6 ms  www.heise.de  2a02:2e0:3fe:1001:7777:772e:2:85]